services/committeeverifier: match blockchain chain family#1223
Merged
Conversation
When adding bootstrap.ChainRegistration to the bootstrapInput, only add chains that match the chain family of the committee verifier.
- Push OnchainSigningPubKey for every declared chain, not just the chain's own, so JD lane resolution can derive a signer address for a family the NOP never declared (e.g. a solana-only NOP signing into a canton-destination lane). - Reject Chains configs that mix chain families: a bootstrapper is built for exactly one family and shares one signing key across every declared chain, so a mixed list would silently push a mis-formatted key for whichever family loses out.
4 tasks
tt-cll
previously approved these changes
Jul 2, 2026
carte7000
previously approved these changes
Jul 2, 2026
tt-cll
previously approved these changes
Jul 2, 2026
|
Code coverage report:
|
tt-cll
approved these changes
Jul 2, 2026
carte7000
approved these changes
Jul 2, 2026
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
3 participants
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.
Description
Related PR: smartcontractkit/chainlink-ccip#2169
Fixes the root cause of the devenv registration bug where a committee verifier's bootstrap config could end up declaring chains from more than one chain family, and adds a config-level guard so this class of bug can't silently recur.
launchVerifierinbuild/devenv/services/committeeverifier/base.gowas registering every deployed blockchain output as abootstrap.ChainRegistrationentry, regardless of which chain family the verifier itself belongs to.In a multi-family devenv (e.g. an EVM + Solana topology), a Solana committee verifier's bootstrap config ended up with both
SOLANAandEVMchain entries. The fix filters registration tooutput.Family == in.ChainFamily.To make sure this can't reappear via a different code path,
bootstrap.Config.Chainsnow rejects entries spanning more than one chain family at load time. A committee verifier binary is built for exactly one family (EVM XOR Solana XOR ..., never mixed) and pushes a single signing key under the assumption every declared chain shares that family; this turns a silent, hard-to-diagnose runtime mismatch into an explicit config validation error naming the offending index and the family already established.Separately,
buildUpdateNodeRequestnow also pushesOcrKeyBundle.OnchainSigningPubKeyfor every declared chain, not just derivingOnchainSigningAddress. A standalone node signs with one shared secp256k1 key across all its declared chains, so exposing the raw key lets downstream lane-configuration code (currently in chainlink-ccip) derive a signer address for a chain family the node never declared directly, e.g. bridging a Solana node's key into a Canton-family lane, instead of only being able to translate between families the node explicitly registered. This pairs with the chainlink-ccip fix for cross-family signer lookup.Testing
go build ./...andgo test ./...in thebootstrapmodulemixed-family
Chainslist rejected, same family in differentcasing accepted, and an invalid entry not masking the family check
on the remaining valid entries.
OnchainSigningPubKeyis populatedand identical across every
ChainConfigproduced for a NOP'sdeclared chains (same underlying key).
Checklist
changelogdirectory)just lint fix- no new lint errorsjust generate- mocks and protobufs are up to date