Profile of ajsutton in Optimism

Posts by ajsutton

• Upgrade Proposal #10: Granite Network Upgrade by ajsutton - No Role
  Posted on: Aug. 17, 2024, 3:20 a.m.
  Content: No, the anchor state is just the starting point for new dispute games of that game type.
  Likes: 0 Replies: 2
  No likes yet.
  Replies:

  • clowes.eth: chom: Emergency upgrade may affect protocols that rely on dispute game such as ENS gateway. Need to test if this such case is handled. This is the case. ajsutton: No, the anchor state is just the starting point for new dispute games of that game type. Is there documentation for this? —- Whilst I appreciate that this is an ‘emergency’ upgrade and a good opportunity to prepare for the future, tooling utilising the implementation as is(was) is prone to breaking - it would be great to have additional documentation and clarity on what can change and under what circumstances.
  • raffy.eth: ajsutton: No, the anchor state is just the starting point for new dispute games of that game type. Where can I query the current finalized root on mainnet? Game 1633 (first gameType 1) is starting from the current gameType 1 anchor state 0x2694ac14dcf54b7a77363e3f60e6462dc78da0d43d1e2f058dbb6a1488814977 @ block 120059863 (95 days ago) ajsutton: It doesn’t affect withdrawals at all proveWithdrawalTransaction() apparently doesn’t require finalization… shouldn’t that be != DEFENDER_WINS ? This was clarified on Discord (there is another finalization step. No withdrawals have been processed post gameType change.)
• Upgrade Proposal #10: Granite Network Upgrade by ajsutton - No Role
  Posted on: Aug. 17, 2024, 3:01 a.m.
  Content: There’s no need to adjust the anchor state. It doesn’t affect withdrawals at all and will just naturally be updated when the next game resolves.
  Likes: 1 Replies: 2
  Likers: donnoh
  Replies:

  • raffy.eth: Isn’t it the latest on-chain finalized state?
  • raffy.eth: ajsutton: No, the anchor state is just the starting point for new dispute games of that game type. Where can I query the current finalized root on mainnet? Game 1633 (first gameType 1) is starting from the current gameType 1 anchor state 0x2694ac14dcf54b7a77363e3f60e6462dc78da0d43d1e2f058dbb6a1488814977 @ block 120059863 (95 days ago) ajsutton: It doesn’t affect withdrawals at all proveWithdrawalTransaction() apparently doesn’t require finalization… shouldn’t that be != DEFENDER_WINS ? This was clarified on Discord (there is another finalization step. No withdrawals have been processed post gameType change.)
• Upgrade Proposal #10: Granite Network Upgrade by ajsutton - No Role
  Posted on: Aug. 17, 2024, 2:34 a.m.
  Content: There have been a number of proposals already made with the permissioned game type (about one an hour as was done with the permissionless games). The AnchorStateRegistry is only updated once the dispute period for games has elapsed and the game resolves as Defender Wins. It’s then used as the starting point for new games after that. Having an old anchor state just means there are more blocks that could be disputed in the top half of the dispute game which narrows down to find the first disputed block.
  Likes: 1 Replies: 0
  Likers: donnoh
  No replies yet.
• [FINAL] Protocol Upgrade #7: Fault Proofs by ajsutton - No Role
  Posted on: May 28, 2024, 9:27 p.m.
  Content: qizhou: One question is that when proposing an output root, could we only store the minimum necessary data on-chain and delay creating the game contract until it is challenged? It is possible that could be done as an optimisation in the future. For simplicity, we haven’t done so at this stage. Note that if this were done, the proposer’s bond would need to be increased to cover the cost of the challenger creating the game to ensure the system remains compatible. So the upfront cost would likely be similar, but you could reclaim that bond if the output root is valid. In terms of costs to operate a chain, there is also the balancing factor that, unlike the L 2 OutputOracle, the DisputeGameFactory does not require proposals be made at a fixed interval. So proposals could be made less often for chains that don’t typically see many withdrawals to save costs then made more frequent as chain usage grows. The timeliness of proposals is also less important because they are no longer restricted to a privileged actor so users can propose their own output root if they don’t want to wait.
  Likes: 1 Replies: 0
  Likers: qizhou
  No replies yet.
• Upgrade Proposal: Fault Proofs by ajsutton - No Role
  Posted on: May 28, 2024, 9:27 p.m.
  Content: qizhou: One question is that when proposing an output root, could we only store the minimum necessary data on-chain and delay creating the game contract until it is challenged? It is possible that could be done as an optimisation in the future. For simplicity, we haven’t done so at this stage. Note that if this were done, the proposer’s bond would need to be increased to cover the cost of the challenger creating the game to ensure the system remains compatible. So the upfront cost would likely be similar, but you could reclaim that bond if the output root is valid. In terms of costs to operate a chain, there is also the balancing factor that, unlike the L 2 OutputOracle, the DisputeGameFactory does not require proposals be made at a fixed interval. So proposals could be made less often for chains that don’t typically see many withdrawals to save costs then made more frequent as chain usage grows. The timeliness of proposals is also less important because they are no longer restricted to a privileged actor so users can propose their own output root if they don’t want to wait.
  Likes: 1 Replies: 0
  Likers: qizhou
  No replies yet.
• [FINAL] Protocol Upgrade #7: Fault Proofs by ajsutton - No Role
  Posted on: May 27, 2024, 10:48 p.m.
  Content: brichis: Hey @ajsutton! I think this link is no longer working. Can you please update it? The link should be working again now. It appears to have been a temporary issue with the Sherlock site.
  Likes: 1 Replies: 0
  Likers: brichis
  No replies yet.
• Upgrade Proposal: Fault Proofs by ajsutton - No Role
  Posted on: May 27, 2024, 10:48 p.m.
  Content: brichis: Hey @ajsutton! I think this link is no longer working. Can you please update it? The link should be working again now. It appears to have been a temporary issue with the Sherlock site.
  Likes: 1 Replies: 0
  Likers: brichis
  No replies yet.
• [FINAL] Protocol Upgrade #7: Fault Proofs by ajsutton - No Role
  Posted on: May 24, 2024, 2:20 a.m.
  Content: Leo.Zhang: When is the end of the veto period? The veto period ends on June 5 th I believe.
  Likes: 0 Replies: 0
  No likes yet.
  No replies yet.
• [FINAL] Protocol Upgrade #7: Fault Proofs by ajsutton - No Role
  Posted on: May 23, 2024, 11:05 p.m.
  Content: Leo.Zhang: @ajsutton So when will be the proposal implemented on mainnet? Is there a specific timeline? Thank you! There isn’t a specific timeline. The upgrade will require coordination with the security council to obtain the appropriate signatures. As mentioned in the proposal, the recommendation is to perform the upgrade shortly after the end of the veto period and I’m definitely excited to see it go live as soon as possible.
  Likes: 0 Replies: 0
  No likes yet.
  No replies yet.
• [FINAL] Protocol Upgrade #7: Fault Proofs by ajsutton - No Role
  Posted on: May 23, 2024, 11:04 p.m.
  Content: Joxes: How large are the bonds expected to be needed to sustain and win a dispute? A summary of the factors involved would be nice. The bonds are sized based on the anticipated cost to post a counter claim as well as to deter spamming invalid claims. There’s more details in the specs. As an example on op-sepolia the game 0 xcf 8 f 181497 DAD 07277781517 A 76 cb 131 C 54 A 1 BEE shows the escalating bond sizes. The list-claims subcommand of op-challenger can provide a good view of the claims in the game: ./op-challenger/bin/op-challenger list-claims --l 1 -eth-rpc <SEPOLIA_L 1 > --game-address 0 xcf 8 f 181497 DAD 07277781517 A 76 cb 131 C 54 A 1 BEE Joxes: How many steps/transactions are required to settle a dispute (worst-case scenario)? The maximum depth of a game is 73 , but there can be any number of claims and counter-claims within a dispute game. Due to the permissionless structure where many different actors can participate in the same game, a single claim may be countered by any number of different counter-claims, effectively combining multiple disputes into a single game. Joxes: With Fault Proofs, are escape hatches practically possible? In the event of sequencer and proposer failure, we would expect to initiate an forced withdrawal from L 1 and then propose a new state root. Are there any dependencies to consider? Users are able to complete the full withdrawal cycle without depending on any privileged action. The caveat is that the Guardian role has the ability to override the system by either blacklisting games or reverting to a permissioned system. So the trust assumption is reduced to requiring only that the guardian role does not act to intervene but there is still a trust assumption, inline with the stage 1 requirements. Joxes: Since the roles of proposer and challenger will be open to everyone, is there a guide available outlining the best practices for running them? It’s not expected that normal users run op-proposer to regularly propose output roots, they’d generally just propose a single output root if they need to withdraw and the chain operator isn’t proposing outputs for them. They can do that through direct calls to the DisputeGameFactory even via Etherscan or could use the create-game subcommand of op-challenger. For running op-challenger, there aren’t detailed docs currently. Definitely an area to build up between the official docs and community content.
  Likes: 3 Replies: 0
  Likers: Joxes, brichis, delphine
  No replies yet.