Editor's Note: This article comes fromBlue Fox Notes (ID: lanhubiji)Editor's Note: This article comes from
Blue Fox Notes (ID: lanhubiji)
Foreword: With the arrival of ETH2.0 sharding, some people worry that the important attribute "combinability" in Ethereum's DeFi will continue to be maintained? V god thinks there is nothing to worry about. You can "yanking" to pull the shard first, and then perform operations on the same shard synchronously. The author of this article is Vitalik Buterin, translated by "SL" of the "Blue Fox Notes" community.
There have been concerns recently about whether the "combinability" property of Ethereum, the ability for different applications to easily talk to each other, will continue to be preserved in the sharding environment of ETH2.0. This paper argues that this capability will basically be maintained.
secondary title
What happens to sharding?
However, as we can see from the examples below, most use cases will not be severely broken, or can be slightly rewritten to survive the cross-shard pattern.
Token
secondary title
Token<->The ERC20 standard will need to be revised. Tokens will exist on all shards and can move seamlessly from one shard to another, just like ETH. This can be done with receipts, and in the same way that ETH is moved from one shard to another, we can move tokens from one shard to another. There is no fundamental difficulty here.
Composability Case 1: Uniswap
Token
Almost all DeFi applications are using composability, because tokens are a type of application, so any DeFi application that uses tokens is an application that interacts with other applications.
Taking Uniswap as an example, in Uniswap, the user sends a certain amount of token A to the Uniswap contract, and the contract returns a certain amount of token B to the user. Uniswap requires strict dependencies between all transactions it interacts with: the Nth transaction must know the output of the N-1th transaction, because this is how the price update algorithm works.
Therefore, Uniswap contracts will need to be carried out on a single shard, (multi-shard Uniswap designs exist, but this is more complicated). Users seeking a transaction will follow two steps:
1. The user sends his token A to the shard where Uniswap is located
2. As before, trade with Uniswap (combine the trade with the "claim" receipt trade from step 1, so it counts as one step)
There is also an optional step of moving the token B given to them by Uniswap to other shards if desired. (Blue Fox Note: For example, perform lending operations on Compound.)
Composability Case 2: Lending on Compound (including cDAI, etc.)
Compounds can also exist on a single shard (if Compound becomes popular, different instances of Compound representing different token pairs can be placed on different shards. Users who own one token move their tokens to a specific Compound instance shard and create a leveraged position as before.
Composability Case 3: Tokens in L2 Scaling Solutions (Rollup, Plasma...)
Move the tokens to the shard of the contracted L2 scaling solution and deposit them into the contract. Done.
Composability Case 4: rDAI, gDAI, etc.
Move your DAI into the [insert DAI style here] contract. Take it from [insert DAI style here], and move to whatever shard you want. For convenience, the [insert DAI style here] contract itself can only be on the same shard as the Compound instance of DAI.
Composability Case 5: Set Protocol
Move the tokens to the shard where the Set protocol contract is located (different instances may be in different shards, such as Compound). Send them to the Set protocol contract, withdraw Set tokens, move Set tokens to whatever shard you want.
Composability Case 6: Oracles
Composability Case 7: Non-Homogeneous Assets and Markets
Non-homogeneous assets, including NFTs, in-game assets, ENS names, MakerAO CDPs, Compound positions, etc., can all be "pull" to other shards, where they can seamlessly interact with other applications (such as atomic swaps Market, Auction), same as before.
secondary title
