mirror of
https://github.com/luxfi/api.git
synced 2026-09-24 00:24:53 +00:00
zeekayandHanzo Dev
8743bbe098
One atomic.Memory exists per node and every chain gets a handle carved out of it. A VM linked into the node reaches its handle off runtime.Runtime; a VM hosted as a ZAP plugin — the C-Chain EVM and the dexvm both are — does not, because the node rebuilds the plugin's Runtime from InitializeRequest fields and neither an interface over a live database (SharedMemory) nor the chain-alias lookup (BCLookup) survives a struct literal. The plugin's SharedMemory was therefore nil and every DEX 0x9999 settlement reverted "requires the cross-chain atomic capability". Adds the wire for it: MsgAtomicGet/MsgAtomicApply, and AtomicServerAddr + DChainID appended to InitializeRequest. The node binds a ZAP server over its own handle and the plugin dials it, so the node is the server and the existing strictly request/response transport carries this with no duplex framing and no gRPC — the same shape already used for DBServerAddr. Indexed is deliberately not proxied: no settlement path calls it. Both skew directions are pinned by test rather than reasoned about, since a wire change that forks a mixed fleet is the failure this design exists to avoid. New node -> old plugin: the appended bytes are inert, the plugin keeps its nil handle and its existing fail-closed revert. Old node -> new plugin: Remaining() is 0, so the capability reads as ABSENT instead of raising the ErrUnexpectedEOF that the Capabilities append once caused. Neither direction changes how any block executes. Co-authored-by: Hanzo Dev <[email protected]>