VIDEO
HIGHLIGHT
Log InSign up
Ben Jones - Fire the Cannons: Optimism's Next-Gen Fault Proofs
SummaryTranscriptChat

Ben Jones - Fire the Cannons: Optimism's Next-Gen Fault Proofs

Introduction

In this section, Ben introduces himself and the topic of his talk. He also plays a song to get everyone's attention.

  • Ben requests a song to kick off his talk.
  • He plays a melody and asks everyone to clap along.
  • Ben thanks the audience for their patience and introduces himself.
  • He talks about optimism's next-gen fault proofs.

What is Canon?

In this section, Ben explains what Canon is and its importance in the context of optimism bedrock.

  • Canon is the multi-step fall proof built for optimism bedrock.
  • It allows running arbitrary golang in a roll-up that follows EVM rules down to the letter.
  • Bedrock edition is optimism's next-gen release that condenses all learnings from building protocols over two years into one minimal code base.
  • The principle followed in building bedrock is "reduce, reuse, recycle, minimize."

Building Bedrock with Security in Mind

In this section, Ben discusses how security was prioritized while building Bedrock.

  • Security comes from having less code as more code increases the risk of introducing bugs.
  • The name of the game for everything built with Bedrock is "do it right" and "do it small."
  • To apply this principle to Canon, they reused Ethereum's system (mini Geth), used a very minimal instruction set (RISC), and worked down to fundamental abstractions that make up these rollup systems.

Multi-step Fraud Proofs

In this section, Ben provides an overview of multi-step fraud proofs.

  • Multi-step fraud proofs are like sandwiches; they have layers.
  • They start with go ethereum implementation (L2 guess dot go).
  • Then, they add a fraud proof layer that checks if the state transition is valid.
  • Finally, they add a data availability layer that ensures all data is available to everyone.

Conclusion

In this section, Ben concludes his talk and invites questions from the audience.

  • Bedrock is built to last and will be the basis for all building over the next few years from optimism.
  • Canon is an essential part of Bedrock that follows EVM rules down to the letter.
  • Multi-step fraud proofs are crucial in ensuring security in rollup systems.
  • Ben invites questions from the audience.

Introduction

In this section, the speaker introduces the two hard problems that had to be solved in developing Canon and generally when building a roll-up.

Two Hard Problems of Building Roll-Ups

  • The first problem is how to deal with inputs. During a dispute, we need to verify that the transaction data being disputed is the transaction data that was posted originally.
  • The second hard part of this is persisting state. We need to know what the state was at block a thousand and show that from block 1000 to block 1001, where the fault occurred.

Pre-image Oracle

In this section, the speaker introduces pre-image oracle as a solution to both hard problems.

What is Pre-image Oracle?

  • It's basically a new singular addition that you make to this missed vm and the function is actually incredibly

Hash Functions and Pre-Image Resistance

In this section, the speaker discusses the concept of pre-image resistance in hash functions and how quantum computing can affect it.

Pre-Image Resistance and Quantum Computing

  • A hash function is by definition pre-image resistant.
  • The solution to this problem is quantum computing.
  • Hashes are resistant to quantum computing as far as we know.
  • If you know the pre-image to a hash, you can find it easily.
  • Some pre-images are easy to find.

Using Pre-Images for Verification

In this section, the speaker explains how knowing the pre-image of a hash can be used for verification purposes.

Verifying with Pre-Images

  • Once you know the pre-image, you can verify it on chain.
  • You do it in reverse by requiring that the hash of the pre-image is equal to the output.
  • If that requirement is met, then you have all of the information needed to progress this VM.

Block Hashes and Ethereum Blocks

In this section, the speaker talks about block hashes and their importance in Ethereum blocks.

The Importance of Block Hashes

  • The block.hash has a header that is known.
  • If you have the block hash, you can know what comes from it.
  • The entire point of distributed global consensus blockchain buzzword dag whatever is that block.hash has a header that is known.

Using Oracle for Reverse Engineering

In this section, the speaker explains how an oracle can be used for reverse engineering.

Reverse Engineering with Oracles

  • An oracle input a block hash and outputs its whole header.
  • For an Ethereum block, one can always find its pre-image.
  • The only input needed for following the bedrock goals is a block hash.
  • Everything else is a subsequent state transition that can be pulled out.

Understanding Ethereum's Rollup Architecture

In this section, the speaker explains how Ethereum's rollup architecture works and how it is different from other smart contract systems.

Smart Contract Transactions

  • Transactions in Ethereum's rollup architecture are submitted to a sequencer.
  • The sequencer submits transactions where the to address is an EOA (Externally Owned Account).
  • There is no code or account bytecode involved in these transactions.
  • The data that matters is stored in the block header.

Pre-image Oracle

  • A pre-image oracle can be used to access state data stored in the database.
  • The state route itself is a hash of some children, which are stored in the guest state db.
  • Traversing an entire state tree can be done using this pre-image oracle.

Rollup Input

  • The one true input to all of the up is just two things:
  • The hash of the next block hash
  • Call data and previous L2 block hash from which you pull the state route from which you can pull any state that you care about.

Conclusion

The speaker emphasizes that understanding this mental model of Ethereum's rollup architecture can save time for developers. He also mentions that his excitement for this abstraction has grown since working on it.

Benefits of Multiple Node Implementations

In this section, the speaker discusses the importance of having multiple node implementations for decentralization and security. They also talk about how the MIPs VM that runs on-chain is just one implementation and how it plays with other implementations.

Importance of Minimizing Diff

  • Bedrock is about minimizing the diff and reducing it.
  • The reference L2 gap implementation right now which runs end-to-end test deposit transact withdrawal sequence, has a diff for that entire code base from Geth to L2 Geth sitting at like 400 lines.
  • Nobody is good at writing code, so the less code you write, the better you are writing code.

Need for Multiple Client Implementations

  • It's important to have multiple client implementations.
  • Check out Optimism's path to decentralization post.
  • Eventually, we want to have multiple VM implementations.

Security Concerns

  • Having multiple client and VM implementations is the best way to get true security that we can actually remove upgrade keys on because there could be tail risks that we want to try to avoid.

Limits of Interactive Fraud Proof Execution

In this section, a question is asked about what are the complexity limits of interactive fraud proof execution. The speaker talks about executing arbitrary MIP bytecode and Wasm on Canon.

  • The question asks what are the complexity limits of interactive fraud proof execution.
  • You can execute arbitrary MIP bytecode and Wasm on Canon.

Tamagotchi Emulator in Canon

In this section, the speaker talks about someone who is writing a Tamagotchi emulator in Canon. The speaker expresses excitement about the first-ever L2 Tamagotchi emulation and emphasizes that there are many things that can be done with Canon.

  • A shoutout is given to someone who is writing a Tamagotchi emulator in Canon.
  • The speaker expresses excitement about the first-ever L2 Tamagotchi emulation.
  • The speaker emphasizes that there are many things that can be done with Canon.

Memory Limitations of VM Steps

In this section, the speaker discusses the memory limitations of VM steps when using Canon. They explain that eventually, you will run out of memory and it will become a hardware requirement for the fault prover. However, so far, it has not been a big issue.

  • The number of VM steps you run determines how much memory you use.
  • Eventually, running out of memory becomes a hardware requirement for the fault prover.
  • So far, memory limitations have not been a big issue when using Canon.

Difficulty Level of Running Tamagotchis vs Smart Contracts

In this section, the speaker responds to a question regarding whether running tamagotchis or smart contracts is harder. They express their belief that tamagotchis are simple and not harder to run than smart contracts.

  • The difficulty level of running tamagotchis compared to smart contracts is discussed.
  • The speaker believes that tamagotchis are simple and not harder to run than smart contracts.

Upgrading Executable During Hard Forks

In this section, the speaker answers a question regarding what happens with hard forks and how to upgrade the executable that is running on the MIPS. They explain that a hard fork in L1 involves changing the Ethereum code base, and if you want to incorporate those changes into your L2, you need to upgrade the executable that has been compiled.

  • A question is asked about what happens during hard forks.
  • The speaker explains that a hard fork in L1 involves changing the Ethereum code base.
  • To incorporate those changes into your L2, you need to upgrade the executable that has been compiled.
Video description

In this talk, Ben will give an overview of Optimism's new fault proof, Cannon. It will cover some of the history of fault proofs within Optimism as well as the broader ecosystem, explain the new insights that Cannon brings to the table, and discuss Optimism's plans for its future. Ben "Weird ETH Yankovic" Jones is a co-founder and Chief Scientist at Optimism. Prior to Optimism he worked on Ethereum's CBC Casper team.