HackMD
  • Prime
    Prime  Full-text search on all paid plans
    Search anywhere and reach everything in a Workspace with Prime plan.
    Got it
      • Create new note
      • Create a note from template
    • Prime  Full-text search on all paid plans
      Prime  Full-text search on all paid plans
      Search anywhere and reach everything in a Workspace with Prime plan.
      Got it
      • Sharing Link copied
      • /edit
      • View mode
        • Edit mode
        • View mode
        • Book mode
        • Slide mode
        Edit mode View mode Book mode Slide mode
      • Note Permission
      • Read
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Write
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • More (Comment, Invitee)
      • Publishing
        Everyone on the web can find and read all notes of this public team.
        After the note is published, everyone on the web can find and read this note.
        See all published notes on profile page.
      • Commenting Enable
        Disabled Forbidden Owners Signed-in users Everyone
      • Permission
        • Forbidden
        • Owners
        • Signed-in users
        • Everyone
      • Invitee
      • No invitee
      • Options
      • Versions and GitHub Sync
      • Transfer ownership
      • Delete this note
      • Template
      • Save as template
      • Insert from template
      • Export
      • Dropbox
      • Google Drive
      • Gist
      • Import
      • Dropbox
      • Google Drive
      • Gist
      • Clipboard
      • Download
      • Markdown
      • HTML
      • Raw HTML
    Menu Sharing Create Help
    Create Create new note Create a note from template
    Menu
    Options
    Versions and GitHub Sync Transfer ownership Delete this note
    Export
    Dropbox Google Drive Gist
    Import
    Dropbox Google Drive Gist Clipboard
    Download
    Markdown HTML Raw HTML
    Back
    Sharing
    Sharing Link copied
    /edit
    View mode
    • Edit mode
    • View mode
    • Book mode
    • Slide mode
    Edit mode View mode Book mode Slide mode
    Note Permission
    Read
    Only me
    • Only me
    • Signed-in users
    • Everyone
    Only me Signed-in users Everyone
    Write
    Only me
    • Only me
    • Signed-in users
    • Everyone
    Only me Signed-in users Everyone
    More (Comment, Invitee)
    Publishing
    Everyone on the web can find and read all notes of this public team.
    After the note is published, everyone on the web can find and read this note.
    See all published notes on profile page.
    More (Comment, Invitee)
    Commenting Enable
    Disabled Forbidden Owners Signed-in users Everyone
    Permission
    Owners
    • Forbidden
    • Owners
    • Signed-in users
    • Everyone
    Invitee
    No invitee
       owned this note    owned this note      
    Published Linked with GitHub
    Like BookmarkBookmarked
    Subscribed
    • Any changes
      Be notified of any changes
    • Mention me
      Be notified of mention me
    • Unsubscribe
    Subscribe
    # The Optimistic Ethereum Specification Overview Optimistic Ethereum is an _EVM equivalent_, _optimistic rollup_ protocol designed to _scale Ethereum_ while remaining maximally compatible with existing Ethereum infrastructure. This document provides an overview of the protocol to provide context for the rest of the specification. ## Table of Contents 1. [Foundations](#foundations) 1. [Network Participants](#network-participants) 1. [User Transactions and The Sequencer](#user-transactions-and-the-sequencer) 1. [L2 Batches and Blocks](#l2-batches-and-blocks) 1. [L2 Block Properties](#l2-block-properties) 1. [L1 Components Overview](#l1-components-overview) - [Data Feeds](#data-feeds) - [Fraud Proof Manager](#fraud-proof-manager) ## Foundations ### What is Ethereum scalability? Ethereum's limited resources, specifically bandwidth, computation, and storage, constrain the number of transactions which can be processed on the network, leading to extremely high fees. Scaling Ethereum means increasing the number of useful transactions the Ethereum network can process, by increasing the supply of these limited resources. This also means the fees can be made much lower. You can [follow this link][rollup-scale] to learn more about how rollups help solve Ethereum scalability. [rollup-scale]: https://hackmd.io/@norswap/rollups ### What is Optimistic Rollup? [Optimistic rollup](https://vitalik.ca/general/2021/01/05/rollup.html) is a layer 2 scalability technique which increases the computation & storage capacity of Ethereum without sacrificing security or decentralization. Transaction data is submitted on-chain but executed off-chain. If there is an error in the off-chain execution, a fraud proof can be submitted on-chain to correct the error and protect user funds. In the same way you don't go to court unless there is a dispute, you don't execute transactions on on-chain unless there is an error. The rollup is *optimistic* because the execution results are assumed to be correct until a fraud proof proves them wrong. ### What is EVM Equivalence? [EVM Equivalence](https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306) is complete compliance with the state transition function described in the Ethereum yellow paper, the formal definition of the protocol. By conforming to the Ethereum standard across EVM equivalent rollups, smart contract developers can write once and deploy anywhere. ### 🎶 All together now 🎶 #### Optimistic Ethereum is an _EVM equivalent_, _optimistic rollup_ protocol designed to _scale Ethereum_. ## Network Participants There are three actors in Optimistic Ethereum: users, sequencers, and verifiers. <!-- ![Network Overview](./assets/network-participants-overview.svg) --> ![Network Overview](https://raw.githubusercontent.com/ethereum-optimism/optimistic-specs/main/assets/network-participants-overview.svg) ### Users At the heart of the network are users (us!). Users can: 1. Deposit or withdraw tokens by sending transactions to Ethereum mainnet. 2. Send transactions to the sequencer, to use EVM smart contracts on L2, or to send ETH to other L2 users. 3. View the status of transactions using block explorers provided by network verifiers. ### Sequencer As a first approximation, you can see the sequencer as the L2 block producer. It accrues user transactions into "batches" and submits these batches to contracts on L1 in order to make L2 blocks out of them (beware however, that there isn't a 1-1 mapping between batches and blocks). Unlike on L1, on L2 transactions can be confirmed before a full block (or even a full batch) is created! We are going to give a lot more detail about the operation of the sequencer in the rest of this document. ### Verifiers Verifiers monitor L1 for rollup data. They serve three purpose: 1. Serving rollup data to users; and 2. Verifying rollup integrity and disputing invalid assertions. 3. Propagate the L2 state among validators (\*) In order for the network to remain secure there must be at least one honest verifier who is able to verify the integrity of the rollup chain & serve blockchain data to users. (\*) It's important to note that a validator does not rely on this data to validate the rollup — only access to the L1 chain is required. However, getting the most recent L2 state allows validators to serve the state to users, and to pre-validate transactions that should soon be posted to L1. L2 state propagation uses the same mechanism as L1 state sync, but must additionally include a signature from the sequencer to ensure the legitimacy of the data. ## User Transactions and The Sequencer As a user, once you have [bridged] (\*) some ETH over to Optimistic Ethereum, you will probably interact with it though your wallet, such as Metamask. Add the network (chainID 10, [JSON-RPC] endpoint `https://mainnet.optimism.io/`) and you're good to go. (\*) L1 -> L2 deposits will be explained later. [bridged]: https://www.optimism.io/apps/bridges [JSON-RPC]: https://github.com/ethereum/execution-apis When you send a transaction, it is sent to the node called the sequencer. The sequencer will run verify your transaction, execute it if valid, and confirm it. This happens much faster than on Ethereum mainnet (around ~1s). There is currently a single sequencer operated by Optimism PBC. We expect future versions of this specification to introduce sequencer decentralization. However, despite the sequencer being decentralized, trust is not required. As we will see, the sequencer posts its results on Ethereum mainnet (henceforth: layer 1 or L1), where they can be permissionlessly challenged with a fraud proof. If the sequencer temporarily goes down, Optimism will remain live because users are able to submit L2 transactions on L1 (of course, this implies the loss of the increased throughput and lower fees). L2 transactions are identical to L1 transactions, except that they use the Optimistic L2 state instead of the L1 state. This includes account balances, deployed contracts and contract storage. ## L2 Batches and Blocks Optimistic Ethereum has blocks, however these work slightly differently from L1 blocks, which are mined by proof-of-work and will soon be decided by proof-of-stake. Optimistic Ethereum has two kind of blocks: 1. L2 deposit blocks 2. L2 sequencer blocks As it confirms transactions, the sequencer accumulates these transaction in a "batch". The transactions in such batches will become **_L2 sequencer block_** once posted to the Optimistic Ethereum contracts on L1. Please note that there is no simple mapping between batches and sequencer blocks: a batch may "contain" multiple blocks or even partial blocks. Batches are simply a means of grouping transactions together for submitting transactions to L1. The sequencer decides which L@ sequencer block a transaction belongs to, although this decision is constrained by the protocol. For instance, block numbers assigned to transactions increase monotonically. See the section [on the `NUMBER` opcode](#NUMBER) for more details. Just like batches, L1 blocks can contain multiple L2 blocks, or even partial blocks. They can also have received zero, one, or many batches from the sequencer. **_L2 deposit blocks_**, on the other hand, arise from L1 blocks. There is one L2 deposit block per L1 block. These deposit blocks are implicitly created by the sequencer whenever it posts a batch to a new L1 block. **TODO:** Implicitly? Needs a link to an explanation of how data feeds are materialized. L2 deposit blocks comprise two types of data: 1. L1 block properties, namely - block hash - block number - timestamp - base fee 2. L2 transactions submitted on L1 These L2 transactions that have been "enqueued" on L1 are called *deposits*. These transactions have two main uses: - Ensure that the rollup remains live even if the sequencer goes down or starts censoring L2 transactions. Consequently, funds can never remain stuck on the rollup. - Deposit ETH and ERC-20 tokens onto the rollup. This is achieved by sending the token to a contract which locks it, then submits a L2 transaction (on L1) instructing a L2 contract to mint an equivalent L2 token. The transaction records the address of the L1 contract that submitted it, and the L2 contract only allows minting if the transaction was submitted by an authorized L1 contract. Anybody can operate such a pair of contracts, but Optimism PBC operates the bridge for ETH and some blue chip tokens ([the gateway]). See also other [trusted bridge providers]. [the gateway]: https://gateway.optimism.io/ [trusted bridge providers]: https://www.optimism.io/apps/bridges ## L2 Block Properties Because Optimistic Ethereum is 100% EVM-equivalent, all EVM opcodes are available. However, because blocks work differently, the semantics of a few opcodes must be made precise, namely `TIMESTAMP`, `NUMBER`, `BLOCKHASH`, `BASEFEE`, `GASLIMIT` and `COINBASE`. #### `NUMBER` The sequencer numbers L2 blocks sequentially. If there were only sequencer blocks, this would be trivial. The fact that the sequencer must "insert" deposit blocks in the L2 block stream makes this a little bit more complicated. To "insert" a deposit block in the block stream, the sequencer *skips over it* by skipping a block number. For instance, if a batch contains a transaction whose assigned block number is `X`, followed by a transaction whose assigned block number is `X+2`, this indicates that: - The first transacton is the final transaction of the L2 sequencer block with number `X`. - The second transaction is the first transaction of the L2 sequencer block with number `X+2`. - There is a deposit block with number `X+1`, which is the oldest deposit block that hasn't yet been included in the L2 block stream. **TODO:** is this true? or does the sequencer signal the insertion point for deposit blocks more explicitly To see the kind of problem that can occur, consider the naive procedure where the smart contract handling new batches enforces that the batch "skips over" every deposit block associated with L1 blocks coming before `B`, and otherwise rejects the batch. There are a few issues with this. This protocol is both too strict and too loose. First, the procedure is too strict: the sequencer doesn't directly control which block the batch will be posted on. This makes it very easy for the batch to land on an L1 block whose parent was unknown to the sequencer. This could occur for a variety of reason, including poor network conditions and malicious L1 block withholding. This could lead to a lot of wasted batch submission transactions. Second, the procedure is not strict enough: under this protocol, the sequencer is allowed to infinitely postpone the inclusion of deposit blocks, as long as it also does not post a batch to L1. To solve these issues, we introduce for each L1 block a *sequencing window* of size `S > 1` during which the sequencer **must** include the deposit block. The *sequencing window* is also called the *sequencer block submission window* (for obvious reasons), but also the *force inclusion period*. This is because if the sequence fails to include the deposit block generated by the L1 block `B` within the sequencing window `[B+1, B+S]`, then validators will consider that deposit block to be forcefully included, and will assign it the block number `X+1` where `X` is the last known L2 block. It's interesting to consider what this last block `X` might be. It might be the highest-number L2 sequencer block for which a transaction was posted by the sequencer within the `[B,B+S]` L1 block range (not a typo, this is `S+1` sized range). However, it could also be another force-included deposit block. For instance, if the `[B,B+S-1]` L1 block range does not include the deposit block generated by the `B-1` L1 block (via a sequencer block skipping over it), then the previous L2 block `X` is the forcefully included deposit block for L1 block `B-1`. In any case, it is sufficient to look a the `[B,B+S]` L1 block range to determine the block number (and the execution result) of the deposit block generated by the L1 block `B`. Also note that the sequencer not submitting any batches during the sequencing window `[B,B+S]` is merely a special case of the force inclusion mechanism, which ensures that the L2 chain remains live, even if the sequencer goes down. Even if the sequencer could never go down, the force inclusion mechanism is required to prevent the sequencer from censoring L2 transactions, which can now be forcefully included via L1. If the sequencer violates these conditions, for instance if it keeps posting batches after the L1 block `B+S` without skipping a block number for the forced inclusion of the deposit block, then this is considered to be fraud, and can be proved as such via a [fraud proof]. [fraud proof]: TODO **TODO:** link fraud proof index page Finally, a bit of jargon. We call an *epoch* the sequence of L2 block starting with a deposit block and containing zero or more L2 sequencing block until the next deposit block, which marks the start of the next epoch. Epoch `E` is the epoch staring with the deposit block generated by the L1 block with number `E`. **TODO:** what do we pick as the actual sequencing window? #### `TIMESTAMP` The timestamp should be **approximately** equivalent to the time at which the block was "conceived". - For deposit blocks, this is the timestamp of the L1 block it belongs to. - For sequencer blocks, this is (approximately) the time at which the decided to assign newly received transactions to a new sequencer block **TODO:** I flat out made this up. How is it supposed to work? Optimistic Ethereum makes the following guarantees when it comes to block timestamps: - The timestamp of each block is higher or equal to that of the block that precedes it. **TODO:** is that so? #### `BLOCKHASH` **TODO:** how does this work? Obviously can't be a block hash because we run and confirm transactions before knowing all the transactions in the block (this section should mention this) #### `BASEFEE` **TODO** #### `GASLIMIT` **TODO:** numbers #### `COINBASE` **TODO:** address of the sequencer? ## L1 Components **TODO:** design ongoing Before digging further into the operation of the sequencer and the verifier, let's give an overview of the Optimistic Ethereum infrastructure on L1. ### Data Feeds First we have **data feeds**. Conceptually, a data feed is an append-only log of a certain kind of data. Smarts contracts may be used to help implement these feeds, but the only requirement is that they these feeds can be deterministically retrieved from the L1 state and L1 block data. **TODO:** The [overview] says "retrievable in a bounded number of steps" but I'm not sure if the precision is useful - what would a counter-example be? Also, as the L1 chain grows, the number of operations to retrieve a log entry naturally increases, so I'm not sure we can talk of bounds in the first place. The **deposit feed** logs all L2 transaction submitted on L1, as well as all L1->L2 deposits submitted on L1. The **sequencer feed** logs all L2 transactions which are submitted (in batches) by the sequencer to L1. These transactions are ordered, and have associated timestamp and block information. **TODO:** I added the part about block information, that's correct right? The **L2 block feed** logs all L2 blocks inputs. Block inputs comprise transactions submitted on L1 (with associated block information), as well as L1 block properties from deposit blocks, but excludes ["block header items"] such as the Merkle roots for the state, receipts, gas information, ... **TODO:** what's the relationship between the L2 block feed and the depsoit feed & sequencer feed? it just seems like an ordered merge of boths? ["block header items"]: https://github.com/norswap/nanoeth/blob/cdc9867ed553847f3b0b7787fd03f0ed091c6b7f/src/com/norswap/nanoeth/blocks/BlockHeader.java#L22-L156 **TODO:** I expanded the description compared to the [overview], confirm that it's right [overview]: https://github.com/ethereum-optimism/optimistic-specs/blob/main/overview.md #### Fraud Proof Manager **TODO:** I'm not a fan of the "L2 block oracle" term - what is it an oracle for? You'd never guess what it does given just the name. What about "Fraud proof manager" instead? The fraud proof manager has two responsibilities: 1. It records *proposals*, which are summarized outcomes of the execution of an L2 block — in particular, the Merkle root of the L2 state and the Merkle root of receipts (yellowpaper §4.3.1) resulting from the block's execution. 2. It *finalizes* L2 blocks after the dispute period (currently 7 days) has passed, after which the L2 blocks can no longer be challenged. **TODO:** things to add to the definition of "proposal"? The fraud proof manager has the following components: The **proposal manager** stores proposals submitted both by proposers (the sequencer and verifiers who wish to challenge another proposer's proposal). It also ensure that proposers are sufficiently bonded. Each proposer must lock up a bond that will be forfeit if their proposal is proved to be invalid by the operation of the fraud proof manager, in which case the bond will be given to the challenger. **TODO:** this will be fleshed out when explaining the dispute game, but it should be made clearer what can be challenged (i.e. not just the sequencer - a challenger can make a wrong challenge and forfeit its bond too) The **the k-section game manager** TODO - [Dispute game specification(https://statechannels.notion.site/Draft-dispute-game-specification-2eee37cd8cc943759405a9ef97885411) - [Dispute game contract](https://github.com/statechannels/dispute-game/blob/main/sol-prototype/dispute-manager.sol) **TODO:** decide k --------------------------------------------------------------------------------

    Import from clipboard

    Advanced permission required

    Your current role can only read. Ask the system administrator to acquire write and comment permission.

    This team is disabled

    Sorry, this team is disabled. You can't edit this note.

    This note is locked

    Sorry, only owner can edit this note.

    Reach the limit

    Sorry, you've reached the max length this note can be.
    Please reduce the content or divide it to more notes, thank you!

    Import from Gist

    Import from Snippet

    or

    Export to Snippet

    Are you sure?

    Do you really want to delete this note?
    All users will lost their connection.

    Create a note from template

    Create a note from template

    Oops...
    This template is not available.


    Upgrade

    All
    • All
    • Team
    No template found.

    Create custom template


    Upgrade

    Delete template

    Do you really want to delete this template?

    This page need refresh

    You have an incompatible client version.
    Refresh to update.
    New version available!
    See releases notes here
    Refresh to enjoy new features.
    Your user state has changed.
    Refresh to load new user state.

    Sign in

    Forgot password

    or

    By clicking below, you agree to our terms of service.

    Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox

    New to HackMD? Sign up

    Help

    • English
    • 中文
    • Français
    • Deutsch
    • 日本語
    • Español
    • Català
    • Ελληνικά
    • Português
    • italiano
    • Türkçe
    • Русский
    • Nederlands
    • hrvatski jezik
    • język polski
    • Українська
    • हिन्दी
    • svenska
    • Esperanto
    • dansk

    Documents

    Tutorials

    Book Mode Tutorial

    Slide Mode Tutorial

    YAML Metadata

    Contacts

    Facebook

    Twitter

    Feedback

    Send us email

    Resources

    Releases

    Pricing

    Blog

    Policy

    Terms

    Privacy

    Cheatsheet

    Syntax Example Reference
    # Header Header 基本排版
    - Unordered List
    • Unordered List
    1. Ordered List
    1. Ordered List
    - [ ] Todo List
    • Todo List
    > Blockquote
    Blockquote
    **Bold font** Bold font
    *Italics font* Italics font
    ~~Strikethrough~~ Strikethrough
    19^th^ 19th
    H~2~O H2O
    ++Inserted text++ Inserted text
    ==Marked text== Marked text
    [link text](https:// "title") Link
    ![image alt](https:// "title") Image
    `Code` Code 在筆記中貼入程式碼
    ```javascript
    var i = 0;
    ```
    var i = 0;
    :smile: :smile: Emoji list
    {%youtube youtube_id %} Externals
    $L^aT_eX$ LaTeX
    :::info
    This is a alert area.
    :::

    This is a alert area.

    Versions

    Versions and GitHub Sync

    Sign in to link this note to GitHub Learn more
    This note is not linked with GitHub Learn more
     
    Add badge Pull Push GitHub Link Settings
    Upgrade now

    Version named by    

    More Less
    • Edit
    • Delete

    Note content is identical to the latest version.
    Compare with
      Choose a version
      No search result
      Version not found

    Feedback

    Submission failed, please try again

    Thanks for your support.

    On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

    Please give us some advice and help us improve HackMD.

     

    Thanks for your feedback

    Remove version name

    Do you want to remove this version name and description?

    Transfer ownership

    Transfer to
      Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

        Link with GitHub

        Please authorize HackMD on GitHub

        Please sign in to GitHub and install the HackMD app on your GitHub repo. Learn more

         Sign in to GitHub

        HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.

        Push the note to GitHub Push to GitHub Pull a file from GitHub

          Authorize again
         

        Choose which file to push to

        Select repo
        Refresh Authorize more repos
        Select branch
        Select file
        Select branch
        Choose version(s) to push
        • Save a new version and push
        • Choose from existing versions
        Available push count

        Upgrade

        Pull from GitHub

         
        File from GitHub
        File from HackMD

        GitHub Link Settings

        File linked

        Linked by
        File path
        Last synced branch
        Available push count

        Upgrade

        Danger Zone

        Unlink
        You will no longer receive notification when GitHub file changes after unlink.

        Syncing

        Push failed

        Push successfully