An Optimism dev @norswap made a great blog post comparing Optimism Bedrock to Arbitrum Nitro! norswap.com
I thought I'd explain why we @Arbitrum made the choices we did and go into some more detail on our side. I'd recommend following along with the blog post! ๐งต
I thought I'd explain why we @Arbitrum made the choices we did and go into some more detail on our side. I'd recommend following along with the blog post! ๐งต
(A) Fixed vs variable block time
We don't quite do 1 tx per block. We actually create a block up to 4 times a second currently, but we skip creating the block if there's no new transactions for it. This minimizes latency for getting your transaction receipt.
We don't quite do 1 tx per block. We actually create a block up to 4 times a second currently, but we skip creating the block if there's no new transactions for it. This minimizes latency for getting your transaction receipt.
How do we deal with smart contracts using block.number for timing? On Arbitrum, block.number actually returns the *L1* block number. You can get the L2 block number from the ArbSys precompile if you need it.
(B) Geth as a library or as the execution engine + State storage
This is because as mentioned in the blog post, Arbitrum has a lot more L2 specific state, such as gas pricing for L1 and L2, and the retryable system. We'll get into those later!
This is because as mentioned in the blog post, Arbitrum has a lot more L2 specific state, such as gas pricing for L1 and L2, and the retryable system. We'll get into those later!
(C) L1 to L2 message inclusion delay
We can reorg L2 if necessary (delayed_seq_reorg_test.go demonstrates this), but we really want to avoid it if at all possible because it hurts UX. We aim to never reorganize L2, providing users a nice stable experience.
We can reorg L2 if necessary (delayed_seq_reorg_test.go demonstrates this), but we really want to avoid it if at all possible because it hurts UX. We aim to never reorganize L2, providing users a nice stable experience.
(D) L1-to-L2 messages retry mechanism
Retryables are definitely more complex, but here's why: They don't rely on a trusted L2 gas price oracle on L1 to figure out how much to charge. Instead, you can charge the L2 gas price, and if it's too high retry later.
Retryables are definitely more complex, but here's why: They don't rely on a trusted L2 gas price oracle on L1 to figure out how much to charge. Instead, you can charge the L2 gas price, and if it's too high retry later.
(E) L2 fee algorithm
Having a variable block time necessitates a more complex gas pricing scheme. We're still heavily inspired by EIP-1559 though!
Having a variable block time necessitates a more complex gas pricing scheme. We're still heavily inspired by EIP-1559 though!
(F) L1 fee algorithm
One thing we wanted to avoid is the sequencer overcollecting fees by only posting batches when gas prices are low, but using a moving average of all L1 gas prices to charge. Our L1 pricer tracks how much the batch poster paid to prevent this.
One thing we wanted to avoid is the sequencer overcollecting fees by only posting batches when gas prices are low, but using a moving average of all L1 gas prices to charge. Our L1 pricer tracks how much the batch poster paid to prevent this.
(G) Fraud proof instruction set (๐)
Because WASM without extensions doesn't have threading, we don't need to do any extra pruning of concurrency. The go compiler handles this natively by green threading the single WASM thread.
Because WASM without extensions doesn't have threading, we don't need to do any extra pruning of concurrency. The go compiler handles this natively by green threading the single WASM thread.
That difference is part of what allows us to prove the full geth, instead of a trimmed down minigeth like Optimism's Cannon will. We just need to implement the APIs Go expects for a WASM host, which we do inside a WASM module here: github.com
(H) Bisection game structure
It's not just less hashing, you actually don't need to execute any blocks in WASM that aren't in dispute! We still execute them anyways to ensure safety, but it's not necessary to participate in the rollup.
It's not just less hashing, you actually don't need to execute any blocks in WASM that aren't in dispute! We still execute them anyways to ensure safety, but it's not necessary to participate in the rollup.
Speaking of which, one advantage of WASM is for that re-execution safety checking, where we're able to use an off the shelf WASM JIT instead of our custom WAVM interpreter. This makes checking that the WASM execution of blocks is correct insanely fast! github.com
(I) Preimage oracle
We don't actually explicitly use the preimage oracle to resolve any L1 data. Instead, because we record each batch's hash in the bridge, we have a ReadInboxMessage opcode which both retrieves that hash *and* pulls out the preimage in a single instruction.
We don't actually explicitly use the preimage oracle to resolve any L1 data. Instead, because we record each batch's hash in the bridge, we have a ReadInboxMessage opcode which both retrieves that hash *and* pulls out the preimage in a single instruction.
(J) Large preimages
As mentioned in the blog post, we avoid this problem by simply ensuring our preimages are small enough. For instance, we merkelize data availability batches to ensure that any given preimage is small enough, even though the whole batch wouldn't be.
As mentioned in the blog post, we avoid this problem by simply ensuring our preimages are small enough. For instance, we merkelize data availability batches to ensure that any given preimage is small enough, even though the whole batch wouldn't be.
(K) Batches & state roots
We actually don't tie our sequencer batches to state roots. The sequencer posts each batch to the sequencer inbox which stores them in the bridge, and then later a validator will post an RBlock asserting the state after consuming some batches.
We actually don't tie our sequencer batches to state roots. The sequencer posts each batch to the sequencer inbox which stores them in the bridge, and then later a validator will post an RBlock asserting the state after consuming some batches.
(L) Misc
(i) I'm curious how Optimism can know if the whole batch contains any garbage before processing it. I'm assuming "garbage" includes a tx that the sender can't pay for, which depends on the previous state. But yes, in practice nobody posts garbage.
(i) I'm curious how Optimism can know if the whole batch contains any garbage before processing it. I'm assuming "garbage" includes a tx that the sender can't pay for, which depends on the previous state. But yes, in practice nobody posts garbage.
(ii) As mentioned in (B), we have a lot more state, so we need precompiles to make that state easily accessible to users.
(iii) I'm not sure if this is how we estimated gas costs for the bisection degree, but hardhat-gas-reporter is quite helpful for reporting gas costs.
(iii) I'm not sure if this is how we estimated gas costs for the bisection degree, but hardhat-gas-reporter is quite helpful for reporting gas costs.
In conclusion: it's a great blog post and a very interesting comparison. I learned a lot about Optimism Bedrock along the way, and I'm super excited for the future of rollups! If you're as excited as I am, and you made it through this thread, we're hiring! jobs.lever.co
Loading suggestions...