mirror of
https://github.com/luxfi/evm.git
synced 2026-08-07 15:24:39 +00:00
zeekayandhanzo-dev
b679723800
Two defects, both fatal, both on the C<->D atomic settlement path. 1. Accept handed the versiondb batch to sm.Apply unconditionally. The C-Chain EVM is an out-of-process plugin, so its SharedMemory is the ZAP client, and that client refuses any batch — a database.Batch cannot cross a process boundary. Every block staging an atomic op would have failed Accept, which is fatal. Commit the versiondb first, then Apply with no batch. Without a shared batch exactly-once is unreachable; the choice is at-most-once or at-least-once, and replay is unsound here (a duplicate put is fatal, and after the peer consumes the object it re-creates it). A skipped op is survivable: C's settlement replay guard is EVM state, not the Remove, and a skipped intent Put is refunded by reclaimIntent. The residual single-node cost is stated in the code. 2. The settle path read the object from shared memory DURING EVM execution while the consuming Remove landed at Accept. A node re-executing that block — bootstrapping, state-syncing, re-tracing — found the object gone, computed a reverted receipt where the network computed a successful one, and died on the receipt root. The seam settled live and wedged every node that tried to sync past it. Execution now binds to the object bytes the transaction carries and declares the consumption in its logs; this adds the block-level rule that proves the declaration against shared memory at Verify, on both the consensus path and the producer's own pre-proposal verify, so a forged object costs a block rather than forking a receipt root. The check is gated on the bootstrap frontier, which the shared-memory layer requires of any chain consuming cross-chain state. Co-authored-by: Hanzo Dev <dev@hanzo.ai>