zeekayandHanzo Dev bdebad3632 eth,plugin/evm: clamp finalized/safe to accept tip + clear export height on rewind (RED MEDIUM/LOW)
Follow-up to the export-boundary re-point, closing RED's re-review MEDIUM (a finality-safety hole
reachable via our own EVM-rewind→re-import restore runbook) and LOW.

MEDIUM — the rewind path. A rewind / RLP re-import (SetLastAcceptedBlockDirect) can lower the accept
tip BELOW the persisted EXPORT-FINAL (Quasar) height; the monotone SetLastQuasarHeight + advance-only
SyncQuasarFrontier then keep it stuck high, and after the chain rebuilds past that height with a
DIFFERENT canonical, `finalized` would name a block that was NEVER ⅔-certified — reported export-final
to every bridge/DEX consumer. Two parts, both needed:
- Belt: api_backend quasarHeight() resolves finalized/safe at min(LastQuasarHeight, LastAccepted) —
  finalized/safe can NEVER exceed the served accept tip, even with a stale-high durable key.
- Suspenders: VM.reconcileQuasarWithAccept clears the durable quasarHeightKey + the in-mem height
  (eth.ResetLastQuasarHeight, bypassing the monotone guard) when the accept tip is below the export
  height — the ONE legal regression of the otherwise-irreversible frontier. Conservative reset to 0
  (nothing export-final until the rebuilt chain re-certifies). Called on boot (against the restored
  accept tip — catches an offline rewind) and after admin_importChain (the live re-import). On the
  next boot the node re-seeds consensus' export frontier from the cleared (0) height, so the
  advance-only SyncQuasarFrontier yields to the rewind without touching the four shipped fixes.

LOW — SetLastQuasarFinalized now PERSISTS the durable key BEFORE advancing the in-mem height, so the
durable key is the source of truth: a crash between the two can only leave in-mem at/behind the
durable value on boot, never ahead of it (no monotonicity dip). A persist failure does not advance.

Tests: augmented TestFinalizedSafeResolveToQuasarNeverAboveIt with the belt case (seed export height
ABOVE the accept tip → finalized CLAMPS to the tip — the case RED flagged as false confidence, now
ENFORCED); new TestReconcileQuasarWithAccept_ClearsStaleHeightOnRewind (durable key + in-mem cleared
on an accept regression) and TestSetLastQuasarFinalized_PersistsBeforeAdvancing (persist-first,
no-advance-on-failure). eth suite green under -race.

Co-authored-by: Hanzo Dev <[email protected]>
2026-07-10 05:49:40 -07:00
2026-06-28 20:35:21 -07:00
2025-08-01 01:23:42 +00:00
2025-07-21 19:04:03 -05:00
2021-12-15 12:28:56 -08:00
2022-06-27 15:40:58 -04:00
2025-07-21 21:10:03 -05:00
2025-08-01 01:23:42 +00:00
2025-08-01 01:23:42 +00:00
2026-06-28 20:35:22 -07:00
2025-08-01 01:23:42 +00:00

evm

Lux EVM

Releases CI CodeQL License

Lux is a network composed of multiple blockchains. Each blockchain is an instance of a Virtual Machine (VM), much like an object in an object-oriented language is an instance of a class. That is, the VM defines the behavior of the blockchain.

Lux EVM is the unified Virtual Machine (VM) that powers both the C-Chain and L1/L2 Subnet EVM chains. This package consolidates the former Coreth (C-Chain) and Subnet EVM codebases into a single implementation.

Note

: The github.com/luxfi/coreth repository has been deprecated and merged here. See the migration guide below.

This chain implements the Ethereum Virtual Machine and supports Solidity smart contracts as well as most other Ethereum client functionality.

Building

The Subnet EVM runs in a separate process from the main Luxd process and communicates with it over a local ZAP-native connection (LP-186 wire schema, no protobuf, no gRPC).

Luxd Compatibility

[v0.7.0] [email protected] (Protocol Version: 38)
[v0.7.1] [email protected] (Protocol Version: 39)
[v0.7.2] [email protected]/1.13.0-testnet (Protocol Version: 39)
[v0.7.3] [email protected]/1.13.0 (Protocol Version: 39)
[v0.7.4] [email protected] (Protocol Version: 40)
[v0.7.5] [email protected] (Protocol Version: 41)
[v0.7.6] [email protected] (Protocol Version: 42)
[v0.7.7] [email protected] (Protocol Version: 42)

API

The Subnet EVM supports the following API namespaces:

  • eth
  • personal
  • txpool
  • debug

Only the eth namespace is enabled by default. Full documentation for the C-Chain's API can be found here.

Compatibility

The Subnet EVM is compatible with almost all Ethereum tooling, including Remix, Metamask, and Foundry.

C-Chain vs Subnet EVM Mode

This unified EVM package supports both modes:

C-Chain Mode (Primary Network):

  • Atomic transactions for cross-chain transfers (X-Chain ↔ C-Chain)
  • Shared memory integration
  • Primary network consensus

Subnet EVM Mode (L1/L2 Subnets):

  • Configurable fees and gas limits in genesis
  • Simplified hardfork configuration
  • No atomic transactions (cross-chain via Warp messaging)

Migrating from Coreth

If you were using github.com/luxfi/coreth, update your imports:

// Before
import "github.com/luxfi/coreth/core"

// After
import "github.com/luxfi/evm/core"

All coreth functionality is preserved in this package.

Block Format

To support these changes, there have been a number of changes to the EVM block format compared to what exists on the C-Chain and Ethereum. Here we list the changes to the block format as compared to Ethereum.

Block Header

  • BaseFee: Added by EIP-1559 to represent the base fee of the block (present in Ethereum as of EIP-1559)
  • BlockGasCost: surcharge for producing a block faster than the target rate

Create an EVM Subnet on a Local Network

Clone EVM

First install Go 1.23.9 or later. Follow the instructions here. You can verify by running go version.

Set $GOPATH environment variable properly for Go to look for Go Workspaces. Please read this for details. You can verify by running echo $GOPATH.

As a few software will be installed into $GOPATH/bin, please make sure that $GOPATH/bin is in your $PATH, otherwise, you may get error running the commands below.

Download the evm repository into your $GOPATH:

cd $GOPATH
mkdir -p src/github.com/luxfi
cd src/github.com/luxfi
git clone [email protected]:luxfi/evm.git
cd evm

This will clone and checkout to master branch.

Run Local Network

To run a local network, it is recommended to use the lux-cli to set up an instance of EVM on a local Lux Network.

There are two options when using the Lux-CLI:

  1. Use an official EVM release: https://docs.lux.network/subnets/build-first-subnet
  2. Build and deploy a locally built (and optionally modified) version of EVM: https://docs.lux.network/subnets/create-custom-subnet

Releasing

You can refer to the docs/releasing/README.md file for the release process.

Plugin Runtime Env Vars

The EVM plugin reads its rpcchainvm handshake address and transport from the unprefixed env var names that current luxd (v1.26+) sets: VM_RUNTIME_ENGINE_ADDR and VM_TRANSPORT. This matches the canonical names defined in luxfi/vm/rpc/runtime/runtime.go. Earlier builds of this plugin (via luxfi/vm ≤ v1.1.0) read LUX_VM_RUNTIME_ENGINE_ADDR/LUX_VM_TRANSPORT, which are no longer recognized.

S
Description
▼ LUX EVM: Launch your own Ethereum compatible EVM on Lux Network.
Readme
548 MiB
Languages
Go 96.1%
Solidity 1.6%
Shell 1.3%
TypeScript 0.9%
Makefile 0.1%