Finally! Now presenting @optimismPBC's Optimistic Rollup contracts (v2): https://github.com/ethereum-optimism/contracts-v2

Here's a little thread about why this code is so fucking cool.

So these contracts handle the Layer 1 (Ethereum) side of @optimismPBC's Optimistic Rollup construction. The basic idea behind "rollup" is that you can make transactions cheaper by running smart contracts outside of Ethereum ("Layer 2") and only storing tx results on Ethereum.

However, doing this means relying on the Layer 2 nodes to actually generate and publish correct transaction results. You're opening the door up to someone publishing a bad result ("all the money is mine now!").

Obviously we want to prevent people from being able to do this, so we need some sort of "fraud proof" system. Essentially, this means allowing people to play back a transaction on Ethereum and demonstrate that the published result was bad (+ reward people who catch bad results).

Great! Buuuuut... we'll quickly run into problems if Layer 2 contracts can run arbitrary code. And all because Ethereum allows contracts to access things like `block.number`, which either don't exist on Layer 2 or have a completely different value!

If a contract can change their behavior based on these values, then we'll never be able to guarantee that a transaction on Layer 2 will produce the same result if it's executed back on Layer 1. Non-determinism, boooooo!

Okay... so how do we get around this? If you guessed "analyze the bytecode of contracts and make sure they don't use non-deterministic opcodes," then you'd be right! But yes, that's basically the first step of solving this issue. Block contracts that use bad opcodes.

Well we've blocked contracts from using potentially non-deterministic functionality, but how do we give them access to the necessities like contract storage or cross-contract interactions?

If you guessed "replace all the bad opcodes with calls to a special contract that simulates the behavior of those opcodes in a deterministic way," then you'd be right! This special contract is called the "Execution Manager."

The Execution Manager is responsible for making sure that any potentially non-deterministic Ethereum behaviors get converted to deterministic ones. For some opcodes (like `block.number`) this is pretty simple and just involves returning stored values. Other opcodes though...

Opcodes like SLOAD and SSTORE (storage opcodes) seem like they could be easily implemented by using the Execution Manager's internal storage. When we want to run a transaction on Layer 1, we'll "prime" the Execution Manager with all of the storage it needs to run our transaction.

Which works, but an issue arises when a contract tries to access storage that wasn't "primed." If this happens, the Execution Manager needs to immediately halt (because it can't continue unless it knows exactly what values to provide during execution).

So HERE's where things get FUCKY. Our custom opcodes are implemented as calls to the Execution Manager. The Execution Manager can't just halt by reverting, because a revert inside of a call doesn't automatically revert the code that made the call.

The only thing that will automatically revert everything is running out of gas, but contracts can always do that themselves. So unfortunately we can't use that as a signal that something went wrong (or contracts could lie about something going wrong).

What's the solution? If you guessed "also analyze contract bytecode to make sure that contracts will automatically halt if the Execution Manager tells them to halt," you'd be right! We force contracts to detect these cases (via revert data) and revert right away.

This works in *every* case but one! Can you guess which?

Contract creations! When contract creation transactions fail, there's no way to pass information out about *why* the creation failed. It's a big limitation of Ethereum. Without this ability, we can't signal that the entire execution needs to be halted.

Hack time. Solution? Don't revert contract creations right away. Always *return*, but set a flag somewhere if things went wrong. Catch that flag after the creation, and *then* revert (within a CALL, meaning we can pass back revert data again).

This means more analysis on contract bytecode, but it works!

https://github.com/ethereum-optimism/contracts-v2/blob/feat/polish/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol is FULL of these amazing little things. I highly recommend checking it out.

There's so much more to these contracts than I can hope to explain in a tweet thread, but I hope this sparked some interest. I'm always very happy to explain anything about these contracts if people have specific questions!

Thank you so much for reading