Introducing Layer N's StateNet

February 6th, 2024 by Layer N

Layer N is designed with one mission in mind: to expand the surface area of what’s possible on-chain. We believe that building in web3 should never be a trade-off. But blockchain infrastructure today is heavily constrained and suffers from two major challenges: performance and composability. Existing solutions prioritize one over the other.

The monolithic approach of building on an L1 or L2 has the advantage of synchronous composability among applications that share a common state. The major downside is performance degradation due to the over-subscription of the underlying blockchain resources by potentially unbounded number of apps. Applications share the same compute and gas bandwidth as thousands of other applications, leading to constrained computational scale and freedom (i.e. harder to implement complex and creative features), congestion, and gas spikes. Consensus requirements for L1 solutions also mean that latency is often a few magnitudes higher than typical web2 applications. Even newer L2 solutions are unable to match web2 UX due to data availability throughput bottlenecks. These performance problems lead to overall degraded user experiences.

The other common approach is building a standalone rollup. The advantage here is a purpose-built and dedicated compute environment that makes it easier to build scalable applications. The major downside is the loss of synchronous composability and the resulting liquidity fragmentation. Solutions like bridges and interoperability frameworks exist, but those lead to other problems like third-party bridge risks, wrapped asset liquidity fragmentation, and withdrawal periods for optimistic-style rollups that lead to overall constrained access to liquidity, flow of liquidity, and composability between applications.

Layer N's StateNet is a solution that provides the performance of modular standalone rollups while retaining the synchronous composability benefits of the monolithic stack. We believe that to enable the next generation of on-chain applications, we first need to achieve performance and feature parity with centralized systems. Once at parity, we enable something irreproducible in the centralized world: seamless composability with thousands of open and innovative on-chain applications through native direct composability and liquidity sharing without withdrawal latencies or bridging risks.

Network Architecture

XVMs

Each node in the StateNet runs a distinct virtual machine (VM). Some VMs are generalized VMs like the EVM, and others are app-specialized custom VMs called XVMs. VMs in the StateNet post input data to a publicly available data availability layer such as EigenDA, and post state update blocks to Ethereum to finalize the network state. The StateNet is horizontally scalable, and can support the deployment of thousands of VMs.

VMs fall under three types:

• System VMs (SysVM)
• Generalized VMs (GVM)
• Application-specific VMs (XVM)

I. System Virtual Machines (SysVM)

System Virtual Machines (SysVM) are foundational VMs that take on system-level functional roles. Their roles are to support the network in enabling system-level features and capabilities. Examples of these include the Router, which aggregates message passing and control functions for a group of logically related VMs, and the Gate VM (or simply Gate) that unifies liquidity management for the network. We go into further detail about these VMs and their responsibilities later. For the purposes of building applications on the StateNet, SysVMs provide infrastructure support for building applications on the StateNet and are not directly interfaced by XVM developers and operators.

II. Generalized Virtual Machines (GVM)

Generalized Virtual Machines (GVM) are VMs that provide a generalized smart contract execution environment. GRNs allow developers to deploy smart contracts in their favorite language that can compose with other VMs, generalized or not. An example of a GVM is the N-EVM, Null Studios’ implementation of the EVM that enables public and permissionless smart contract deployment. Other potential GVMs include the SolanaVM, the MoveVM, or any other general execution environment. The StateNet supports the deployment of all kinds of GVMs and enables these GVMs and the applications built on-top of them to compose seamlessly with other GVMs and XVMs.

III. Application-specific Virtual Machines (GVM)

Application-specific Virtula Machines (XVM) are instead dedicated to running a single program Unlike GVMs, XVMs run entirely custom pre-deployed application logic. Each XVM operates a single application. The application logic does not need to conform to the constraints of the EVM or any other generalized VM either, enabling specialized implementations unconstrained by other programs and the environment. An example of a XVM is the NordVM, an exchange-optimized VM purpose built for the orderbook use case. The NordVM is an entirely custom rust-based orderbook program. Another example can be a market making VM node that runs complex trading algorithms. Each XVM is a rollup with custom application-specific execution logic. XVMs enable developers to build highly computationally complex applications without worrying about congestion, gas, compute constraints, and performance constraints. XVMs are also directly composable and callable by other XVMs as well as GVMs and the smart contracts built on-top of GVMs.

Inter-VM Communication

Inter-VM Communication lays out the pipes and gears towards enabling StateNet-wide message passing. We highlight three key components to the system:

• Message Queues
• Routers
• The Gate

I. Message Queues

VMs communicate by maintaining point to point message queues. The queues guarantee exactly-once delivery semantics for inter-rollup messages. Each VM manages separate message request and reply queues. The state of and operation on the queues are then validated and authenticated by the VM’s native state validation scheme, allowing validators to demonstrate state inconsistencies without having to run the full network.

II. Routers

Routers are intermediary SysVMs that route transactions between logical clusters of VMs, which we call a fault domain. Routers provide load balancing and atomicity by acting as a sequencer between a cluster of VMs. Router behavior is fully customizable, including whitelists and load management policies.

III. Gate

The gate VM is a specialized SysVM that handles all deposits into and withdrawals out of the Layer N StateNet. The gate functions as an entry and exit point for Layer N. Once liquidity has been deposited into Layer N through the gate, it can then freely move between all other VMs. The asset transfer between VMs does not need to go through the Gate afterwards because of the GMP functionality provided by Layer N message queue infrastructure. This design ensures that no double spend occurs when VMs move assets between each other.

XVM Architecture

Now that we have an understanding of how the network is composed at a high level, we can look into how each VM is able to maintain a standard for communicating and interacting with each other, as well as how we can enable the scalable permissionless deployment of XVMs across the Layer N StateNet.

At a high level we can separate each VM into 5 distinct modules:

I. Input module

The input module deterministically schedules input messages to the VM's state machines. Input messages are sourced from the following 5 types of streams:

• Transfer stream - asset transfers
• User stream - messages sent by regular users
• Cron stream - messages submitted by cron jobs
• VM stream - messages passed by other VMs
• Read stream - read requests by other VMs

The input messages are stored in a queue, and network handshakes are used to respond to the message sender to confirm the proper execution and receipt of the messages.

II. Execution engine module

The execution engine module defines the execution logic. It is the part of the VM that takes in the input data, executes program logic on the input data, and outputs results to the output module for messages that require being sent to another VM. For GVMs, the engine is a generalized state machine like the EVM, SolanaVM, etc. For XVMs, the engine is an application-specific execution engine. For developers building their own GVMs or XVMs, the execution engine is where they will be able to fully customize and develop their own logic.

III. Output module

The output module holds data that needs to be routed to other VMs.

The output messages are stored in a queue, and await network handshakes before cleaning up sent messages to ensure exactly-once delivery.

IV. Rollman module

The rollman module is responsible for posting network and transaction-level data to a data availability layer, and ensuring proper state block settlement on Ethereum.

V. Cron module

With the cron module, developers can schedule events and callbacks to execute without relying on a third party off-chain service. The jobs scheduled in the cron module are natively routed to the input module and fed into their respective VMs.

Conclusion

Current on-chain infrastructure is limiting in terms of performance, composability, and liquidity sharing. The StateNet is a system that can achieve the performance of modular standalone rollups while retaining the synchronous composability and shared liquidity of the monolithic stack, without third party bridge risks and other UX constraints like withdrawal periods.

If the StateNet sounds like something you’d be interested in learning more about, help develop, or build on-top of, we encourage you to reach out to us and join our community through our various social channels (opens in a new tab).