BVM Optimistic rollups

Bitcoin, scaled. NOS is a fast, stable, and scalable Bitcoin L2 blockchain.

Introduction

By bringing smart contracts to Bitcoin, Bitcoin Virtual Machine lets developers create DEX, DAO, tokens, data storage, and many other use cases on Bitcoin. However, the biggest challenge is Bitcoin's 10-min block time.

Increasing Bitcoin capability in terms of speed is fundamental to the mass adoption of decentralized applications on Bitcoin.

The main goal of NOS (or "Nitrous Oxide") is to turbocharge Bitcoin transactions (reduce transaction latency) without sacrificing decentralization or security.

Architecture

NOS reuses the battle-tested Optimism codebase. It is a modified version of the OP Stack that adds support for Bitcoin.

Like Optimism, NOS uses Optimistic Rollup, a fancy way of describing a blockchain that piggybacks off the security of another blockchain.

In this case, NOS takes advantage of the consensus mechanism of Bitcoin instead of its own. This is possible thanks to the Bitcoin Virtual Machine protocol, which brings smart contract capability to Bitcoin.

LAYER 1

Data Validation

Implementation: The Bitcoin Network

The foundation of the NOS software stack is the Data Validation component. This component significantly impacts the security model of the whole stack. Everything else in the entire stack is derived from the Data Validation component.

Data Availability:

Implementation: The Polygon Network

For pragmatic reasons, NOS currently stores data on both Bitcoin and Polygon. Bitcoin is arguably the most secure blockchain. NOS stores the data hash on Bitcoin. Polygon is the most cost-effective storage solution. NOS stores the data (compressed transactions) on Polygon.

Smart Contract Platform

Implementation: Bitcoin Virtual Machine #0

Bitcoin Virtual Machine #0 is a special computer. It is a modified version of the EVM that adds smart contracts to Bitcoin. Bitcoin Virtual Machine #0 is used to glue all the components of the NOS software stack together.

LAYER 2

Sequencer

Implementation: op-batcher

A sequencer (block producer) determines how transactions are collected and published to Layer 1. The sequencer compresses transactions into batches and writes these batches to Polygon, and writes the hash to Bitcoin via Bitcoin Virtual Machine to ensure data availability and integrity.

NOS blocks are currently produced every 2 seconds.

Rollup Node

Implementation: op-node

The Rollup node defines how the raw data stored in the Data Availability component (Polygon) is processed to form the inputs for the Execution Engine. This is also referred to as the Derivation component, which derives the L2 blocks from the L1 blocks.

Execution Engine

Implementation: op-geth

The Execution Engine defines the state transition function. It takes inputs from the Rollup node, executes on the current state, and outputs the new state. op-geth is a modified version of the EVM that adds support for L2 transactions.

Settlement

Implementation: op-proposer

The Settlement component commits the Merkle root of the new state (the output from the Execution Engine) to Bitcoin. Note that the state roots are not immediately valid. In an optimistic rollup setup, state commitments are published onto Bitcoin as pending validity for a period (currently, set as 7 days) and subject to challenge. The Optimism team is developing the fault-proof process. Once it’s completed, we’ll add it to NOS.

GOVERNANCE LAYER

Token

Implementation: NOS as a BRC-20 token

NOS is the governance token to decentralize decision-making.

DAO

Implementation: Under development

The NOS DAO manages NOS configurations, upgrades, design decisions, development grants, etc.

Directory Structure

~~ Production ~~
├── packages
│   ├── common-ts: Common tools for building apps in TypeScript
│   ├── contracts: L1 and L2 smart contracts for Optimism
│   ├── contracts-periphery: Peripheral contracts for Optimism
│   ├── core-utils: Low-level utilities that make building Optimism easier
│   ├── data-transport-layer: Service for indexing Optimism-related L1 data
│   ├── chain-mon: Chain monitoring services
│   ├── fault-detector: Service for detecting Sequencer faults
│   ├── message-relayer: Tool for automatically relaying L1<>L2 messages in development
│   ├── replica-healthcheck: Service for monitoring the health of a replica node
│   └── sdk: provides a set of tools for interacting with Optimism
├── batch-submitter: Service for submitting batches of transactions and results to L1
├── bss-core: Core batch-submitter logic and utilities
├── gas-oracle: Service for updating L1 gas prices on L2
├── indexer: indexes and syncs transactions
├── infra/op-replica: Deployment examples and resources for running an Optimism replica
├── integration-tests: Various integration tests for the Optimism network
├── l2geth: Optimism client software, a fork of geth v1.9.10
├── l2geth-exporter: A prometheus exporter to collect/serve metrics from an L2 geth node
├── op-exporter: A prometheus exporter to collect/serve metrics from an Optimism node
├── proxyd: Configurable RPC request router and proxy
├── technical-documents: audits and post-mortem documents

~~ BEDROCK upgrade - Not production-ready yet, part of next major upgrade ~~
├── packages
│   └── contracts-bedrock: Bedrock smart contracts. To be merged with ./packages/contracts.
├── op-bindings: Go bindings for Bedrock smart contracts.
├── op-batcher: L2-Batch Submitter, submits bundles of batches to L1
├── op-e2e: End-to-End testing of all bedrock components in Go
├── op-node: rollup consensus-layer client.
├── op-proposer: L2-Output Submitter, submits proposals to L1
├── ops-bedrock: Bedrock devnet work
└── specs: Specs of the rollup starting at the Bedrock upgrade

License

Code forked from go-ethereum under the name l2geth is licensed under the GNU GPLv3 in accordance with the original license.

All other files within this repository are licensed under the MIT License unless stated otherwise.