lux/evm
2
0
Fork 0
mirror of https://github.com/luxfi/evm.git synced 2026-09-24 00:27:44 +00:00
Code Issues Packages Projects Releases Wiki Activity

Remove old files

Browse Source
This commit is contained in:
zeekay
2025-07-17 22:38:14 +00:00
parent b945d4f18c
commit acaa4eacac
3 changed files with 0 additions and 413 deletions
Download Patch File Download Diff File Expand all files Collapse all files
create_missing_interfaces.py
-153
View File
@@ -1,153 +0,0 @@
#!/usr/bin/env python3
import os
# Create missing interface files
interfaces_to_create = [
# Core interfaces
('interfaces/core/asm/asm.go', '''package asm
// Placeholder interface for core/asm
type Interface interface{}
'''),
# Metrics interface
('interfaces/metrics/metrics.go', '''package metrics
// Placeholder metrics interface
type Interface interface{}
'''),
# Core rawdb
('interfaces/core/rawdb/rawdb.go', '''package rawdb
import "github.com/ethereum/go-ethereum/core/rawdb"
// Re-export rawdb types
type Interface = rawdb.Database
'''),
# Trie interfaces
('interfaces/trie/trie.go', '''package trie
// Placeholder trie interface
type Interface interface{}
'''),
# Trie node
('trie/trienode/node.go', '''package trienode
// Placeholder trienode
type Node interface{}
'''),
# Ethdb memory
('interfaces/ethdb/memorydb/memorydb.go', '''package memorydb
import "github.com/ethereum/go-ethereum/ethdb/memorydb"
// Re-export memorydb
var New = memorydb.New
'''),
# Tracers
('eth/tracers/logger/logger.go', '''package logger
// Placeholder logger
type Logger interface{}
'''),
('eth/tracers/js/tracer.go', '''package js
// Placeholder JS tracer
type Tracer interface{}
'''),
('eth/tracers/native/tracer.go', '''package native
// Placeholder native tracer
type Tracer interface{}
'''),
# VM errors
('vmerrs/errors.go', '''package vmerrs
import "errors"
// Common VM errors
var (
ErrInvalidJump = errors.New("invalid jump")
ErrOutOfGas = errors.New("out of gas")
)
'''),
# Transaction pool
('interfaces/core/txpool/blobpool/blobpool.go', '''package blobpool
// Placeholder blobpool interface
type Interface interface{}
'''),
('interfaces/core/txpool/legacypool/legacypool.go', '''package legacypool
// Placeholder legacypool interface
type Interface interface{}
'''),
# Tracers
('interfaces/eth/tracers/js/js.go', '''package js
// Placeholder JS tracer interface
type Interface interface{}
'''),
('interfaces/eth/tracers/native/native.go', '''package native
// Placeholder native tracer interface
type Interface interface{}
'''),
# Test utils
('interfaces/trie/testutil/testutil.go', '''package testutil
// Placeholder test utilities
type TestUtil interface{}
'''),
# Accounts
('accounts/scwallet/wallet.go', '''package scwallet
// Placeholder smart card wallet
type Wallet interface{}
'''),
# Tests
('tests/utils/runner/runner.go', '''package runner
// Placeholder test runner
type Runner interface{}
'''),
# X warp
('x/warp/warp.go', '''package warp
// Placeholder warp interface
type Interface interface{}
'''),
# Ethdb memorydb
('ethdb/memorydb/memorydb.go', '''package memorydb
import "github.com/ethereum/go-ethereum/ethdb/memorydb"
// Re-export memorydb functions
var New = memorydb.New
var NewWithCap = memorydb.NewWithCap
'''),
]
for filepath, content in interfaces_to_create:
full_path = os.path.join('/Users/z/work/lux/evm', filepath)
os.makedirs(os.path.dirname(full_path), exist_ok=True)
with open(full_path, 'w') as f:
f.write(content)
print(f"Created {filepath}")
ethereum_consensus_integration_research.md
-215
View File
@@ -1,215 +0,0 @@
# Ethereum Consensus Integration Research for Lux Node
## Executive Summary
This document outlines research on integrating Ethereum's post-merge Proof of Stake (PoS) consensus mechanism into the Lux node, enabling it to validate on Ethereum mainnet alongside Avalanche/Lux. The integration would involve implementing Ethereum's Gasper consensus (combining LMD-GHOST and Casper FFG), supporting beacon chain architecture, and handling the execution/consensus layer separation.
## 1. Ethereum's Consensus Mechanism (Gasper)
### Overview
Gasper is Ethereum's hybrid consensus protocol combining:
- **LMD-GHOST** (Latest Message Driven - Greedy Heaviest Observed Sub-Tree): Provides slot-by-slot liveness
- **Casper FFG** (Friendly Finality Gadget): Provides deterministic finality
### Technical Implementation Details
#### LMD-GHOST
- Fork choice algorithm that uses heaviest weight instead of longest chain
- Processes only the latest attestation from each validator
- Starts search from highest justified checkpoint
- Provides probabilistic finality (~5 minutes)
#### Casper FFG
- BFT-based protocol requiring 2/3+ validators to be honest
- Two-stage finality process:
1. **Justification**: Block receives 2/3+ attestations in first epoch
2. **Finalization**: After 2 epochs of agreement (~19 minutes)
- Protects against long-range attacks
### Time Structure
- **Slot**: 12 seconds (one block proposal opportunity)
- **Epoch**: 32 slots (~6.4 minutes)
- **Finality**: ~2-3 epochs (~12-19 minutes)
## 2. Beacon Chain Architecture
### Core Components
- Manages validator registry and stake
- Coordinates validator assignments
- Processes attestations and block proposals
- Handles rewards and penalties
### Validator Requirements
- **Minimum Stake**: 32 ETH per validator
- **Hardware**: Consumer-grade (can run on mobile/single-board computer)
- **Responsibilities**:
- Attestations (voting on blocks)
- Block proposals (when selected)
- Participation in sync committees
### Validator Selection
- RANDAO pseudorandom selection for proposers
- Committee shuffling each epoch
- Weighted by validator balance
### 2025 Updates
- Over 1 million validator keys active
- Upcoming Electra hardfork: Max effective balance increases from 32 to 2048 ETH
- Consolidation of validators expected post-Electra
## 3. Execution vs Consensus Layer Separation
### Architecture
- **Execution Layer (EL)**: Handles transactions, EVM execution, state management
- **Consensus Layer (CL)**: Manages PoS consensus, validator coordination
### Communication
- Layers communicate via Engine API
- EL clients: Geth (80.1%), Erigon (8.7%), Besu (3.0%), Nethermind (2.6%)
- CL clients: Prysm, Lighthouse, Teku, Nimbus, Lodestar
### Client Requirements
- Every node needs both EL and CL clients
- Clients must be compatible pairs
- 2025 Pectra fork requires updated clients (May 7, 2025)
## 4. Ethereum Validator Operations
### Attestation Process
- Validators attest once per epoch
- Contains both LMD-GHOST and FFG votes
- 32-slot inclusion window
- Rewards decrease with delayed inclusion
### Block Proposal Process
- Pseudorandom selection via RANDAO
- Proposer gathers:
- Previous block (network head)
- Pending attestations
- Transactions from mempool
- Packages into new block
### Reward Structure
- Attestation rewards (majority of rewards)
- Block proposal rewards
- Sync committee participation
- Penalties for offline/incorrect behavior
## 5. Key Differences: Avalanche vs Ethereum Consensus
### Consensus Mechanism
| Feature | Avalanche/Lux | Ethereum |
|---------|---------------|----------|
| Type | Avalanche Consensus (Snowman) | Gasper (LMD-GHOST + Casper FFG) |
| Finality | Sub-second | ~12-19 minutes |
| Throughput | Up to 6,500 TPS | ~15-30 TPS |
| Required Agreement | 80% | 66.7% (2/3) |
| Leader | No leader | Rotating proposers |
### Technical Differences
- **Avalanche**: Uses repeated random subsampling, no fixed validator set size
- **Ethereum**: All validators participate, fixed epoch/slot structure
- **Energy**: Avalanche quiesces when idle; Ethereum validators always active
## 6. Integration Libraries and Clients
### Consensus Layer Clients (Go-based for easier integration)
1. **Prysm** (Go)
- Full-featured, production-ready
- Good documentation and APIs
- Active development
2. **Other Options**:
- Lighthouse (Rust)
- Teku (Java)
- Nimbus (Nim)
- Lodestar (TypeScript)
### Key Components to Integrate
- Beacon chain state management
- Validator client functionality
- Fork choice implementation
- Attestation/proposal logic
- Engine API client
### Integration Approach
1. Embed consensus client library
2. Implement Engine API server in Lux
3. Adapt block structures and state management
4. Handle dual consensus participation
## 7. Cross-Chain Synchronization
### Current Bridge Technologies (2025)
- **Symbiosis Finance**: 30+ networks, AMM-based
- **deBridge**: ~2 second transfers, MPC-based
- **Across Protocol**: Intents-based, L2 focused
### Architecture Considerations
1. **State Synchronization**:
- Track Ethereum state root in Lux
- Implement light client verification
- Handle reorgs and finality
2. **Transaction Relay**:
- Monitor Ethereum events
- Queue for Lux processing
- Handle atomicity/rollbacks
3. **Consensus Coordination**:
- Participate in both networks
- Handle conflicting requirements
- Manage validator keys/stakes
### Security Considerations
- Slashing risk management
- Key separation/isolation
- Network partition handling
- Economic attack vectors
## 8. Implementation Roadmap
### Phase 1: Research & Design
- Study Prysm/Lighthouse codebases
- Design integration architecture
- Define state management approach
### Phase 2: Core Integration
- Implement Engine API adapter
- Integrate beacon chain client
- Adapt block/state structures
### Phase 3: Validator Support
- Implement validator client
- Handle attestations/proposals
- Manage dual participation
### Phase 4: Cross-Chain Features
- State synchronization
- Event monitoring
- Bridge functionality
### Phase 5: Testing & Optimization
- Testnet deployment
- Performance optimization
- Security audits
## 9. Technical Challenges
1. **Consensus Conflicts**: Managing participation in two different consensus mechanisms
2. **State Management**: Maintaining separate state trees while enabling cross-chain visibility
3. **Performance**: Handling Ethereum's slower finality without impacting Lux performance
4. **Security**: Preventing cross-chain attack vectors
5. **Economic**: Managing validator incentives across chains
## 10. Recommendations
1. **Start with Prysm** as the consensus client due to Go compatibility
2. **Implement read-only mode first** to understand Ethereum consensus without validator risk
3. **Focus on modular architecture** to allow swapping consensus clients
4. **Prioritize security isolation** between consensus mechanisms
5. **Consider phased rollout** starting with testnet validation
## Conclusion
Integrating Ethereum consensus into Lux is technically feasible but complex. The main challenges involve managing dual consensus participation, handling different finality models, and ensuring security isolation. A phased approach starting with read-only Ethereum consensus monitoring before full validator integration is recommended.
fix_luxfi_imports.py
-45
View File
@@ -1,45 +0,0 @@
#!/usr/bin/env python3
import os
import re
def fix_go_file(filepath):
"""Fix Go imports in a single file."""
with open(filepath, 'r') as f:
content = f.read()
original_content = content
# Replace luxdefi/node with luxfi/node
content = content.replace('github.com/luxfi/node', 'github.com/luxfi/node')
# Write back if changed
if content != original_content:
with open(filepath, 'w') as f:
f.write(content)
return True
return False
def process_directory(directory):
"""Process all Go files in a directory."""
fixed_files = []
for root, dirs, files in os.walk(directory):
# Skip vendor and .git directories
if 'vendor' in root or '.git' in root:
continue
for file in files:
if file.endswith('.go'):
filepath = os.path.join(root, file)
if fix_go_file(filepath):
fixed_files.append(filepath)
return fixed_files
if __name__ == '__main__':
# Process the entire evm directory
fixed_files = process_directory('/Users/z/work/lux/evm')
print(f"Fixed {len(fixed_files)} files:")
for file in sorted(fixed_files):
print(f" {file}")