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 storage 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 validityproofs, 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:

1. Replay
   Verifier replays state on local machine after reading transaction level data
   posted on data availability layer;

2. Detection
   Verifier detects that state root update posted to Ethereum does not match the
   state root that is obtained from DA replay;

3. Proof generation
   Verifier creates a snark-proof by execution the program, which returns a
   cryptographic receipt as a proof of fraud.

4. On-chain verification
   The verifier then submits the receipt directly to the on-chain verifier that
   uses the program hash to verify the proof.

5. State recovery
   If this proof is submitted to the contract and it proves fraud, the Ethereum
   contract will go into state recovery mode and the operator will be forced
   to revert the fraudulent state update.

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.