Batch_operator: drop the operator-side bootstrap push#523
Conversation
The genesis advance (epoch 0 -> 1) is a SYSTEM responsibility, not a batch operator's. `sysio.msgch::bootstrap` gates on `require_auth(get_self())`, so only the holder of `sysio.msgch`'s own authority (the genesis / bootstrap process) can trigger it. `do_poll_epoch_state` was pushing `msgch::bootstrap` at epoch 0 signed with the operator's own account authority, which the chain rejects UNCONDITIONALLY with `missing authority of sysio.msgch (3090004)` before the epoch check ever runs. It never advanced anything; it only produced boot-window error-log noise (3 lines/run observed on the 9-op clusters). From epoch 1 onward `advance` re-arms itself via `evalcons` consensus; batch operators never trigger it. Remove the epoch==0 bootstrap-push block and the now-orphan `action_bootstrap` constant. Verified on top of the chain_plugin sync gate (#520): full unit sweep green (unit_test 1507/1507, contracts_unit_test, plugin_test, test_fc, and the chain / underwriter / batch_operator plugin test binaries), and the full 13-flow suite 13/13 SUCCEEDED with the `msgch::bootstrap 3090004` signature now 0 across every cluster (was 3x on the 9-op runs) and `3060002/3060003` still 0. Co-Authored-By: Claude <noreply@anthropic.com> Change-Id: I08613c5379c85ba98e5d00a1c794ac00fb9b2de5
| // fails unconditionally with `missing authority of sysio.msgch` before the | ||
| // epoch check — it never advanced anything, it only produced boot-window | ||
| // error-log noise. From epoch 1 onward, `advance` re-arms itself via | ||
| // `evalcons` consensus; batch operators never trigger it. |
There was a problem hiding this comment.
The post-genesis description is inaccurate: elected batch operators still invoke sysio.msgch::chkcons during each poll, and chkcons triggers sysio.epoch::advance after consensus and the time gate. evalcons only records the durable per-outpost consensus state. Please clarify that batch operators never authorize bootstrap or advance directly, but do trigger advancement through chkcons.
There was a problem hiding this comment.
Correct — chkcons is the operator-cranked trigger: the elected operator's poll invokes msgch::chkcons, which sends the inline sysio.epoch::advance under msgch's own authority once the per-outpost consensus recorded during evalcons dispatch and the epoch time gate are met; evalcons only records that durable state. Reworded the code comment (317f54f) and the PR description accordingly: batch operators never authorize bootstrap or advance directly, but do trigger advancement through chkcons.
Batch operators never authorize bootstrap or advance directly (both are inline actions under msgch's own authority), but the elected operator does trigger advancement each poll by cranking msgch::chkcons, which sends the inline sysio.epoch::advance once the per-outpost consensus recorded during evalcons dispatch and the epoch time gate are met. evalcons only records that durable per-outpost consensus state.
3 participants
Stacked on #522
Base is
fix/chain-plugin-sync-gate-channel(#522, the sync-gate replacement for #520). This restacks #521 — the same single commit, cherry-picked unchanged — onto the new base; GitHub will retarget this tomasteronce #522 merges.Problem
batch_operator_plugin::do_poll_epoch_statepushedsysio.msgch::bootstrapat epoch 0 to trigger the genesis advance — signed with the operator's own account authority. Butmsgch::bootstrapgates onrequire_auth(get_self())(i.e.sysio.msgch's own authority), so the chain rejected the push unconditionally withmissing authority of sysio.msgch (3090004), before thecheck(epoch == 0)ever ran. It never advanced anything — it only emitted boot-window error-log noise.The genesis advance is a system responsibility: only the holder of
sysio.msgch's authority (the genesis/bootstrap process; the harness in test clusters) can trigger it. From epoch 1 onward batch operators still trigger advancement — the elected operator's poll cranksmsgch::chkcons, which sends the inlinesysio.epoch::advanceunder msgch's own authority once the per-outpost consensus recorded duringevalconsdispatch and the epoch time gate are met — but they never authorizebootstraporadvancedirectly.Change
Remove the
epoch == 0bootstrap-push block fromdo_poll_epoch_stateand the now-orphanaction_bootstrapconstant. One file.