Direct Memory Architecture (DMA)

Although many smart contract platforms today advertise "native-speed execution", especially those built with high-performance WASM runtimes, this often overlooks the real bottleneck in blockchain computation. In practice, most smart contract transactions are extremely short-lived, performing only a few arithmetic or conditional operations. The real cost lies in how state is accessed and persisted.

Take a typical DEX swap operation as an example: while the core logic involves just a few integer calculations to apply a constant product formula (x * y = k), the surrounding state access is far more expensive. Reading and updating balances and liquidity pool reserves often requires multiple storage lookups, key hashing, and object (de)serialization, all of which introduce overhead that far exceeds the actual computation.

Lyquor addresses this fundamental bottleneck with a radically different approach: each contract is given its own virtual, non-volatile, byte-addressable memory space, similar to the memory model of a cloud virtual instance that can be suspended, rather than a database. This memory is persistent across executions, yet fully portable and virtualized, requiring no special hardware or OS modifications. State access becomes as efficient and intuitive as working with in-memory data structures, eliminating the need for serialization, hashing, or storage layout gymnastics.

Benefits

Zero Translation There is only one representation: in-memory form. No conversion overhead.

On-Demand Loading Only the needed fraction of the virtual memory is loaded when accessed.

Efficient Caching Frequently used portions of memory (e.g., accounts, protocol states) stay hot in host's OS, enabling native performance.

Unified Access Both network and instance states are handled through the same memory with different address range. Off-chain code can manipulate instance state that is persisted per node. Network state memory is correctly versioned during the execution of the sequence from FCO.

Data-structure Agnostic Developers can use third-party Rust libraries: as long as they support a custom Allocator, already provided in Lyquid LDK. Nothing else needs to change. To simplify development, the LDK also ships with common standard containers (Vec, HashMap, etc.) under runtime::network and runtime::instance.

Portable Node DMA is implemented entirely in user space, and therefore does not require special OS/kernel tweaks. Our node can run on major Unix-like platforms and architectures such as macOS/Linux/WSL and x86/arm. It can run on Android without rooting the device.

The Real Bottleneck in State Access

From years of our research and industrial experience, state access overhead is one of the most underestimated performance bottlenecks in blockchain systems, regardless of whether it's L1 or L2, sequential or parallel execution.

Even in those ultra-fast, consensus-free L2 systems, all transactions must eventually access the state (at least once, for ZK-rollups). In parallel execution environments, contention still occurs when multiple transactions access the same contract, often rendering parallelism ineffective due to shared-state synchronization.

There have been many different “Virtual Machines” (VMs) used across L1 and L2 blockchains. While they differ in language specification and execution performance, they all share a common goal: to make smart contract development easier by abstracting away low-level storage and database details. Broadly, there are two dominant approaches:

1. Slot-based: This approach is exemplified by the Ethereum Virtual Machine (EVM). In Solidity, the most widely used language compiled to EVM bytecode, the compiler must translate high-level data structures like bytes, arrays, and mappings into a restricted word-level key-value mapping model, because EVM provides only two core operations for persisted state access:

   • sload: read a 32-byte word from a key.
   • sstore: store a 32-byte word to a key.

   Solidity partitions all variables into logical "slots" starting from 0 index, where each one stores a 32-byte data chunk. The identifiers for the slots are then hashed into fixed 32-byte keys, which the EVM uses for load/store instructions.

2. Object-based: This approach is more coarse-grained. Platforms like Solana/Polkadot/Dfinity treat on-chain state as entire serialized objects (of structs). These objects are defined by the user and serialized/deserialized either manually or via automatic derivation (e.g., Rust's serde), typically stored under hashed keys (e.g., account-derived addresses or internal storage hashing). State updates occur when transactions invoke functions that mutate the in-memory representation, which is later serialized back.

Why DMA is Better?

There are pros and cons for each of the two approaches:

Slot-based

• Allows partial state access, which reduces amplification (i.e., how much extra data is accessed beyond what's precisely needed).
• Offers reasonable developer ergonomics, as Solidity hides the complexity of storage translation.
• However, hashing each slot destroys data locality. For example, an array of uint64 values becomes fragmented into isolated slots with "random" hashed keys.
• Developers are largely confined to using only two kinds of data structures offered by Solidity: mappings and arrays, as the compiler applies special logic to layout these structures somewhat efficiently across storage slots. Technically, more complex structs are possible, but require custom layout handling and are practically discouraged.

Object-based

• Developers face challenges in designing efficient serialization/deserialization logic.

• Although deriving Serialize/Deserialize in Rust seems straightforward in toy examples, it's not scalable for large, realistic states (e.g., user balances, liquidity pools, order books, multi-megabyte state).

• Platforms try to provide optimized containers (like Vec, BTreeMap, HashMap), but this leads to several limitations:

  1. Platforms must optimize and customize these containers internally, often using smart pointers or internal metadata tracking to capture writes made at finer granularity, effectively reintroducing slot-based storage mechanics under the hood.
  2. Users are restricted to these "blessed" containers. Using third-party data structures requires deep modifications (e.g., custom pointers), which is impractical.
  3. Even then, platforms can't introspect or incrementally access user-defined types inside these containers, so they still require full serialization and deserialization for each contract execution, again losing fine-grained access capabilities.

Lyquor addresses these challenges by treating each contract hosted on a node as a lightweight container with proper memory isolation and dedicated, persistent (non-volatile) memory. The network state of each contract is driven by sequences from FCO, while its instance state is shaped by other per-node events.

Feature	Slot-based	Object-based	DMA
Fine-grained Access	✅	❌ *	✅ (byte-level)
Cache Locality	❌	🟡	✅ (dynamic page caching)
Low Fragmentation	❌	✅	✅
No Manual Layout	✅	❌ *	✅
Good Ergonomics	🟡	❌ *	✅ (in-memory allocation)
Rich Data Structures	❌ *	🟡	✅ (any data structure via Allocator)
Hash-free	❌	❌	✅ (32-bit memory address)