search

ethereum-optimism / design-docs

MIT License
27 stars 20 forks source link

feat: Stage 1.4: Kona + Asterisc FMA #132

Closed pauldowman closed 3 weeks ago

pauldowman commented 1 month ago

Description

A failure modes and recovery paths analysis for Stage 1.4: Kona and Asterisc.

Status: In Review

pauldowman commented 1 month ago

We can share this branch to make edits as we think of things. (No rebasing and force pushing until it's done.)

refcell commented 1 month ago

I've taken this on and updated. The initial draft is ready for review.

refcell commented 1 month ago

This document often uses the fact that asterisc/kona will not be in the hot path as a justification for low risk. My understanding of the goal of the project is to have a fallback for cannon/op-program that maintains the permissionless property. Therefore it is assumed that it may be part of the hot path, we should be planning for that case. What happens if it fails when its in the hot path? Line 94 touches on this, but not on the case there is a failure for both op-program/cannon and kona/asterisc

Good point. I've updated to add a section to Failure Modes and Recovery Paths Analysis detailing this situation. I believe with this, your point should be covered but let me know if there's any other holes you can poke!

pauldowman commented 1 month ago

This document often uses the fact that asterisc/kona will not be in the hot path as a justification for low risk. My understanding of the goal of the project is to have a fallback for cannon/op-program that maintains the permissionless property. Therefore it is assumed that it may be part of the hot path, we should be planning for that case. What happens if it fails when its in the hot path? Line 94 touches on this, but not on the case there is a failure for both op-program/cannon and kona/asterisc

Yes, and I think "hot path" isn't really a meaningful concept to talk about in here, because any of these failures will only occur if we have switched the active game type to use Kona + Asterisc, i.e. it's "in the hot path", right? It's not going to be exercised if nobody is creating dispute games with it.

So it seems to me that "Kona and Asterisc Hot Path Failure" doesn't really add anything that's not covered in the other sections.

refcell commented 1 month ago

This document often uses the fact that asterisc/kona will not be in the hot path as a justification for low risk. My understanding of the goal of the project is to have a fallback for cannon/op-program that maintains the permissionless property. Therefore it is assumed that it may be part of the hot path, we should be planning for that case. What happens if it fails when its in the hot path? Line 94 touches on this, but not on the case there is a failure for both op-program/cannon and kona/asterisc

Yes, and I think "hot path" isn't really a meaningful concept to talk about in here, because any of these failures will only occur if we have switched the active game type to use Kona + Asterisc, i.e. it's "in the hot path", right? It's not going to be exercised if nobody is creating dispute games with it.

So it seems to me that "Kona and Asterisc Hot Path Failure" doesn't really add anything that's not covered in the other sections.

It sounds like your suggesting to remove the "Hot Path" section I added in response to the above is that correct? If so, then Mark's comment would be unsatisfied.

refcell commented 1 month ago

https://github.com/ethereum-optimism/design-docs/pull/140 is a blocker for this FMA.

The Stage 1.4 FMA needs to be updated to reference fma-generic-contracts.md.