Mainnet
SatoshiVM is a decentralized Bitcoin ZK Rollup Layer 2 solution compatible with the Ethereum Virtual Machine (EVM) ecosystem, using native BTC as gas. Empowered with the ability to connect both Bitcoin and EVM ecosystems, it seamlessly merges the value anchoring of BTC with the programmability of EVM, bringing infinite possibilities to the evolution of the new ecosystem.
Currently, SatoshiVM's technological approach integrates the following concepts:
ZK Rollup: SatoshiVM utilizes Rollup technology to bundle multiple transactions into a single batch, which is then submitted to a Rollup Node for verification as a single transaction.
ZK Verification: Based on the BitVM framework, SatoshiVM introduces an enhanced scheme that does not rely on the challenge-response protocol. Without altering Bitcoin's consensus rules, it uses Taproot scripts to verify the execution of any function. This method effectively ensures the validity of transactions within SatoshiVM.
Data Availability: SatoshiVM needs to send block transaction data to the BTC mainnet, allowing anyone to independently verify the accuracy of computations performed on Bitcoin.
BTC Native Gas: Similar to how Ethereum OP Rollup/ZK Rollup Layer 2 solutions use ETH as Gas for the second layer, SatoshiVM uses BTC as Gas for EVM transactions.
The overall technical architecture of SatoshiVM is as follows:
Sequencing Layer
Similar to the ZK Rollup on Ethereum, the architecture of SatoshiVM also includes divisions similar to execution and settlement layers. The Sequencing Layer depicted above is analogous to the Execution Layer in Ethereum's Rollup, encompassing the most critical components within the Layer 2 network.
The Execution module in the diagram is similar to Ethereum Layer 2's Sequencer, centrally receiving and processing user transactions to generate new Layer 2 blocks or transaction batches. The Rollup node, as illustrated, can be further divided into two categories: ordinary Layer 2 full nodes and Proposers.
In the designs of Ethereum Layer 2 and SatoshiVM, there is a certain degree of cooperation between the Proposer and the Sequencer. After the Sequencer has processed a batch of transaction commands, the Proposer attempts to synchronize the content of these transactions. In the design of Ethereum Layer 2, the data synchronization process can occur off-chain immediately or wait until the Sequencer publicly discloses the transaction content on-chain, at which point the Proposer can download it locally.
In the scheme of SatoshiVM, the additional data synchronization between the Sequencer and Proposer can occur off-chain or after the Sequencer publishes the data on the Bitcoin chain, at which point the Proposer can actively download it locally. It is important to emphasize that both the Sequencer and Proposer need to run Bitcoin nodes, meaning they must synchronize with the latest Bitcoin blocks for the Layer 2 system to operate smoothly.
Before releasing new transaction batches to the public, the Sequencer in SatoshiVM fixes their order. After completing the transaction sequencing, the following actions are triggered:
Sequencer Executes Transactions: The Sequencer executes transactions and completes state updates locally.
Packaging Transaction Data: The transaction data is packaged into a transaction batch (txn batch) / Block and sent to the Proposer (this step is optional) and the Prover.
Uploading Transaction Batches to Bitcoin Chain: The Sequencer uploads the transaction batch to the Bitcoin chain. The Proposer downloads this data locally and completes the state update.
Publishing State Commitment: The Proposer publishes the updated State commitment (State root) to the Bitcoin chain.
Responding to Challenges: If someone challenges the Commitment, the Proposer needs to respond to the Challenger's challenge.
It's worth noting that, similar to most Layer2 solutions, SatoshiVM's Sequencer uses a private mempool, meaning that, similar to mainstream Ethereum Rollups like Arbitrum, SatoshiVM does not make transaction data in the transaction pool public. The SatoshiVM Sequencer can guarantee the generation of a new Block off-chain every 3 to 60 seconds, regardless of whether new transaction requests have been submitted.
Censorship-Resistant Scheme for User Transactions
Currently, users can submit transaction requests to the Sequencer in two ways:
Direct Submission on Layer1:
SatoshiVM allows users to directly publish transaction data in a specific format on the Bitcoin chain. Layer2 nodes synchronize Bitcoin blocks and search for transactions published by users in the specific format. If the Layer2 Sequencer ignores transaction requests published by some users, the new blocks it generates off-chain cannot pass the verification by Rollup nodes and Proposers. SatoshiVM achieves censorship resistance through this method.
Direct Submission within the Layer2 Network
This method is more mainstream, where users directly send their transaction requests to specified RPC nodes via RPC calls, which then forward the requests to the Sequencer. This way of submitting transactions is much less costly than publishing transaction data directly on Layer1, but it might be subject to censorship or rejection by the Sequencer.
It is widely believed that the first method of transaction delivery can make Layer2 as censorship-resistant as possible, similar to Layer1. However, due to Bitcoin's inability to support full-fledged smart contract functionality, Bitcoin Layer2 solutions cannot include user transaction requests in a Layer1 Rollup contract like Ethereum Layer2 can. Specifically, Ethereum Layer2 can deploy fixed Rollup contracts directly on Layer1 to manage Layer2 ledger data and also directly incorporate user-submitted transaction requests, but current Bitcoin Layer2 solutions cannot adopt this approach.
SatoshiVM's transaction censorship-resistant scheme has essentially achieved the highest level of censorship resistance possible within Bitcoin Layer2. This technological approach is also employed by well-known Bitcoin Layer2 projects.
Rollup Node and Proposer
As previously mentioned, a Rollup node is essentially a standard full node within Layer2, whereas a Proposer is a select few nodes among these full nodes with special permissions. SatoshiVM's Rollup nodes and Proposers can synchronize newly added transaction data from the Sequencer through the following two methods:
P2P Network among Rollup Nodes: Rollup nodes form a P2P network under the Bitcoin chain, where each node can directly request the latest Layer2 new blocks propagated by the Sequencer from its neighbor nodes in the P2P network to learn about the latest batch of transaction requests. This step is not mandatory; Rollup nodes can choose whether or not to synchronize data in this way voluntarily.
Waiting for Sequencer to Publish on Layer1: Rollup nodes can wait for the Sequencer to finish publishing the latest transaction batch (txn batch) on Layer1 and then parse the latest few Layer2 blocks from it. Compared to obtaining data directly in the off-chain P2P network, this method is slower but offers stronger censorship resistance. In some scenarios, the Sequencer or the majority of Rollup nodes could isolate certain nodes, preventing them from smoothly synchronizing data. However, if the Sequencer regularly publishes data on the Bitcoin chain, anyone can download and synchronize it, allowing isolated nodes to bypass other Layer2 nodes and successfully synchronize the data.
After a Proposer node synchronizes a batch of ordered transactions, it executes them in sequence to complete the corresponding state transitions, resulting in new state commitments (State root). We will detail the specific meanings and generation processes of commitments and State root later in the text.
For now, let's briefly explain that state commitments are characteristic values summarizing the status of all accounts. A change in the status of any account will cause a related change in the state commitments. The global state at different moments corresponds to different state commitments, with a one-to-one mapping relationship between the two.
The Proposer is responsible for publishing the Commitment, derived from off-chain computations, onto the blockchain. (For a more detailed explanation of State root and the Proposer, refer to the L2BEAT website).
In the design of SatoshiVM, certain nodes within the Rollup node act as Proposers, promptly publishing the commitment corresponding to each transaction batch (Txn Batch) to the Bitcoin blockchain.
Settlement Layer
In a modular blockchain architecture, the settlement layer is fundamentally crucial. According to Celestia's official perspective, the settlement layer encompasses two main functions: state transition verification and bridging components. Essentially, the settlement layer ensures that off-chain state updates in Layer 2 are valid and secures asset transfers between L1 and L2. Some technical teams further break down the settlement layer into arbitration and bridging layers. The arbitration layer is the module that verifies the commitment.
As previously mentioned in the SatoshiVM proposal, Proposer nodes regularly submit State Commitments to the Bitcoin chain, representing the completion of numerous off-chain transaction executions in Layer 2 and the attainment of a new state. State Commitment publication and ZK proof generation occur concurrently, with ZK proofs released in the form of Taproot-locked UTXOs on the BTC mainnet.
SatoshiVM employs a non-interactive on-chain validation scheme. Once a Proposer submits a Commitment on the BTC chain, Verifier nodes on the Bitcoin chain observe this Commitment value and off-chain attempt to acquire the complete original data set corresponding to the Commitment to verify its integrity. If errors are detected, Verifiers can initiate a one-time interaction to involve Bitcoin nodes directly, identifying specific errors within the original dataset associated with the Commitment submitted by the Proposer. Subsequently, the Verifier can transfer the Proposer's Bitcoin UTXO as a punishment.
It's important to note that unlike bitVM, SatoshiVM's single-time interactive penalty mechanism isn't based on a challenge-response mechanism. Verifiers can ascertain whether the Proposer engaged in malicious behavior in one interaction and immediately enforce penalties. This is achieved through the technical features of Taproot Script and time locks. External observers, apart from the Proposer and Verifier, can retrospectively observe the movement of specific UTXOs on the Bitcoin chain to determine the validity of Commitments. Once a Commitment is finalized, it becomes immutable. SatoshiVM employs this approach to inherit Bitcoin's finality for Layer 2 ledger data. Further details and the specific role of Commitments will be elaborated below.
We can understand the entire process as follows: The Sequencer informs everyone that the next transaction should compute "1+1=?". After receiving this message, each Rollup Node automatically computes "1+1=2" locally. Some nodes in the Rollup Node are predetermined by the system to be Proposers, and a Proposer is deemed obligated to announce to everyone on the Bitcoin chain that the next Layer2 state should be "2".
The Proposer submits the hash value of "2" on the Bitcoin chain, indicating that this is the result of hashing the current state of Layer2. Along with submitting the hash value, the Proposer also provides a ZK proof of the computation process in the form of Taproot-locked UTXOs, allowing anyone to verify the correctness of the current Layer2 state through the spending of the relevant UTXOs.
Proving Layer (Circuits)
The Proving Layer is responsible for generating ZK Proofs and submitting them to the Sequencing Layer. Members within this layer mainly act as Verifiers to maintain the security of SatoshiVM, preventing the Sequencing Layer from acting maliciously. The Sequencing Layer sends L2 blocks to the Prover within the Proving Layer. The Prover generates ZK proofs and submits them to the Proposer.
Additionally, the Sequencer/Execution Node transmits the latest Layer2 blocks to the Prover node, allowing the latter to sync the latest Layer2 transaction records, know the latest state changes, and generate the corresponding ZK Proof. Simultaneously, the Sequencer and Rollup nodes also store the complete ledger data and global state of Layer2 locally.
After obtaining ZK proofs from the Prover, the Proposer will verify them. The verification process's corresponding Commitment is publicly posted on the BTC mainnet and downloaded by the Verifier for local verification. If verification reveals problems, challenges can be initiated through bit commitments Taproot and verification Taproot.
Last updated
