Spike: investigate Cosmos SDK

[mudler]

Problem

We need to have a production ready blockchain that can be used for the following:

1. Have MASA as native asset for paying for transactions
2. Enable staking by Validators to secure the network
3. Enable delegation of stake by Miners to Validators
4. Enable the deployment of other tokens on our network
5. Enables the storage of a shared state - for example nodeData
6. Enables a trusted party (a Validator) to attest and allow non-validators to join the network
7. May simplify our architecture

We have cards that already capture part of the issues that we want to tackle:

https://github.com/masa-finance/masa-oracle/issues/590 https://github.com/masa-finance/masa-oracle/issues/507 https://github.com/masa-finance/masa-oracle/issues/518 https://github.com/masa-finance/masa-oracle/issues/496 https://github.com/masa-finance/masa-oracle/issues/382 https://github.com/masa-finance/masa-oracle/issues/381

Description

This card is about investigating if we can use the Cosmos SDK to implement Blockchain, CAS and consensus being the nodes and allow to have token with proof of work.

Acceptance criteria

The objective of this card is to make sure that Cosmos SDK can cover the features described in the cards listed above and to which extent. We want to know if its a viable solution to tackle most of the issues instead of backing our own solution on top of libp2p.

• [ ] We want to know how much overlap there is infeature between Cosmos SDK and libp2p
• [ ] How many features we miss from libp2p, and if it is a better replacement to it
• [ ] Create new follow-up cards as needed
• [ ] Close relevant card related to libp2p in place of equivalent with Cosmos SDK
• [ ] Before closing the card, have a brainstorming session with the team to show off the difference between Comsos SDK and libp2p and if they can co-operate together
• [ ] We need also to know if libp2p and Cosmos SDK can be used in the same node or we can replace functionalities by building on top of Cosmos SDK and deprecate libp2p

[restevens402]

Spike Outcome: Cosmos SDK with Oracle Node Integration

After conducting a spike to evaluate Cosmos SDK for our Oracle Node, we’ve confirmed that Cosmos SDK offers a robust framework for implementing a production-ready blockchain that aligns with our key requirements. We successfully set up a Cosmos-based chain and created a custom module that enables on-chain data storage using Cosmos’ consensus model, demonstrating its suitability for our needs.

1. Native Asset (MASA) for Transaction Fees

• Supported: Cosmos SDK allows the definition of custom native assets. You can create MASA as the primary token on the blockchain, which can be used to pay transaction fees. By leveraging the SDK's x/bank and x/auth modules, you can define MASA's functionality, including fee payment and token management.

2. Staking for Network Security (Validators)

• Supported: Cosmos SDK provides an x/staking module for staking, designed to enable Proof-of-Stake (PoS) mechanisms. Validators can bond (stake) tokens like MASA, participate in block validation, and receive rewards. This module is highly configurable, allowing you to set staking parameters that fit your network's requirements for security.

3. Delegation of Stake by Miners to Validators

• Supported: The Cosmos SDK’s staking module also supports delegation, allowing token holders (e.g., Miners) to delegate their tokens to Validators. This feature allows them to earn a share of the staking rewards without directly validating blocks. Delegators maintain their tokens but entrust Validators to perform the network's consensus duties, securing the network by increasing the Validator's stake weight.

4. Deployment of Additional Tokens on the Network

• Supported: Cosmos SDK’s modular design allows for the creation and management of multiple tokens. You can define additional tokens alongside MASA using the x/bank module and custom modules if specific token behaviors are needed. Additionally, Cosmos SDK supports multi-asset environments and enables flexibility in handling token issuance, transfer, and management.

5. Shared State Storage (e.g., nodeData)

• Supported: Cosmos SDK supports on-chain storage of shared data through custom modules. We prototyped a custom module with gRPC services to get and set nodeData, enabling straightforward access and manipulation of this shared state across nodes. This setup leverages Cosmos SDK’s state management, ensuring that nodeData is stored consistently and available network-wide through gRPC calls, with consensus and data integrity maintained through Cosmos' underlying Merkle proofs and Tendermint consensus.

6. Validator Attestation for Network Entry (Trusted Party Authorization)

• Supported with Customization: Cosmos SDK can support a Validator attestation system, although it may require a custom module. Validators can be configured to perform specific roles beyond block validation, such as approving new nodes. Custom logic can be added to enforce policies where certain Validators attest to the legitimacy of new nodes joining the network, effectively enabling a trusted entry mechanism.

7. Simplified Architecture Compared to libp2p (Hybrid Approach)

• Supported: I am proposing a hybrid approach where Cosmos SDK handles consensus, storage, and coin management, while libp2p remains responsible for the operational work of the distributed network. This setup leverages Cosmos SDK’s strengths in blockchain-specific functions, simplifying the architecture by consolidating blockchain essentials within Cosmos while keeping libp2p optimized for custom peer-to-peer operations. This approach balances Cosmos SDK’s robust state management and consensus capabilities with libp2p’s flexibility for distributed task handling, providing an efficient framework that meets both blockchain and operational requirements.

Next Steps:

• Proceed with follow-up tickets to formalize implementation details, including defining MASA as the native asset, configuring staking/delegation, and further developing shared state mechanisms.
• Continue with a team brainstorming session to finalize the architecture and determine any remaining overlap or gaps between Cosmos SDK and libp2p.

[mudler]

Closing with the https://github.com/masa-finance/masa-oracle/issues/619 as follow-up.

Outcome: We know that Cosmos SDK is having all the features we need for having our own blockchain and token, but we want to make sure before jumping into it, to not loose all the benefits of using a libp2p-based transport layer, and go back at a "web2" style of network.