Appchains are sovereign independent, efficient blockchains. Compared with monolithic blockchains, appchains are more dedicated, stable, and performant. Most importantly, they bring control back to the application’s own community and ensure reasonable gas fees for its developers and users. As a result, developers of appchains can focus more on improving application performance.
A future of multichain/many-appchain world is likely to be more versatile, providing more choice for users, developers, and consequently, more freedom.
The recent growth in the market share of appchains demonstrates the crypto community’s desire for these properties.
As the number of appchains grows, every bit of improvement in an appchain’s infrastructure will be multiplied by the number of active appchains using that infrastructure, resulting in significant net benefits.
Compared to smart contract exploits, appchain-level exploits have been rare recently. However, considering that appchains often have a smaller validator set compared to Nakamoto-consensus blockchains, it is worth exploring ways to enhance appchain security and trustlessness beyond just adding more nodes.
So, what can we actually do to improve appchain security and trustlessness?
1
First, we can continue to diversify appchain consensus protocols and appchain SDKs. Currently, the CosmosSDK is arguably the most important SDK for appchain developers. Although it’s not the only one, it has been the most stress-tested, and currently hosting the largest volume of assets across many types of applications, including decentralized exchanges, AI, depin, and general-purpose blockchains.
The CometBFT protocol is light-weight, deterministic, and partially asynchronous protocol. It is also the default consensus protocol of CosmosSDK. Most Cosmos appchains can use CometBFT as a consensus layer and be sufficient. However, diversification of consensus protocols is going to be a great strength for the future appchain world. When more appchains emerge, they can choose, or design consensus protocols that best suit them. There exists light-weight ABCI implementations that decouples consensus layers. For example, recent experiments from Dora Factory tests Honey Badger BFT based asynchronous consensus protocols on the Cosmos stack.
2
Some appchains might need to expand their validator set beyond the practical limit of normal BFT protocols. There are some benefits of doing so, such as involving more community members in network validation and further decentralizing the network. Although the current appchain tech stacks generally allow an appchain to switch to a Nakamoto consensus, the cost might be overwhelming, defeating the purpose of building an appchain in the first place. In order to get the benefits from Nakamoto consensus without bearing the full cost of it, an appchain can adopt a hybrid consensus.
A hybrid consensus protocol consists of a fast chain and a slow chain. The fast chain can be a BFT-type blockchain with a smaller set of highly performant validators to propose blocks, and validate transactions—similar to the validator set of an appchain built with the CosmosSDK.
The slow chain can be a Nakamoto chain, which allows permissionless participation. It ensures validity of the fastchain’s transactions. The Nakamoto chain does not have to sync the entire blockchain; rather the blockdata is mainly digests of the fastchain transactions during a slowchain block.
When necessary, the fast chain can introduce a rotating committee. In this case, the slow chain selects the committee.
The selection of consensus algorithms for the fast and slow chains is relatively flexible. For instance, a BFT-PoW blockchain adopting fruitchain can be friendly to small miners.
Adding layers to consensus protocols can create a balance between cost and efficiency of a blockchain.
However, it is worth noting that the hybrid consensus / rotating committee approach not only adds complexity to protocol design and implementation, but is also limited by the dilemma that efficiency, security, and number of validators cannot be improved indefinitely.
3
Imagine a highly secure validator technology that can break the current dilemma between number of nodes and efficiency, achieving comparable security and efficiency with much less number of nodes.
Such technology might exist—in outer space. A satellite in orbit can act as a “node” for blockchain networks on earth. Computation in outer space (e.g., on a satellite) is isolated, making it an ideal Trusted Computation Environment (SpaceTEE).
Some organizations have already explored SpaceTEE via crypto satellites for specific use cases, including space IPFS node, DoraHacks’ ISS experiment, and Ethereum’s later KZG ceremony.
Satellites can be used to create blockchain validators. A recent research added a non-traitorous assumption and used it to design a performant blockchain network in space.
Implementing a non-traitorous satellite is feasible with read-only memories and software attestation technology.
Similarly, we can design and build satellites to validate appchains on earth. A simple system to start with is an appchain attestation service. A satellite constellation deployed in Earth’s orbit could receive and store block state attestations from appchains on Earth. An appchain can periodically submit attestations to validate its state.
A satellite constellation can provide attestation service to many appchains, which is scalable. Depending on the asset value hosted by the attested appchains, the attestation service provider can decide how many satellites to add to the constellation, as well as their capabilities.
It is possible to start with a small constellation, providing basic attestation service to a range of appchains. As the appchain ecosystem grows, more satellites can be added to the constellation, and less capable satellites can be replaced with more capable satellites over time.
Some possible upgrades of satellites:
-
Satellite-to-satellite communication for synchronization and data replication without relying on ground stations.
-
Greater storage capacity for longer lifetimes and more complex attestations.
-
Enhanced computational capabilities for not just attestation but also block validation in space.
Conclusion
The future of appchains is likely to be more open and versatile. The strength of the appchain ecosystem lies in the freedom of choice it offers to application developers and users—the choice of technology, communities to join, and values to align with.
Enhancing the security of individual appchains brings significant positive externalities. Improvements in the security of one appchain can be applied to many others. As the number of appchains increases, the cumulative benefit becomes substantial.
There are multiple ways to further secure appchains, and this article proposes three. The practical choice depends on an appchain’s goals and its evaluation of trade-offs. The design space, though, is not limited. Building robust technical and economic infrastructures is crucial for further securing and scaling appchains. Sovereign blockchains will eat the crypto world.