Profile of ben-chain in Optimism
Posts by ben-chain
-
About L3s and the Superchain
by ben-chain - No Role
Posted on: March 14, 2024, 6:05 p.m.
Content: Hey y’all, loving these great questions and acknowledging the need for clarification here. We have been putting cycles into the right way to lay out a breakdown more cleanly. Hoping to clarify this as we head into Season 6 !
Likes: 2
Replies: 1
Replies:
- jaack: Yeah, hope this all gets sorted out in Season 6, but I think this a good start - just talking about it.
-
About L3s and the Superchain
by ben-chain - This user is a moderator
Posted on: March 14, 2024, 2:05 p.m.
Content: Hey y’all, loving these great questions and acknowledging the need for clarification here. We have been putting cycles into the right way to lay out a breakdown more cleanly. Hoping to clarify this as we head into Season 6 !
Likes: 2
Replies: 1
Replies:
- jaack: Yeah, hope this all gets sorted out in Season 6, but I think this a good start - just talking about it.
-
Upgrade Proposal #4
by ben-chain - No Role
Posted on: Jan. 30, 2024, 9:55 p.m.
Content: The Optimism Foundation would not activate this pause mechanism in the event of a bug in an application running on an OP Chain, as that would undermine his would undermine the User Protection of State Transition and Messaging Validity 3 . The pause functionality is only intended to be used to protect against withdrawals which should be invalid, but are possible due to unforeseen bugs in the OP Stack bridge or elsewhere in the protocol. Given that all OP Chains will share the same logic across contracts in the L 1 system, it is expected that a bug present in one OP Chain will be present in all. Therefore it is essential to pause all chains at once. If a bug is present, any delay between pausing the first chain and pausing others will: reveal to the world that a bug is likely to be present provide time for a hacker to find and exploit the bug in any OP Chain which is not yet paused. It is also worth highlighting that this is not new functionality, but rather an enhancement of existing functionality. Per the proposal: maurelian: The primary new functionality will be an extension of the pause mechanism, which prevents the withdrawal of assets from the system in the event that a vulnerability is identified. This will improve the incident response capacity of OP Labs. Currently only the OptimismPortal’s proveWithdrawalTransaction() and finalizeWithdrawalTransaction() functions are pausable. Following this upgrade, this will expand to include the following additional functions: L 1 CrossDomainMessenger.relayMessage() L 1 StandardBridge.finalizeBridgeERC 20 () L 1 StandardBridge.finalizeERC 20 Withdrawal L 1 tandardBridge.finalizeBridgeETH() L 1 StandardBridge.finalizeETHWithdrawal L 1 ERC 721 Bridge.finalizeBridgeERC 721 () It gives us greater confidence that if a pause is necessary to protect against a bug, it will indeed provide the protection required, thus providing the time to put in place the proper fix.
Likes: 2
Replies: 0
No replies yet.
-
Upgrade Proposal #4
by ben-chain - This user is a moderator
Posted on: Jan. 30, 2024, 4:55 p.m.
Content: The Optimism Foundation would not activate this pause mechanism in the event of a bug in an application running on an OP Chain, as that would undermine his would undermine the User Protection of State Transition and Messaging Validity 3 .
The pause functionality is only intended to be used to protect against withdrawals which should be invalid, but are possible due to unforeseen bugs in the OP Stack bridge or elsewhere in the protocol.
Given that all OP Chains will share the same logic across contracts in the L 1 system, it is expected that a bug present in one OP Chain will be present in all. Therefore it is essential to pause all chains at once. If a bug is present, any delay between pausing the first chain and pausing others will:
reveal to the world that a bug is likely to be present
provide time for a hacker to find and exploit the bug in any OP Chain which is not yet paused.
It is also worth highlighting that this is not new functionality, but rather an enhancement of existing functionality. Per the proposal:
maurelian:
The primary new functionality will be an extension of the pause mechanism, which prevents the withdrawal of assets from the system in the event that a vulnerability is identified. This will improve the incident response capacity of OP Labs.
Currently only the OptimismPortal’s proveWithdrawalTransaction()
and finalizeWithdrawalTransaction() functions are pausable.
Following this upgrade, this will expand to include the following additional functions:
L 1 CrossDomainMessenger.relayMessage()
L 1 StandardBridge.finalizeBridgeERC 20 ()
L 1 StandardBridge.finalizeERC 20 Withdrawal
L 1 tandardBridge.finalizeBridgeETH()
L 1 StandardBridge.finalizeETHWithdrawal
L 1 ERC 721 Bridge.finalizeBridgeERC 721 ()
It gives us greater confidence that if a pause is necessary to protect against a bug, it will indeed provide the protection required, thus providing the time to put in place the proper fix.
Likes: 2
Replies: 0
No replies yet.
-
Upgrade Proposal #4
by ben-chain - This user is a moderator
Posted on: Jan. 30, 2024, 4:55 p.m.
Content: The Optimism Foundation would not activate this pause mechanism in the event of a bug in an application running on an OP Chain, as that would undermine his would undermine the User Protection of State Transition and Messaging Validity.
The pause functionality is only intended to be used to protect against withdrawals which should be invalid, but are possible due to unforeseen bugs in the OP Stack bridge or elsewhere in the protocol.
Given that all OP Chains will share the same logic across contracts in the L 1 system, it is expected that a bug present in one OP Chain will be present in all. Therefore it is essential to pause all chains at once. If a bug is present, any delay between pausing the first chain and pausing others will:
reveal to the world that a bug is likely to be present
provide time for a hacker to find and exploit the bug in any OP Chain which is not yet paused.
It is also worth highlighting that this is not new functionality, but rather an enhancement of existing functionality. Per the proposal:
maurelian:
The primary new functionality will be an extension of the pause mechanism, which prevents the withdrawal of assets from the system in the event that a vulnerability is identified. This will improve the incident response capacity of OP Labs.
Currently only the OptimismPortal’s proveWithdrawalTransaction()
and finalizeWithdrawalTransaction() functions are pausable.
Following this upgrade, this will expand to include the following additional functions:
L 1 CrossDomainMessenger.relayMessage()
L 1 StandardBridge.finalizeBridgeERC 20 ()
L 1 StandardBridge.finalizeERC 20 Withdrawal
L 1 tandardBridge.finalizeBridgeETH()
L 1 StandardBridge.finalizeETHWithdrawal
L 1 ERC 721 Bridge.finalizeBridgeERC 721 ()
It gives us greater confidence that if a pause is necessary to protect against a bug, it will indeed provide the protection required, thus providing the time to put in place the proper fix.
Likes: 2
Replies: 0
No replies yet.
-
Upgrade Proposal #4
by ben-chain - No Role
Posted on: Jan. 26, 2024, 11:07 p.m.
Content: This is correct as it applies to OP Mainnet. It is important to note that for now, this upgrade only applies to OP Mainnet. Other chains can follow this upgrade or not, given the current scope of the vote. In the future, it may become a mandatory requirement to use the shared guardian role for the Optimism Collective to provide sufficient, uniform security guarantees alongside further tech milestones (like interoperability). Today, if other OP Chains elect to follow this upgrade, they can continue to designate “ownership” of the Extended Pause functionality to the entity or entities currently responsible for the Guardian role on their chain, though it’s our strong recommendation that the most robust incident response plan would be to transfer guardian role to the Foundation. The Optimism Foundation may not be able to react quickly/through its primary incident response protocol in the event of critical vulnerabilities present on chains which do not use Foundation as their guardian. [Note: this scope only applies to standard OP Chains. not forks. Optimism Foundation is not proposing a security SLA for forks or unofficial chains at this time, please do not transfer the guardian role before direct communication with the Optimism Foundation.]
Likes: 7
Replies: 0
No replies yet.
-
Upgrade Proposal #4
by ben-chain - This user is a moderator
Posted on: Jan. 26, 2024, 6:07 p.m.
Content: This is correct as it applies to OP Mainnet. It is important to note that for now, this upgrade only applies to OP Mainnet. Other chains can follow this upgrade or not, given the current scope of the vote. In the future, it may become a mandatory requirement to use the shared guardian role for the Optimism Collective to provide sufficient, uniform security guarantees alongside further tech milestones (like interoperability).
Today, if other OP Chains elect to follow this upgrade, they can continue to designate “ownership” of the Extended Pause functionality to the entity or entities currently responsible for the Guardian role on their chain, though it’s our strong recommendation that the most robust incident response plan would be to transfer guardian role to the Foundation. The Optimism Foundation may not be able to react quickly/through its primary incident response protocol in the event of critical vulnerabilities present on chains which do not use Foundation as their guardian. [Note: this scope only applies to standard OP Chains. not forks. Optimism Foundation is not proposing a security SLA for forks or unofficial chains at this time, please do not transfer the guardian role before direct communication with the Optimism Foundation.]
Likes: 7
Replies: 0
No replies yet.
-
[FINAL] Law of Chains v0.1
by ben-chain - No Role
Posted on: Nov. 1, 2023, 3:34 p.m.
Content: We recognize the technical nature of the current Law of Chains. It was drafted to provide a comprehensive perspective on a complex protocol. It is certainly our hope that, as more of the Law of Chains becomes enforceable programmatically, the protocol architecture, documentation, etc. itself make the Law of Chains more intuitively comprehensible… Meanwhile, we have prepared a section-by-section summary 5 of the Law of Chains that we hope helps bridge the gap. With respect to enforceability, the important point is that (as described in Section 8 ) the Law of Chains is meant to be enforced by Optimism Governance, not a court of law. For more information see the Important Disclaimer 1 included in the LoC.
Likes: 4
Replies: 0
No replies yet.
-
Law of Chains v0.1: Full Draft
by ben-chain - No Role
Posted on: Nov. 1, 2023, 3:34 p.m.
Content: We recognize the technical nature of the current Law of Chains. It was drafted to provide a comprehensive perspective on a complex protocol. It is certainly our hope that, as more of the Law of Chains becomes enforceable programmatically, the protocol architecture, documentation, etc. itself make the Law of Chains more intuitively comprehensible… Meanwhile, we have prepared a section-by-section summary 5 of the Law of Chains that we hope helps bridge the gap. With respect to enforceability, the important point is that (as described in Section 8 ) the Law of Chains is meant to be enforced by Optimism Governance, not a court of law. For more information see the Important Disclaimer 1 included in the LoC.
Likes: 4
Replies: 0
No replies yet.
-
Law of Chains v0.1: Full Draft
by ben-chain - No Role
Posted on: Nov. 1, 2023, 3:33 p.m.
Content: nickbtts: With this in mind, the Law Of Chains raises a few questions. Firstly, if post-vote the ‘platform’ is the Superchain, where does that leave OP Mainnet in terms of governance representation? Who exactly is representing the home of many projects and builders, as OPlabs do not participate in governance? We expect Optimism Governance to ultimately own some or all of the responsibilities of the “Chain Governor” for OP Mainnet. In the interim, it will continue to be stewarded by the Foundation with governance controlling various components of the system such as protocol upgrades. nickbtts: However, without any clear vision, dedicated team or enshrinement of rights for Optimism Mainnet, we may well see it simply fade away as a place to build, deploy and transact (and maybe this is part of the long term strategy, but if so I believe now is the time for that to be communicated). We expect that OP Mainnet will continue to play an important role in bringing builders to the Superchain and providing a neutral platform for innovation. Governance’s Season 5 Intents represent an extended commitment to growing developers across all OP Chains, including but not limited to OP Mainnet.
Likes: 2
Replies: 0
No replies yet.
