Ethereum, EOS, STEEM, ONT, NEO, NAS, Cardano, Tezos, POA, Dfinity, ThunderCore, Solana, RChain, Oasis Labs, Zilliqa, VeChain… there are enough Layer-1 blockchain projects released, or nearing release, that it’s hard for even a dedicated developer in the space to keep track of them all. Even individual platforms are planning sub-chains, like Ethereum’s sharding and plasma projects. There are chains on top of chains. How should you make sense of a world with so many chains?
Many Chains, or One Chain?
One question we often get is whether we believe there will be a single stablecoin that rules them all… we think the answer here should be no. We subscribe to Hayek’s theory that there should be many competing currencies and the best ones will get continued and lasting use. Competition between currencies will be driven by better stability, philosophy, economic scalability, or incentive alignment with network growth, and that competition between monies is itself a form of decentralization worth fighting for.
Just as different digital currencies have different behavioral characteristics, different layer-1 chains also have different platform characteristics. Ethereum explicitly trades transaction throughput for increased decentralization. EOS explicitly trades decentralization for increased transaction throughput. Each of these will be home to different kinds of applications that care about different tradeoffs.
DApp vs Money
If you’re a decentralized application, like Augur for example, it makes sense to choose one chain and deploy there. All your data is in one place and your users only need to manage one wallet to interact with it.
If you’re building a new money that aims to eventually become a medium of exchange, you want to be everywhere anyone is making a transaction. ALSO, if you’re aiming to be a real money, you need a way of regulating supply with market demand.
This seems to lead to a conflict between the needs of two different parts of a monetary system. A monetary policy looks a lot like a DApp and wants to be on a single platform, while a token contract looks a lot like a money and wants to be on every platform.
As a refresher, here is the single chain Ampleforth architecture as described in the whitepaper:
We’d like the Ampleforth Monetary Policy, Oracles, and Governance modules to exist on the chain with the highest level of decentralization.
Fortunately in the case of Ampleforth, the set of users who interact with the Monetary Policy is much smaller than the set of users who interact with the token. There is currently one publicly callable function, rebase, that users can call that will initiate a monetary policy action and this executes at most once every 24hrs. Similarly, our Oracle data sources receive data about 4 times per day. For these modules we’re not that concerned with transaction throughput, so we’ll gladly sacrifice speed for decentralization. As of today, Ethereum meets these needs very nicely. It has a high level of decentralization, enough usage to guard against 51% attacks, and has an amazing and supportive community of developers around it.
The ERC-20 (or perhaps in the future, the zkERC-20) contract will be deployed on every platform capable of supporting the arithmetic necessary to power the token transfer and supply operations, which is mostly simple arithmetic.
Now instead of one “Ampleforth ERC-20” box, there will be one on every platform on which we’ve launched. In order for this to work, we need a few things:
- A user must be able to transfer Amples from their wallet on one chain to another wallet on a different chain — Value-transfer.
- The monetary policy must be able to call rebase() on the token contract of a different chain, or otherwise sync its state to the other chain — State Transfer.
Thanks to Evan Kuo.
This Article was originally posted on Ampleforth's Medium Blog.