What kind of scaling network does DeFi need? Inference from Radix and StarkWare technologies
This article was published on the White Plan, author: Li.
DeFi has become an indispensable part of the cryptocurrency world.
Throughout 2020, the scale of DeFi experienced unprecedented growth. According to DefiMarketCap statistics, the market capitalization of the Top 100 DeFi tokens has approached 100 billion, and it can be seen that the total value locked in DeFi has also exceeded 50 billion dollars.
The above image shows the changes in DeFi locked assets as displayed by DeBank.
This enormous figure is based on Ethereum, which now bears the liquid value of other on-chain assets such as BTC, ETH, and DAI. However, according to Ethereum's operational logic, behind this massive number lies significant resource consumption.
By examining Ethereum's gas consumption, it can be seen that with ETH prices continuously rising and DeFi applications increasing, Ethereum's daily miner revenue peak has already exceeded 27 million dollars. Besides the regular block rewards, a large portion of this revenue comes from DeFi users invoking smart contracts.
Excessively high gas fees not only increase the barrier for users to utilize cryptocurrencies but, from a higher dimension, hinder the original intention of cryptocurrency: inclusive finance.
Therefore, cryptocurrencies need to address the cost issues in transactions to achieve lower-cost DeFi transactions. Currently, many public chain projects have clear development roadmaps, and Ethereum has the most DeFi, so its expansion solutions are the most representative, with three proposals: transitioning to PoS, sharding, and Layer 2.
Representative projects for Layer 2 expansion technologies include StarkWare, Matic, Celer, etc., while representative networks for sharding expansion include Radix, Near, etc. Both forms have their technical strengths and varying benefits for the DeFi track. In this article, we will infer what kind of cryptocurrency network DeFi needs based on these two expansion designs.
Layer 2 is currently the easiest expansion solution to implement
Ethereum and other public chains are attempting to expand using a multi-chain structure, such as the homomorphic sharding that Ethereum 2.0 may achieve, the heterogeneous sharding being implemented by Polkadot, and the cross-chain structure of COSMOS. New networks like Avalanche have further refined the definition of functional layering and modularization for expansion within a multi-chain structure.
These are large and long-term designs. For example, Polkadot will still need to undergo slot auctions in the future, and COSMOS needs to build a better ecosystem, while the technological progress and ecological construction of other chains are still in the early stages.
For other projects more focused on expansion, they will concentrate on a single network structure, such as implementing sharding in Layer 1, with representative projects being Radix and Near. In the long run, Layer 1 expansion (such as sharding) is inevitable. Once these networks are EVM compatible, DeFi can quickly migrate to them. If the asset transfer issue is resolved, these networks will become expansion networks for Ethereum.
However, for the booming demand for DeFi in a bull market, the implementation of Layer 2 expansion is very necessary.
Taking Ethereum as an example, the performance of Ethereum's PoW chain is far inferior to that of the Beacon chain. If Ethereum can successfully transition to PoS, its performance will see a qualitative improvement. However, the transition to PoS will still undergo a long transition period. During the phase where the PoW chain bears the network's block production, only Layer 2 is the fastest expansion solution. Many foresighted projects have already begun to establish Layer 2 testing applications, such as AAVE, Synthetix, dYdX, etc., but the principles of Layer 2 will create some new associated issues.
Brief analysis of Layer 2 principles
Let’s take a look at the principles of Layer 2.
Using Ethereum as an example, its Layer 2 solution involves establishing an off-chain structure or sidechain structure on Ethereum, mapping the address balances on Ethereum to the Layer 2 layer, then completing transactions and other operations between accounts on the Layer 2 layer, and finally feeding the settlement results back to the chain to confirm the final data changes of the addresses.
This means that for DeFi applications running on Layer 2, there is interaction between Layer 2 and the chain only when Layer 2 is initially launched and during final settlement; all other transaction processes occur on Layer 2, which does not occupy chain resources, allowing for rapid transaction processing and effectively reducing gas consumption.
However, this approach still has two associated concerns:
- If the main chain's performance is poor and congestion occurs on-chain, Layer 2 and account settlements may still require high gas fees and longer confirmation times.
- Layer 2 may not be able to execute interactions with other on-chain assets and contracts. If interactions are possible, it will still require multiple calls to on-chain resources, leading to the first issue.
Because, aside from transactions being packaged into blocks stored on-chain, all smart contracts are also uploaded to the chain. The norm for DeFi is that asset contracts, lending contracts, and trading contracts call each other, so when calls occur between contracts, it occupies on-chain resources.
This implies two things: first, the process of paying gas fees is unavoidable; second, DeFi requires rich composability.
Thus, the fundamental solution lies in addressing the gas issues brought by Ethereum's PoW chain while maintaining composability among DeFi. This brings us to the answer: if the performance of Layer 1 is fast enough, there is no need for Layer 2 to expand. If the business is not suitable for Layer 2, it is better to use Layer 1 expansion technology, as Layer 2 will affect the composability of smart contracts.
Example of StarkWare's Layer 2 design
However, in the hot demand of a bull market, Layer 2 is a choice for many projects seeking development. For example, dYdX will build the StarkEx system using StarkWare's technology for perpetual contract trading. Let’s look at the technical logic of StarkWare.
StarkWare aims to establish a network beneath Ethereum, where the interaction process with the chain and the communication process of Layer 2 will use Rollup and zero-knowledge proofs to ensure security. However, the premise for applying various DeFi in this network is that DeFi needs to be deployed on StarkWare's network.
The Layer 2 network structure that StarkWare will form in the future.
For example, dYdX is an order book-style DEX. Before applying Layer 2, the order book matching of dYdX worked off-chain, synchronizing settlement data with the chain, which incurred high gas fees. After applying Layer 2, the StarkEx system will complete the settlement process on the Layer 2 layer, significantly reducing the gas fee consumption of this process.
However, this will bring some associated impacts, such as the steps may be slightly more complex, it may not be applicable on mobile devices, and it may incur Layer 2 account opening costs. Furthermore, the biggest issue is that if dYdX wants to open composable applications with other DeFi protocols, other DeFi applications also need to be deployed on this network.
From the original intention of cryptocurrency, this is not an approach to inclusive finance; its application may ultimately become the domain of advanced and professional users.
Therefore, compared to Layer 2, which can make some DeFi (that requires frequent trading) run faster, some DeFi is more suitable for using Layer 1 expansion solutions or higher-performance networks.
For example, Compound has hinted at possibly migrating to other public chains. Order book-style DEXs require a large number of transactions, making them more suitable for Layer 2. In contrast, lending, stablecoins, AMM pools, etc., are better suited to run on higher-performance networks to maximize their value in rich composability.
Layer 1 expansion ideas more aligned with DeFi characteristics
So how do we determine what kind of Layer 1 DeFi needs? Radix provides some insights in its network design:
- Solve the performance bottleneck caused by consensus issues.
- Strive to create composability.
Thus, Radix adopts some unconventional approaches.
As mentioned earlier, homomorphic sharding and heterogeneous sharding involve distributing shards, which are chains composed of a portion of nodes. This can be understood as dividing some nodes into a partition, where this partition exists independently from other partitions, handling tasks separately.
For example, in Ethereum 2.0, if it still follows the original roadmap for executing sharding, it may initially establish 64 shards, all of which will ultimately be validated by the Beacon chain. Communication between shards is called "cross-linking," and if one shard needs to validate another, cross-shard communication will occur. Due to the existence of shards, DApp developers need to choose a shard as the primary processing area when developing DApps on Ethereum.
This means that if this DApp needs to obtain data from other shards, there will be some redundant steps. The structures implemented by Polkadot and COSMOS are similar; Polkadot's parachains are shards within a heterogeneous sharding structure, and interactions between parachains are conducted through a relay chain, but the interaction process is quite complex and requires individual definitions between parachains. COSMOS is similar.
Such sharding is a design that delineates boundaries, and each shard chain will form a certain island effect, naturally leading to some subsequent issues.
However, changing the approach may yield new technical ideas.
For example, Radix has designed a new consensus mechanism on top of database sharding. This can be understood as a new sharding structure combining database sharding and consensus.
Radix's sharding deployment diagram.
This type of sharding differs from the previously mentioned definition of some nodes as shard chains; instead, it divides all computing resources joining the network into different shards. Shards are not divided by chains but are randomly assigned to predetermined shard locations through random commands. These shards formed by commands then constitute larger partitions.
This method of pre-setting shard locations and dynamically assigning commands to various locations to form shards requires consensus to confirm the final state. Radix's Cerberus consensus executes this process, and similar to the ghost algorithm of the Beacon chain that achieves finality, Cerberus consensus can determine the order of transactions and form the final dataset for validators to verify.
The best aspect of this approach is that it can achieve greater parallelism, mobilizing all resources for use, rather than the boundary issues brought by fixed partitions.
Secondly, an important issue is composability.
In comparison to Ethereum, the composability on-chain is the interaction between smart contracts. For example, the cToken borrowed through Compound can be used for mining and swapping in other DeFi applications. This indicates that DeFi contracts need to call the Compound contract to confirm the cToken. The calls between these contracts reflect composability.
If the two are not deployed on the same network or shard, it will be difficult to combine them, requiring gateway processing or the existence of a mapping smart contract.
To solve this problem, Radix's approach is to reduce the programming complexity of smart contracts. Since smart contracts will inevitably record accounts' ledgers to output final results, if implemented in Layer 1, smart contracts can be replaced with smaller units of execution. Radix refers to this execution unit as a "component," which has predefined functionalities. The execution of these components is very simple and direct, allowing multiple components to combine and quickly execute DeFi operations.
For example, when a smart contract involves a transfer, it needs to edit the accounts of both parties, forming a small ledger where the transferor's balance is destroyed and the receiver's balance is increased. If using Radix's component design, the component can be defined as "a's transfer token belongs to b," making execution very fast without requiring further proof.
This will enable a sufficient number of composability possibilities.
Example of Radix's components.
According to official technical documents, the components established by the Radix Foundation will include some standard functions for DeFi applications. These will include (as shown in the image): assets (fungible or non-fungible tokens), accounts (including multi-sig control), liquidity pools, exchange systems, purchasable assets, data oracles, etc.
These components can be directly instantiated, for example, creating custom token supplies through API calls or modularly combining to create more complex functionalities.
Can we expect DeFi applications on new networks?
Just as Compound has hinted at considering new public chains, for the currently popular DeFi, choosing a new network is challenging.
The feasibility of migrating to another public chain is not only a matter of performance but also significantly relates to the compatibility of this chain with assets from Ethereum, Bitcoin, and other networks, as well as the value of the on-chain base currency.
So for now, no DeFi can escape Ethereum, but there are certainly new attempts emerging. On February 11, Chainlink, Aave, mStable, Messari, and Radix announced the joint launch of a new DeFi alliance called GoodFi. This alliance aims to promote education, research, and practical development in the DeFi industry. This gives us hope.
We look forward to the early emergence of low-cost, high-experience DeFi.