Revert "fix: support proof-bearing validator joins (#206)" — unblocks e2e - #207
Merged
Merged
Conversation
This reverts commit 6f12738.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
MuncleUscles
added a commit
that referenced
this pull request
Aug 18, 2026
…mpanions) (#208) * Reapply "fix: support proof-bearing validator joins (#206)" (#207) This reverts commit 7666f0b. * feat(staking): support the two-step operator rotation CON-715 removed ValidatorWalletBlueprint.setOperator in favour of initiateOperatorTransfer + completeOperatorTransfer. The SDK only spoke the single-call surface, so rotating an operator against a consensus deployment that carries the change fails: the selector no longer exists, so viem reverts with no reason and the Python SDK reports ABIFunctionNotFound. Adds both calls plus cancelOperatorTransfer and the getPendingOperator view, and keeps setOperator for deployments that still expose it. The proof binding is the subtle part. validatorJoin's possession proof is verified by the ValidatorWalletFactory and is bound to it; rotation is verified by the wallet, so the registrar is the wallet's own address (PubKeyUtils.validateWithPossession(pubKey, address(this), owner(), proof)). createOperatorRegistration already takes the registrar as a parameter, so no change was needed there — but a join proof silently fails to verify for a rotation, which is the easy mistake to make. getOperatorTransferContext builds the wallet-bound context and reads owner() from the wallet rather than assuming the caller is the owner, so a mismatch surfaces as a clear local error instead of an onlyOwner revert. A test pins that a join-bound proof does not verify for rotation while a wallet-bound one does. Callers still need updating; this only adds the surface they need: genlayer-e2e's driver interface, genlayer-cli's staking set-operator, and genlayer-py's staking_set_operator all remain single-call. Verified: npx tsc --noEmit, npm test -- --run (123/123, no type errors), npm run build. * fix(staking): resolve the Claim/Commit layout from the chain CON-715 widened both staking structs — Claim gained `offset`, Commit gained `outstanding`/`priced`/`fragmented` and narrowed several members — while keeping the same function names and arguments. Static tuples decode positionally, so reading a post-CON-715 chain with the shape in STAKING_ABI does not fail: `commit.input` picks up `claim.commit`. Pending deposits came back as small indices instead of amounts, which is why the e2e delegator scenarios asserted 0.1 GEN and got "0" or "2". Both layouts are deployed — consensus v0.6-dev has the old one, #1290 the new — so neither shape can simply replace the other. STAKING_COMMIT_VIEWS_CURRENT_ABI adds the post-CON-715 shape for the four struct-returning views, and readCommitView resolves which one the chain speaks, once, then caches it for the client: getStakeInfo loops over every pending entry and must not re-probe per entry. The probe only works in one direction, and the tests pin that: decoding a legacy response with the current shape throws (the response is short), while decoding a current response with the legacy shape succeeds and lies. So the current shape is always attempted first and a decode *failure* identifies a legacy chain. If that asymmetry ever breaks, the probe would quietly start reporting wrong balances again — hence the test asserting the exact misread value rather than merely "not equal". Also drops duplicate ValidatorWalletBlueprint entries: the ABI already carried initiateOperatorTransfer/completeOperatorTransfer/cancelOperatorTransfer/ getPendingOperator, with initiateOperatorTransfer declared as taking an address rather than the pubkey and possession proof it actually takes. Verified: npx tsc --noEmit, npm test -- --run (126/126, no type errors), npm run build. --------- Co-authored-by: kirilaa <kirilantevski@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reverts #206. Unblocks e2e across every repo that follows the v0.6 matrix.
Diagnosis and bracketing are @darien's — this PR is just the mechanical revert.
What happened
genlayer-js #206 ("support proof-bearing validator joins") was one of a coordinated five-repo set. Only the SDK half landed:
validatorJoinwent from proofless{amount, operator?}to requiring{registration}plus a client-sideverifyOperatorRegistration. Sincetracks/v0.6/matrix.yamlpinsgenlayer-js: v2-dev— a moving branch, not a commit — every downstream build began pulling an SDK that demands a proof its callers don't send.Both lanes fail on the same shared
join as a validatorsetup step, with the same error —Operator registration proof does not match the owner, registrar, chain, or public key:js-drivercallsvalidatorJoin({amount})in-process; the SDK throws.The chain couldn't have satisfied it regardless: the deployed consensus is proofless, and the proof-bearing on-chain surface lives only on the still-open #1285.
Bracketed on an otherwise identical matrix, only the floating tip differing — last green
31282868593(08-08 22:57), first red31324780948(08-09 16:49), immediately after the merge.Why revert rather than pin the matrix
Pinning
genlayer-jsto0b7e3bdwould unblock CI just as fast, but it leavesv2-devbroken for everyone else consuming it and creates a stale pin someone has to remember to remove. Reverting restores the property the matrix depends on —v2-devis always usable — and #206 re-lands unchanged with its four companions, which is what should have happened.Nothing landed on top of #206, so this is a clean single-commit revert: the resulting tree is byte-identical to
0b7e3bd6, the last-green commit (git diff 0b7e3bd6 HEADis empty).Worth fixing separately
#206's own
E2E Testscheck never ran — it sat permanently pending, becausegate_policy: release-branchesmakes e2e advisory on*-devbranches. It merged on the unit-test job via the merge queue. No green e2e ever certified it, which is why a five-repo breaking change could land alone without anything objecting.