Thanks Damon, and the endorsement on all three carries weight coming from a node operator, plus the OCP closed-registry / skip-on-unknown precedent is exactly the right parallel for the versioning model.
On the transition window, good catch, and it’s the right question to ask of a pull-based mesh. The answer falls out of pinning the identity key rather than the signer: a record from an unrecognized signer for a known node isn’t a reject, it’s a trigger to re-resolve the delegation.
Concretely:
-
Peers pin the nodeId (identity key). When a peer sees a record signed by S_new it doesn’t recognize, it re-fetches the delegation, the node’s /vni, or NodeRegistry.signerOf(nodeId) as the on-chain authority, before deciding.
-
The delegation is self-certifying: it’s signed by the identity key the peer already pins, so the peer validates S_new the moment it first sees it. No grace period on the old signer required.
-
If the delegation isn’t fetchable yet (genuine race, node mid-rotation or briefly unreachable), the peer defers the record and retries next cycle rather than hard-rejecting. So nothing is lost, just delayed until the delegation propagates.
-
validFrom monotonicity stops a stale/rolled-back delegation from sneaking in during the window.
So the old signer doesn’t need to stay valid, and there’s no flag-day, because acceptance keys on “does the pinned identity currently delegate this signer?”, resolved on demand, not on “have I seen this exact signer before?”. An operator MAY overlap (keep signing with the old key until they’ve confirmed propagation) as belt-and-suspenders, but the protocol doesn’t require it.
Folding this in as a “rotation propagation” clause in the key-rotation section, it’s a real gap in the draft as written. Good one.
1 Like
The on-demand re-resolve is the right answer — keying acceptance on “does the pinned identity currently delegate this signer” rather than “have I seen this exact signer before” is what makes the model work without a flag-day or a grace period on the old signer.
The deferred-retry on a genuine race is the correct failure mode too. A hard reject during a brief rotation window would be the wrong tradeoff for a pull-based mesh — delay until the delegation propagates is strictly better than losing the record.
validFrom monotonicity closing the stale-delegation vector is the detail that makes the whole thing auditable. Flag it explicitly in the key-rotation section so implementers don’t miss it.
1 Like
That’s the model exactly, @Damonzwicker , and validFrom is the one I most wanted flagged, so good to have you call it.
It’s in the draft: the rotation-propagation clause carries the on-demand re-resolve and the deferred-retry-on-race, and I’ve now pulled validFrom monotonicity out into its own normative line in the key-rotation section, a node MUST reject any delegation whose validFrom isn’t strictly greater than the last it accepted for that nodeId, so it reads as the explicit auditability hook rather than a buried clause. Gist updated.
And yep “delay until propagation beats losing the record” is exactly the pull-based-mesh tradeoff. Good to have the OCP closed-registry precedent confirming the failure mode; that’s the kind of cross-check that makes me trust the design more than my own say-so.
Pulling validFrom monotonicity into its own normative line is the right call — that’s exactly where it needs to be visible for anyone implementing against the spec rather than reading it end to end.
The OCP closed-registry precedent holds: strict monotonicity on the commit sequence is what makes the audit trail trustworthy. Same principle applies here — if validFrom isn’t enforced as a hard floor per nodeId, the rotation record becomes ambiguous under any race condition, and the re-resolve path loses its guarantee.
1 Like
Done validFrom monotonicity is now its own normative line in the spec, not a sub-clause of the rotation flow. It reads as a hard floor: a node MUST reject any delegation whose validFrom isn’t strictly greater than the highest it has accepted for that nodeId, and, your race point exactly, that check applies uniformly, including on the rotation-propagation re-resolve path. So a delegation re-fetched mid-rotation is held to the same floor as one received in steady state; there’s no window where an equal-or-stale validFrom slips through because it arrived via re-resolve.
I cited the precedent directly: it’s the same invariant the OCP closed registry enforces on its commit sequence, strict monotonicity is what makes the audit trail trustworthy, and without a strict per-nodeId floor the rotation record goes ambiguous under any race and the re-resolve path loses its guarantee that the pinned identity key’s current signer is the latest one it authorized.
Pulling it out where an implementer hits it without reading end to end was the right call. Updated gist is live.
1 Like
Update: this is now filed as a Draft ERC.
→ ethereum/ERCs#1826 — https://github.com/ethereum/ERCs/pull/1826
Same protocol discussed here: a pull-based mesh-sync layer for EIP-3668 gateways — each exposes GET /records of EIP-191-signed records, peers poll and replicate what they verify, so a record served by one gateway survives the loss of any other. Content-addressed and deduplicated, signer keys verifiable and rotatable (two-tier identity/signer), optional on-chain NodeRegistry for discovery.
Reference implementation is live ccip-router (npm, a 4-node mainnet mesh); the spec’s test vector was pulled from the live deployment and recomputes against it.
Co-authored with @Damonzwicker and @JimmyShi22 , with @TruthAnchor-AI on the ERC-8263 integration (acknowledged). Review and discussion welcome here or on the PR — requires: 191, 3668, and it’s intentionally a single-purpose protocol ERC.
1 Like
Update: the editors have assigned the number, this is now ERC-8309.
The PR is updated accordingly (file renamed to erc-8309.md, discussions-to pointed here) and CI is green, so it’s in the editor review queue.
→ https://github.com/ethereum/ERCs/pull/1826
Same protocol as discussed above, review and feedback welcome here or on the PR.