You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/adr/adr-023-execution-owned-proposer-rotation.md
+8-7Lines changed: 8 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,11 +27,11 @@ An empty `NextProposerAddress` from `ExecuteTxs` means the proposer is unchanged
27
27
28
28
When execution returns a non-empty next proposer:
29
29
30
-
- The producing node commits it to `Header.NextProposerAddress` before signing the header.
31
-
- Syncing nodes require the signed header value to match the execution result.
32
30
-`State.NextProposerAddress` is updated and used as the expected signer for `LastBlockHeight + 1`.
31
+
- Full nodes validate the next block signer against the previous state's `NextProposerAddress`.
32
+
- Header encoding remains unchanged. `Header.ProposerAddress` continues to identify the signer of the current block only.
33
33
34
-
`Header.NextProposerAddress` lets header-only paths and DA envelope validation see proposer transitions without replaying execution first. The execution result remains the authority; mismatches between the signed header and execution are invalid.
34
+
The execution result is the authority for proposer rotation. Header-only paths cannot derive proposer transitions without either replaying execution or using a future proof/certificate mechanism. This preserves header compatibility while keeping the rotation rule deterministic for full nodes.
35
35
36
36
## EVM System Contract Model
37
37
@@ -47,7 +47,7 @@ The security council or multisig becomes the authority for proposer updates. It
47
47
48
48
The system contract must restrict writes to the configured authority. Unauthorized proposer updates are consensus-critical because they determine who can sign the next block.
49
49
50
-
ev-node validates the execution output against the signed header. A malicious proposer cannot advertise one next proposer in the header while execution derives another.
50
+
ev-node validates each block's signer against the proposer address stored in the previous state. A malicious proposer cannot rotate the next signer through node-local configuration; the rotation must be derived from execution.
51
51
52
52
If the execution interface returns an empty proposer, ev-node treats the proposer as unchanged. At startup, empty execution info falls back to genesis so existing execution implementations remain usable.
- Rejected. Nodes could disagree about the active proposer unless every operator updates configuration at the same time.
80
81
81
-
Execution-only proposer without header commitment:
82
+
Header commitment for next proposer:
82
83
83
-
- Rejected. Syncing nodes can replay execution, but header and DA envelope paths benefit from having the selected next proposer committed in the signed header when it changes.
84
+
- Rejected for the first version. It would expose rotations to header-only paths, but it changes the signed header and hash encoding. Keeping rotation in execution/state avoids a header compatibility break.
0 commit comments