mirror of
https://github.com/luxfi/evm.git
synced 2026-09-24 00:27:44 +00:00
zeekayandHanzo Dev
2f9a315893
The C++ and Rust EVMs are separate luxd plugins. The host spawns every VM with VM_TRANSPORT=zap (node/vms/rpcchainvm/factory.go) and the cevm binary is exercised that way cross-process today. Choosing an EVM is choosing which plugin binary runs -- not a switch inside the Go EVM. This tree carried a second mechanism for the same choice: an in-process cgo bridge that linked C++ into the Go binary behind -tags cevm/revm, with a per-transaction executor registry, an evm_setBackend RPC to flip between backends at runtime, a resident-store config knob, and a startup log naming the chosen backend. Its executor returned nil, nil; its tagged build did not compile (cevm_resident_store.go referenced symbols cevmbridge never defined); and no build produced a binary that used it. 3,961 lines, gone. What stays is what the Go EVM actually has: the BlockExecutor seam and Block-STM behind it (blockstm.go), and the GPU accelerator seam with its darwin/cgo bridge into luxfi/gpu (gpu_bridge.go). The state processor consults both and falls through to sequential execution when neither is registered. Note for the record: nothing in the shipped binary registers a BlockExecutor, so blocks run sequentially on the Go interpreter. The removed startup log said "Block-STM across all cores"; it was not describing this binary. Wiring Block-STM into the production path changes consensus execution and is a separate decision, made deliberately, with a parity gate. Co-authored-by: Hanzo Dev <[email protected]>