Execution

N1 is completely agnostic to the execution environment. We encourage developers to get creative and think of specializations to squeeze more performance out, such as lightning networks or specialized exchanges. Nonetheless, N1 provides a default execution environment which we describe here. Within this execution environment, we support a multitude of different virtual machines, including TypeScript and Solidity.

Overview

N1's default execution environment is an asynchronous network of virtual machines, which we term processes. Each process can run a variety of different virtual machines and can send and receive messages from any other process in the network through ordered channels. For example, one process could be a perpetuals exchange built in TypeScript and another could be some Solidity smart contract, both of which are able to inter-operate through messages. The benefit of this approach is that there is no state contention. Each app operates independently and at its own pace, for more flexibility in performance.

The gate app is a special program that handles bridging assets from the L1 and routing them to the correct app in the L2 network. This greatly simplifies the network's topology and enables immediate liquidity between apps, on the order of seconds.

Unique properties

You'll notice that N1's default execution network is quite unusual. As mentioned, the goal is to fully exploit the capabilities of the underlying Layer 1 and provide a novel, high-performance default. We explain why that is. The key concepts are:

• dedicated compute
• asynchronous communication
• snark fraud proofs

Dedicated Compute

Existing blockchains run all applications on a single, shared virtual machine. Under sudden load, this causes state contention, gas spikes, and high latency variance, imposing strict limitations on building more complex apps. This is akin to a shared database cluster in Web2 development, which are known to be significantly less scalable.

In N1, each program is run in an isolated environment we call "dedicated compute environment". DCEs provide reserved and dedicated computational bandwith to apps, allowing each to scale vertically and to make use of the full computational resources of its own server to solve a major scalability bottleneck.

Deploying to applications is as simple as, if not simpler than, deploying on typical blockchains. N1 simplifies the process by leverage existing tooling. For example, Solidity developers can simply use foundry, Rust developers just use the wasm toolchain, TypeScript developers can use all their existing tooling.

Instantaneous communication

Programs communicate point-to-point over ordered channels with binary messages. Each message triggers the receiver program to execute the message's payload.

Unlike other messaging solutions, messages here are instantaneous, i.e. executed as soon as they land. This is unlike bridging in other blockchains, where messages on each side have to wait for some form of validation before the counterparty can trust the message.

Snark Fraud Proofs

A snark proof is a short proof of computation. In our case, we could create a proof that a given starting state and a set of actions produces some end state. The proof is fast to verify, so the verification can even be done on Ethereum.

We fundamentally believe that snarks are the future of blockchain security, but current prover systems are too slow to provide the performance we target. Thus, we take a temporary trade-off: use an optimistic model that builds on snarks to support efficient execution, but that can eventually transition to a fully verified model. In the optimistic model, instead of using snarks as validity proofs, we use them as fraud proofs. Fraud proofs are retroactive disputes submitted by validators to contest the validity of a state update. In other words, instead of using snarks to show that the end state is valid, fraud proofs prove that the end state is invalid.

The virtual machines support any deterministic function, as long as there is a snark-provable implementation for it. For example, for the EVM, any zkEVM system functions just as well. Similarly, we are able to support wasm through either zkWASM translations or binary translation to RISC-V.

Our execution environment is unique in that snark-based fraud proofs are non-interactive. That is, once a challenger has constructed a snark, all they have to do is send it to Ethereum to challenge N1's claimed state. This is unlike some optimistic rollups which use interactive schemes requiring several steps between the operator (us!) and the challenger. Interactive schemes lead to long, usually 7 day withdrawal periods and subtleties around ensuring compatibility between execution done on-chain during the challenge versus off-chain during regular execution.

The process for a verifier detecting and reporting fraud on N1 is as follows:

Data Availability

Data availability is the process by which N1's network makes available the entire history of transaction data it receives to network nodes who can then use this history to reconstruct state transitions, and verify that the state on N1 is legitimate. This is critical to ensuring that we, as the operator, are unable to withhold data to prevent a fraud proof from being created. In the case where a state transition is invalid, a node can use the transaction data to construct a fraud proof used to roll back the chain state and to slash the validator that submitted the fraudulent state update.

N1 builds on high-throughput data availability, as the throughput for any given program is bottlenecked by the data availability bandwidth. Our modular architecture allows us to allocate an arbitrary amount of bandwidth on-demand for a given program, which is critical to enabling dedicated compute.