application: CILA - omnichain ifrastructure

[AlexShkor]

Project Abstract

The goal of this project is to implement an omnichain smart contract infrastructure support for Substrate framework. This will include the implementation of CQRS + Event Sourcing execution environment plus an example smart-contract. The implementation will be done using WASM and/or native Rust Substrate implementation as a pallet. The implementation will include implementing Protobuf support on-chain, serialization/deserialization, aggregated repository, event store, command/operations dispatcher, and events emitter.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) address in the application).
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[CLAassistant]

All committers have signed the CLA.

[takahser]

@AlexShkor thanks for submitting your grant proposal.
I've got a couple of questions:

• regarding "events relay" for cross-chain communication, what tech are you planning to use here? Protobuf?
• If yes, is there a reason not to use XCM here?
• Are you aiming to replace Substrates' storage APIs with mongodb for the scope of your project?
• If yes, what's the reasoning behind that?
• What's your strategy on syncing the mongodb state with other blockchain nodes?
• Storing all event will make it much easier to interact with these smart contracts. However, this comes at a cost: loads of additional storage. Did you think of ways to ensure scalability here, when compared to the more "traditional" model where events are not necessarily persisted after their emittance?
• Why did you add NFTs to the architecture diagram? Are they that elementary to the architecture? I would have imagined them to be just one of many things you can implement through the smart contract.
• Regarding M2, we don't usually support deployment efforts. Feel free to remove it or to add some code deliveries, such as automated tests, fuzz tests or other code-related deliverables.
• Regarding M3, are you trying to reuse any existing NFT standards here? If not, why?

[AlexShkor]

@takahser thank you for the questions.

regarding "events relay" for cross-chain communication, what tech are you planning to use here? Protobuf?
If yes, is there a reason not to use XCM here?

We use Protobuf as a cross-platform data format that can be implemented in any execution environment, and that is not specific to cross-chain communication but a general software framework. XCM is more specific and contains also some domain-specific features. We might actually utilize XCM for some infrastructural needs, but for omnichain smart-contracts, it's not a proper tool, and a general cross-platform data format like Protobuff, Thrift or Avro are a better fit.

Are you aiming to replace [Substrates' storage APIs](https://docs.substrate.io/build/runtime-storage/) with mongodb for the scope of your project?
If yes, what's the reasoning behind that?

MongoDB in our setup is just for storing the read model - infrastructure events/logs to aggregate data about execution details. For on-chain data, we will be utilizing Substrate Storage.

What's your strategy on syncing the mongodb state with other blockchain nodes?
It's not gonna be synced with blockchain nodes, it's just for read model data.

Storing all event will make it much easier to interact with these smart contracts. However, this comes at a cost: loads of additional storage. Did you think of ways to ensure scalability here, when compared to the more "traditional" model where events are not necessarily persisted after their emittance?

Having a complete event store is an essential module for omnichain smart-contracts to work. Yes, it comes with some tradeoffs.

Why did you add NFTs to the architecture diagram? Are they that elementary to the architecture? I would have imagined them to be just one of many things you can implement through the smart contract.

yes, it can be segregated, as it is just one of the possible smart contracts, we just decided to include it to have a full overview on one slide.

Regarding M2, we don't usually support deployment efforts. Feel free to remove it or add some code deliveries, such as automated tests, fuzz tests or other code-related deliverables.

Got it, thank you, we will update it.

Regarding M3, are you trying to reuse any existing NFT standards here? If not, why?

Yes, we are considering a number of formats to implement, but we have very strict requirements - for example, the design of the NFT standard should not violate the single responsibility design principle, which is the case with most NFT standards since they include collection into it.

[takahser]

@AlexShkor

We use Protobuf as a cross-platform data format that can be implemented in any execution environment, and that is not specific to cross-chain communication but a general software framework. XCM is more specific and contains also some domain-specific features. We might actually utilize XCM for some infrastructural needs, but for omnichain smart-contracts, it's not a proper tool, and a general cross-platform data format like Protobuff, Thrift or Avro are a better fit.

Ok, fair enough.

MongoDB in our setup is just for storing the read model - infrastructure events/logs to aggregate data about execution details. For on-chain data, we will be utilizing Substrate Storage.

I see, so it serves just as a local cache, right? In that case I'm fine with it.

Yes, it comes with some tradeoffs.

I imagine it to be quite expensive. Is the event emittance being paid for somehow by the contract owner or the person who calls a corresponding function that emits the event?

Got it, thank you, we will update it.

Feel free to still include the purpose of these tests though.

Yes, we are considering a number of formats to implement, but we have very strict requirements - for example, the design of the NFT standard should not violate the single responsibility design principle, which is the case with most NFT standards since they include collection into it.

By that, do you mean that it's a problem that an NFT can be part of a collection? Afaik there are both type of standards: Those which are part of a collection and those which aren't. If you seek funding for the NFT development it would be good to learn what additional value your implementation brings to the ecosystem and why it's not viable to just reuse an existing standard/implementation.

[AlexShkor]

@takahser

I imagine it to be quite expensive. Is the event emittance being paid for somehow by the contract owner or the person who calls a corresponding function that emits the event?

yes, it will be paid by the original sender, the events will be batched with other smart contracts so it might help optimize the cost.

By that, do you mean that it's a problem that an NFT can be part of a collection? Afaik there are both type of standards: Those which are part of a collection and those which aren't. If you seek funding for the NFT development it would be good to learn what additional value your implementation brings to the ecosystem and why it's not viable to just reuse an existing standard/implementation.

Most probably we will reuse existing standards, I just wanted to mention here our approach to choosing a standard that we aim to reimplement in our omnichain format.

[takahser]

Thanks for the updates, I'm generally open to support M1 and M2.

Most probably we will reuse existing standards, I just wanted to mention here our approach to choosing a standard that we aim to reimplement in our omnichain format.

If you run your own standard, I'd expect you to justify why it's needed. On the other hand, if it's feasible to reuse an existing standard/implementation it would be the better option. However, in my personal opinion, it wouldn't really deliver any additional value to the ecosystem, and it's questionable if we should fund this. An alternative idea would be to deliver a market research report on existing NFT standards/implementations in the ecosystem as part of M3, which might help other teams in a similar situation to make a choice. In that case, I'd personally be open to support it.

[AlexShkor]

@takahser Thank you, it's actually a good idea since we will be doing it anyway to select a proper standard for the omnichain implementation.

[takahser]

@AlexShkor thanks for the updates, I'm happy to vote in favor of your application now. I'm going to share it with the other committee members, please note that it may take some time before you'll receive their feedback as we have currently a lot of open applications that need to be reviewed. Thank you for your patience in advance.

[keeganquigley]

Thanks for the deep dive @takahser and for making the changes @AlexShkor CQRS sounds like interesting tech, and a good use case for an alternative WASM implementation. LGTM.

[Noc2]

You clearly put a lot of effort into this. I'm happy to support it.

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at [email protected] and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀

[keeganquigley]

Hi @AlexShkor are you still working on this grant? If so please let us know, otherwise we will close it shortly due to inactivity. See my comment on the above milestone.