Bond Incentives
+ + +Table of Contents
+-
+
- Overview +
- Moves +
- Subgame Resolution + + +
Overview
Bonds is an add-on to the core Fault Dispute Game. The core game mechanics are designed to ensure honesty as the best response to winning subgames. By introducing financial incentives, Bonds makes it worthwhile for honest challengers to participate. diff --git a/experimental/fault-proof/cannon-fault-proof-vm.html b/experimental/fault-proof/cannon-fault-proof-vm.html index 6c193be87..a50e43400 100644 --- a/experimental/fault-proof/cannon-fault-proof-vm.html +++ b/experimental/fault-proof/cannon-fault-proof-vm.html @@ -272,7 +272,7 @@
Heap
result of the syscall to locate free memory. The page size is 4096.The FPVM has a fixed program break at 0x40000000
. However, the FPVM is permitted to extend the
heap beyond this limit via mmap syscalls.
-For simplicity, there are no memory protections against "heap overruns" against other memory segments.
+For simplicity, there are no memory protections against "heap overruns" against other memory segments.
Such VM steps are still considered valid state transitions.
Specification of memory mappings is outside the scope of this document as it is irrelevant to the VM state. FPVM implementers may refer to the Linux/MIPS kernel for inspiration.
@@ -283,7 +283,7 @@Delay Slots
A VM state transition is invalid whenever the current instruction is a delay slot that is filled with jump or branch type instruction. That is, where while stepping on a jump/branch instruction. -Otherwise, there would be two consecutive delay slots. While this is considered "undefined" +Otherwise, there would be two consecutive delay slots. While this is considered "undefined" behavior in typical MIPS implementations, FPVM must raise an exception when stepping on such states.
Syscalls
Syscalls work similar to Linux/MIPS, including the diff --git a/experimental/fault-proof/fault-dispute-game.html b/experimental/fault-proof/fault-dispute-game.html index b95ca585d..5f3380f47 100644 --- a/experimental/fault-proof/fault-dispute-game.html +++ b/experimental/fault-proof/fault-dispute-game.html @@ -193,7 +193,7 @@
Fault D
GAME_DURATION
-Game Mechanics
+ Core Game Mechanics
Subgame
A sub-game is a DAG of depth 1, where the root of the DAG is a Claim
and the children are Claim
s that counter the
@@ -280,7 +280,7 @@
Game Tree
Position
A position represents the location of a claim in the Game Tree. This is represented by a
-"generalized index" (or gindex) where the high-order bit is the level in the tree and the remaining
+"generalized index" (or gindex) where the high-order bit is the level in the tree and the remaining
bits is a unique bit pattern, allowing a unique identifier for each node in the tree.
The gindex of a position can be calculated as , where:
@@ -422,7 +422,7 @@ FDG Responses
@@ -220,7 +221,7 @@ Root Claims
- Do Nothing if they agree with the root claim. They do nothing because if the root
claim is left un-countered, the game resolves to their agreement.
NOTE: The honest challenger will still track this game in order to defend any subsequent
-claims made against the root claim - in effect, "playing the game".
+claims made against the root claim - in effect, "playing the game".
Countering Invalid Claims
For every claim made in a dispute game with a game tree
diff --git a/experimental/fault-proof/index.html b/experimental/fault-proof/index.html
index 3540ff62c..fc8ad44f6 100644
--- a/experimental/fault-proof/index.html
+++ b/experimental/fault-proof/index.html
@@ -231,7 +231,7 @@
Overview
Each of these 3 components may have different implementations, which can be combined into different proof stacks,
and contribute to proof diversity when resolving a dispute.
-"Stateless execution" of the program, and its individual instructions, refers to reproducing
+
"Stateless execution" of the program, and its individual instructions, refers to reproducing
the exact same computation by authenticating the inputs with a Pre-image Oracle.
Pre-image Oracle
@@ -265,7 +265,7 @@
Type 3
: Global generic key
Reserved. This scheme allows for unlimited application-layer pre-image types without fault-proof VM redeployments.
This is a generic version of a global key store: key = 0x03 ++ keccak256(x, sender)[1:]
, where:
@@ -408,7 +408,7 @@ Prologue
dispute game interface, in the L1 history up and till the specified l1_head
.
The dispute
may be the claim itself, or a pointer to specific prior claimed data in L1,
depending on the dispute game interface.
-
Implied inputs are loaded in a "prologue" before the actual core state-transition function executes.
+
Implied inputs are loaded in a "prologue" before the actual core state-transition function executes.
During testing a simplified prologue that loads the overrides may be used.
Note: only the test-prologues are currently supported, since the dispute game interface is actively changing.
diff --git a/glossary.html b/glossary.html
index d392cbfe0..1a77be6f6 100644
--- a/glossary.html
+++ b/glossary.html
@@ -187,8 +187,8 @@ Glossary
EOA
Merkle Patricia Trie
Chain Re-Organization
-Predeployed Contract ("Predeploy")
-Preinstalled Contract ("Preinstall")
+Predeployed Contract ("Predeploy")
+Preinstalled Contract ("Preinstall")
Receipt
Transaction Type
Fork Choice Rule
@@ -291,7 +291,7 @@ Block
block, and output block properties, which are derived after executing the block's transactions. These include various
Merkle Patricia Trie roots that notably commit to the L2 state and to the log events emitted during execution.
EOA
-"Externally Owned Account", an Ethereum term to designate addresses operated by users, as opposed to contract addresses.
+"Externally Owned Account", an Ethereum term to designate addresses operated by users, as opposed to contract addresses.
Merkle Patricia Trie
A Merkle Patricia Trie (MPT) is a sparse trie, which is a tree-like structure that maps keys to values.
The root hash of a MPT is a commitment to the contents of the tree, which allows a
@@ -302,10 +302,10 @@
C
the fork choice rule) to a block that is not a child of the previous head.
L1 re-orgs can happen because of network conditions or attacks. L2 re-orgs are a consequence of L1 re-orgs, mediated via
L2 chain derivation.
-Predeployed Contract ("Predeploy")
+Predeployed Contract ("Predeploy")
A contract placed in the L2 genesis state (i.e. at the start of the chain).
All predeploy contracts are specified in the predeploys specification.
-Preinstalled Contract ("Preinstall")
+Preinstalled Contract ("Preinstall")
A contract placed in the L2 genesis state (i.e. at the start of the chain). These contracts do not share the same
security guarantees as predeploys, but are general use contracts made
available to improve the L2's UX.
@@ -363,9 +363,9 @@ L1 Origin
Deposits
In general, a deposit is an L2 transaction derived from an L1 block (by the rollup driver).
-While transaction deposits are notably (but not only) used to "deposit" (bridge) ETH and tokens to L2, the word
-deposit should be understood as "a transaction deposited to L2 from L1".
-This term deposit is somewhat ambiguous as these "transactions" exist at multiple levels. This section disambiguates
+
While transaction deposits are notably (but not only) used to "deposit" (bridge) ETH and tokens to L2, the word
+deposit should be understood as "a transaction deposited to L2 from L1".
+This term deposit is somewhat ambiguous as these "transactions" exist at multiple levels. This section disambiguates
all deposit-related terms.
Notably, a deposit can refer to:
@@ -423,7 +423,7 @@ Withdrawals
TODO expand this whole section to be clearer
In general, a withdrawal is a transaction sent from L2 to L1 that may transfer data and/or value.
-The term withdrawal is somewhat ambiguous as these "transactions" exist at multiple levels. In order to differentiate
+
The term withdrawal is somewhat ambiguous as these "transactions" exist at multiple levels. In order to differentiate
between the L1 and L2 components of a withdrawal we introduce the following terms:
- A withdrawal initiating transaction refers specifically to a transaction on L2 sent to the Withdrawals predeploy.
@@ -443,12 +443,12 @@ Final
Batch Submission
Data Availability
-Data availability is the guarantee that some data will be "available" (i.e. retrievable) during a reasonably long time
+
Data availability is the guarantee that some data will be "available" (i.e. retrievable) during a reasonably long time
window. In Optimism's case, the data in question are sequencer batches that validators
need in order to verify the sequencer's work and validate the L2 chain.
The finalization period should be taken as the lower bound on the availability window, since
that is when data availability is the most crucial, as it is needed to perform a fault proof.
-"Availability" does not mean guaranteed long-term storage of the data.
+"Availability" does not mean guaranteed long-term storage of the data.
Data Availability Provider
A data availability provider is a service that can be used to make data available. See the Data
Availability for more information on what this means.
@@ -556,7 +556,7 @@ L2 Genesis
- State inherited from the previous version of the L2 chain.
-- This state was possibly modified by "state surgeries". For instance, the migration to Bedrock entailed changes on
+
- This state was possibly modified by "state surgeries". For instance, the migration to Bedrock entailed changes on
how native ETH balances were stored in the storage trie.
@@ -610,7 +610,7 @@ Rollup Node
In sequencer mode, the rollup node receives L2 transactions from users, which it uses to create L2 blocks. These are
then submitted to a data availability provider via batch submission. The L2 chain
derivation then acts as a sanity check and a way to detect L1 chain re-orgs.
-In validator mode, the rollup node performs derivation as indicated above, but is also able to "run ahead" of the L1
+
In validator mode, the rollup node performs derivation as indicated above, but is also able to "run ahead" of the L1
chain by getting blocks directly from the sequencer, in which case derivation serves to validate the sequencer's
behaviour.
A rollup node running in validator mode is sometimes called a replica.
@@ -622,7 +622,7 @@ Rollup Driver
The rollup driver is the rollup node component responsible for deriving the L2 chain
from the L1 chain (L1 blocks and their associated receipts).
-TODO delete this entry, alongside its reference — can be replaced by "derivation process" or "derivation logic"
+
TODO delete this entry, alongside its reference — can be replaced by "derivation process" or "derivation logic"
where needed
L1 Attributes Predeployed Contract
@@ -647,7 +647,7 @@ Fault Proof
cf. Fault Proofs
Time Slot
On L2, there is a block every 2 second (this duration is known as the block time).
-We say that there is a "time slot" every multiple of 2s after the timestamp of the L2 genesis block.
+We say that there is a "time slot" every multiple of 2s after the timestamp of the L2 genesis block.
On L1, post-merge, the time slots are every 12s. However, an L1 block may not be produced for every time slot, in case
of even benign consensus issues.
Block Time
@@ -669,7 +669,7 @@ Execution E
engine (using transactions from the L1 mempool), at the request of the L1 consensus layer.
On L2, the executed blocks are freshly minted by the execution engine at the request of the rollup node,
using transactions derived from L1 blocks.
-In these specifications, "execution engine" always refer to the L2 execution engine, unless otherwise specified.
+In these specifications, "execution engine" always refer to the L2 execution engine, unless otherwise specified.
diff --git a/introduction.html b/introduction.html
index dc4df3686..bc8235fcf 100644
--- a/introduction.html
+++ b/introduction.html
@@ -273,7 +273,7 @@ Sequencers
The sequencer is the primary block producer.
There may be one sequencer or many using a consensus protocol.
For 1.0.0, there is just one sequencer (currently operated under the oversight of the Optimism Foundation).
-In general, specifications may use "the sequencer" to be a stand-in term
+In general, specifications may use "the sequencer" to be a stand-in term
for the consensus protocol operated by multiple sequencers.
The sequencer:
diff --git a/print.html b/print.html
index f85647c61..f205b7f58 100644
--- a/print.html
+++ b/print.html
@@ -353,7 +353,7 @@ Sequencers
The sequencer is the primary block producer.
There may be one sequencer or many using a consensus protocol.
For 1.0.0, there is just one sequencer (currently operated under the oversight of the Optimism Foundation).
-In general, specifications may use "the sequencer" to be a stand-in term
+In general, specifications may use "the sequencer" to be a stand-in term
for the consensus protocol operated by multiple sequencers.
The sequencer:
@@ -742,7 +742,7 @@ Message
into that field.
Message Version 0
abi.encodeWithSignature(
- "relayMessage(address,address,bytes,uint256)",
+ "relayMessage(address,address,bytes,uint256)",
_target,
_sender,
_message,
@@ -751,7 +751,7 @@ Message V
Message Version 1
abi.encodeWithSignature(
- "relayMessage(uint256,address,address,uint256,uint256,bytes)",
+ "relayMessage(uint256,address,address,uint256,uint256,bytes)",
_nonce,
_sender,
_target,
@@ -765,7 +765,7 @@ relayedMessages
mapping was removed.
It was built as a way to be able to fund third parties who relayed messages
on the behalf of users, but it was improperly implemented as it was impossible
to know if the relayed message actually succeeded.
@@ -1188,7 +1188,7 @@ Address Ali
0x1111000000000000000000000000000000001111
to it. The math is unchecked
and done on a
Solidity uint160
so the value will overflow. This prevents attacks in which a
contract on L1 has the same address as a contract on L2 but doesn't have the same code. We can safely ignore this
-for EOAs because they're guaranteed to have the same "code" (i.e. no code at all). This also makes
+for EOAs because they're guaranteed to have the same "code" (i.e. no code at all). This also makes
it possible for users to interact with contracts on L2 even when the Sequencer is down.
Deposit Contract Implementation: Optimism Portal
A reference implementation of the deposit contract can be found in OptimismPortal.sol.
@@ -1425,7 +1425,7 @@ Overview
initiated on L1. The gas that they use on L2 is bought on L1 via a gas burn (or a direct payment
in the future). We maintain a fee market and hard cap on the amount of gas provided to all deposits
in a single L1 block.
-The gas provided to deposited transactions is sometimes called "guaranteed gas". The gas provided to
+
The gas provided to deposited transactions is sometimes called "guaranteed gas". The gas provided to
deposited transactions is unique in the regard that it is not refundable. It cannot be refunded as
it is sometimes paid for with a gas burn and there may not be any ETH left to refund.
The guaranteed gas is composed of a gas stipend, and of any guaranteed gas the user would like
@@ -1567,7 +1567,7 @@
Overview
After processing one or more blocks the outputs will need to be synchronized with the settlement layer (L1)
for trustless execution of L2-to-L1 messaging, such as withdrawals.
These output proposals act as the bridge's view into the L2 state.
-Actors called "Proposers" submit the output roots to the settlement layer (L1) and can be contested with a fault proof,
+Actors called "Proposers" submit the output roots to the settlement layer (L1) and can be contested with a fault proof,
with a bond at stake if the proof is wrong. The op-proposer in one such implementation of a proposer.
Note: Fault proofs on Optimism are not fully specified at this time. Although fault proof
construction and verification is implemented in Cannon,
@@ -1899,7 +1899,7 @@
in user JSON-RPC.
Nodes may apply L2 blocks out of band ahead of time, and then reorg when L1 data conflicts.
safeBlockHash
: block hash of the canonical chain, derived from L1 data, unlikely to reorg.
finalizedBlockHash
: irreversible block hash, matches lower boundary of the dispute period.
@@ -2087,7 +2087,7 @@ Worst-case sy
Ecotone: disable Blob-transactions
EIP-4844 introduces Blob transactions: featuring all the functionality of an EIP-1559 transaction,
-plus a list of "blobs": "Binary Large Object", i.e. a dedicated data type for serving Data-Availability as base-layer.
+plus a list of "blobs": "Binary Large Object", i.e. a dedicated data type for serving Data-Availability as base-layer.
With the Ecotone upgrade, all Cancun L1 execution features are enabled, with EIP-4844 as exception:
as a L2, the OP-Stack does not serve blobs, and thus disables this new transaction type.
EIP-4844 is disabled as following:
@@ -2101,14 +2101,14 @@ Ecotone: Beacon Block Root
-EIP-4788 introduces a "beacon block root" into the execution-layer block-header and EVM.
+
EIP-4788 introduces a "beacon block root" into the execution-layer block-header and EVM.
This block root is an SSZ hash-tree-root of the consensus-layer contents of the previous consensus block.
With the adoption of EIP-4399 in the Bedrock upgrade the OP-Stack already includes the PREVRANDAO
of L1.
And thus with EIP-4788 the L1 beacon block root is made available.
For the Ecotone upgrade, this entails that:
- The
parent_beacon_block_root
of the L1 origin is now embedded in the L2 block header.
-- The "Beacon roots contract" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis.
+- The "Beacon roots contract" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis.
- The block state-transition process now includes the same special beacon-block-root EVM processing as L1 ethereum.
@@ -2307,7 +2307,7 @@ Overview
This also enables faster historical sync to be bootstrapped by providing block headers to sync towards,
and only having to compare the L2 chain inputs to the L1 data as compared to processing everything one block at a time.
The rollup node will always prioritize L1 and reorganize to match the canonical chain.
-The L2 data retrieved via the P2P interface is strictly a speculative extension, also known as the "unsafe" chain,
+The L2 data retrieved via the P2P interface is strictly a speculative extension, also known as the "unsafe" chain,
to improve the happy case performance.
This also means that P2P behavior is a soft-rule: nodes keep each other in check with scoring and eventual banning
of malicious peers by identity or IP. Any behavior on the P2P layer does not affect the rollup security, at worst nodes
@@ -2371,8 +2371,8 @@
NAT
Peer management
The default is to maintain a peer count with a tide-system based on active peer count:
-- At "low tide" the node starts to actively search for additional peer connections.
-- At "high tide" the node starts to prune active connections,
+
- At "low tide" the node starts to actively search for additional peer connections.
+- At "high tide" the node starts to prune active connections,
except those that are marked as trusted or have a grace period.
Peers will have a grace period for a configurable amount of time after joining.
@@ -2531,7 +2531,7 @@
Block proce
A node may apply the block to their local engine ahead of L1 availability, if it ensures that:
- The application of the block is reversible, in case of a conflict with delayed L1 information
-- The subsequent forkchoice-update ensures this block is recognized as "unsafe"
+
- The subsequent forkchoice-update ensures this block is recognized as "unsafe"
(see fork choice updated)
Block topic scoring parameters
@@ -2866,7 +2866,7 @@
@@ -2880,17 +2880,17 @@ L2 block derived from each batch. Note that we have a 1-1 batch to
block mapping here but, as we'll see later, empty blocks that do not map to batches can be inserted in cases where there
-are "gaps" in the batches posted on L1.
+are "gaps" in the batches posted on L1.
The fifth line shows the L1 attributes deposited transaction which, within each L2 block, records
information about the L1 block that matches the L2 block's epoch. The first number denotes the epoch/L1x number, while
-the second number (the "sequence number") denotes the position within the epoch.
+the second number (the "sequence number") denotes the position within the epoch.
Finally, the sixth line shows user-deposited transactions derived from the deposit
contract event mentioned earlier.
Note the 101-0
L1 attributes transaction on the bottom right of the diagram. Its presence there is only possible if
frame B2
indicates that it is the last frame within the channel and (2) no empty blocks must be inserted.
The diagram does not specify the sequencing window size in use, but from this we can infer that it must be at least 4
blocks, because the last frame of channel A
appears in block 102, but belong to epoch 99.
-As for the comment on "security types", it explains the classification of blocks as used on L1 and L2.
+As for the comment on "security types", it explains the classification of blocks as used on L1 and L2.
- Unsafe L2 blocks:
- Safe L2 blocks:
@@ -2944,14 +2944,14 @@ Channel Format<
where:
-batches
is the input, a sequence of batches byte-encoded as per the next section ("Batch Encoding")
+batches
is the input, a sequence of batches byte-encoded as per the next section ("Batch Encoding")
rlp_batches
is the concatenation of the RLP-encoded batches
compress
is a function performing compression, using the ZLIB algorithm (as specified in RFC-1950) with
no dictionary
channel_encoding
is the compressed version of rlp_batches
When decompressing a channel, we limit the amount of decompressed data to MAX_RLP_BYTES_PER_CHANNEL
(currently
-10,000,000 bytes), in order to avoid "zip-bomb" types of attack (where a small compressed input decompresses to a
+10,000,000 bytes), in order to avoid "zip-bomb" types of attack (where a small compressed input decompresses to a
humongous amount of data). If the decompressed data exceeds the limit, things proceeds as though the channel contained
only the first MAX_RLP_BYTES_PER_CHANNEL
decompressed bytes. The limit is set on RLP decoding, so all batches that
can be decoded in MAX_RLP_BYTES_PER_CHANNEL
will be accepted even if the size of the channel is greater than
@@ -3002,7 +3002,7 @@
This ensures that we use the data we already have before pulling more data and minimizes the latency of data traversing
the derivation pipeline.
@@ -3115,7 +3115,7 @@ Frame Queue
See Batcher transaction format and Frame format specifications.
Channel Bank
The Channel Bank stage is responsible for managing buffering from the channel bank that was written to by the L1
-retrieval stage. A step in the channel bank stage tries to read data from channels that are "ready".
+retrieval stage. A step in the channel bank stage tries to read data from channels that are "ready".
Channels are currently fully buffered until read or dropped,
streaming channels may be supported in a future version of the ChannelBank.
To bound resource usage, the Channel Bank prunes based on channel size, and times out old channels.
@@ -3295,7 +3295,7 @@ Engine QueueThe unsafe L2 head: blocks between the safe and unsafe heads are unsafe
blocks that have not been derived from L1. These blocks either come from sequencing (in sequencer
mode) or from unsafe sync to the sequencer (in validator mode).
-This is also known as the "latest" head.
+This is also known as the "latest" head.
Additionally, it buffers a short history of references to recently processed safe L2 blocks, along with references
from which L1 blocks each was derived.
@@ -3357,8 +3357,8 @@
+- A successful consolidation of unsafe L2 blocks: updating the "safe" L2 block.
- The first thing after a derivation pipeline reset, to ensure a consistent execution engine forkchoice state.
The new forkchoice state is applied by calling fork choice updated on the engine API.
@@ -3367,7 +3367,7 @@
consolidation is attempted, verifying that
existing unsafe L2 chain matches the derived L2 inputs as derived from the canonical L1 data.
During consolidation, we consider the oldest unsafe L2 block, i.e. the unsafe L2 block directly after the safe head. If
-the payload attributes match this oldest unsafe L2 block, then that block can be considered "safe" and becomes the new
+the payload attributes match this oldest unsafe L2 block, then that block can be considered "safe" and becomes the new
safe head.
The following fields of the derived L2 payload attributes are checked for equality with the L2 block:
@@ -3436,7 +3436,7 @@ Processing unsafe payload attributes
If no forkchoice updates or L1 data remain to be processed, and if the next possible L2 block is already available
through an unsafe source such as the sequencer publishing it via the p2p network, then it is optimistically processed as
-an "unsafe" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the
+an "unsafe" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the
user to see the head of the L2 chain faster than the L1 may confirm the L2 batches.
To process unsafe payloads, the payload must:
@@ -3562,7 +3562,7 @@
Deriving Payload Attributes
@@ -3629,20 +3629,20 @@ L1Block
gasLimit
: 375,000
data
: 0x60806040523480156100105...
(full bytecode)
sourceHash
: 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8
,
-computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Deployment"
+computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Deployment"
This results in the Ecotone L1Block contract being deployed to 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff
, to verify:
cast compute-address --nonce=0 0x4210000000000000000000000000000000000000
Computed Address: 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Deployment"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Deployment"))
# 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8
Verify data
:
git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932
pnpm clean && pnpm install && pnpm build
-jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json
+jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json
This transaction MUST deploy a contract with the following code hash
0xc88a313aa75dc4fbf0b6850d9f9ae41e04243b7008cf3eadb29256d4a71c1dfd
.
@@ -3658,7 +3658,7 @@ full bytecode)
sourceHash
: 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42
-computed with the "Upgrade-deposited" type, with `intent = "Ecotone: Gas Price Oracle Deployment"
+computed with the "Upgrade-deposited" type, with `intent = "Ecotone: Gas Price Oracle Deployment"
This results in the Ecotone GasPriceOracle contract being deployed to 0xb528D11cC114E026F138fE568744c6D45ce6Da7A
,
to verify:
@@ -3666,13 +3666,13 @@ ❯ cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Deployment"))
+❯ cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Deployment"))
# 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42
Verify data
:
git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932
pnpm clean && pnpm install && pnpm build
-jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json
+jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json
This transaction MUST deploy a contract with the following code hash
0x8b71360ea773b4cfaf1ae6d2bd15464a4e1e2e360f786e475f63aeaed8da0ae5
.
@@ -3687,14 +3687,14 @@ L1B
gasLimit
: 50,000
data
: 0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff
sourceHash
: 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc
-computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Proxy Update"
+computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Proxy Update"
Verify data:
-cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)
+cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)
0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Proxy Update"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Proxy Update"))
# 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc
GasPriceOracle Proxy Update
@@ -3709,14 +3709,14 @@ intent = "Ecotone: Gas Price Oracle Proxy Update"
Verify data:
-cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)
+cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)
0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Proxy Update"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Proxy Update"))
# 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a
GasPriceOracle Enable Ecotone
@@ -3730,18 +3730,18 @@
Verify data:
-cast sig "setEcotone()"
+cast sig "setEcotone()"
0x22b90ab3
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Set Ecotone"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Set Ecotone"))
# 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93
Beacon block roots contract deployment (EIP-4788)
-EIP-4788 introduces a "Beacon block roots" contract, that processes and exposes the beacon-block-root values.
+
EIP-4788 introduces a "Beacon block roots" contract, that processes and exposes the beacon-block-root values.
at address BEACON_ROOTS_ADDRESS = 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02
.
For deployment, EIP-4788 defines a pre-EIP-155 legacy transaction, sent from a key that is derived such that the
transaction signature validity is bound to message-hash, which is bound to the input-data, containing the init-code.
@@ -3763,7 +3763,7 @@ 0x60618060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604d57602036146024575f5ffd5b5f35801560495762001fff810690815414603c575f5ffd5b62001fff01545f5260205ff35b5f5ffd5b62001fff42064281555f359062001fff015500
isSystemTx
: false
, as per the Regolith upgrade, even the system-generated transactions spend gas.
sourceHash
: 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c
,
-computed with the "Upgrade-deposited" type, with intent = "Ecotone: beacon block roots contract deployment"
+computed with the "Upgrade-deposited" type, with intent = "Ecotone: beacon block roots contract deployment"
The contract address upon deployment is computed as rlp([sender, nonce])
, which will equal:
@@ -3776,7 +3776,7 @@
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: beacon block roots contract deployment"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: beacon block roots contract deployment"))
# 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c
Building Individual Payload Attributes
@@ -4230,7 +4230,7 @@ Batch Queue
Once validated, the batch-queue then emits a block-input for each of the blocks included in the span-batch.
The next derivation stage is thus only aware of individual block inputs, similar to the previous V0 batch,
-although not strictly a "v0 batch" anymore.
+although not strictly a "v0 batch" anymore.
Batcher
Instead of transforming L2 blocks into batches,
the blocks should be buffered to form a span-batch.
@@ -4832,7 +4832,7 @@ ERC-4
ERC-4337 SenderCreator
Address: 0x7fc98430eaedbb6070b35b39d798725049088348
-Helper contract for EntryPoint, to call userOp.initCode
from a "neutral" address,
+
Helper contract for EntryPoint, to call userOp.initCode
from a "neutral" address,
which is explicitly not EntryPoint
itself.
Superchain Configuration
@@ -5046,8 +5046,8 @@
+Recommended storage slot: bytes32(uint256(keccak256("protocolversion.recommended")) - 1)
Required getter: required()
returns ProtocolVersion
Recommended getter recommended()
returns ProtocolVersion
Version updates also emit a typed event:
@@ -5106,7 +5106,7 @@ Post-Bedrock Network upgrades
Regolith
-The Regolith upgrade, named after a material best described as "deposited dust on top of a layer of bedrock",
+
The Regolith upgrade, named after a material best described as "deposited dust on top of a layer of bedrock",
implements minor changes to deposit processing, based on reports of the Sherlock Audit-contest and findings in
the Bedrock Optimism Goerli testnet.
Summary of changes:
@@ -5304,11 +5304,11 @@ gasLimi
unsafeBlockSigner
(address
)
Blocks are gossiped around the p2p network before they are made available on L1.
To prevent denial of service on the p2p layer, these unsafe blocks must be
-signed with a particular key to be accepted as "canonical" unsafe blocks.
+signed with a particular key to be accepted as "canonical" unsafe blocks.
The address corresponding to this key is the unsafeBlockSigner
. To ensure
that its value can be fetched with a storage proof in a storage layout independent
manner, it is stored at a special storage slot corresponding to
-keccak256("systemconfig.unsafeblocksigner")
.
+keccak256("systemconfig.unsafeblocksigner")
.
Unlike the other values, the unsafeBlockSigner
only operates on blockchain
policy. It is not a consensus level parameter.
Writing the system config
@@ -5413,7 +5413,7 @@ Overview
Each of these 3 components may have different implementations, which can be combined into different proof stacks,
and contribute to proof diversity when resolving a dispute.
-"Stateless execution" of the program, and its individual instructions, refers to reproducing
+
"Stateless execution" of the program, and its individual instructions, refers to reproducing
the exact same computation by authenticating the inputs with a Pre-image Oracle.
Pre-image Oracle
@@ -5447,7 +5447,7 @@
Type 3
: Global generic key
Reserved. This scheme allows for unlimited application-layer pre-image types without fault-proof VM redeployments.
This is a generic version of a global key store: key = 0x03 ++ keccak256(x, sender)[1:]
, where:
@@ -5590,7 +5590,7 @@ Prologue
dispute game interface, in the L1 history up and till the specified l1_head
.
The dispute
may be the claim itself, or a pointer to specific prior claimed data in L1,
depending on the dispute game interface.
-
Implied inputs are loaded in a "prologue" before the actual core state-transition function executes.
+
Implied inputs are loaded in a "prologue" before the actual core state-transition function executes.
During testing a simplified prologue that loads the overrides may be used.
Note: only the test-prologues are currently supported, since the dispute game interface is actively changing.
@@ -5827,7 +5827,7 @@ Heap
result of the syscall to locate free memory. The page size is 4096.
The FPVM has a fixed program break at 0x40000000
. However, the FPVM is permitted to extend the
heap beyond this limit via mmap syscalls.
-For simplicity, there are no memory protections against "heap overruns" against other memory segments.
+For simplicity, there are no memory protections against "heap overruns" against other memory segments.
Such VM steps are still considered valid state transitions.
Specification of memory mappings is outside the scope of this document as it is irrelevant to
the VM state. FPVM implementers may refer to the Linux/MIPS kernel for inspiration.
@@ -5838,7 +5838,7 @@ Delay Slots
A VM state transition is invalid whenever the current instruction is a delay slot that is filled
with jump or branch type instruction.
That is, where while stepping on a jump/branch instruction.
-Otherwise, there would be two consecutive delay slots. While this is considered "undefined"
+Otherwise, there would be two consecutive delay slots. While this is considered "undefined"
behavior in typical MIPS implementations, FPVM must raise an exception when stepping on such states.
Syscalls
Syscalls work similar to Linux/MIPS, including the
@@ -6180,7 +6180,7 @@
Fault D
GAME_DURATION
-Game Mechanics
+ Core Game Mechanics
Subgame
A sub-game is a DAG of depth 1, where the root of the DAG is a Claim
and the children are Claim
s that counter the
@@ -6267,7 +6267,7 @@
Game Tree
Position
A position represents the location of a claim in the Game Tree. This is represented by a
-"generalized index" (or gindex) where the high-order bit is the level in the tree and the remaining
+"generalized index" (or gindex) where the high-order bit is the level in the tree and the remaining
bits is a unique bit pattern, allowing a unique identifier for each node in the tree.
The gindex of a position can be calculated as , where:
@@ -6409,7 +6409,7 @@ FDG Responses
@@ -6598,7 +6599,7 @@ Root Claims
- Do Nothing if they agree with the root claim. They do nothing because if the root
claim is left un-countered, the game resolves to their agreement.
NOTE: The honest challenger will still track this game in order to defend any subsequent
-claims made against the root claim - in effect, "playing the game".
+claims made against the root claim - in effect, "playing the game".
Countering Invalid Claims
For every claim made in a dispute game with a game tree
@@ -6712,6 +6713,20 @@
Resolution
challengers are economically incentivized to resolve the game promptly to capture the bonds.
Bond Incentives
+
+
+Table of Contents
+
+- Overview
+- Moves
+- Subgame Resolution
+
+
+
+
+Overview
Bonds is an add-on to the core Fault Dispute Game. The core game mechanics are
designed to ensure honesty as the best response to winning subgames. By introducing financial incentives,
Bonds makes it worthwhile for honest challengers to participate.
@@ -6759,8 +6774,8 @@
Glossary
- EOA
- Merkle Patricia Trie
- Chain Re-Organization
-- Predeployed Contract ("Predeploy")
-- Preinstalled Contract ("Preinstall")
+- Predeployed Contract ("Predeploy")
+- Preinstalled Contract ("Preinstall")
- Receipt
- Transaction Type
- Fork Choice Rule
@@ -6863,7 +6878,7 @@ Block
block, and output block properties, which are derived after executing the block's transactions. These include various
Merkle Patricia Trie roots that notably commit to the L2 state and to the log events emitted during execution.
EOA
-"Externally Owned Account", an Ethereum term to designate addresses operated by users, as opposed to contract addresses.
+"Externally Owned Account", an Ethereum term to designate addresses operated by users, as opposed to contract addresses.
Merkle Patricia Trie
A Merkle Patricia Trie (MPT) is a sparse trie, which is a tree-like structure that maps keys to values.
The root hash of a MPT is a commitment to the contents of the tree, which allows a
@@ -6874,10 +6889,10 @@
C
the fork choice rule) to a block that is not a child of the previous head.
L1 re-orgs can happen because of network conditions or attacks. L2 re-orgs are a consequence of L1 re-orgs, mediated via
L2 chain derivation.
-Predeployed Contract ("Predeploy")
+Predeployed Contract ("Predeploy")
A contract placed in the L2 genesis state (i.e. at the start of the chain).
All predeploy contracts are specified in the predeploys specification.
-Preinstalled Contract ("Preinstall")
+Preinstalled Contract ("Preinstall")
A contract placed in the L2 genesis state (i.e. at the start of the chain). These contracts do not share the same
security guarantees as predeploys, but are general use contracts made
available to improve the L2's UX.
@@ -6935,9 +6950,9 @@ L1 Origin
Deposits
In general, a deposit is an L2 transaction derived from an L1 block (by the rollup driver).
-While transaction deposits are notably (but not only) used to "deposit" (bridge) ETH and tokens to L2, the word
-deposit should be understood as "a transaction deposited to L2 from L1".
-This term deposit is somewhat ambiguous as these "transactions" exist at multiple levels. This section disambiguates
+
While transaction deposits are notably (but not only) used to "deposit" (bridge) ETH and tokens to L2, the word
+deposit should be understood as "a transaction deposited to L2 from L1".
+This term deposit is somewhat ambiguous as these "transactions" exist at multiple levels. This section disambiguates
all deposit-related terms.
Notably, a deposit can refer to:
@@ -6995,7 +7010,7 @@ Withdrawals
TODO expand this whole section to be clearer
In general, a withdrawal is a transaction sent from L2 to L1 that may transfer data and/or value.
-The term withdrawal is somewhat ambiguous as these "transactions" exist at multiple levels. In order to differentiate
+
The term withdrawal is somewhat ambiguous as these "transactions" exist at multiple levels. In order to differentiate
between the L1 and L2 components of a withdrawal we introduce the following terms:
- A withdrawal initiating transaction refers specifically to a transaction on L2 sent to the Withdrawals predeploy.
@@ -7015,12 +7030,12 @@ Final
Batch Submission
Data Availability
-Data availability is the guarantee that some data will be "available" (i.e. retrievable) during a reasonably long time
+
Data availability is the guarantee that some data will be "available" (i.e. retrievable) during a reasonably long time
window. In Optimism's case, the data in question are sequencer batches that validators
need in order to verify the sequencer's work and validate the L2 chain.
The finalization period should be taken as the lower bound on the availability window, since
that is when data availability is the most crucial, as it is needed to perform a fault proof.
-"Availability" does not mean guaranteed long-term storage of the data.
+"Availability" does not mean guaranteed long-term storage of the data.
Data Availability Provider
A data availability provider is a service that can be used to make data available. See the Data
Availability for more information on what this means.
@@ -7128,7 +7143,7 @@ L2 Genesis
- State inherited from the previous version of the L2 chain.
-- This state was possibly modified by "state surgeries". For instance, the migration to Bedrock entailed changes on
+
- This state was possibly modified by "state surgeries". For instance, the migration to Bedrock entailed changes on
how native ETH balances were stored in the storage trie.
@@ -7182,7 +7197,7 @@ Rollup Node
In sequencer mode, the rollup node receives L2 transactions from users, which it uses to create L2 blocks. These are
then submitted to a data availability provider via batch submission. The L2 chain
derivation then acts as a sanity check and a way to detect L1 chain re-orgs.
-In validator mode, the rollup node performs derivation as indicated above, but is also able to "run ahead" of the L1
+
In validator mode, the rollup node performs derivation as indicated above, but is also able to "run ahead" of the L1
chain by getting blocks directly from the sequencer, in which case derivation serves to validate the sequencer's
behaviour.
A rollup node running in validator mode is sometimes called a replica.
@@ -7194,7 +7209,7 @@ Rollup Driver
The rollup driver is the rollup node component responsible for deriving the L2 chain
from the L1 chain (L1 blocks and their associated receipts).
-TODO delete this entry, alongside its reference — can be replaced by "derivation process" or "derivation logic"
+
TODO delete this entry, alongside its reference — can be replaced by "derivation process" or "derivation logic"
where needed
L1 Attributes Predeployed Contract
@@ -7219,7 +7234,7 @@ Fault Proof
cf. Fault Proofs
Time Slot
On L2, there is a block every 2 second (this duration is known as the block time).
-We say that there is a "time slot" every multiple of 2s after the timestamp of the L2 genesis block.
+We say that there is a "time slot" every multiple of 2s after the timestamp of the L2 genesis block.
On L1, post-merge, the time slots are every 12s. However, an L1 block may not be produced for every time slot, in case
of even benign consensus issues.
Block Time
@@ -7241,7 +7256,7 @@ Execution E
engine (using transactions from the L1 mempool), at the request of the L1 consensus layer.
On L2, the executed blocks are freshly minted by the execution engine at the request of the rollup node,
using transactions derived from L1 blocks.
-In these specifications, "execution engine" always refer to the L2 execution engine, unless otherwise specified.
+In these specifications, "execution engine" always refer to the L2 execution engine, unless otherwise specified.
diff --git a/protocol/deposits.html b/protocol/deposits.html
index de6bf9f67..bf0f25136 100644
--- a/protocol/deposits.html
+++ b/protocol/deposits.html
@@ -592,7 +592,7 @@ Address Ali
0x1111000000000000000000000000000000001111
to it. The math is unchecked
and done on a
Solidity uint160
so the value will overflow. This prevents attacks in which a
contract on L1 has the same address as a contract on L2 but doesn't have the same code. We can safely ignore this
-for EOAs because they're guaranteed to have the same "code" (i.e. no code at all). This also makes
+for EOAs because they're guaranteed to have the same "code" (i.e. no code at all). This also makes
it possible for users to interact with contracts on L2 even when the Sequencer is down.
Deposit Contract Implementation: Optimism Portal
A reference implementation of the deposit contract can be found in OptimismPortal.sol.
diff --git a/protocol/derivation.html b/protocol/derivation.html
index f41f03364..f19389a21 100644
--- a/protocol/derivation.html
+++ b/protocol/derivation.html
@@ -423,7 +423,7 @@
@@ -437,17 +437,17 @@ L2 block derived from each batch. Note that we have a 1-1 batch to
block mapping here but, as we'll see later, empty blocks that do not map to batches can be inserted in cases where there
-are "gaps" in the batches posted on L1.
+are "gaps" in the batches posted on L1.
The fifth line shows the L1 attributes deposited transaction which, within each L2 block, records
information about the L1 block that matches the L2 block's epoch. The first number denotes the epoch/L1x number, while
-the second number (the "sequence number") denotes the position within the epoch.
+the second number (the "sequence number") denotes the position within the epoch.
Finally, the sixth line shows user-deposited transactions derived from the deposit
contract event mentioned earlier.
Note the 101-0
L1 attributes transaction on the bottom right of the diagram. Its presence there is only possible if
frame B2
indicates that it is the last frame within the channel and (2) no empty blocks must be inserted.
The diagram does not specify the sequencing window size in use, but from this we can infer that it must be at least 4
blocks, because the last frame of channel A
appears in block 102, but belong to epoch 99.
-As for the comment on "security types", it explains the classification of blocks as used on L1 and L2.
+As for the comment on "security types", it explains the classification of blocks as used on L1 and L2.
- Unsafe L2 blocks:
- Safe L2 blocks:
@@ -501,14 +501,14 @@ Channel Format<
where:
-batches
is the input, a sequence of batches byte-encoded as per the next section ("Batch Encoding")
+batches
is the input, a sequence of batches byte-encoded as per the next section ("Batch Encoding")
rlp_batches
is the concatenation of the RLP-encoded batches
compress
is a function performing compression, using the ZLIB algorithm (as specified in RFC-1950) with
no dictionary
channel_encoding
is the compressed version of rlp_batches
When decompressing a channel, we limit the amount of decompressed data to MAX_RLP_BYTES_PER_CHANNEL
(currently
-10,000,000 bytes), in order to avoid "zip-bomb" types of attack (where a small compressed input decompresses to a
+10,000,000 bytes), in order to avoid "zip-bomb" types of attack (where a small compressed input decompresses to a
humongous amount of data). If the decompressed data exceeds the limit, things proceeds as though the channel contained
only the first MAX_RLP_BYTES_PER_CHANNEL
decompressed bytes. The limit is set on RLP decoding, so all batches that
can be decoded in MAX_RLP_BYTES_PER_CHANNEL
will be accepted even if the size of the channel is greater than
@@ -559,7 +559,7 @@
This ensures that we use the data we already have before pulling more data and minimizes the latency of data traversing
the derivation pipeline.
@@ -672,7 +672,7 @@ Frame Queue
See Batcher transaction format and Frame format specifications.
Channel Bank
The Channel Bank stage is responsible for managing buffering from the channel bank that was written to by the L1
-retrieval stage. A step in the channel bank stage tries to read data from channels that are "ready".
+retrieval stage. A step in the channel bank stage tries to read data from channels that are "ready".
Channels are currently fully buffered until read or dropped,
streaming channels may be supported in a future version of the ChannelBank.
To bound resource usage, the Channel Bank prunes based on channel size, and times out old channels.
@@ -852,7 +852,7 @@ Engine QueueThe unsafe L2 head: blocks between the safe and unsafe heads are unsafe
blocks that have not been derived from L1. These blocks either come from sequencing (in sequencer
mode) or from unsafe sync to the sequencer (in validator mode).
-This is also known as the "latest" head.
+This is also known as the "latest" head.
Additionally, it buffers a short history of references to recently processed safe L2 blocks, along with references
from which L1 blocks each was derived.
@@ -914,8 +914,8 @@
+A successful consolidation of unsafe L2 blocks: updating the "safe" L2 block.
The first thing after a derivation pipeline reset, to ensure a consistent execution engine forkchoice state.
The new forkchoice state is applied by calling fork choice updated on the engine API.
@@ -924,7 +924,7 @@
consolidation is attempted, verifying that
existing unsafe L2 chain matches the derived L2 inputs as derived from the canonical L1 data.
During consolidation, we consider the oldest unsafe L2 block, i.e. the unsafe L2 block directly after the safe head. If
-the payload attributes match this oldest unsafe L2 block, then that block can be considered "safe" and becomes the new
+the payload attributes match this oldest unsafe L2 block, then that block can be considered "safe" and becomes the new
safe head.
The following fields of the derived L2 payload attributes are checked for equality with the L2 block:
@@ -993,7 +993,7 @@ Processing unsafe payload attributes
If no forkchoice updates or L1 data remain to be processed, and if the next possible L2 block is already available
through an unsafe source such as the sequencer publishing it via the p2p network, then it is optimistically processed as
-an "unsafe" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the
+an "unsafe" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the
user to see the head of the L2 chain faster than the L1 may confirm the L2 batches.
To process unsafe payloads, the payload must:
@@ -1119,7 +1119,7 @@
Deriving Payload Attributes
@@ -1186,20 +1186,20 @@ L1Block
gasLimit
: 375,000
data
: 0x60806040523480156100105...
(full bytecode)
sourceHash
: 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8
,
-computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Deployment"
+computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Deployment"
This results in the Ecotone L1Block contract being deployed to 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff
, to verify:
cast compute-address --nonce=0 0x4210000000000000000000000000000000000000
Computed Address: 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Deployment"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Deployment"))
# 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8
Verify data
:
git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932
pnpm clean && pnpm install && pnpm build
-jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json
+jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json
This transaction MUST deploy a contract with the following code hash
0xc88a313aa75dc4fbf0b6850d9f9ae41e04243b7008cf3eadb29256d4a71c1dfd
.
@@ -1215,7 +1215,7 @@ full bytecode)
sourceHash
: 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42
-computed with the "Upgrade-deposited" type, with `intent = "Ecotone: Gas Price Oracle Deployment"
+computed with the "Upgrade-deposited" type, with `intent = "Ecotone: Gas Price Oracle Deployment"
This results in the Ecotone GasPriceOracle contract being deployed to 0xb528D11cC114E026F138fE568744c6D45ce6Da7A
,
to verify:
@@ -1223,13 +1223,13 @@ ❯ cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Deployment"))
+❯ cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Deployment"))
# 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42
Verify data
:
git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932
pnpm clean && pnpm install && pnpm build
-jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json
+jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json
This transaction MUST deploy a contract with the following code hash
0x8b71360ea773b4cfaf1ae6d2bd15464a4e1e2e360f786e475f63aeaed8da0ae5
.
@@ -1244,14 +1244,14 @@ L1B
gasLimit
: 50,000
data
: 0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff
sourceHash
: 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc
-computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Proxy Update"
+computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Proxy Update"
Verify data:
-cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)
+cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)
0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Proxy Update"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Proxy Update"))
# 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc
GasPriceOracle Proxy Update
@@ -1266,14 +1266,14 @@ intent = "Ecotone: Gas Price Oracle Proxy Update"
Verify data:
-cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)
+cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)
0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Proxy Update"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Proxy Update"))
# 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a
GasPriceOracle Enable Ecotone
@@ -1287,18 +1287,18 @@
Verify data:
-cast sig "setEcotone()"
+cast sig "setEcotone()"
0x22b90ab3
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Set Ecotone"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Set Ecotone"))
# 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93
Beacon block roots contract deployment (EIP-4788)
-EIP-4788 introduces a "Beacon block roots" contract, that processes and exposes the beacon-block-root values.
+
EIP-4788 introduces a "Beacon block roots" contract, that processes and exposes the beacon-block-root values.
at address BEACON_ROOTS_ADDRESS = 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02
.
For deployment, EIP-4788 defines a pre-EIP-155 legacy transaction, sent from a key that is derived such that the
transaction signature validity is bound to message-hash, which is bound to the input-data, containing the init-code.
@@ -1320,7 +1320,7 @@ 0x60618060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604d57602036146024575f5ffd5b5f35801560495762001fff810690815414603c575f5ffd5b62001fff01545f5260205ff35b5f5ffd5b62001fff42064281555f359062001fff015500
isSystemTx
: false
, as per the Regolith upgrade, even the system-generated transactions spend gas.
sourceHash
: 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c
,
-computed with the "Upgrade-deposited" type, with intent = "Ecotone: beacon block roots contract deployment"
+computed with the "Upgrade-deposited" type, with intent = "Ecotone: beacon block roots contract deployment"
The contract address upon deployment is computed as rlp([sender, nonce])
, which will equal:
@@ -1333,7 +1333,7 @@
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: beacon block roots contract deployment"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: beacon block roots contract deployment"))
# 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c
Building Individual Payload Attributes
diff --git a/protocol/exec-engine.html b/protocol/exec-engine.html
index b6f4326cf..ea8d95ff5 100644
--- a/protocol/exec-engine.html
+++ b/protocol/exec-engine.html
@@ -376,7 +376,7 @@ in user JSON-RPC.
Nodes may apply L2 blocks out of band ahead of time, and then reorg when L1 data conflicts.
safeBlockHash
: block hash of the canonical chain, derived from L1 data, unlikely to reorg.
finalizedBlockHash
: irreversible block hash, matches lower boundary of the dispute period.
@@ -564,7 +564,7 @@ Worst-case sy
Ecotone: disable Blob-transactions
EIP-4844 introduces Blob transactions: featuring all the functionality of an EIP-1559 transaction,
-plus a list of "blobs": "Binary Large Object", i.e. a dedicated data type for serving Data-Availability as base-layer.
+plus a list of "blobs": "Binary Large Object", i.e. a dedicated data type for serving Data-Availability as base-layer.
With the Ecotone upgrade, all Cancun L1 execution features are enabled, with EIP-4844 as exception:
as a L2, the OP-Stack does not serve blobs, and thus disables this new transaction type.
EIP-4844 is disabled as following:
@@ -578,14 +578,14 @@ Ecotone: Beacon Block Root
-EIP-4788 introduces a "beacon block root" into the execution-layer block-header and EVM.
+
EIP-4788 introduces a "beacon block root" into the execution-layer block-header and EVM.
This block root is an SSZ hash-tree-root of the consensus-layer contents of the previous consensus block.
With the adoption of EIP-4399 in the Bedrock upgrade the OP-Stack already includes the PREVRANDAO
of L1.
And thus with EIP-4788 the L1 beacon block root is made available.
For the Ecotone upgrade, this entails that:
- The
parent_beacon_block_root
of the L1 origin is now embedded in the L2 block header.
-- The "Beacon roots contract" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis.
+- The "Beacon roots contract" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis.
- The block state-transition process now includes the same special beacon-block-root EVM processing as L1 ethereum.
diff --git a/protocol/guaranteed-gas-market.html b/protocol/guaranteed-gas-market.html
index 1f4aa469b..5c64833d8 100644
--- a/protocol/guaranteed-gas-market.html
+++ b/protocol/guaranteed-gas-market.html
@@ -192,7 +192,7 @@ Overview
initiated on L1. The gas that they use on L2 is bought on L1 via a gas burn (or a direct payment
in the future). We maintain a fee market and hard cap on the amount of gas provided to all deposits
in a single L1 block.
-The gas provided to deposited transactions is sometimes called "guaranteed gas". The gas provided to
+
The gas provided to deposited transactions is sometimes called "guaranteed gas". The gas provided to
deposited transactions is unique in the regard that it is not refundable. It cannot be refunded as
it is sometimes paid for with a gas burn and there may not be any ETH left to refund.
The guaranteed gas is composed of a gas stipend, and of any guaranteed gas the user would like
diff --git a/protocol/messengers.html b/protocol/messengers.html
index 49d41d278..7688be610 100644
--- a/protocol/messengers.html
+++ b/protocol/messengers.html
@@ -258,7 +258,7 @@
Message
into that field.
Message Version 0
abi.encodeWithSignature(
- "relayMessage(address,address,bytes,uint256)",
+ "relayMessage(address,address,bytes,uint256)",
_target,
_sender,
_message,
@@ -267,7 +267,7 @@ Message V
Message Version 1
abi.encodeWithSignature(
- "relayMessage(uint256,address,address,uint256,uint256,bytes)",
+ "relayMessage(uint256,address,address,uint256,uint256,bytes)",
_nonce,
_sender,
_target,
@@ -281,7 +281,7 @@ relayedMessages
mapping was removed.
It was built as a way to be able to fund third parties who relayed messages
on the behalf of users, but it was improperly implemented as it was impossible
to know if the relayed message actually succeeded.
diff --git a/protocol/preinstalls.html b/protocol/preinstalls.html
index 5163851b4..bdad01dea 100644
--- a/protocol/preinstalls.html
+++ b/protocol/preinstalls.html
@@ -275,7 +275,7 @@ ERC-4
ERC-4337 SenderCreator
Address: 0x7fc98430eaedbb6070b35b39d798725049088348
-Helper contract for EntryPoint, to call userOp.initCode
from a "neutral" address,
+
Helper contract for EntryPoint, to call userOp.initCode
from a "neutral" address,
which is explicitly not EntryPoint
itself.
Claim
and the children are Claim
s that counter the
@@ -280,7 +280,7 @@ FDG Responses
@@ -220,7 +221,7 @@ Root Claims
Countering Invalid Claims
For every claim made in a dispute game with a game tree diff --git a/experimental/fault-proof/index.html b/experimental/fault-proof/index.html index 3540ff62c..fc8ad44f6 100644 --- a/experimental/fault-proof/index.html +++ b/experimental/fault-proof/index.html @@ -231,7 +231,7 @@
Overview
Type 3
: Global generic key
Reserved. This scheme allows for unlimited application-layer pre-image types without fault-proof VM redeployments.
This is a generic version of a global key store: key = 0x03 ++ keccak256(x, sender)[1:]
, where:
Prologue
dispute game interface, in the L1 history up and till the specifiedl1_head
.
The dispute
may be the claim itself, or a pointer to specific prior claimed data in L1,
depending on the dispute game interface.
-Note: only the test-prologues are currently supported, since the dispute game interface is actively changing.
diff --git a/glossary.html b/glossary.html index d392cbfe0..1a77be6f6 100644 --- a/glossary.html +++ b/glossary.html @@ -187,8 +187,8 @@Glossary
Block
block, and output block properties, which are derived after executing the block's transactions. These include various Merkle Patricia Trie roots that notably commit to the L2 state and to the log events emitted during execution.EOA
-"Externally Owned Account", an Ethereum term to designate addresses operated by users, as opposed to contract addresses.
+"Externally Owned Account", an Ethereum term to designate addresses operated by users, as opposed to contract addresses.
Merkle Patricia Trie
A Merkle Patricia Trie (MPT) is a sparse trie, which is a tree-like structure that maps keys to values. The root hash of a MPT is a commitment to the contents of the tree, which allows a @@ -302,10 +302,10 @@
C the fork choice rule) to a block that is not a child of the previous head.
L1 re-orgs can happen because of network conditions or attacks. L2 re-orgs are a consequence of L1 re-orgs, mediated via L2 chain derivation.
-Predeployed Contract ("Predeploy")
+Predeployed Contract ("Predeploy")
A contract placed in the L2 genesis state (i.e. at the start of the chain).
All predeploy contracts are specified in the predeploys specification.
-Preinstalled Contract ("Preinstall")
+Preinstalled Contract ("Preinstall")
A contract placed in the L2 genesis state (i.e. at the start of the chain). These contracts do not share the same security guarantees as predeploys, but are general use contracts made available to improve the L2's UX.
@@ -363,9 +363,9 @@L1 Origin
Deposits
In general, a deposit is an L2 transaction derived from an L1 block (by the rollup driver).
-While transaction deposits are notably (but not only) used to "deposit" (bridge) ETH and tokens to L2, the word -deposit should be understood as "a transaction deposited to L2 from L1".
-This term deposit is somewhat ambiguous as these "transactions" exist at multiple levels. This section disambiguates +
While transaction deposits are notably (but not only) used to "deposit" (bridge) ETH and tokens to L2, the word +deposit should be understood as "a transaction deposited to L2 from L1".
+This term deposit is somewhat ambiguous as these "transactions" exist at multiple levels. This section disambiguates all deposit-related terms.
Notably, a deposit can refer to:
-
@@ -423,7 +423,7 @@
Withdrawals
TODO expand this whole section to be clearer
Final
Batch Submission
Data Availability
-Data availability is the guarantee that some data will be "available" (i.e. retrievable) during a reasonably long time
+
Data availability is the guarantee that some data will be "available" (i.e. retrievable) during a reasonably long time
window. In Optimism's case, the data in question are sequencer batches that validators
need in order to verify the sequencer's work and validate the L2 chain.
The finalization period should be taken as the lower bound on the availability window, since
that is when data availability is the most crucial, as it is needed to perform a fault proof.
-"Availability" does not mean guaranteed long-term storage of the data.
+"Availability" does not mean guaranteed long-term storage of the data.
Data Availability Provider
A data availability provider is a service that can be used to make data available. See the Data
Availability for more information on what this means.
@@ -556,7 +556,7 @@ L2 Genesis
- State inherited from the previous version of the L2 chain.
-- This state was possibly modified by "state surgeries". For instance, the migration to Bedrock entailed changes on
+
- This state was possibly modified by "state surgeries". For instance, the migration to Bedrock entailed changes on
how native ETH balances were stored in the storage trie.
@@ -610,7 +610,7 @@ Rollup Node
In sequencer mode, the rollup node receives L2 transactions from users, which it uses to create L2 blocks. These are
then submitted to a data availability provider via batch submission. The L2 chain
derivation then acts as a sanity check and a way to detect L1 chain re-orgs.
-In validator mode, the rollup node performs derivation as indicated above, but is also able to "run ahead" of the L1
+
In validator mode, the rollup node performs derivation as indicated above, but is also able to "run ahead" of the L1
chain by getting blocks directly from the sequencer, in which case derivation serves to validate the sequencer's
behaviour.
A rollup node running in validator mode is sometimes called a replica.
@@ -622,7 +622,7 @@ Rollup Driver
The rollup driver is the rollup node component responsible for deriving the L2 chain
from the L1 chain (L1 blocks and their associated receipts).
-TODO delete this entry, alongside its reference — can be replaced by "derivation process" or "derivation logic"
+
TODO delete this entry, alongside its reference — can be replaced by "derivation process" or "derivation logic"
where needed
L1 Attributes Predeployed Contract
@@ -647,7 +647,7 @@ Fault Proof
cf. Fault Proofs
Time Slot
On L2, there is a block every 2 second (this duration is known as the block time).
-We say that there is a "time slot" every multiple of 2s after the timestamp of the L2 genesis block.
+We say that there is a "time slot" every multiple of 2s after the timestamp of the L2 genesis block.
On L1, post-merge, the time slots are every 12s. However, an L1 block may not be produced for every time slot, in case
of even benign consensus issues.
Block Time
@@ -669,7 +669,7 @@ Execution E
engine (using transactions from the L1 mempool), at the request of the L1 consensus layer.
On L2, the executed blocks are freshly minted by the execution engine at the request of the rollup node,
using transactions derived from L1 blocks.
-In these specifications, "execution engine" always refer to the L2 execution engine, unless otherwise specified.
+In these specifications, "execution engine" always refer to the L2 execution engine, unless otherwise specified.
diff --git a/introduction.html b/introduction.html
index dc4df3686..bc8235fcf 100644
--- a/introduction.html
+++ b/introduction.html
@@ -273,7 +273,7 @@ Sequencers
The sequencer is the primary block producer.
There may be one sequencer or many using a consensus protocol.
For 1.0.0, there is just one sequencer (currently operated under the oversight of the Optimism Foundation).
-In general, specifications may use "the sequencer" to be a stand-in term
+In general, specifications may use "the sequencer" to be a stand-in term
for the consensus protocol operated by multiple sequencers.
The sequencer:
diff --git a/print.html b/print.html
index f85647c61..f205b7f58 100644
--- a/print.html
+++ b/print.html
@@ -353,7 +353,7 @@ Sequencers
The sequencer is the primary block producer.
There may be one sequencer or many using a consensus protocol.
For 1.0.0, there is just one sequencer (currently operated under the oversight of the Optimism Foundation).
-In general, specifications may use "the sequencer" to be a stand-in term
+In general, specifications may use "the sequencer" to be a stand-in term
for the consensus protocol operated by multiple sequencers.
The sequencer:
@@ -742,7 +742,7 @@ Message
into that field.
Message Version 0
abi.encodeWithSignature(
- "relayMessage(address,address,bytes,uint256)",
+ "relayMessage(address,address,bytes,uint256)",
_target,
_sender,
_message,
@@ -751,7 +751,7 @@ Message V
Message Version 1
abi.encodeWithSignature(
- "relayMessage(uint256,address,address,uint256,uint256,bytes)",
+ "relayMessage(uint256,address,address,uint256,uint256,bytes)",
_nonce,
_sender,
_target,
@@ -765,7 +765,7 @@ relayedMessages
mapping was removed.
It was built as a way to be able to fund third parties who relayed messages
on the behalf of users, but it was improperly implemented as it was impossible
to know if the relayed message actually succeeded.
@@ -1188,7 +1188,7 @@ Address Ali
0x1111000000000000000000000000000000001111
to it. The math is unchecked
and done on a
Solidity uint160
so the value will overflow. This prevents attacks in which a
contract on L1 has the same address as a contract on L2 but doesn't have the same code. We can safely ignore this
-for EOAs because they're guaranteed to have the same "code" (i.e. no code at all). This also makes
+for EOAs because they're guaranteed to have the same "code" (i.e. no code at all). This also makes
it possible for users to interact with contracts on L2 even when the Sequencer is down.
Deposit Contract Implementation: Optimism Portal
A reference implementation of the deposit contract can be found in OptimismPortal.sol.
@@ -1425,7 +1425,7 @@ Overview
initiated on L1. The gas that they use on L2 is bought on L1 via a gas burn (or a direct payment
in the future). We maintain a fee market and hard cap on the amount of gas provided to all deposits
in a single L1 block.
-The gas provided to deposited transactions is sometimes called "guaranteed gas". The gas provided to
+
The gas provided to deposited transactions is sometimes called "guaranteed gas". The gas provided to
deposited transactions is unique in the regard that it is not refundable. It cannot be refunded as
it is sometimes paid for with a gas burn and there may not be any ETH left to refund.
The guaranteed gas is composed of a gas stipend, and of any guaranteed gas the user would like
@@ -1567,7 +1567,7 @@
Overview
After processing one or more blocks the outputs will need to be synchronized with the settlement layer (L1)
for trustless execution of L2-to-L1 messaging, such as withdrawals.
These output proposals act as the bridge's view into the L2 state.
-Actors called "Proposers" submit the output roots to the settlement layer (L1) and can be contested with a fault proof,
+Actors called "Proposers" submit the output roots to the settlement layer (L1) and can be contested with a fault proof,
with a bond at stake if the proof is wrong. The op-proposer in one such implementation of a proposer.
Note: Fault proofs on Optimism are not fully specified at this time. Although fault proof
construction and verification is implemented in Cannon,
@@ -1899,7 +1899,7 @@
in user JSON-RPC.
Nodes may apply L2 blocks out of band ahead of time, and then reorg when L1 data conflicts.
safeBlockHash
: block hash of the canonical chain, derived from L1 data, unlikely to reorg.
finalizedBlockHash
: irreversible block hash, matches lower boundary of the dispute period.
@@ -2087,7 +2087,7 @@ Worst-case sy
Ecotone: disable Blob-transactions
EIP-4844 introduces Blob transactions: featuring all the functionality of an EIP-1559 transaction,
-plus a list of "blobs": "Binary Large Object", i.e. a dedicated data type for serving Data-Availability as base-layer.
+plus a list of "blobs": "Binary Large Object", i.e. a dedicated data type for serving Data-Availability as base-layer.
With the Ecotone upgrade, all Cancun L1 execution features are enabled, with EIP-4844 as exception:
as a L2, the OP-Stack does not serve blobs, and thus disables this new transaction type.
EIP-4844 is disabled as following:
@@ -2101,14 +2101,14 @@ Ecotone: Beacon Block Root
-EIP-4788 introduces a "beacon block root" into the execution-layer block-header and EVM.
+
EIP-4788 introduces a "beacon block root" into the execution-layer block-header and EVM.
This block root is an SSZ hash-tree-root of the consensus-layer contents of the previous consensus block.
With the adoption of EIP-4399 in the Bedrock upgrade the OP-Stack already includes the PREVRANDAO
of L1.
And thus with EIP-4788 the L1 beacon block root is made available.
For the Ecotone upgrade, this entails that:
- The
parent_beacon_block_root
of the L1 origin is now embedded in the L2 block header.
-- The "Beacon roots contract" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis.
+- The "Beacon roots contract" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis.
- The block state-transition process now includes the same special beacon-block-root EVM processing as L1 ethereum.
@@ -2307,7 +2307,7 @@ Overview
This also enables faster historical sync to be bootstrapped by providing block headers to sync towards,
and only having to compare the L2 chain inputs to the L1 data as compared to processing everything one block at a time.
The rollup node will always prioritize L1 and reorganize to match the canonical chain.
-The L2 data retrieved via the P2P interface is strictly a speculative extension, also known as the "unsafe" chain,
+The L2 data retrieved via the P2P interface is strictly a speculative extension, also known as the "unsafe" chain,
to improve the happy case performance.
This also means that P2P behavior is a soft-rule: nodes keep each other in check with scoring and eventual banning
of malicious peers by identity or IP. Any behavior on the P2P layer does not affect the rollup security, at worst nodes
@@ -2371,8 +2371,8 @@
NAT
Peer management
The default is to maintain a peer count with a tide-system based on active peer count:
-- At "low tide" the node starts to actively search for additional peer connections.
-- At "high tide" the node starts to prune active connections,
+
- At "low tide" the node starts to actively search for additional peer connections.
+- At "high tide" the node starts to prune active connections,
except those that are marked as trusted or have a grace period.
Peers will have a grace period for a configurable amount of time after joining.
@@ -2531,7 +2531,7 @@
Block proce
A node may apply the block to their local engine ahead of L1 availability, if it ensures that:
- The application of the block is reversible, in case of a conflict with delayed L1 information
-- The subsequent forkchoice-update ensures this block is recognized as "unsafe"
+
- The subsequent forkchoice-update ensures this block is recognized as "unsafe"
(see fork choice updated)
Block topic scoring parameters
@@ -2866,7 +2866,7 @@
@@ -2880,17 +2880,17 @@ L2 block derived from each batch. Note that we have a 1-1 batch to
block mapping here but, as we'll see later, empty blocks that do not map to batches can be inserted in cases where there
-are "gaps" in the batches posted on L1.
+are "gaps" in the batches posted on L1.
The fifth line shows the L1 attributes deposited transaction which, within each L2 block, records
information about the L1 block that matches the L2 block's epoch. The first number denotes the epoch/L1x number, while
-the second number (the "sequence number") denotes the position within the epoch.
+the second number (the "sequence number") denotes the position within the epoch.
Finally, the sixth line shows user-deposited transactions derived from the deposit
contract event mentioned earlier.
Note the 101-0
L1 attributes transaction on the bottom right of the diagram. Its presence there is only possible if
frame B2
indicates that it is the last frame within the channel and (2) no empty blocks must be inserted.
The diagram does not specify the sequencing window size in use, but from this we can infer that it must be at least 4
blocks, because the last frame of channel A
appears in block 102, but belong to epoch 99.
-As for the comment on "security types", it explains the classification of blocks as used on L1 and L2.
+As for the comment on "security types", it explains the classification of blocks as used on L1 and L2.
- Unsafe L2 blocks:
- Safe L2 blocks:
@@ -2944,14 +2944,14 @@ Channel Format<
where:
-batches
is the input, a sequence of batches byte-encoded as per the next section ("Batch Encoding")
+batches
is the input, a sequence of batches byte-encoded as per the next section ("Batch Encoding")
rlp_batches
is the concatenation of the RLP-encoded batches
compress
is a function performing compression, using the ZLIB algorithm (as specified in RFC-1950) with
no dictionary
channel_encoding
is the compressed version of rlp_batches
When decompressing a channel, we limit the amount of decompressed data to MAX_RLP_BYTES_PER_CHANNEL
(currently
-10,000,000 bytes), in order to avoid "zip-bomb" types of attack (where a small compressed input decompresses to a
+10,000,000 bytes), in order to avoid "zip-bomb" types of attack (where a small compressed input decompresses to a
humongous amount of data). If the decompressed data exceeds the limit, things proceeds as though the channel contained
only the first MAX_RLP_BYTES_PER_CHANNEL
decompressed bytes. The limit is set on RLP decoding, so all batches that
can be decoded in MAX_RLP_BYTES_PER_CHANNEL
will be accepted even if the size of the channel is greater than
@@ -3002,7 +3002,7 @@
This ensures that we use the data we already have before pulling more data and minimizes the latency of data traversing
the derivation pipeline.
@@ -3115,7 +3115,7 @@ Frame Queue
See Batcher transaction format and Frame format specifications.
Channel Bank
The Channel Bank stage is responsible for managing buffering from the channel bank that was written to by the L1
-retrieval stage. A step in the channel bank stage tries to read data from channels that are "ready".
+retrieval stage. A step in the channel bank stage tries to read data from channels that are "ready".
Channels are currently fully buffered until read or dropped,
streaming channels may be supported in a future version of the ChannelBank.
To bound resource usage, the Channel Bank prunes based on channel size, and times out old channels.
@@ -3295,7 +3295,7 @@ Engine QueueThe unsafe L2 head: blocks between the safe and unsafe heads are unsafe
blocks that have not been derived from L1. These blocks either come from sequencing (in sequencer
mode) or from unsafe sync to the sequencer (in validator mode).
-This is also known as the "latest" head.
+This is also known as the "latest" head.
Additionally, it buffers a short history of references to recently processed safe L2 blocks, along with references
from which L1 blocks each was derived.
@@ -3357,8 +3357,8 @@
+- A successful consolidation of unsafe L2 blocks: updating the "safe" L2 block.
- The first thing after a derivation pipeline reset, to ensure a consistent execution engine forkchoice state.
The new forkchoice state is applied by calling fork choice updated on the engine API.
@@ -3367,7 +3367,7 @@
consolidation is attempted, verifying that
existing unsafe L2 chain matches the derived L2 inputs as derived from the canonical L1 data.
During consolidation, we consider the oldest unsafe L2 block, i.e. the unsafe L2 block directly after the safe head. If
-the payload attributes match this oldest unsafe L2 block, then that block can be considered "safe" and becomes the new
+the payload attributes match this oldest unsafe L2 block, then that block can be considered "safe" and becomes the new
safe head.
The following fields of the derived L2 payload attributes are checked for equality with the L2 block:
@@ -3436,7 +3436,7 @@ Processing unsafe payload attributes
If no forkchoice updates or L1 data remain to be processed, and if the next possible L2 block is already available
through an unsafe source such as the sequencer publishing it via the p2p network, then it is optimistically processed as
-an "unsafe" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the
+an "unsafe" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the
user to see the head of the L2 chain faster than the L1 may confirm the L2 batches.
To process unsafe payloads, the payload must:
@@ -3562,7 +3562,7 @@
Deriving Payload Attributes
@@ -3629,20 +3629,20 @@ L1Block
gasLimit
: 375,000
data
: 0x60806040523480156100105...
(full bytecode)
sourceHash
: 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8
,
-computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Deployment"
+computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Deployment"
This results in the Ecotone L1Block contract being deployed to 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff
, to verify:
cast compute-address --nonce=0 0x4210000000000000000000000000000000000000
Computed Address: 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Deployment"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Deployment"))
# 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8
Verify data
:
git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932
pnpm clean && pnpm install && pnpm build
-jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json
+jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json
This transaction MUST deploy a contract with the following code hash
0xc88a313aa75dc4fbf0b6850d9f9ae41e04243b7008cf3eadb29256d4a71c1dfd
.
@@ -3658,7 +3658,7 @@ full bytecode)
sourceHash
: 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42
-computed with the "Upgrade-deposited" type, with `intent = "Ecotone: Gas Price Oracle Deployment"
+computed with the "Upgrade-deposited" type, with `intent = "Ecotone: Gas Price Oracle Deployment"
- State inherited from the previous version of the L2 chain.
-
-
- This state was possibly modified by "state surgeries". For instance, the migration to Bedrock entailed changes on +
- This state was possibly modified by "state surgeries". For instance, the migration to Bedrock entailed changes on how native ETH balances were stored in the storage trie.
@@ -610,7 +610,7 @@ safeBlockHash
: block hash of the canonical chain, derived from L1 data, unlikely to reorg.finalizedBlockHash
: irreversible block hash, matches lower boundary of the dispute period.
@@ -2087,7 +2087,7 @@ - The
parent_beacon_block_root
of the L1 origin is now embedded in the L2 block header.
- - The "Beacon roots contract" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis. +
- The "Beacon roots contract" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis.
- The block state-transition process now includes the same special beacon-block-root EVM processing as L1 ethereum.
- At "low tide" the node starts to actively search for additional peer connections. -
- At "high tide" the node starts to prune active connections, +
- At "low tide" the node starts to actively search for additional peer connections. +
- At "high tide" the node starts to prune active connections, except those that are marked as trusted or have a grace period.
- The application of the block is reversible, in case of a conflict with delayed L1 information -
- The subsequent forkchoice-update ensures this block is recognized as "unsafe" +
- The subsequent forkchoice-update ensures this block is recognized as "unsafe" (see fork choice updated)
- Unsafe L2 blocks:
- Safe L2 blocks: @@ -2944,14 +2944,14 @@
batches
is the input, a sequence of batches byte-encoded as per the next section ("Batch Encoding")
+batches
is the input, a sequence of batches byte-encoded as per the next section ("Batch Encoding")rlp_batches
is the concatenation of the RLP-encoded batchescompress
is a function performing compression, using the ZLIB algorithm (as specified in RFC-1950) with no dictionarychannel_encoding
is the compressed version ofrlp_batches
- A successful consolidation of unsafe L2 blocks: updating the "safe" L2 block.
- The first thing after a derivation pipeline reset, to ensure a consistent execution engine forkchoice state.
Rollup Node
In sequencer mode, the rollup node receives L2 transactions from users, which it uses to create L2 blocks. These are then submitted to a data availability provider via batch submission. The L2 chain derivation then acts as a sanity check and a way to detect L1 chain re-orgs.
-In validator mode, the rollup node performs derivation as indicated above, but is also able to "run ahead" of the L1 +
In validator mode, the rollup node performs derivation as indicated above, but is also able to "run ahead" of the L1 chain by getting blocks directly from the sequencer, in which case derivation serves to validate the sequencer's behaviour.
A rollup node running in validator mode is sometimes called a replica.
@@ -622,7 +622,7 @@Rollup Driver
The rollup driver is the rollup node component responsible for deriving the L2 chain from the L1 chain (L1 blocks and their associated receipts).
-TODO delete this entry, alongside its reference — can be replaced by "derivation process" or "derivation logic" +
TODO delete this entry, alongside its reference — can be replaced by "derivation process" or "derivation logic" where needed
L1 Attributes Predeployed Contract
@@ -647,7 +647,7 @@Fault Proof
cf. Fault Proofs
Time Slot
On L2, there is a block every 2 second (this duration is known as the block time).
-We say that there is a "time slot" every multiple of 2s after the timestamp of the L2 genesis block.
+We say that there is a "time slot" every multiple of 2s after the timestamp of the L2 genesis block.
On L1, post-merge, the time slots are every 12s. However, an L1 block may not be produced for every time slot, in case of even benign consensus issues.
Block Time
@@ -669,7 +669,7 @@Execution E engine (using transactions from the L1 mempool), at the request of the L1 consensus layer.
On L2, the executed blocks are freshly minted by the execution engine at the request of the rollup node, using transactions derived from L1 blocks.
-In these specifications, "execution engine" always refer to the L2 execution engine, unless otherwise specified.
+In these specifications, "execution engine" always refer to the L2 execution engine, unless otherwise specified.
diff --git a/introduction.html b/introduction.html index dc4df3686..bc8235fcf 100644 --- a/introduction.html +++ b/introduction.html @@ -273,7 +273,7 @@Sequencers
The sequencer is the primary block producer. There may be one sequencer or many using a consensus protocol. For 1.0.0, there is just one sequencer (currently operated under the oversight of the Optimism Foundation). -In general, specifications may use "the sequencer" to be a stand-in term +In general, specifications may use "the sequencer" to be a stand-in term for the consensus protocol operated by multiple sequencers.
The sequencer:
-
diff --git a/print.html b/print.html
index f85647c61..f205b7f58 100644
--- a/print.html
+++ b/print.html
@@ -353,7 +353,7 @@
Sequencers
The sequencer is the primary block producer. There may be one sequencer or many using a consensus protocol. For 1.0.0, there is just one sequencer (currently operated under the oversight of the Optimism Foundation). -In general, specifications may use "the sequencer" to be a stand-in term +In general, specifications may use "the sequencer" to be a stand-in term for the consensus protocol operated by multiple sequencers.
The sequencer:
-
@@ -742,7 +742,7 @@
Message
into that field.
Message Version 0
abi.encodeWithSignature(
- "relayMessage(address,address,bytes,uint256)",
+ "relayMessage(address,address,bytes,uint256)",
_target,
_sender,
_message,
@@ -751,7 +751,7 @@ Message V
Message Version 1
abi.encodeWithSignature(
- "relayMessage(uint256,address,address,uint256,uint256,bytes)",
+ "relayMessage(uint256,address,address,uint256,uint256,bytes)",
_nonce,
_sender,
_target,
@@ -765,7 +765,7 @@ relayedMessages
mapping was removed.
It was built as a way to be able to fund third parties who relayed messages
on the behalf of users, but it was improperly implemented as it was impossible
to know if the relayed message actually succeeded.
@@ -1188,7 +1188,7 @@ Address Ali
0x1111000000000000000000000000000000001111
to it. The math is unchecked
and done on a
Solidity uint160
so the value will overflow. This prevents attacks in which a
contract on L1 has the same address as a contract on L2 but doesn't have the same code. We can safely ignore this
-for EOAs because they're guaranteed to have the same "code" (i.e. no code at all). This also makes
+for EOAs because they're guaranteed to have the same "code" (i.e. no code at all). This also makes
it possible for users to interact with contracts on L2 even when the Sequencer is down.
Deposit Contract Implementation: Optimism Portal
A reference implementation of the deposit contract can be found in OptimismPortal.sol.
@@ -1425,7 +1425,7 @@ Overview
initiated on L1. The gas that they use on L2 is bought on L1 via a gas burn (or a direct payment
in the future). We maintain a fee market and hard cap on the amount of gas provided to all deposits
in a single L1 block.
-The gas provided to deposited transactions is sometimes called "guaranteed gas". The gas provided to
+
The gas provided to deposited transactions is sometimes called "guaranteed gas". The gas provided to
deposited transactions is unique in the regard that it is not refundable. It cannot be refunded as
it is sometimes paid for with a gas burn and there may not be any ETH left to refund.
The guaranteed gas is composed of a gas stipend, and of any guaranteed gas the user would like
@@ -1567,7 +1567,7 @@
Overview
After processing one or more blocks the outputs will need to be synchronized with the settlement layer (L1)
for trustless execution of L2-to-L1 messaging, such as withdrawals.
These output proposals act as the bridge's view into the L2 state.
-Actors called "Proposers" submit the output roots to the settlement layer (L1) and can be contested with a fault proof,
+Actors called "Proposers" submit the output roots to the settlement layer (L1) and can be contested with a fault proof,
with a bond at stake if the proof is wrong. The op-proposer in one such implementation of a proposer.
Note: Fault proofs on Optimism are not fully specified at this time. Although fault proof
construction and verification is implemented in Cannon,
@@ -1899,7 +1899,7 @@
in user JSON-RPC.
Nodes may apply L2 blocks out of band ahead of time, and then reorg when L1 data conflicts.
Worst-case sy
abi.encodeWithSignature(
- "relayMessage(address,address,bytes,uint256)",
+ "relayMessage(address,address,bytes,uint256)",
_target,
_sender,
_message,
@@ -751,7 +751,7 @@ Message V
abi.encodeWithSignature(
- "relayMessage(uint256,address,address,uint256,uint256,bytes)",
+ "relayMessage(uint256,address,address,uint256,uint256,bytes)",
_nonce,
_sender,
_target,
@@ -765,7 +765,7 @@ relayedMessages
mapping was removed.
It was built as a way to be able to fund third parties who relayed messages
on the behalf of users, but it was improperly implemented as it was impossible
to know if the relayed message actually succeeded.
@@ -1188,7 +1188,7 @@ Address Ali
0x1111000000000000000000000000000000001111
to it. The math is unchecked
and done on a
Solidity uint160
so the value will overflow. This prevents attacks in which a
contract on L1 has the same address as a contract on L2 but doesn't have the same code. We can safely ignore this
-for EOAs because they're guaranteed to have the same "code" (i.e. no code at all). This also makes
+for EOAs because they're guaranteed to have the same "code" (i.e. no code at all). This also makes
it possible for users to interact with contracts on L2 even when the Sequencer is down.
Deposit Contract Implementation: Optimism Portal
A reference implementation of the deposit contract can be found in OptimismPortal.sol.
@@ -1425,7 +1425,7 @@ Overview
initiated on L1. The gas that they use on L2 is bought on L1 via a gas burn (or a direct payment
in the future). We maintain a fee market and hard cap on the amount of gas provided to all deposits
in a single L1 block.
-The gas provided to deposited transactions is sometimes called "guaranteed gas". The gas provided to
+
The gas provided to deposited transactions is sometimes called "guaranteed gas". The gas provided to
deposited transactions is unique in the regard that it is not refundable. It cannot be refunded as
it is sometimes paid for with a gas burn and there may not be any ETH left to refund.
The guaranteed gas is composed of a gas stipend, and of any guaranteed gas the user would like
@@ -1567,7 +1567,7 @@
Overview
After processing one or more blocks the outputs will need to be synchronized with the settlement layer (L1)
for trustless execution of L2-to-L1 messaging, such as withdrawals.
These output proposals act as the bridge's view into the L2 state.
-Actors called "Proposers" submit the output roots to the settlement layer (L1) and can be contested with a fault proof,
+Actors called "Proposers" submit the output roots to the settlement layer (L1) and can be contested with a fault proof,
with a bond at stake if the proof is wrong. The op-proposer in one such implementation of a proposer.
Note: Fault proofs on Optimism are not fully specified at this time. Although fault proof
construction and verification is implemented in Cannon,
@@ -1899,7 +1899,7 @@
in user JSON-RPC.
Nodes may apply L2 blocks out of band ahead of time, and then reorg when L1 data conflicts.
Worst-case sy
Worst-case sy
Ecotone: disable Blob-transactions
EIP-4844 introduces Blob transactions: featuring all the functionality of an EIP-1559 transaction, -plus a list of "blobs": "Binary Large Object", i.e. a dedicated data type for serving Data-Availability as base-layer.
+plus a list of "blobs": "Binary Large Object", i.e. a dedicated data type for serving Data-Availability as base-layer.With the Ecotone upgrade, all Cancun L1 execution features are enabled, with EIP-4844 as exception: as a L2, the OP-Stack does not serve blobs, and thus disables this new transaction type.
EIP-4844 is disabled as following:
@@ -2101,14 +2101,14 @@Ecotone: Beacon Block Root
-EIP-4788 introduces a "beacon block root" into the execution-layer block-header and EVM. +
EIP-4788 introduces a "beacon block root" into the execution-layer block-header and EVM. This block root is an SSZ hash-tree-root of the consensus-layer contents of the previous consensus block.
With the adoption of EIP-4399 in the Bedrock upgrade the OP-Stack already includes the PREVRANDAO
of L1.
And thus with EIP-4788 the L1 beacon block root is made available.
For the Ecotone upgrade, this entails that:
Overview
This also enables faster historical sync to be bootstrapped by providing block headers to sync towards, and only having to compare the L2 chain inputs to the L1 data as compared to processing everything one block at a time.
The rollup node will always prioritize L1 and reorganize to match the canonical chain. -The L2 data retrieved via the P2P interface is strictly a speculative extension, also known as the "unsafe" chain, +The L2 data retrieved via the P2P interface is strictly a speculative extension, also known as the "unsafe" chain, to improve the happy case performance.
This also means that P2P behavior is a soft-rule: nodes keep each other in check with scoring and eventual banning of malicious peers by identity or IP. Any behavior on the P2P layer does not affect the rollup security, at worst nodes @@ -2371,8 +2371,8 @@
NAT
Peer management
The default is to maintain a peer count with a tide-system based on active peer count:
-
-
Peers will have a grace period for a configurable amount of time after joining. @@ -2531,7 +2531,7 @@
Block proce
A node may apply the block to their local engine ahead of L1 availability, if it ensures that:
Block topic scoring parameters
@@ -2866,7 +2866,7 @@
@@ -2880,17 +2880,17 @@ L2 block derived from each batch. Note that we have a 1-1 batch to
block mapping here but, as we'll see later, empty blocks that do not map to batches can be inserted in cases where there
-are "gaps" in the batches posted on L1.
+are "gaps" in the batches posted on L1.
The fifth line shows the L1 attributes deposited transaction which, within each L2 block, records
information about the L1 block that matches the L2 block's epoch. The first number denotes the epoch/L1x number, while
-the second number (the "sequence number") denotes the position within the epoch.
+the second number (the "sequence number") denotes the position within the epoch.
Finally, the sixth line shows user-deposited transactions derived from the deposit
contract event mentioned earlier.
Note the 101-0
L1 attributes transaction on the bottom right of the diagram. Its presence there is only possible if
frame B2
indicates that it is the last frame within the channel and (2) no empty blocks must be inserted.
The diagram does not specify the sequencing window size in use, but from this we can infer that it must be at least 4
blocks, because the last frame of channel A
appears in block 102, but belong to epoch 99.
-As for the comment on "security types", it explains the classification of blocks as used on L1 and L2.
+As for the comment on "security types", it explains the classification of blocks as used on L1 and L2.
Channel Format<
where:
-
When decompressing a channel, we limit the amount of decompressed data to MAX_RLP_BYTES_PER_CHANNEL
(currently
-10,000,000 bytes), in order to avoid "zip-bomb" types of attack (where a small compressed input decompresses to a
+10,000,000 bytes), in order to avoid "zip-bomb" types of attack (where a small compressed input decompresses to a
humongous amount of data). If the decompressed data exceeds the limit, things proceeds as though the channel contained
only the first MAX_RLP_BYTES_PER_CHANNEL
decompressed bytes. The limit is set on RLP decoding, so all batches that
can be decoded in MAX_RLP_BYTES_PER_CHANNEL
will be accepted even if the size of the channel is greater than
@@ -3002,7 +3002,7 @@
This ensures that we use the data we already have before pulling more data and minimizes the latency of data traversing
the derivation pipeline.
@@ -3115,7 +3115,7 @@ Frame Queue
See Batcher transaction format and Frame format specifications.
Channel Bank
The Channel Bank stage is responsible for managing buffering from the channel bank that was written to by the L1
-retrieval stage. A step in the channel bank stage tries to read data from channels that are "ready".
+retrieval stage. A step in the channel bank stage tries to read data from channels that are "ready".
Channels are currently fully buffered until read or dropped,
streaming channels may be supported in a future version of the ChannelBank.
To bound resource usage, the Channel Bank prunes based on channel size, and times out old channels.
@@ -3295,7 +3295,7 @@ Engine QueueThe unsafe L2 head: blocks between the safe and unsafe heads are unsafe
blocks that have not been derived from L1. These blocks either come from sequencing (in sequencer
mode) or from unsafe sync to the sequencer (in validator mode).
-This is also known as the "latest" head.
+This is also known as the "latest" head.
Additionally, it buffers a short history of references to recently processed safe L2 blocks, along with references
from which L1 blocks each was derived.
@@ -3357,8 +3357,8 @@
+
L2 block derived from each batch. Note that we have a 1-1 batch to block mapping here but, as we'll see later, empty blocks that do not map to batches can be inserted in cases where there -are "gaps" in the batches posted on L1. +are "gaps" in the batches posted on L1.
The fifth line shows the L1 attributes deposited transaction which, within each L2 block, records information about the L1 block that matches the L2 block's epoch. The first number denotes the epoch/L1x number, while -the second number (the "sequence number") denotes the position within the epoch.
+the second number (the "sequence number") denotes the position within the epoch.Finally, the sixth line shows user-deposited transactions derived from the deposit contract event mentioned earlier.
Note the 101-0
L1 attributes transaction on the bottom right of the diagram. Its presence there is only possible if
frame B2
indicates that it is the last frame within the channel and (2) no empty blocks must be inserted.
The diagram does not specify the sequencing window size in use, but from this we can infer that it must be at least 4
blocks, because the last frame of channel A
appears in block 102, but belong to epoch 99.
As for the comment on "security types", it explains the classification of blocks as used on L1 and L2.
+As for the comment on "security types", it explains the classification of blocks as used on L1 and L2.
Channel Format<
where:
-
When decompressing a channel, we limit the amount of decompressed data to MAX_RLP_BYTES_PER_CHANNEL
(currently
-10,000,000 bytes), in order to avoid "zip-bomb" types of attack (where a small compressed input decompresses to a
+10,000,000 bytes), in order to avoid "zip-bomb" types of attack (where a small compressed input decompresses to a
humongous amount of data). If the decompressed data exceeds the limit, things proceeds as though the channel contained
only the first MAX_RLP_BYTES_PER_CHANNEL
decompressed bytes. The limit is set on RLP decoding, so all batches that
can be decoded in MAX_RLP_BYTES_PER_CHANNEL
will be accepted even if the size of the channel is greater than
@@ -3002,7 +3002,7 @@
This ensures that we use the data we already have before pulling more data and minimizes the latency of data traversing
the derivation pipeline.
@@ -3115,7 +3115,7 @@ Frame Queue
See Batcher transaction format and Frame format specifications.
Channel Bank
The Channel Bank stage is responsible for managing buffering from the channel bank that was written to by the L1
-retrieval stage. A step in the channel bank stage tries to read data from channels that are "ready".
+retrieval stage. A step in the channel bank stage tries to read data from channels that are "ready".
Channels are currently fully buffered until read or dropped,
streaming channels may be supported in a future version of the ChannelBank.
To bound resource usage, the Channel Bank prunes based on channel size, and times out old channels.
@@ -3295,7 +3295,7 @@ Engine QueueThe unsafe L2 head: blocks between the safe and unsafe heads are unsafe
blocks that have not been derived from L1. These blocks either come from sequencing (in sequencer
mode) or from unsafe sync to the sequencer (in validator mode).
-This is also known as the "latest" head.
+This is also known as the "latest" head.
MAX_RLP_BYTES_PER_CHANNEL
(currently
-10,000,000 bytes), in order to avoid "zip-bomb" types of attack (where a small compressed input decompresses to a
+10,000,000 bytes), in order to avoid "zip-bomb" types of attack (where a small compressed input decompresses to a
humongous amount of data). If the decompressed data exceeds the limit, things proceeds as though the channel contained
only the first MAX_RLP_BYTES_PER_CHANNEL
decompressed bytes. The limit is set on RLP decoding, so all batches that
can be decoded in MAX_RLP_BYTES_PER_CHANNEL
will be accepted even if the size of the channel is greater than
@@ -3002,7 +3002,7 @@ This ensures that we use the data we already have before pulling more data and minimizes the latency of data traversing the derivation pipeline.
@@ -3115,7 +3115,7 @@Frame Queue
See Batcher transaction format and Frame format specifications.Channel Bank
Additionally, it buffers a short history of references to recently processed safe L2 blocks, along with references from which L1 blocks each was derived. @@ -3357,8 +3357,8 @@
+
The new forkchoice state is applied by calling fork choice updated on the engine API. @@ -3367,7 +3367,7 @@
consolidation is attempted, verifying that existing unsafe L2 chain matches the derived L2 inputs as derived from the canonical L1 data.
During consolidation, we consider the oldest unsafe L2 block, i.e. the unsafe L2 block directly after the safe head. If -the payload attributes match this oldest unsafe L2 block, then that block can be considered "safe" and becomes the new +the payload attributes match this oldest unsafe L2 block, then that block can be considered "safe" and becomes the new safe head.
The following fields of the derived L2 payload attributes are checked for equality with the L2 block:
-
@@ -3436,7 +3436,7 @@
gasLimit
:375,000
data
:0x60806040523480156100105...
(full bytecode)sourceHash
:0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8
, -computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Deployment"
+computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Deployment"
Processing unsafe payload attributes
If no forkchoice updates or L1 data remain to be processed, and if the next possible L2 block is already available through an unsafe source such as the sequencer publishing it via the p2p network, then it is optimistically processed as -an "unsafe" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the +an "unsafe" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the user to see the head of the L2 chain faster than the L1 may confirm the L2 batches.
To process unsafe payloads, the payload must:
-
@@ -3562,7 +3562,7 @@
Deriving Payload Attributes
@@ -3629,20 +3629,20 @@ L1Block
This results in the Ecotone L1Block contract being deployed to 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff
, to verify:
cast compute-address --nonce=0 0x4210000000000000000000000000000000000000
Computed Address: 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff
Verify sourceHash
:
cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Deployment"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Deployment"))
# 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8
Verify data
:
git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932
pnpm clean && pnpm install && pnpm build
-jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json
+jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json
This transaction MUST deploy a contract with the following code hash
0xc88a313aa75dc4fbf0b6850d9f9ae41e04243b7008cf3eadb29256d4a71c1dfd
.
@@ -3658,7 +3658,7 @@ full bytecode)
sourceHash
: 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42
-computed with the "Upgrade-deposited" type, with `intent = "Ecotone: Gas Price Oracle Deployment"
+computed with the "Upgrade-deposited" type, with `intent = "Ecotone: Gas Price Oracle Deployment"
0xb528D11cC114E026F138fE568744c6D45ce6Da7A
,
to verify:❯ cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Deployment"))
# 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42
Verify data
:
git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932
pnpm clean && pnpm install && pnpm build
-jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json
+jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json
This transaction MUST deploy a contract with the following code hash
0x8b71360ea773b4cfaf1ae6d2bd15464a4e1e2e360f786e475f63aeaed8da0ae5
.
L1B
gasLimit
: 50,000
data
: 0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff
sourceHash
: 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc
-computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Proxy Update"
+computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Proxy Update"
Verify data:
-cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)
+cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)
0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Proxy Update"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Proxy Update"))
# 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc
GasPriceOracle Proxy Update
@@ -3709,14 +3709,14 @@ intent = "Ecotone: Gas Price Oracle Proxy Update"
Verify data:
-cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)
+cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)
0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Proxy Update"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Proxy Update"))
# 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a
GasPriceOracle Enable Ecotone
@@ -3730,18 +3730,18 @@
Verify data:
-cast sig "setEcotone()"
+cast sig "setEcotone()"
0x22b90ab3
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Set Ecotone"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Set Ecotone"))
# 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93
Beacon block roots contract deployment (EIP-4788)
-EIP-4788 introduces a "Beacon block roots" contract, that processes and exposes the beacon-block-root values.
+
EIP-4788 introduces a "Beacon block roots" contract, that processes and exposes the beacon-block-root values.
at address BEACON_ROOTS_ADDRESS = 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02
.
For deployment, EIP-4788 defines a pre-EIP-155 legacy transaction, sent from a key that is derived such that the
transaction signature validity is bound to message-hash, which is bound to the input-data, containing the init-code.
@@ -3763,7 +3763,7 @@ 0x60618060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604d57602036146024575f5ffd5b5f35801560495762001fff810690815414603c575f5ffd5b62001fff01545f5260205ff35b5f5ffd5b62001fff42064281555f359062001fff015500
isSystemTx
: false
, as per the Regolith upgrade, even the system-generated transactions spend gas.
sourceHash
: 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c
,
-computed with the "Upgrade-deposited" type, with intent = "Ecotone: beacon block roots contract deployment"
+computed with the "Upgrade-deposited" type, with intent = "Ecotone: beacon block roots contract deployment"
The contract address upon deployment is computed as rlp([sender, nonce])
, which will equal:
@@ -3776,7 +3776,7 @@
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: beacon block roots contract deployment"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: beacon block roots contract deployment"))
# 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c
Building Individual Payload Attributes
@@ -4230,7 +4230,7 @@ Batch Queue
Once validated, the batch-queue then emits a block-input for each of the blocks included in the span-batch.
The next derivation stage is thus only aware of individual block inputs, similar to the previous V0 batch,
-although not strictly a "v0 batch" anymore.
+although not strictly a "v0 batch" anymore.
Batcher
Instead of transforming L2 blocks into batches,
the blocks should be buffered to form a span-batch.
@@ -4832,7 +4832,7 @@ ERC-4
ERC-4337 SenderCreator
Address: 0x7fc98430eaedbb6070b35b39d798725049088348
-Helper contract for EntryPoint, to call userOp.initCode
from a "neutral" address,
+
Helper contract for EntryPoint, to call userOp.initCode
from a "neutral" address,
which is explicitly not EntryPoint
itself.
Superchain Configuration
@@ -5046,8 +5046,8 @@
+Recommended storage slot: bytes32(uint256(keccak256("protocolversion.recommended")) - 1)
Required getter: required()
returns ProtocolVersion
Recommended getter recommended()
returns ProtocolVersion
Version updates also emit a typed event:
@@ -5106,7 +5106,7 @@ Post-Bedrock Network upgrades
Regolith
-The Regolith upgrade, named after a material best described as "deposited dust on top of a layer of bedrock",
+
The Regolith upgrade, named after a material best described as "deposited dust on top of a layer of bedrock",
implements minor changes to deposit processing, based on reports of the Sherlock Audit-contest and findings in
the Bedrock Optimism Goerli testnet.
Summary of changes:
@@ -5304,11 +5304,11 @@ gasLimi
unsafeBlockSigner
(address
)
Blocks are gossiped around the p2p network before they are made available on L1.
To prevent denial of service on the p2p layer, these unsafe blocks must be
-signed with a particular key to be accepted as "canonical" unsafe blocks.
+signed with a particular key to be accepted as "canonical" unsafe blocks.
The address corresponding to this key is the unsafeBlockSigner
. To ensure
that its value can be fetched with a storage proof in a storage layout independent
manner, it is stored at a special storage slot corresponding to
-keccak256("systemconfig.unsafeblocksigner")
.
+keccak256("systemconfig.unsafeblocksigner")
.
Unlike the other values, the unsafeBlockSigner
only operates on blockchain
policy. It is not a consensus level parameter.
Writing the system config
@@ -5413,7 +5413,7 @@ Overview
Each of these 3 components may have different implementations, which can be combined into different proof stacks,
and contribute to proof diversity when resolving a dispute.
-"Stateless execution" of the program, and its individual instructions, refers to reproducing
+
"Stateless execution" of the program, and its individual instructions, refers to reproducing
the exact same computation by authenticating the inputs with a Pre-image Oracle.
Pre-image Oracle
@@ -5447,7 +5447,7 @@
Type 3
: Global generic key
Reserved. This scheme allows for unlimited application-layer pre-image types without fault-proof VM redeployments.
This is a generic version of a global key store: key = 0x03 ++ keccak256(x, sender)[1:]
, where:
@@ -5590,7 +5590,7 @@ Prologue
dispute game interface, in the L1 history up and till the specified l1_head
.
The dispute
may be the claim itself, or a pointer to specific prior claimed data in L1,
depending on the dispute game interface.
-
Implied inputs are loaded in a "prologue" before the actual core state-transition function executes.
+
Implied inputs are loaded in a "prologue" before the actual core state-transition function executes.
During testing a simplified prologue that loads the overrides may be used.
Note: only the test-prologues are currently supported, since the dispute game interface is actively changing.
@@ -5827,7 +5827,7 @@ Heap
result of the syscall to locate free memory. The page size is 4096.
The FPVM has a fixed program break at 0x40000000
. However, the FPVM is permitted to extend the
heap beyond this limit via mmap syscalls.
-For simplicity, there are no memory protections against "heap overruns" against other memory segments.
+For simplicity, there are no memory protections against "heap overruns" against other memory segments.
Such VM steps are still considered valid state transitions.
Specification of memory mappings is outside the scope of this document as it is irrelevant to
the VM state. FPVM implementers may refer to the Linux/MIPS kernel for inspiration.
@@ -5838,7 +5838,7 @@ Delay Slots
A VM state transition is invalid whenever the current instruction is a delay slot that is filled
with jump or branch type instruction.
That is, where while stepping on a jump/branch instruction.
-Otherwise, there would be two consecutive delay slots. While this is considered "undefined"
+Otherwise, there would be two consecutive delay slots. While this is considered "undefined"
behavior in typical MIPS implementations, FPVM must raise an exception when stepping on such states.
Syscalls
Syscalls work similar to Linux/MIPS, including the
@@ -6180,7 +6180,7 @@
Fault D
GAME_DURATION
-Game Mechanics
+ Core Game Mechanics
Subgame
A sub-game is a DAG of depth 1, where the root of the DAG is a Claim
and the children are Claim
s that counter the
@@ -6267,7 +6267,7 @@
Game Tree
Position
A position represents the location of a claim in the Game Tree. This is represented by a
-"generalized index" (or gindex) where the high-order bit is the level in the tree and the remaining
+"generalized index" (or gindex) where the high-order bit is the level in the tree and the remaining
bits is a unique bit pattern, allowing a unique identifier for each node in the tree.
The gindex of a position can be calculated as , where:
@@ -6409,7 +6409,7 @@ FDG Responses
@@ -6598,7 +6599,7 @@ Root Claims
- Do Nothing if they agree with the root claim. They do nothing because if the root
claim is left un-countered, the game resolves to their agreement.
NOTE: The honest challenger will still track this game in order to defend any subsequent
-claims made against the root claim - in effect, "playing the game".
+claims made against the root claim - in effect, "playing the game".
Countering Invalid Claims
For every claim made in a dispute game with a game tree
@@ -6712,6 +6713,20 @@
Resolution
challengers are economically incentivized to resolve the game promptly to capture the bonds.
Bond Incentives
+
+
+Table of Contents
+
+- Overview
+- Moves
+- Subgame Resolution
+
+
+
+
+Overview
Bonds is an add-on to the core Fault Dispute Game. The core game mechanics are
designed to ensure honesty as the best response to winning subgames. By introducing financial incentives,
Bonds makes it worthwhile for honest challengers to participate.
@@ -6759,8 +6774,8 @@
Glossary
- EOA
- Merkle Patricia Trie
- Chain Re-Organization
-- Predeployed Contract ("Predeploy")
-- Preinstalled Contract ("Preinstall")
+- Predeployed Contract ("Predeploy")
+- Preinstalled Contract ("Preinstall")
- Receipt
- Transaction Type
- Fork Choice Rule
@@ -6863,7 +6878,7 @@ Block
block, and output block properties, which are derived after executing the block's transactions. These include various
Merkle Patricia Trie roots that notably commit to the L2 state and to the log events emitted during execution.
EOA
-"Externally Owned Account", an Ethereum term to designate addresses operated by users, as opposed to contract addresses.
+"Externally Owned Account", an Ethereum term to designate addresses operated by users, as opposed to contract addresses.
Merkle Patricia Trie
A Merkle Patricia Trie (MPT) is a sparse trie, which is a tree-like structure that maps keys to values.
The root hash of a MPT is a commitment to the contents of the tree, which allows a
@@ -6874,10 +6889,10 @@
C
the fork choice rule) to a block that is not a child of the previous head.
L1 re-orgs can happen because of network conditions or attacks. L2 re-orgs are a consequence of L1 re-orgs, mediated via
L2 chain derivation.
-Predeployed Contract ("Predeploy")
+Predeployed Contract ("Predeploy")
A contract placed in the L2 genesis state (i.e. at the start of the chain).
All predeploy contracts are specified in the predeploys specification.
-Preinstalled Contract ("Preinstall")
+Preinstalled Contract ("Preinstall")
A contract placed in the L2 genesis state (i.e. at the start of the chain). These contracts do not share the same
security guarantees as predeploys, but are general use contracts made
available to improve the L2's UX.
@@ -6935,9 +6950,9 @@ L1 Origin
Deposits
In general, a deposit is an L2 transaction derived from an L1 block (by the rollup driver).
-While transaction deposits are notably (but not only) used to "deposit" (bridge) ETH and tokens to L2, the word
-deposit should be understood as "a transaction deposited to L2 from L1".
-This term deposit is somewhat ambiguous as these "transactions" exist at multiple levels. This section disambiguates
+
While transaction deposits are notably (but not only) used to "deposit" (bridge) ETH and tokens to L2, the word
+deposit should be understood as "a transaction deposited to L2 from L1".
+This term deposit is somewhat ambiguous as these "transactions" exist at multiple levels. This section disambiguates
all deposit-related terms.
Notably, a deposit can refer to:
@@ -6995,7 +7010,7 @@ Withdrawals
TODO expand this whole section to be clearer
In general, a withdrawal is a transaction sent from L2 to L1 that may transfer data and/or value.
-The term withdrawal is somewhat ambiguous as these "transactions" exist at multiple levels. In order to differentiate
+
The term withdrawal is somewhat ambiguous as these "transactions" exist at multiple levels. In order to differentiate
between the L1 and L2 components of a withdrawal we introduce the following terms:
- A withdrawal initiating transaction refers specifically to a transaction on L2 sent to the Withdrawals predeploy.
@@ -7015,12 +7030,12 @@ Final
Batch Submission
Data Availability
-Data availability is the guarantee that some data will be "available" (i.e. retrievable) during a reasonably long time
+
Data availability is the guarantee that some data will be "available" (i.e. retrievable) during a reasonably long time
window. In Optimism's case, the data in question are sequencer batches that validators
need in order to verify the sequencer's work and validate the L2 chain.
The finalization period should be taken as the lower bound on the availability window, since
that is when data availability is the most crucial, as it is needed to perform a fault proof.
-"Availability" does not mean guaranteed long-term storage of the data.
+"Availability" does not mean guaranteed long-term storage of the data.
Data Availability Provider
A data availability provider is a service that can be used to make data available. See the Data
Availability for more information on what this means.
@@ -7128,7 +7143,7 @@ L2 Genesis
- State inherited from the previous version of the L2 chain.
-- This state was possibly modified by "state surgeries". For instance, the migration to Bedrock entailed changes on
+
- This state was possibly modified by "state surgeries". For instance, the migration to Bedrock entailed changes on
how native ETH balances were stored in the storage trie.
@@ -7182,7 +7197,7 @@ Rollup Node
In sequencer mode, the rollup node receives L2 transactions from users, which it uses to create L2 blocks. These are
then submitted to a data availability provider via batch submission. The L2 chain
derivation then acts as a sanity check and a way to detect L1 chain re-orgs.
-In validator mode, the rollup node performs derivation as indicated above, but is also able to "run ahead" of the L1
+
In validator mode, the rollup node performs derivation as indicated above, but is also able to "run ahead" of the L1
chain by getting blocks directly from the sequencer, in which case derivation serves to validate the sequencer's
behaviour.
A rollup node running in validator mode is sometimes called a replica.
@@ -7194,7 +7209,7 @@ Rollup Driver
The rollup driver is the rollup node component responsible for deriving the L2 chain
from the L1 chain (L1 blocks and their associated receipts).
-TODO delete this entry, alongside its reference — can be replaced by "derivation process" or "derivation logic"
+
TODO delete this entry, alongside its reference — can be replaced by "derivation process" or "derivation logic"
where needed
L1 Attributes Predeployed Contract
@@ -7219,7 +7234,7 @@ Fault Proof
cf. Fault Proofs
Time Slot
On L2, there is a block every 2 second (this duration is known as the block time).
-We say that there is a "time slot" every multiple of 2s after the timestamp of the L2 genesis block.
+We say that there is a "time slot" every multiple of 2s after the timestamp of the L2 genesis block.
On L1, post-merge, the time slots are every 12s. However, an L1 block may not be produced for every time slot, in case
of even benign consensus issues.
Block Time
@@ -7241,7 +7256,7 @@ Execution E
engine (using transactions from the L1 mempool), at the request of the L1 consensus layer.
On L2, the executed blocks are freshly minted by the execution engine at the request of the rollup node,
using transactions derived from L1 blocks.
-In these specifications, "execution engine" always refer to the L2 execution engine, unless otherwise specified.
+In these specifications, "execution engine" always refer to the L2 execution engine, unless otherwise specified.
diff --git a/protocol/deposits.html b/protocol/deposits.html
index de6bf9f67..bf0f25136 100644
--- a/protocol/deposits.html
+++ b/protocol/deposits.html
@@ -592,7 +592,7 @@ Address Ali
0x1111000000000000000000000000000000001111
to it. The math is unchecked
and done on a
Solidity uint160
so the value will overflow. This prevents attacks in which a
contract on L1 has the same address as a contract on L2 but doesn't have the same code. We can safely ignore this
-for EOAs because they're guaranteed to have the same "code" (i.e. no code at all). This also makes
+for EOAs because they're guaranteed to have the same "code" (i.e. no code at all). This also makes
it possible for users to interact with contracts on L2 even when the Sequencer is down.
Deposit Contract Implementation: Optimism Portal
A reference implementation of the deposit contract can be found in OptimismPortal.sol.
diff --git a/protocol/derivation.html b/protocol/derivation.html
index f41f03364..f19389a21 100644
--- a/protocol/derivation.html
+++ b/protocol/derivation.html
@@ -423,7 +423,7 @@
@@ -437,17 +437,17 @@ L2 block derived from each batch. Note that we have a 1-1 batch to
block mapping here but, as we'll see later, empty blocks that do not map to batches can be inserted in cases where there
-are "gaps" in the batches posted on L1.
+are "gaps" in the batches posted on L1.
The fifth line shows the L1 attributes deposited transaction which, within each L2 block, records
information about the L1 block that matches the L2 block's epoch. The first number denotes the epoch/L1x number, while
-the second number (the "sequence number") denotes the position within the epoch.
+the second number (the "sequence number") denotes the position within the epoch.
Finally, the sixth line shows user-deposited transactions derived from the deposit
contract event mentioned earlier.
Note the 101-0
L1 attributes transaction on the bottom right of the diagram. Its presence there is only possible if
frame B2
indicates that it is the last frame within the channel and (2) no empty blocks must be inserted.
The diagram does not specify the sequencing window size in use, but from this we can infer that it must be at least 4
blocks, because the last frame of channel A
appears in block 102, but belong to epoch 99.
-As for the comment on "security types", it explains the classification of blocks as used on L1 and L2.
+As for the comment on "security types", it explains the classification of blocks as used on L1 and L2.
- Unsafe L2 blocks:
- Safe L2 blocks:
@@ -501,14 +501,14 @@ Channel Format<
where:
-batches
is the input, a sequence of batches byte-encoded as per the next section ("Batch Encoding")
+batches
is the input, a sequence of batches byte-encoded as per the next section ("Batch Encoding")
rlp_batches
is the concatenation of the RLP-encoded batches
compress
is a function performing compression, using the ZLIB algorithm (as specified in RFC-1950) with
no dictionary
channel_encoding
is the compressed version of rlp_batches
When decompressing a channel, we limit the amount of decompressed data to MAX_RLP_BYTES_PER_CHANNEL
(currently
-10,000,000 bytes), in order to avoid "zip-bomb" types of attack (where a small compressed input decompresses to a
+10,000,000 bytes), in order to avoid "zip-bomb" types of attack (where a small compressed input decompresses to a
humongous amount of data). If the decompressed data exceeds the limit, things proceeds as though the channel contained
only the first MAX_RLP_BYTES_PER_CHANNEL
decompressed bytes. The limit is set on RLP decoding, so all batches that
can be decoded in MAX_RLP_BYTES_PER_CHANNEL
will be accepted even if the size of the channel is greater than
@@ -559,7 +559,7 @@
This ensures that we use the data we already have before pulling more data and minimizes the latency of data traversing
the derivation pipeline.
@@ -672,7 +672,7 @@ Frame Queue
See Batcher transaction format and Frame format specifications.
Channel Bank
The Channel Bank stage is responsible for managing buffering from the channel bank that was written to by the L1
-retrieval stage. A step in the channel bank stage tries to read data from channels that are "ready".
+retrieval stage. A step in the channel bank stage tries to read data from channels that are "ready".
Channels are currently fully buffered until read or dropped,
streaming channels may be supported in a future version of the ChannelBank.
To bound resource usage, the Channel Bank prunes based on channel size, and times out old channels.
@@ -852,7 +852,7 @@ Engine QueueThe unsafe L2 head: blocks between the safe and unsafe heads are unsafe
blocks that have not been derived from L1. These blocks either come from sequencing (in sequencer
mode) or from unsafe sync to the sequencer (in validator mode).
-This is also known as the "latest" head.
+This is also known as the "latest" head.
Additionally, it buffers a short history of references to recently processed safe L2 blocks, along with references
from which L1 blocks each was derived.
@@ -914,8 +914,8 @@
+A successful consolidation of unsafe L2 blocks: updating the "safe" L2 block.
The first thing after a derivation pipeline reset, to ensure a consistent execution engine forkchoice state.
The new forkchoice state is applied by calling fork choice updated on the engine API.
@@ -924,7 +924,7 @@
consolidation is attempted, verifying that
existing unsafe L2 chain matches the derived L2 inputs as derived from the canonical L1 data.
During consolidation, we consider the oldest unsafe L2 block, i.e. the unsafe L2 block directly after the safe head. If
-the payload attributes match this oldest unsafe L2 block, then that block can be considered "safe" and becomes the new
+the payload attributes match this oldest unsafe L2 block, then that block can be considered "safe" and becomes the new
safe head.
The following fields of the derived L2 payload attributes are checked for equality with the L2 block:
@@ -993,7 +993,7 @@ Processing unsafe payload attributes
If no forkchoice updates or L1 data remain to be processed, and if the next possible L2 block is already available
through an unsafe source such as the sequencer publishing it via the p2p network, then it is optimistically processed as
-an "unsafe" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the
+an "unsafe" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the
user to see the head of the L2 chain faster than the L1 may confirm the L2 batches.
To process unsafe payloads, the payload must:
@@ -1119,7 +1119,7 @@
Deriving Payload Attributes
@@ -1186,20 +1186,20 @@ L1Block
gasLimit
: 375,000
data
: 0x60806040523480156100105...
(full bytecode)
sourceHash
: 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8
,
-computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Deployment"
+computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Deployment"
This results in the Ecotone L1Block contract being deployed to 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff
, to verify:
cast compute-address --nonce=0 0x4210000000000000000000000000000000000000
Computed Address: 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Deployment"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Deployment"))
# 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8
Verify data
:
git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932
pnpm clean && pnpm install && pnpm build
-jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json
+jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json
This transaction MUST deploy a contract with the following code hash
0xc88a313aa75dc4fbf0b6850d9f9ae41e04243b7008cf3eadb29256d4a71c1dfd
.
@@ -1215,7 +1215,7 @@ full bytecode)
sourceHash
: 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42
-computed with the "Upgrade-deposited" type, with `intent = "Ecotone: Gas Price Oracle Deployment"
+computed with the "Upgrade-deposited" type, with `intent = "Ecotone: Gas Price Oracle Deployment"
This results in the Ecotone GasPriceOracle contract being deployed to 0xb528D11cC114E026F138fE568744c6D45ce6Da7A
,
to verify:
@@ -1223,13 +1223,13 @@ ❯ cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Deployment"))
+❯ cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Deployment"))
# 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42
Verify data
:
git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932
pnpm clean && pnpm install && pnpm build
-jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json
+jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json
This transaction MUST deploy a contract with the following code hash
0x8b71360ea773b4cfaf1ae6d2bd15464a4e1e2e360f786e475f63aeaed8da0ae5
.
@@ -1244,14 +1244,14 @@ L1B
gasLimit
: 50,000
data
: 0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff
sourceHash
: 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc
-computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Proxy Update"
+computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Proxy Update"
Verify data:
-cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)
+cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)
0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Proxy Update"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Proxy Update"))
# 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc
GasPriceOracle Proxy Update
@@ -1266,14 +1266,14 @@ intent = "Ecotone: Gas Price Oracle Proxy Update"
Verify data:
-cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)
+cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)
0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Proxy Update"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Proxy Update"))
# 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a
GasPriceOracle Enable Ecotone
@@ -1287,18 +1287,18 @@
Verify data:
-cast sig "setEcotone()"
+cast sig "setEcotone()"
0x22b90ab3
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Set Ecotone"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Set Ecotone"))
# 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93
Beacon block roots contract deployment (EIP-4788)
-EIP-4788 introduces a "Beacon block roots" contract, that processes and exposes the beacon-block-root values.
+
EIP-4788 introduces a "Beacon block roots" contract, that processes and exposes the beacon-block-root values.
at address BEACON_ROOTS_ADDRESS = 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02
.
For deployment, EIP-4788 defines a pre-EIP-155 legacy transaction, sent from a key that is derived such that the
transaction signature validity is bound to message-hash, which is bound to the input-data, containing the init-code.
@@ -1320,7 +1320,7 @@ 0x60618060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604d57602036146024575f5ffd5b5f35801560495762001fff810690815414603c575f5ffd5b62001fff01545f5260205ff35b5f5ffd5b62001fff42064281555f359062001fff015500
isSystemTx
: false
, as per the Regolith upgrade, even the system-generated transactions spend gas.
sourceHash
: 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c
,
-computed with the "Upgrade-deposited" type, with intent = "Ecotone: beacon block roots contract deployment"
+computed with the "Upgrade-deposited" type, with intent = "Ecotone: beacon block roots contract deployment"
The contract address upon deployment is computed as rlp([sender, nonce])
, which will equal:
@@ -1333,7 +1333,7 @@
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: beacon block roots contract deployment"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: beacon block roots contract deployment"))
# 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c
Building Individual Payload Attributes
diff --git a/protocol/exec-engine.html b/protocol/exec-engine.html
index b6f4326cf..ea8d95ff5 100644
--- a/protocol/exec-engine.html
+++ b/protocol/exec-engine.html
@@ -376,7 +376,7 @@ in user JSON-RPC.
Nodes may apply L2 blocks out of band ahead of time, and then reorg when L1 data conflicts.
safeBlockHash
: block hash of the canonical chain, derived from L1 data, unlikely to reorg.
finalizedBlockHash
: irreversible block hash, matches lower boundary of the dispute period.
@@ -564,7 +564,7 @@ Worst-case sy
Ecotone: disable Blob-transactions
EIP-4844 introduces Blob transactions: featuring all the functionality of an EIP-1559 transaction,
-plus a list of "blobs": "Binary Large Object", i.e. a dedicated data type for serving Data-Availability as base-layer.
+plus a list of "blobs": "Binary Large Object", i.e. a dedicated data type for serving Data-Availability as base-layer.
With the Ecotone upgrade, all Cancun L1 execution features are enabled, with EIP-4844 as exception:
as a L2, the OP-Stack does not serve blobs, and thus disables this new transaction type.
EIP-4844 is disabled as following:
@@ -578,14 +578,14 @@ Ecotone: Beacon Block Root
-EIP-4788 introduces a "beacon block root" into the execution-layer block-header and EVM.
+
EIP-4788 introduces a "beacon block root" into the execution-layer block-header and EVM.
This block root is an SSZ hash-tree-root of the consensus-layer contents of the previous consensus block.
With the adoption of EIP-4399 in the Bedrock upgrade the OP-Stack already includes the PREVRANDAO
of L1.
And thus with EIP-4788 the L1 beacon block root is made available.
For the Ecotone upgrade, this entails that:
- The
parent_beacon_block_root
of the L1 origin is now embedded in the L2 block header.
-- The "Beacon roots contract" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis.
+- The "Beacon roots contract" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis.
- The block state-transition process now includes the same special beacon-block-root EVM processing as L1 ethereum.
diff --git a/protocol/guaranteed-gas-market.html b/protocol/guaranteed-gas-market.html
index 1f4aa469b..5c64833d8 100644
--- a/protocol/guaranteed-gas-market.html
+++ b/protocol/guaranteed-gas-market.html
@@ -192,7 +192,7 @@ Overview
initiated on L1. The gas that they use on L2 is bought on L1 via a gas burn (or a direct payment
in the future). We maintain a fee market and hard cap on the amount of gas provided to all deposits
in a single L1 block.
-The gas provided to deposited transactions is sometimes called "guaranteed gas". The gas provided to
+
The gas provided to deposited transactions is sometimes called "guaranteed gas". The gas provided to
deposited transactions is unique in the regard that it is not refundable. It cannot be refunded as
it is sometimes paid for with a gas burn and there may not be any ETH left to refund.
The guaranteed gas is composed of a gas stipend, and of any guaranteed gas the user would like
diff --git a/protocol/messengers.html b/protocol/messengers.html
index 49d41d278..7688be610 100644
--- a/protocol/messengers.html
+++ b/protocol/messengers.html
@@ -258,7 +258,7 @@
Message
into that field.
Message Version 0
abi.encodeWithSignature(
- "relayMessage(address,address,bytes,uint256)",
+ "relayMessage(address,address,bytes,uint256)",
_target,
_sender,
_message,
@@ -267,7 +267,7 @@ Message V
Message Version 1
abi.encodeWithSignature(
- "relayMessage(uint256,address,address,uint256,uint256,bytes)",
+ "relayMessage(uint256,address,address,uint256,uint256,bytes)",
_nonce,
_sender,
_target,
@@ -281,7 +281,7 @@ relayedMessages
mapping was removed.
It was built as a way to be able to fund third parties who relayed messages
on the behalf of users, but it was improperly implemented as it was impossible
to know if the relayed message actually succeeded.
diff --git a/protocol/preinstalls.html b/protocol/preinstalls.html
index 5163851b4..bdad01dea 100644
--- a/protocol/preinstalls.html
+++ b/protocol/preinstalls.html
@@ -275,7 +275,7 @@ ERC-4
ERC-4337 SenderCreator
Address: 0x7fc98430eaedbb6070b35b39d798725049088348
-Helper contract for EntryPoint, to call userOp.initCode
from a "neutral" address,
+
Helper contract for EntryPoint, to call userOp.initCode
from a "neutral" address,
which is explicitly not EntryPoint
itself.
gasLimit
: 50,000
data
: 0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff
sourceHash
: 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc
-computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Proxy Update"cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)
+cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)
0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Proxy Update"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Proxy Update"))
# 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc
GasPriceOracle Proxy Update
@@ -3709,14 +3709,14 @@ intent = "Ecotone: Gas Price Oracle Proxy Update"
Verify data:
-cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)
+cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)
0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Proxy Update"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Proxy Update"))
# 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a
GasPriceOracle Enable Ecotone
@@ -3730,18 +3730,18 @@
Verify data:
-cast sig "setEcotone()"
+cast sig "setEcotone()"
0x22b90ab3
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Set Ecotone"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Set Ecotone"))
# 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93
Beacon block roots contract deployment (EIP-4788)
-EIP-4788 introduces a "Beacon block roots" contract, that processes and exposes the beacon-block-root values.
+
EIP-4788 introduces a "Beacon block roots" contract, that processes and exposes the beacon-block-root values.
at address BEACON_ROOTS_ADDRESS = 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02
.
For deployment, EIP-4788 defines a pre-EIP-155 legacy transaction, sent from a key that is derived such that the
transaction signature validity is bound to message-hash, which is bound to the input-data, containing the init-code.
@@ -3763,7 +3763,7 @@ 0x60618060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604d57602036146024575f5ffd5b5f35801560495762001fff810690815414603c575f5ffd5b62001fff01545f5260205ff35b5f5ffd5b62001fff42064281555f359062001fff015500
isSystemTx
: false
, as per the Regolith upgrade, even the system-generated transactions spend gas.
sourceHash
: 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c
,
-computed with the "Upgrade-deposited" type, with intent = "Ecotone: beacon block roots contract deployment"
+computed with the "Upgrade-deposited" type, with intent = "Ecotone: beacon block roots contract deployment"
The contract address upon deployment is computed as rlp([sender, nonce])
, which will equal:
@@ -3776,7 +3776,7 @@
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: beacon block roots contract deployment"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: beacon block roots contract deployment"))
# 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c
Building Individual Payload Attributes
@@ -4230,7 +4230,7 @@ Batch Queue
Once validated, the batch-queue then emits a block-input for each of the blocks included in the span-batch.
The next derivation stage is thus only aware of individual block inputs, similar to the previous V0 batch,
-although not strictly a "v0 batch" anymore.
+although not strictly a "v0 batch" anymore.
Batcher
Instead of transforming L2 blocks into batches,
the blocks should be buffered to form a span-batch.
@@ -4832,7 +4832,7 @@ ERC-4
ERC-4337 SenderCreator
Address: 0x7fc98430eaedbb6070b35b39d798725049088348
-Helper contract for EntryPoint, to call userOp.initCode
from a "neutral" address,
+
Helper contract for EntryPoint, to call userOp.initCode
from a "neutral" address,
which is explicitly not EntryPoint
itself.
Superchain Configuration
@@ -5046,8 +5046,8 @@
+Recommended storage slot: bytes32(uint256(keccak256("protocolversion.recommended")) - 1)
Required getter: required()
returns ProtocolVersion
Recommended getter recommended()
returns ProtocolVersion
Version updates also emit a typed event:
@@ -5106,7 +5106,7 @@ Post-Bedrock Network upgrades
Regolith
-The Regolith upgrade, named after a material best described as "deposited dust on top of a layer of bedrock",
+
The Regolith upgrade, named after a material best described as "deposited dust on top of a layer of bedrock",
implements minor changes to deposit processing, based on reports of the Sherlock Audit-contest and findings in
the Bedrock Optimism Goerli testnet.
Summary of changes:
@@ -5304,11 +5304,11 @@ gasLimi
unsafeBlockSigner
(address
)
Blocks are gossiped around the p2p network before they are made available on L1.
To prevent denial of service on the p2p layer, these unsafe blocks must be
-signed with a particular key to be accepted as "canonical" unsafe blocks.
+signed with a particular key to be accepted as "canonical" unsafe blocks.
The address corresponding to this key is the unsafeBlockSigner
. To ensure
that its value can be fetched with a storage proof in a storage layout independent
manner, it is stored at a special storage slot corresponding to
-keccak256("systemconfig.unsafeblocksigner")
.
+keccak256("systemconfig.unsafeblocksigner")
.
Unlike the other values, the unsafeBlockSigner
only operates on blockchain
policy. It is not a consensus level parameter.
Writing the system config
@@ -5413,7 +5413,7 @@ Overview
Each of these 3 components may have different implementations, which can be combined into different proof stacks,
and contribute to proof diversity when resolving a dispute.
-"Stateless execution" of the program, and its individual instructions, refers to reproducing
+
"Stateless execution" of the program, and its individual instructions, refers to reproducing
the exact same computation by authenticating the inputs with a Pre-image Oracle.
Pre-image Oracle
@@ -5447,7 +5447,7 @@
Type 3
: Global generic key
Reserved. This scheme allows for unlimited application-layer pre-image types without fault-proof VM redeployments.
This is a generic version of a global key store: key = 0x03 ++ keccak256(x, sender)[1:]
, where:
@@ -5590,7 +5590,7 @@ Prologue
dispute game interface, in the L1 history up and till the specified l1_head
.
The dispute
may be the claim itself, or a pointer to specific prior claimed data in L1,
depending on the dispute game interface.
-
Implied inputs are loaded in a "prologue" before the actual core state-transition function executes.
+
Implied inputs are loaded in a "prologue" before the actual core state-transition function executes.
During testing a simplified prologue that loads the overrides may be used.
Note: only the test-prologues are currently supported, since the dispute game interface is actively changing.
@@ -5827,7 +5827,7 @@ Heap
result of the syscall to locate free memory. The page size is 4096.
The FPVM has a fixed program break at 0x40000000
. However, the FPVM is permitted to extend the
heap beyond this limit via mmap syscalls.
-For simplicity, there are no memory protections against "heap overruns" against other memory segments.
+For simplicity, there are no memory protections against "heap overruns" against other memory segments.
Such VM steps are still considered valid state transitions.
Specification of memory mappings is outside the scope of this document as it is irrelevant to
the VM state. FPVM implementers may refer to the Linux/MIPS kernel for inspiration.
@@ -5838,7 +5838,7 @@ Delay Slots
A VM state transition is invalid whenever the current instruction is a delay slot that is filled
with jump or branch type instruction.
That is, where while stepping on a jump/branch instruction.
-Otherwise, there would be two consecutive delay slots. While this is considered "undefined"
+Otherwise, there would be two consecutive delay slots. While this is considered "undefined"
behavior in typical MIPS implementations, FPVM must raise an exception when stepping on such states.
Syscalls
Syscalls work similar to Linux/MIPS, including the
@@ -6180,7 +6180,7 @@
Fault D
GAME_DURATION
-Game Mechanics
+ Core Game Mechanics
Subgame
A sub-game is a DAG of depth 1, where the root of the DAG is a Claim
and the children are Claim
s that counter the
@@ -6267,7 +6267,7 @@
Game Tree
Position
A position represents the location of a claim in the Game Tree. This is represented by a
-"generalized index" (or gindex) where the high-order bit is the level in the tree and the remaining
+"generalized index" (or gindex) where the high-order bit is the level in the tree and the remaining
bits is a unique bit pattern, allowing a unique identifier for each node in the tree.
The gindex of a position can be calculated as , where:
@@ -6409,7 +6409,7 @@ FDG Responses
@@ -6598,7 +6599,7 @@ Root Claims
- Do Nothing if they agree with the root claim. They do nothing because if the root
claim is left un-countered, the game resolves to their agreement.
NOTE: The honest challenger will still track this game in order to defend any subsequent
-claims made against the root claim - in effect, "playing the game".
+claims made against the root claim - in effect, "playing the game".
Countering Invalid Claims
For every claim made in a dispute game with a game tree
@@ -6712,6 +6713,20 @@
Resolution
challengers are economically incentivized to resolve the game promptly to capture the bonds.
Bond Incentives
+
+
+Table of Contents
+
+- Overview
+- Moves
+- Subgame Resolution
+
+
+
+
+Overview
Bonds is an add-on to the core Fault Dispute Game. The core game mechanics are
designed to ensure honesty as the best response to winning subgames. By introducing financial incentives,
Bonds makes it worthwhile for honest challengers to participate.
@@ -6759,8 +6774,8 @@
Glossary
- EOA
- Merkle Patricia Trie
- Chain Re-Organization
-- Predeployed Contract ("Predeploy")
-- Preinstalled Contract ("Preinstall")
+- Predeployed Contract ("Predeploy")
+- Preinstalled Contract ("Preinstall")
- Receipt
- Transaction Type
- Fork Choice Rule
@@ -6863,7 +6878,7 @@ Block
block, and output block properties, which are derived after executing the block's transactions. These include various
Merkle Patricia Trie roots that notably commit to the L2 state and to the log events emitted during execution.
EOA
-"Externally Owned Account", an Ethereum term to designate addresses operated by users, as opposed to contract addresses.
+"Externally Owned Account", an Ethereum term to designate addresses operated by users, as opposed to contract addresses.
Merkle Patricia Trie
A Merkle Patricia Trie (MPT) is a sparse trie, which is a tree-like structure that maps keys to values.
The root hash of a MPT is a commitment to the contents of the tree, which allows a
@@ -6874,10 +6889,10 @@
C
the fork choice rule) to a block that is not a child of the previous head.
L1 re-orgs can happen because of network conditions or attacks. L2 re-orgs are a consequence of L1 re-orgs, mediated via
L2 chain derivation.
-Predeployed Contract ("Predeploy")
+Predeployed Contract ("Predeploy")
A contract placed in the L2 genesis state (i.e. at the start of the chain).
All predeploy contracts are specified in the predeploys specification.
-Preinstalled Contract ("Preinstall")
+Preinstalled Contract ("Preinstall")
A contract placed in the L2 genesis state (i.e. at the start of the chain). These contracts do not share the same
security guarantees as predeploys, but are general use contracts made
available to improve the L2's UX.
@@ -6935,9 +6950,9 @@ L1 Origin
Deposits
In general, a deposit is an L2 transaction derived from an L1 block (by the rollup driver).
-While transaction deposits are notably (but not only) used to "deposit" (bridge) ETH and tokens to L2, the word
-deposit should be understood as "a transaction deposited to L2 from L1".
-This term deposit is somewhat ambiguous as these "transactions" exist at multiple levels. This section disambiguates
+
While transaction deposits are notably (but not only) used to "deposit" (bridge) ETH and tokens to L2, the word
+deposit should be understood as "a transaction deposited to L2 from L1".
+This term deposit is somewhat ambiguous as these "transactions" exist at multiple levels. This section disambiguates
all deposit-related terms.
Notably, a deposit can refer to:
@@ -6995,7 +7010,7 @@ Withdrawals
TODO expand this whole section to be clearer
In general, a withdrawal is a transaction sent from L2 to L1 that may transfer data and/or value.
-The term withdrawal is somewhat ambiguous as these "transactions" exist at multiple levels. In order to differentiate
+
The term withdrawal is somewhat ambiguous as these "transactions" exist at multiple levels. In order to differentiate
between the L1 and L2 components of a withdrawal we introduce the following terms:
- A withdrawal initiating transaction refers specifically to a transaction on L2 sent to the Withdrawals predeploy.
@@ -7015,12 +7030,12 @@ Final
Batch Submission
Data Availability
-Data availability is the guarantee that some data will be "available" (i.e. retrievable) during a reasonably long time
+
Data availability is the guarantee that some data will be "available" (i.e. retrievable) during a reasonably long time
window. In Optimism's case, the data in question are sequencer batches that validators
need in order to verify the sequencer's work and validate the L2 chain.
The finalization period should be taken as the lower bound on the availability window, since
that is when data availability is the most crucial, as it is needed to perform a fault proof.
-"Availability" does not mean guaranteed long-term storage of the data.
+"Availability" does not mean guaranteed long-term storage of the data.
Data Availability Provider
A data availability provider is a service that can be used to make data available. See the Data
Availability for more information on what this means.
@@ -7128,7 +7143,7 @@ L2 Genesis
- State inherited from the previous version of the L2 chain.
-- This state was possibly modified by "state surgeries". For instance, the migration to Bedrock entailed changes on
+
- This state was possibly modified by "state surgeries". For instance, the migration to Bedrock entailed changes on
how native ETH balances were stored in the storage trie.
@@ -7182,7 +7197,7 @@ Rollup Node
In sequencer mode, the rollup node receives L2 transactions from users, which it uses to create L2 blocks. These are
then submitted to a data availability provider via batch submission. The L2 chain
derivation then acts as a sanity check and a way to detect L1 chain re-orgs.
-In validator mode, the rollup node performs derivation as indicated above, but is also able to "run ahead" of the L1
+
In validator mode, the rollup node performs derivation as indicated above, but is also able to "run ahead" of the L1
chain by getting blocks directly from the sequencer, in which case derivation serves to validate the sequencer's
behaviour.
A rollup node running in validator mode is sometimes called a replica.
@@ -7194,7 +7209,7 @@ Rollup Driver
The rollup driver is the rollup node component responsible for deriving the L2 chain
from the L1 chain (L1 blocks and their associated receipts).
-TODO delete this entry, alongside its reference — can be replaced by "derivation process" or "derivation logic"
+
TODO delete this entry, alongside its reference — can be replaced by "derivation process" or "derivation logic"
where needed
L1 Attributes Predeployed Contract
@@ -7219,7 +7234,7 @@ Fault Proof
cf. Fault Proofs
Time Slot
On L2, there is a block every 2 second (this duration is known as the block time).
-We say that there is a "time slot" every multiple of 2s after the timestamp of the L2 genesis block.
+We say that there is a "time slot" every multiple of 2s after the timestamp of the L2 genesis block.
On L1, post-merge, the time slots are every 12s. However, an L1 block may not be produced for every time slot, in case
of even benign consensus issues.
Block Time
@@ -7241,7 +7256,7 @@ Execution E
engine (using transactions from the L1 mempool), at the request of the L1 consensus layer.
On L2, the executed blocks are freshly minted by the execution engine at the request of the rollup node,
using transactions derived from L1 blocks.
-In these specifications, "execution engine" always refer to the L2 execution engine, unless otherwise specified.
+In these specifications, "execution engine" always refer to the L2 execution engine, unless otherwise specified.
diff --git a/protocol/deposits.html b/protocol/deposits.html
index de6bf9f67..bf0f25136 100644
--- a/protocol/deposits.html
+++ b/protocol/deposits.html
@@ -592,7 +592,7 @@ Address Ali
0x1111000000000000000000000000000000001111
to it. The math is unchecked
and done on a
Solidity uint160
so the value will overflow. This prevents attacks in which a
contract on L1 has the same address as a contract on L2 but doesn't have the same code. We can safely ignore this
-for EOAs because they're guaranteed to have the same "code" (i.e. no code at all). This also makes
+for EOAs because they're guaranteed to have the same "code" (i.e. no code at all). This also makes
it possible for users to interact with contracts on L2 even when the Sequencer is down.
Deposit Contract Implementation: Optimism Portal
A reference implementation of the deposit contract can be found in OptimismPortal.sol.
diff --git a/protocol/derivation.html b/protocol/derivation.html
index f41f03364..f19389a21 100644
--- a/protocol/derivation.html
+++ b/protocol/derivation.html
@@ -423,7 +423,7 @@
@@ -437,17 +437,17 @@ L2 block derived from each batch. Note that we have a 1-1 batch to
block mapping here but, as we'll see later, empty blocks that do not map to batches can be inserted in cases where there
-are "gaps" in the batches posted on L1.
+are "gaps" in the batches posted on L1.
The fifth line shows the L1 attributes deposited transaction which, within each L2 block, records
information about the L1 block that matches the L2 block's epoch. The first number denotes the epoch/L1x number, while
-the second number (the "sequence number") denotes the position within the epoch.
+the second number (the "sequence number") denotes the position within the epoch.
Finally, the sixth line shows user-deposited transactions derived from the deposit
contract event mentioned earlier.
Note the 101-0
L1 attributes transaction on the bottom right of the diagram. Its presence there is only possible if
frame B2
indicates that it is the last frame within the channel and (2) no empty blocks must be inserted.
The diagram does not specify the sequencing window size in use, but from this we can infer that it must be at least 4
blocks, because the last frame of channel A
appears in block 102, but belong to epoch 99.
-As for the comment on "security types", it explains the classification of blocks as used on L1 and L2.
+As for the comment on "security types", it explains the classification of blocks as used on L1 and L2.
- Unsafe L2 blocks:
- Safe L2 blocks:
@@ -501,14 +501,14 @@ Channel Format<
where:
-batches
is the input, a sequence of batches byte-encoded as per the next section ("Batch Encoding")
+batches
is the input, a sequence of batches byte-encoded as per the next section ("Batch Encoding")
rlp_batches
is the concatenation of the RLP-encoded batches
compress
is a function performing compression, using the ZLIB algorithm (as specified in RFC-1950) with
no dictionary
channel_encoding
is the compressed version of rlp_batches
When decompressing a channel, we limit the amount of decompressed data to MAX_RLP_BYTES_PER_CHANNEL
(currently
-10,000,000 bytes), in order to avoid "zip-bomb" types of attack (where a small compressed input decompresses to a
+10,000,000 bytes), in order to avoid "zip-bomb" types of attack (where a small compressed input decompresses to a
humongous amount of data). If the decompressed data exceeds the limit, things proceeds as though the channel contained
only the first MAX_RLP_BYTES_PER_CHANNEL
decompressed bytes. The limit is set on RLP decoding, so all batches that
can be decoded in MAX_RLP_BYTES_PER_CHANNEL
will be accepted even if the size of the channel is greater than
@@ -559,7 +559,7 @@
This ensures that we use the data we already have before pulling more data and minimizes the latency of data traversing
the derivation pipeline.
@@ -672,7 +672,7 @@ Frame Queue
See Batcher transaction format and Frame format specifications.
Channel Bank
The Channel Bank stage is responsible for managing buffering from the channel bank that was written to by the L1
-retrieval stage. A step in the channel bank stage tries to read data from channels that are "ready".
+retrieval stage. A step in the channel bank stage tries to read data from channels that are "ready".
Channels are currently fully buffered until read or dropped,
streaming channels may be supported in a future version of the ChannelBank.
To bound resource usage, the Channel Bank prunes based on channel size, and times out old channels.
@@ -852,7 +852,7 @@ Engine QueueThe unsafe L2 head: blocks between the safe and unsafe heads are unsafe
blocks that have not been derived from L1. These blocks either come from sequencing (in sequencer
mode) or from unsafe sync to the sequencer (in validator mode).
-This is also known as the "latest" head.
+This is also known as the "latest" head.
Additionally, it buffers a short history of references to recently processed safe L2 blocks, along with references
from which L1 blocks each was derived.
@@ -914,8 +914,8 @@
+A successful consolidation of unsafe L2 blocks: updating the "safe" L2 block.
The first thing after a derivation pipeline reset, to ensure a consistent execution engine forkchoice state.
The new forkchoice state is applied by calling fork choice updated on the engine API.
@@ -924,7 +924,7 @@
consolidation is attempted, verifying that
existing unsafe L2 chain matches the derived L2 inputs as derived from the canonical L1 data.
During consolidation, we consider the oldest unsafe L2 block, i.e. the unsafe L2 block directly after the safe head. If
-the payload attributes match this oldest unsafe L2 block, then that block can be considered "safe" and becomes the new
+the payload attributes match this oldest unsafe L2 block, then that block can be considered "safe" and becomes the new
safe head.
The following fields of the derived L2 payload attributes are checked for equality with the L2 block:
@@ -993,7 +993,7 @@ Processing unsafe payload attributes
If no forkchoice updates or L1 data remain to be processed, and if the next possible L2 block is already available
through an unsafe source such as the sequencer publishing it via the p2p network, then it is optimistically processed as
-an "unsafe" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the
+an "unsafe" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the
user to see the head of the L2 chain faster than the L1 may confirm the L2 batches.
To process unsafe payloads, the payload must:
@@ -1119,7 +1119,7 @@
Deriving Payload Attributes
@@ -1186,20 +1186,20 @@ L1Block
gasLimit
: 375,000
data
: 0x60806040523480156100105...
(full bytecode)
sourceHash
: 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8
,
-computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Deployment"
+computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Deployment"
This results in the Ecotone L1Block contract being deployed to 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff
, to verify:
cast compute-address --nonce=0 0x4210000000000000000000000000000000000000
Computed Address: 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Deployment"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Deployment"))
# 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8
Verify data
:
git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932
pnpm clean && pnpm install && pnpm build
-jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json
+jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json
This transaction MUST deploy a contract with the following code hash
0xc88a313aa75dc4fbf0b6850d9f9ae41e04243b7008cf3eadb29256d4a71c1dfd
.
@@ -1215,7 +1215,7 @@ full bytecode)
sourceHash
: 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42
-computed with the "Upgrade-deposited" type, with `intent = "Ecotone: Gas Price Oracle Deployment"
+computed with the "Upgrade-deposited" type, with `intent = "Ecotone: Gas Price Oracle Deployment"
This results in the Ecotone GasPriceOracle contract being deployed to 0xb528D11cC114E026F138fE568744c6D45ce6Da7A
,
to verify:
@@ -1223,13 +1223,13 @@ ❯ cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Deployment"))
+❯ cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Deployment"))
# 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42
Verify data
:
git checkout 5996d0bc1a4721f2169ba4366a014532f31ea932
pnpm clean && pnpm install && pnpm build
-jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json
+jq -r ".bytecode.object" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json
This transaction MUST deploy a contract with the following code hash
0x8b71360ea773b4cfaf1ae6d2bd15464a4e1e2e360f786e475f63aeaed8da0ae5
.
@@ -1244,14 +1244,14 @@ L1B
gasLimit
: 50,000
data
: 0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff
sourceHash
: 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc
-computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Proxy Update"
+computed with the "Upgrade-deposited" type, with `intent = "Ecotone: L1 Block Proxy Update"
Verify data:
-cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)
+cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)
0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Proxy Update"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: L1 Block Proxy Update"))
# 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc
GasPriceOracle Proxy Update
@@ -1266,14 +1266,14 @@ intent = "Ecotone: Gas Price Oracle Proxy Update"
Verify data:
-cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)
+cast concat-hex $(cast sig "upgradeTo(address)") $(cast abi-encode "upgradeTo(address)" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)
0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Proxy Update"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Proxy Update"))
# 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a
GasPriceOracle Enable Ecotone
@@ -1287,18 +1287,18 @@
Verify data:
-cast sig "setEcotone()"
+cast sig "setEcotone()"
0x22b90ab3
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Set Ecotone"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: Gas Price Oracle Set Ecotone"))
# 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93
Beacon block roots contract deployment (EIP-4788)
-EIP-4788 introduces a "Beacon block roots" contract, that processes and exposes the beacon-block-root values.
+
EIP-4788 introduces a "Beacon block roots" contract, that processes and exposes the beacon-block-root values.
at address BEACON_ROOTS_ADDRESS = 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02
.
For deployment, EIP-4788 defines a pre-EIP-155 legacy transaction, sent from a key that is derived such that the
transaction signature validity is bound to message-hash, which is bound to the input-data, containing the init-code.
@@ -1320,7 +1320,7 @@ 0x60618060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604d57602036146024575f5ffd5b5f35801560495762001fff810690815414603c575f5ffd5b62001fff01545f5260205ff35b5f5ffd5b62001fff42064281555f359062001fff015500
isSystemTx
: false
, as per the Regolith upgrade, even the system-generated transactions spend gas.
sourceHash
: 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c
,
-computed with the "Upgrade-deposited" type, with intent = "Ecotone: beacon block roots contract deployment"
+computed with the "Upgrade-deposited" type, with intent = "Ecotone: beacon block roots contract deployment"
The contract address upon deployment is computed as rlp([sender, nonce])
, which will equal:
@@ -1333,7 +1333,7 @@
Verify sourceHash
:
-cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: beacon block roots contract deployment"))
+cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak "Ecotone: beacon block roots contract deployment"))
# 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c
Building Individual Payload Attributes
diff --git a/protocol/exec-engine.html b/protocol/exec-engine.html
index b6f4326cf..ea8d95ff5 100644
--- a/protocol/exec-engine.html
+++ b/protocol/exec-engine.html
@@ -376,7 +376,7 @@ in user JSON-RPC.
Nodes may apply L2 blocks out of band ahead of time, and then reorg when L1 data conflicts.
safeBlockHash
: block hash of the canonical chain, derived from L1 data, unlikely to reorg.
finalizedBlockHash
: irreversible block hash, matches lower boundary of the dispute period.
@@ -564,7 +564,7 @@ Worst-case sy
Ecotone: disable Blob-transactions
EIP-4844 introduces Blob transactions: featuring all the functionality of an EIP-1559 transaction,
-plus a list of "blobs": "Binary Large Object", i.e. a dedicated data type for serving Data-Availability as base-layer.
+plus a list of "blobs": "Binary Large Object", i.e. a dedicated data type for serving Data-Availability as base-layer.
With the Ecotone upgrade, all Cancun L1 execution features are enabled, with EIP-4844 as exception:
as a L2, the OP-Stack does not serve blobs, and thus disables this new transaction type.
EIP-4844 is disabled as following:
@@ -578,14 +578,14 @@ Ecotone: Beacon Block Root
-EIP-4788 introduces a "beacon block root" into the execution-layer block-header and EVM.
+
EIP-4788 introduces a "beacon block root" into the execution-layer block-header and EVM.
This block root is an SSZ hash-tree-root of the consensus-layer contents of the previous consensus block.
With the adoption of EIP-4399 in the Bedrock upgrade the OP-Stack already includes the PREVRANDAO
of L1.
And thus with EIP-4788 the L1 beacon block root is made available.
For the Ecotone upgrade, this entails that:
- The
parent_beacon_block_root
of the L1 origin is now embedded in the L2 block header.
-- The "Beacon roots contract" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis.
+- The "Beacon roots contract" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis.
- The block state-transition process now includes the same special beacon-block-root EVM processing as L1 ethereum.
diff --git a/protocol/guaranteed-gas-market.html b/protocol/guaranteed-gas-market.html
index 1f4aa469b..5c64833d8 100644
--- a/protocol/guaranteed-gas-market.html
+++ b/protocol/guaranteed-gas-market.html
@@ -192,7 +192,7 @@ Overview
initiated on L1. The gas that they use on L2 is bought on L1 via a gas burn (or a direct payment
in the future). We maintain a fee market and hard cap on the amount of gas provided to all deposits
in a single L1 block.
-The gas provided to deposited transactions is sometimes called "guaranteed gas". The gas provided to
+
The gas provided to deposited transactions is sometimes called "guaranteed gas". The gas provided to
deposited transactions is unique in the regard that it is not refundable. It cannot be refunded as
it is sometimes paid for with a gas burn and there may not be any ETH left to refund.
The guaranteed gas is composed of a gas stipend, and of any guaranteed gas the user would like
diff --git a/protocol/messengers.html b/protocol/messengers.html
index 49d41d278..7688be610 100644
--- a/protocol/messengers.html
+++ b/protocol/messengers.html
@@ -258,7 +258,7 @@
Message
into that field.
Message Version 0
abi.encodeWithSignature(
- "relayMessage(address,address,bytes,uint256)",
+ "relayMessage(address,address,bytes,uint256)",
_target,
_sender,
_message,
@@ -267,7 +267,7 @@ Message V
Message Version 1
abi.encodeWithSignature(
- "relayMessage(uint256,address,address,uint256,uint256,bytes)",
+ "relayMessage(uint256,address,address,uint256,uint256,bytes)",
_nonce,
_sender,
_target,
@@ -281,7 +281,7 @@ relayedMessages
mapping was removed.
It was built as a way to be able to fund third parties who relayed messages
on the behalf of users, but it was improperly implemented as it was impossible
to know if the relayed message actually succeeded.
diff --git a/protocol/preinstalls.html b/protocol/preinstalls.html
index 5163851b4..bdad01dea 100644
--- a/protocol/preinstalls.html
+++ b/protocol/preinstalls.html
@@ -275,7 +275,7 @@ ERC-4
ERC-4337 SenderCreator
Address: 0x7fc98430eaedbb6070b35b39d798725049088348
-Helper contract for EntryPoint, to call userOp.initCode
from a "neutral" address,
+
Helper contract for EntryPoint, to call userOp.initCode
from a "neutral" address,
which is explicitly not EntryPoint
itself.