CRE Don2Don accept OCR attestation of a response

[dhaidashenko]

Allow Capabilities Nodes to provide OCR attestation of the response.

Motivation

To reduce the bandwidth used by chain capabilities OCR, for some request types, nodes will exchange hashes of observed RPC responses instead of actual responses. While this greatly reduces the required bandwidth, there is now a high probability that only F+1 chain cap nodes will have the RPC response. Thus, to ensure reliability, we should allow capability nodes to provide OCR attestation so that receiving a response from a single node is sufficient.

All chain capability nodes will still attempt to send the response. If the node has only a report and no RPC payload, it will return a special error indicating that the node must wait for a response from another node.
Changes to Don2Don to ensure that only one capability node returns the report with the payload are out of scope for this PR. And the benefits of that approach are debatable.

Ticket: https://smartcontract-it.atlassian.net/browse/PLEX-2611
Depends on:

• Allow capability DONs to include OCR attestation of the responses chainlink-common#1907

[github-actions]

CORA - Pending Reviewers

All codeowners have approved! ✅

Legend: ✅ Approved | ❌ Changes Requested | 💬 Commented | 🚫 Dismissed | ⏳ Pending | ❓ Unknown

For more details, see the full review summary.

[github-actions]

I see you updated files related to core. Please run make gocs in the root directory to add a changeset as well as in the text include at least one of the following tags:

• #added For any new functionality added.
• #breaking_change For any functionality that requires manual action for the node to boot.
• #bugfix For bug fixes.
• #changed For any change to the existing functionality.
• #db_update For any feature that introduces updates to database schema.
• #deprecation_notice For any upcoming deprecation functionality.
• #internal For changesets that need to be excluded from the final changelog.
• #nops For any feature that is NOP facing and needs to be in the official Release Notes for the release.
• #removed For any functionality/config that is removed.
• #updated For any functionality that is updated.
• #wip For any change that is not ready yet and external communication about it should be held off till it is feature complete.

[github-actions]

✅ No conflicts with other open PRs targeting develop

[trunk-io]

     

Failed Test	Failure Summary	Logs
Test_CCIPTokenTransfer_EVM2Sui_ManagedTokenPool_NoRateLimit		Logs ↗︎
Test_CCIPPureTokenTransfer_EVM2Sui_BurnMintTokenPool		Logs ↗︎

View Full Report ↗︎ ⋅ Docs

[Copilot]

Pull request overview

Risk Rating: HIGH (changes remote executable request aggregation/validation logic and adds a new OCR-attestation fast-path)

This PR updates the remote executable capability client to accept and verify OCR-attested responses (rather than requiring a quorum of identical responses), and bumps chainlink-common / keystore dependencies across multiple modules to pick up the needed functionality.

Changes:

• Add OCR attestation verification for capability responses in the remote executable client request path.
• Plumb OCR3 configs through launcher → executable client → request validation.
• Update tests to cover OCR-attested responses and bump chainlink-common / keystore versions across modules.

Reviewed changes

Copilot reviewed 14 out of 21 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
core/capabilities/remote/executable/request/client_request.go	Adds OCR-attestation verification path, metering extraction helper, and new error-handling behavior.
core/capabilities/remote/executable/request/client_request_test.go	Extends request tests to cover OCR-attested responses and new constructor signature.
core/capabilities/remote/executable/request/client_request_internal_test.go	Adds focused unit tests for attestation verification logic.
core/capabilities/remote/executable/client.go	Extends dynamic config + SetConfig to carry OCR3 configs into requests.
core/capabilities/launcher.go	Passes OCR3 configs into v2 remote executable client config.
core/capabilities/remote/executable/client_test.go	Updates tests for SetConfig signature change.
core/capabilities/remote/executable/endtoend_test.go	Updates workflow-node config call signature.
go.mod	Bumps github.com/smartcontractkit/chainlink-common and .../keystore versions.
go.sum	Checksum updates for bumped dependencies.
core/scripts/go.mod	Bumps chainlink-common / keystore versions in scripts module.
core/scripts/go.sum	Checksum updates for scripts module.
deployment/go.mod	Bumps chainlink-common / keystore versions in deployment module.
deployment/go.sum	Checksum updates for deployment module.
integration-tests/go.mod	Bumps chainlink-common / keystore versions for integration tests.
integration-tests/go.sum	Checksum updates for integration tests.
integration-tests/load/go.mod	Bumps chainlink-common / keystore versions for load tests.
integration-tests/load/go.sum	Checksum updates for load tests.
system-tests/lib/go.mod	Bumps chainlink-common / keystore versions for system-test lib.
system-tests/lib/go.sum	Checksum updates for system-test lib.
system-tests/tests/go.mod	Bumps chainlink-common / keystore versions for system tests.
system-tests/tests/go.sum	Checksum updates for system tests.

Scrupulous human review focus:

• ClientRequest.verifyAttestation (signature bounds checks, config-digest checks, and overall correctness of the “1 response with F+1 sigs” acceptance criteria).
• ClientRequest.OnMessage error-handling path for ErrResponsePayloadNotAvailable and the interaction with response quorum/timeout behavior.
• Operational/logging impact of adding ocr3Configs to SetConfig logs.

Suggested reviewers (per CODEOWNERS):

• For /core/capabilities/**: @smartcontractkit/keystone, @smartcontractkit/capabilities-team
• For root go.mod/go.sum: @smartcontractkit/core, @smartcontractkit/foundations
• For /integration-tests/**: @smartcontractkit/devex-tooling, @smartcontractkit/core
• For /deployment/**: @smartcontractkit/ccip-tooling, @smartcontractkit/operations-platform, @smartcontractkit/keystone, @smartcontractkit/core

Comments suppressed due to low confidence (1)

core/capabilities/remote/executable/request/client_request.go:350

• OnMessage unmarshals the capability response (pb.UnmarshalCapabilityResponse) to check for OCR attestation, and then for the non-attestation path calls getMessageHashAndMetadata, which unmarshals the same payload again. Consider refactoring to unmarshal once and reuse the parsed response/metadata when computing the response hash to avoid redundant work on the hot path.

		resp, err := pb.UnmarshalCapabilityResponse(msg.Payload)
		if err != nil {
			return fmt.Errorf("failed to unmarshal capability response: %w", err)
		}

		if resp.Metadata.OCRAttestation != nil {
			rpt, err := extractMeteringFromMetadata(sender, resp.Metadata)
			if err != nil {
				return fmt.Errorf("failed to extract metering detail from metadata: %w", err)
			}
			// Since signatures are provided switch to OCR based validation. It's enough to get 1 response with F+1 signatures
			// to be confident that the response is honest.
			err = c.verifyAttestation(resp, rpt)
			if err != nil {
				c.lggr.Errorw("failed to verify capability response OCR attestation", "peer", sender, "err", err, "requestID", c.id, "msgPayload", hex.EncodeToString(msg.Payload))
				return fmt.Errorf("failed to verify capability response OCR attestation: %w", err)
			}

			var payload []byte
			payload, err = c.encodePayloadWithMetadata(msg, commoncap.ResponseMetadata{Metering: []commoncap.MeteringNodeDetail{rpt}})
			if err != nil {
				return fmt.Errorf("failed to encode payload with metadata: %w", err)
			}

			c.sendResponse(clientResponse{Result: payload})
			return nil
		}

		// metering reports per node are aggregated into a single array of values. for any single node message, the
		// metering values are extracted from the CapabilityResponse, added to an array, and the CapabilityResponse
		// is marshalled without the metering value to get the hash. each node could have a different metering value
		// which would result in different hashes. removing the metering detail allows for direct comparison of results.
		responseID, metadata, err := c.getMessageHashAndMetadata(msg)
		if err != nil {
			return fmt.Errorf("failed to get message hash: %w", err)
		}

[cl-sonarqube-production]

Quality Gate passed

Issues
4 New issues
1 Fixed issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.4% Duplication on New Code

See analysis details on SonarQube