Profile of testinprod_io in Optimism

Posts by testinprod_io

• [FINAL] Upgrade Proposal #3: Delta Network Upgrade by testinprod_io - No Role
  Posted on: Jan. 19, 2024, 9:39 a.m.
  Content: Hello! We are proposing the Mainnet activation at 00 : 00 : 00 , Feb 22 , 2024 UTC. testinprod_io: (Proposed) Mainnet activation at 00 : 00 : 00 , Feb 22 , 2024 UTC.
  Likes: 7 Replies: 0
  Likers: 0x666, gonna.eth, joxes, polynya, limes.eth, cruzdanilo, fractalvisions
  No replies yet.
• [FINAL] Upgrade Proposal #3: Delta Network Upgrade by testinprod_io - No Role
  Posted on: Jan. 19, 2024, 4:39 a.m.
  Content: Hello! We are proposing the Mainnet activation at 00 : 00 : 00 , Feb 22 , 2024 UTC. testinprod_io: (Proposed) Mainnet activation at 00 : 00 : 00 , Feb 22 , 2024 UTC.
  Likes: 7 Replies: 0
  Likers: 0x666, Gonna.eth, Joxes, polynya, limes.eth, cruzdanilo, FractalVisions
  No replies yet.
• [FINAL] Upgrade Proposal #3: Delta Network Upgrade by testinprod_io - No Role
  Posted on: Jan. 10, 2024, 6:02 p.m.
  Content: testinprod_io: L 1 -confirmed block reorgs (safe block), Correction: it’s a Sequencer’s pre-confirmed blocks reorgs—unsafe head.
  Likes: 2 Replies: 0
  Likers: joxes, fractalvisions
  No replies yet.
• [FINAL] Upgrade Proposal #3: Delta Network Upgrade by testinprod_io - No Role
  Posted on: Jan. 10, 2024, 4:34 p.m.
  Content: Joxes: So, in this case, does the sequencer provide the confirmation, but the batcher not include the actual tx in the batch? Yes. That is correct. Joxes: I want to make sure I understand the worst case impact on users and services. The worst-case impact on users & services is the L 1 -confirmed block reorgs (safe block), which are triggered by various situations–for example, when the batcher omits a transaction. It won’t halt the sequencer’s pre-confirmed block progression. That’s why we expect end users to be less likely to be impacted in the majority of failure scenarios. Please let us know if you have any more questions! Happy to answer :slight_smile:
  Likes: 2 Replies: 2
  Likers: joxes, fractalvisions
  Replies:

  • Joxes: Thank you for clarifying @testinprod_io. I will come with more questions if necessary. I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.
  • testinprod_io: testinprod_io: L1-confirmed block reorgs (safe block), Correction: it’s a Sequencer’s pre-confirmed blocks reorgs—unsafe head.
• [FINAL] Upgrade Proposal #3: Delta Network Upgrade by testinprod_io - No Role
  Posted on: Jan. 10, 2024, 1:02 p.m.
  Content: testinprod_io: L 1 -confirmed block reorgs (safe block), Correction: it’s a Sequencer’s pre-confirmed blocks reorgs—unsafe head.
  Likes: 2 Replies: 0
  Likers: Joxes, FractalVisions
  No replies yet.
• [FINAL] Upgrade Proposal #3: Delta Network Upgrade by testinprod_io - No Role
  Posted on: Jan. 10, 2024, 11:34 a.m.
  Content: Joxes: So, in this case, does the sequencer provide the confirmation, but the batcher not include the actual tx in the batch? Yes. That is correct. Joxes: I want to make sure I understand the worst case impact on users and services. The worst-case impact on users & services is the L 1 -confirmed block reorgs (safe block), which are triggered by various situations–for example, when the batcher omits a transaction. It won’t halt the sequencer’s pre-confirmed block progression. That’s why we expect end users to be less likely to be impacted in the majority of failure scenarios. Please let us know if you have any more questions! Happy to answer :slight_smile:
  Likes: 2 Replies: 2
  Likers: Joxes, FractalVisions
  Replies:

  • Joxes: Thank you for clarifying @testinprod_io. I will come with more questions if necessary. I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.
  • testinprod_io: testinprod_io: L1-confirmed block reorgs (safe block), Correction: it’s a Sequencer’s pre-confirmed blocks reorgs—unsafe head.
• [FINAL] Upgrade Proposal #3: Delta Network Upgrade by testinprod_io - No Role
  Posted on: Jan. 10, 2024, 7:16 a.m.
  Content: Hi Joxes! Thanks for the question. Joxes: is this when the proposer generates and posts a new state root, right? No. This case refers to when the op-batcher has an unexpected bug where it omits some transactions. Joxes: The proposer would just ignore the batch -or a portion of it-?. The proposer cannot omit any portion of the batch. Let us know if you have any more questions!
  Likes: 4 Replies: 0
  Likers: lavande, pumbi, joxes, fractalvisions
  No replies yet.
• [FINAL] Upgrade Proposal #3: Delta Network Upgrade by testinprod_io - No Role
  Posted on: Jan. 10, 2024, 2:16 a.m.
  Content: Hi Joxes! Thanks for the question. Joxes: is this when the proposer generates and posts a new state root, right? No. This case refers to when the op-batcher has an unexpected bug where it omits some transactions. Joxes: The proposer would just ignore the batch -or a portion of it-?. The proposer cannot omit any portion of the batch. Let us know if you have any more questions!
  Likes: 4 Replies: 0
  Likers: lavande, Pumbi, Joxes, FractalVisions
  No replies yet.
• [FINAL] Upgrade Proposal #3: Delta Network Upgrade by testinprod_io - No Role
  Posted on: Jan. 5, 2024, 7:35 a.m.
  Content: Executive Summary Test in Prod proposes Delta network upgrade, which activates Span Batches for OP Mainnet and all other OP Chains. Span Batches implement a new batching specification that reduces L 1 costs by ~ 97 % for inactive chains 42 ( 165 ETH → 5 ETH). We expect Span Batches to derisk launching new OP Chains by meaningfully reducing L 1 costs for inactive chains. Hello! This is Test in Prod, one of the core development teams 16 of Optimism Collective. This is a proposal for the Delta network upgrade, which activates Span Batches. Span Batches is a new batching spec from Test in Prod, building upon initial designs by Protolambda. Span Batches removes the overhead of the current batching specs by encoding consecutive L 2 blocks into one batch. This leads to reducing L 1 costs by ~ 97 % for inactive chains, and 6 %~ 11 % for performant chains like OP Mainnet or Base Mainnet based on our backtesting results 15 . Span Batches will support the adoption of the OP Stack by meaningfully reducing L 1 costs for OP Chains, therefore reducing the risks of launching new L 2 s with the OP Stack. Technical Summary Specification This upgrade (“Delta”) contains a single consensus-layer feature, Span Batches. Please refer to the following documents for the technical information on Span Batches: Design Docs 30 Spec Docs 18 Github Issue Tracker 10 Research Repository 2 (includes backtesting results & code for various OP Chains) Security Considerations The Span Batch is a consensus-critical feature. It is not required to undergo a security audit according to the OP Labs Audit Framework 6 ; Span Batches impacts liveness & reputational quadrant, instead of existential & safety parts in the rubrics of the Audit Framework—specifically derivation aside from deposits and batching. The Audit Framework doesn’t suggest audits in the liveness & reputational quadrant, but rather testing via progressive real-world usage. The Span Batch doesn’t have changes on the state transitions, so there is no possibility that users’ states can change in an unintended way. In the worst case, some transactions could be omitted. Therefore, Test in Prod went through the following steps to ensure the safety of this proposal, focusing on the liveness parts: 1 ) Security review with OP Labs Test in Prod passed a security review with OP Labs. Since the Delta upgrade isn’t related to user assets, but instead implements a consensus upgrade, we focused on reviewing cases where the consensus could fail and built contingency plans for the failure. Please refer to the Contingency Plans section in the current proposal for detailed contingency plans. Throughout the review, we figured that the Span Batch deployment would be less likely to impact Sequencer’s pre-confirming block production—the unsafe head progression; we expect end users to be less likely to be impacted in the majority of failure scenarios. 2 ) Ran verification script on Superchain Devnet & Testnets Test in Prod prepared the verification script 1 for Span Batches. The script checks the entire consensus process from posting batches on L 1 to deriving L 2 blocks from L 1 . It tests if there’s a consensus failure by detecting unsafe reorgs—ensuring nodes derive the same state that the Sequencer originally calculated before posting batches. Please refer to the Functionality Verification Guide 5 for more details. The verification script works as follows: Send various types of transactions to the L 2 . Record the transactions’ hashes & included unsafe blocks’ hashes. Poll if the included blocks are consolidated to safe. Compare recorded unsafe blocks’ hashes to safe blocks that include transactions. If same, it’s a success! 3 ) E 2 E tests & unit tests Test in Prod prepared the e 2 e tests & unit tests for Span Batches. They cover a wide range of scenarios and check if the code operates as intended. Here are Github PRs for e 2 e tests: # 1 1 # 2 1 # 3 1 Impact Summary Performance Impact Span Batch saves more L 1 fees than the current state of the OP Stack, and savings increase the less active the chain is. Therefore, Test in Prod expects more savings on L 1 fees for less-active chains; we expect to save L 1 fees by ~ 97 % for low-throughput chains and 6 %~ 11 % for high-throughput chains like OP Mainnet or Base Mainnet. Test in Prod backtested several OP Chains and prepared the expected L 1 fee savings in %. Please refer to the Expected Result section in the Design Docs 15 for the result. User Impact Delta doesn’t include any direct impact on the users’ side. Also, Test in Prod doesn’t expect downtime for the Delta upgrade. Node Impact Nodes will be unable to sync the chain if nodes don’t perform the software update until the op-batcher operator starts posting Span Batches. Thus, nodes are required to update software versions to keep in sync with the OP Chains. Please refer to the Guides for Nodes section in the current proposal for the upgrade details. Upgrade Details After Delta hard fork, Span Batches submission won’t be activated automatically; the op-batcher operators should restart their instance with the Span Batches enabled. Therefore, even though Delta hard fork time passes, nothing will happen until the op-batcher operator explicitly starts posting batches in the Span Batch. OP Chains can use (post & derive) both Singular Batches and Span Batches after the Delta hard fork. Action Plans Timeline (including finished items) Test in Prod proposes 00 : 00 : 00 Feb 22 , 2024 , UTC for the Delta hard fork time— 1707922800 in Unix Timestamp. It’s three weeks after Voting Cycle # 17 ends, and two weeks after the Citizens’ House veto period. The Delta upgrade has already been activated on op-goerli, op-sepolia, base-goerli, base-sepolia, pgn-sepolia, zora-sepolia, and Superchain Devnet (operated by OP Labs, Base, and Conduit). Here’s the list of the timeline for Delta including finished items: Superchain Devnet activation at 00 : 00 : 00 , Dec 08 , 2023 UTC. Goerli Testnets activation at 00 : 00 : 00 , Dec 21 , 2023 UTC. Sepolia Testnets activation at 00 : 00 : 00 , Dec 22 , 2023 UTC. Voting results are final & start to notify upgrading nodes at 19 : 00 : 00 , Jan 31 , 2024 UTC. Including the one-week veto period. (Proposed) Mainnet activation at 00 : 00 : 00 , Feb 22 , 2024 UTC. Appended one week due to the veto period. Contingency Plans Our contingency plans for the unexpected failure of the Delta upgrade are as follows: op-batcher disables posting Span Batches, start posting legacy batches (Singular Batches), prepare the fix, and enable Span Batches again. In this way, we expect the impact on the user side will be minimized while resolving the issues—the sequencer would continue pre-confirming blocks as normal, but batch submission would be halted until the op-batcher restarts to push Singular Batches. However, if there’s an unexpected critical issue where we need nodes’ action, we have prepared a way for nodes to disable the upgrade by using --override.delta flag on op-node. Test in Prod will work with OP Labs to monitor, communicate, and alert relevant parties upon the upgrade in such cases. Software versions The code for the Delta upgrade is ready in the following Optimism monorepo hash: 54 a 7 dbf 8 aa 9 b 982 f 9 c 6 a 54 cbbe 448 be 41 c 0 b 7 bc 7 6 . Nodes can manually set the Delta hard fork time with the preceding code. However, nodes will not automatically activate Delta on Mainnet as the Delta hard fork time is not embedded in the code; it cannot be embedded since Delta has not yet been approved by governance. If the governance approves the Delta hard fork and finalizes the hard fork time, Test in Prod will work with OP Labs to prepare the new release that embeds the Mainnet hard fork time and notify the community. With the new release, nodes won’t have to manually set the Delta hard fork time; but they will automatically activate the Delta upgrade. The following versions are deployed in the testnets: op-node: v 1 . 4 . 1 1 op-batcher: v 1 . 4 . 1 op-proposer: v 1 . 4 . 1 op-geth: v 1 . 101304 . 2 Guides for Node Operators Node operators are required to upgrade the software versions. Please refer to the following guides: Delta Upgrade Guide in Optimism Docs 8 Delta Node Upgrade Guide 4 (For op-batcher operators) Delta Hard Fork Functionality Verification Guide 5 Conclusion This proposal outlines the Delta upgrade that includes Span Batches. This upgrade reduces the size overheads of the current specs in a significant step for less-active chains, and it leads to alleviating the risks of launching new OP Stack L 2 s. By reducing the L 1 fees and risks with the Delta upgrade, we expect to alleviate burdens for less-active chains, help easier adoptions of the OP Stack, and head one step forward to the Superchain future. We don’t expect sequencer downtime for the Delta hard fork & activating Span Batches.
  Likes: 22 Replies: 2
  Likers: danftz, bobby, harper, raho, lavande, polynya, joxes, pgov, butterbum, chain_l, cpoetter, mastermojo, philliprossii, chooose, moneymandoug, joseebasanta, ms1, kutubu, revmiller, jepsen, fractalvisions, fujiar
  Replies:

  • Joxes: Hey! It’s great to see this proposal posted in the forum. testinprod_io: The Span Batch doesn’t have changes on the state transitions, so there is no possibility that users’ states can change in an unintended way. In the worst case, some transactions could be omitted. For now, I have a quick question about this sentence, in the worst case, some transactions could be omitted: is this when the proposer generates and posts a new state root, right? The proposer would just ignore the batch -or a portion of it-?. Is this the case, or are we talking about another situation in particular?
  • testinprod_io: Hello! We are proposing the Mainnet activation at 00:00:00, Feb 22, 2024 UTC. testinprod_io: (Proposed) Mainnet activation at 00:00:00, Feb 22, 2024 UTC.
• [FINAL] Upgrade Proposal #3: Delta Network Upgrade by testinprod_io - No Role
  Posted on: Jan. 5, 2024, 2:35 a.m.
  Content: Executive Summary Test in Prod proposes Delta network upgrade, which activates Span Batches for OP Mainnet and all other OP Chains. Span Batches implement a new batching specification that reduces L 1 costs by ~ 97 % for inactive chains 50 ( 165 ETH → 5 ETH). We expect Span Batches to derisk launching new OP Chains by meaningfully reducing L 1 costs for inactive chains. Hello! This is Test in Prod, one of the core development teams 21 of Optimism Collective. This is a proposal for the Delta network upgrade, which activates Span Batches. Span Batches is a new batching spec from Test in Prod, building upon initial designs by Protolambda. Span Batches removes the overhead of the current batching specs by encoding consecutive L 2 blocks into one batch. This leads to reducing L 1 costs by ~ 97 % for inactive chains, and 6 %~ 11 % for performant chains like OP Mainnet or Base Mainnet based on our backtesting results 18 . Span Batches will support the adoption of the OP Stack by meaningfully reducing L 1 costs for OP Chains, therefore reducing the risks of launching new L 2 s with the OP Stack. Technical Summary Specification This upgrade (“Delta”) contains a single consensus-layer feature, Span Batches. Please refer to the following documents for the technical information on Span Batches: Design Docs 33 Spec Docs 23 Github Issue Tracker 11 Research Repository 3 (includes backtesting results & code for various OP Chains) Security Considerations The Span Batch is a consensus-critical feature. It is not required to undergo a security audit according to the OP Labs Audit Framework 7 ; Span Batches impacts liveness & reputational quadrant, instead of existential & safety parts in the rubrics of the Audit Framework—specifically derivation aside from deposits and batching. The Audit Framework doesn’t suggest audits in the liveness & reputational quadrant, but rather testing via progressive real-world usage. The Span Batch doesn’t have changes on the state transitions, so there is no possibility that users’ states can change in an unintended way. In the worst case, some transactions could be omitted. Therefore, Test in Prod went through the following steps to ensure the safety of this proposal, focusing on the liveness parts: 1 ) Security review with OP Labs Test in Prod passed a security review with OP Labs. Since the Delta upgrade isn’t related to user assets, but instead implements a consensus upgrade, we focused on reviewing cases where the consensus could fail and built contingency plans for the failure. Please refer to the Contingency Plans section in the current proposal for detailed contingency plans. Throughout the review, we figured that the Span Batch deployment would be less likely to impact Sequencer’s pre-confirming block production—the unsafe head progression; we expect end users to be less likely to be impacted in the majority of failure scenarios. 2 ) Ran verification script on Superchain Devnet & Testnets Test in Prod prepared the verification script 2 for Span Batches. The script checks the entire consensus process from posting batches on L 1 to deriving L 2 blocks from L 1 . It tests if there’s a consensus failure by detecting unsafe reorgs—ensuring nodes derive the same state that the Sequencer originally calculated before posting batches. Please refer to the Functionality Verification Guide 9 for more details. The verification script works as follows: Send various types of transactions to the L 2 . Record the transactions’ hashes & included unsafe blocks’ hashes. Poll if the included blocks are consolidated to safe. Compare recorded unsafe blocks’ hashes to safe blocks that include transactions. If same, it’s a success! 3 ) E 2 E tests & unit tests Test in Prod prepared the e 2 e tests & unit tests for Span Batches. They cover a wide range of scenarios and check if the code operates as intended. Here are Github PRs for e 2 e tests: # 1 1 # 2 1 # 3 1 Impact Summary Performance Impact Span Batch saves more L 1 fees than the current state of the OP Stack, and savings increase the less active the chain is. Therefore, Test in Prod expects more savings on L 1 fees for less-active chains; we expect to save L 1 fees by ~ 97 % for low-throughput chains and 6 %~ 11 % for high-throughput chains like OP Mainnet or Base Mainnet. Test in Prod backtested several OP Chains and prepared the expected L 1 fee savings in %. Please refer to the Expected Result section in the Design Docs 18 for the result. User Impact Delta doesn’t include any direct impact on the users’ side. Also, Test in Prod doesn’t expect downtime for the Delta upgrade. Node Impact Nodes will be unable to sync the chain if nodes don’t perform the software update until the op-batcher operator starts posting Span Batches. Thus, nodes are required to update software versions to keep in sync with the OP Chains. Please refer to the Guides for Nodes section in the current proposal for the upgrade details. Upgrade Details After Delta hard fork, Span Batches submission won’t be activated automatically; the op-batcher operators should restart their instance with the Span Batches enabled. Therefore, even though Delta hard fork time passes, nothing will happen until the op-batcher operator explicitly starts posting batches in the Span Batch. OP Chains can use (post & derive) both Singular Batches and Span Batches after the Delta hard fork. Action Plans Timeline (including finished items) Test in Prod proposes 00 : 00 : 00 Feb 22 , 2024 , UTC for the Delta hard fork time— 1707922800 in Unix Timestamp. It’s three weeks after Voting Cycle # 17 ends, and two weeks after the Citizens’ House veto period. The Delta upgrade has already been activated on op-goerli, op-sepolia, base-goerli, base-sepolia, pgn-sepolia, zora-sepolia, and Superchain Devnet (operated by OP Labs, Base, and Conduit). Here’s the list of the timeline for Delta including finished items: Superchain Devnet activation at 00 : 00 : 00 , Dec 08 , 2023 UTC. Goerli Testnets activation at 00 : 00 : 00 , Dec 21 , 2023 UTC. Sepolia Testnets activation at 00 : 00 : 00 , Dec 22 , 2023 UTC. Voting results are final & start to notify upgrading nodes at 19 : 00 : 00 , Jan 31 , 2024 UTC. Including the one-week veto period. (Proposed) Mainnet activation at 00 : 00 : 00 , Feb 22 , 2024 UTC. Appended one week due to the veto period. Contingency Plans Our contingency plans for the unexpected failure of the Delta upgrade are as follows: op-batcher disables posting Span Batches, start posting legacy batches (Singular Batches), prepare the fix, and enable Span Batches again. In this way, we expect the impact on the user side will be minimized while resolving the issues—the sequencer would continue pre-confirming blocks as normal, but batch submission would be halted until the op-batcher restarts to push Singular Batches. However, if there’s an unexpected critical issue where we need nodes’ action, we have prepared a way for nodes to disable the upgrade by using --override.delta flag on op-node. Test in Prod will work with OP Labs to monitor, communicate, and alert relevant parties upon the upgrade in such cases. Software versions The code for the Delta upgrade is ready in the following Optimism monorepo hash: 54 a 7 dbf 8 aa 9 b 982 f 9 c 6 a 54 cbbe 448 be 41 c 0 b 7 bc 7 10 . Nodes can manually set the Delta hard fork time with the preceding code. However, nodes will not automatically activate Delta on Mainnet as the Delta hard fork time is not embedded in the code; it cannot be embedded since Delta has not yet been approved by governance. If the governance approves the Delta hard fork and finalizes the hard fork time, Test in Prod will work with OP Labs to prepare the new release that embeds the Mainnet hard fork time and notify the community. With the new release, nodes won’t have to manually set the Delta hard fork time; but they will automatically activate the Delta upgrade. The following versions are deployed in the testnets: op-node: v 1 . 4 . 1 2 op-batcher: v 1 . 4 . 1 op-proposer: v 1 . 4 . 1 op-geth: v 1 . 101304 . 2 Guides for Node Operators Node operators are required to upgrade the software versions. Please refer to the following guides: Delta Upgrade Guide in Optimism Docs 17 Delta Node Upgrade Guide 10 (For op-batcher operators) Delta Hard Fork Functionality Verification Guide 9 Conclusion This proposal outlines the Delta upgrade that includes Span Batches. This upgrade reduces the size overheads of the current specs in a significant step for less-active chains, and it leads to alleviating the risks of launching new OP Stack L 2 s. By reducing the L 1 fees and risks with the Delta upgrade, we expect to alleviate burdens for less-active chains, help easier adoptions of the OP Stack, and head one step forward to the Superchain future. We don’t expect sequencer downtime for the Delta hard fork & activating Span Batches.
  Likes: 22 Replies: 2
  Likers: danftz, bobby, Harper, raho, lavande, polynya, Joxes, PGov, Luckyhooman.eth, Chain_L, cpoetter, mastermojo, philliprossii, simple8720, MoneyManDoug, joseebasanta, MS1, kutubu, revmiller, Jepsen, FractalVisions, fujiar
  Replies:

  • Joxes: Hey! It’s great to see this proposal posted in the forum. testinprod_io: The Span Batch doesn’t have changes on the state transitions, so there is no possibility that users’ states can change in an unintended way. In the worst case, some transactions could be omitted. For now, I have a quick question about this sentence, in the worst case, some transactions could be omitted: is this when the proposer generates and posts a new state root, right? The proposer would just ignore the batch -or a portion of it-?. Is this the case, or are we talking about another situation in particular?
  • testinprod_io: Hello! We are proposing the Mainnet activation at 00:00:00, Feb 22, 2024 UTC. testinprod_io: (Proposed) Mainnet activation at 00:00:00, Feb 22, 2024 UTC.