.jpeg)
While people are still thinking about using rollup to ease the congestion of Layer 1, Vitalik is already considering how to interact between rollups. Six days ago, Vitalik initiated a proposal called "Cross-rollup DEX", which mentioned that when one rollup has smart contract deployment and the other rollup does not have full smart contract functions, the assets can go between the two rollups. Transfer in a centralized way.
There is a feeling of "moving things in the air". How is this process realized? Beep News translated the proposal and the wonderful discussions between Vitalik and community members as follows: Suppose we have two rollups, rollup A and rollup B. Alice wants to transfer a certain amount of tokens from rollup A to rollup B. If both A and B have full smart contract support, in this case, there have been proposals on how to solve this problem in a decentralized way. This proposal intends to provide ideas for the situation where only rollup B has full smart contract support (rollup A can only handle simple transactions). We assume that the transaction on rollup A has some kind of "remark field". If it does not, we can use the low-order bits of the value to send as a remark.
proposal
Suppose there is a transaction intermediary Ivan (in actual implementation, there will be many intermediaries to choose from). Ivan has an account IVAN_A on rollup A (he fully controls the account). Ivan also deposited some funds into the smart contract IVAN_B on rollupB. The smart contract IVAN_B has the following rules: If anyone sends TRADE_VALUE tokens to IVAN_A with an address DESTINATION as a remark, then after the MIN_REDEMPTION_DELAY block, IVAN_B will receive a transaction that contains a proof of token transfer , So that a transaction of withdrawing TRADE_VALUE tokens is queued to the DESTINATION address. Withdrawal is processed according to the batch and index order of the transaction included in rollup A, with some delay (for example, 1 day).
When Ivan sees that he has received funds in IVAN_A, he can personally send TRADE_VALUE *(1-fee) tokens to the DESTINATION address. He can send a transaction through the method in IVAN_B, which saves a record to prevent the automatic sending clause in the contract from triggering the transaction. The expected operation is simple: -Alice sends a transaction to IVAN_A, which contains N tokens and the memo address ALICE_B. -Ivan sends TRADE_VALUE * (1-fee) tokens to ALICE_B via IVAN_B. The second step can be performed immediately after the first step. If Ivan proves that the time stamp difference between the second transaction and the first transaction is very small, then the contract can even make rules that allow higher fees. The "worst case" is that Ivan did not send tokens to ALICE_B as expected. In this case, Alice can wait for the transaction confirmation on rollup A to find other ways to obtain tokens on rollup B to pay for the fee, and then she can ask for funds herself.
Capital cost
The main limitation of this scheme is that IVAN_B needs to hold a large amount of funds to ensure that all senders can be paid. In particular, suppose: we set the upper limit of the transaction amount to TRADE_LIMIT (so in the transaction sent to IVAN_A, the transaction with the transaction value> TRADE_LIMIT is not a valid transaction). At the same time, we set the maximum number of transactions that can be included in each rollup batch to TXS_PER_BATCH. Alice can check by herself how many unprocessed transactions before rollup A's upcoming batch, subtract this value from the funds she sees in the IVAN_B contract, and check whether the remaining amount is sufficient.
Since withdrawals are processed in sequence (this is the goal of the sequence mechanism above), Alice does not need to worry that IVAN_B will deal with subsequent withdrawal requirements before she withdraws by herself. The maximum amount that can be traded in a batch is TRADE_LIMIT * TXS_PER_BATCH, so the IVAN_B contract needs to hold at least this amount of ETH, plus enough funds to cover unprocessed transactions. For example, suppose TRADE_LIMIT = 0.1 ETH (the upper limit can be set lower because a higher amount of transaction can be completed in multiple transactions), and TXS_PER_BATCH = 1000. Then, IVAN_B needs to have 100 ETH funds.
Note that there are additional hidden costs in this design, because anyone who trades more than 0.1 ETH needs to consume block space, which is weighed against the funding requirements: if you consume half of the block space, then your Funding requirements will also be doubled (which may mean higher implied fees), and vice versa. To establish the right balance, it seems that the hidden costs should be several times less than the explicit costs that appear in the market. If we want to reduce or eliminate this consumption, rollup A can be designed such that, for example, the sequencer sends a signed message to prove to Alice that all messages approved in the batch so far. Then Alice will know that there was no transaction before her (although a malicious sequencer can deceive Alice, but at a high cost).
Remarks
The above design is based on the assumption that the transaction on rollup A has a remark field. Alice can use this field to 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 ALICE_B on rollup B of the sequential registration contract and get an ID assigned in sequence (so Alice's ID is equal to the number of users registered before her). Set MAX_USER_COUNT to the maximum number of users. If necessary, this value can be adjusted upwards over time. Alice can simply make sure that TRADE_VALUE% MAX_USER_COUNT is equal to (Alice's ID), and use the low-order bits of TRADE_VALUE (this number represents an unimportant value) to indicate the number of tokens she wants to trade.
Transaction from rollup B to rollup A
If Alice transfers the tokens on rollup B to rollup A, a similar mechanism can be used, but the role is reversed: -Alice sends the tokens to IVAN_B-After a period of delay, she will get the right to withdraw the tokens-if Ivan can prove to IVAN_B that he sent Alice tokens on rollup A, and Alice lost this right
to sum up
So we can see that in this process, many "Ivans" are actually decentralized banks, playing the roles of deposit machine and cash machine on the two rollups, thereby earning fees. If Ivan does evil, there is no need for too much interaction between rollup A and rollup B, and Alice can provide proof of the coin. According to Vitalik's statement, in the scenario of transferring money from rollup A to rollup B, the step of providing proof can be performed directly on rollup B. As long as rollup B can obtain the block hash of rollup A, it can be calculated on rollup A. Transaction records, thereby claiming against Ivan. In the process of claiming, Vitalik also gave more possibilities.
For example, a "fast track" can be added to Ivan B, and Alice B can sell her withdrawal slot on Ivan B to other users. Assuming this user is called Bob, then Bob can transfer the money to Alice B first, and then, the funds that Ivan B should transfer to Alice B will be obtained by Bob. That is, Bob advances funds to Alice to improve Alice's user experience. This process may involve gameplay such as mining. Some users on Github mentioned whether this model would be better if the middleman Ivan was not an individual, but a decentralized fund pool.
Vitalik said that this will involve the ownership of the fund pool on rollup A (maybe all funds in the pool are controlled by a private key). In contrast, it may be more reasonable to have multiple middlemen as a decentralized "funding bridge" . This is the general idea of cross-rollup DEX.
Although there may not be many applicable scenarios, and some scenarios that affect the security of funds may not be considered, this allows us to see some possibilities on Layer 2. From some perspectives, blockchain solutions may be rule design.