feat(proposervm): dedup inner block bytes when the inner VM retains accepted blocks

[containerman17]

Why this should be merged

The proposervm persists each accepted block's full container, including the inner block bytes that the inner VM already persists in its own database, so every subnet block is stored twice. Measured on a 751k-block mainnet L1 (FIFA): the duplicate inner bytes are 1.36 GiB, 19.7% of that subnet's total storage (proposervm store 1.755 GiB, of which 1.385 GiB is inner bytes). This removes the second copy with no configuration.

How this works

Inner VMs declare a capability in their InitializeResponse: a new additive proto3 field retains_accepted_blocks = 6 meaning the VM durably retains every accepted block's bytes, retrievable via GetBlock, forever. No RPCChainVMProtocol bump is required (additive field, defaults false). The capability surfaces through a small optional interface (block.RetainsAcceptedBlocksVM), is set by rpcchainvm.VMServer from the served VM, exposed by VMClient, and forwarded through tracedvm. subnet-evm and coreth (the C-chain) implement it returning true: in both VMs accepted bodies are never deleted (state pruning, offline pruning included, only touches the state trie; only rejected blocks are removed). On the C-chain the method is declared by the atomic VM wrapper, since that is the VM the proposervm wraps and it embeds the inner VM as an interface, so a declaration on the inner evm.VM alone would not surface; coreth runs in-process, so the Go interface rather than the proto field is what engages there.

The proposervm checks the capability after the inner VM initializes and, when set, stores accepted blocks in a new state codec version (v1): the block bytes with the inner bytes stripped, plus the inner block ID. Reads reconstruct the exact original container by fetching the inner block from the inner VM. Both codec versions are always readable, so databases with mixed records (normal after an upgrade) work; existing v0 records are not rewritten.

Safety, in depth:

• Write time: every stripped block is restored and byte-compared against the original before being written; any mismatch falls back to the legacy full v0 record. Because this check is pure in-memory container mechanics, a mismatch has no legitimate data-dependent cause and can only be a strip/restore code bug for some container shape, so the fallback is loud: an error-level log with the block ID and the cause, plus the dedup_blocks_fallback metric (alongside dedup_blocks_stored). Hard-failing the write instead was rejected: a shape-dependent bug would halt every upgraded node on the same block, and a storage feature must not be able to halt consensus.
• Read time: the reconstructed block's ID is asserted to match the store key, so a wrong inner block can never be served.
• VMs without the capability (P-chain, X-chain) keep the v0 path byte-for-byte unchanged.

How this was tested

• Unit tests: strip/restore round-trips for all four stateless block types (signed, Granite, unsigned, option), dedup storage path, plus the existing state suites against the new constructor signatures. Tests that exercise the dedup write path assert dedup_blocks_fallback stays 0, and a dedicated test drives the fallback branch (a block whose bytes cannot round-trip) asserting the counter fires and the record is stored in the legacy full format.
• End-to-end on a mainnet L1 (TixChain, 2834 blocks), synced from genesis with no subnet config and no chain config: the capability engages on its own (inner VM retains accepted blocks; storing blocks without inner bytes), dedup_blocks_stored 2834, dedup_blocks_fallback 0, all records codec v1, clean restart, historical RPC reads fine.
• Size: proposervm block store 7.14 MiB (master baseline node, same chain, same tip) vs 1.51 MiB deduplicated, 79% smaller, consistent with the FIFA measurement above.
• Bulk serving (the GetAncestors bootstrap-serve path adds an inner GetBlock hop per block): a p2p test peer walked the full 2835-block chain against both nodes. Master-built node: 0.11 s cold, 0.05 s warm. Dedup node: 1.15 s cold (about 0.4 ms per block for the inner hop, until the proposervm block cache warms), 0.05 s warm. Both nodes served byte-identical containers (7,187,477 bytes total).
• C-chain: unit tests (graft/coreth/plugin/evm/atomic/vm, vms/proposervm). The proposervm side is chain-agnostic, the same write/read path exercised end to end above; the C-chain declaration itself is a constant method guarded by a compile-time interface assertion, and the write-time round-trip fallback applies there like everywhere else.
• Downgrade: pointing a master-built binary at the deduplicated data dir fails chain creation with, verbatim: error while creating new snowman vm failed to repair accepted chain by height: failed to get last accepted block: unknown codec version. The node stays up, nothing is written, and re-upgrading works. avalanchego currently has no database version stamp at startup (the v1.4.5 in the db path is only a folder name), so making future downgrades fail with a friendlier message would be new node-level machinery; left as future work.

Need to be documented in RELEASES.md?

Yes: modifies the proposervm database format for chains whose VM declares retains_accepted_blocks (subnet-evm and the C-chain); downgrade to earlier versions is not supported after running this code.