Virtual Machine and Execution Environment

Abstract

Activation

Parameter	Value
Flag string	lp2-lux-vm-execution
Default in code	N/A
Deployment branch	N/A
Roll-out criteria	N/A
Back-off plan	N/A

LP-2 specifies the Lux execution model, which is designed to be EVM-compatible while allowing future extensibility for new virtual machines. The proposal’s primary goal is to leverage the rich developer ecosystem of Ethereum by supporting the Ethereum Virtual Machine (EVM) as a core smart contract engine. By adopting an EVM-compatible execution environment, Lux enables developers to deploy Solidity smart contracts and reuse existing tooling, compilers, and security audits – accelerating adoption through familiarity. This design choice mirrors the approach of other layer-1s like Lux (which implements an ARM-compatible “C-Chain” running the EVM) and Cosmos SDK chains that incorporate Ethereum’s Web3 API, thereby lowering the barrier for DApp migration. LP-2 details how Lux’s VM executes transactions deterministically across all validators in a chain, and how it handles gas pricing, resource metering, and possible improvements over the vanilla EVM. One improvement under consideration is integrating the HyperSDK techniques (as pioneered by Lux) to increase throughput by parallelizing transaction processing and pre-validating blocks. Additionally, the proposal discusses modularity: while the default VM is the EVM for general-purpose computation, Lux’s architecture permits specialized VMs for particular chains (for example, a WASM-based VM or application-specific state machines) without affecting other chains. This modular execution approach is influenced by the heterogeneous multi-chain philosophy – each chain can choose the VM that best fits its use case, whether it be for DeFi, gaming, or privacy-centric applications. The LP also covers the Smart Contract Standard Library and APIs that Lux provides, ensuring that contract behavior on Lux aligns with Ethereum’s well-understood semantics (for instance, compatibility with ERC-20, ERC-721 standards for tokens) to maximize cross-chain composability. By clearly defining the execution environment, LP-2 lays th...

Motivation

[TODO]

Specification

[TODO]

Rationale

[TODO]

Backwards Compatibility

[TODO]

Security Considerations

[TODO]

Implementation

C-Chain EVM Implementation

Location: ~/work/lux/evm/ (Coreth - Lux EVM) GitHub: github.com/luxfi/evm

Core EVM:

• Base: Fork of go-ethereum (geth) with Lux modifications
• core/vm/ - EVM interpreter and execution
• core/state/ - State management with Merkle Patricia trie
• params/config.go - Chain configuration and hard fork rules

Lux-Specific EVM Extensions:

• plugin/evm/ - Plugin architecture for node integration
• precompile/contracts/ - Custom precompiles:
  • ML-DSA (0x0200...0006) - Post-quantum signatures
  • CGGMP21 (0x0200...000D) - Threshold ECDSA
  • NativeMinter, FeeManager, Warp, etc.

Optimizations:

• LP-176: Dynamic gas pricing (evm/lp176/)
• LP-226: Dynamic block timing (evm/lp226/)
• Parallel transaction processing (under development)

Testing:

cd ~/work/lux/evm
go test -v ./core/vm ./core/state
# Comprehensive EVM execution tests

VM Registry and Management

Location: ~/work/lux/node/vms/ GitHub: github.com/luxfi/node/tree/main/vms

VM Manager:

• registry/vm_registry.go - VM registration and lifecycle
• manager.go - Cross-VM coordination

Registered VMs:

1. Platform VM (vms/platformvm/)

• Purpose: Validator management, staking, chain coordination
• Execution: Native Go, not EVM-based
• Key Files:
  • vm.go - Core platform logic
  • txs/ - Transaction types
  • state/ - Validator/staker state

2. AVM (X-Chain) (vms/avm/)

• Purpose: Asset exchange and UTXO-based transfers
• Execution: Custom VM with DAG consensus
• Key Files:
  • vm.go - Asset VM core
  • txs/ - Asset transaction types
  • utxos/ - UTXO management

3. Quantum VM (Q-Chain) (vms/quantumvm/)

• Purpose: Post-quantum cryptography and hybrid consensus
• Execution: Custom VM with Quasar consensus
• Key Files:
  • vm.go - Quantum VM
  • config/config.go - Ringtail and ML-DSA config
  • txs/ - Quantum-safe transactions

4. EVM (C-Chain) (via ~/work/lux/evm/)

• Purpose: Smart contracts and DeFi
• Execution: Full EVM compatibility
• Integration: plugin/evm/vm.go implements snowman.ChainVM interface

Solidity Contract Standards

Location: ~/work/lux/standard/

Token Standards (standard/src/tokens/):

• LRC20.sol - LRC-20 (LP-20)
• LRC721.sol - LRC-721 (LP-721)
• LRC1155.sol - LRC-1155 (LP-1155)

DeFi Standards (standard/src/defi/):

• UniswapV2-style AMM (available in standard/contracts/liquidity/)
• UniswapV3-style concentrated liquidity (available in standard/contracts/liquidity/)
• Lending protocols, staking contracts, etc.

Precompile Interfaces (precompiles/):

• IMLDSA.sol - Post-quantum signatures
• ICGGMP21.sol - Threshold signatures
• IWarpMessenger.sol - Cross-chain messaging

Testing:

cd ~/work/lux/standard
forge build
forge test --match-contract ERC20Test
forge test --match-contract ERC721Test
# Comprehensive Solidity contract tests

Gas Metering and Pricing

Static Fee Configuration:

• P-Chain: ~/work/lux/node/vms/platformvm/txs/fee/calculator.go
• X-Chain: ~/work/lux/node/vms/avm/txs/fee.go

Dynamic Gas (C-Chain):

• LP-176 Implementation: ~/work/lux/node/vms/evm/lp176/
  • config.go - Dynamic gas parameters
  • calculator.go - Gas price calculation

Precompile Gas Costs:

• ML-DSA verify: 100,000 + (message_bytes * 10) gas
• secp256r1 verify: 3,450 gas (LP-204)
• BLS aggregate verify: Variable based on signature count

VM Integration Testing

End-to-End Tests:

# Test all VMs in local network
cd ~/work/lux/netrunner
RUN_E2E=1 go test -v ./tests/e2e/

# Tests verify:
# - Platform VM validator operations
# - AVM asset transfers
# - EVM smart contract execution
# - Cross-VM Warp messaging
# - Q-Chain quantum signatures

Performance Benchmarks:

• Platform VM: ~2,000 validator txs/sec
• AVM: ~10,000 transfers/sec
• EVM: ~1,500 contract calls/sec (single-threaded)
• Q-Chain: ~500 quantum-verified txs/sec

Test Cases

Unit Tests

1. Component Initialization

   • Verify correct initialization of all components
   • Test configuration validation
   • Validate error handling for invalid configurations

2. Core Functionality

   • Test primary operations under normal conditions
   • Verify expected outputs for standard inputs
   • Test edge cases and boundary conditions

3. Error Handling

   • Verify graceful handling of invalid inputs
   • Test recovery from transient failures
   • Validate error messages and codes

Integration Tests

1. Cross-Component Integration

   • Test interaction between related components
   • Verify data flow across module boundaries
   • Validate state consistency

2. Performance Tests

   • Benchmark critical operations
   • Verify performance under load
   • Test resource utilization limits

Copyright

Copyright and related rights waived via CC0.```