Architecture
Last updated
Last updated
Orange network primarily consists of five key layers: Decentralized Sorting Layer, Rollup Layer, Modular Computing Layer, Data Availability (DA) Layer, and Hub Interaction Layer. By adopting efficient and secure technology solutions, it redefines the implementation approach of the Bitcoin Layer-2 network.
An overview of Orange technical architecture is illustrated in the following image.
The main process of sorting is as the following image.
Transactions are received through the RPC aggregation gateway service (RPC Gateway).
The RPC Gateway forwards transactions to the Decentralized Sequence Hub Network (DSHN) for consensus ordering.
DSHN packages the ordered transactions into blocks and forwards the validated transactions to the Rollup Layer for execution via subnet gateways.
DSHN simultaneously issues succinct commitments for the blocks. Contract verification and sorting proofs are validated, then block commitments are stored.
The Rollup Layer publishes the updated state to the Decentralized Oracle Network.
Orange Chain utilizes Optimistic Rollup to implement the Rollup Layer, responsible for executing user transactions and generating related proofs within the second-layer network. Users submit their transactions to the Rollup Layer for processing, and their states are stored in this layer as well. Batches and generated zero-knowledge proofs are transmitted to the data availability layer provided by the Decentralized Oracle Network for storage and verification purposes.
The Decentralized Oracle Network ensures the integrity of state transitions using validity proofs, but it doesn't store transaction data on the BTC network. For the DA service itself, it issues scatter requests to dispersers, who encode the Blob using Reed-Solomon coding, compute KZG commitments for the encoded Blob, and generate KZG proofs for each block. The dispersers then send the blocks, KZG commitments, and KZG proofs to operators, who return signatures. The dispersers aggregate these signatures and upload them to L1 in the form of call data for the DA contract.
The OP Stack + ZK Fraud Proof architecture is a novel design integrating validity proofs based on zero-knowledge proofs into Optimistic Rollup technology. When challengers point out that the sequencer has submitted incorrect data, they submit a challenge to Layer 1. The sequencer must generate the corresponding ZK Proof within a limited challenge time and submit it to the Layer 1 contract for verification. If the verification result indicates that the data is valid, the challenge fails; otherwise, the challenge succeeds.
The diagram illustrates the specific process of handling fraud proofs in Layer 2 technology under the Op Stack and ZK Fraud Proof architecture. In this architecture, the Op Stack module performs the core functions of Layer 2, including handling basic blockchain functions and submitting batches to Layer 1. Meanwhile, the ZK Fraud Proof module focuses on handling challenges of fraud proofs.
The process details are as follows:
Challenge initiation: Validators initiate challenges of fraud proofs.
Information synchronization: Lumoz verification nodes synchronize challenge information to prepare for the next verification step.
Obtain zero-knowledge proof inputs: Verification nodes retrieve necessary zero-knowledge proof input data from the Op Stack module, including block traces and batch information.
Generate zero-knowledge proofs: Lumoz subsequently requests the modular computing layer to generate the required zero-knowledge proofs.
Proof submission: Once the zero-knowledge proofs are generated, Lumoz verification nodes submit the proofs to Layer 1 for verification.
Through the above process, the challenge and verification process of ZK Fraud Proof is completed.
As is well known, Optimistic Rollup has lower costs but longer withdrawal wait times, while ZK Rollup requires almost no waiting time for withdrawals but has higher costs. This solution combines the strengths and weaknesses of Optimistic Rollup and ZK Rollup, maintaining the characteristics of low cost while effectively reducing waiting times.
User transactions are all submitted and processed at the Rollup layer, with their states also stored in this layer. The network generates relevant zero-knowledge proofs, packages them, and sends them to the DONA layer for storage and verification. The DONA layer encompasses decentralized storage, Orange Chain nodes, and the BTC network, used to verify the zero-knowledge proofs of Rollup and permanently store data copies from the Rollup layer. Ultimately, data is imprinted into the BTC network in plaintext.
The DSHN sequencer packs user transaction data, which is then saved through DONA distributed storage to avoid single points of failure and enhance reliability. To ensure data availability, Orange Chain writes Tapscript scripts to the Bitcoin network within each block, achieving continuous data availability.
In the Ethereum network, Rollup passes Layer 2 network data to the mainnet contract for verification and storage via calldata. However, the Bitcoin network does not support automatic verification of smart contracts. ZK-Rollup only writes zero-knowledge proofs and aggregated Rollup data to the Bitcoin network via Taproot, ensuring the anchoring of ZK-Rollup data in Bitcoin and preventing tampering.
However, this does not guarantee the validity and correctness of transactions within ZK-Rollup, nor does it utilize Bitcoin's powerful consensus to ensure the security of Layer 2 ZK-Rollup. Therefore, the approach adopted by Orange Chain is to write commitments of zero-knowledge proofs to the mainnet, allowing challengers to verify the commitments within a specified period. If a challenge succeeds, Rollup will roll back, and the challenger will receive assets locked by nodes. If no one challenges or the challenge fails within the challenge period, Rollup will receive final confirmation on the BTC network.
