BOLD Smart Contracts Walkthrough

Summary

In this informative walkthrough, R Jordan, a staff software engineer at Offchain Labs, delves into the Arbitrum Bold smart contract suite. He explains that Arbitrum Bold, standing for Bounded Liquidity Delay Protocol, is a dispute system designed to ensure the security of Arbitrum chains. Jordan clarifies complex terms and discusses the protocol's robustness against delay attacks, guaranteeing a secure withdrawal process from Layer Two to Layer One. He explores the technical aspects, including the assertion chain, the Arbitrum inbox, and the dispute resolution process involving proofs of execution and the innovative use of history commitments. The presentation aims to demystify the Bold protocol and provide insights into its operation and benefits for the Arbitrum ecosystem.

Takeaways

• 😀 Arbitrum Bold is a new dispute system for Arbitrum chains, ensuring the security of the chain by allowing disputes over withdrawal claims.
• 🛡️ Bold is robust against delay attacks, which are common in naive protocols where a malicious party could delay withdrawals by continuously initiating disputes.
• 🔒 It guarantees an upper bound on the confirmation of challenges, ensuring that Layer Two to Layer One withdrawals are safe from invalid claims.
• ⏱️ The system works on an hourly basis where assertions about the execution of the Arbitrum inbox are posted to Ethereum, which can then be challenged.
• 📦 The Arbitrum inbox allows anyone to post Layer 2 data to a contract on Ethereum, which is crucial for the chain's state transition.
• 🔄 The Assertion Chain is a smart contract that contains a linked list data structure, recording claims about the execution of inbox messages with a 7-Day dispute window.
• 🔍 Disputes involve a binary search to narrow down the disagreement to a single block and then to a specific step within that block's execution.
• 🤖 Arbitrum uses an emulator of the state transition function, which uses web assembly op codes to execute step by step and create a unique hash of the emulator state at each step.
• 🌳 History commitments are used to represent the entire computation with a single Merkle root, allowing for efficient Merkle proofs of individual steps.
• 📈 The Bold dispute resolution involves multiple levels of granularity, starting from block level disagreements down to the individual steps of WebAssembly execution.
• 🕒 The timer inheritance mechanism is key in Bold, where edges inherit a timer from their children, allowing the accumulation of time to confirm the challenge branches by time once a sufficient period has passed.

Q & A

What does Arbitron Bold stand for and what is its primary function?

Arbitron Bold stands for Bounded Liquidity Delay protocol. It is a dispute system for Arbitrum chains designed to ensure the security of the chain by allowing for disputes over withdrawal claims, thus ensuring that as long as there are honest parties monitoring the state of withdrawals from Arbitrum, the Arbitrum bridge remains secure.

How does the Arbitrum Bold protocol protect against delay attacks?

Arbitrum Bold is robust against delay attacks by providing a guaranteed upper bound on the confirmation of challenges. This means that even if someone initiates a dispute over a withdrawal claim, the system ensures that the dispute process will not be indefinitely delayed, thus preventing the attacker from disrupting withdrawals for an extended period.

What is an 'assertion' in the context of the Arbitrum Bold protocol?

An 'assertion' in the Arbitrum Bold protocol refers to claims about the execution of the Arbitrum inbox that are posted to Ethereum every hour. These assertions are crucial as they can be challenged, and they form the basis for the dispute resolution process within the protocol.

Can you explain the role of the Arbitrum inbox?

The Arbitrum inbox is a system where anyone can post Layer 2 data to a contract on Ethereum. It allows for the posting of raw user transaction data, which is then used by Arbitrum to derive its state and chain. The inbox is essential for the operation of the Arbitrum rollup as it facilitates the posting of transaction data that needs to be executed.

What is the purpose of the assertion chain in the Arbitrum Bold protocol?

The assertion chain is a smart contract that contains a linked list data structure. It is used to post assertions about the execution of the inbox at regular intervals. Each assertion contains information about the execution and is linked to its parent assertion, ensuring a chain of claims that can be verified and challenged if necessary.

How does the dispute resolution process work in Arbitrum Bold?

The dispute resolution process in Arbitrum Bold involves parties providing proofs of execution when a dispute arises. Through a binary search approach, the disputing parties narrow down the disagreement to a single block and then to a specific step within that block. The process uses an emulator of the state transition function and a history commitment to represent the entire computation, allowing for efficient dispute resolution.

What is a 'fork' in the assertion chain and how does it relate to disputes?

A 'fork' in the assertion chain occurs when two assertions claim to be the next valid state after a given inbox message count but result in different block hashes. This indicates a disagreement over the execution result, which can trigger a dispute. The Bold protocol then facilitates a resolution process to determine the correct execution path.

How does the timer inheritance work in the context of confirming an edge by time?

Timer inheritance is a mechanism where an edge in the challenge tree inherits a timer from its children. If a bottommost edge accumulates a significant amount of time because it is unrivaled, this timer value propagates up the tree. Each edge along the path updates its inherited timer from its children, and once the topmost edge accumulates enough time, it can confirm the entire branch by time.

What are the steps involved in disputing an assertion in the Arbitrum Bold protocol?

To dispute an assertion, a party must create a layer zero Edge for the claimed assertion hash. After this, the opposing party must also create a rival Edge. Both parties then bisect their edges (BCT) to narrow down their disagreement. The process continues until a single step of disagreement is identified. Once the timer cache is sufficiently large, the honest party can confirm the entire challenge branch by time.

What is the significance of the 7-day dispute window in the assertion chain?

The 7-day dispute window is a sliding window that allows for assertions to be confirmed. Any assertion that falls below this window is considered confirmed. This mechanism ensures that the system progresses and does not get stuck on unchallenged assertions, providing a time-bound for disputes to be resolved.

How does the history commitment play a role in the Bold protocol?

The history commitment is a single Merkle root that represents the entire computation of executing a block through the emulator. It allows for powerful functionalities such as proving a single step of execution. It is critical for the Bold protocol as it ensures that all honest parties agree on one history, which is essential for resolving disputes efficiently.