Super World Computer
  • About Super World Computer
  • Core Concepts
    • Soul Gas Token
    • Inbox Contract
    • L2 Blob
    • web3://
    • L1 Header Hash History
  • Guides
    • App Developers
      • Receive tokens
      • Bridge tokens
      • EthStorage Usage Guide
    • Node Operators
      • Run an Ethereum node
      • Run a Super World Computer node
      • Run op-challenger
  • Network Reference
    • Contract addresses
    • RPC configurations
  • Fork Diff
    • op-node forkdiff
    • op-geth forkdiff
  • Others
    • Join our Discord
    • Whitepaper
Powered by GitBook
On this page
  • Motivation
  • How It Works
  1. Core Concepts

Inbox Contract

PreviousSoul Gas TokenNextL2 Blob

Last updated 6 months ago

Motivation

The batch inbox is currently an Externally Owned Account (EOA), which has both advantages and disadvantages:

Advantages:

  • Low submission gas cost due to the absence of onchain execution.

  • Verification logic is moved offchain to the derivation part, protected by a fault dispute game with a correct absolute prestate.

Disadvantage:

  • Onchain verification is not possible.

This specification aims to allow the batch inbox to be a contract, enabling customized batch submission conditions such as:

  • Requiring the batch transaction to be signed by a quorum of sequencers in a decentralized sequencing network; or

  • Mandating that the batch transaction call a BLOB storage contract (e.g., EthStorage) with a long-term storage fee, which is then distributed to data nodes that prove BLOB storage over time.

How It Works

The integration process consists of three primary components:

  1. The can now be set to either an Externally Owned Account (EOA) or a smart contract. When a contract is used, it assumes responsibility for verifying and enforcing batch submission conditions.

  2. Modification of the op-node derivation process: The op-node will be updated to exclude failed batch transactions during the derivation process. This change ensures that only successfully executed batch transactions are processed and included in the derived state.

  3. Modification of the op-batcher submission process: The op-batcher will be updated to for failed batch transactions. This modification ensures that the data contained in failed transactions will be resubmitted automatically.

    1. Most failures will be detected during the call. However, under certain race conditions, failures may occur after the transaction has been included in a block.

These modifications aim to enhance the security and efficiency of the batch submission and processing pipeline, allowing for more flexible and customizable conditions while maintaining the integrity of the derived state.

BatchInboxAddress
call recordFailedTx
EstimateGas