[runtime, tesseract]: Arc consensus client

[seunlanlege]

Overview

Consensus client for Arc, Circle's EVM L1 finalized by a fork of Malachite (the Tendermint consensus algorithm, but none of CometBFT's wire formats). Finality is attested by commit certificates: per-validator ed25519 signatures over SSZ-encoded precommits for the execution block hash.

Trust model

1. Certificate verification: reconstruct each validator's 75-byte SSZ precommit sign-bytes {Precommit, height, round, block_hash, address} and verify ed25519 signatures against the trusted validator set, requiring strictly more than 2/3 of total voting power (Malachite's quorum rule, including duplicate/unknown-signer rejection).
2. Header binding: keccak256(rlp(header)) == certificate.block_hash, yielding a trusted state_root/timestamp for the StateCommitment. State machine dispatch reuses the generic EvmStateMachine (Arc is stock reth).
3. Validator set rotation: the active set lives in the ValidatorRegistry system contract (0x36..02, ERC-7201 storage). Every update carries an EIP-1186 proof of the set against the newly finalized state root; the reconstruction mirrors the Arc node's own getActiveValidatorSet() filtering (Active status, non-zero power, decompressible ed25519 key) so the adopted set and quorum denominator match consensus exactly. Adopting a new set always requires the previous set's signatures. Arc has no epochs, so rotation can happen at any block; the relayer walks back to the rotation boundary when a tip certificate no longer verifies.

Components

• arc-primitives / arc-verifier (modules/consensus/arc): no_std types, sign-bytes construction, registry slot derivation, and verification.
• arc-prover (modules/consensus/arc/prover): fetches certificates (arc_getCertificate), headers, and registry proofs. Public Arc RPCs run reth's default zero eth_getProof window while producing 2–4 blocks/s, so proofs are requested at "latest" and the anchor block is discovered afterwards by verifying the account proof against candidate headers' state roots. A separate certificate endpoint is supported since third-party providers (e.g. Alchemy) don't proxy the arc namespace.
• ismp-arc (modules/ismp/clients/arc): the ConsensusClient, registered in the gargantua runtime. Fraud proof = two conflicting quorum certificates at the same height.
• tesseract-arc (tesseract/consensus/arc): IsmpHost consensus relayer, registered as type = "arc" in tesseract-consensus-config.

Testing

test_arc_consensus_client follows live Arc testnet consensus like test_beefy_consensus_client: bootstraps a trusted state from a storage proof, then fetches and fully verifies 5 consecutive finalized updates. Latest run verified certificates at heights 50764534–50764567 with 12/17–17/17 signature participation (17 active validators, total power 28000). test_arc_rejects_tampered_certificate verifies signatures re-pointed at a different block are rejected. Six verifier unit tests cover the quorum boundary (exactly 2/3 fails), duplicates, unknown signers, invalid signatures, and power weighting. CI gains an arc change filter and a gated arc-tests job.

Follow-ups

• evm/config.testnet.toml entry + HostExecutive params once the EvmHost is deployed on Arc testnet (chain id 5042002).
• Arc's sign-bytes currently have no domain separation; arc-node reserves a fork-version field for it, so the format will likely change before their mainnet — needs tracking.
• Mainnet chain id dispatch when Arc mainnet launches.