Profile of bayardo in Optimism

Posts by bayardo

• Upgrade Proposal #9: Fjord Network Upgrade by bayardo - No Role
  Posted on: June 14, 2024, 2:24 p.m.
  Content: Apologies for the delayed reply, we were working on getting a version of our internal failure mode analysis published, and it’s now available here 9 . This should provide more context on the decision to forgo audit, and also links to some of the test cases. I have also fixed the duplicated link, thank you for flagging that.
  Likes: 3 Replies: 0
  Likers: brichis, OPUser, seb
  No replies yet.
• Upgrade Proposal #9: Fjord Network Upgrade by bayardo - No Role
  Posted on: June 14, 2024, 1:56 p.m.
  Content: @habacuc.eth The primary motivation of increasing the maximum seqeuencer drift value is because of past incidents in which L 1 node issues have led to L 2 unsafe head chain halts. (Unsafe chain halts are the most user-disruptive type, since transactions won’t clear the transaction pool until the chain restarts). With a 10 minute sequencer drift, chain operators have at most 10 minutes to respond to a non-responsive L 1 before unsafe chain halt. In our experience it has not been possible to react quickly enough to prevent this. The sequencer drift parameter sets a maximum bound on the time the L 2 chain’s knowledge of L 1 “attributes” (such as L 1 gas price) is out of date. Because L 1 attributes like gas price are designed not to fluctuate wildly in short time periods, and situations where we must rely on a larger drift will be rare, the consensus was the downsides of such an increase were small and well worth the added safety it provides against unsafe chain halt. I should add that ideally chain operators should have significant L 1 node redundancy so that these sorts of L 1 issues never arise. However this has proven challenging in practice, hence the desire for this extra level of insurance. As for how we reached the decision, the Base team made a request at one of our regular infrastructure meetings to increase this value, citing previous testnet incidents, and continued discussing the proposal with OP Labs engineers on our shared Slack channels. We reached consensus on 30 minutes as providing enough time for paged engineers to respond to alerts for all but the most catastrophic of incidents. The proposal was socialized on our broader shared superchain channels and OP stack infrastructure meetings without objections from the community.
  Likes: 7 Replies: 0
  Likers: seb, EricForgy, habacuc.eth, Joxes, brichis, 0x666, delphine
  No replies yet.
• Developer Advisory Board S6 Election Town Hall by bayardo - No Role
  Posted on: June 13, 2024, 3:36 p.m.
  Content: Hi, due to my involvement in a different OP council I feel it’s best to withdraw my application for this season to avoid the overlap. I look forward to participating in a future iteration! Roberto
  Likes: 4 Replies: 0
  Likers: brichis, Liliop.eth, wbnns, Gonna.eth
  No replies yet.
• Upgrade Proposal #9: Fjord Network Upgrade by bayardo - No Role
  Posted on: June 2, 2024, 5:24 p.m.
  Content: Excellent point, fixed.
  Likes: 1 Replies: 0
  Likers: ulerdogan
  No replies yet.
• Upgrade Proposal #9: Fjord Network Upgrade by bayardo - No Role
  Posted on: June 2, 2024, 1:24 p.m.
  Content: Excellent point, fixed.
  Likes: 2 Replies: 0
  Likers: ulerdogan, Jepsen
  No replies yet.
• Upgrade Proposal #9: Fjord Network Upgrade by bayardo - No Role
  Posted on: May 30, 2024, 9:44 p.m.
  Content: Executive Summary Hi I’m Roberto, an engineer at Coinbase working on the Base blockchain, and a core developer of the OP Stack. I reviewed this proposal in collaboration with Sebastian Stammler and Dragan Zurzin from the OP labs team. Neither Coinbase nor I represent or speak on behalf of the Optimism Foundation. This is a proposal for the Fjord network upgrade, which includes the EIP- 7212 precompile to reduce gas costs of many smart wallet applications, supports Brotli batch compression for ~ 5 - 15 % lower data availability costs, and improves the robustness of L 1 data pricing. The upgrade also increases and hardcodes the max-sequencer-drift parameter, giving chain operators more time to respond to L 1 node issues without facing a potential L 2 chain halt. Specifications Technical Specification We propose the Fjord network upgrade (spec overview 8 ), which activates: RIP- 7212 1 : Precompile for secp 256 r 1 Curve Support (spec 1 ) Brotli as a channel compression option (spec 6 ) FastLZ based L 1 data availability cost calculation (spec 3 ), including an upgraded GasPriceOracle L 2 predeploy to compute it (spec 2 ). Parameter changes: Max sequencer drift becomes a constant with value increased to 1800 seconds (spec 1 ) Increased values for MAX_RLP_BYTES_PER_CHANNEL and MAX_CHANNEL_BANK_SIZE (spec) The Fjord hardfork activation block, which includes several transactions to perform all L 2 contract deployments, upgrades, enablements, and proxy updates. (spec 1 ) The upgrade also updates and deprecates: getL 1 GasUsed method of the GasPriceOracle contract (spec 1 ) L 1 GasUsed field of the transaction receipt (spec 1 ) Security Considerations Consistent with the OP Labs Audit Framework 2 , we did not have the contents of Fjord audited; however, Coinbase and OP Labs engineers did perform a security review of these changes. The Fjord upgrade’s inclusion of EIP- 7212 involves use of the reference implementation that is already live on other blockchains, which we consider low risk. Brotli compression is also a low-risk change since it is already used by other L 2 s and was evaluated for both its runtime performance and compression improvements across four different OP-stack chains. It’s usage is also optional and must be activated by the chain operator after the upgrade in order to be applied. The introduction of the new L 1 data fee cost function required updates to the GasPriceOracle L 2 predeploy, and changes op-geth to compute the fee values. The contract extension allows developers to continue using the GasPriceOracle to compute the data fee, and affects only helper functions that are outside of consensus. We extensively evaluated the accuracy of this new function compared to multiple variants as well as the previous one across various timeslices of OP mainnet and Base mainnet transactions (analysis repo 2 ). The new function consistently produced significant improvements in mean-squared-error and mean-absolute-error across each, and we were unable to find any instances where the new function could wildly diverge from ground truth. (We computed ground truth by putting the transaction in a simulated batch, compressing the entire batch with Brotli- 10 , and returning the number of bytes occupied by the transaction in the result.) Bugs in the op-geth computation might still lead to under/over payment for L 1 data fees by users. Significant underpayment could result in revenue loss for the chain operator, but the system provides parameters that can be updated quickly via the SystemConfig in order to quickly compensate for such scenarios. Overall we feel this change remains low risk. Similar to the previous upgrade, Fjord uses a special upgrade block to perform the contract deployment and activation on the L 2 . Bugs in this code could lead to an incomplete fork with missing contracts or contract functionality expected by the upgrade, in the worst case leading to chain halt. Since this approach to automating the upgrade has been used successfully in the past, we consider this low risk. Security considerations for the parameter changes are discussed in the upgrade specification here 1 and here 1 . These changes are also straightforward and we consider them low risk. Impact Summary We do not anticipate any downtime due to this upgrade. Bringing EIP- 7212 to the OP stack will benefit applications such as smart wallets that want to support many common authentication methods (such as Apple’s FaceID) that would otherwise be too gas intensive. We evaluated Brotli compression compared to the previous compression algorithm (zlib) on 4 OP stack chains (OP mainnet, Base, Zora, and Mode) and found compression ratio improvements ranging from 5 - 15 % under Brotli quality level 10 . This will directly translate to a 5 - 15 % reduction in L 1 data availability costs, so we expect most chains will want to activate this feature immediately following the upgrade. The FastLZ based L 1 data fee function will more accurately charge for L 1 data usage on a per transaction basis. Previously, highly incompressible transactions might be undercharged for L 1 data usage, and a large number of such transactions might lead to an inability to recover revenue without the chain operator having to take action by re-tuning fee parameters. We expect this new function to far more accurately detect the (lack of) compressibility of each individual transaction and reduce the chance of revenue recovery drifting from its intended target. The main impact of the parameter changes is that chain operators will have more time to respond to L 1 node outage issues before the L 2 chain stalls ( 30 minutes instead of 10 minutes). Action Plan for this release If this vote passes, the Fjord upgrade will be scheduled for execution on July 10 th at 16 : 00 : 01 UTC. The upgrade will occur automatically for nodes on a release which contains the baked in activation time. Fjord is code complete in the optimism monorepo at commit 4 a 487 b 8920 daa 9 dc 4 b 496 d 691 d 5 f 283 f 9 bb 659 b 1 and op-geth at commit 3 fbae 78 d 638 d 1 b 903 e 702 a 14 f 98644 c 1103 ae 1 b 3 . The op-node release v 1 . 7 . 6 and op-geth release v 1 . 101315 . 1 contain these changes. This upgrade has already been activated on internal devnets and the Sepolia Superchain in coordination with Base and Conduit. Fault Proofs Update This is the first protocol upgrade that will activate on mainnet following the launch of Fault Proofs, which has recently been accepted by governance 5 . However, its version of the op-program and Fault Dispute Game doesn’t contain the Fjord mainnet activation yet, so we need to perform an update of the Fault Proofs L 1 infrastructure before the Fjord activation on mainnet. This is the first time that we need to perform this exercise. This update requires us to create a new release of the op-program that contains the Fjord activation and generate the so-called absolute pre-state for it, which is a commitment to the program and its starting state. We then have to deploy new FaultDisputeGame and PerimissionedDisputeGame contracts to L 1 Mainnet with the new op-program pre-state hash. These steps will be done while the review period is ongoing, so that the new contracts are deployed to L 1 by the time that the voting period starts. However, deploying these contracts doesn’t update the actual Fault Proofs system yet to use them. After the veto period has ended, we will ask the Security Council to sign transactions to update the DisputeGameFactory to use the new FaultDisputeGame and PermissionedDisputeGame implementations that were voted on. This transaction has to be executed before the actual Fjord activation to avoid a broken Fault Proofs system after the activation. Emergency Cancellation The optimistic mainnet releases will contain a Fjord activation at the above mentioned time. If there is a critical security issue found between approval and rollout, the Optimism Foundation and Security Council will work to coordinate an emergency cancellation. We have included functionality for node operators to quickly react by using the --override.fjord flag on both op-node & op-geth. Conclusion This proposal outlines the network upgrade after Ecotone titled Fjord. This network upgrade brings reduced execution fees for certain (e.g. smart wallet) applications, lower data availability costs, and more robust L 1 data pricing. We expect that this upgrade will not result in any downtime and will occur on Wednesday, July 10 2024 at 16 : 00 : 01 UTC.
  Likes: 12 Replies: 1
  Likers: ulerdogan, polynya, lavande, Milo, Joxes, estmcmxci, maintainer.eth, brichis, 0x666, Michael, Liliop.eth, seb
  Replies:

  • OPUser: One suggestion from someone with less technical knowledge: even if it’s a low-risk change and external audit was not requested as per OP Lab Audit Framework, would it be possible to show different test runs and their outputs? Internal or peer reviewed document ? Assuming i am not asking anything confidential. I am also assuming there might be something similar in the analysis repo attached, but without direction, it’s hard to navigate. This makes decision-making hard from a non-technical delegate standpoint. Out of interest, I have been following EIP-7212. This helped me understand the change and associated risks, and I’m happy to see it coming live. For other points, here is the parent link of EIP if anyone wants to read: EIP-7212 Precompiled for SECP256R1 Curve Support. Both links point to the same page: bayardo: upgrade specification here and here. As OP Stack evolves and governance matures, we, as delegates, have some responsibility. When approving, I want to be sure my decision is based on information rather than assumption at the same time I don’t want to request something unnecessary, leading to additional bureaucracy and work hour. Sharing so that other delegate could share their feedback.
• Upgrade Proposal #9: Fjord Network Upgrade by bayardo - No Role
  Posted on: May 30, 2024, 5:44 p.m.
  Content: Executive Summary Hi I’m Roberto, an engineer at Coinbase working on the Base blockchain, and a core developer of the OP Stack. I reviewed this proposal in collaboration with Sebastian Stammler and Dragan Zurzin from the OP labs team. Neither Coinbase nor I represent or speak on behalf of the Optimism Foundation. This is a proposal for the Fjord network upgrade, which includes the EIP- 7212 precompile to reduce gas costs of many smart wallet applications, supports Brotli batch compression for ~ 5 - 15 % lower data availability costs, and improves the robustness of L 1 data pricing. The upgrade also increases and hardcodes the max-sequencer-drift parameter, giving chain operators more time to respond to L 1 node issues without facing a potential L 2 chain halt. Specifications Technical Specification We propose the Fjord network upgrade (spec overview 30 ), which activates: RIP- 7212 32 : Precompile for secp 256 r 1 Curve Support (spec 32 ) Brotli as a channel compression option (spec 22 ) FastLZ based L 1 data availability cost calculation (spec 14 ), including an upgraded GasPriceOracle L 2 predeploy to compute it (spec 9 ). Parameter changes: Max sequencer drift becomes a constant with value increased to 1800 seconds (spec 10 ) Increased values for MAX_RLP_BYTES_PER_CHANNEL and MAX_CHANNEL_BANK_SIZE (spec 1 ) The Fjord hardfork activation block, which includes several transactions to perform all L 2 contract deployments, upgrades, enablements, and proxy updates. (spec 7 ) The upgrade also updates and deprecates: getL 1 GasUsed method of the GasPriceOracle contract (spec 5 ) L 1 GasUsed field of the transaction receipt (spec 6 ) Security Considerations Consistent with the OP Labs Audit Framework 9 , we did not have the contents of Fjord audited; however, Coinbase and OP Labs engineers did perform a security review of these changes. The Fjord upgrade’s inclusion of EIP- 7212 involves use of the reference implementation that is already live on other blockchains, which we consider low risk. Brotli compression is also a low-risk change since it is already used by other L 2 s and was evaluated for both its runtime performance and compression improvements across four different OP-stack chains. It’s usage is also optional and must be activated by the chain operator after the upgrade in order to be applied. The introduction of the new L 1 data fee cost function required updates to the GasPriceOracle L 2 predeploy, and changes op-geth to compute the fee values. The contract extension allows developers to continue using the GasPriceOracle to compute the data fee, and affects only helper functions that are outside of consensus. We extensively evaluated the accuracy of this new function compared to multiple variants as well as the previous one across various timeslices of OP mainnet and Base mainnet transactions (analysis repo 6 ). The new function consistently produced significant improvements in mean-squared-error and mean-absolute-error across each, and we were unable to find any instances where the new function could wildly diverge from ground truth. (We computed ground truth by putting the transaction in a simulated batch, compressing the entire batch with Brotli- 10 , and returning the number of bytes occupied by the transaction in the result.) Bugs in the op-geth computation might still lead to under/over payment for L 1 data fees by users. Significant underpayment could result in revenue loss for the chain operator, but the system provides parameters that can be updated quickly via the SystemConfig in order to quickly compensate for such scenarios. Overall we feel this change remains low risk. Similar to the previous upgrade, Fjord uses a special upgrade block to perform the contract deployment and activation on the L 2 . Bugs in this code could lead to an incomplete fork with missing contracts or contract functionality expected by the upgrade, in the worst case leading to chain halt. Since this approach to automating the upgrade has been used successfully in the past, we consider this low risk. Security considerations for the parameter changes are discussed in the upgrade specification here 3 and here 1 . These changes are also straightforward and we consider them low risk. Impact Summary We do not anticipate any downtime due to this upgrade. Bringing EIP- 7212 to the OP stack will benefit applications such as smart wallets that want to support many common authentication methods (such as Apple’s FaceID) that would otherwise be too gas intensive. We evaluated Brotli compression compared to the previous compression algorithm (zlib) on 4 OP stack chains (OP mainnet, Base, Zora, and Mode) and found compression ratio improvements ranging from 5 - 15 % under Brotli quality level 10 . This will directly translate to a 5 - 15 % reduction in L 1 data availability costs, so we expect most chains will want to activate this feature immediately following the upgrade. The FastLZ based L 1 data fee function will more accurately charge for L 1 data usage on a per transaction basis. Previously, highly incompressible transactions might be undercharged for L 1 data usage, and a large number of such transactions might lead to an inability to recover revenue without the chain operator having to take action by re-tuning fee parameters. We expect this new function to far more accurately detect the (lack of) compressibility of each individual transaction and reduce the chance of revenue recovery drifting from its intended target. The main impact of the parameter changes is that chain operators will have more time to respond to L 1 node outage issues before the L 2 chain stalls ( 30 minutes instead of 10 minutes). Action Plan for this release If this vote passes, the Fjord upgrade will be scheduled for execution on July 10 th at 16 : 00 : 01 UTC. The upgrade will occur automatically for nodes on a release which contains the baked in activation time. Fjord is code complete in the optimism monorepo at commit f 8143 c 8 cbc 4 cc 0 c 83922 c 53 f 17 a 1 e 47280673485 and op-geth at commit 7 c 2819836018 bfe 0 ca 07 c 4 e 4955754834 ffad 4 e 0 . The op-node release v 1 . 7 . 7 5 and op-geth release v 1 . 101315 . 2 4 contain these changes. This upgrade has already been activated on internal devnets and the Sepolia Superchain in coordination with Base and Conduit. Fault Proofs Update This is the first protocol upgrade that will activate on mainnet following the launch of Fault Proofs, which has recently been accepted by governance 18 . However, its version of the op-program and Fault Dispute Game doesn’t contain the Fjord mainnet activation yet, so we need to perform an update of the Fault Proofs L 1 infrastructure before the Fjord activation on mainnet. This is the first time that we need to perform this exercise. This update involves a new release of the op-program (v 1 . 2 . 0 4 ) that contains the Fjord activation and generate the so-called absolute pre-state for it, which is a commitment to the program and its starting state. It also requires deploying new FaultDisputeGame and PerimissionedDisputeGame contracts to L 1 Mainnet with the new op-program pre-state hash. These are deployed at addresses 0 xf 691 F 8 A 6 d 908 B 58 C 534 B 624 cF 16495 b 491 E 633 BA 7 and 0 xc 307 e 93 a 7 c 530 a 184 c 98 eade 4545 a 412 b 857 b 62 f 5 respectively. After the veto period has ended, we will ask the Security Council to sign transactions to update the DisputeGameFactory to begin using these new contract implementations. This transaction has to be executed before the actual Fjord activation to avoid a broken Fault Proofs system after the activation. Emergency Cancellation The optimistic mainnet releases will contain a Fjord activation at the above mentioned time. If there is a critical security issue found between approval and rollout, the Optimism Foundation and Security Council will work to coordinate an emergency cancellation. We have included functionality for node operators to quickly react by using the --override.fjord flag on both op-node & op-geth. Conclusion This proposal outlines the network upgrade after Ecotone titled Fjord. This network upgrade brings reduced execution fees for certain (e.g. smart wallet) applications, lower data availability costs, and more robust L 1 data pricing. We expect that this upgrade will not result in any downtime and will occur on Wednesday, July 10 2024 at 16 : 00 : 01 UTC.
  Likes: 28 Replies: 1
  Likers: ulerdogan, polynya, lavande, Milo, Joxes, estmcmxci, maintainer.eth, brichis, 0x666, Michael, Liliop.eth, seb, Pl3b4n, itublockchain, ismailemin, Jrocki, web3magnetic, Jepsen, eugenia, Tane, habacuc.eth, leesmit, httpsageyd, josefophe, noobman, revmiller, Gosuigoti, Zer0Luck
  Replies:

  • OPUser: One suggestion from someone with less technical knowledge: even if it’s a low-risk change and external audit was not requested as per OP Lab Audit Framework, would it be possible to show different test runs and their outputs? Internal or peer reviewed document ? Assuming i am not asking anything confidential. I am also assuming there might be something similar in the analysis repo attached, but without direction, it’s hard to navigate. This makes decision-making hard from a non-technical delegate standpoint. Out of interest, I have been following EIP-7212. This helped me understand the change and associated risks, and I’m happy to see it coming live. For other points, here is the parent link of EIP if anyone wants to read: EIP-7212 Precompiled for SECP256R1 Curve Support. Both links point to the same page: bayardo: upgrade specification here and here. As OP Stack evolves and governance matures, we, as delegates, have some responsibility. When approving, I want to be sure my decision is based on information rather than assumption at the same time I don’t want to request something unnecessary, leading to additional bureaucracy and work hour. Sharing so that other delegate could share their feedback.
• Upgrade Proposal #9: Fjord Network Upgrade by bayardo - No Role
  Posted on: May 30, 2024, 5:44 p.m.
  Content: Executive Summary Hi I’m Roberto, an engineer at Coinbase working on the Base blockchain, and a core developer of the OP Stack. I reviewed this proposal in collaboration with Sebastian Stammler and Dragan Zurzin from the OP labs team. Neither Coinbase nor I represent or speak on behalf of the Optimism Foundation. This is a proposal for the Fjord network upgrade, which includes the EIP- 7212 precompile to reduce gas costs of many smart wallet applications, supports Brotli batch compression for ~ 5 - 15 % lower data availability costs, and improves the robustness of L 1 data pricing. The upgrade also increases and hardcodes the max-sequencer-drift parameter, giving chain operators more time to respond to L 1 node issues without facing a potential L 2 chain halt. Specifications Technical Specification We propose the Fjord network upgrade (spec overview), which activates: RIP- 7212 : Precompile for secp 256 r 1 Curve Support (spec) Brotli as a channel compression option (spec) FastLZ based L 1 data availability cost calculation (spec), including an upgraded GasPriceOracle L 2 predeploy to compute it (spec). Parameter changes: Max sequencer drift becomes a constant with value increased to 1800 seconds (spec) Increased values for MAX_RLP_BYTES_PER_CHANNEL and MAX_CHANNEL_BANK_SIZE (spec) The Fjord hardfork activation block, which includes several transactions to perform all L 2 contract deployments, upgrades, enablements, and proxy updates. (spec) The upgrade also updates and deprecates: getL 1 GasUsed method of the GasPriceOracle contract (spec) L 1 GasUsed field of the transaction receipt (spec) Security Considerations Consistent with the OP Labs Audit Framework, we did not have the contents of Fjord audited; however, Coinbase and OP Labs engineers did perform a security review of these changes. The Fjord upgrade’s inclusion of EIP- 7212 involves use of the reference implementation that is already live on other blockchains, which we consider low risk. Brotli compression is also a low-risk change since it is already used by other L 2 s and was evaluated for both its runtime performance and compression improvements across four different OP-stack chains. It’s usage is also optional and must be activated by the chain operator after the upgrade in order to be applied. The introduction of the new L 1 data fee cost function required updates to the GasPriceOracle L 2 predeploy, and changes op-geth to compute the fee values. The contract extension allows developers to continue using the GasPriceOracle to compute the data fee, and affects only helper functions that are outside of consensus. We extensively evaluated the accuracy of this new function compared to multiple variants as well as the previous one across various timeslices of OP mainnet and Base mainnet transactions (analysis repo). The new function consistently produced significant improvements in mean-squared-error and mean-absolute-error across each, and we were unable to find any instances where the new function could wildly diverge from ground truth. (We computed ground truth by putting the transaction in a simulated batch, compressing the entire batch with Brotli- 10 , and returning the number of bytes occupied by the transaction in the result.) Bugs in the op-geth computation might still lead to under/over payment for L 1 data fees by users. Significant underpayment could result in revenue loss for the chain operator, but the system provides parameters that can be updated quickly via the SystemConfig in order to quickly compensate for such scenarios. Overall we feel this change remains low risk. Similar to the previous upgrade, Fjord uses a special upgrade block to perform the contract deployment and activation on the L 2 . Bugs in this code could lead to an incomplete fork with missing contracts or contract functionality expected by the upgrade, in the worst case leading to chain halt. Since this approach to automating the upgrade has been used successfully in the past, we consider this low risk. Security considerations for the parameter changes are discussed in the upgrade specification here and here. These changes are also straightforward and we consider them low risk. Impact Summary We do not anticipate any downtime due to this upgrade. Bringing EIP- 7212 to the OP stack will benefit applications such as smart wallets that want to support many common authentication methods (such as Apple’s FaceID) that would otherwise be too gas intensive. We evaluated Brotli compression compared to the previous compression algorithm (zlib) on 4 OP stack chains (OP mainnet, Base, Zora, and Mode) and found compression ratio improvements ranging from 5 - 15 % under Brotli quality level 10 . This will directly translate to a 5 - 15 % reduction in L 1 data availability costs, so we expect most chains will want to activate this feature immediately following the upgrade. The FastLZ based L 1 data fee function will more accurately charge for L 1 data usage on a per transaction basis. Previously, highly incompressible transactions might be undercharged for L 1 data usage, and a large number of such transactions might lead to an inability to recover revenue without the chain operator having to take action by re-tuning fee parameters. We expect this new function to far more accurately detect the (lack of) compressibility of each individual transaction and reduce the chance of revenue recovery drifting from its intended target. The main impact of the parameter changes is that chain operators will have more time to respond to L 1 node outage issues before the L 2 chain stalls ( 30 minutes instead of 10 minutes). Action Plan for this release If this vote passes, the Fjord upgrade will be scheduled for execution on July 10 th at 16 : 00 : 01 UTC. The upgrade will occur automatically for nodes on a release which contains the baked in activation time. Fjord is code complete in the optimism monorepo at commit f 8143 c 8 cbc 4 cc 0 c 83922 c 53 f 17 a 1 e 47280673485 and op-geth at commit 7 c 2819836018 bfe 0 ca 07 c 4 e 4955754834 ffad 4 e 0 . The op-node release v 1 . 7 . 7 and op-geth release v 1 . 101315 . 2 contain these changes. This upgrade has already been activated on internal devnets and the Sepolia Superchain in coordination with Base and Conduit. Fault Proofs Update This is the first protocol upgrade that will activate on mainnet following the launch of Fault Proofs, which has recently been accepted by governance. However, its version of the op-program and Fault Dispute Game doesn’t contain the Fjord mainnet activation yet, so we need to perform an update of the Fault Proofs L 1 infrastructure before the Fjord activation on mainnet. This is the first time that we need to perform this exercise. This update involves a new release of the op-program (v 1 . 2 . 0 ) that contains the Fjord activation and generate the so-called absolute pre-state for it, which is a commitment to the program and its starting state. It also requires deploying new FaultDisputeGame and PerimissionedDisputeGame contracts to L 1 Mainnet with the new op-program pre-state hash. These are deployed at addresses 0 xf 691 F 8 A 6 d 908 B 58 C 534 B 624 cF 16495 b 491 E 633 BA and 0 xc 307 e 93 a 7 c 530 a 184 c 98 eade 4545 a 412 b 857 b 62 f respectively. After the veto period has ended, we will ask the Security Council to sign transactions to update the DisputeGameFactory to begin using these new contract implementations. This transaction has to be executed before the actual Fjord activation to avoid a broken Fault Proofs system after the activation. Emergency Cancellation The optimistic mainnet releases will contain a Fjord activation at the above mentioned time. If there is a critical security issue found between approval and rollout, the Optimism Foundation and Security Council will work to coordinate an emergency cancellation. We have included functionality for node operators to quickly react by using the --override.fjord flag on both op-node & op-geth. Conclusion This proposal outlines the network upgrade after Ecotone titled Fjord. This network upgrade brings reduced execution fees for certain (e.g. smart wallet) applications, lower data availability costs, and more robust L 1 data pricing. We expect that this upgrade will not result in any downtime and will occur on Wednesday, July 10 2024 at 16 : 00 : 01 UTC.
  Likes: 28 Replies: 1
  Likers: ulerdogan, polynya, lavande, Milo, Joxes, estmcmxci, maintainer.eth, brichis, 0x666, Michael, Liliop.eth, seb, Pl3b4n, itublockchain, ismailemin, Jrocki, web3magnetic, Jepsen, eugenia, Tane, habacuc.eth, leesmit, httpsageyd, josefophe, noobman, revmiller, Gosuigoti, Zer0Luck
  Replies:

  • OPUser: One suggestion from someone with less technical knowledge: even if it’s a low-risk change and external audit was not requested as per OP Lab Audit Framework, would it be possible to show different test runs and their outputs? Internal or peer reviewed document ? Assuming i am not asking anything confidential. I am also assuming there might be something similar in the analysis repo attached, but without direction, it’s hard to navigate. This makes decision-making hard from a non-technical delegate standpoint. Out of interest, I have been following EIP-7212. This helped me understand the change and associated risks, and I’m happy to see it coming live. For other points, here is the parent link of EIP if anyone wants to read: EIP-7212 Precompiled for SECP256R1 Curve Support. Both links point to the same page: bayardo: upgrade specification here and here. As OP Stack evolves and governance matures, we, as delegates, have some responsibility. When approving, I want to be sure my decision is based on information rather than assumption at the same time I don’t want to request something unnecessary, leading to additional bureaucracy and work hour. Sharing so that other delegate could share their feedback.
• Season 6 Nominations: Developer Advisory Board by bayardo - No Role
  Posted on: May 30, 2024, 3:50 p.m.
  Content: Developer Advisory Board Self-Nomination Template Please keep your answers as concise as possible while conveying all relevant information. If you are a delegate, please provide the link to your delegate profile: If you are a delegate, please indicate what % of votable supply is delegated to you: (voting power can be referenced here) If you are a delegate, please indicate your voting participation rate in OP governance to date: (You may link to your profile on Karma, if applicable.) Please link to your voting history and any voting rationale you’ve shared: (You may link to your Snapshot and/or Agora profile for voting history. You may link to your delegate communication thread, or any other medium you use to communicate with your delegators, to share your voting rationale.) Are you a representative of OP Labs: No Please elaborate on your technical background. Please include information about the layer of the stack you have the most expertise on: I am an engineer at Coinbase where I lead protocol development and blockchain scaling within the Base team. I am a core contributor to the OP stack, with contributions spanning the monorepo, op-geth, and (op-)reth. Please demonstrate any non-Optimism experience you believe is relevant to this role: My work at Coinbase over the past 2 . 5 years has been focused on getting our users onchain. Have you previously served in a representative (appointed or elected) role in the Collective? If so, please specify which: Please outline your contributions, and their impact, to the Optimism ecosystem to date: I led much of the work that culminated in the Ecotone Superchain upgrade and am currently driving much of the next upgrade, Fjord. Ecotone included the activation of blobs for transaction batching, which reduced transaction fees by up to 90 x. Please describe your philosophy on what makes a good Mission Application: A good mission application is one which clearly articulates its benefits to the ecosystem and paves a credible path towards delivering impact. Please demonstrate your ability to explain complex technical topics to a non-technical audience: I regularly appear on podcasts and speak to the press about Base engineering accomplishments, with the goal of making them accessible for non or less-technical audiences. Some examples here. Please disclose any anticipated conflicts of interest: If you are a top 25 delegate in another ecosystem, hold an elected position in another DAO, and/or are a multisig signer in another community please disclose here. Please verify that you understand you may be removed from this role via the Representative Removal proposal type in the Operating Manual : I understand I may be removed from this role as outlined. Please verify that you understand KYC will be required to receive Council rewards at the end of Season 6 : I understand KYC will be required to receive Council rewards. Please verify that you are able to commit ~ 7 hours / week to Board operations: I am able to commit ~ 7 hours/week.
  Likes: 6 Replies: 0
  Likers: lavande, devtooligan, Jepsen, Michael, anika, Harper
  No replies yet.
• Upgrade Proposal #5: Ecotone Network Upgrade by bayardo - No Role
  Posted on: Feb. 21, 2024, 9:53 p.m.
  Content: No changes to L 1 contracts at all. L 2 contract interfaces are the same, though there are some new functions that get called by updated implementations of the existing API.
  Likes: 2 Replies: 0
  Likers: seb, fractalvisions
  No replies yet.