From 0a77a8e58db74b968833e9b34211ac0a3a1055e9 Mon Sep 17 00:00:00 2001 From: Pete Date: Fri, 4 Apr 2025 10:47:05 -0500 Subject: [PATCH 1/8] refactor of gentle-intro --- .../01-a-gentle-introduction.mdx | 90 +++++++++---------- 1 file changed, 43 insertions(+), 47 deletions(-) diff --git a/arbitrum-docs/how-arbitrum-works/01-a-gentle-introduction.mdx b/arbitrum-docs/how-arbitrum-works/01-a-gentle-introduction.mdx index 23451c879d..1591b28b51 100644 --- a/arbitrum-docs/how-arbitrum-works/01-a-gentle-introduction.mdx +++ b/arbitrum-docs/how-arbitrum-works/01-a-gentle-introduction.mdx @@ -8,6 +8,7 @@ content_type: get-started --- import ImageWithCaption from '@site/src/components/ImageCaptions/'; +import ImageZoom from '@site/src/components/ImageZoom'; :::info @@ -15,73 +16,68 @@ This page gives a high-level overview. It explains Blockchain can handle only about 20 to 40 transactions per second (TPS) for all users. Once it reaches this limit, users must compete for space to have their transactions included, increasing fees. +The following diagram provides a high-level system overview, showing how transactions and messages flow between Arbitrum and Ethereum. It illustrates the roles of the Sequencer, validator, State Transition Function (STF), bridging infrastructure, and proving mechanism. -Arbitrum Rollup solves this issue! Here's how it works: an Arbitrum Rollup Chain acts as a submodule within Ethereum. Unlike regular Ethereum transactions, we don't need Ethereum nodes to handle every Arbitrum transaction. Instead, Ethereum takes an ["innocent until proven guilty"](https://insights.deribit.com/market-research/making-sense-of-rollups-part-2-dispute-resolution-on-arbitrum-and-optimism/) stance with Arbitrum. Initially, the Parent chain assumes that actions on Arbitrum follow the rules. If there is a rule violation (like someone claiming, "Now I have all of your money"), that claim is challengeable on the parent chain. In this case, we can prove fraud, disregard the invalid claim, and penalize the guilty party. This ability to investigate and confirm fraud on the parent chain is Arbitrum's main feature and explains why it benefits from Ethereum's security. +The diagram is interactive –– you can click on each component to navigate to the corresponding section of the document and learn more about how that part of the system works. -### How do these fraud proofs work? - -People who help manage the Arbitrum chain on the parent chain are called validators. They make claims about the chain's state, dispute others' claims, and more. Most Arbitrum users are unlikely to run a validator, just as most Ethereum users do not operate their parent chain staking node. However, anyone can become a validator; you don't need special permission ([once the allowlist gets lifted](https://docs.arbitrum.foundation/state-of-progressive-decentralization)). You only need to run the [open source validator software](https://github.com/OffchainLabs/nitro) and stake Ether if required. - -The chain stays secure if there is at least one honest validator. It only takes one trustworthy fraud prover to catch many bad actors. These features make the system "Trustless." Users do not depend on any specific group to keep their funds safe. - -### Who does this fraud proofing? - -This step is where the "Rollup" part comes in. Arbitrum Rollup chains handle user transaction data by posting it directly on Ethereum. This setup means that as long as Ethereum is secure, anyone can see what happens on Arbitrum. They can also spot and prove any fraud that occurs. - -Validators are the nodes that help move the Arbitrum Chain state forward on the parent chain. They make claims about the chain's state and can dispute claims made by others. Most Arbitrum users are unlikely to want to run a validator, just as most Ethereum users typically don't run their parent chain staking nodes. However, anyone can become a validator. Once the allowlist gets removed, users only need to run the open-source validator software and stake Ether if they need to take action. - -The network stays secure if there is at least one honest validator, which means that just one trustworthy fraud prover can catch any number of bad actors. This setup makes the system "trustless"; users do not have to rely on any specific person to keep their funds safe. - -### The game + -It's not as complicated as it seems. If two validators disagree, only one is telling the truth. In the event of a dispute, the two validators engage in an interactive game, where they respond to each other in a call-and-response format. This process allows them to narrow their disagreement to a single computational step—something straightforward, like multiplying two numbers. This step executes on the parent chain, which shows which party is honest. For a more detailed explanation, see here. +## The transaction lifecycle: from submission to finalization +At the most basic level, an Arbitrum chain works like this: -Users only experience delays when they withdraw funds from Arbitrum back to Ethereum. When withdrawing directly from Arbitrum to Ethereum, users usually wait one week to receive their funds on the parent chain. However, users can skip this waiting period if they use a fast bridge application, often for a small fee. Other activities do not have this delay, like depositing funds from Ethereum to Arbitrum or using a decentralized application (dApp) on the Arbitrum chain. + -### How is it cheaper? +The original napkin drawing seems primitive, but the core idea remains true. Four big ideas make up the Arbitrum protocol: -Arbitrum helps lower user transaction costs by reducing the strain on the parent chain. The primary way it does this is by processing transactions in batches. A batch can contain several hundred child chain transactions and gets submitted as one parent chain transaction. This batching makes interacting with the parent chain cheaper since you save on overhead costs compared to submitting each transaction individually. +### Sequencing, followed by deterministic execution +When a user submits a transaction to Arbitrum, it first enters the Sequencer, which establishes a global ordering of transactions. -Additionally, Arbitrum posts transaction data on the parent chain in a compressed format. It only decompresses this data within the child chain environment, reducing the amount of information that needs storing on the parent chain. +Once ordered, transactions may interact with the parent chain via Arbitrum's canonical bridges. These interactions include moving funds or sending messages from Ethereum to Arbitrum. -### How does it all work together? +### Geth at the core +After transactions are sequenced, the Arbitrum State Transition Function (STF) consumes them, thereby computing the next state of the chain. The STF operates deterministically, ensuring all validators arrive at the same result when replaying the same input. -At the most basic level, an Arbitrum chain works like this: +### Separate execution from proving +At periodic intervals, validators take the resulting post-state and submit assertions (summarizing the executed state) to the parent chain. `ETH` bonds back these assertions, and other validators may challenge them in a fraud-proof dispute game. - +### Optimistic Rollup with interactive fraud proofs +Once an assertion passes the challenge window without being disputed, it becomes finalized. Only then can messages originating from the child chain be executed on the parent chain. These include `ETH` or token withdrawals, as well as arbitrary cross-chain messages. -Users and contracts put messages into the inbox. The chain reads the messages one at a time and processes each one. This processing updates the state of the chain and produces some outputs. -If you want an Arbitrum chain to process a transaction for you, you need to put that transaction into the chain's inbox. Then, the chain will see your transaction, execute it, and produce some outputs: a transaction receipt and any withdrawals that your transaction initiated. +## Document structure +We take the four big ideas and break them into six key parts, each corresponding to a critical phase (or big idea) in the Arbitrum system: -Execution is deterministic, meaning that the contents of its inbox uniquely determine the chain's behavior. Because of this, the result of your transaction is knowable as soon as it gets put in the inbox. Any Arbitrum node will be able to tell you the result. (And you can run an Arbitrum node yourself if you want.) +### [1. Sequencing, followed by deterministic execution](/how-arbitrum-works/02-transaction-lifecycle.mdx) +Describes how the Sequencer receives user transactions and posts them to Ethereum in batches. Arbitrum's STF then processes these transactions deterministically offchain. -All of the technical details in this document connect to this diagram. To get from this diagram to a complete description of Arbitrum, we'll need to answer questions like these: +### [2. The Sequencer and censorship resistance](/how-arbitrum-works/03-sequencer.mdx) +Explains how users are protected against censorship via the Delayed Inbox, allowing fallback transaction submission directly to the child chain for guaranteed inclusion. -- Who keeps track of the inbox, Chain state, and outputs? -- How does Arbitrum make sure that the chain state and outputs are correct? -- How can Ethereum users and contracts interact with Arbitrum? -- How does Arbitrum support Ethereum-compatible contracts and transactions? -- How are ETH and tokens transferred into and out of Arbitrum chains, and how are they managed while on the chain? -- How can I run my own Arbitrum node or validator? +### [3. Bridging from a parent chain to a child chain](/how-arbitrum-works/10-l1-to-l2-messaging.mdx) +This section covers the inbound messaging system, including retryables, token bridging via canonical contracts, and the mechanisms that allow Ethereum to communicate with Arbitrum. -### Nitro's Design: The Four Big Ideas +### [4. State Transition Function (STF)](/how-arbitrum-works/04-state-transition-function/01-stf-gentle-intro.mdx) +Unpacks the core state computation logic in Arbitrum –– how input messages become state updates, and how Arbitrum supports multiple execution languages like Solidity and Stylus. -The essence of Nitro and its key innovations lie in four big ideas. We'll list them here with a quick summary of each. We will unpack them in more detail in later sections. +### [5. Validation and proving](/how-arbitrum-works/05-validation-and-proving/01-validation-and-proving.mdx) +Describes how validators confirm chain correctness using assertions and fraud proofs. Includes bonding mechanics, challenge games, and the role of WAVM in proving execution. -**Big Idea: Sequencing, Followed by Deterministic Execution**: Nitro processes transactions with a two-phase strategy. First, the transactions get organized into a single-ordered sequence, and Nitro commits to that sequence. Then, the transactions get processed in that sequence by a deterministic State Transition Function. +### [6. Child to parent chain bridging](/how-arbitrum-works/11-l2-to-l1-messaging.mdx) +Explains outbound messaging from the child chain to the parent chain –– including `ETH` and token withdrawals, Merkle proofs, and the Outbox execution model. -**Big Idea: Geth at the Core**: Nitro supports Ethereum's data structures, formats, and virtual machine by compiling in the core code of the popular go-ethereum ("Geth") Ethereum node software. Using Geth as a library in this way ensures a very high degree of compatibility with Ethereum. -**Big Idea: Separate Execution from Proving**: Nitro takes the same source code and compiles it twice, once to native code for execution in a Nitro node, optimized for speed, and again to WASM for use in proving, optimized for portability and security. +## Bringing it all together +Each component of the Arbitrum system contributes to a secure, efficient, and trustless pipeline for transaction processing. From submission to sequencing, bridging, execution, validation, and withdrawal, Arbitrum ensures that every transaction is verifiable, censorship-resistant, and anchored in Ethereum's security. -**Big Idea: Optimistic Rollup with Interactive Fraud Proofs**: Nitro settles transactions to the parent Ethereum chain using an Optimistic Rollup protocol, including the interactive fraud proofs pioneered by Arbitrum. -Now that we have covered the foundational concepts, the big picture, and the four big ideas of Arbitrum Nitro, we will begin a journey following a transaction through the Arbitrum protocol. In the next section, the transaction lifecycle begins. +These articles connect each step, from low-level protocol internals to real-world application –– offering a complete picture of how Arbitrum works under the hood. \ No newline at end of file From 30dec4bc2b74583a312967609088139b1379e137 Mon Sep 17 00:00:00 2001 From: Pete Date: Fri, 4 Apr 2025 15:57:21 -0500 Subject: [PATCH 2/8] haw-gentle-intro-refactor --- .../01-a-gentle-introduction.mdx | 80 +++++++++++-------- 1 file changed, 48 insertions(+), 32 deletions(-) diff --git a/arbitrum-docs/how-arbitrum-works/01-a-gentle-introduction.mdx b/arbitrum-docs/how-arbitrum-works/01-a-gentle-introduction.mdx index 1591b28b51..b9dbae48e1 100644 --- a/arbitrum-docs/how-arbitrum-works/01-a-gentle-introduction.mdx +++ b/arbitrum-docs/how-arbitrum-works/01-a-gentle-introduction.mdx @@ -16,13 +16,14 @@ This page gives a high-level overview. It explains -## The transaction lifecycle: from submission to finalization +## The lifecycle of a transaction At the most basic level, an Arbitrum chain works like this: +- Users submit transactions +- The Sequencer determines a global order +- The State Transition Function (STF) processes these transactions deterministically +- Valdiators post assertions summarizing results to Ethereum +- The results become finalized if no one challenges the assertion within the dispute window +- Messages and funds can be bridged back to Ethereum upon finalization -The original napkin drawing seems primitive, but the core idea remains true. Four big ideas make up the Arbitrum protocol: +This documentation follows a transction from start to finish: -### Sequencing, followed by deterministic execution -When a user submits a transaction to Arbitrum, it first enters the Sequencer, which establishes a global ordering of transactions. +### [1. Sequencing, followed by determinstic execution](/how-arbitrum-works/02-transaction-lifecycle.mdx) +The user submits a transaction, which the Sequencer receives and orders. This ordering forms the basis of consistent state transitions across all nodes. +### [2. The Sequencer and censorship resistance](/how-arbitrum-works/03-sequencer.mdx) +Even if the Sequencer misbehaves or censors, users can bypass it using the parent chain’s Delayed Inbox. This bypass ensures liveness and permissionless access. -Once ordered, transactions may interact with the parent chain via Arbitrum's canonical bridges. These interactions include moving funds or sending messages from Ethereum to Arbitrum. +### [3. Bridging from a parent chain to a child chain](/how-arbitrum-works/10-l1-to-l2-messaging.mdx) +Transactions can move assets and messages from the parent chain (Ethereum) to the child chain (Arbitrum). This movement is facilitated via canonical bridge contracts and retryables, allowing future execution on the child chain. -### Geth at the core -After transactions are sequenced, the Arbitrum State Transition Function (STF) consumes them, thereby computing the next state of the chain. The STF operates deterministically, ensuring all validators arrive at the same result when replaying the same input. +### [4. State Transition Function (STF)](/how-arbitrum-works/04-state-transition-function/01-stf-gentle-intro.mdx) +The STF consumes transactions as inputs and computes outputs deterministically. It supports multiple languages (e.g., Solidity, Stylus) and compiles into execution/proving formats. -### Separate execution from proving -At periodic intervals, validators take the resulting post-state and submit assertions (summarizing the executed state) to the parent chain. `ETH` bonds back these assertions, and other validators may challenge them in a fraud-proof dispute game. +### [5. Validation and proving]()/how-arbitrum-works/05-validation-and-proving/01-validation-and-proving.mdx) +Validators periodically create assertions summarizing state updates and post them to Ethereum. These can be challenged in an interactive fraud-proof game if incorrect. If no challenge occurs, the assertion is confirmed. -### Optimistic Rollup with interactive fraud proofs -Once an assertion passes the challenge window without being disputed, it becomes finalized. Only then can messages originating from the child chain be executed on the parent chain. These include `ETH` or token withdrawals, as well as arbitrary cross-chain messages. +### [6. Child to parent chain bridging](/how-arbitrum-works/11-l2-to-l1-messaging.mdx) +Once finalized, withdrawals and outbound messages (e.g., ETH, tokens) are now executable on the parent chain via the Outbox system, where results flow back to the parent chain. -## Document structure -We take the four big ideas and break them into six key parts, each corresponding to a critical phase (or big idea) in the Arbitrum system: +## Why Arbitrum? +Ethereum is powerful but limited in scalability, supporting only 20 to 40 transactions per second for the entire network. Once at capacity, transaction fees spike as users compete for space. Arbitrum Rollup solves this by batching hundreds of transactions into a single update to Ethereum, compressing data, and leveraging off-chain execution to maximize efficiency. -### [1. Sequencing, followed by deterministic execution](/how-arbitrum-works/02-transaction-lifecycle.mdx) -Describes how the Sequencer receives user transactions and posts them to Ethereum in batches. Arbitrum's STF then processes these transactions deterministically offchain. +Ethereum doesn’t directly verify every transaction on Arbitrum. Instead, it assumes that transactions are valid unless fraud is proven — the essence of an Optimistic Rollup. If any invalid state transition occurs, validators can challenge it through interactive fraud proofs, and Ethereum enforces the correct. -### [2. The Sequencer and censorship resistance](/how-arbitrum-works/03-sequencer.mdx) -Explains how users are protected against censorship via the Delayed Inbox, allowing fallback transaction submission directly to the child chain for guaranteed inclusion. +### The Trust model and fraud proofing +Anyone can run a validator. Validators propose state assertions and challenge others in a call-and-response dispute game. This process narrows disagreements to a single computation step that executes on the parent chain, determining the honest party. -### [3. Bridging from a parent chain to a child chain](/how-arbitrum-works/10-l1-to-l2-messaging.mdx) -This section covers the inbound messaging system, including retryables, token bridging via canonical contracts, and the mechanisms that allow Ethereum to communicate with Arbitrum. +The system requires only one honest validator to maintain correctness. This makes the protocol trustless — where trust is not dependent on a single party, and dishonest participants are penalized economically. -### [4. State Transition Function (STF)](/how-arbitrum-works/04-state-transition-function/01-stf-gentle-intro.mdx) -Unpacks the core state computation logic in Arbitrum –– how input messages become state updates, and how Arbitrum supports multiple execution languages like Solidity and Stylus. +### Why it's cheaper +Arbitrum minimizes costs by: -### [5. Validation and proving](/how-arbitrum-works/05-validation-and-proving/01-validation-and-proving.mdx) -Describes how validators confirm chain correctness using assertions and fraud proofs. Includes bonding mechanics, challenge games, and the role of WAVM in proving execution. +- Batching transactions into single-parent chain posts. +- Compressing transaction data before posting to the parent chain. +- Deferring execution to the child chain nodes using deterministic state computation. -### [6. Child to parent chain bridging](/how-arbitrum-works/11-l2-to-l1-messaging.mdx) -Explains outbound messaging from the child chain to the parent chain –– including `ETH` and token withdrawals, Merkle proofs, and the Outbox execution model. +All this significantly reduces gas usage on the parent chain while maintaining transparency and verifiability. + +### The Four big ideas behind Nitro +The essence of Nitro and its key innovations lie in four big ideas. We'll list them here with a quick summary of each. We will unpack them in more detail in later sections. + +**Big Idea: Sequencing, Followed by Deterministic Execution**: Nitro processes transactions with a two-phase strategy. First, the transactions get organized into a single-ordered sequence, and Nitro commits to that sequence. Then, the transactions get processed in that sequence by a deterministic State Transition Function. + +**Big Idea: Geth at the Core**: Nitro supports Ethereum's data structures, formats, and virtual machine by compiling in the core code of the popular go-ethereum ("Geth") Ethereum node software. Using Geth as a library in this way ensures a very high degree of compatibility with Ethereum. +**Big Idea: Separate Execution from Proving**: Nitro takes the same source code and compiles it twice, once to native code for execution in a Nitro node, optimized for speed, and again to WASM for use in proving, optimized for portability and security. -## Bringing it all together -Each component of the Arbitrum system contributes to a secure, efficient, and trustless pipeline for transaction processing. From submission to sequencing, bridging, execution, validation, and withdrawal, Arbitrum ensures that every transaction is verifiable, censorship-resistant, and anchored in Ethereum's security. +**Big Idea: Optimistic Rollup with Interactive Fraud Proofs**: Nitro settles transactions to the parent Ethereum chain using an Optimistic Rollup protocol, including the interactive fraud proofs pioneered by Arbitrum. Now that we have covered the foundational concepts, the big picture, and the four big ideas of Arbitrum Nitro, we will begin a journey following a transaction through the Arbitrum protocol. In the next section, the transaction lifecycle begins. -These articles connect each step, from low-level protocol internals to real-world application –– offering a complete picture of how Arbitrum works under the hood. \ No newline at end of file +## What comes next? +The remainder of this document walks through each component in detail. If you want to know how a particular part works — token bridging, STF execution, validator staking, or fraud-proof games — just click into the relevant section from the diagram or navigate sequentially. We’ll trace every step in the lifecycle and explain how Arbitrum delivers secure, efficient scaling for Ethereum. From 8827e08a6c1e94954c88edb08f8629e48771c8d5 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 7 Apr 2025 09:15:11 -0500 Subject: [PATCH 3/8] final touches --- .../01-a-gentle-introduction.mdx | 78 ++++++++++--------- 1 file changed, 43 insertions(+), 35 deletions(-) diff --git a/arbitrum-docs/how-arbitrum-works/01-a-gentle-introduction.mdx b/arbitrum-docs/how-arbitrum-works/01-a-gentle-introduction.mdx index b9dbae48e1..a04e97ade6 100644 --- a/arbitrum-docs/how-arbitrum-works/01-a-gentle-introduction.mdx +++ b/arbitrum-docs/how-arbitrum-works/01-a-gentle-introduction.mdx @@ -10,20 +10,16 @@ content_type: get-started import ImageWithCaption from '@site/src/components/ImageCaptions/'; import ImageZoom from '@site/src/components/ImageZoom'; -:::info +Arbitrum is a scaling technology suite designed to enhance Ethereum by offering cheaper, faster transactions without sacrificing security. The core product, Arbitrum Rollup (i.e., Arbitrum Nitro), is an Optimistic Rollup protocol that processes transactions offchain and posts succinct proofs to Ethereum for verification. This approach allows users to interact with Web3 apps and deploy smart contracts just like on Ethereum but with significantly reduced fees and higher throughput. -This page gives a high-level overview. It explains Arbitrum, its purpose, and a brief "how it works." As you progress through the articles in this section, the content will get more technical and dive deeper into each component(s) and function(s) of the Arbitrum technology stack. +This documentation provides a comprehensive, end-to-end walkthrough of how Arbitrum works. It combines a high-level overview with a step-by-step technical explanation, following a transaction from the moment it's submitted all the way through execution, proving, and bridging. Each section corresponds to a core protocol component and collectively paints a full picture of how Arbitrum achieves scalability with Ethereum-grade trustlessness. -::: -Arbitrum is a scaling technology suite designed to enhance Ethereum by offering cheaper, faster transactions without sacrificing security. The core product, Arbitrum Rollup, is an Optimistic Rollup protocol that processes transactions offchain and posts succinct proofs to Ethereum for verification. This approach allows users to interact with Web3 apps and deploy smart contracts just like on Ethereum but with significantly reduced fees and higher throughput. - -This document provides a comprehensive, end-to-end walkthrough of how Arbitrum works. It combines a high-level overview with a step-by-step technical explanation, following a transaction from the moment it's submitted all the way through execution, proving, and bridging. Each section corresponds to a core protocol component and collectively paints a full picture of how Arbitrum achieves scalability with Ethereum-grade trustlessness. - -## Design overview +## Diagram overview The following diagram provides a clickable, high-level visualization of Arbitrum's architecture. It captures the key components and their interactions: sequencing, validation, execution, bridging, and proving. -The digram is interactive –– you can click on each part to view a more detailed scope of the relevant section of the document. +The diagram is interactive –– you can click on each part to view a more detailed scope of the relevant section of the document. + + ## The lifecycle of a transaction -At the most basic level, an Arbitrum chain works like this: +At the most basic level, an Arbitrum chain works like this: - Users submit transactions -- The Sequencer determines a global order -- The State Transition Function (STF) processes these transactions deterministically -- Valdiators post assertions summarizing results to Ethereum -- The results become finalized if no one challenges the assertion within the dispute window +- The Sequencer determines a global order +- The State Transition Function (STF) processes these transactions deterministically +- Validators post assertions summarizing results to Ethereum +- The results become finalized if no one challenges the assertion within the dispute window - Messages and funds can be bridged back to Ethereum upon finalization + -This documentation follows a transction from start to finish: -### [1. Sequencing, followed by determinstic execution](/how-arbitrum-works/02-transaction-lifecycle.mdx) -The user submits a transaction, which the Sequencer receives and orders. This ordering forms the basis of consistent state transitions across all nodes. +This documentation follows a transaction from start to finish: + +### [1. Sequencing, followed by deterministic execution](/how-arbitrum-works/02-transaction-lifecycle.mdx) +A user submits a transaction, which the Sequencer receives and orders. This ordering forms the basis of consistent state transitions across all nodes. + ### [2. The Sequencer and censorship resistance](/how-arbitrum-works/03-sequencer.mdx) -Even if the Sequencer misbehaves or censors, users can bypass it using the parent chain’s Delayed Inbox. This bypass ensures liveness and permissionless access. +Even if the Sequencer misbehaves or censors, users can bypass it using the Parent chain's Delayed Inbox. This bypass ensures liveness and permissionless access. ### [3. Bridging from a parent chain to a child chain](/how-arbitrum-works/10-l1-to-l2-messaging.mdx) -Transactions can move assets and messages from the parent chain (Ethereum) to the child chain (Arbitrum). This movement is facilitated via canonical bridge contracts and retryables, allowing future execution on the child chain. +Transactions can move assets and messages from the parent chain (Ethereum) to the Child chain (Arbitrum). This movement is facilitated via canonical Bridge contracts and retryables, allowing future execution on the child chain. ### [4. State Transition Function (STF)](/how-arbitrum-works/04-state-transition-function/01-stf-gentle-intro.mdx) -The STF consumes transactions as inputs and computes outputs deterministically. It supports multiple languages (e.g., Solidity, Stylus) and compiles into execution/proving formats. +The STF consumes transactions as inputs and computes outputs deterministically. It supports multiple languages (e.g., Solidity, Stylus) and compiles into execution/proving formats. ### [5. Validation and proving]()/how-arbitrum-works/05-validation-and-proving/01-validation-and-proving.mdx) -Validators periodically create assertions summarizing state updates and post them to Ethereum. These can be challenged in an interactive fraud-proof game if incorrect. If no challenge occurs, the assertion is confirmed. +Validators periodically create assertions summarizing state updates and post them to Ethereum. These can be challenged in an interactive fraud-proof game if incorrect. If no challenge occurs, the assertion is confirmed. ### [6. Child to parent chain bridging](/how-arbitrum-works/11-l2-to-l1-messaging.mdx) -Once finalized, withdrawals and outbound messages (e.g., ETH, tokens) are now executable on the parent chain via the Outbox system, where results flow back to the parent chain. +Once finalized, withdrawals and outbound messages (e.g., `ETH`, tokens) are now executable on the parent chain via the Outbox system, where results flow back to the parent chain. ## Why Arbitrum? -Ethereum is powerful but limited in scalability, supporting only 20 to 40 transactions per second for the entire network. Once at capacity, transaction fees spike as users compete for space. Arbitrum Rollup solves this by batching hundreds of transactions into a single update to Ethereum, compressing data, and leveraging off-chain execution to maximize efficiency. +Ethereum is powerful but limited in scalability, supporting only 20 to 40 transactions per second (TPS) for the entire network. Once at capacity, transaction fees spike as users compete for space. Arbitrum Rollup solves this by batching hundreds of transactions into a single update to Ethereum, compressing data, and leveraging offchain execution to maximize efficiency. -Ethereum doesn’t directly verify every transaction on Arbitrum. Instead, it assumes that transactions are valid unless fraud is proven — the essence of an Optimistic Rollup. If any invalid state transition occurs, validators can challenge it through interactive fraud proofs, and Ethereum enforces the correct. +Ethereum doesn't directly verify every transaction on Arbitrum. Instead, it assumes that transactions are valid unless fraud is proven –– the essence of an Optimistic Rollup. If any state transition occurs, validators can challenge it through interactive fraud proofs, and Ethereum enforces the correct state. ### The Trust model and fraud proofing -Anyone can run a validator. Validators propose state assertions and challenge others in a call-and-response dispute game. This process narrows disagreements to a single computation step that executes on the parent chain, determining the honest party. +Anyone can run a validator. Validators propose state assertions and challenge others in a call-and-response dispute game. This process narrows disagreements to a single computation step that executes on the parent chain, determining the honest party. + +The system requires only one honest validator to maintain correctness. This makes the protocol trustless –– where trust is not dependent on a single party, and dishonest participants are penalized economically. -The system requires only one honest validator to maintain correctness. This makes the protocol trustless — where trust is not dependent on a single party, and dishonest participants are penalized economically. ### Why it's cheaper Arbitrum minimizes costs by: - -- Batching transactions into single-parent chain posts. -- Compressing transaction data before posting to the parent chain. -- Deferring execution to the child chain nodes using deterministic state computation. +- Batching transactions into single-parent chain posts +- Compressing transaction data before posting to the parent chain +- Deferring execution to the child chain nodes using deterministic state computation All this significantly reduces gas usage on the parent chain while maintaining transparency and verifiability. + ### The Four big ideas behind Nitro The essence of Nitro and its key innovations lie in four big ideas. We'll list them here with a quick summary of each. We will unpack them in more detail in later sections. -**Big Idea: Sequencing, Followed by Deterministic Execution**: Nitro processes transactions with a two-phase strategy. First, the transactions get organized into a single-ordered sequence, and Nitro commits to that sequence. Then, the transactions get processed in that sequence by a deterministic State Transition Function. +#### Sequencing, followed by deterministic execution +Nitro processes transactions with a two-phase strategy. First, the transactions get organized into a single-ordered sequence, and Nitro commits to that sequence. Then, the transactions get processed in that sequence by a deterministic State Transition Function. + +#### Geth at the core +Nitro supports Ethereum's data structures, formats, and virtual machine by compiling in the core code of the popular go-ethereum (Geth) Ethereum node software. Using Geth as a library in this way ensures a very high degree of compatibility with Ethereum. + +#### Separate execution from proving +Nitro takes the same source code and compiles it twice, once to native code for execution in Nitro code, optimized for speed, and again to WASM for use in proving, optimized for portability and security. -**Big Idea: Geth at the Core**: Nitro supports Ethereum's data structures, formats, and virtual machine by compiling in the core code of the popular go-ethereum ("Geth") Ethereum node software. Using Geth as a library in this way ensures a very high degree of compatibility with Ethereum. +#### Optimistic Rollup with interactive fraud proofs +Nitro settles transactions to the parent Ethereum chain an Optimistic Rollup protocol, including the interactive fraud proofs pioneered by Arbitrum. -**Big Idea: Separate Execution from Proving**: Nitro takes the same source code and compiles it twice, once to native code for execution in a Nitro node, optimized for speed, and again to WASM for use in proving, optimized for portability and security. +Now that we have covered the foundational concepts, the big picture, and the four big ideas of Arbitrum Nitro, we will begin a journey following a transaction through the Arbitrum protocol. In the next section, the transaction lifecycle begins. -**Big Idea: Optimistic Rollup with Interactive Fraud Proofs**: Nitro settles transactions to the parent Ethereum chain using an Optimistic Rollup protocol, including the interactive fraud proofs pioneered by Arbitrum. Now that we have covered the foundational concepts, the big picture, and the four big ideas of Arbitrum Nitro, we will begin a journey following a transaction through the Arbitrum protocol. In the next section, the transaction lifecycle begins. ## What comes next? -The remainder of this document walks through each component in detail. If you want to know how a particular part works — token bridging, STF execution, validator staking, or fraud-proof games — just click into the relevant section from the diagram or navigate sequentially. We’ll trace every step in the lifecycle and explain how Arbitrum delivers secure, efficient scaling for Ethereum. +The remainder of this document walks through each component in detail. If you want to know how a particular part works –– token bridging, STF execution, validator staking, or fraud-proof games –– just click into the relevant section from the diagram or navigate sequentially. We'll trace every step in the lifecycle and explain how Arbitrum delivers secure, efficient scaling for Ethereum. \ No newline at end of file From aa6c43d7922954c4b237f304e0c7c91012abf10c Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 7 Apr 2025 09:17:58 -0500 Subject: [PATCH 4/8] new haw image, needs additional work to be interactive --- .../haw-transaction-lifecycle-interactive.svg | 861 ++++++++++++++++++ 1 file changed, 861 insertions(+) create mode 100644 website/static/img/haw-transaction-lifecycle-interactive.svg diff --git a/website/static/img/haw-transaction-lifecycle-interactive.svg b/website/static/img/haw-transaction-lifecycle-interactive.svg new file mode 100644 index 0000000000..1f6cb602ad --- /dev/null +++ b/website/static/img/haw-transaction-lifecycle-interactive.svg @@ -0,0 +1,861 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + From 7828552eb0ee1c3b61847015d0b695e545641d43 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 7 Apr 2025 12:44:21 -0500 Subject: [PATCH 5/8] updating soft finality -> settlement based on reminder from Ed --- .../how-arbitrum-works/03-sequencer.mdx | 26 +++++++++---------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/arbitrum-docs/how-arbitrum-works/03-sequencer.mdx b/arbitrum-docs/how-arbitrum-works/03-sequencer.mdx index a705a4db43..5d4dc282d4 100644 --- a/arbitrum-docs/how-arbitrum-works/03-sequencer.mdx +++ b/arbitrum-docs/how-arbitrum-works/03-sequencer.mdx @@ -48,19 +48,19 @@ The real-time feed represents the Sequencer's commitment to process transactions - **Receive Immediate Notifications**: Obtain instant information about newly sequenced transactions and their ordering. - **Process Transactions Promptly**: Utilize the sequenced transactions to update the state locally, enabling rapid application responses and user interactions. -- **Benefit from Soft Finality**: Gain provisional assurance about transaction acceptance and ordering before the parent chain reaches finality. +- **Benefit from Settlement**: Gain provisional assurance about transaction acceptance and ordering before the parent chain reaches finality. This mechanism is particularly valuable for applications requiring low latency and high throughput, such as decentralized exchanges or real-time gaming platforms. -### Soft Finality and Trust Model +### Settlement and Trust Model -"Soft finality" refers to the preliminary confirmation of transactions based on the Sequencer's real-time feed. Key aspects include: +Settlement (soft finality) refers to the preliminary confirmation of transactions based on the Sequencer's real-time feed. Key aspects include: - **Dependence on Sequencer Integrity**: The feed's accuracy and reliability depend on the Sequencer operating honestly and without significant downtime. - **Immediate User Feedback**: Users can act on transaction confirmations swiftly, improving the user experience. - **Eventual Consistency with the parent chain**: While the real-time feed provides quick updates, ultimate security, and finality are established once transactions are posted to and finalized on the parent chain. (See the **Finality** section for an in-depth discussion.) -Understanding this trust model is essential. While we expect the Sequencer to behave correctly, users and developers should know that soft finality depends on this assumption. In scenarios where absolute certainty is required, parties may wait for transactions to achieve finality on the parent chain. +Understanding this trust model is essential. While we expect the Sequencer to behave correctly, users and developers should know that settlement depends on this assumption. In scenarios where absolute certainty is required, parties may wait for transactions to achieve finality on the parent chain. ### Role of the Sequencer Feed in the Network @@ -75,7 +75,7 @@ The Sequencer Feed serves several vital functions within the Arbitrum ecosystem: While the Sequencer Feed offers significant advantages, consider the following: - **Reliance on Sequencer Availability**: The effectiveness of the real-time feed depends on the Sequencer's uptime and responsiveness. Network issues or Sequencer downtime can delay transaction visibility. -- **Provisional Nature of Soft Finality**: Until transactions reach finality on the parent chain, there is a small risk that the provisional ordering provided by the feed could change in exceptional circumstances. +- **Provisional Nature of Settlement**: Until transactions reach finality on the parent chain, there is a small risk that the provisional ordering provided by the feed could change in exceptional circumstances. - **Security Implications**: For high-stakes transactions where security is paramount (e.g., centralized exchange deposits and withdrawals), users may prefer to wait for the parent chain confirmation despite the longer latency. Developers and users should design their applications and interactions with these factors in mind, choosing the appropriate balance between speed and certainty based on their requirements. @@ -199,30 +199,30 @@ Finality in blockchain systems refers to the point at which a transaction become Arbitrum offers two levels of finality: -1. **Soft Finality**: Provided by the Sequencer's real-time feed, offering immediate but provisional transaction confirmations. +1. **Settlement**: Provided by the Sequencer's real-time feed, offering immediate but provisional transaction confirmations. 2. **Hard Finality**: Occurs when transactions are included in batches posted to and finalized on the parent chain, providing strong security assurances. This section explores the concepts of soft and hard finality, their implications, trust considerations, and guidance for utilizing them effectively within the Arbitrum network. -### Soft Finality +### Settlement (soft finality) -Soft finality refers to the preliminary confirmation of transactions based on the Sequencer's real-time feed. Key characteristics include: +Settlement refers to the preliminary confirmation of transactions based on the Sequencer's real-time feed. Key characteristics include: - **Immediate Confirmation**: Transactions are confirmed almost instantly as they are accepted and ordered by the Sequencer. - **Provisional Assurance**: The confirmations are provisional and rely on the Sequencer's integrity and availability. - **High Performance**: Enables applications to offer rapid responses and real-time interactions, enhancing user experience. -**Advantages of Soft Finality**: +**Advantages of Settlement**: - **Low Latency**: Users receive immediate feedback on transaction status. - **Optimized for Speed**: Ideal for applications where responsiveness is critical. - **Improved User Experience**: Reduces waiting times and uncertainty. -**Limitations of Soft Finality**: +**Limitations of Settlement**: - **Trust Dependency**: Relies on the Sequencer's honesty and ability to maintain uptime.. - **Potential for Reordering**: In rare cases, if the Sequencer acts maliciously or encounters issues, the provisional ordering could change. -- **Not Suitable for High-Value Transactions**: For transactions requiring strong security guarantees, soft finality may not suffice. +- **Not Suitable for High-Value Transactions**: For transactions requiring strong security guarantees, settlement may not suffice. ### Hard Finality @@ -247,7 +247,7 @@ Hard finality occurs when batched transactions get posted to the parent chain. K Understanding the trust assumptions associated with each level of finality is essential: -- **Soft Finality Trust Model**: +- **Settlement Trust Model**: - **Reliance on the Sequencer**: Users must trust that the Sequencer operates honestly, sequences transactions correctly, and remains available. - **Risk of Misbehavior**: If the Sequencer acts maliciously, it could reorder or censor certain transactions before they achieve hard finality. - **Hard Finality Trust Model**: @@ -258,7 +258,7 @@ Understanding the trust assumptions associated with each level of finality is es Developers and users should consider the appropriate level of finality based on their specific use cases: -- **When to Rely on Soft Finality**: +- **When to Rely on Settlement**: - **Low-Risk Transactions**: For transactions where the potential impact of reordering or delays is minimal. - **User Experience Priority**: Applications where responsiveness and immediacy enhance user engagement, such as gaming or social platforms. - **Frequent Transactions**: Scenarios involving a high volume of small transactions where waiting for hard finality is impractical. From 888bde71fe2b3d4ab22dc620ac7bcbbe275e6313 Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 7 Apr 2025 13:09:19 -0500 Subject: [PATCH 6/8] converted list to table where flow is better --- .../01-a-gentle-introduction.mdx | 41 +++++++++++++------ .../02-stf-inputs.mdx | 41 +++++-------------- 2 files changed, 39 insertions(+), 43 deletions(-) diff --git a/arbitrum-docs/how-arbitrum-works/01-a-gentle-introduction.mdx b/arbitrum-docs/how-arbitrum-works/01-a-gentle-introduction.mdx index a04e97ade6..73c247785b 100644 --- a/arbitrum-docs/how-arbitrum-works/01-a-gentle-introduction.mdx +++ b/arbitrum-docs/how-arbitrum-works/01-a-gentle-introduction.mdx @@ -10,26 +10,31 @@ content_type: get-started import ImageWithCaption from '@site/src/components/ImageCaptions/'; import ImageZoom from '@site/src/components/ImageZoom'; -Arbitrum is a scaling technology suite designed to enhance Ethereum by offering cheaper, faster transactions without sacrificing security. The core product, Arbitrum Rollup (i.e., Arbitrum Nitro), is an Optimistic Rollup protocol that processes transactions offchain and posts succinct proofs to Ethereum for verification. This approach allows users to interact with Web3 apps and deploy smart contracts just like on Ethereum but with significantly reduced fees and higher throughput. +Arbitrum is a scaling technology suite designed to enhance Ethereum +by offering cheaper, faster transactions without sacrificing security. The core product, Arbitrum Rollup +(i.e., Arbitrum Nitro), is an Optimistic Rollup protocol +that processes transactions offchain and posts succinct proofs to Ethereum for verification. This +approach allows users to interact with Web3 apps and deploy smart contracts just like on Ethereum +but with significantly reduced fees and higher throughput. This documentation provides a comprehensive, end-to-end walkthrough of how Arbitrum works. It combines a high-level overview with a step-by-step technical explanation, following a transaction from the moment it's submitted all the way through execution, proving, and bridging. Each section corresponds to a core protocol component and collectively paints a full picture of how Arbitrum achieves scalability with Ethereum-grade trustlessness. - ## Diagram overview + The following diagram provides a clickable, high-level visualization of Arbitrum's architecture. It captures the key components and their interactions: sequencing, validation, execution, bridging, and proving. The diagram is interactive –– you can click on each part to view a more detailed scope of the relevant section of the document. - - ## The lifecycle of a transaction + At the most basic level, an Arbitrum chain works like this: + - Users submit transactions - The Sequencer determines a global order - The State Transition Function (STF) processes these transactions deterministically @@ -37,71 +42,81 @@ At the most basic level, an Arbitrum cha - The results become finalized if no one challenges the assertion within the dispute window - Messages and funds can be bridged back to Ethereum upon finalization - - This documentation follows a transaction from start to finish: ### [1. Sequencing, followed by deterministic execution](/how-arbitrum-works/02-transaction-lifecycle.mdx) + A user submits a transaction, which the Sequencer receives and orders. This ordering forms the basis of consistent state transitions across all nodes. ### [2. The Sequencer and censorship resistance](/how-arbitrum-works/03-sequencer.mdx) + Even if the Sequencer misbehaves or censors, users can bypass it using the Parent chain's Delayed Inbox. This bypass ensures liveness and permissionless access. ### [3. Bridging from a parent chain to a child chain](/how-arbitrum-works/10-l1-to-l2-messaging.mdx) + Transactions can move assets and messages from the parent chain (Ethereum) to the Child chain (Arbitrum). This movement is facilitated via canonical Bridge contracts and retryables, allowing future execution on the child chain. ### [4. State Transition Function (STF)](/how-arbitrum-works/04-state-transition-function/01-stf-gentle-intro.mdx) + The STF consumes transactions as inputs and computes outputs deterministically. It supports multiple languages (e.g., Solidity, Stylus) and compiles into execution/proving formats. -### [5. Validation and proving]()/how-arbitrum-works/05-validation-and-proving/01-validation-and-proving.mdx) +### [5. Validation and proving](/how-arbitrum-works/05-validation-and-proving/01-validation-and-proving.mdx) + Validators periodically create assertions summarizing state updates and post them to Ethereum. These can be challenged in an interactive fraud-proof game if incorrect. If no challenge occurs, the assertion is confirmed. ### [6. Child to parent chain bridging](/how-arbitrum-works/11-l2-to-l1-messaging.mdx) -Once finalized, withdrawals and outbound messages (e.g., `ETH`, tokens) are now executable on the parent chain via the Outbox system, where results flow back to the parent chain. +Once finalized, withdrawals and outbound messages (e.g., `ETH`, tokens) are now executable on the parent chain via the Outbox system, where results flow back to the parent chain. ## Why Arbitrum? + Ethereum is powerful but limited in scalability, supporting only 20 to 40 transactions per second (TPS) for the entire network. Once at capacity, transaction fees spike as users compete for space. Arbitrum Rollup solves this by batching hundreds of transactions into a single update to Ethereum, compressing data, and leveraging offchain execution to maximize efficiency. Ethereum doesn't directly verify every transaction on Arbitrum. Instead, it assumes that transactions are valid unless fraud is proven –– the essence of an Optimistic Rollup. If any state transition occurs, validators can challenge it through interactive fraud proofs, and Ethereum enforces the correct state. ### The Trust model and fraud proofing + Anyone can run a validator. Validators propose state assertions and challenge others in a call-and-response dispute game. This process narrows disagreements to a single computation step that executes on the parent chain, determining the honest party. The system requires only one honest validator to maintain correctness. This makes the protocol trustless –– where trust is not dependent on a single party, and dishonest participants are penalized economically. - ### Why it's cheaper + Arbitrum minimizes costs by: + - Batching transactions into single-parent chain posts - Compressing transaction data before posting to the parent chain - Deferring execution to the child chain nodes using deterministic state computation All this significantly reduces gas usage on the parent chain while maintaining transparency and verifiability. - ### The Four big ideas behind Nitro + The essence of Nitro and its key innovations lie in four big ideas. We'll list them here with a quick summary of each. We will unpack them in more detail in later sections. #### Sequencing, followed by deterministic execution + Nitro processes transactions with a two-phase strategy. First, the transactions get organized into a single-ordered sequence, and Nitro commits to that sequence. Then, the transactions get processed in that sequence by a deterministic State Transition Function. #### Geth at the core + Nitro supports Ethereum's data structures, formats, and virtual machine by compiling in the core code of the popular go-ethereum (Geth) Ethereum node software. Using Geth as a library in this way ensures a very high degree of compatibility with Ethereum. #### Separate execution from proving + Nitro takes the same source code and compiles it twice, once to native code for execution in Nitro code, optimized for speed, and again to WASM for use in proving, optimized for portability and security. #### Optimistic Rollup with interactive fraud proofs -Nitro settles transactions to the parent Ethereum chain an Optimistic Rollup protocol, including the interactive fraud proofs pioneered by Arbitrum. -Now that we have covered the foundational concepts, the big picture, and the four big ideas of Arbitrum Nitro, we will begin a journey following a transaction through the Arbitrum protocol. In the next section, the transaction lifecycle begins. +Nitro settles transactions to the parent Ethereum chain an Optimistic Rollup protocol, including the interactive fraud proofs pioneered by Arbitrum. +Now that we have covered the foundational concepts, the big picture, and the four big ideas of Arbitrum Nitro, we will begin a journey following a transaction through the Arbitrum protocol. In the next section, the transaction lifecycle begins. ## What comes next? -The remainder of this document walks through each component in detail. If you want to know how a particular part works –– token bridging, STF execution, validator staking, or fraud-proof games –– just click into the relevant section from the diagram or navigate sequentially. We'll trace every step in the lifecycle and explain how Arbitrum delivers secure, efficient scaling for Ethereum. \ No newline at end of file + +The remainder of this document walks through each component in detail. If you want to know how a particular part works –– token bridging, STF execution, validator staking, or fraud-proof games –– just click into the relevant section from the diagram or navigate sequentially. We'll trace every step in the lifecycle and explain how Arbitrum delivers secure, efficient scaling for Ethereum. diff --git a/arbitrum-docs/how-arbitrum-works/04-state-transition-function/02-stf-inputs.mdx b/arbitrum-docs/how-arbitrum-works/04-state-transition-function/02-stf-inputs.mdx index 02c2696ee7..cbfc72d514 100644 --- a/arbitrum-docs/how-arbitrum-works/04-state-transition-function/02-stf-inputs.mdx +++ b/arbitrum-docs/how-arbitrum-works/04-state-transition-function/02-stf-inputs.mdx @@ -34,35 +34,16 @@ In the system, we refer to these messages as `L1IncomingMessage` [source code re When submitted to the Sequencer feed, messages are tagged with a unique identifier, ensuring Arbitrum nodes correctly differentiate and process them. Below is the list of message types, their associated constant values, and descriptions: -```solidity -uint8 constant L2_MSG = 3; -uint8 constant L1MessageType_L2FundedByL1 = 7; -uint8 constant L1MessageType_submitRetryableTx = 9; -uint8 constant L1MessageType_ethDeposit = 12; -uint8 constant L1MessageType_batchPostingReport = 13; -uint8 constant L2MessageType_unsignedEOATx = 0; -uint8 constant L2MessageType_unsignedContractTx = 1; - -uint8 constant ROLLUP_PROTOCOL_EVENT_TYPE = 8; -uint8 constant INITIALIZATION_MSG_TYPE = 11; -``` - -- `L2_MSG` (3): Child chain messages submitted directly to the Sequencer. - -- `L1MessageType_L2FundedByL1` (7): Child chain messages that go to the parent chain's Delayed Inbox, with funding provided on the parent chain itself. - -- `L1MessageType_submitRetryableTx` (9): Submitting parent chain messages to the child chain via retryable tickets. - -- `L1MessageType_ethDeposit` (12): Child chain messages that handle deposits of native tokens (`ETH`) into the child chain. - -- `L1MessageType_batchPostingReport` (13): Used by the Sequencer to update the pricing model based on payment(s) by the batch poster. - -- `L2MessageType_unsignedEOATx` (0): Child chain messages submitted by externally owned accounts (EOAs) to the parent chain that does not include a signature. - -- `L2MessageType_unsignedContractTx` (1): Child chain messages submitted on the parent chain that does not include a signature. - -- `ROLLUP_PROTOCOL_EVENT_TYPE` (8): Arbitrum Classic used it for messages sent to bridge, Nitro does not use it. - -- `INITIALIZATION_MSG_TYPE` (11): The first message added to a new Rollup inbox. Its presence indicates proper initialization of the Rollup. +| Message Type | Constant Value | Description | +| ------------ | -------------- | ----------- | +| `L2_MSG` | `uint8 constant L2_MSG = 3;` | Child chain messages submitted directly to the Sequencer. | +| `L1MessageType_L2FundedByL1` | `uint8 constant L1MessageType_L2FundedByL1 = 7;` | Child chain messages that go to the parent chain's Delayed Inbox, with funding provided on the parent chain itself. | +| `L1MessageType_submitRetryableTx` | `uint8 constant L1MessageType_submitRetryableTx = 9;` | Submitting parent chain messages to the child chain via retryable tickets. | +| `L1MessageType_ethDeposit` | `uint8 constant L1MessageType_ethDeposit = 12;` | Child chain messages that handle deposits of native tokens (`ETH`) into the child chain. | +| `L1MessageType_batchPostingReport` | `uint8 constant L1MessageType_batchPostingReport = 13;` | Used by the Sequencer to update the pricing model based on payment(s) by the batch poster. | +| `L2MessageType_unsignedEOATx` | `uint8 constant L2MessageType_unsignedEOATx = 0;` | Child chain messages submitted by externally owned accounts (EOAs) to the parent chain that does not include a signature. | +| `L2MessageType_unsignedContractTx` | `uint8 constant L2MessageType_unsignedContractTx = 1;` | Child chain messages submitted on the parent chain that does not include a signature. | +| `ROLLUP_PROTOCOL_EVENT_TYPE` | `uint8 constant ROLLUP_PROTOCOL_EVENT_TYPE = 8;` | Arbitrum Classic used it for messages sent to bridge, Nitro does not use it. | +| `INITIALIZATION_MSG_TYPE` | `uint8 constant INITIALIZATION_MSG_TYPE = 11;` | The first message added to a new Rollup inbox. Its presence indicates proper initialization of the Rollup. | These tagged identifiers enable Arbitrum nodes to parse incoming messages and direct their payloads appropriately, ensuring smooth and reliable network operation. From f5079b660b5e3523ca879b8c4eda22bb6b6ca08e Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 8 Apr 2025 14:58:58 -0500 Subject: [PATCH 7/8] yarn format --- .../02-stf-inputs.mdx | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/arbitrum-docs/how-arbitrum-works/04-state-transition-function/02-stf-inputs.mdx b/arbitrum-docs/how-arbitrum-works/04-state-transition-function/02-stf-inputs.mdx index cbfc72d514..d9d94f8bae 100644 --- a/arbitrum-docs/how-arbitrum-works/04-state-transition-function/02-stf-inputs.mdx +++ b/arbitrum-docs/how-arbitrum-works/04-state-transition-function/02-stf-inputs.mdx @@ -34,16 +34,16 @@ In the system, we refer to these messages as `L1IncomingMessage` [source code re When submitted to the Sequencer feed, messages are tagged with a unique identifier, ensuring Arbitrum nodes correctly differentiate and process them. Below is the list of message types, their associated constant values, and descriptions: -| Message Type | Constant Value | Description | -| ------------ | -------------- | ----------- | -| `L2_MSG` | `uint8 constant L2_MSG = 3;` | Child chain messages submitted directly to the Sequencer. | -| `L1MessageType_L2FundedByL1` | `uint8 constant L1MessageType_L2FundedByL1 = 7;` | Child chain messages that go to the parent chain's Delayed Inbox, with funding provided on the parent chain itself. | -| `L1MessageType_submitRetryableTx` | `uint8 constant L1MessageType_submitRetryableTx = 9;` | Submitting parent chain messages to the child chain via retryable tickets. | -| `L1MessageType_ethDeposit` | `uint8 constant L1MessageType_ethDeposit = 12;` | Child chain messages that handle deposits of native tokens (`ETH`) into the child chain. | -| `L1MessageType_batchPostingReport` | `uint8 constant L1MessageType_batchPostingReport = 13;` | Used by the Sequencer to update the pricing model based on payment(s) by the batch poster. | -| `L2MessageType_unsignedEOATx` | `uint8 constant L2MessageType_unsignedEOATx = 0;` | Child chain messages submitted by externally owned accounts (EOAs) to the parent chain that does not include a signature. | -| `L2MessageType_unsignedContractTx` | `uint8 constant L2MessageType_unsignedContractTx = 1;` | Child chain messages submitted on the parent chain that does not include a signature. | -| `ROLLUP_PROTOCOL_EVENT_TYPE` | `uint8 constant ROLLUP_PROTOCOL_EVENT_TYPE = 8;` | Arbitrum Classic used it for messages sent to bridge, Nitro does not use it. | -| `INITIALIZATION_MSG_TYPE` | `uint8 constant INITIALIZATION_MSG_TYPE = 11;` | The first message added to a new Rollup inbox. Its presence indicates proper initialization of the Rollup. | +| Message Type | Constant Value | Description | +| ---------------------------------- | ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `L2_MSG` | `uint8 constant L2_MSG = 3;` | Child chain messages submitted directly to the Sequencer. | +| `L1MessageType_L2FundedByL1` | `uint8 constant L1MessageType_L2FundedByL1 = 7;` | Child chain messages that go to the parent chain's Delayed Inbox, with funding provided on the parent chain itself. | +| `L1MessageType_submitRetryableTx` | `uint8 constant L1MessageType_submitRetryableTx = 9;` | Submitting parent chain messages to the child chain via retryable tickets. | +| `L1MessageType_ethDeposit` | `uint8 constant L1MessageType_ethDeposit = 12;` | Child chain messages that handle deposits of native tokens (`ETH`) into the child chain. | +| `L1MessageType_batchPostingReport` | `uint8 constant L1MessageType_batchPostingReport = 13;` | Used by the Sequencer to update the pricing model based on payment(s) by the batch poster. | +| `L2MessageType_unsignedEOATx` | `uint8 constant L2MessageType_unsignedEOATx = 0;` | Child chain messages submitted by externally owned accounts (EOAs) to the parent chain that does not include a signature. | +| `L2MessageType_unsignedContractTx` | `uint8 constant L2MessageType_unsignedContractTx = 1;` | Child chain messages submitted on the parent chain that does not include a signature. | +| `ROLLUP_PROTOCOL_EVENT_TYPE` | `uint8 constant ROLLUP_PROTOCOL_EVENT_TYPE = 8;` | Arbitrum Classic used it for messages sent to bridge, Nitro does not use it. | +| `INITIALIZATION_MSG_TYPE` | `uint8 constant INITIALIZATION_MSG_TYPE = 11;` | The first message added to a new Rollup inbox. Its presence indicates proper initialization of the Rollup. | These tagged identifiers enable Arbitrum nodes to parse incoming messages and direct their payloads appropriately, ensuring smooth and reliable network operation. From d65eac9d829ce2287726286ac1adc6f3f4d72376 Mon Sep 17 00:00:00 2001 From: Pete Date: Fri, 11 Apr 2025 08:21:25 -0500 Subject: [PATCH 8/8] typo --- arbitrum-docs/how-arbitrum-works/10-l1-to-l2-messaging.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arbitrum-docs/how-arbitrum-works/10-l1-to-l2-messaging.mdx b/arbitrum-docs/how-arbitrum-works/10-l1-to-l2-messaging.mdx index c6a7164616..757156d702 100644 --- a/arbitrum-docs/how-arbitrum-works/10-l1-to-l2-messaging.mdx +++ b/arbitrum-docs/how-arbitrum-works/10-l1-to-l2-messaging.mdx @@ -233,7 +233,7 @@ You can find additional details on message types in the next section of this doc :::note -Please refer to the [Address aliasing](#address-aliasing) discussion for more background on address aliasing. This mechanism ensures that a parent chain contract can't impersonate a child chain address unless it provides a vlaid signature as an EOA. +Please refer to the [Address aliasing](#address-aliasing) discussion for more background on address aliasing. This mechanism ensures that a parent chain contract can't impersonate a child chain address unless it provides a valid signature as an EOA. :::