The Cosmos SDK Parachain Development Kit will enable developers to host their existing Cosmos chain or Zone on Polkadot, secured by the Polkadot Relay Chain and benefiting from Polkadot’s interoperability stack. Developers will also be able to use the Cosmos SDK to build new parachains for use on Polkadot. With the Cosmos SDK Parachain Development Kit, Cosmos Zones will no longer have to provision their own validator set and economic security, allowing them to focus on building out their core technologies and products rather than maintaining their staking infrastructure. We have already finished Phase 1 of development, and have successfully delivered the first milestone for the Web3 Foundation grant concerning Phase 2.
Building a Polkadot Parachain with the Cosmos SDK
The Cosmos ecosystem has a significant number of developers building applications using the Cosmos SDK. However, since the Cosmos ecosystem does not provide a system for shared security, these developers are currently forced to bootstrap their own security networks.
Polkadot’s architecture, on the other hand, provides a method to share security between the parachains and the Polkadot Relay Chain, with the latter ensuring system-wide coherence. In turn, developers can focus more on the business logic of their own apps. This sharing of security has some democratizing effect as well, as developers do not need to be blockchain security experts to create blockchain-secure applications.
Our project aims to allow developers in the Cosmos ecosystem to tap into the security and resource benefits of Polkadot, so more developers can more easily create applications with blockchain-level security.
Connecting the Polkadot and Cosmos architectures
Each separate blockchain in the Cosmos architecture is termed a Zone and is connected to a central chain (hub), which facilitates interaction between the Zones. The Zones are independent of one another, and each Zone is responsible for its own governance, security, and economics. Cosmos native consensus is Tendermint, which is based on the Delegated Proof of Stake (DPoS) approach.
Cosmos nodes use Tendermint Core for the consensus and network layers, while the application layer uses its namesake Cosmos. The Cosmos application and the Tendermint-powered consensus and network layers are decoupled for greater flexibility. They communicate through the application blockchain interface (ABCI), which serves as a decoupling mechanism.
On the other hand, Polkadot uses the Substrate framework for all of its layers, from application down to the network. In our project, we focus on Polkadot’s consensus and network layers. In order to build Cosmos-SDK-based apps for the Polkadot consensus mechanism, we will replace Tendermint core with Substrate network communication and consensuses (AURA/BABE and GRANDPA for separate chains and Cumulus for parachains). The replacement involves mirroring Cosmos’ ABCI and remote procedure calls (RPCs) with Substrate-compatible ones. A final aim of the project is to connect Cosmos apps to the Polkadot Relay Chain.
Background and overview of approach
A detailed treatment of our approach can be found on our grant github.
Substrate extrinsics are used as wrappers for Cosmos transactions. For block processing, Substrate sends the new block or transaction data to the Cosmos node, which updates its own state and responds to the Substrate node. Substrate then updates its own state. All interaction between the nodes passes through gRPC.
For pure Cosmos applications, users can interact with a Cosmos node via CLI. As mentioned above, the CLI connects not to the Cosmos node itself but to the Tendermint Core, which relays the messages to the intended node using ABCI. For this interaction, Tendermint uses an RPC server, similar to Polkadot. This similarity allows us to shift out of the Cosmos-only architecture and incorporate Polkadot. As illustrated in the schema below, users send commands through the Cosmos CLI, which talks to the Substrate RPC server. The RPC server translates for the ABCI Substrate pallet, and the latter interacts with the Cosmos runtime and the Substrate runtime. This preserves the characteristic Cosmos separation between the Cosmos runtime and the CLI, so users can still use the same CLI for various applications.
Phase I completed – basic PoC (ABCI methods and Cosmos updated)
We have successfully completed our first phase, which aimed to get a Cosmos app to interact with Substrate. To do so, we advanced development via two milestones.
Milestone 1 was to add basic ABCI methods to Substrate so Cosmos ABCI methods could be mirrored (see exact calls in the project details). Once the Substrate RPC is ready (development in Phase II), it will translate Cosmos CLI requests into these new ABCI methods. This replaces the Tendermint RPC with a Substrate-based one. For this milestone, we sped up development by using a simple token app that implemented ABCI like Cosmos rather than a full-fledged Cosmos app.
For Milestone 2, we updated the basic ABCI methods developed in Milestone 1, standardized data formats, and updated the Cosmos version for the application in the tutorials (Nameservice). We successfully launched the updated Namservice app on top of Substrate. Running a real Cosmos application (instead of just the demo token app) verifies our approach works in the real world.
At this point, in order to run a Cosmos application on Substrate (instead of Tendermint Core), the user needs only set a few flags at startup.
Phase II – Next steps for ABCI, RPC, nodes, and validators
In Phase II, grant milestone 1, we finished all of the Substrate ABCI methods (except Snapshots, which will come later). The remaining ABCI methods can be found here. Milestone 1 also added some Substrate RPC methods, building the first point of interaction between the Cosmos CLI and the Substrate component.
Milestone 2 is concerned with consensus and interfacing Substrate validators with the Cosmos election process, as token logic is set by Cosmos. To interface these, we must match the Cosmos-based addresses of validators with the Substrate-based addresses. This part of the project neatly folds Cosmos validator election into the Substrate consensus layer.
Milestone 2 also includes synchronizing Cosmos and Substrate nodes. Currently, users must manually reflect changes in one node on the other, which increases workload and the prevalence of errors. Automating synchronization reduces workload and ensures changes in either node are properly reflected in the other.
Benefitting Developers, Users, and Polkadot
Our project benefits the Polkadot ecosystem by attracting Cosmos developers, who are accustomed to building with the Cosmos SDK. Anyone who can build a Cosmos app will be able to build for Polkadot, shifting the security burden to the Polkadot Relay Chain instead of relying on the Cosmos app’s own consensus and security processes.
More developers and more applications mean more choice for users. This expansion of choice implies the best applications will prevail, improving the quality of Polkadot-connected applications. More apps benefits users, too, who will be able to find the perfect fit for their own needs rather than needing to build custom solutions. With more choice and higher quality, Polkadot will benefit from greater adoption rates and the associated advantages.
Links