mirror of
https://github.com/luxfi/vm.git
synced 2026-08-07 05:56:50 +00:00
zeekayandhanzo-dev
f9f6cff69a
A VM linked into the node reads its per-chain atomic.SharedMemory handle straight off runtime.Runtime. A VM hosted as a ZAP plugin — the C-Chain EVM and the D-Chain dexvm both are — could not: handleInitialize rebuilds the Runtime from InitializeRequest scalars, and neither an interface over a live database (SharedMemory) nor the node's chain-alias lookup (BCLookup) is a scalar. Both were silently dropped. Every plugin-hosted VM therefore ran with SharedMemory nil and DChainID empty, so the DEX 0x9999 settlement seam was dark on every chain and every swap reverted "requires the cross-chain atomic capability". chains/atomic/atomiczap carries the handle. The node listens and the plugin dials, which is what lets the existing strictly request/response ZAP transport carry it with no duplex framing and no gRPC — the same shape already used for DBServerAddr. Both halves live in one package beside the interface they transport, so the round trip is pinned by tests against a REAL atomic.Memory over a REAL socket rather than by two mocks agreeing with each other; splitting them across repos would have made it untestable in either, since node imports vm. Those tests found two things reasoning had not. Get does not return an empty value for an absent key, it errors — so the wire propagates the error rather than softening it, because softening would let a caller that checks only err conclude an object exists. And Apply cannot take a database batch across a process boundary, so it refuses one outright instead of dropping it; the flush path does not need one, since its window is derived from a monotone consensus seq and both Puts and Removes are idempotent, making at-least-once delivery exactly-once in effect. BCLookup is not proxied. The seam resolves exactly one alias, to a value fixed for the life of the network, so the resolved id is carried instead — strictly smaller than a lookup service, and it cannot fail mid-call. Co-authored-by: Hanzo Dev <dev@hanzo.ai>