Conversation
just-mitch
assigned
just-mitch,
spalladino,
iAmMichaelConnor,
PhilWindle,
charlielye and
joeandrews and unassigned
just-mitch
just-mitch
changed the title
…-contract 7482: update contract interface
add test and deployment details
|
|
||
| We will explicitly support multiple concurrent "chains": | ||
|
|
||
| - "Pending Chain" - Reflects blocks published to L1 with their state diffs, but not yet been proven. |
There was a problem hiding this comment.
Not a fan of the "Pending" name, since it already has semantics in Ethereum which differ from these.
There was a problem hiding this comment.
Let us know if you have a better option!
|
|
||
| It is the responsibility of the prover selected at the beginning of an epoch to submit the proof of the epoch. | ||
|
|
||
| The proof of epoch i must land in epoch i+1. |
There was a problem hiding this comment.
I wouldn't enforce this for v1. If we did, what should the protocol do if the proof doesn't land on time? We don't handle reorgs nicely yet.
There was a problem hiding this comment.
The reasoning for i landing in i + 1 was a simple way of ensuring that a proof does not land on top of an epoch that have not yet been proven.
It is essentially just making accounting slightly easier since there is not this case where epoch i + 1 is proven but i is not yet. If we have any kind of timeliness requirement on it we can reorgs. @spalladino, Would you suggest here that we instead just force that the ordering is correct for proofs but ignore any timeliness?
|
|
||
| It is the responsibility of the prover selected at the beginning of an epoch to submit the proof of the epoch. | ||
|
|
||
| The proof of epoch i must land in epoch i+1. |
There was a problem hiding this comment.
The reasoning for i landing in i + 1 was a simple way of ensuring that a proof does not land on top of an epoch that have not yet been proven.
It is essentially just making accounting slightly easier since there is not this case where epoch i + 1 is proven but i is not yet. If we have any kind of timeliness requirement on it we can reorgs. @spalladino, Would you suggest here that we instead just force that the ordering is correct for proofs but ignore any timeliness?
|
|
||
| #### Overview | ||
|
|
||
| It is the responsibility of the prover selected at the beginning of an epoch to submit the proof of the epoch. |
There was a problem hiding this comment.
Do we want to be this strict for version 1? I thought the plan was to push prover coordination for later. Should we initially allow any to submit the proof to keep the chain moving?
Particularly as we can't currently handle re-orgs.
There was a problem hiding this comment.
This is related to @spalladino and @LHerskind comments below.
How about we keep this coordination (we pick a prover for an epoch), but do not worry about any timeliness (so no re-orgs).
In order for the proven chain to advance, all previous proofs must be posted.
Separately, we keep a function on the rollup contract just for verifying whether a proof is valid (not advancing the proven chain), enabling the "free for all" games to be played on SPRTN, DevNet, or both.
8 participants
This design and implementation plan describes version 1 of "Spartan", a public network that will be operational on/before 2024-09-16.