Lattice Virtual Machine (LVM)
The Citrate Virtual Machine (CVM) is built on REVM, the same Rust EVM implementation used by many Ethereum clients. It is fully EVM-compatible: any Solidity contract you can deploy on Ethereum can be deployed on Citrate without changes. The additions are seven precompiled contracts at addresses 0x1000 through 0x1004 that expose AI operations as native execution primitives.
Precompile operations: model registration, inference execution, embedding generation, LoRA adapter application, and embedding comparison. Gas costs for AI precompiles are priced proportionally to compute cost. The pricing model is specified in Paper I, Section 3.
EVM Compatibility
Developers familiar with the Ethereum ecosystem can deploy to Citrate immediately. The LVM supports:
- Solidity and Vyper smart contracts compiled to EVM bytecode
- All standard EVM opcodes up through the Shanghai upgrade
- Standard JSON-RPC methods (
eth_call,eth_sendTransaction,eth_getBalance, etc.) - Existing tooling: Hardhat, Foundry, Remix, ethers.js, viem
// This standard EVM contract works on Citrate without changes
contract SimpleStorage {
uint256 public value;
function store(uint256 _value) external {
value = _value;
}
}
The EVM compatibility means the entire Ethereum developer ecosystem -- tools, libraries, tutorials, and audited contract patterns -- is available to Citrate developers from day one. Our goal was to make onboarding as frictionless as possible: if you know Solidity, you already know how to build on Citrate.
Built on REVM
Rather than forking geth or another Go implementation, Citrate chose REVM as the foundation for the LVM. REVM is a high-performance Rust implementation of the EVM that provides:
- Near-native execution speed for smart contract bytecode
- Memory safety guarantees from the Rust compiler
- Deterministic gas metering
- A clean extension point for custom precompiles
REVM's architecture makes it straightforward to inject Citrate's seven AI precompiled contracts without modifying core EVM execution logic.
Why "Lattice"?
The name comes from the LVM's approach to state management. In a standard EVM, global state is a single Merkle-Patricia trie. The LVM extends this with a lattice-based state structure where:
- Base state holds standard account balances, nonces, and contract storage (identical to EVM).
- Model state tracks registered AI models, their metadata, and version history.
- Adapter state stores LoRA adapter weights and their composition graph.
- Reputation state maintains blue scores and mentorship signal histories for each node.
These four dimensions form a product lattice where each dimension can be updated independently, enabling parallel state transitions that align with GhostDAG's parallel block production. When blocks from different DAG branches modify different state dimensions, they can be merged without conflict.
State Lattice:
┌─────────────┐
│ Base State │ (accounts, balances, contract storage)
├─────────────┤
│ Model State │ (model registry, versions, metadata)
├─────────────┤
│Adapter State │ (LoRA weights, composition graph)
├─────────────┤
│ Rep State │ (blue scores, mentorship history)
└─────────────┘
AI Precompiles
The LVM includes seven precompiled contracts at reserved addresses (0x0100--0x0106) that provide native AI operations at gas costs far below what equivalent Solidity logic would require. These precompiles are the primary interface between smart contracts and Citrate's AI subsystem.
See AI Precompiles for the full reference.
Execution Flow
When a transaction is submitted to the LVM:
- Decode -- The transaction is parsed and the target contract is identified.
- EVM Execute -- Standard EVM bytecode runs in the REVM interpreter.
- Precompile Intercept -- If the contract calls an AI precompile address, execution is routed to the native AI handler.
- State Commit -- Modified state is written to the appropriate lattice dimension.
- Receipt -- A transaction receipt is generated with standard EVM logs plus any AI-specific events.
Gas Metering
Standard EVM operations use Ethereum-equivalent gas costs. AI precompile operations have custom gas schedules designed to reflect actual computational cost:
| Operation | Approximate Gas |
|---|---|
| Model deployment | 100,000 + input size |
| Single inference | 5,000 + 10/element |
| Batch inference | 5,000 + batch overhead (20% discount) |
| Model metadata lookup | 2,600 |
| Proof verification | 3,000 + proof size |
| Model benchmark | 500,000 |
| Model encryption | 100,000 + input size |
Further Reading
- AI Precompiles -- detailed reference for all seven precompile contracts
- GhostDAG Consensus -- how parallel blocks drive parallel state transitions