CodeChain Foundry

CodeChain Foundry is a blockchain engine based on a composable module system. Users can write their own modules in addition to bringing in those written by others in order to construct an arbitrary blockchain application. Foundry is under active development and going to release its first working version soon. In this article we briefly introduce the core idea of the project.

Consensus

As Foundry started from CodeChain, we took advantage of such verified implementation of blockchain. Both CodeChain and Foundry use Tendermint, a Byzantine fault tolerant PoS consensus. The CodeChain team has successfully developed its own Rust implementation of Tendermint, and thoroughly tested it over a couple of years. It is working well with the mainnet of CodeChain even as we speak. Foundry is incorporating such well implemented and verified works, including other essential components such as P2P networking and DB.

Module System

Upon execution of a transaction that is essentially a state transition, the module system will be told to execute the transaction from the underlying consensus engine. Transactions will be delivered to the responsible modules, and those modules will handle the execution of the transactions, which might also involve communications with other modules.

Foundry provides a powerful and general module system that supports:

• Multiple runtimes for multiple kinds of modules: each module can be written in various languages requiring different runtime environments. Thus, languages compiled to executables or WASM modules can be supported, as well as those requiring an interpreter or virtual machine like Python and JavaScript.
• General communication system based on services: details are explained in this article.
• Configurability by the app-descriptor: Users can compose an application from various modules, specifying how to exchange services between each module and the consensus engine. It is human readable, declarative, and easily auditable.
• Reusability by well-defined and targeted interfaces between each module and the consensus engine: this makes modules independent, decoupled, and clear in one’s responsibilities. Each module can be easily adapted and reused.
• Security by sandbox and services. Modules will be sandboxed and can affect the outside world only via services explicitly specified by the app-descriptor. Each module exposes its interface exactly as the user allowed in the app-descriptor.

Module

Modules are independent components that make up an application. They cooperate to function as a blockchain application along with the consensus engine. Each module has its own state, and may define its own transactions. Imagine a really simple cryptocurrency application. Typical implementations would consist of the following modules:

• Account module: manages sequences and balances for accounts. It defines a payment transaction to transfer tokens. It will, at the very least, provide an interface for other modules to access accounts’ sequences, because other modules’ transactions will likely depend on sequences anyway.
• Staking module: provides the validator set of Tendermint to the consensus engine. It might query balances of accounts to determine the stake of each.
• Sorting module: Sorts transactions in the mempool by priority and excludes those made invalid by recent transactions. The sorting module is consulted when proposing a block to pick transactions for inclusion. It is also consulted when evicting invalid or lower priority transactions when the mempool is full.

IBC and Lightclient

Besides the module system, Foundry has some useful built-in modules: the IBC modules. IBC stands for Inter-Blockchain Communication, and the IBC modules function as a connection end of verifiable chain-to-chain communication. You can communicate with other blockchains built with Foundry, and with completely different chains too as long as they meet the IBC requirements. See this article to learn more about what IBC is and how we implemented it.

Light client is a special algorithm to cryptographically verify the state or transactions in blockchain without using the whole state. It is key in constructing a truly decentralized (where you do not need to trust anybody) and practically utilizable network made possible by light-weight nodes. We have implemented and tested the light client of Foundry while implementing IBC (see this article to know how IBC and a light client are related). Foundry will eventually have a stand-alone light client for its users that can be used for all chains built with Foundry.

Future

One of Foundry’s ultimate goals is to have an active and rich ecosystem of diverse modules. Since we have already established a general module system and its communication protocol, we can add more types of module runtimes continuously. Users will be able to easily write their own business logic in whatever language they want, especially simple scripting languages. Users can easily compose such custom modules with other common popular modules to construct their own applications.