Another + vote for cross-shard synchronousity (even though it’s not technically a word). I’m imagining that we’re sacrificing developer/user experience for security/scalability here, though?
Granted, all DeFi apps could just be on the same shard. So, that could work, too, but potentially without as much scalability.
FYI. We have implemented a multi-chain/sharding blockchain network that supports most of the DeFi examples at the time being in QuarkChain. To be specific, the network has implemented the following features to support Cross-Shard DeFi composability:
Current address = ETH address (20 bytes) + chain ID (2 bytes) + 2 bytes unused. When performing a transaction, both the sender and receiver must specify the full addresses so that the network could determine which chain the tx is initiated from and which chain the receiver (a user address or smart contract) will receive the transferred token. If the chain ID’s of the sender and receiver of a tx are different, then the tx is cross-shard tx.
To support moving a user-created token between different shards, a user could create a native token with a unique token ID, and a transferTokenID field is added in a tx to indicate which native token is transferred. As a result, a cross-shard tx will move the user-created token by deducting the balance of a user-created token, create a receipt (we call it “deposit”) including the balance and transferTokenId to target shard, and the target shard will process the receipt and increase the balance of the transferTokenId of the receiver.
Note that if the receiver address is a smart contract, the processing of the receipt will automatically call the smart contract and if there is a refund, the corresponding token will be added to the sender’s address in the target shard (i.e., same ETH address but with target shard chain ID).
Currently, we don’t support moving contract-based tokens (e.g., ERC20) to different shards at the moment, but a user could easily create a contract that could automatically swap a contracted-based token to a native token and move it to any shard.
Suppose a user with ETH address 0x1122…ff would like to swap token A in chain ID 1 to token B by a uniswap contract in chain ID 0 with address 0x2233…ff0000xxxx, a user will create a tx with
tx = { sender_chain_ID: 1, to: 0x2233..ff0000xxxx, transferTokenID=tokenA, value=number_tokenA, data="uniswap_call_data (e.g., swap to tokenB)", v,r,s=sigature of sender, ...,}
The transaction will trigger the following steps:
1, Withdraw tokenA from sender account in chain 1
2, Send the receipt to chain 0
3, Chain 0 processes the receipt, calls contract 0x2233…ff0000xxxx. Upon the success of the call, the swapped tokenB will be returned to 0x1122…ff0000xxxx
After the tx, a user could move the tokenB from 0x1122…ff0000xxxx to another shard address own by the user (e.g., 0x1122…ff0001xxxx). A tool was developed to help users collecting all balances from all shards to one shard (www.qpocket.io).
The design allows the sender who has balance in a shard chain with different ledger models (e.g., UTXO) to participant in DeFi in other chains. The transaction basically contains two parts: 1, the part that unlocks the sender’s UXTOs in a UTXO chain; 2, the part containing information for calling target shard such as smart contract full address, refund address, transferTokenId, startgas, etc.
Note that all the features are available in mainnet except we are discussing the native token insurance model at the time being.
Further, notice that the network only aims to provide a practical system that already supports the examples in the original post by Vitalik. This means it will suffer from the same issues (e.g., calling multiple contract in different shards atomically) of the original idea as discussed in the thread because all the cross-shard tx calls are async.
Further solution to address the async issue may provide a shard chain that is dedicated for DeFi with DeFi optimized consensus/ledger/tx model. Actually, we are working with nuts on the idea.
So from what i am understanding from this is that regular composability on the same shard would not be disrupted and would not require any form of rewriting. On other hand, if i need to perform composability with a contract on a different shard, i would need to rewrite that contract to perform yanking.