Hey I’ve tried checking out your GitHub in search for a technical document but your page has
for most links. I couldn’t find anything useful on Google either. Your GH profile doesn’t point to an org: Juderegev (Yoda) · GitHub
I’m not into making baseless claims but maybe a mod should look into that comment?
You can do this with Merkle proofs.
Remember that we are talking about rollups, whose roots are committed to in the Ethereum chain. Merkle proofs can prove that a transaction or state change took place in a particular block whose root we can verify by inspecting the Ethereum base chain.
Note that this does require the rollup execution to be able to see the Ethereum base chain, but I think this is already supported functionality in many of them.
@vbuterin Does that mean cross rollup transfer can happen off chain (I only need to pay a few cents to transfer my WETH from ZkSync to Arbitrum)?
The rate on Hop exchange is just horrible now (using AMM), so I am wondering if I can just implement what you described for much less fee. Thanks!
If by “off-chain” you mean “without hitting L1”, then yes. The transfer does require a transaction on ZkSync and a transaction on Arbitrum, both of which are much cheaper than Ethereum base layer.
Thanks for the clarification! So I assume in the future for most users, it would be fiat → L2, L2 → L2, which are all very cheap. And occasionally may be L2 to other blockchain L1 if they needed?
Right, that’s definitely the goal! L1 becomes a layer for L2s to make commitments, in addition to sometimes being a place users send transactions in emergency situations if the L2 they are on breaks and they need to withdraw to L1 and re-deposit their funds to another L2 directly.
Could this be used for a trust-minimized BTC / ETH dex?
Smart contract on the ETH side, as described above. You’d also need a contract that tracks the canonical BTC chain.
Sketch of how an ETH contract might track the latest Bitcoin block without a trusted oracle.
Anyone can submit new BTC block headers to the contract. If the total work is higher than the currently-stored head, then the current head is replaced. Concretely the contract would store a mapping from block height > block hash.
Actually validating BTC blocks would be gas cost prohibitive. It might become possible in future if zk advances to where we can succinctly prove Bitcoin block validity. In meantime, the contract would only verify the header / PoW.
Even without tx validation, the contract has reasonable security. Posting invalid blocks with >0 confirmations still requires outrunning the valid BTC hashrate.
Finally, this BTC mirror contract lets you prove that a given Bitcoin transaction was included at a given block height. If necessary, the contract can charge a small fee for supplying those proofs, using the collected fees to incentivize people to publish new BTC blocks / compensate them for gas.
Then, to swap BTC for ETH:
Swapping ETH to BTC works conversely. Alice sends eth to the Ivan2 contract. She can take it back n blocks later, unless Ivan posts a proof that he sent her the correct amount of bitcoin from Ivan1.
Hi all,
We are seriously considering implementing this approach (or something very similar) at ChainSafe.
There seems to be a sticking point around the proof though. I understand how access to L1 header hashes on one rollup allows for proving a transaction that occurs in any other rollup.
The issue is that I can’t find any evidence of an existing rollup that makes L1 header hashes available to the execution. Unless I am mistaken, making header hashes trustlessly available would require changing the rollup validation logic to require block producers to include them for some window in the past.
Does anyone have any further insight into this?
I actually talked to Optimism and Arbitrum about this in the context of cross-L2 bridge work. The summary is that indeed none of them yet support L1 block hash or state root access in their present form, but there is no technical reason why it can’t be done, and I know there are either specific plans or a lot of interest in implementing it.
Until that happens, the easiest workaround is to have a contract on L1 that reads recent block hashes and makes deposit messages into the L2 passing along those block hashes at regular intervals.
I also talked to Optimism and Arbitrum about it a year ago when I wrote GitHub - yoavw/cross-rollup-bridge which relied on this capability to avoid the periodic L1 transactions. Arbitrum suggested that it’ll make more sense to have a higher level functionality in a precompile. If L2 only exposes the L1 state root, then each L2 transaction requires a fairly large proof. Calldata is the primary cost for rollups so it makes sense to optimize.
The suggestion was for the sequencer to still include a recent L1 state root in each batch, to be covered by fraud proofs, but then use it in the precompile to offer things such as getStorageSlot(account,slot) and getBalance(account). The proof itself doesn’t need to be in calldata.
If @Willem-ChainSafe is going to build this, then it’s worth revisiting this issue with Optimism and Arbitrum. But in the meantime a periodic L1 blockhash update via the canonical bridges should work fine.
How is fee determined? It can’t be controlled directly by Ivan, or he could make it 1 and walk away with TRADE_VALUE, but it also can’t be a fixed fee because L1 calldata costs fluctuate so Ivan’s transaction to IVAN_B could cost more than the fee. I guess IVAN_B must calculate the fee, taking L1 costs into account.
Luckily both Arbitrum and Optimism have a precompile/predeploy with the L1 gas price paid by the sequencer, but it can only be used for estimation, since calldata is compressed and I think the actual size is unknown to the contract. IVAN_B should probably overestimate fee by assuming no calldata compression.
