Concepts
Layer N is somewhat unique in its approach, so we provide short summaries of each concept that makes us unique, as a sort of glossary or reference. 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 Layer N, 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. Layer N simplifies the process by leverage existing tooling. For example, Solidity developers can simply use foundry, and Rust developers just use the wasm toolchain.
Instantaneous communication
Layer N is a network of programs. 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 in Layer N 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.
Layer N can support any bytecode format, 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.
Layer N 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 Layer N'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 periods1 and subtleties around ensuring compatibility between execution done on-chain during the challenge versus off-chain during regular execution2.
The process for a verifier detecting and reporting fraud on Layer N is as follows:
Replay
Verifier replays state on local machine after reading transaction level data posted on data availability layer;
Detection
Verifier detects that state root update posted to Ethereum does not match the state root that is obtained from DA replay;
Proof generation
Verifier creates a snark-proof by execution the program, which returns a cryptographic receipt as a proof of fraud.
On-chain verification
The verifier then submits the receipt directly to the on-chain verifier that uses the program hash to verify the proof.
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 Layer N 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 Layer N is indeed correct and 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.
Layer N 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.
Eigen DA
Eigen DA ↗ (opens in a new tab) is a hyperscaled DA layer providing high DA rates and low costs utilizing EigenLayer restaking and cutting edge ideas in DA developed in the Ethereum community, including Danksharding. Eigen Layer re-purposes Ethereum stakers, thus also enabling high security guarantees.