From 7763f5393c72fa3e5f8fdab52795f5c471a63255 Mon Sep 17 00:00:00 2001 From: Alex Shkor Date: Tue, 25 Apr 2023 15:07:09 +0100 Subject: [PATCH] application: CILA - omnichain ifrastructure (#1679) * application: CILA - omnichain ifrastructure * requested changes * Update applications/CILA-omnichain-infrastructure.md Co-authored-by: S E R A Y A * Update applications/CILA-omnichain-infrastructure.md Co-authored-by: S E R A Y A * Update applications/CILA-omnichain-infrastructure.md Co-authored-by: S E R A Y A * Update applications/CILA-omnichain-infrastructure.md Co-authored-by: S E R A Y A * requested changes fix * add details to automated tests delivery * added NFT standard research delivery * added NFT standard research delivery fix --------- Co-authored-by: S E R A Y A --- applications/CILA-omnichain-infrastructure.md | 511 ++++++++++++++++++ 1 file changed, 511 insertions(+) create mode 100644 applications/CILA-omnichain-infrastructure.md diff --git a/applications/CILA-omnichain-infrastructure.md b/applications/CILA-omnichain-infrastructure.md new file mode 100644 index 00000000000..208632f1bad --- /dev/null +++ b/applications/CILA-omnichain-infrastructure.md @@ -0,0 +1,511 @@ +# CILA - Omnichain Infrastructure + +- **Team Name:** Collective Intelligence Labs +- **Payment Address:** bc1qff0kjc6pyjkneyt3pctm5nahjpd9f774avz55x (BTC) +- **Level:** 2 + +## Project Overview :page_facing_up: + +### Overview + +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. πŸ› οΈπŸ‘¨β€πŸ’» + +### Introduction + +This project aims to add an omnichain smart contract infrastructure support for Substrate framework by implementing a CQRS + Event Sourcing execution environment. CQRS (Command Query Responsibility Segregation) is a design pattern that separates the command and query responsibilities of an application. Event Sourcing is a design pattern that represents the state of an application as a series of events that are stored in an event store. πŸ§¬πŸ’» + +### Implementation +The implementation of the omnichain smart contract infrastructure will be done using WASM and/or native Rust Substrate implementation as a pallet. The implementation will include the following components: + +#### Protobuf support on-chain +Protobuf is a language-agnostic binary serialization format that allows developers to define structured data schemas. The implementation will include support for Protobuf on-chain, which will enable developers to define smart contract interfaces using Protobuf. πŸ€–πŸ’Ύ + +#### Aggregate Repository +Aggregate Repository is a data storage module that manages the state and storage of aggregate objects. It provides methods for creating, reading, updating, and deleting aggregates. πŸ“ˆπŸ“Š + +#### Event Store +An event store is a database that stores events in the order they occurred. The implementation will include an event store, which will store all the events generated by the smart contract. πŸ—‚οΈπŸ“‘ + +#### Command/operations Dispatcher +A command/operations dispatcher is a component that receives commands/operations and dispatches them to the appropriate handler. The implementation will include a command/operations dispatcher, which will enable developers to define command/operation handlers for the smart contract. πŸššπŸ‘¨β€βœˆοΈ + +#### Events Emitter +An events emitter is a component that emits events. The implementation will include an events emitter, which will enable developers to define event handlers for the smart contract. πŸ“£πŸ”Š + +## Conclusion +The completion of this project will provide a powerful infrastructure for developers to build customized omnichain smart contracts on the Substrate framework. πŸ’ͺπŸ‘¨β€πŸ’Ό + +![architecture](https://i.imgur.com/QsmzpZR.png) + +## πŸš€ Technology Stack + +**Programming Language** - Rust πŸ¦€ + +**Blockchain Framework** - Substrate ⛓️ + +**Virtual Machine** - WebAssembly (WASM) πŸ•ΈοΈ + +**Serialization** - Protocol Buffers (protobuf) πŸ“œ: a language-agnostic data serialization format that allows for efficient and interoperable communication between different services and systems. + +**Design Patterns**: +- Event Sourcing πŸ“: a pattern that captures all changes to an application state as a sequence of events, which can be used to reconstruct the state at any point in time. +- Command Query Responsibility Segregation (CQRS) 🧬: a pattern that separates the read and write concerns of an application, using separate models and interfaces for each. +- Saga pattern 🌟: a pattern for coordinating distributed transactions across multiple services, ensuring consistency and reliability. +- Domain-Driven Design (DDD) 🏰: a design approach that emphasizes the importance of the domain model in shaping the architecture of a software system. + +**Database** - MongoDB πŸ—„οΈ: a NoSQL document database that provides scalability, flexibility, and high availability. + +**Testing Framework** - Rust Testing πŸ§ͺ: Rust has an inbuilt testing framework that enables testing of units of code in isolation. + +**CI/CD** - GitHub Actions πŸš€: a continuous integration and continuous deployment service that can automate the build and deployment processes. + +**Containerization** - Docker 🐳: a tool that allows for the creation, deployment, and running of applications in containers, providing a consistent runtime environment across different platforms. + + +# Documentation for Core Copmpontents + +# Dispatcher + +The `Dispatcher` is a component of the omnichain smart contract infrastructure that receives commands/operations and dispatches them to the appropriate handler. The `Dispatcher` class enables developers to define command/operation handlers for the smart contract. + +## Usage + +The `Dispatcher` can be used in the implementation of the CQRS + Event Sourcing execution environment for Substrate framework. It receives commands/operations from external sources, such as a client or a node, and routes them to the appropriate command/operation handler. + +To use the `Dispatcher`, developers first define a set of command/operation handlers for the smart contract. These handlers can be implemented as methods in a Rust struct. The `Dispatcher` class then instantiates this struct and routes commands/operations to the appropriate method based on the type of command/operation. + +## Benefits + +The `Dispatcher` provides a simple and flexible way to handle commands/operations in the smart contract. By defining a set of command/operation handlers, developers can easily add new functionality to the smart contract without having to modify the `Dispatcher` class itself. + +In addition, the `Dispatcher` enables developers to implement complex business logic in the smart contract by routing commands/operations to the appropriate handler. This allows for a more modular and maintainable codebase. + +## Conclusion + +The `Dispatcher` is a crucial component of the omnichain smart contract infrastructure. By enabling developers to define command/operation handlers for the smart contract, it provides a simple and flexible way to handle commands/operations. Its usage in the implementation of the CQRS + Event Sourcing execution environment for Substrate framework enables developers to implement complex business logic in a modular and maintainable codebase. + +# EventStore + +## Description + +The `EventStore` is a database that stores events in the order they occurred. It is a crucial component of the omnichain smart contract infrastructure support for Substrate framework. The `EventStore` class enables the storage of all events generated by the smart contract, allowing for a complete historical record of all transactions and changes to the smart contract's state. + +## Implementation + +The `EventStore` is implemented using an internal Substrate database. The `EventStore` stores events in the form of serialized binary data plus metadata, which can be easily deserialized for querying and analysis. + +## Features + +The `EventStore` includes the following features: + +- **Event storage:** The `EventStore` stores all events generated by the smart contract in the order they occurred, allowing for a complete historical record of all transactions and changes to the smart contract's state. + +- **Querying:** The `EventStore` allows for easy querying of events using various criteria, such as time range, event type, or specific parameters. + +- **Deserialization:** The `EventStore` can easily deserialize stored binary data for querying and analysis. + +- **Scalability:** The `EventStore` can handle large volumes of events and is designed for scalability. + +## Benefits + +The `EventStore` provides several benefits to developers building smart contracts on the Substrate framework, including: + +- **Transparency:** The `EventStore` provides a complete historical record of all transactions and changes to the smart contract's state, ensuring transparency and accountability. + +- **Auditability:** The `EventStore` allows for easy querying and analysis of events, enabling developers to audit the smart contract's behavior and ensure compliance with regulations and business rules. + +- **Flexibility:** The `EventStore` can handle a wide range of event types and is designed for scalability, providing flexibility for developers building smart contracts on the Substrate framework. + +## Conclusion + +The `EventStore` is a crucial component of the omnichain smart contract infrastructure support for Substrate framework. It provides event storage, querying, deserialization, and scalability features, enabling developers to build transparent, auditable, and flexible smart contracts on the Substrate framework. The completion of this project will provide a powerful infrastructure for developers to build customized smart contracts on the Substrate framework, with the `EventStore` serving as a key component of this infrastructure. + +# Snapshot Store + +## Overview +The `Snapshot Store` is a component of the omnichain smart contract infrastructure that provides a way to store and retrieve snapshots of the smart contract state. A snapshot is a read-only view of the smart contract state at a particular point in time. Snapshots are useful for optimizing the performance of the smart contract by reducing the amount of data that needs to be read from the event store. + +## Implementation +The implementation of the `Snapshot Store` includes the following components: + +- `Snapshot Store`: The Snapshot Store is the primary component. It provides an interface for storing and retrieving snapshots of the smart contract state. +- `Snapshot Index`: The Snapshot Index is a data structure that is used to index snapshots by their version. It allows for efficient retrieval of the latest snapshot. +- `Snapshot Writer`: The Snapshot Writer is a component that is used to write snapshots to the Snapshot Store. It receives the current state of the smart contract and writes it to the Snapshot Store as a snapshot. +- `Snapshot Reader`: The Snapshot Reader is a component that is used to read snapshots from the Snapshot Store. It receives a snapshot version and returns a read-only view of the smart contract state at that version. + +## Conclusion +The `Snapshot Store` provides a way to store and retrieve snapshots of the smart contract state, which can be used to optimize the performance of the smart contract. The implementation includes the `Snapshot Store`, `Snapshot Index`, `Snapshot Writer`, and `Snapshot Reader` components. The completion of this component will provide a pefrormance optmization for omnichain smart contracts on the Substrate framework. + +# Aggregate + +The `Aggregate` is a core component of the CQRS + Event Sourcing design pattern. It represents the current state of an entity and is responsible for handling commands and producing events. + +## Description + +An `Aggregate` is a stateful object that represents a single entity in the system. It maintains its state by applying events to its internal state. A new state can be generated by applying new events to the existing state. + +In the context of the Substrate framework, an `Aggregate` is implemented as a Rust struct that contains its internal state and a set of methods to apply events and handle commands. + +## Implementation + +The `Aggregate` is implemented using the following components: + +### Internal state + +The internal state of an `Aggregate` is represented as a Rust struct. The struct contains all the data necessary to represent the current state of the entity. + +### Command handling + +The `Aggregate` contains a set of methods to handle commands. These methods accept a command object as input and return a set of events that represent the result of executing the command. + +### Event sourcing + +The `Aggregate` implements event sourcing by maintaining a list of events that have been applied to the internal state. When a new command is received, the `Aggregate` applies the appropriate events to generate a new state. + +### Snapshotting + +The `Aggregate` implements snapshotting by periodically storing a snapshot of its internal state. When an `Aggregate` is retrieved from its event stream, it can be initialized with the latest snapshot and then apply only the events that occurred after the snapshot. + +## Conclusion + +The `Aggregate` is a core component of the CQRS + Event Sourcing design pattern. It represents the current state of an entity and is responsible for handling commands and producing events. The implementation of the `Aggregate` in the Substrate framework provides a powerful mechanism for building complex and scalable smart contracts. + + +# AggregateState + +The `AggregateState` represents the state of an aggregate object in the event sourcing pattern. It is responsible for maintaining the current state of the aggregate object by processing the events that have occurred in the past. + +### Properties + +- `id`: The unique identifier of the aggregate object. +- `version`: The version of the aggregate object. +- `events`: The list of events that have occurred in the past. + +### Methods + +- `apply_event(event)`: Applies the given event to the current state of the aggregate object. This method updates the state of the aggregate object based on the event that occurred. +- `get_version()`: Returns the version of the aggregate object. +- `get_events()`: Returns the list of events that have occurred in the past. + +### Usage + +To use the `AggregateState` , you must first create an instance of it and initialize it with the current state of the aggregate object. You can then apply events to the aggregate object by calling the `apply_event()` method. + +## Diagramm + +Architecture Overview Diagram +![Diagramm](https://i.imgur.com/nWGtuEc.png) + +Flow Diagramm + +![Diagramm](https://i.imgur.com/1jeLNo1.png) + +Command Processing Flow Diagramm + +```sql + +------------+ +------------+ +-----------------+ +-------------------+ +------------+ + | Application| | Router | | Execution Chain | | Event Relay Node | | Aggregation| + +------------+ +------------+ +-----------------+ +-------------------+ +------------+ + | | | | | + | Command Request | | | | + |------------------>| | | | + | | | | | + | Command Handler | | | | + |------------------>| | | | + | | Command Request | | | + | |------------------->| | | + | | | Execute Command (CQRS) | | + | | |--------------------------->| | + | | | | Store Event (ES) | + | | | |----------------------------->| + | | | | | + | | | | Broadcast Event to | + | | | | Other Chains | + | | | |--------------------------->| + | | | | | + | | | | Transmit Event to | + | | | | Aggregation Cluster | + | | | |----------------------------->| + | | | | | + | | | | Process Events and | + | | | | Produce Aggregated Data | + | | | |<-----------------------------| + | | | | | + | | | | Return Aggregated Data | + | | | |<-----------------------------| + | | | | | + +``` + +# API Documentation + +## Domain + +### Aggregate + +#### `AggregateState` + +##### Methods + +* `new() -> Self`: Creates a new instance of `AggregateState`. +* `apply_events(&mut self, events: Vec) -> Result<(), String>`: Applies a list of domain events to the aggregate state. +* `clear(&mut self)`: Clears the state of the aggregate. + +#### `DomainEvent` + +##### Methods + +* `new(evnt_type: DomainEventType, evnt_payload: Vec) -> Self`: Creates a new instance of `DomainEvent`. +* `serialize(&self) -> Result, String>`: Serializes the domain event to a byte array. + +#### `DomainEventType` + +##### Variants + +* `NFT_MINTED` +* `NFT_TRANSFERED` + +### Entities + +#### `NFT` + +##### Fields + +* `hash: [u8; 32]`: The unique hash of the NFT. +* `owner: Address`: The address of the owner of the NFT. + +##### Methods + +* `new(hash: [u8; 32], owner: Address) -> Self`: Creates a new instance of `NFT`. +* `get_hash(&self) -> [u8; 32]`: Returns the hash of the NFT. +* `get_owner(&self) -> Address`: Returns the owner of the NFT. +* `transfer(&mut self, new_owner: Address)`: Transfers the ownership of the NFT to a new owner. + +## Application + +### Command + +#### `Command` + +##### Fields + +* `cmd_type: CommandType` +* `cmd_payload: Vec` + +##### Methods + +* `new(cmd_type: CommandType, cmd_payload: Vec) -> Self`: Creates a new instance of `Command`. +* `serialize(&self) -> Result, String>`: Serializes the command to a byte array. + +#### `CommandType` + +##### Variants + +* `MINT_NFT` +* `TRANSFER_NFT` + +### Service + +#### `CommandDispatcher` + +##### Methods + +* `dispatch(command: Command) -> Result<(), String>`: Dispatches a command to the appropriate handler. + +#### `NFTService` + +##### Fields + +* `state: NFTsState` +* `event_store: Box` +* `dispatcher: Box` + +##### Methods + +* `new(state: NFTsState, event_store: Box, dispatcher: Box) -> Self`: Creates a new instance of `NFTService`. +* `handle_command(&mut self, command: Command) -> Result<(), String>`: Handles a command by dispatching it to the appropriate handler. +* `get_nft_owner(&self, hash: [u8; 32]) -> Option
`: Returns the owner of an NFT with the given hash. + +### Event + +#### `DomainEventType` + +##### Variants + +* `NFT_MINTED` +* `NFT_TRANSFERED` + +#### `DomainEvent` + +##### Fields + +* `evnt_type: DomainEventType` +* `evnt_payload: Vec` + +##### Methods + +* `new(evnt_type: DomainEventType, evnt_payload: Vec) -> Self`: Creates a new instance of `DomainEvent`. +* `serialize(&self) -> Result, String>`: Serializes the domain event to a byte array. + +### Store + +#### `AggregateRepository` + +##### Fields + +* `event_store: Box` + +##### Methods + +* `new(event_store: Box) -> Self`: Creates a new instance of `AggregateRepository + +🌟 **Ecosystem Fit:** 🌟 + +πŸ”Ή **Project's Fit:** CILA will provide an infrastructure for building efficient omnichain smart contracts that can be integrated into the Polkadot ecosystem, offering a unique solution in the Substrate/Polkadot/Kusama landscape. + +πŸ”Ή **Target Audience:** Developers interested in building omnichain smart contracts on Substrate, Polkadot, and Kusama, particularly those looking to develop cross-chain applications and interact with multiple blockchain networks. + +πŸ”Ή **Project's Purpose:** The infrastructure will enable developers to build more efficient and scalable omnichain smart contracts, making it easier to create cross-chain applications that interact with multiple blockchain networks. This will help solve the problem of siloed blockchains and allow developers to take advantage of the benefits of multiple chains. + +πŸ”Ή **Similar Projects:** We are not aware of any other projects similar to OmniChain in the Substrate/Polkadot/Kusama ecosystem, offering a unique solution for building omnichain smart contracts. + +## Team 🦾 + +### Team members + +- πŸ‘¨β€πŸ’» Alex Shkor - Architect, Developer, Team Lead +- πŸ‘¨β€πŸ’» Alexey Kulik - Architect, Developer +- πŸ‘©β€πŸ’Ό Julia Shinkevich - Project Manager +- πŸ§‘β€πŸ’Ό Max Slyzkoukh - Product Manager +- πŸ‘¨β€πŸ”§ Yahor Tsaryk - Engineer + + +### Contact + +- **Contact Name:** Alex Shkor +- **Contact Email:** alex@cilabs.ai +- **Website:** https://collectiveintelligence.dev/ + +### Legal Structure + +- **Registered Address:** 16192 Coastal Highway, Lewes, DE 19958, United States. +- **Registered Legal Entity:** Collective Intelligence Labs Inc. + +### Team's experience + +Our team's extensive experience in blockchain development and past successful projects make us well-suited for this project. We have developed several blockchain-based platforms, including DeSci, which offers a decentralized scientific communication infrastructure, and IPledger, which registers intellectual property assets on the blockchain. We have also built a Proof of Share protocol for verification on a chain that specific files have been shared between parties, an on-chain grants distribution platform, a decentralized technology transfer platform, [F-NFT](https://github.com/DEIPworld/deip-node/tree/develop/pallets/deip_f_nft) and [Event Proxy](https://github.com/DEIPworld/deip-node/tree/develop/event-proxy) for Substrate, and other projects. + +Our team members have also contributed to open-source blockchain projects, demonstrating our commitment to the development of the blockchain ecosystem as a whole. + +Our Team Lead is distributed systems architect and has over 14 years of experience in this field, with one of our team members being the inventor of omnichain smart-contracts protocol, which is an important aspect of this project. Our Software Engineer has over 10 years of experience in distributed systems engineering and was the ex-CTO at DEIP and the creator of the Economy Protocol. Our Tech Lead has experience in distributed system and blockchain R&D and was the ex-Head of R&D at Paralect, while also having experience as an ex-CPO at DEIP. Our Head of Marketing has 9 years of experience in PR and communications, having worked with micromobility and web3 startups. Our Product Manager expert in digital transformation has 6 years of experience in the procurement of 50+ leading private and state Ukrainian enterprises. + +As a team, we have previously applied for a grant from the web3 foundation grants program for our DEIP project (DEIPWORLC Inc. legal entity). However, due to the constantly evolving market landscape and changing needs of the industry, we decided to pivot multiple times, and therefore did not deliver original proposal fully (only about 50% of it - onchain part). During the process we realized that on-chain IP management would not be possible without other infrastructure part. Therefore we decided to completely stop [previous project](https://github.com/DEIPworld), change our focus and start working on a diferent solution, the core solution that will make possible to implement DEIP and other our projects that rely on omni-chain infrastructure and onchain IP management - omni-chain infrastructure + +We believe that being transparent about our previous application and pivot is important. We want to assure the committee that we are committed to delivering the proposed solution for our current application, and that we are passionate about creating value in the blockchain ecosystem. + +We are confident that our team's expertise and experience in developing distributed systems and infrastructure will enable us to successfully execute our proposed CILA omnichain infrastructure project. We believe that this infrastructure is crucial for the growth and adoption of blockchain technology, and we are excited about the opportunity to contribute to this space. + +### Team Code Repos + +- https://github.com/Collective-Intelligence-Labs + +### Team GitHub Profiles + + +- https://github.com/alexshkor +- https://github.com/aliakseikulik +- https://github.com/yahortsaryk +- https://github.com/juliacil + +### Team LinkedIn Profiles + +- https://www.linkedin.com/in/alexshkor/ +- https://www.linkedin.com/in/alexeykulik/ +- https://www.linkedin.com/in/julia-shinkevich/ +- https://www.linkedin.com/in/max-slyzkouh/ +- https://www.linkedin.com/in/yahor-tsaryk-92032a68/ + + +## Development Status :open_book: + +CILA omnichain infrastructure for Substrate is currently in the research and planning phase. We have conducted extensive research on the existing smart contract infrastructure and identified the need for an omnichain smart contract solution. Our team has also analyzed the capabilities of the Substrate/Polkadot/Kusama ecosystem and determined that it is the ideal platform for building this solution. + +We have created a detailed project plan that outlines the development roadmap and milestones. This plan includes research and development of the necessary components. + +- Draft of solidity implementation: https://github.com/Collective-Intelligence-Labs/cila-sol-contracts +- Vision Paper: https://docsend.com/view/eqt2iazwmff3jikh + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 3 months +- **Full-Time Equivalent (FTE):** 2 FTE +- **Total Costs:** 30,000 USD + +### Milestone 1 β€” Design and Implementation + +- **Estimated duration:** 1 month +- **FTE:** 2 +- **Costs:** 10,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | + **0b.** | Documentation | We will ensure comprehensive documentation of the code by providing both inline comments and a step-by-step tutorial. This tutorial will guide the user through spinning up a Substrate-based execution environment for the CILA Omnichain Infrastructure and testing omnichain transactions, showcasing the new functionality. | +| **0c.** | Testing and Testing Guide | We will conduct comprehensive unit testing on the core functionalities including Aggregate, Event Store, Aggregate Repository, Snapshot Store, and Dispatcher, to ensure optimum functionality and robustness. The testing guide will contain instructions on how to execute these tests. | +| **0d.** | Docker | We will deliver Dockerfiles for testing all the functionality included in this milestone. | +| 1. | Substrate module: Aggregate | The Aggregate pallet provides the base functionality for implementing the Command Query Responsibility Segregation (CQRS) pattern on a Substrate-based blockchain. It defines the Aggregate trait, which is used to define the state and behavior of an Aggregate. | +| 2. | Substrate module: AggregateState | The AggregateState pallet provides a default implementation of the AggregateState trait, which stores the current state of an Aggregate in the blockchain's storage. This pallet is responsible for managing the state of an Aggregate and updating it based on incoming commands. | +| 3. | Substrate module: AggregateRepository | The AggregateRepository pallet provides an implementation of the AggregateRepository trait, which is responsible for retrieving and storing Aggregates in the blockchain's storage. It allows developers to easily store and retrieve Aggregates from the blockchain's storage. | +| 4. | Substrate module: CommandDispatcher | The CommandDispatcher pallet provides a way to dispatch incoming commands to the appropriate Aggregates based on their type. It uses a HashMap to store the mapping between command types and the Aggregates that handle them. | +| 5. | Substrate module: EventStore | The EventStore pallet provides a way to store and retrieve events that have been emitted by Aggregates. It allows developers to easily retrieve the events emitted by a specific Aggregate and replay them to reconstruct the current state of the Aggregate. | +| 6. | Substrate module: EventsEmitter | The EventsEmitter pallet provides a way for Aggregates to emit events. It defines a trait that Aggregates can implement to specify the types of events they emit, and provides a way to subscribe to events emitted by specific Aggregates. | + + +### Milestone 2 β€” Testing and Documentation + +- **Estimated duration:** 1 month +- **FTE:** 2 +- **Costs:** 10,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will ensure comprehensive documentation of the code by providing both inline comments and a step-by-step tutorial. This tutorial will guide the user through spinning up a Substrate-based execution environment for the CILA Omnichain Infrastructure and testing omnichain transactions, showcasing the new functionality. Special attention will be given to documenting the setup and testing of multiple Substrate chains running simultaneously, to test the synchronization of the state smart contract between them. | +| **0c.** | Testing and Testing Guide | We will conduct comprehensive unit testing on the core functionalities including Aggregate, Event Store, Aggregate Repository, Snapshot Store, and Dispatcher, to ensure optimum functionality and robustness. In particular, we will place emphasis on testing the infrastructure running with multiple chains to ensure that the synchronization mechanism is functioning as intended. The testing guide will contain instructions on how to execute these tests. | +| **0d.** | Docker | We will deliver Dockerfiles for testing all the functionality included in this milestone, including orchestration with multiple chains. For orchestration purposes we might use Kubernates. | +| 0e. | Article | We will publish a technical article that details the implementation of the Command-Query Responsibility Segregation (CQRS) and Event Sourcing architecture on the Substrate framework. The article will provide an in-depth explanation of the design choices made and the challenges faced during the implementation. It will also include a detailed walkthrough of the codebase, highlighting key areas of interest and how they fit into the overall architecture. The article will be written in a technical language that targets developers with experience in blockchain and distributed systems. | +| 1. | Substrate chain | Set up and run multiple Substrate chains simultaneously to test the synchronization of a state smart contract between them. This will involve deploying the omnichain smart contract infrastructure to each chain and executing transactions on each chain to ensure that the contract state is properly synchronized between them. Additionally, various network conditions such as network latency and node failures will be simulated to test the robustness and reliability of the synchronization mechanism. The results of these tests will be recorded and analyzed to identify any potential issues and ensure that the synchronization mechanism is functioning as intended. | +| 2. | Automated Tests | We will create and publish automated tests for critical infrastructure parts of Substrate-based CQRS + Event Sourcing execution enviroment. The aim of this test will be to test two cases - non conflicting execution (changes coming to one chain and transmitted to the other one), and conflicting transactions when the same aggregate is updated with two conflicing state changes that simuntaniusly come to different chans. | + +### Milestone 3 β€” Example Smart Contracts and Enhancements + +- **Estimated duration:** 1 month +- **FTE:** 2 +- **Costs:** 10,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | Provide inline documentation of the NFTAggregate pallet and NFTAggregateState pallet code, as well as a basic tutorial that explains how a user can set up a Substrate node and send test transactions to test the NFT functionalities provided by these modules. Additionally, comprehensive unit tests will be developed and documented to ensure the functionality and robustness of the NFTAggregate pallet and NFTAggregateState pallet. A testing guide will also be provided, describing how to run the tests. | +| **0c.** | Testing and Testing Guide |For this milestone, we will develop comprehensive unit tests to cover the core functions of the NFTAggregate module and the NFTAggregateState pallet. These tests will be designed to ensure the functionality and robustness of the code. The unit tests will be included in the code repository and will cover a range of scenarios to ensure that the code is thoroughly tested. For example, we will test the minting, burning, and transferring of NFTs, as well as error handling and edge cases. In the testing guide, we will provide detailed instructions on how to run these tests, including any required dependencies and setup steps. We will also include information on how to interpret the test results and what to do in the case of failures or errors.. | +| **0d.** | Docker | In order to facilitate testing and deployment of the NFTAggregate pallet and NFTAggregateState pallet, we will provide Dockerfiles that can be used to easily set up and configure a development environment. These Dockerfiles will include all the necessary dependencies and configuration to run the Substrate-based blockchain with the new functionalities. | +| 1. | Substrate module: NFTAggregate | The NFTAggregate pallet provides a way to implement Non-Fungible Tokens (NFTs) on a Substrate-based blockchain. It defines a trait that NFT Aggregates can implement to specify the behavior of NFTs, including minting, burning, and transferring. | +| 2. | Substrate module: NFTAggregateState | The NFTAggregateState pallet provides a default implementation of the state of an NFT Aggregate, which stores the current state of NFTs in the blockchain's storage. This pallet is responsible for managing the state of NFTs and updating it based on incoming commands. | +| 3. | Report: Substrate Ecosystem NFT standards | To choose the most optimal standard for omnichain implementation we will conduct research and assess all the available NFT standards against two major criteria: popularity and technical quality. Popularity will be measured by the number of stars on the GitHub repository and how many projects are actually using it (usage assesment will be done on a best effort basis), and the technical quality will be assessed by analyzing if a specific standard satisfies [SOLID](https://en.wikipedia.org/wiki/SOLID) design principles. | + + +## Future Plans + +In the short term, we plan to continue to develop and enhance our project to ensure its success and sustainability. This will include ongoing testing, bug fixes, and implementing additional features and improvements as needed. We will actively promote our project through various channels, including social media, blog posts, and community events. + +After the completion of the proposed infrastructure, we intend to continue its development by incorporating support for multiple blockchains and introducing more advanced functionalities, such as dynamic rebalancing for aggregates. Additionally, we plan to establish partnerships with leading players in the Substrate/Polkadot/Kusama ecosystem and to integrate our omnichain infrastructure with existing projects, such as DeFi and NFT marketplaces, to further increase adoption. Finally, we will provide comprehensive documentation and support to ensure that our infrastructure is accessible and user-friendly for developers and users alike. + +In the long term, we envision our project becoming a leading platform for event-centric CQRS + Event Sourcing execution environments and omnichain smart contracts on the Substrate blockchain. We plan to expand our team and further invest in research and development to stay ahead of the curve and meet the needs of the rapidly evolving blockchain industry. We will continue to engage with the community and seek feedback to ensure that our project remains relevant and valuable to users. Our ultimate goal is to create a platform that is widely adopted and helps to drive the mainstream adoption of blockchain technology. + +## Additional Information :heavy_plus_sign: + +![mission](https://i.imgur.com/WZt1hdx.png) + +**How did you hear about the Grants Program?** personal recommendation