Author | Vitalik Buterin
Author | Vitalik Buterin
Suppose we have two rollup solutions A and B, and Alice wants to exchange a certain amount of tokens on rollup A for the same tokens on rollup B. Someone has already proposed a solution to this problem. If both rollup A and B fully support smart contracts, then this assumption can be realized in a decentralized manner. However, this article proposes how to implement cross-rollup transfers when only rollup B fully supports smart contracts (and rollup A can only handle simple transactions).
proposal
proposal
Suppose we have an exchange intermediary Ivan (there are many intermediaries to choose from in implementation). Ivan owns an (account fully controlled by him) IVAN_A in rollup A. At the same time, Ivan also deposited some funds in the smart contract IVAN_B of rollup B.
Smart contract IVAN_B has the following rules:
➤ If any user sends a transaction (sending a token transaction value TRADE_VALUE to account IVAN_A), (a destination address B DESTINATION is also attached as a note in the transaction), after the minimum repayment delay of MIN_REDEMPTION_DELAY blocks, the user A transaction can be returned to the account IVAN_B (including the previous transfer proof), and then the transaction will be queued for withdrawal to the address DESTINATION.
➤ After waiting for a certain delay (for example, one day), the withdrawals are processed in the batch and index order in which the transfers are packaged into rollup A.
➤ When Ivan finds out that his account IVAN_A has received money, he can personally send TRADE_VALUE * (1 - fee) tokens to DESTINATION. He can do this by sending a transaction using the IVAN_B method, which keeps a record and prevents the automatic sending clause in the contract from triggering the transaction.
The expected behavior is simple:
➤ Alice sends a transaction to account IVAN_A (contains N tokens and a note ALICE_B)
➤ Ivan sends TRADE_VALUE * (1 - fee) tokens to ALICE_B via IVAN_B
The second transaction happens right after the first transaction. If Ivan can prove that the timestamp difference between the first transaction and the second transaction is very small, then the contract even has rules that allow the fee to be raised.
capital cost
capital cost
The main limitation of this scheme is that IVAN_B needs to hold a large amount of funds to ensure that all transaction senders are paid. In particular, assume the following situation occurs:
➤ We set the transaction cap to TRADE_LIMIT (so when a transaction sent to IVAN_A exceeds the limit value > TRADE_LIMIT, the transaction is invalid)
➤ Each rollup batch can contain up to TXS_PER_BATCH transactions
Alice can check herself how many unprocessed transactions are left before rollup A's next batch of transactions needs to be processed, subtract the total value of these transactions from her funds in contract IVAN_B, and check whether the remaining amount is enough. Since withdrawals are processed sequentially (which is the purpose of the queuing mechanism described above), Alice doesn't need to worry about the contract processing other withdrawal requests before processing her withdrawal transaction request.
The maximum transaction size in each batch is TRADE_LIMIT * TXS_PER_BATCH , so at least this much ETH is required in the IVAN_B contract, plus additional funds are required to include transactions for processing. For example, suppose the transaction limit is 0.1 ETH TRADE_LIMIT = 0.1 ETH (the transaction limit can be set relatively low, because a large transaction can be divided into several small transactions), and each batch can process 1000 transactions TXS_PER_BATCH = 1000 . Then, contract IVAN_B needs to hold 100 ETH.
Note that there is also an implicit fee in this design, as any user who transacts more than 0.1 ETH needs to waste block space. This is weighed against the capital requirement, i.e. if a user consumes half of the block space, then their capital requirement will be doubled, and vice versa. If one wants to strike the right balance, the implied fees are several times less than the explicit fees on the market.
first level title
Remark
The above design is based on an assumption: the transaction on Rollup A has a comment field, through which Alice can specify ALICE_B as the destination address for her to receive tokens. If rollup does not have this feature, then we can use the following solution. Alice can register account ALICE_B on a sequentially registered contract on rollup B and get a sequentially assigned ID (so Alice's ID is equal to the number of users registered before her).
first level title
Transaction from Rollup B to Rollup A
If Alice transfers tokens from Rollup B to Rollup A, she can use the same mechanism, but with the roles reversed:
➤ Alice sends tokens to IVAN_B
➤ After some delay, she will be given the right to get her tokens back
ECN's translation work aims to deliver high-quality information and learning resources for the Chinese Ethereum community. The copyright of the article belongs to the original author, and the source of the original text and the ETH Chinese website must be indicated when reprinting. For long-term reprinting, please contact eth@ecn.co for authorization.
Click "Read the original text" to get the internal link of the article!
Original link:https://ethresear.ch/
ECN's translation work aims to deliver high-quality information and learning resources for the Chinese Ethereum community. The copyright of the article belongs to the original author, and the source of the original text and the ETH Chinese website must be indicated when reprinting. For long-term reprinting, please contact eth@ecn.co for authorization.
