Validate outpost signer references and Ethereum chain IDs

[huangminghuang]

Summary

• require every Ethereum and Solana outpost client signer reference to match an explicitly named --signature-provider
• enforce the correct target chain and native key type for each outpost
• reject empty client IDs, signer names, and RPC URLs with plugin configuration errors
• validate explicitly configured Ethereum chain IDs with eth_chainId during startup using checked uint32_t parsing
• bound Ethereum client construction, DNS resolution, and explicit chain-ID validation to five seconds
• retain the three-field Solana client schema and signer-integrity checks without adding partial cluster-identity behavior
• add deterministic loopback RPC fixtures, startup validation coverage, provider-provenance tests, and updated operator documentation

Behavior

Signature-provider references

Outpost client configuration previously resolved signer references through the general provider registry. Anonymous key-N aliases and programmatically created providers could therefore satisfy a reference even though the operator had not supplied a stable shared name.

Both Ethereum and Solana clients now require the referenced name to come from the explicit five-field --signature-provider form. The provider must also use the target chain's native key type.

Ethereum chain IDs

The optional fourth Ethereum client field is parsed as a positive 32-bit decimal integer or Ethereum hex quantity. When present, startup calls eth_chainId, rejects malformed/error responses, and fails on mismatch before registering the client.

The legacy three-field Ethereum format intentionally remains non-probing for compatibility: when no expected chain ID is configured, client construction still validates the URL and resolves DNS, but startup does not perform a reachability/identity RPC.

Solana scope

--outpost-solana-client remains exactly:

<client-id>,<sig-provider-id>,<rpc-url>

PR #534 validates the explicit signer reference, Solana target chain/key type, and non-empty fields. It deliberately does not add an optional genesis hash or a startup getGenesisHash probe. Mandatory startup pinning, runtime freshness, bypass-resistant gating, and telemetry belong to SEC-139 / WSA-225 and will be implemented as a separate complete control.

Review follow-up

• deduplicated Ethereum exception translation and changed construction failures to neutral wording
• preserved three-field Ethereum no-probe compatibility instead of expanding the requirement to unconditional reachability checks
• retained the registered outpost chain-ID width as uint32_t; wider EVM chain IDs require a separate protocol/contracts migration
• removed the partial Solana cluster-identity implementation and its obsolete review concern while retaining Solana signer hardening
• added Solana empty-field coverage and explicit rejection of a fourth client field
• merged current origin/master (d224ba5606) and retained its role-aware Solana IDL/envelope-layout decoding while resolving the overlapping test include block

Validation

• rebuilt Release targets:
  • test_signature_provider_manager_plugin
  • test_outpost_ethereum_client_plugin
  • test_outpost_solana_client_plugin
• focused CTest suites: 3/3 passed after the origin/master merge
• git diff --check origin/master
• full 11-file PR-only diff and 3-commit review
• independent Claude C++/security review of the feature diff: CLEAN

Earlier validation of the unchanged JSON-RPC transport and compatibility path also passed json_rpc_client_tests (10/10) and 100 repeated Ethereum three-field no-RPC runs.

Notes

The feature branch was created directly from origin/master at c3b84b93bf and now includes merge commit 099e239bc1 from current origin/master (d224ba5606) to resolve the GitHub conflict. It does not include or depend on PR #516.

[heifner]

Reviewed the outpost startup-validation changes. Core logic is solid: get_client_by_chain_id fails closed on ambiguity, parse_chain_id is overflow-guarded, and the deadline_scope is genuinely honored by the json-rpc transport via current_deadline(). A few notes below, mostly minor.

[heifner]

Re-reviewed b9a58cfdac. The helper extraction cleanly resolves the catch-block feedback (acknowledged on the individual threads), and the removal is consistent across the plugin, README, and tests. One doc note and one design note:

The ## Why and ## Validation sections of the PR description still describe Solana getGenesisHash startup validation, which this commit removed. Worth updating so the description matches the shipped behavior. Inline note below on the cluster-identity tradeoff itself.

[heifner]

Approving the outpost startup-validation changes.

Reviewed through the origin/master merge (099e239bc1): the Ethereum and signature-provider-manager changes are unchanged from prior review, the Solana signer/chain/key/empty-field validation survived the merge intact, and the merge's solana_outpost_role threading correctly matches master's create_outpost_client signature.

Signer references now require an explicitly named --signature-provider with the correct target chain and key type; explicit Ethereum chain IDs are parsed as checked uint32_t and verified against eth_chainId within a five-second bound; get_client_by_chain_id fails closed on ambiguity. The uint32_t chain-id ceiling and the deferral of mandatory Solana cluster pinning to SEC-139/WSA-225 are both intentional and documented.

All review threads resolved. Build/test CI is still running on the merge head, so this is the code sign-off; recommend merging only once CI is green.

[huangminghuang]

Residual follow-up recorded: SEC-141 tracks the documented uint32_t EVM external_chain_id ceiling and any coordinated protocol/contracts migration needed to support wider chain IDs. This remains intentionally out of scope for PR #534.