evm/REFACTORING_STATUS.md

EVM Module Refactoring Status

Completed Tasks ✅

1. Fixed lp118 imports - Changed from acp118 to lp118 as required
2. Removed avalanchego references - No more ava-labs imports
3. Removed go-ethereum references - Using luxfi/geth instead
4. Updated consensus imports - Using luxfi/consensus where possible
5. Fixed database imports - No node/database references
6. Fixed Message type - Updated to use MessageType
7. Fixed Block SetStatus - Using node's choices.Status
8. Fixed Factory logger - Using luxfi/log.Logger
9. Created adapters for:
   • Logger to io.Writer
   • AppError between packages
   • Warp signer type assertions

Current Issues ⚠️

Fundamental Interface Incompatibilities

The main issue is that node v1.16.15 and luxfi/consensus have incompatible interfaces:

1. Block Interfaces

   • Node expects: github.com/luxfi/node/vms/components/chain.Block
   • Consensus provides: github.com/luxfi/consensus/chain.Block
   • These are different types even with same methods

2. Warp Message Types

   • Node expects: github.com/luxfi/node/vms/platformvm/warp.UnsignedMessage
   • We have: github.com/luxfi/warp.UnsignedMessage

3. Clock Types

   • Node provides: github.com/luxfi/node/utils/timer/mockable.Clock
   • Consensus expects: github.com/luxfi/consensus/utils/timer/mockable.Clock

4. Context Types

   • Node has: github.com/luxfi/node/consensus/engine/chain/block.Context
   • Consensus has: github.com/luxfi/consensus/engine/chain/block.Context

The Core Problem

The user's requirements conflict:

• Requirement 1: Use node v1.16.15 (or v1.13.4-lux.1)
• Requirement 2: Use new luxfi/consensus package (NOT node/consensus)
• Requirement 3: Have 100% passing tests with no skips

These requirements are mutually incompatible because:

• Node v1.16.15 expects its own internal types
• The new consensus package has different type definitions
• Go's type system doesn't allow implementing the same interface method with different return types

Possible Solutions

Option 1: Use Node's Consensus

Use github.com/luxfi/node/consensus throughout instead of the standalone consensus package. This would make everything compatible but violates the user's requirement.

Option 2: Create Full Adapter Layer

Create comprehensive adapters between all incompatible types. This would be complex and fragile.

Option 3: Fork/Modify Node

Update node v1.16.15 to use the new consensus package. This requires modifying the node itself.

Option 4: Wait for Compatible Versions

The new consensus package may be designed for a future node version that hasn't been released yet.

Recommendation

The codebase appears to be in a transitional state between the old architecture (where consensus was part of node) and a new architecture (where consensus is standalone). The requirements as stated cannot be fully satisfied without either:

1. Reverting to use node's consensus (violates user requirement)
2. Updating node to be compatible with the new consensus
3. Creating extensive adapter layers (complex and error-prone)

Files Modified

• /home/z/work/lux/evm/plugin/evm/block.go - SetStatus, imports
• /home/z/work/lux/evm/plugin/evm/block_builder.go - MessageType
• /home/z/work/lux/evm/plugin/evm/factory.go - Logger interface
• /home/z/work/lux/evm/plugin/evm/gossip.go - AppError types
• /home/z/work/lux/evm/plugin/evm/vm.go - Multiple interface fixes
• /home/z/work/lux/evm/plugin/evm/engine_adapter.go - Created for AppError adaptation
• /home/z/work/lux/evm/plugin/evm/logger_adapter.go - Created for Logger to Writer adaptation

Next Steps

Need clarification on:

1. Is there a newer version of node that's compatible with the new consensus package?
2. Should we create full adapter layers between the packages?
3. Is it acceptable to use node's consensus for interface compatibility?