Add Zephyr Consensus & Performance Lab

[the-code-learner]

Scope

Introduces the first Zephyr Consensus & Performance Lab milestone and fixes the recovery gaps exposed by repeated partition testing.

Canonical performance definition

• defines headline TPS as transactions finalized by validator consensus, not API ingress or mempool acceptance
• uses a native-transfer reference workload with real P-256 signatures, validation, state execution, state commitment, proposal/vote quorum and persisted block commit
• documents finalized TPS/finality/profile/environment reporting

Multi-validator conformance harness

• runs the real api.Server, ledger, consensus automation and HTTP peer transport in-process
• parameterized validator cluster with equal voting power and certificate-gated finality
• 7-validator reference: 70,000 total voting power and 46,667 quorum
• transport fault wrapper for partitions, latency, duplicate delivery and deliberate vote-before-proposal reordering
• 7-validator certified happy path
• 4/3 no-quorum partition must stall while partitioned, then recover after heal
• 5/2 quorum partition must preserve safety and minority nodes must recover
• delayed + duplicated + out-of-order consensus messages must still converge on one tip
• the critical 4/3 partition/heal recovery also runs repeatedly as a permanent CI stress gate

Recovery gaps found and fixed by the Lab

Repeated 4/3 fault testing exposed an important integration case: after a partition heals, enough validators can sign the same proposal to finalize a block while some signers still have not materialized the committed block. Requiring quorum snapshots alone cannot immediately recover every lagging validator.

This PR adds certified block catch-up without weakening snapshot or consensus quorum:

• an authenticated internal endpoint exposes retained signed proposal/vote fragments, including evidence held by validators that have not materialized the block yet
• block evidence is an optional transport capability rather than part of the base peer transport contract
• recovering nodes collect compatible evidence from multiple peers and combine it with matching votes already persisted locally
• fragments are grouped by canonical proposal/round/block; signatures from competing proposals or rounds are never added together
• malformed or conflicting fragments from one peer do not poison compatible evidence from other peers
• the receiver independently validates the block execution, chain continuity, transaction validity, state root and block hash
• every P-256 proposal/vote signature, scheduled proposer, active validator identity and distinct voter is validated against the receiver's local validator set
• voting power is reconstructed locally and the normal 2/3+ threshold is mandatory before atomic state mutation
• evidence below quorum is rejected; tampered signatures are rejected; local+remote and multi-peer evidence can reach quorum only with enough valid validator power
• quorum-validated snapshot recovery remains the fallback for deeper repair
• the partition recovery scenario passed a 5x stress verifier before the integration was committed

Benchmarks

• 7-validator end-to-end finalized-throughput/finality benchmark over consecutive committed blocks
• reports finalized tx/s, p50/p95/p99 finality, protocol payload bytes per finalized tx, finalized block bytes and state bytes per node
• separate P-256 transaction verification benchmark
• documents CPU/heap/mutex/block profile commands for flame-graph driven optimization

First hosted-runner baseline

Development baseline only, not a production-capacity claim. One successful AMD EPYC 7763 GitHub-hosted run with 7 validators and 32 finalized transfers/block reported approximately:

• 42.92 finalized tx/s
• 628 ms p50 finality
• 1.128 s p95/p99 finality
• 23,045 B finalized block
• 17,468 B measured protocol payload per finalized tx
• 162,138 B persisted state/node
• ~88.8 us/op separate P-256 transaction-validation baseline

A separate verifier landed in the same rough range (~44.3 finalized tx/s). Shared-runner variance is expected; numerical regression gates wait for a controlled reference machine.

CI gate

• dedicated Consensus & performance lab job
• correctness/conformance is a hard gate
• partition recovery is stress-run three times in permanent CI
• benchmark samples run in CI but do not yet impose numerical TPS thresholds
• normal gofmt, go vet ./..., full go test ./..., wallet audit and build remain required
• final workflow uses read-only repository permissions; temporary integration scripts/jobs were removed

This milestone is intentionally before storage/execution redesign, libp2p/QUIC and WASM: the canonical benchmark and profiles should decide which performance architecture change comes first.