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
+2-3Lines changed: 2 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,14 +21,13 @@ The replacement design moves proposer selection into the execution environment.
21
21
-`UpdatedStateRoot`: the state root after executing the block.
22
22
-`NextProposerAddress`: the address expected to sign the next block.
23
23
24
-
`GetExecutionInfo` also exposes `NextProposerAddress` for startup. If execution returns an empty proposer at startup, ev-node falls back to `genesis.proposer_address`.
25
-
26
24
An empty `NextProposerAddress` from `ExecuteTxs` means the proposer is unchanged. ev-node must not write a redundant header field in that case, preserving compatibility with existing headers and hash chains.
27
25
28
26
When execution returns a non-empty next proposer:
29
27
30
28
-`State.NextProposerAddress` is updated and used as the expected signer for `LastBlockHeight + 1`.
31
29
- Full nodes validate the next block signer against the previous state's `NextProposerAddress`.
30
+
- Nodes recover the expected signer after restart from the persisted state. If legacy state has no stored proposer, ev-node falls back to `genesis.proposer_address`.
32
31
- Header encoding remains unchanged. `Header.ProposerAddress` continues to identify the signer of the current block only.
33
32
34
33
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.
@@ -49,7 +48,7 @@ The system contract must restrict writes to the configured authority. Unauthoriz
49
48
50
49
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
50
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.
51
+
If the execution interface returns an empty proposer from `ExecuteTxs`, ev-node treats the proposer as unchanged. At startup, missing proposer data in legacy state falls back to genesis so existing execution implementations remain usable.
53
52
54
53
Compromise of the security council can still rotate the proposer to an attacker. This ADR reduces node configuration risk; it does not eliminate governance-key risk.
0 commit comments