[runtime, tesseract]: Kaia consensus client

[seunlanlege]

Draft — parked pending Kaia's Permissionless hardfork (see Why this is a draft below).

Adds a light client for Kaia (ex-Klaytn, mainnet chain id 8217, Kairos 1001), an EVM chain finalized instantly by Istanbul BFT.

How Kaia finality works

~33 known companies (the Governance Council) take turns proposing blocks and signing off on each other's. A block only exists once roughly two-thirds have committed to it, so there are no reorgs and no confirmations — 1s blocks, final on arrival.

Every header carries its own finality artifact in extra_data: the proposer's secp256k1 seal plus the committee's committed seals. All plain ecrecover, no BLS. Verification mirrors the chain's own import check in blockchain/block_validator.go:

• the recovered author must be a council member
• 2f + 1 distinct council members must have committed, f = ceil(min(|council|, committee_size)/3) - 1

Mainnet today: 33 council members, blocks carry 22 seals, 21 required. State commitments are standard MPT, so state proofs reuse EvmStateMachine unchanged.

What's here

crate	role
modules/consensus/kaia/verifier	no_std verifier — header RLP, Istanbul extra, seal recovery, council tracking
modules/consensus/kaia/prover	update assembly over the kaia_* RPC namespace
modules/ismp/clients/kaia	ConsensusClient impl (KAIA)
tesseract/consensus/kaia	relayer host, config type = "kaia"

Plus registration in both runtimes, the tesseract consensus config, the fisherman's exhaustive match, the EVM registry, and relayer docs.

Things worth a reviewer's attention

The proposer seal is a double hash. Istanbul's GetSignatureAddress keccaks its payload, so the seal signs keccak256(sig_hash), not sig_hash. Recovering with the single hash yields a plausible-looking wrong address. Pinned by a fixture test.

Kaia headers are not Ethereum headers. No uncles, difficulty, gas limit or nonce; they add rewardbase, block_score, timestamp_fos, governance and vote. The geth-primitives header cannot reproduce Kaia block hashes, hence the separate type.

Validator votes have three encodings and the chain rejects none of them. Besides a single address and concatenated addresses, any other length is canonicalized via BytesToAddress — the last 20 bytes, left-padded — with no hex decoding. Mainnet blocks 75038594 and 90897408 carried the 42-byte ASCII text of an address, and the address that yields (0x6332386239...) is in the canonical council to this day. A parser that rejects these silently diverges from the chain. Both blocks are pinned as fixtures.

Governance parameters are read from live state, not genesis. istanbul.committeesize is 22 in the genesis config and 50 on-chain today; the governing node moved too. The client tracks both from ratified epoch-block governance.

Known limitations

Council freshness is a trust assumption. Updates skip blocks — Kaia produces 86,400 a day, so following every one would cost ~122 MB/day of ancestry — and no header proves the blocks before it carried no votes. Whoever assembles updates is trusted to include every vote-bearing header.

Drift in the dangerous direction is caught rather than trusted: a header declaring a validator the client doesn't know proves a skipped addvalidator (which would understate the quorum), and is rejected. A skipped removevalidator is not detectable from headers.

The quorum denominator is conservative. The chain derives f from qualified validators (council minus those below the 5M KAIA minimum stake); that's staking state, invisible to a header-only client, so the council size stands in. It's never smaller, so the client can only demand more seals than the chain — but blocks carry ~ceil(2N/3), so with 33 council / 22 seals / 21 required the margin is one. Roughly three demotions would stall the client until its state is refreshed.

Why this is a draft

Kaia's Permissionless hardfork retires most of this. Post-fork the chain enforces that a header's declared validator list matches state (kaiax/valset/impl/consensus.go — the check exists today but returns early), which turns the list from an unchecked hint into a consensus-validated claim. A quorum signature then is a quorum attestation of the roster, so the client reads it off the header: no vote parsing, no epoch tracking, no ancestry, and the quorum denominator becomes exactly right since qualified = committee post-fork. Both limitations above dissolve, and the verifier gets smaller.

It is unscheduled — PermissionlessCompatibleBlock is nil with a TODO on both mainnet and Kairos as of kaiachain/kaia@d6eb00a, and the latest release schedules only Osaka. If it activates before an upgrade the client fails closed: seals recover to non-council addresses and every header is rejected, so it stalls rather than accepting anything unsound. Kairos getting a fork block is the signal to start the rewrite.

Testing

37 unit and fixture tests. The fixtures are captured mainnet responses, so the RLP layout, block hash, both seal preimages and the historical vote blocks are pinned offline — silent drift fails the build.

cargo test -p kaia-verifier

A live suite verifies real mainnet finality end to end (bootstrap a trusted state from RPC, then verify sequential and batched updates):

cargo test -p kaia-prover -- --ignored

One caveat found while writing these: kaia_getBlockWithConsensusInfoByNumber's committers field is not a reliable oracle — it returns different sets for the same finalized block across calls (a stale signature-address cache). An independent eth_keys recovery agreed with this implementation, not with the node. The tests assert against the seals themselves.

Not included

Contracts aren't deployed on Kaia yet, so there's no EvmHosts entry, chain.ts entry, or indexer wiring. Also outstanding: testsuite-runtime registration, a CI job, and integration tests.