aggregate confidential-relay responses by logical hash#22304
Closed
nadahalli wants to merge 1 commit intotejaswi/relay-response-signaturesfrom
Closed
aggregate confidential-relay responses by logical hash#22304nadahalli wants to merge 1 commit intotejaswi/relay-response-signaturesfrom
nadahalli wants to merge 1 commit intotejaswi/relay-response-signaturesfrom
Conversation
product-security-plaid-production
Bot
requested review from
ilija42 and
russell-stern
Contributor
|
✅ No conflicts with other open PRs targeting |
Contributor
|
I see you updated files related to
|
|
This was referenced May 5, 2026
Merged
Contributor
Author
nadahalli
added a commit
that referenced
this pull request
May 7, 2026
…e paths
chainlink-common#2032 made SecretsResponseResult.Hash and
CapabilityResponseResult.Hash run params.Validate first and return
([32]byte, error), so a relay node can no longer accidentally sign
over a payload missing fields the canonical hash binds to.
Production callsites:
- core/capabilities/confidentialrelay/handler.go: sign{Secrets,Capability}Response
now wrap any Hash error and return it; the handler's existing error path
surfaces it back to the gateway as a JSON-RPC error so a request with
malformed identity fields (Owner format, ExecutionID length, etc.) is
rejected at signing time rather than silently producing an unbinding
signature.
- core/services/gateway/handlers/confidentialrelay/aggregator.go:
decodeSignedResponse propagates the Hash error so a single node's
response that fails canonical hashing is dropped from quorum counting
in the existing skip-this-response path, without aborting the whole
aggregation.
Also widens the changeset to mention the aggregator change folded in
from PR #22304.
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.
What changed
Hash(params)helpers in chainlink-common) and merges signatures into a single envelope once F+1 unique signers vouch for the same hash.req.Methodto handle bothconfidential.secrets.getandconfidential.capability.execute.aggregator.godescribes the future signature-verification hook for when the gateway has access to the relay-DON signer set; the trust anchor remains the enclave.Why
PR #22302 made each relay-DON node sign its response (Step 2 of the E9 plan, PRIV-432). The previous aggregator bucketed by full-envelope digest, which broke once each honest node's envelope started carrying a different signature for identical logical content. Step 3 makes the gateway aggregate-and-pass-through correctly, so the enclave can verify F+1 unique relay signatures over a shared logical payload at E9.
Stacked on
Stacked on #22302 (
tejaswi/relay-response-signatures). Once that lands, this rebases onto develop.Validation
go test ./core/services/gateway/handlers/confidentialrelay