# About Radius
Radius provides the foundational infrastructure necessary to build, deploy, and operate institutional-grade Layer 1 (L1) and Layer 2 (L2) networks. Our goal is to transform complex regulatory requirements into structural, verifiable features of the protocol.
Radius offers a suite of products designed to address the three core mandates of institutional needs: **Compliance, Resilience, and Scale**.
***
#### What Radius Delivers
We enable global enterprises, leading fintechs, and ambitious protocols to launch networks with a definitive competitive edge:
* Protocol-Level Compliance: Tools for guaranteeing compliance standards are met at the foundational layer.
* Operational Resilience: Infrastructure that guarantees stability, security, and fault-tolerant operations.
* Rapid Scalability: The capability to support long-term business growth.
By transforming compliance, security, and financials into built-in features, Radius provides the foundational infrastructure necessary for the next generation of global finance.
***
#### Explore our products
* [Secure Block Building](/overview/secure-block-building-sbb)
* [Lighthouse](/overview/lighthouse)
* ...and soon more
***
#### Further resources
* **Developers**: [GitHub](https://github.com/radiusxyz)
* **Conact Us:** [Contact Form](https://www.theradius.xyz/contact)
# The Vision
Ethereum was founded on the vision of providing a neutral, open infrastructure. As the ecosystem has scaled via rollups, however, new and opaque market structures have emerged. Value flows are split, transaction orderflow is obscured, and markets are siloed. This results in systemic inefficiency, misaligned incentives, and limited collaboration.
At the same time, the stakes are rising rapidly. Traditional finance and large-scale institutional capital are beginning to migrate onchain, demanding realiability, predictability, and transparency in operations. This migration necessitates compliant, auditable infrastructure to meet emerging global regulatory standards and mitigate systemic risk.
Radius is the solution built for this moment: We are building the critical infrastructure that restores transparent, open markets and enables trusted institutional adoption. Radius prepares Ethereum for the next era of global finance.
# Secure Block Building (SBB)
# Overview
**Secure Block Building (SBB)** is protocol designed to provide institutional readiness for L1 and L2 blockchain networks. It solves the primary challenge of building blockchains by eliminating intermediary risk, guaranteeing operational resilience, and supporting efficient, sufficient markets.
SBB is not an execution layer; it is a structural compliance layer guaranteeing neutral, non-intermediary transaction ordering, allowing institutional builders to focus on scaling financial markets without compromising compliance.
#### Key Benefits
SBB delivers uncompromising integrity across three critical dimensions for modern institutional infrastructure:
* **Regulatory Readiness**: Ensures the network meets the structural requirements for non-intermediary status by eliminating the source of intermediary risk (i.e., no single actor can unilaterally influence transaction order).
* **Operational Resilience**: Preserves system integrity under duress, guaranteeing continuous, fault-tolerant operations essential for high-value financial execution that can withstand attacks and system failures.
* Economic Efficiency: Facilitates robust economic growth by fostering efficient markets that support scalable, long-term revenue models (via anti-extractive mechanisms and arbitrage).
#### **Ready to evaluate SBB?**
SBB is the final layer of infrastructure required to ensure your network is built for institutional readiness.
To begin integrating SBB or to conduct a technical review:
* Explore the core components and full architecture in the [next section](/overview/secure-block-building-sbb/core-components).
* See the FCFS mechanism proven on our [demo](https://x.com/radius_xyz/status/1991045378628882836).
* [Contact our team](https://www.theradius.xyz/contact) to discuss regulatory fit, technical requirements, and deployment pathways.
# Architecture
Figure 1. Secure Block Building (SBB) Architecture
1. A user submits either an **encrypted** or **plaintext** transaction to the `Tx_Orderers` via **Secure-RPC**.
2. The **public key** generated by the DKG (operated by Radius) is shared with Secure-RPC.
3. The transaction is encrypted using this public key and delivered to one of the available `Tx_Orderers`.
> There are multiple Tx\_Orderers: one serves as the lead `Tx_Orderer`, while the others verify the leader’s results.
4. The lead `Tx_Orderer` aggregates transactions, appends them to its transaction list, and returns **order commitments**—a preconfirmation of each transaction’s position in the batch.
> Since **commitments are made before decryption**, the lead `Tx_Orderer` has no visibility into transaction contents or value, eliminating incentives for frontrunning or reordering.
5. Once the timelock puzzle is solved, the corresponding **private key** is delivered to the `Tx_Orderers`. The lead `Tx_Orderer` then decrypts the transactions and adds them to the mempool.
6. When the rollup initiaties block building based on a new fork choice, the lead `Tx_Orderer` sends decrypted user transaction list (Top of Block, or ToB) to the searcher.
7. The searcher constructs an MEV bundle (Bottom of Block, or BoB) using the ToB as reference, and sends it back to the Tx\_Orderer.
8. The lead `Tx_Orderer` stores the transactions inside the MEV Bundle into the mempool while preserving the order between ToB and BoB.
# Core Components
There are three components in SBB: Secure-RPC, Tx\_Orderer (Operators), and Distributed Key Generator (DKG).
**Secure-RPC**
The Secure-RPC is responsible for creating the initial state of transaction blindness necessary for the ordering mechanism.
* **Encryption**: Encrypts transactions using the public key from DKG before they are sent to any external system (e.g., a Tx\_Orderer)
* **Key Management**: Manages the communication and retrieval of encryption keys from DKG.
This ensures sensitive transaction data is protected both in transit and at rest, guaranteeing data integrity during the ordering phase.
* Secure-RPC is designed to be operated by the RPC provider.
* All necessary code will be provided by Radius to support integration.
* The component is fully dockerized.
***
### **Tx\_Orderer (Operators)**
Tx\_Orderer is a node within Radius AVS (Actively Validated Services), responsible for deterministic transaction ordering. The Tx\_Orderer is protocol-constrained to only order encrypted data, fundamentally removing the technical ability to front-run or exploit transactions.
* Multiple Tx\_Orderers operate as a cluster to guarantee system fault tolerance and availability. For each block, one Tx\_Orderer is selected from the cluster as the leader, while others serve as verifiers.
* Tx\_Orderers are run by independent operators and receive rewards directly from the rollup via restaking protocol integration (e.g., Symbiotic, EigenLayer), ensuring economic alignment. Rollups may choose to run the Tx\_Orderer directly.
* The component is fully dockerized.
A monitoring tool for operators
***
### **Distributed Key Generator (DKG)**
The Distributed Key Generator (DKG) is a critical protocol component responsible for provisioning cryptographic keys for a secure, time-locked encryption/decryption mechanism. This mechanism is formalized via Single Key Delay Encryption (SKDE).
Learn more about DKG in the [next section](/overview/secure-block-building-sbb/distributed-key-generator-dkg).
# Distributed Key Generator (DKG)
The Distributed Key Generator (DKG) is a critical protocol component responsible for provisioning cryptographic keys for a secure, time-locked encryption/decryption mechanism. This mechanism is formalized via Single Key Delay Encryption (SKDE).
{% hint style="info" %}
*Initially, the DKG is operated by Radius, with plans for transitioning to decentralized operator management to further enhance network robustness.*
{% endhint %}
#### **Core Functions**
DKG is designed to provide the foundational certainty necessary for high-value operations:
* **Byzantine Fault Tolerance (BFT)**: Implements BFT to safeguard the system. By decentralizing key management, DKG ensures that operator failure does not compromise the cryptographic security of the entire system.
* **Distributed Architecture**: Multiple specialized nodes decentralize the key management process, eliminating the single point of failure inherent in centralized key storage.
* **Time-Lock Encryption**: Keys for encryption are available immediately; decryption keys are released only after pre-determined time intervals.
* **SKDE Integration**: Seamlessly integrates with the SKDE framework to guarantee the integrity of time-locked cryptographic operations.
* **High Performance**: Achieves efficient key generation and consensus via asynchronous task processing.
#### **Architecture**
DKG operates through four specialized node types, each contributing to the security and integrity of the key lifecycle:
#### **Node Roles**
| **Role** | **Purpose** | **Key Responsibilities** |
| --------- | --------------------- | ----------------------------------------------------------------------------------------------- |
| Authority | Trusted Setup Manager | Constructs, manages, and securely distributes SKDE parameters. |
| Committee | Key Generation Leader | Generates encryption keys and coordinates consensus among nodes. |
| Solver | Decryption Provider | Computes the time-lock decryption keys. |
| Verifier | Network Monitoring | Detects, monitors, and reports any Byzantine (malicious or faulty) behavior within the network. |
#### **How DKG Works**
DKG utilizes a time-locked encryption model:
1. Setup Phase: The Authority node initializes the system by generating and distributing foundational SKDE parameters.
2. Key Generation: Committee nodes create the encryption keys corresponding to scheduled time intervals.
3. Immediate Access: Encryption Keys are immediately available for external services.
4. Time-Locked Release: Solver nodes compute and release the corresponding decryption keys after pre-determined delays.
5. Verification: Verifier nodes continuously monitor the network operations, ensuring all nodes adhere to the protocol and maintaining fault tolerance.
#### **Operational Lifecycle**
#### **Key States and Transitions**
# OP Stack Compatibility
OP Stack's standard execution client (`op-geth`) strictly order transactions by priority fee (gas price). However, SBB requires preconfirmation of inclusion order before the transaction contents are decrypted, meaning transactions must follow a first-come, first-served (FCFS) order based on the encrypted arrival time. This deterministic ordering logic is fundamentally incompatible with the OP Stack’s default `tx_list` block production mechanism.
**To maintain compliance and alignment with the Superchain, and avoid modifying core OP Stack logic, we integrate SBB using a specialized sidecar architecture (**Rollup Boost + a modified `rBuilder`).
***
#### SBB Integration: Rollup-Boost + rBuilder Sidecar
Our integration solution leverages Flashbots' Rollup-Boost technology alongside a custom rBuilder implementation.
* **Rollup-Boost**: This functions as a bridge between OP Stack's `op-node` and `op-geth`, preserving canonical interfaces.
* **rBuilder**: This is the external, modular block builder that incorporates SBB's logic. It is modified to incorporate SBB's cryptographic ordering constraints (FCFS pre-confirmation logic) when constructing the transaction payload.
This sidecar integration ensures we can fully support SBB while maintaining full alignment with Superchain governance and upgrade paths.
# Lighthouse
# Overview
Lighthouse is an auction layer designed to bring professional trading participants (e.g., arbitrageurs, searchers, solvers) into the ecosystem of institutional-grade blockchains.
Modern crypto markets are defined by high fragmentation, with liquidity scattered across numerous L1s, L2s, and CEXs. This environment creates profitable price discrepancies and arbitrage opportunities. However, capturing these opportunities safely and efficiently is inherently difficult across fractured venues.
Lighthouse replaces this fragmented environment with a single auction. venue. By acting as a central point of coordination, Lighthouse provides a transparent, competitive venue that translates directly into financial returns and enhanced market efficiency on institutional chains.
# Slot-Ordering
Lighthouse uses a **slot-based transaction ordering mechanism.**
A slot is a unit of transactions, comprising searcher bundles (from Lighthouse) and user transactions (from SBB). Slot ordering is run independently of fixed block times, managing the ordering of transactions within each slot.
Once slots are submitted to the mempool and included in a block, they are executed in a *predetermined order* defined by the slot. This model guarantees deterministic outcomes and eliminates risks of arbitrary reordering.
***
### **Slot Structure**
Each slot is divided into two segments to ensure value capture and user protection coexist:
1. **Top-of-Slot (Priority Txs):** Arbitrage bundles from searchers via Lighthouse auctions. These transactions backrun the previous slots (user transactions) to capture market opportunities.
2. **Bottom-of-Slot (User Txs):** User transactions from SBB, which are protected from exploitation (e.g., frontrunning or sandwich attacks).
Figure 1. Slot Structure – Each slot comprises Lighthouse (searcher bundles) and SBB (user transactions), operating independently of block times.
***
### **Why slots, not blocks?**
Slot ordering solves key execution and latency limitations of standard block-based ordering:
* **Network Congestion**: Fixed block intervals risk hitting gas or size limits during transaction surges, potentially preventing committed transaction orders from being included.
* **Communication Delays**: Mitigates issues caused by latency between the rollup and external systems (e.g., SBB or Lighthouse) that disrupt timely block production.
* **External Failures**: Prevents external system failures from cascading into the rollup's core transaction pipeline, ensuring predictable block production.
# Architecture
There are two primary interfaces:
* **User Interface (UI):** Manage deposits/withdrawals, track live auctions, and view system statistics.
* **API:** Provide data queries and integration endpoints for developers and advanced users.
***
Figure 4. Lighthouse Architecture
Lighthouse achieves robustness, stability, and performance by leveraging core components of Kubernetes (Ingress, Service, Deployment), a log monitoring system (ELK), and a message broker:
* **Event Processing:** The Lighthouse server asynchronously publishes all events to a message broker, ensuring that its core logic remains performant. A Kubernetes-based API server subscribes to these events, recording them in both database and the log monitoring system, respectively.
* **Quick Recovery:** Log and data enables rapid state restoration and operational continuity in the event of failure.
* **Role Separation:** The API server separates user-facing requests from core server logic, improving both robustness and scalability.
* **High Availability:** Lighthouse runs in a Kubernetes environment with autoscaling, periodic health checks, and zero-downtime deployments to maximize service reliability.
# Lighthouse Auctions
Lighthouse runs on a hybrid architecture that combines **off-chain execution** (a dedicated server runs real-time auctions and processes data) with **on-chain settlement** (smart contracts manage deposits/withdrawals and final auction settlement), balancing performance with security. \[Figure 2]
Figure 2. Interaction Overview – Shows how the rollup, Lighthouse, SBB, and searchers interact.
***
### **Lighthouse Auction Process**
1. **Deposit**: Searchers deposit tokens into the Lighthouse auction contract to collateralize bids, ensuring settlement integrity.
2. **Slot Transition & Real-time Auctions (Concurrent):**
* **2-1. Create Auction (Slot N+1):** The rollup requests an auction for the next slot; Lighthouse notifies all searchers participating in the rollup’s auction.
* **2-2. Deliver Bundles (Slot N)**: Confirmed winning bundles from the previous Lighthouse auction are submitted to the rollup.
* **2-3. Fetch Transactions (Slot N)**: The rollup retrieves the list of user transactions from SBB.
* **2-4. Broadcast Transactions:** The rollup merges Lighthouse bundles with SBB transactions and broadcasts the complete list to searchers participating in the auction, enabling backrunning opportunities for the next auction.
* **2-5. Include in Mempool (Slot N):** Transactions for Slot N are added to the mempool and executed in the defined order.
3. **Simulate Transactions (Private Node):** Searchers simulate MEV opportunities on private full nodes using the latest transaction order flow.
4. **Submit Bids:** Searchers submit MEV bundles and a `BidMsg`, which includes:
* `BidPrice`, `AuctionNonce`, `bidderAddress`, `mevTxHashes`, and `Signature`.
* Each signature is verified against the bidder’s private key to prevent unauthorized withdrawals.
5. **Auction Close & Settlement** **(Concurrent):**
* **5-1. Order Bundles**: After the auction closes, bundles are sorted by descending bid price.
* **5-2. Simulate Bundles:** Bundles are simulated in sequence; only valid bundles are confirmed and forwarded to the rollup for Slot N+1 (Step 2-2).
* **5-3. Submit Auction Closed Msg**: The Lighthouse contract executes settlement and closes the auction.
***
{% hint style="info" %}
### **Transaction Handling for SBB and Lighthouse**
* **Standalone SBB**: Manages both FCFS user transaction ordering and local searcher bundles, optimized for value capture within a single rollup.
* **SBB + Lighthouse**: SBB manages user transactions, while Lighthouse coordinates cross-market auctions, expanding arbitrage opportunities and supporting more advanced trading strategies across connected venues.
{% endhint %}
# Deposits & Withdrawals
The system uses off-chain balance tracking and on-chain contract settlement.
### Deposits
Figure 3. Deposit – steps to deposit funds within Lighthouse.
1. **Deposit Tokens**: Searchers deposit tokens into the Lighthouse contract to fund bidding fees.
2. **Send `Deposited` Event:** The server receives the deposits instantly and updates the searcher balances, avoiding redundant on-chain queries.
3. **Submit Bid:** Searchers submit MEV bundles with a `BidMsg`; the server verifies that each bid is fully backed by the searcher’s deposit.
4. **Send Auction Closed Message**: The server informs the chain of auction close, triggering settlement. The server deducts the winning bid and distributes it between Lighthouse and the rollup per a predefined ratio.
***
### Withdrawals
Figure 4. Withdrawal – steps to withdraw funds within Lighthouse.
1. **Reserve Withdrawal:** A searcher reserves a withdrawal first. This enforces a delay to prevent inconsistencies (e.g., using the same deposits simultaneously for a bid and a withdrawal).
2. **Send `WithdrawalReserved` Event:** Upon receiving the reservation event, the server marks the searcher as *ineligible to bid*. From this point, the searcher cannot submit bids.
3. **Withdraw:** After the withdrawal window opens, the searcher withdraws their funds from the contract.
4. **Send `Withdrew` Event:** The server detects withdrawal and updates the searcher’s deposit balance.
# Roadmap
### **(2025) SBB: Arbitrage Support for Rollups**
SBB enables searchers to submit MEV bundles directly to rollups, providing secure MEV capture for users.
* **Q1 2025:** SBB × Rollup Integration — User Protection
* **Q2 2025:** SBB x Rollup Integration — Rewards, Slashing, and MEV Revenue
### **(2025) Lighthouse: Cross-Rollup Expansion**
Lighthouse's decentralized network bridges multiple rollups with searchers, enabling safe MEV capture through competitive cross-rollup bidding.
* **Q2 2025:** Lighthouse 1.0 Testnet
* **Q4 2025:** Lighthouse 1.0 Mainnet
### **(2026) Lighthouse: L1-L2 Expansion**
Lighthouse extends MEV capture between Layer 1 and Layer 2, enabling cross-layer arbitrage and maximizing value throughout the Ethereum ecosystem.
* **Q2 2026:** Lighthouse 2.0 Testnet
* **Q4 2026:** Lighthouse 2.0 Mainnet
***
### Join Us
Advance the foundation of economic trust with us: [Contact Us](https://www.theradius.xyz/contact) | [Follow on X](https://x.com/radius_xyz).
# Secure Block Building (SBB)
The **Secure Block Builder (SBB)** by Radius is designed to **ensure liveness for rollups** while leveraging the **security of restaking protocols**. It consists of several key components that work together to maintain network integrity and secure transaction processing.
#### **Secure Block Builder (SBB) by Radius**
The **Secure Block Builder (SBB)** is Radius's solution for ensuring **liveness for rollups** while leveraging the **security of restaking protocols**. It consists of several key components that work together to provide efficient block production and secure transaction handling.
* **Seeder**
* The **Seeder** manages the **IP addresses of tx\_orderers and rollups**. It verifies nodes by referencing blockchain smart contract data and stores the **IP addresses** of verified nodes, ensuring seamless communication within the network.
* **Secure RPC**
* The **Secure RPC** is designed to **protect sensitive transaction data** within a blockchain or rollup environment. Its primary goal is to ensure that transactions are encrypted after leaving the client environment, preserving data integrity and security throughout the broadcasting process.
* **Distributed Key Generation Service (DKG)**
* The **DKG service** is a crucial component of Radius's **SKDE encryption method**. Each node generates a **partial key**, which is then combined to create an **aggregated encryption key**. A **delay function** is applied to generate the **decryption key**.
* **Users receive an encryption key** from DKG to encrypt transactions.
* **Tx\_orderers obtain a decryption key** to decrypt the encrypted transactions.
* **Liveness Service Manager Contract (`LivenessServiceManager.sol`)**
Relationship between LivenessServiceManager related entities
* The **LivenessServiceManager contract** ensures **tx\_orderer availability**. It helps rollups and tx\_orderer sets **determine the leader tx\_orderer**, allowing for **block creation and transaction ordering**. Within the above structure, a **cluster** consists of both a **tx\_orderer set** and a **rollup set.** The **tx\_orderer set** manages all registered rollups within the cluster. Each **rollup stores the addresses of executors**, responsible for its operation, and is registered with specific enabled features provided by Radius.
* **Additional Rollup Configurations:**
* **`rollupType`**: **rollupType:** Specifies the rollup framework responsible for executing transactions and updating the rollup's state. It processes transactions in the order provided by the **tx\_orderer**. Supported options include **`polygon_cdk`** and **op\_stack.**
* **`encryptedTransactionType`**: Specifies the encryption method used for transactions. Options include **PVDE** and **SKDE**, provided by Radius. If `none` is selected, transactions will not be encrypted.
* **`ValidationInfo`**: Contains **protocol details for re-staking**, specifying:
* **`platform`**: The blockchain where the validation contract is deployed.
* **`serviceProvider`**: The specific re-staking service used (**EigenLayer or Symbiotic**).
* **Validation Service Manager Contract (`ValidationServiceManager.sol`)**
* The **ValidationServiceManager contract** integrates with **restaking protocols** like **Symbiotic**. It facilitates **tx\_orderer validation and reward distribution** through the following process:
1. The **leader tx\_orderer** submits **block commitment information** by creating a task using `createTask`.
2. **Follower tx\_orderers** participate in validation by responding to the task with `respondToTask`.
3. Once validation is complete, the contract **allocates rewards or applies slashing** based on operator performance.
These components work together to provide a **decentralized, secure, and restaking-enabled rollup infrastructure**.
# Quick Start
Out of all the components of SBB, only two are likely to be run by most users:
1. **Tx\_Orderer** – This component is responsible for ordering transactions, providing order commitments for users, block commitments for block validation, and delivering blocks(raw transaction lists) to rollup operators.
2. **Secure RPC** – This component receives raw transactions from clients/wallets and formats them in a way that is acceptable to the tx\_orderers.
Radius provides a Secure RPC service, but since it involves trust, clients should have the option to run their own.
You can run both the tx\_orderer and Secure RPC by following the instructions on the next two pages. For more details, please refer to the relevant section.
# Run Tx\_Orderer
## **Prerequisites**
### **1. Installations**
1. Install
2. Run the following shell command to match the correct version:
```sh
foundryup -v nightly-5b7e4cb3c882b28f3c32ba580de27ce7381f415a
```
### 2. Contract calls
All smart contract function calls must be executed with success.
*Note:* We use two separate accounts for different purposes:
* The **operator account** (secured by `OPERATOR_PRIVATE_KEY`) is **only** used for registering the operator in Symbiotic.
* The **tx\_orderer account** (secured by `TX_ORDERER_PRIVATE_KEY`) is responsible for running our tx\_orderer.
This setup follows best practices recommended by other operators. They avoid using their operator private key for running programs to minimize security risks. To enhance security, our system ensures that the operator private key is strictly for registration, while the tx\_orderer private key manages tx\_orderer operations within the network.
Tx. Orderer (Operator) contract calls to Symbiotic and Radius contracts
Using Private Key (Holesky version)
{% code overflow="wrap" %}
```sh
#!/bin/bash
# ============================
# Symbiotic Operator Setup
# ============================
# This script handles registration and opt-in processes for the Symbiotic contract.
# It interacts with the Ethereum Holesky testnet.
# Validation Related
# ---------------------------
# 1. Configuration
# ---------------------------
RPC_URL="https://ethereum-holesky-rpc.publicnode.com" # Ethereum RPC URL
# Operator registration details
OPERATOR_REGISTRY_CONTRACT_ADDRESS="0x6F75a4ffF97326A00e52662d82EA4FdE86a2C548"
OPERATOR_PRIVATE_KEY="" # Your operator private key
# Vault opt-in service details
OPERATOR_VAULT_OPT_IN_SERVICE_CONTRACT_ADDRESS="0x95CC0a052ae33941877c9619835A233D21D57351"
VAULT_CONTRACT_ADDRESS="0x919c0EbA1b68803cd453fF218b0E59e174d8C2b0"
# Network opt-in service details
OPERATOR_NETWORK_OPT_IN_SERVICE_CONTRACT_ADDRESS="0x58973d16FFA900D11fC22e5e2B6840d9f7e13401"
NETWORK_ADDRESS="0x47482dA197719f2CE0BAeBB7F72D1d7C1D6cc8bD" # Ask network (rollup) team
# Operator details
OPERATOR_ADDRESS="" # Your operator address
# Tx_Orderer registration details
LIVENESS_CONTRACT_ADDRESS="0xBE32Ae8d955747FD4Ab0818C927c3926F373E05E" # Radius contract address
CLUSTER_ID="radius" # Cluster ID (Ask network/rollup team)
TX_ORDERER_PRIVATE_KEY="" # Your tx_orderer private key
TX_ORDERER_ADDRESS="" # Your tx_orderer address
# ============================
# 2. Register Operator
# ============================
echo "Registering operator..."
cast send "$OPERATOR_REGISTRY_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" --private-key "$OPERATOR_PRIVATE_KEY" \
"registerOperator()"
echo "Checking operator registration..."
cast call "$OPERATOR_REGISTRY_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" \
"isEntity(address who)(bool)" "$OPERATOR_ADDRESS"
echo "Expected output: true"
# ============================
# 3. Opt-in to Vault
# ============================
echo "Opting in to vault..."
cast send "$OPERATOR_VAULT_OPT_IN_SERVICE_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" --private-key "$OPERATOR_PRIVATE_KEY" \
"optIn(address vault)" "$VAULT_CONTRACT_ADDRESS"
echo "Checking vault opt-in status..."
cast call "$OPERATOR_VAULT_OPT_IN_SERVICE_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" \
"isOptedIn(address who, address where)(bool)" "$OPERATOR_ADDRESS" "$VAULT_CONTRACT_ADDRESS"
echo "Expected output: true"
# ============================
# 4. Opt-in to Network
# ============================
echo "Opting in to network..."
cast send "$OPERATOR_NETWORK_OPT_IN_SERVICE_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" --private-key "$OPERATOR_PRIVATE_KEY" \
"optIn(address network)" "$NETWORK_ADDRESS"
echo "Checking network opt-in status..."
cast call "$OPERATOR_NETWORK_OPT_IN_SERVICE_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" \
"isOptedIn(address who, address where)(bool)" "$OPERATOR_ADDRESS" "$NETWORK_ADDRESS"
echo "Expected output: true"
# Liveness Related
# ============================
# 5. Register Tx_Orderer
# ============================
echo "Registering tx_orderer..."
cast send "$LIVENESS_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" --private-key "$TX_ORDERER_PRIVATE_KEY" \
"registerTxOrderer(string clusterId)" "$CLUSTER_ID"
echo "Checking tx_orderer registration..."
cast call "$LIVENESS_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" \
"isTxOrdererRegistered(string clusterId, address txOrderer)(bool)" "$CLUSTER_ID" "$TX_ORDERER_ADDRESS"
echo "Expected output: true"
```
{% endcode %}
Using Ledger
```sh
#!/bin/bash
# ============================
# Symbiotic Operator Setup (Ledger)
# ============================
# This script registers an operator and opts into services using a Ledger device for signing.
# All transactions interact with the Ethereum Holesky testnet.
# ---------------------------
# 1. Configuration
# ---------------------------
RPC_URL="https://ethereum-holesky-rpc.publicnode.com" # Ethereum RPC URL
# Operator registration details
OPERATOR_REGISTRY_CONTRACT_ADDRESS="0x6F75a4ffF97326A00e52662d82EA4FdE86a2C548"
# Vault opt-in service details
OPERATOR_VAULT_OPT_IN_SERVICE_CONTRACT_ADDRESS="0x95CC0a052ae33941877c9619835A233D21D57351"
VAULT_CONTRACT_ADDRESS="0x919c0EbA1b68803cd453fF218b0E59e174d8C2b0"
# Network opt-in service details
OPERATOR_NETWORK_OPT_IN_SERVICE_CONTRACT_ADDRESS="0x58973d16FFA900D11fC22e5e2B6840d9f7e13401"
NETWORK_ADDRESS="0x47482dA197719f2CE0BAeBB7F72D1d7C1D6cc8bD" # Ask network (rollup) team
# Operator details
OPERATOR_ADDRESS="" # Your operator address
# Tx_orderer registration details
LIVENESS_CONTRACT_ADDRESS="0xBE32Ae8d955747FD4Ab0818C927c3926F373E05E" # Radius contract address
CLUSTER_ID="radius" # Cluster ID (Ask network/rollup team)
TX_ORDERER_ADDRESS="" # Your tx_orderer address
# Validation Related
# ============================
# 2. Register Operator
# ============================
echo "Registering operator..."
cast send "$OPERATOR_REGISTRY_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" --ledger \
"registerOperator()"
echo "Checking operator registration..."
cast call "$OPERATOR_REGISTRY_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" \
"isEntity(address who)(bool)" "$OPERATOR_ADDRESS"
echo "Expected output: true"
# ============================
# 3. Opt-in to Vault
# ============================
echo "Opting in to vault..."
cast send "$OPERATOR_VAULT_OPT_IN_SERVICE_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" --ledger \
"optIn(address vault)" "$VAULT_CONTRACT_ADDRESS"
echo "Checking vault opt-in status..."
cast call "$OPERATOR_VAULT_OPT_IN_SERVICE_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" \
"isOptedIn(address who, address where)(bool)" "$OPERATOR_ADDRESS" "$VAULT_CONTRACT_ADDRESS"
echo "Expected output: true"
# ============================
# 4. Opt-in to Network
# ============================
echo "Opting in to network..."
cast send "$OPERATOR_NETWORK_OPT_IN_SERVICE_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" --ledger \
"optIn(address network)" "$NETWORK_ADDRESS"
echo "Checking network opt-in status..."
cast call "$OPERATOR_NETWORK_OPT_IN_SERVICE_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" \
"isOptedIn(address who, address where)(bool)" "$OPERATOR_ADDRESS" "$NETWORK_ADDRESS"
echo "Expected output: true"
# Liveness Related
# ============================
# 5. Register Tx_Orderer
# ============================
echo "Registering tx_orderer..."
cast send "$LIVENESS_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" --ledger \
"registerTxOrderer(string clusterId)" "$CLUSTER_ID"
echo "Checking tx_orderer registration..."
cast call "$LIVENESS_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" \
"isTxOrdererRegistered(string clusterId, address txOrderer)(bool)" "$CLUSTER_ID" "$TX_ORDERER_ADDRESS"
echo "Expected output: true"
```
### **3. Running Tx\_Orderer**
Repository: [Tx\_Orderer GitHub](https://github.com/radiusxyz/tx_orderer)
***Note**:* A cluster is a group of tx\_orderers with a leader. This process can run with a single tx\_orderer as well. Do not be confused by the `.env` variables referencing clusters.
### Key Details
* **Language and Build Requirements:** The Tx\_Orderer is written in Rust and must be built using `cargo build --release` in the root directory.
* **Environment Variables:**
* Create an `env.sh` file at `tx_orderer/scripts/execute/env.sh` based on the contents of `env_example.sh`.
* Ensure the ports defined in `env.sh` are available.
* Another `env.sh` is needed at `tx_orderer/scripts/rpc-call/env.sh` for RPC-related scripts, also derived from `env_example.sh`.
* **Initialization Scripts:**
* Tx\_orderer is initialized and run using scripts located in the repository:
* `tx_orderer/scripts/execute/01_init_tx_orderer.sh`
* `tx_orderer/scripts/execute/02_run_tx_orderer.sh`
*Note*: the tx\_orderer is configured to support various types of liveness and validation. Additionally, a single tx\_orderer is not limited to operating for just one rollup but is designed to manage multiple rollups. If the components currently provided through APIs were converted into configurations, the tx\_orderer serving an existing rollup would need to be restarted each time a new rollup is added. To prevent this, these components are structured as APIs.
***
#### Hardware Specs
* CPU: 4
* Memory (GiB): 16
* Network (Gbps): 1
* Storage (GB): 256
#### Running the Tx\_Orderer
1. Clone the repository
```sh
git clone https://github.com/radiusxyz/tx_orderer
```
2. Build the binary
```sh
cd tx_orderer
cargo build --release
```
3. Set up environment variables in `./scripts/execute/env.sh`.
4. Initialize the Tx\_Orderer:
```bash
./scripts/execute/01_init_tx_orderer.sh
```
5. Start the Tx\_Orderer:
```bash
./scripts/execute/02_run_tx_orderer.sh
```
6. Set up environment variables in `tx_orderer/scripts/rpc-call/env.sh`.
7. **Initialize RPC for adding the sequencing info related to LivenessServiceManager contract:** This action serves for integrating liveness information from the LivenessServiceManager smart contract into the tx\_orderer. Upon completion, the tx\_orderer will be able to listen to events related to the LivenessServiceManager smart contract on the `LIVENESS_PLATFORM`, retrieve information about tx\_orderers and rollups, and invoke functions within the smart contract:
```bash
./scripts/rpc-call/11_add_sequencing_info.sh
```
8. **Add validation service details with RPC:** This action serves for integrating validation information from the ValidationServiceManager smart contract into the tx\_orderer. Upon completion, the tx\_orderer will be able to listen to events related to the ValidationServiceManager smart contract on the VALIDATION\_PLATFORM, retrieve information from the ValidationServiceManager contract, and invoke its functions.
```bash
./scripts/rpc-call/12_add_symbiotic_validation_info.sh
```
9. **Add cluster info:** This action serves for integrating cluster information, registered in the smart contract, into the tx\_orderer. Upon completion, the tx\_orderer will collect events whenever a block is generated in LIVENESS\_PLATFORM and automatically update itself with the relevant cluster information.
```bash
./scripts/rpc-call/13_add_cluster.sh
```
**Environment Variables**
tx_orderer/scripts/execute/env.sh
{% code overflow="wrap" %}
```bash
#!/bin/bash
SCRIPT_PATH="$( cd -- "$(dirname "$0")" >/dev/null 2>&1 ; pwd -P )"
PROJECT_ROOT_PATH="$( cd $SCRIPT_PATH/../.. >/dev/null 2>&1 ; pwd -P )"
BIN_FILE_NAME="tx_orderer"
BIN_PATH="$PROJECT_ROOT_PATH/scripts/$BIN_FILE_NAME"
DATA_PATH=$PROJECT_ROOT_PATH/data
CONFIG_FILE_PATH=$DATA_PATH/Config.toml
PRIVATE_KEY_PATH=$DATA_PATH/signing_key
# Copy the new version's binary to the scripts directory
if [[ -f "$PROJECT_ROOT_PATH/target/release/$BIN_FILE_NAME" ]]; then
cp $PROJECT_ROOT_PATH/target/release/$BIN_FILE_NAME $PROJECT_ROOT_PATH/scripts
fi
# Check if the binary exists
if [[ ! -f "$BIN_PATH" ]]; then
echo "Error: Tx_orderer binary not found at $BIN_PATH"
echo "Please run this command 'cp $PROJECT_ROOT_PATH/target/release/$BIN_FILE_NAME $PROJECT_ROOT_PATH/scripts"
exit 1
fi
# ONLY THE FOLLOWING VARIABLES SHOULD BE CHANGED
# ============================
# Tx_Orderer Configuration
# ============================
# ⚠️ NOTE: The following values are provided for contracts deployed on the Ethereum Holesky testnet.
# ⚠️ If you're deploying to a different network, update these values accordingly.
# ---------------------------------
# 🔑 Tx_Orderer Private Key
# ---------------------------------
# Used for signing various data, such as order commitments for users, block commitments for validation, etc.
TX_ORDERER_PRIVATE_KEY="0xe090d38fc4b19212e1b61fd32f02c9f928fedaa3338c13e0911fde837762d9ee" # ⚠️ Change this before deploying.
# ---------------------------------
# 🔄 Tx_Orderer RPC URLs
# ---------------------------------
# Used for storing node-related information.
TX_ORDERER_INTERNAL_RPC_URL="http://127.0.0.1:4000" # Internal IP - Update as needed.
# Used for communication within the cluster.
TX_ORDERER_CLUSTER_RPC_URL="http://127.0.0.1:5555" # External IP - Update as needed.
# Used for retrieving blocks and order commitments from the transaction orderer.
TX_ORDERER_EXTERNAL_RPC_URL="http://127.0.0.1:5556" # External IP - Update as needed.
# ---------------------------------
# 🔐 DKG (Distributed Key Generator)
# ---------------------------------
# Used for retrieving the decryption key from the DKG.
DISTRIBUTED_KEY_GENERATOR_RPC_URL="http://127.0.0.1:7100" # External DKG RPC URL - Update as needed.
# ---------------------------------
# 🌱 Seeder Configuration
# ---------------------------------
# Used for registering the transaction orderer's IP and providing the IPs of other transaction orderers in the cluster.
SEEDER_RPC_URL="http://127.0.0.1:6000" # External Seeder RPC URL - Update as needed.
```
{% endcode %}
tx_orderer/scripts/rpc-call/env.sh
#!/bin/bash
# ============================
# Tx_Orderer Configuration
# ============================
# ⚠️ NOTE: The following values are for the Ethereum Holesky testnet.
# ⚠️ If you're deploying to a different network, update them accordingly.
# ---------------------------------
# 🔄 Tx_Orderer RPC Configuration
# ---------------------------------
# The RPC endpoint for registering the transaction orderer for both the Liveness and Validation services.
TX_ORDERER_INTERNAL_RPC_URL="http://127.0.0.1:4000" # Internal IP - Update this with your correct IP.
# ============================
# 🔵 LivenessServiceManager Contract
# ============================
# ⚠️ DO NOT CHANGE THESE VALUES ⚠️
# The blockchain on which the LivenessServiceManager contract is deployed, currently Ethereum.
LIVENESS_PLATFORM="ethereum" # Options: [ethereum]
# The network that provides liveness service, currently Radius.
LIVENESS_SERVICE_PROVIDER="radius" # Options: [radius]
# Ethereum RPC & WebSocket URLs for the LivenessServiceManager contract.
LIVENESS_RPC_URL="https://ethereum-holesky-rpc.publicnode.com"
LIVENESS_WS_URL="wss://ethereum-holesky-rpc.publicnode.com"
# 📍 LivenessServiceManager contract address (provided by Radius).
LIVENESS_CONTRACT_ADDRESS="0xBE32Ae8d955747FD4Ab0818C927c3926F373E05E"
# 🏗️ Cluster ID (provided by the network/rollup team).
# A unique identifier for the cluster.
CLUSTER_ID="radius" # ⚠️ Update this if necessary.
# ============================
# 🟡 ValidationServiceManager Contract
# ============================
# ⚠️ DO NOT CHANGE THESE VALUES ⚠️
# The blockchain on which the ValidationServiceManager is deployed, currently Ethereum.
VALIDATION_PLATFORM="ethereum" # Options: [ethereum]
# The network providing validation services, either Symbiotic or EigenLayer.
VALIDATION_SERVICE_PROVIDER="symbiotic" # Options: [eigen_layer / symbiotic]
# Ethereum RPC & WebSocket URLs for the ValidationServiceManager contract.
VALIDATION_RPC_URL="https://ethereum-holesky-rpc.publicnode.com"
VALIDATION_WS_URL="wss://ethereum-holesky-rpc.publicnode.com"
# 📍 ValidationServiceManager contract (provided by the network/rollup team).
# The address of the deployed ValidationServiceManager, used for validating block commitments and other restaking-related matters.
VALIDATION_SERVICE_MANAGER_CONTRACT_ADDRESS="0x886404D7b959B01E351FC975Aa298e4c2b6F9d55"
# Run Secure RPC
### Key Details
* **Language and Build Requirements:** The Secure RPC is written in Rust and must be built using `cargo build --release` in the root directory.
* **Environment Variables:**
* Create an `env.sh` file at `secure-rpc/scripts/execute/env.sh` based on the contents of `env_example.sh`.
* Ensure the ports defined in `env.sh` are available.
* **Initialization Scripts:**
* Secure RPC is initialized and run using scripts located in the repository:
* `secure-rpc/scripts/execute/01_init_secure_rpc.sh`
* `secure-rpc/scripts/execute/02_run_secure_rpc.sh`
#### Steps
1. Clone the repository
```sh
git clone https://github.com/radiusxyz/secure-rpc/
```
2. Build the binary
```sh
cd secure-rpc
cargo build --release
```
3. Set up environment variables in `./scripts/execute/env.sh`.
4. Initialize the service:
```bash
./scripts/execute/01_init_secure_rpc.sh
```
5. Start the service:
```bash
./scripts/execute/02_run_secure_rpc.sh
```
**Environment Variables**
secure-rpc/scripts/execute/env.sh
{% code overflow="wrap" %}
```bash
#!/bin/bash
SCRIPT_PATH="$( cd -- "$(dirname "$0")" >/dev/null 2>&1 ; pwd -P )"
PROJECT_ROOT_PATH="$( cd $SCRIPT_PATH/../.. >/dev/null 2>&1 ; pwd -P )"
BIN_FILE_NAME="secure-rpc"
BIN_PATH="$PROJECT_ROOT_PATH/scripts/$BIN_FILE_NAME"
DATA_PATH=$PROJECT_ROOT_PATH/data
CONFIG_FILE_PATH=$DATA_PATH/Config.toml
# Copy the new version's binary to the scripts directory
if [[ -f "$PROJECT_ROOT_PATH/target/release/$BIN_FILE_NAME" ]]; then
cp $PROJECT_ROOT_PATH/target/release/$BIN_FILE_NAME $PROJECT_ROOT_PATH/scripts
fi
# Check if the binary exists
if [[ ! -f "$BIN_PATH" ]]; then
echo "Error: Secure RPC binary not found at $BIN_PATH"
echo "Please run this command 'cp $PROJECT_ROOT_PATH/target/release/$BIN_FILE_NAME $PROJECT_ROOT_PATH/scripts' after building the project"
exit 1
fi
# ONLY THE FOLLOWING VARIABLES SHOULD BE CHANGED
# ============================
# 🔒 Secure RPC Configuration
# ============================
# 🎯 Used to configure the RPC endpoint that can be identified and accessed
# by users and transaction orderers.
SECURE_RPC_EXTERNAL_RPC_URL="http://127.0.0.1:6666" # 🌐 External IP - Please update this.
# ============================
# 🔵 Rollup Configuration
# ============================
# 🏗️ Due to the ordering of transactions across multiple rollups,
# the Rollup ID is required to identify the target rollup executor.
ROLLUP_ID="nodeinfra_rollup" # ⚠️ Please update this Rollup ID.
# 💡 Since wallets support adding only a single network RPC URL, Secure-RPC must provide
# all the methods that would be accessible without it when directly communicating
# with the blockchain. Therefore, ROLLUP_RPC_URL is used to retrieve rollup information
# and forward it to the wallet or client.
ROLLUP_RPC_URL="http://131.153.159.15:8123" # 🌐 Please update this Rollup RPC URL.
# ============================
# 🔄 Tx_Orderer Configuration
# ============================
# 🎯 Used to identify the target IP of the transaction orderer (tx_orderer)
# responsible for receiving encrypted transactions and responding with order commitments.
TX_ORDERER_RPC_RPC_URL="http://127.0.0.1:7777" # 🌐 Please update this Tx_Orderer (external) RPC URL.
# ============================
# 🔐 Encrypted Transaction Type
# ============================
# 🔏 Specifies the cryptographic scheme used for encrypting the user's transactions.
# Options: skde / pvde
ENCRYPTED_TRANSACTION_TYPE="skde"
# ============================
# 🔑 DKG (Distributed Key Generator)
# ============================
# 🔓 Used for retrieving SKDE parameters, encryption keys, and decryption keys from the DKG.
DISTRIBUTED_KEY_GENERATOR_RPC_URL="http://127.0.0.1:7100" # 🌐 Please update this Distributed Key Generator (external) RPC URL.
```
{% endcode %}
# Contracts
The system involves two key contracts:
1. **LivenessServiceManager**
* Ensures the overall **liveness** of the **SBB**.
* Coordinates multiple entities, including:
* **Transaction Orderers**
* **Seeder**
* **Clusters**
* **Rollups** and their **Executors**
* Plays a **crucial role** in maintaining network activity and availability.
2. **ValidationServiceManager**
* Manages **operators, network participation, vaults, stakes, and rewards**.
* Every **rollup** that registers with the **LivenessServiceManager** must also **add their ValidationServiceManager contract**.
* This is required to **participate in the Symbiotic restaking protocol**.
These contracts work together to **maintain network liveness, coordination, and incentive mechanisms**.
# Liveness Service Manager
### Overview
The purpose of this contract is to facilitate the management of clusters, rollups, and tx\_orderers in a decentralized system. It provides the ability to organize clusters, where each cluster contains rollups, and the rollups are coordinated by tx\_orderers. The contract ensures security, modularity, and upgradability using industry-standard libraries.
This system is designed to be highly customizable, allowing owners to define and manage their clusters, control rollups, and ensure proper registration of participants such as tx\_orderers and executors.
***
### Key Concepts
1. **Clusters**\
A cluster represents a logical grouping managed by an owner. Within a cluster, there are limits on how many participants can be active at any time. The cluster owner is responsible for configuring the cluster and ensuring proper operation.
2. **Rollups**\
Rollups are components within clusters that process transactions. They carry specific properties, such as types, transaction encryption methods, and validation mechanisms. Rollups also support executors who perform specific operations within the rollup.
3. **Tx\_orderers**\
Tx\_orderers are responsible for ensuring liveness and ordering of operations within clusters. Each cluster has a fixed capacity for tx\_orderers, and new participants must register to fill available slots.
***
### Process Overview
#### Contract Setup
The contract is designed to prevent unauthorized modifications. It starts in an uninitialized state and must be explicitly initialized before it can be used. During this initialization, important configurations and security mechanisms are set up to ensure safe and secure operation.
#### Cluster Management
One can create a new cluster by defining its unique identifier and specifying how many tx\_orderers it can support. Once a cluster is created, it is ready to have rollups added and participants registered. Clusters are fully owned and controlled by their creators, ensuring that no unauthorized entity can make changes.
#### Adding Rollups
To expand the functionality of a cluster, rollups can be added by the cluster owner. Each rollup is uniquely identified and comes with specific configuration details. These include its type, the transaction methods it supports, and validation rules. Additionally, an executor—a participant responsible for executing the transactions—can be assigned during the setup process.
Currently, the `ValidationServiceManager` contract address is emitted during this process. This contract serves as a critical component for coordinating the network, its operators, and associated vaults. It is also responsible for defining stake limits, managing rewards, and enforcing slashing conditions to maintain network integrity.
The details of the `ValidationServiceManager.sol` contract, which is a part of the symbiotic-middleware-contract framework, will be explained in the next section. This explanation will provide further clarity on its role in ensuring efficient and secure operations within the network.
#### Registering Participants
Clusters require tx\_orderers to ensure operations run smoothly. When a new participant wants to join as a tx\_orderer, they must register with the cluster. This process checks for available slots and ensures that the participant has not already been registered. If successful, the tx\_orderer is assigned a position in the cluster.
#### Deregistering Participants
A tx\_orderer can be deregistered if needed. This process involves removing their association with the cluster or rollup and making their slot available for others.
#### Retrieving Information
The contract provides detailed visibility into its state. Owners and participants can query information about clusters, including the list of active tx\_orderers, details about rollups, and registered executors. Additionally, participants can discover all clusters they are associated with, and anyone can retrieve a complete list of all cluster identifiers in the system.
***
### How the System Ensures Integrity
1. **Ownership-Based Control**\
Only the owner of a cluster or rollup has permission to make changes, ensuring that unauthorized entities cannot interfere.
2. **Limits and Validation**\
The system enforces limits, such as the maximum number of tx\_orderers per cluster, and validates input to prevent duplicate or invalid registrations.
3. **Event Emission**\
Every significant action, such as adding a rollup or registering a tx\_orderer, triggers an event. These events create an immutable record that can be reviewed externally.
4. **Fault Tolerance**\
Deregistration processes are designed to handle cleanup gracefully, ensuring that the system remains consistent even when participants leave.
***
### Use Cases
1. **Managing a Decentralized Rollup Ecosystem**\
A developer or organization can use this system to manage a decentralized network of rollups, assigning specific roles to participants and maintaining overall control.
2. **Participant Registration**\
It provides a structured process for participants, such as tx\_orderers or executors, to join or leave clusters dynamically.
3. **Real-Time Queries**\
It lets accessing detailed, up-to-date information about clusters, rollups, and participants for decision-making or monitoring purposes.
***
# Validation Service Manager
### Overview
The `ValidationServiceManager` is a contract designed to coordinate and manage a decentralized network of operators, tokens, and vaults. It operates on an epoch-based system, enabling dynamic interactions while maintaining a high degree of security and accountability. This contract ensures proper registration, staking, and task execution in a modular and scalable manner.
At its core, the contract aims to create a seamless environment for managing decentralized validation services, providing mechanisms for operators, tokens, and vaults to participate in a structured network.
***
### Key Concepts
1. **Epochs**\
Time is divided into discrete intervals called epochs. Each epoch serves as a logical unit for calculating staking, task execution, and operator activity.
2. **Operators**\
Operators are key participants in the network, responsible for tasks such as validation. They must meet certain criteria, such as opting into the network and maintaining a minimum stake.
3. **Tokens**\
Tokens represent assets that can be staked by operators. They are registered with the network and require owner approval to be added or removed.
4. **Vaults**\
Vaults are associated with tokens and represent collateral-backed mechanisms in the system. They ensure that only valid assets are included in the staking and task-execution processes.
5. **Tasks**
Tasks are the operational units in the system. They are created, assigned, and executed by operators, ensuring the network functions smoothly. In the task creation process, the leader tx\_orderer takes the initiative by submitting a block commitment to the contract. \
This submission creates a new task. Once the task is created, follower tx\_orderers monitor the contract for the emitted event indicating the new task. Upon detecting the event, they calculate their own block commitment based on the data they have and respond to the task accordingly. \
The leader's role is critical in initiating the task, while the followers' responses validate and strengthen the integrity of the system. The `ValidationServiceManager` contract plays a key role in facilitating this interaction, emitting relevant events and ensuring that all task-related activities are tracked and verified within the network. This seamless interaction between the leader and follower tx\_orderers is a cornerstone of the contract’s operational design, ensuring the network operates efficiently and securely.
***
### Process Overview
#### System Initialization
The contract is initialized by defining the network, registry, and opt-in service parameters. Additionally, the epoch duration is set, dividing time into manageable intervals for operations.
#### Epoch Management
Epochs are used to organize and track network activity. The start time of the system is recorded, and the current epoch is determined based on the duration elapsed since initialization. Epoch-specific calculations, such as staking or operator activity, are performed relative to these intervals.
#### Operator Management
Operators are the backbone of the network, and their management involves several steps:
* **Registration**: An operator can join the network after opting in and providing an operational address. This registration is approved by the contract owner.
* **Pausing and Resuming**: Operators can be paused to temporarily disable their activity, ensuring the network remains secure.
* **Unregistration**: Operators can be removed if they are inactive for a specified grace period. This process also clears their operational data.
Operators are required to maintain a minimum stake in approved tokens to participate in tasks or other network activities.
#### Token Management
Tokens are added to the system by the contract owner and represent the assets that can be staked. The management process includes:
* **Registration**: New tokens can be registered and enabled for use.
* **Pausing and Unpausing**: Tokens can be temporarily disabled if necessary.
* **Unregistration**: Tokens can be removed if they are no longer active in the system.
Each token is subject to a minimum staking requirement, which is defined by the owner. Operators must meet this threshold to remain active.
#### Vault Management
Vaults are associated with collateral and are linked to the tokens in the network. They provide the infrastructure for staking. The vault management process involves:
* **Registration**: Vaults are added after verifying they are valid entities in the registry.
* **Pausing and Resuming**: Vaults can be disabled temporarily, similar to tokens.
* **Unregistration**: Vaults can be removed after ensuring they have completed their activity gracefully.
#### Staking Management
Staking ensures that operators remain accountable within the network. The system calculates and caches stake information for tokens and operators during each epoch. This includes:
* **Total Staked Amounts**: The total stake for each token is tracked and updated.
* **Operator Stakes**: Individual operator stakes are calculated and compared against the minimum staking threshold.
* **Caching and Validation**: Stake information is cached to optimize network performance and validated periodically to ensure accuracy.
#### Task Management
Tasks are critical for network operations, providing a mechanism for operators to contribute. The task process includes:
* **Creation**: Tasks are created with specific parameters, such as the block number and commitment hash. Only eligible operators can create tasks.
* **Responses**: Operators can respond to tasks, and their participation is recorded. Each operator can only respond once to a specific task.
* **Validation**: Responses are validated to ensure operators meet all requirements and are actively participating in the network.
#### Querying Information
The contract provides comprehensive tools for querying the state of the network. Users can retrieve:
* The list of active operators, tokens, or vaults for the current epoch.
* Detailed information about specific operators, including their stakes and operational status.
* Cached stake data for tokens and operators, optimized for quick access.
***
### Security and Integrity
1. **Ownership Control**\
All critical actions, such as registering operators, tokens, and vaults, require approval from the contract owner. This ensures that only authorized entities can modify the system.
2. **Opt-In Mechanism**\
Operators must explicitly opt into the network before registration, ensuring that they acknowledge and comply with the network's rules.
3. **Grace Periods**\
Both tokens and operators have a defined grace period before they can be removed.
4. **Stake Requirements**\
Minimum staking amounts are enforced to ensure operators have sufficient collateral to back their participation.
5. **Epoch-Based Activity**\
The use of epochs ensures that all operations are time-bound, reducing ambiguity and improving coordination across the network.
***
# Seeder
Repository: [Seeder GitHub](https://github.com/radiusxyz/seeder.git)
The **Seeder** plays a crucial role in coordinating **transaction orderers (tx\_orderers)** by providing the necessary information for network communication.
To become a tx\_orderer, a node must first **register itself in the LivenessServiceManager contract**. Once registered, it can join a cluster through the Seeder. The Seeder then **verifies the node’s wallet address** in the Liveness Contract before storing its **IP address**.
After successful registration, the **tx\_orderer receives the IP addresses of other peers in the cluster**, enabling seamless **internal communication** between nodes.
Seeder - Tx_Orderer interaction
Seeder - Rollup Operator Interaction
### **Seeder: Managing Tx\_Orderer RPC URLs**
The **Seeder** functions as a **key-value store**, mapping tx\_orderer addresses to their corresponding RPC URLs.
#### **Key Responsibilities**
* Stores **tx\_orderer addresses** as keys and their **RPC URLs** as values.
* Ensures that only **tx\_orderers registered in the LivenessServiceManager contract** can register on the Seeder.
***
### **Registration Process**
To register, a **tx\_orderer** must send a **signed message** containing:
* **Tx\_Orderer Address**
* **External RPC URL** (handles user transactions)
* **Cluster RPC URL** (for inter-cluster messages with signature verification)
* **Cluster ID** (received upon registering with the LivenessServiceManager contract)
#### **Validation Steps**
When a **registration request** is received, the Seeder:
1. **Verifies the message signature**.
2. **Confirms that the tx\_orderer is registered on the LivenessServiceManger contract**.
3. **Checks the accessibility of the external RPC URL** via the `/health` endpoint.
**Upon successful validation, the tx\_orderer's address and RPC URLs are stored in the Seeder**, making them available to **Secure RPC, Tx\_Orderers, and Rollups**.
***
### **Deregistration Process (TBD)**
A **tx\_orderer** can deregister by sending a **signed message** containing:
* **Tx\_Orderer Address**
* **Cluster ID**
#### **Validation Steps**
When a **deregistration request** is received, the Seeder:
1. **Verifies the message signature**.
2. **Checks if the tx\_orderer has been removed from the LivenessServiceManager contract**.
If confirmed, the **Seeder removes the tx\_orderer’s address**, making its **RPC URLs unavailable**.
# Tx\_Orderer Cluster
**Overview**
The cryptographic approach employed by the system ensures a trustless environment for the tx\_orderer operation. However, the architecture still faces the challenge of a Single Point of Failure (SPOF). To mitigate this risk, Radius adopts a distributed tx\_orderer network. This network comprises multiple tx\_orderers operating concurrently to ensure system reliability and continuity.
**Functionality**
In the event of a tx\_orderer failure, the distributed nature of the network allows the remaining tx\_orderers to continue operations without interruption. This redundancy enhances the robustness of the system against individual node failures.
**Communication and Decision making**
To ensure efficient communication and syncing among multiple nodes, Radius adopts a leader-based decision-making process. This strategy eliminates the need for consensus regarding the order and formation of blocks. It clearly outlines the roles and duties of the tx\_orderers in the network, distinguishing between the leader and the followers.
**Key Benefits**
* **Reliability:** The distributed tx\_orderer network significantly reduces the risk associated with a single point of failure, ensuring higher system uptime.
* **Efficiency:** By eliminating the need for consensus between network members, Radius ensures efficient decision-making among tx\_orderers, leading to a swift and reliable sequencing process.
* **Scalability:** The distributed architecture allows for scalability, accommodating an increasing number of tx\_orderers as the network grows.
**Conclusion**
The implementation of a distributed tx\_orderer network represents a strategic approach to enhancing the reliability, scalability, and decision making efficiency of tx\_orderer set. This ensures that the system remains robust against failures and maintains continuous operation.
# Liveness
A key advantage of distributed systems is their fault tolerance. In the current architecture, since the main actions depend on the leader, a robust recovery mechanism is essential. This mechanism should ensure the system's liveness by:
1. **Quick Transition to a New Leader:** Ensuring that a new leader can be quickly established if the current leader fails.
2. **Data Synchronization:** Keeping data synchronized across all nodes to maintain continuous operation even during a leader transition.
These measures ensure the system remains operational and efficient, even in the event of a leader failure.
# Leader Selection
## Leader selection
Dynamic leader selection is a crucial part of the current product to ensure the fair distribution of reward and ensure the liveness of the tx\_orderer set. Unlike the RAFT algorithm, which involves voting based leader election process, in the Eigenlayer Testnet we introduce the new algorithmic method of leader selection.
## Algorithm
**Arguments**
* **L1 Block Number**: Provides access to the instance of the tx\_orderer list stored on Ethereum for a given block number.
* **Rollup Block Number**: The number of the rollup's next block.
**Method**
1. Access the tx\_orderer list using the L1 block number.
2. Compute the index:
$$
\text{index} = (\text{rollup block number})\bmod(\text{number of elements in the tx\_orderer list})
$$
3. Determine the leader as the ***index***-th element of the cluster.
## Corner Cases
* The rollup will provide the necessary arguments to the leader responsible for building the current block. However, if the leader tx\_orderer is unresponsive, the rollup will send the same request to any of the followers. The leader for the next block will be determined in the usual manner. For the current block, the follower contacted by the rollup will assume the [role of the leader](https://docs.theradius.xyz/overview/secure-block-building-sbb-1/tx_orderer-cluster/liveness/pages/ESbJQd5rQb0Rr7PlfU7j#id-2.-improved-system-performance).
* Tx\_orderers must verify that the L1 block number provided by the rollup falls within a predefined block margin. This ensures that the rollup adheres to the fair leader change mechanism (round robin) and prevents the rollup from using an L1 block number that would result in the same index as the previous block.
## Benefits
* **Encourages Participation**: Ensures that every member of cluster has an equal opportunity to become a leader and earn rewards, motivating more participants to opt in.
* **Promotes Decentralization**: Enhances decentralized sequencing even with a leader-based system. Although a single entity orders transactions for each block, the frequent rotation of leaders reduces centralization.
* **Ensures Consistent Leader Selection**: Eliminates the need for voting or trust among nodes. Since the contract block number and rollup block number are shared with all nodes, the calculation of the next leader will consistently produce the same result for everyone.
# Syncing
### Normal Operation
* A well functioning leader tx\_orderer consistently shares its state with the followers in a concurrent manner, who then synchronize their states to match that of the leader. This synchronization process ensures consistency across the network.
### Failover Operation
When the leader becomes unresponsive or fails, the following process ensures continuity and proper synchronization within the system:
1. **Leader Recovery and Request**:
* Upon recovery, the leader makes a request to all other members of the cluster to check if any of them have received the "build block" request from the rollup.
2. **No Build Block Request Received**:
* If no other peer has received the "build block" request from the rollup, the leader resumes its leadership role.
3. **Build Block Request Received by Follower**:
* If another peer has received the build block request, the recovered members of the cluster will synchronize its block height with that of the new leader, as the leadership role has been transferred to it.
This process ensures that the leader can either continue its role seamlessly or synchronize appropriately with the follower to maintain the integrity and continuity of the system.
This mechanism ensures that the network remains robust and consistent, aligning the states of all nodes with the selected leader's state, whether it includes the latest transactions and commitments or necessitates a rollback to maintain network integrity.
# Block Validation
#### Block Commitment Verification Process
Since each follower is synchronized with leader's encrypted transactions and respective order commitments, this enables them to build the block similarly to the leader. The following steps outline the block commitment verification *process*:
Block Validation Flow
1. **Initiating the Build**:
* Upon receiving the build block request, the leader initiates the build function.
* The leader propagates the close message to all followers, prompting them to close their blocks and begin building.
2. **Submitting Block to Rollup Operator**:
* The rollup operator requests a block from the leader.
* The leader submits the block to the rollup operator.
3. **Generating Block Commitments**:
* The leader and followers generate a block commitment based on the encrypted transactions and order commitments.
* This process occurs in parallel across all members of the cluster.
4. **Submitting Block Commitment by Leader**:
* The leader creates a task and submits its block commitment to ValidationServiceManager contract, triggering an event that followers listen to.
5. **Submitting Block Commitment by Followers**:
* The followers submit their block commitments as a respond to the same task.
6. **Commitment Validation**:
* ValidationServiceManager contract aggregates commitments from all members of the cluster.
* It validates the commitments by comparing them with the leader's block commitment through a smart contract.
* Rewards are determined based on the validation results.
This process ensures that block commitments are accurately validated.
**Validation Scenarios**
* **Scenario 1: Majority Coincidence**
* If the majority of the followers' commitments coincide with the leader's commitment, the leader's commitment is considered valid.
* The leader is rewarded.
* **Scenario 2: Majority Discrepancy**
* If the majority of the followers' commitments do not coincide with the leader's commitment, the leader's commitment is considered invalid.
* The leader is not rewarded.
**Assumptions**
* There is no slashing of the tx\_orderer in this flow as of now, regardless of the result of the evaluation of block commitments.
* It is assumed that all members of the cluster, both followers and the leader, are motivated to earn fees and thus will not act maliciously.
This process ensures that the block commitments are verified in a decentralized manner, promoting fairness and accuracy in the blockchain network.
# Leader-based
The cluster members are divided into two categories: leaders and followers. Followers are responsible for routing data to and from the leader and users, as well as synchronizing the state. Meanwhile, the leader takes on more complex tasks such as sequencing transactions into blocks, providing order commitments, signing transactions, and interacting with rollups. This method offers several advantages.
#### 1. Simplified Decision Making
* **Simplicity:** With a single leader responsible for sequencing, the system simplifies the decision-making process. This centralized approach reduces the complexity and overhead associated with achieving consensus among multiple nodes.
* **Efficiency:** Leader-based systems can implement more efficient ordering and syncing related decisions since the leader node acts as the authoritative source for sequencing. This streamlines the process of agreeing on the state of the system, as there's no need for multiple nodes to negotiate each sequence.
#### 2. Improved System Performance
* **Reduced Latency:** By centralizing the sequencing tasks, leader-based systems can often reduce communication latency. Messages do not need to traverse multiple nodes to reach a consensus, as the leader directly sequences and processes requests. However, note that the leader manages all processing, meaning its performance directly influences the overall network's functionality.
* **Optimized Throughput:** The leader can optimize sequencing and resource allocation based on the current system load and priorities, potentially improving the overall throughput of the system.
To avoid confusion, the details regarding the leader-follower interaction were not included in the previous sections. This was done to simplify the concept, allowing readers to view the cluster as a singular entity. However, below is an overview of how leader-follower interactions are handled:
For every RPC request made to any of the followers, the request and its associated data are redirected to the leaders. This redirection mechanism is evident in the tx\_ orderer's RPC methods:
The leader distributes the data to the followers to maintain a synchronized and updated state across the entire cluster. Generally, synchronization in the sequencing process involves every piece of data being propagated among the follower nodes. Syncing encrypted transactions, time-lock puzzles, order commitments are carried out.
Leader's Responsibilities
The sequence diagram illustrates the actions that are managed by the leader, eliminating the need for consensus:
1. **Verification of zk-proof:** The leader verifies the zk-proof.
2. **Ordering of Encrypted Transactions:** The leader arranges the encrypted transactions for the upcoming block.
3. **Generating an Order Commitment:** The leader creates order commitments with PRE Merkle proofs for the encrypted transactions.
4. **Signing the Order Commitment:** The leader signs the order commitments.
5. **Forwarding the Order Commitments:** The leader forwards the order commitments, encrypted transactions and other relevant data to the followers
6. **Receiving RPC call for providing the block the rollup operator:** Upon receiving the call for providing the block to the rollup operator, leader broadcasts this message to all the peers and starts the process of block building.
7. **Transaction Decryption:** The leader decrypts the transactions using the key obtained from the DKG.
* SKDE allows decryption of all transactions using a single key obtained from solving a single time-lock puzzle.
8. **Interacting with Rollup Operator for Block Provision:** The leader responds to the rollup operator by providing the blocks.
9. **Creating task on ValidationServiceManager contract:** Upon completion and submission of the block, the leader generates the block commitment and submits it to the ValidationServiceManager contract as initialization of the block validation process.
Although currently in the development stage leader also generates POST Merkle proofs, which users can use together with the PRE Merkle Proof to verify the order and inclusion of their transactions.
# Secure RPC
Repository: [Secure RPC GitHub](https://github.com/radiusxyz/secure-rpc.git)
### Introduction
The **secure-rpc** framework enables **confidential transmission** of transaction data by:
* Encrypting transactions before sending them to any external system (e.g., a tx\_orderer).
* Managing encryption keys via a **Distributed Key Generation (DKG)** service.
This approach ensures sensitive transaction data is protected both **at rest** and **in transit**.
***
### System Overview
The **secure-rpc** framework is designed to safeguard sensitive transaction data in a blockchain or rollup environment. Its core objective is to ensure that whenever a transaction needs to be broadcast, it can be protected by powerful encryption mechanisms after leaving the client environment. This encryption can later be undone by the tx\_orderer. At the heart of the system lies a Distributed Key Generation (DKG) service, which manages the cryptographic keys needed to execute these operations.
Rather than manually tracking encryption keys or pre-sharing them among participants, the **secure-rpc** approach offloads most key-related responsibilities to this DKG service. The DKG is capable of serving the latest encryption keys for encrypting new transactions, while also storing and providing the corresponding decryption keys.
1. **Encryption Flows**
* **SKDE**\
A default encryption method that uses a distributed key approach. A “delay” aspect is introduced ensuring data is only decryptable after a certain time or condition.
* **PVDE**\
Leverages time-lock puzzles to enforce a minimum waiting period before decryption is possible.
2. **Decryption Flows**
* The system fetches the correct decryption key from the DKG service based on a `key_id`.
* Applies the corresponding decryption mechanism.
* Reconstructs the original transaction.
3. **RPC Endpoints**
* **Send Raw Transaction** (`send_raw_transaction`): Based on the configuration the tx can be encrypted or tx. encryption type can be changed.
4. **Distributed Key Generation Service**
* Provides encryption keys, decryption keys, and SKDE parameters.
* Manages key rotation or updates so that the client always uses the latest encryption key.
***
### Key Components & Flows
#### DKG Integration
* The secure-rpc client retrieves:
* **Encryption Key** for encrypting outgoing transactions.
* **Decryption Key** for decrypting incoming or stored transactions.
* **SKDE Parameters** needed for the SKDE algorithm.
#### Encryption Flow (SKDE Example)
1. **Raw Transaction** (e.g., Ethereum transaction) is provided.
2. **Transaction Splitting**:
* **Open Data**: Non-sensitive metadata or fields that must remain unencrypted.
* **Encrypted Data**: Sensitive fields that should remain confidential.
3. **Key Retrieval** from the DKG service (latest or specific `key_id`).
4. **Encryption** using SKDE routines (`skde::delay_encryption`) along with the **encryption\_key**.
5. **Result** is an `EncryptedTransaction` with a reference to the `key_id` used.
#### Time-Lock Puzzle (PVDE)
Though currently a minimal or “unsupported” flow in the provided code, the concept is:
1. Generate a puzzle parameter (`time_lock_puzzle_param`) which involves a carefully chosen modulus `n`, base `g`, and exponent `y`.
2. The encryption includes a puzzle, meaning that *even with the correct key*, it takes a certain number of sequential operations to unlock the data.
3. The puzzle is combined with zero-knowledge proofs (`sigma_protocol_public_input`) to prove that data was encrypted correctly without revealing it.
### Usage Scenario
Secure RPC data flow
1. **Client** needs to submit a transaction to a tx\_orderer, but data is sensitive.
2. **AppState / Config** indicates encryption is enabled with SKDE.
3. Client calls `send_raw_transaction`, which internally:
* Calls `encrypt_transaction` → obtains an `EncryptedTransaction`.
* Sends this encrypted data to the tx\_orderer via a chosen RPC endpoint from a configured URL list.
4. The tx\_orderer provides the secure-rpc with order-commitment.
5. The secure RPC forwards it to the user.
6. Later, the tx-orderer needs to retrieve the original transaction.
* Tx\_orderer fetches the decryption key from the DKG system and obtains the original transaction.
# Distributed Key Management System (DKG)
Repository: [Distributed Key Generation GitHub](https://github.com/radiusxyz/distributed_key_generation)
## Overview of DKG
## Distributed Key Generation (DKG) Overview
The Distributed Key Generation (DKG) service is a core component of Radius’s Single Key Delay Encryption (SKDE) method. It ensures secure encryption and decryption by distributing key generation across multiple nodes. Each node contributes a partial key, which is aggregated into an encryption key. A delay function is then applied to derive the decryption key later. This enables:
* Users and secure-RPC to encrypt transactions.
* The transaction orderer to obtain the decryption key for secure processing.
### SBB with SKDE
#### Background
SKDE powers encrypted mempool operations within SBB. Traditionally, each blockchain network requires independent SKDE systems, which introduces inefficiencies. Since networks have different block generation cycles, managing unique encryption schemes for each is impractical.
A unified DKG network addresses this by supporting all block intervals, optimizing key management across blockchain ecosystems. This Proof of Concept (PoC) lays out a scalable DKG protocol designed to enhance security, interoperability, and efficiency.
#### SKDE Workflow
1. **Partial Key Generation**
* Nodes generate partial keys and validity proofs using RSA-based parameters and time-lock puzzles to distribute trust.
2. **Partial Key Verification**
* Ensures the authenticity of generated partial keys.
3. **Partial Key Aggregation**
* A block proposer collects and combines partial keys using Multi-Party Computation (MPC).
4. **Transaction Encryption**
* Users encrypt transactions with the aggregated key to prevent pre-execution visibility, mitigating MEV and censorship risks.
5. **Puzzle Solving**
* A solver derives the decryption key by solving a time-lock puzzle, ensuring transactions remain encrypted until processing time.
6. **Transaction Decryption**
* Transactions are decrypted in an ordered manner for execution.
### Key Assumptions
* **Key Committee**: A designated committee ensures secure and efficient operation.
* **Minimal Delay Impact**: Time fluctuations should not disrupt protocol effectiveness.
* **Network Latency**: Assumed round-trip time (RTT) is 100–200ms.
* **Key Rotation**: New keys are generated every second, with overlapping cycles ensuring availability.
* **Participation Requirements**: Nodes must stake tokens to participate in the DKG network.
### Key Life Cycle & Usage
#### Life Cycle
A defined key committee generates partial keys and aggregates them into a master encryption key (AggKey). Until it is decrypted, transactions remain encrypted. The decryption key (DevKey) is used once the delay function is solved.
#### Key-Related Periods
* **Key Request Period**: Users request encryption keys before submission deadlines.
* **Transaction Submission**: Encrypted transactions must be submitted within the given timeframe.
* **Key Solve Period**: Decryption keys are computed with a 2-second delay.
* **Order Commit Period**: Transactions are committed to blocks in an ordered sequence.
### DKG Protocol with Fast Consensus
#### Overview
Committees precompute partial keys and proofs ahead of time, maintaining two key instances to optimize encryption order commitments. Initial blocks include valid key lists, followed by decryption key releases.
#### Protocol Workflow
1. **Setup**: Nodes exchange and validate partial keys, forming a consensus on a valid key list.
2. **Key Aggregation**: All nodes independently compute the aggregated encryption key.
3. **Transaction Encryption**: Users encrypt transactions with the aggregated key (AggKey).
4. **Order Commitment**: SBB nodes establish transaction order before decryption.
5. **Puzzle Solving**: Anyone can solve the time-lock puzzle to reveal the decryption key.
6. **Decryption & Execution**: The decrypted key is shared with SBB nodes to execute transactions.
7. **Key Cycle Reiteration**: New keys are continuously generated to maintain security and efficiency.
### Consensus Considerations
* **Without Consensus (Ethereum Dependency)**: Relies on Ethereum for validation.
* **With Consensus**: A decentralized approach where committee members reach agreement independently.
By leveraging a unified DKG system, this protocol enhances encryption efficiency, reduces redundant infrastructure, and ensures seamless blockchain interoperability.
# Client (User)
Clients have two ways to submit their transactions to the transaction orderer.
1. **Using secure-rpc**:\
Clients send their signed raw transactions to secure-rpc. The secure-rpc retrieves the necessary encryption key and other data from the DKG, encrypts the transaction, and forwards it to the tx\_orderer. When the tx\_orderer responds with an encrypted pre-confirmation, the secure-rpc then provides the decryption key. This ensures that transactions can only be decrypted after encrypted pre-confirmations are received.
2. **Using radius-snap**:\
Clients can generate or import their private key through the radius-snap. This allows the snap to sign raw transactions and encrypt them using an encryption key obtained from the DKG locally. Once signed and encrypted, the transaction is sent directly to the tx\_orderer.
### Client ↔ Secure RPC ↔ Tx\_Orderer
via Secure RPC
1. **Client** sends a raw transaction to Secure RPC.
2. **Secure RPC** fetches SKDE parameters and the encryption key from the Distributed Key Generation (DKG) Service.
3. **Secure RPC** encrypts the transaction.
4. **Secure RPC** sends the encrypted transaction to the tx\_orderer.
### Client ↔ Snap ↔ Tx\_Orderer
via Radius Snap
1. **Client** generates or imports a private key.
2. **Client** sends a raw transaction to the Snap.
3. **Snap** fetches SKDE parameters and the encryption key from the Distributed Key Generation (DKG) Service.
4. **Snap** encrypts the transaction using `.wasm`.
5. **Snap** sends the encrypted transaction to the tx\_orderer.
For details on **radius-snap**, refer to its [GitHub repository](https://github.com/radiusxyz/radius-snap).
# Backrunning
### Increasing Rollup Revenue with Radius’ Backrunning Feature
Radius provides a Backrunning feature to enhance rollup profitability. This feature ensures that user transactions maintain their order-commitment sequence while also sharing block information with MEV searchers.
#### How it works:
1. User transactions are ordered according to the order-commitment principle.
2. Block information is shared with the MEV searcher.
3. 3\. The MEV searcher analyzes the rollup state and transactions within the block to identify arbitrage opportunities.
4. The identified opportunities are then provided to the tx\_orderer (send MEV\_tx).
5. The tx\_orderer then creates a block based on the transaction it received from the user and the MEV\_tx it received from the mev searcher and propagates it to the rollup.
This process protects user transactions while enabling the rollup to generate additional revenue. To facilitate this, Radius’ tx\_orderer provides a dedicated API for communication with MEV searchers.
# Lighthouse
Key Requirements, Architecture, Specifications, and Security
### 1. Key Requirements
#### User Protection
Lighthouse balances revenue generation with user protection through a **Top-of-Block (ToB) / Bottom-of-Block (BoB)** framework that allocates blockspace strategically:
Top-of-Block (ToB):
* **Builder Revenue**: ToB provides builders with access to liquidity across rollups and Ethereum, unlocking strategic MEV opportunities to increase profits.
* **Rollup Revenue**: Builders compete in blockspace auctions, and this competition—enhanced by cross-rollup arbitrage—maximizes revenue for rollups.
* **Market Stability**: By enabling arbitrage between centralized and decentralized exchanges, Lighthouse helps minimize price disparities and stabilize the market.
Bottom-of-Block (BoB):
* **User Safety**: BoB secures blockspace for regular user transactions, protecting them from harmful MEV practices like frontrunning and sandwich attacks, while ensuring censorship resistance.
#### Revenue Maximization
Lighthouse uses advanced auction mechanisms to optimize builder revenue:
* **Just-in-Time Auction**: Builders can make real-time profitability assessments.
* **Cross-Rollup Bundle Auction**: Winning a ToB auction allows builders to coordinate transactions across multiple rollups for consistent MEV capture and seamless atomic execution.
#### Governance Integrity
Lighthouse is designed to integrate smoothly with existing rollup governance frameworks without causing disruptions:
* **Flexible Auction Scheduling**: Adapts to the unique block production times of rollups, enabling broad, simultaneous support.
* **Custom Auction Cycles**: Divides Lighthouse operations into intervals that match rollup-specific governance and block production processes.
By addressing these requirements, Lighthouse promotes a unified, revenue-enhancing system that protects users while fostering a dynamic, competitive blockspace ecosystem.
***
### 2. Lighthouse Network Architecture
Lighthouse runs trustless, permissionless auctions between rollups and builders, creating an open ecosystem for blockspace allocation. Builders can bid for the Top-of-Block (ToB) segment, capture MEV, and settle auction fees using L1 native tokens.
Each block in Lighthouse is divided into two distinct parts:
* **Top-of-Block (ToB)**
* Transactions in ToB are secured through Lighthouse auctions.
* Builders participate in permissionless auctions to secure ToB, optimizing MEV strategies such as backrunning arbitrage and CEX-DEX arbitrage.
* Builders analyze the previous state of rollups to make informed bids, maximizing their potential returns. Once ToB rights are secured, they can achieve atomic execution across rollups, enhancing profitability.
* **Bottom-of-Block (BoB)**
* Reserved exclusively for user transactions, ensuring secure and interference-free execution.
* Secure Block Building (SBB) protects user transactions against censorship and harmful MEV.
The [**Secure Block Building**](/#secure-block-building-sbb-user-protection) component within each rollup manages ToB and BoB, distinguishing builder transactions from regular user transactions. Once a block is formed, the rollup tx\_orderer executes the entire block.
This balanced architecture benefits both builders and users: builders gain access to lucrative opportunities while users receive strong protections. Through Lighthouse’s trustless and decentralized auction system, rollups enjoy a sustainable revenue model that promotes a thriving market.
#### Entities
1. **Seller (`Proposer`)**
* **Role**: The Proposer is an entity with the signing key responsible for submitting blocks.
* **Responsibilities:** Includes the winning builder's transactions in the Top-of-Block (ToB) for the assigned slot.
* **Block Creation**: The rollup tx\_orderer acts as the proposer, constructing the block by including the builder's bundle. The proposer ensures the block includes both ToB and BoB. Ultimately, the tx\_orderer is fully responsible for the final block content, managing the complete execution of transactions.
2. **Buyer (`Builder`)**:
* **Role**: The Builder constructs the content of the block.
* **Responsibilities:** Purchases the right to include transactions in ToB for a designated slot.
3. **Mediator (`Lighthouse`)**:
* **Role**: Acts as the intermediary facilitating the auction process
* **Responsibilities**: Ensures a secure and trustless contract between the seller (proposer) and buyer (builder).
#### Process Overview
1. **Seller Registration**:
* The **Rollup Tx\_Orderer** registers as a seller by locking collateral on Layer 1 (L1).
* **Bridge**: Lighthouse securely stores the Tx\_Orderer’s registration details.
2. **Blockspace Listing**:
* The **Rollup Tx\_Orderer** lists blockspace for sale by registering with Lighthouse.
* Lighthouse verifies the seller’s details and publicly shares the details of available slots.
3. **Buyer Registration**:
* **Builders** deposit auction fees into Lighthouse to participate.
* **Bridge**: Assets are locked on L1 and transferred to Lighthouse.
4. **Bid Submission**:
* **Builders** compete for ToB space by submitting their bids through Lighthouse.
* Lighthouse verifies all bids, selects the highest, and announces the winning Builder.
5. **ToB Submission**:
* The winning **Builder** constructs the ToB and submits it to Lighthouse.
6. **Block Creation**:
* The **Rollup Tx\_Orderer** includes the ToB while generating the block.
7. **Non-compliance Handling**:
If the Rollup Tx\_Orderer fails to include the ToB:
* **Bridge**: A **Slasher** forwards details (auction information, winning builder’s address, and ToB) from Lighthouse to L1
* L1 reviews the Tx\_Orderer’s actions and, if necessary, enforces a penalty by slashing the Tx\_Orderer’s collateral.
***
### 3. Technical Specifications
#### Design
Lighthouse operates based on a set of design dimensions that shape the interaction between Rollup Tx\_Orderers and Builders. Each dimension influences the auction mechanics, participant experience, and overall efficiency of the Lighthouse ecosystem. Below are the design dimensions we considered, along with the choices we made and the rationale for each decision.
1. **Bidder Access Control: Permissioned / Permissionless**
* **Choice:** **Permissionless**
* **Rationale:** We chose a permissionless system to ensure that any participant can access the auction without requiring prior approval or authorization. This open approach increases competition and fosters a more decentralized ecosystem, and encourages diverse participation in MEV opportunities.
2. **Winner Selection: Highest Bid (Auction) / Lottery**
* **Choice:** **Highest Bid (Auction)**
* **Rationale:** Selecting the highest bid as the winner promotes a competitive environment where Builders are incentivized to bid their true valuation of blockspace. This approach maximizes revenue for Rollup Tx\_Orderers and aligns with our goal of creating an efficient and economically sustainable marketplace.
3. **Bid Time: After Previous State Disclosure / Before Previous State Disclosure**
* **Choice:** **After Previous State Disclosure**
* **Rationale:** Allowing bids to be placed after the previous state is disclosed provides Builders with the information they need to make informed bidding decisions. This transparency reduces uncertainty and allows Builders to optimize their MEV strategies based on the most recent data, ultimately improving the quality of bids.
4. **Bidder’s Fee Payment Method: Instant Payment with Winner Update and Refund / Prepayment with Refund / Postpayment**
* **Choice:** **Instant Payment with Winner Update and Refund**
* **Rationale:** Requiring instant payment at the time of bidding ensures the auction is efficiently settled, minimizing potential delays and reducing the risk of non-payment. This mechanism provides a clear and immediate commitment from Builders while allowing refunds for unsuccessful bids, streamlining the auction process.
5. **Winning Bidders per Slot: 1 (Bid for Entire ToB) / Multiple (Bid for Partial Space)**
* **Choice:** **1 (Bid for Entire ToB)**
* **Rationale:** By allowing a single winning bidder for the entire ToB, we simplify the auction structure and provide Builders with full control over the top blockspace. This approach optimizes MEV capture for Builders by allowing them to fully utilize the ToB, making it a more attractive and valuable position to bid for.
6. **Seller’s Previous State Disclosure Method: Data Availability (DA) / Tx\_Orderer Self-Disclosure with Builder Tool / Lighthouse (Broadcast Relay)**
* **Choice:** **Tx\_Orderer Self-Disclosure with Builder Tool**
* **Rationale:** Having the Tx\_Orderer directly disclose the previous state and provide a Builder tool enables efficient and direct access to state information. This setup reduces dependency on external relays and ensures that Builders have the tools necessary to interpret state data accurately, making it easier to participate in the auction effectively.
7. **Transaction Guarantee: Inclusion / Execution**
* **Choice:** **Execution**
* **Rationale:** We chose to guarantee both the inclusion and execution of transactions in the specified order. This level of assurance gives Builders confidence that their transactions will not only be included but also executed as intended, which is crucial for complex MEV strategies that rely on specific transaction sequencing.
By selecting these options, we have designed Lighthouse to support an open, efficient, and reliable blockspace marketplace. Each choice is intended to align with our goals of decentralization, transparency, and maximizing economic incentives, creating a robust platform for both Rollup Tx\_Orderers and Builders to interact in a trustless and decentralized manner.
The diagram illustrates the sequence of actions and interactions between the **Tx\_Orderer**, **Lighthouse**, **Builder**, and **L1** contracts within the Lighthouse. The process is as follows:
1. **Auction Initiation**: The Tx\_Orderer begins by calling `startAuction()` on Lighthouse, initiating the auction process for blockspace.
2. **Auction Notification**: Lighthouse broadcasts the auction event, allowing Builders to listen for and participate in the auction.
3. **Bid Submission**: Builders submit bids via Lighthouse’s `bid()` function. Lighthouse records the bids and identifies the highest bidder.
4. **Winning Bid Record**: The highest bid is recorded in Lighthouse, and the winning Builder is notified.
5. **ToB Submission**: The winning Builder submits their transactions for the **Top of Block (ToB)** section to Lighthouse.
6. **Block Building**: Lighthouse notifies the Tx\_Orderer to include the ToB transactions, and the Tx\_Orderer constructs the block, incorporating the Builder's ToB.
7. **Slash Mechanism**: If the Tx\_Orderer fails to fulfill its obligations, the Builder can call `slashTxOrderer()` on L1, triggering a penalty (slashing) of the Tx\_Orderer’s collateral.
This diagram captures the core interactions and enforcements in Lighthouse, ensuring an efficient, secure, and transparent auction process for blockspace.
#### Contract overview
1. L1 Contracts
1. `Asset Bridge Contract` : facilitates asset transfers between L1 and Lighthouse by locking and unlocking assets.
1. `send`: Lock assets on L1 and transfers wrapped tokens to Lighthouse.
2. `receive`: Unlocks wrapped tokens on Lighthouse and sends the equivalent assets back to L1 users.
2. `Tx_Orderer Registry and Slashing Contract` : manages the registration, deregistration, and slashing of Tx\_Orderers to ensure accountability.
1. `registerTxOrderer`: Registers a Tx\_Orderer by locking collateral.
2. `deregisterTxOrderer`: Allows Tx\_Orderers to unregister, releasing locked collateral.
3. `slashTxOrderer`: Slashes the collateral of a Tx\_Orderer if obligations are not met, enforcing penalties for non-compliance.
2. Lighthouse Contracts
1. `Asset Bridge Contract` : mirrors the L1 Asset Bridge functionality, managing the minting and burning of wrapped tokens on Lighthouse.
1. `receive`: Mints wrapped tokens on Lighthouse after assets are locked on L1.
2. `send`: Burns wrapped tokens on Lighthouse to release equivalent assets back to L1.
2. `Payment Token Contract` : manages payment tokens used in Lighthouse for auction transactions.
1. `transfer`: Transfers payment tokens (e.g., wrapped ETH) within Lighthouse.
2. `approve`: Grants permission to other contracts to use the tokens on behalf of the owner.
3. `Blockspace Auction Management Contract` : manages the auctioning of blockspace, handling the bidding process and transaction submission.
1. `registerTxOrderer`: Verifies and registers Tx\_Orderers eligible to participate in auctions.
2. `deregisterTxOrderer`: Deregisters Tx\_Orderers, removing them from eligible participants.
3. `startAuction`: Initializes an auction, defining parameters like auction ID, block height, duration, and bundle size.
4. `bid`: Allows Builders to place bids, transferring payment tokens and updating the highest bid.
5. `submitToB`: Records the transactions for the winning Builder’s ToB space.
#### The timing and sequence of actions
Here’s a breakdown of each step in terms of timing:
1. **Auction Start Timing**:
* Tx\_Orderer initiates the auction for the **Top of Block (ToB)** space in an upcoming rollup block (#3 in this example).
* This auction begins after the completion of block #2, allowing Builders to prepare their bids in advance of block #3.
2. **Auction Process in Lighthouse (Bid Submission and Selection)**:
* During this phase, Builders actively participate in the auction by submitting their bids for the ToB space in block #3.
* The bid submission and selection happen concurrently, with Lighthouse evaluating bids in real-time to determine the highest bid, which will secure the ToB space.
3. **ToB Submission Timing**:
* Once the auction concludes and a winning bid is selected, the chosen Builder submits their ToB transactions to Lighthouse.
* This submission occurs before block #3 is finalized, ensuring that the winning transactions are available for inclusion in the top portion of the block.
4. **Block Building and Finalization**:
* With the ToB transactions from the winning Builder, the Rollup Tx\_Orderer constructs block #3, positioning the Builder’s transactions at the top as specified.
* This process completes the integration of the auctioned ToB, aligning with the timing and sequence requirements for Lighthouse.
***
### 4. Security
#### Threat models
In the Lighthouse, various entities participate in the auction and blockspace allocation process, each with potential vulnerabilities and risks. To maintain a secure and trustless environment, it is crucial to address the threat models associated with each entity involved: the Tx\_Orderer, Builder, and Mediator.
| Entity | Threat models |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Tx\_Orderer (Seller) |
- Fails to include the transactions as agreed upon in the designated slot, violating the terms of the auction. - Lacks legitimate authority over the slot it intends to sell, potentially resulting in invalid transaction processing.
|
| Builder (Buyer) | - Does not fulfill the required bit payment, compromising the fairness and economic balance of the auction. |
| Mediator (Lighthouse) |
- Publishes invalid or incorrect information, leading to misinformation and potential exploitation by participants. - Fails to execute the auction according to the established rules, undermining the trust in the auction process. - Sells overlapping slots to different buyers, creating conflicts and issues in transaction inclusion and execution. - Does not refund bids to participants who did not win the auction, leading to financial losses for non-winning Builders.
|
#### Mitigation Strategies
For each entity involved in the Lighthouse, specific reliability methods are implemented to mitigate the potential risks outlined in the threat models. These strategies are designed to ensure compliance, protect users, and maintain trust within the Lighthouse ecosystem.
1. Tx\_Orderer (Seller) Reliability Measures
* To ensure that the Tx\_Orderer fulfills its commitment to include the designated transactions in the assigned block, Lighthouse has implemented a collateral-based enforcement mechanism on L1. When a Tx\_Orderer is registered, it locks collateral on L1, which can only be withdrawn after a set block delay, preventing premature withdrawal.
If the Tx\_Orderer fails to meet its obligations, a slashing mechanism is triggered. This mechanism verifies the Tx\_Orderer’s actions by comparing the finalized block information on L1 with the contract information on Lighthouse. If the Tx\_Orderer has violated its contract terms by omitting required transactions, its locked collateral is slashed. This approach ensures accountability and provides a strong financial disincentive against non-compliance, upholding the integrity of the Lighthouse.
2. Builder (Buyer) Reliability Measures
* To prevent unpaid bids, Lighthouse enforces real-time settlement of bid payments. Builders are required to fulfill the bid payment immediately upon placing a bid, ensuring that only financially committed bids are processed. This instant settlement mechanism eliminates the possibility of delayed or unpaid bids, maintaining the fairness of the auction and protecting against time-delay attacks.
Additionally, any deviation in the Builder’s blockspace configuration or failure to submit transactions within the designated slot impacts only the Builder, as Lighthouse’s design isolates these risks, minimizing disruptions to the broader ecosystem.
3. Mediator (Lighthouse) Reliability Measures
* Lighthouse is built with L1-grade security to prevent vulnerabilities and ensure a reliable auction process. Immutable smart contracts enforce established auction rules, delivering fair and transparent execution that sustains participant trust. Each slot is uniquely allocated to prevent overlapping sales, while an automated refund mechanism immediately returns bids to non-winning participants, safeguarding against financial losses and promoting a fair, trustworthy experience.
# Internal Secure Block Building (SBB)
The **Secure Block Builder (SBB)** by Radius is designed to **ensure liveness for rollups** while leveraging the **security of restaking protocols**. It consists of several key components that work together to maintain network integrity and secure transaction processing.
#### **Secure Block Builder (SBB) by Radius**
The **Secure Block Builder (SBB)** is Radius's solution for ensuring **liveness for rollups** while leveraging the **security of restaking protocols**. It consists of several key components that work together to provide efficient block production and secure transaction handling.
* **Seeder**
* The **Seeder** manages the **IP addresses of tx. orderers and rollups**. It verifies nodes by referencing blockchain smart contract data and stores the **IP addresses** of verified nodes, ensuring seamless communication within the network.
* **Secure RPC**
* The **Secure RPC framework** is designed to **protect sensitive transaction data** within a blockchain or rollup environment. Its primary goal is to ensure that transactions are encrypted after leaving the client environment, preserving data integrity and security throughout the broadcasting process.
* **Distributed Key Generation Service (DKG)**
* The **DKG service** is a crucial component of Radius's **SKDE encryption method**. Each node generates a **partial key**, which is then combined to create an **aggregated encryption key**. A **delay function** is applied to generate the **decryption key**.
* **Users receive an encryption key** from DKG to encrypt transactions.
* **Tx. orderers obtain a decryption key** to process and execute transactions securely.
* **Liveness Service Manager Contract (`LivenessServiceManager.sol`)**
Relationship between LivenessServiceManager related entities
* The **LivenessServiceManager contract** ensures **tx. orderer availability**. It helps rollups and tx. orderer sets **determine the leader tx. orderer**, allowing for **block creation and transaction ordering**. Within the above structure, a **cluster** consists of both a **tx. orderer set** and a **rollup set.** The **tx. orderer set** manages all registered rollups within the cluster. Each **rollup stores the addresses of executors**, responsible for its operation, and is registered with specific enabled features provided by Radius.
* **Additional Rollup Configurations:**
* **`rollupType`**: Determines the **block creation mechanism**, based on the transaction list provided by the tx. orderer. Supported options include **`polygon_cdk`**.
* **`encryptedTransactionType`**: Defines the encryption method used, with **PVDE and SKDE** offered by Radius.
* **`ValidationInfo`**: Contains **protocol details for re-staking**, specifying:
* **`platform`**: The blockchain where the validation contract is deployed.
* **`serviceProvider`**: The specific re-staking service used (**EigenLayer or Symbiotic**).
* **Validation Service Manager Contract (`ValidationServiceManager.sol`)**
* The **ValidationServiceManager contract** integrates with **restaking protocols** like **Symbiotic**. It facilitates **tx. orderer validation and reward distribution** through the following process:
1. The **leader tx. orderer** submits **block commitment information** by creating a task using `createTask`.
2. **Follower tx. orderers** participate in validation by responding to the task with `respondToTask`.
3. Once validation is complete, the contract **allocates rewards or applies slashing** based on operator performance.
These components work together to provide a **decentralized, secure, and restaking-enabled rollup infrastructure**.
# Quick Start
### Overview
This document provides guidance on setting up and running four main components:
1. **Seeder**
Repository: [Seeder GitHub](https://github.com/radiusxyz/seeder.git)
2. **Key Management System**
Repository: [Distributed Key Generation GitHub](https://github.com/radiusxyz/distributed_key_generation)
3. **Secure RPC**
Repository: [Secure RPC GitHub](https://github.com/radiusxyz/secure-rpc.git)
4. **Sequencer**
Repository: [Sequencer GitHub](https://github.com/radiusxyz/sequencer.git)
***Note**:* A cluster is a group of sequencers with a leader. This process can run with a single sequencer as well. Do not be confused by the `.env` variables referencing clusters.
### Key Details
* **Language and Build Requirements:** All components are written in Rust and must be built using `cargo build --release` in the root directory of each repository.
* **Environment Variables:**
* Create an `env.sh` file at `/scripts/execute/env.sh` based on the contents of `env_example.sh`.
* Ensure the ports defined in `env.sh` are available.
* Shared variables across components must have consistent values.
* Another `env.sh` is needed at `/scripts/rpc-call/env.sh` for RPC-related scripts, also derived from `env_example.sh`.
* **Initialization Scripts:**
* Each component is initialized and run using scripts located in the repository:
* `/scripts/execute/01_init_....sh`
* `/scripts/execute/02_run_....sh`
* **Inter-Component Integration:**
* Some components require registration with others via JSON RPC calls to internal RPC URLs. The necessary scripts are found in `/scripts/rpc-call`, except for the Secure RPC component, which does not require this step.
***
# Run Seeder
Repository: [Seeder GitHub](https://github.com/radiusxyz/seeder.git)
1. Clone the repository:
git clone https://github.com/radiusxyz/seeder
2. Build the binary
```sh
cd seeder
cargo build --release
```
3. Set up environment variables in `./scripts/execute/env.sh`.
4. Initialize the Seeder:
```bash
./scripts/execute/01_init_seeder.sh
```
5. Start the Seeder:
```bash
./scripts/execute/02_run_seeder.sh
```
6. Set up environment variables in `./scripts/rpc-call/env.sh`.
7. Initialize RPC: This action serves for is **r**egistering sequencing information related to the LivenessServiceManager
./scripts/rpc-call/10_initialize.sh
**Environment Variables**
seeder/scripts/execute/env.sh
```sh
#!/bin/bash
CURRENT_PATH="$( cd -- "$(dirname "$0")" >/dev/null 2>&1 ; pwd -P )"
PROJECT_ROOT_PATH="$( cd $SCRIPT_PATH/../.. >/dev/null 2>&1 ; pwd -P )"
BIN_FILE_NAME="seeder"
BIN_PATH="$PROJECT_ROOT_PATH/scripts/$BIN_FILE_NAME"
DATA_PATH=$PROJECT_ROOT_PATH/data
CONFIG_FILE_PATH=$DATA_PATH/Config.toml
# Copy the new version's binary to the scripts directory
if [[ -f "$PROJECT_ROOT_PATH/target/release/$BIN_FILE_NAME" ]]; then
cp $PROJECT_ROOT_PATH/target/release/$BIN_FILE_NAME $PROJECT_ROOT_PATH/scripts
fi
# Check if the binary exists
if [[ ! -f "$BIN_PATH" ]]; then
echo "Error: Secure RPC binary not found at $BIN_PATH"
echo "Please run this command 'cp $PROJECT_ROOT_PATH/target/release/$BIN_FILE_NAME $PROJECT_ROOT_PATH/scripts' after building the project"
exit 1
fi
# ONLY THE FOLLOWING VARIABLES SHOULD BE CHANGED
# Used by transaction orderers to register their IP addresses
# and retrieve the IP addresses of peers when they register
# in the LivenessServiceManager contract.
SEEDER_EXTERNAL_RPC_URL="http://127.0.0.1:6000"
# Used by the network owner to add sequencing information,
# including the RPC and WebSocket URLs for interacting with
# the LivenessServiceManager contract, the contract address itself, and
# the platform with the service provider.
SEEDER_INTERNAL_RPC_URL="http://127.0.0.1:6001"
```
seeder/scripts/rpc-call/env.sh
{% code overflow="wrap" %}
```sh
#!/bin/bash
# Used by the network owner to add sequencing information,
# including the RPC and WebSocket URLs for interacting with
# the liveness contract, the contract address itself, and
# the platform with the service provider.
SEEDER_INTERNAL_RPC_URL="http://127.0.0.1:6001" # Internal IP - Please change this IP.
# Used as parameters for registering liveness-related data
# through the internal RPC URL.
LIVENESS_PLATFORM="ethereum" # Option: [ethereum]
LIVENESS_SERVICE_PROVIDER="radius" # Option: [radius]
LIVENESS_RPC_URL="http://127.0.0.1:8545" # Please change this IP.
LIVENESS_WS_URL="ws://127.0.0.1:8545" # Please change this IP.
LIVENESS_CONTRACT_ADDRESS="0x0000000000000000000000000000000000000000" # Please change this liveness contract address.
```
{% endcode %}
# Run DKG
Repository: [Distributed Key Generation GitHub](https://github.com/radiusxyz/distributed_key_generation)
1. Clone the repository
```sh
git clone https://github.com/radiusxyz/distributed_key_generation
```
2. Build the binary
```jsx
cd distributed_key_generation
cargo build --release
```
3. Set up environment variables in `./scripts/execute/env.sh`.
4. Initialize the system:
```bash
./scripts/execute/01_init_key_generator.sh
```
5. Start the system:
```bash
./scripts/execute/02_run_key_generator.sh
```
6. Set up environment variables in `./scripts/rpc-call/env.sh`.
7. Initialize RPC: This action serves for registering a key generator by submitting its address and RPC endpoints to an internal system.
```bash
./scripts/rpc-call/10_initialize.sh
```
**Environment Variables**
distributed_key_generation/scripts/execute/env.sh
```sh
#!/bin/bash
#!/bin/bash
CURRENT_PATH="$( cd -- "$(dirname "$0")" >/dev/null 2>&1 ; pwd -P )"
PROJECT_ROOT_PATH="$( cd $SCRIPT_PATH/../.. >/dev/null 2>&1 ; pwd -P )"
BIN_FILE_NAME="key-generator"
BIN_PATH="$PROJECT_ROOT_PATH/scripts/$BIN_FILE_NAME"
DATA_PATH=$PROJECT_ROOT_PATH/data
CONFIG_FILE_PATH=$DATA_PATH/Config.toml
PRIVATE_KEY_PATH=$DATA_PATH/signing_key
# Copy the new version's binary to the scripts directory
if [[ -f "$PROJECT_ROOT_PATH/target/release/$BIN_FILE_NAME" ]]; then
cp $PROJECT_ROOT_PATH/target/release/$BIN_FILE_NAME $PROJECT_ROOT_PATH/scripts
fi
# Check if the binary exists
if [[ ! -f "$BIN_PATH" ]]; then
echo "Error: Keygenerator binary not found at $BIN_PATH"
echo "Please run this command 'cp $PROJECT_ROOT_PATH/target/release/$BIN_FILE_NAME $PROJECT_ROOT_PATH/scripts' after building the project"
exit 1
fi
# ONLY THE FOLLOWING VARIABLES SHOULD BE CHANGED
# Below are the environment variables required for setting up the Distributed Key Generator.
# ============================
# 🔄 RPC Endpoints
# ============================
# Internal RPC URL
# Used to add a node to the Distributed Key Management System (DKG).
KEY_GENERATOR_INTERNAL_RPC_URL="http://127.0.0.1:7200" # Internal IP - Please change this IP.
# Cluster RPC URL
# Used for communication within the DKG cluster.
KEY_GENERATOR_CLUSTER_RPC_URL="http://127.0.0.1:7300" # External IP - Please change this IP.
# External RPC URL
# Used for retrieving SKDE parameters, encryption keys, and decryption keys from the DKG.
KEY_GENERATOR_EXTERNAL_RPC_URL="http://127.0.0.1:7100" # External IP - Please change this IP.
# ============================
# 🔑 Wallet Address
# ============================
# Key Generator Address
# Used to retrieve the list of RPC URLs from the seeder,
# registered through the Liveness Radius contract (TBD).
KEY_GENERATOR_ADDRESS="0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266" # Please change this key generator address.
```
distributed_key_generation/scripts/rpc-call/env.sh
```sh
#!/bin/bash
# Below are the environment variables required for setting up the Distributed Key Generator.
# ============================
# 🔄 RPC Endpoints
# ============================
# Internal RPC URL
# Used to add a node to the Distributed Key Management System (DKG).
KEY_GENERATOR_INTERNAL_RPC_URL="http://127.0.0.1:7200" # Internal IP - Please change this IP.
# Cluster RPC URL
# Used for communication within the DKG cluster.
KEY_GENERATOR_CLUSTER_RPC_URL="http://127.0.0.1:7300" # External IP - Please change this IP.
# External RPC URL
# Used for retrieving SKDE parameters, encryption keys, and decryption keys from the DKG.
KEY_GENERATOR_EXTERNAL_RPC_URL="http://127.0.0.1:7100" # External IP - Please change this IP.
# ============================
# 🔑 Wallet Address
# ============================
# Key Generator Address
# Used to retrieve the list of RPC URLs from the seeder,
# registered through the Liveness Radius contract (TBD).
KEY_GENERATOR_ADDRESS="0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266" # Please change this key generator address.
```
# Run Tx. Orderer
## **Prerequisites**
### **1. Installations**
1. `Rust`, `Foundry`, `build-essential`, `pkg-config`, `libssl-dev`, `libclang-dev` must be installed.
2. Run the following shell command to match the correct version:
`foundryup -v nightly-5b7e4cb3c882b28f3c32ba580de27ce7381f415a`
### 2. Contract calls
All smart contract function calls must be executed with success.
*Note:* We use two separate accounts for different purposes:
* The **operator account** (secured by `OPERATOR_PRIVATE_KEY`) is **only** used for registering the operator in Symbiotic.
* The **operating account** (secured by `OPERATING_PRIVATE_KEY`) is responsible for running our tx. orderer.
This setup follows best practices recommended by other operators. They avoid using their operator private key for running programs to minimize security risks. To enhance security, our system ensures that the operator private key is strictly for registration, while the operating private key manages tx. orderer operations within the network.
Tx. Orderer (Operator) interactions with Symbiotic and Radius contracts
Using Private Key
```sh
#!/bin/bash
# ============================
# Symbiotic Operator Setup
# ============================
# This script handles registration and opt-in processes for the Symbiotic contract.
# It interacts with the Ethereum Holesky testnet.
# Validation Related
# ---------------------------
# 1. Configuration
# ---------------------------
RPC_URL="https://ethereum-holesky-rpc.publicnode.com" # Ethereum RPC URL
# Operator registration details
OPERATOR_REGISTRY_CONTRACT_ADDRESS="0x6F75a4ffF97326A00e52662d82EA4FdE86a2C548"
OPERATOR_PRIVATE_KEY="" # Your operator private key
# Vault opt-in service details
OPERATOR_VAULT_OPT_IN_SERVICE_CONTRACT_ADDRESS="0x95CC0a052ae33941877c9619835A233D21D57351"
VAULT_CONTRACT_ADDRESS="0x919c0EbA1b68803cd453fF218b0E59e174d8C2b0"
# Network opt-in service details
OPERATOR_NETWORK_OPT_IN_SERVICE_CONTRACT_ADDRESS="0x58973d16FFA900D11fC22e5e2B6840d9f7e13401"
NETWORK_ADDRESS="0x47482dA197719f2CE0BAeBB7F72D1d7C1D6cc8bD" # Ask network (rollup) team
# Operator details
OPERATOR_ADDRESS="" # Your operator address
# Tx. Orderer registration details
LIVENESS_CONTRACT_ADDRESS="0xBE32Ae8d955747FD4Ab0818C927c3926F373E05E" # Radius contract address
CLUSTER_ID="radius" # Cluster ID (Ask network/rollup team)
OPERATING_PRIVATE_KEY="" # Your operating private key
OPERATING_ADDRESS="" # Your operating address
# ============================
# 2. Register Operator
# ============================
echo "Registering operator..."
cast send "$OPERATOR_REGISTRY_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" --private-key "$OPERATOR_PRIVATE_KEY" \
"registerOperator()"
echo "Checking operator registration..."
cast call "$OPERATOR_REGISTRY_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" \
"isEntity(address who)(bool)" "$OPERATOR_ADDRESS"
echo "Expected output: true"
# ============================
# 3. Opt-in to Vault
# ============================
echo "Opting in to vault..."
cast send "$OPERATOR_VAULT_OPT_IN_SERVICE_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" --private-key "$OPERATOR_PRIVATE_KEY" \
"optIn(address vault)" "$VAULT_CONTRACT_ADDRESS"
echo "Checking vault opt-in status..."
cast call "$OPERATOR_VAULT_OPT_IN_SERVICE_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" \
"isOptedIn(address who, address where)(bool)" "$OPERATOR_ADDRESS" "$VAULT_CONTRACT_ADDRESS"
echo "Expected output: true"
# ============================
# 4. Opt-in to Network
# ============================
echo "Opting in to network..."
cast send "$OPERATOR_NETWORK_OPT_IN_SERVICE_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" --private-key "$OPERATOR_PRIVATE_KEY" \
"optIn(address network)" "$NETWORK_ADDRESS"
echo "Checking network opt-in status..."
cast call "$OPERATOR_NETWORK_OPT_IN_SERVICE_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" \
"isOptedIn(address who, address where)(bool)" "$OPERATOR_ADDRESS" "$NETWORK_ADDRESS"
echo "Expected output: true"
# Liveness Related
# ============================
# 5. Register Tx. Orderer
# ============================
echo "Registering tx. orderer..."
cast send "$LIVENESS_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" --private-key "$OPERATING_PRIVATE_KEY" \
"registerSequencer(string clusterId)" "$CLUSTER_ID"
echo "Checking tx. orderer registration..."
cast call "$LIVENESS_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" \
"isSequencerRegistered(string clusterId, address operating)(bool)" "$CLUSTER_ID" "$OPERATING_ADDRESS"
echo "Expected output: true"
```
Using Ledger
```sh
#!/bin/bash
# ============================
# Symbiotic Operator Setup (Ledger)
# ============================
# This script registers an operator and opts into services using a Ledger device for signing.
# All transactions interact with the Ethereum Holesky testnet.
# ---------------------------
# 1. Configuration
# ---------------------------
RPC_URL="https://ethereum-holesky-rpc.publicnode.com" # Ethereum RPC URL
# Operator registration details
OPERATOR_REGISTRY_CONTRACT_ADDRESS="0x6F75a4ffF97326A00e52662d82EA4FdE86a2C548"
# Vault opt-in service details
OPERATOR_VAULT_OPT_IN_SERVICE_CONTRACT_ADDRESS="0x95CC0a052ae33941877c9619835A233D21D57351"
VAULT_CONTRACT_ADDRESS="0x919c0EbA1b68803cd453fF218b0E59e174d8C2b0"
# Network opt-in service details
OPERATOR_NETWORK_OPT_IN_SERVICE_CONTRACT_ADDRESS="0x58973d16FFA900D11fC22e5e2B6840d9f7e13401"
NETWORK_ADDRESS="0x47482dA197719f2CE0BAeBB7F72D1d7C1D6cc8bD" # Ask network (rollup) team
# Operator details
OPERATOR_ADDRESS="" # Your operator address
# Tx. orderer registration details
LIVENESS_CONTRACT_ADDRESS="0xBE32Ae8d955747FD4Ab0818C927c3926F373E05E" # Radius contract address
CLUSTER_ID="radius" # Cluster ID (Ask network/rollup team)
OPERATING_ADDRESS="" # Your operating address
# Validation Related
# ============================
# 2. Register Operator
# ============================
echo "Registering operator..."
cast send "$OPERATOR_REGISTRY_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" --ledger \
"registerOperator()"
echo "Checking operator registration..."
cast call "$OPERATOR_REGISTRY_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" \
"isEntity(address who)(bool)" "$OPERATOR_ADDRESS"
echo "Expected output: true"
# ============================
# 3. Opt-in to Vault
# ============================
echo "Opting in to vault..."
cast send "$OPERATOR_VAULT_OPT_IN_SERVICE_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" --ledger \
"optIn(address vault)" "$VAULT_CONTRACT_ADDRESS"
echo "Checking vault opt-in status..."
cast call "$OPERATOR_VAULT_OPT_IN_SERVICE_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" \
"isOptedIn(address who, address where)(bool)" "$OPERATOR_ADDRESS" "$VAULT_CONTRACT_ADDRESS"
echo "Expected output: true"
# ============================
# 4. Opt-in to Network
# ============================
echo "Opting in to network..."
cast send "$OPERATOR_NETWORK_OPT_IN_SERVICE_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" --ledger \
"optIn(address network)" "$NETWORK_ADDRESS"
echo "Checking network opt-in status..."
cast call "$OPERATOR_NETWORK_OPT_IN_SERVICE_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" \
"isOptedIn(address who, address where)(bool)" "$OPERATOR_ADDRESS" "$NETWORK_ADDRESS"
echo "Expected output: true"
# Liveness Related
# ============================
# 5. Register Tx. Orderer
# ============================
echo "Registering tx. orderer..."
cast send "$LIVENESS_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" --ledger \
"registerSequencer(string clusterId)" "$CLUSTER_ID"
echo "Checking tx. orderer registration..."
cast call "$LIVENESS_CONTRACT_ADDRESS" --rpc-url "$RPC_URL" \
"isSequencerRegistered(string clusterId, address operating)(bool)" "$CLUSTER_ID" "$OPERATING_ADDRESS"
echo "Expected output: true"
```
### **3. Running Tx. Orderer**
Repository: [Sequencer GitHub](https://github.com/radiusxyz/sequencer.git)
***Note**:* A cluster is a group of tx. orderers with a leader. This process can run with a single tx. orderer as well. Do not be confused by the `.env` variables referencing clusters.
### Key Details
* **Language and Build Requirements:** The Tx. Orderer is written in Rust and must be built using `cargo build --release` in the root directory.
* **Environment Variables:**
* Create an `env.sh` file at `sequencer/scripts/execute/env.sh` based on the contents of `env_example.sh`.
* Ensure the ports defined in `env.sh` are available.
* Another `env.sh` is needed at `sequencer/scripts/rpc-call/env.sh` for RPC-related scripts, also derived from `env_example.sh`.
* **Initialization Scripts:**
* Tx. orderer is initialized and run using scripts located in the repository:
* `sequencer/scripts/execute/01_init_sequencer.sh`
* `sequencer/scripts/execute/02_run_sequencer.sh`
*Note*: the tx. orderer is configured to support various types of liveness and validation. Additionally, a single tx. orderer is not limited to operating for just one rollup but is designed to manage multiple rollups. If the components currently provided through APIs were converted into configurations, the tx. orderer serving an existing rollup would need to be restarted each time a new rollup is added. To prevent this, these components are structured as APIs.
***
#### Hardware Specs
* CPU: 4
* Memory (GiB): 16
* Network (Gbps): 1
* Storage (GB): 256
#### Running the Tx. Orderer
1. Clone the repository
```sh
git clone https://github.com/radiusxyz/sequencer
```
2. Build the binary
```sh
cd sequencer
cargo build --release
```
3. Set up environment variables in `./scripts/execute/env.sh`.
4. Initialize the Tx. Orderer:
```bash
./scripts/execute/01_init_sequencer.sh
```
5. Start the Tx. Orderer:
```bash
./scripts/execute/02_run_sequencer.sh
```
6. Set up environment variables in `sequencer/scripts/rpc-call/env.sh`.
7. **Initialize RPC for adding the sequencing info related to LivenessServiceManager contract:** This action serves for integrating liveness information from the LivenessServiceManager smart contract into the tx. orderer. Upon completion, the tx. orderer will be able to listen to events related to the LivenessServiceManager smart contract on the `LIVENESS_PLATFORM`, retrieve information about tx. orderers and rollups, and invoke functions within the smart contract:
```bash
./scripts/rpc-call/11_add_sequencing_info.sh
```
8. **Add validation service details with RPC:** This action serves for integrating validation information from the ValidationServiceManager smart contract into the tx. orderer. Upon completion, the tx. orderer will be able to listen to events related to the ValidationServiceManager smart contract on the VALIDATION\_PLATFORM, retrieve information from the ValidationServiceManager contract, and invoke its functions.
```bash
./scripts/rpc-call/12_add_symbiotic_validation_info.sh
```
9. **Add cluster info:** This action serves for integrating cluster information, registered in the smart contract, into the tx. orderer. Upon completion, the tx. orderer will collect events whenever a block is generated in LIVENESS\_PLATFORM and automatically update itself with the relevant cluster information.
```bash
./scripts/rpc-call/13_add_cluster.sh
```
**Environment Variables**
sequencer/scripts/execute/env.sh
{% code overflow="wrap" %}
```bash
#!/bin/bash
SCRIPT_PATH="$( cd -- "$(dirname "$0")" >/dev/null 2>&1 ; pwd -P )"
PROJECT_ROOT_PATH="$( cd $SCRIPT_PATH/../.. >/dev/null 2>&1 ; pwd -P )"
BIN_FILE_NAME="sequencer"
BIN_PATH="$PROJECT_ROOT_PATH/scripts/$BIN_FILE_NAME"
DATA_PATH=$PROJECT_ROOT_PATH/data
CONFIG_FILE_PATH=$DATA_PATH/Config.toml
PRIVATE_KEY_PATH=$DATA_PATH/signing_key
# Copy the new version's binary to the scripts directory
if [[ -f "$PROJECT_ROOT_PATH/target/release/$BIN_FILE_NAME" ]]; then
cp $PROJECT_ROOT_PATH/target/release/$BIN_FILE_NAME $PROJECT_ROOT_PATH/scripts
fi
# Check if the binary exists
if [[ ! -f "$BIN_PATH" ]]; then
echo "Error: Sequencer binary not found at $BIN_PATH"
echo "Please run this command 'cp $PROJECT_ROOT_PATH/target/release/$BIN_FILE_NAME $PROJECT_ROOT_PATH/scripts"
exit 1
fi
# ONLY THE FOLLOWING VARIABLES SHOULD BE CHANGED
# ============================
# Tx. Orderer Configuration
# ============================
# ⚠️ NOTE: The following values are provided for contracts deployed on the Ethereum Holesky testnet.
# ⚠️ If you're deploying to a different network, update these values accordingly.
# ---------------------------------
# 🔑 Operating Tx. Orderer Private Key
# ---------------------------------
# Used for signing various data, such as order commitments for users, block commitments for validation, etc.
SEQUENCER_PRIVATE_KEY="0xe090d38fc4b19212e1b61fd32f02c9f928fedaa3338c13e0911fde837762d9ee" # ⚠️ Change this before deploying.
# ---------------------------------
# 🔄 Tx. Orderer RPC URLs
# ---------------------------------
# Used for storing node-related information.
SEQUENCER_INTERNAL_RPC_URL="http://127.0.0.1:4000" # Internal IP - Update as needed.
# Used for communication within the cluster.
SEQUENCER_CLUSTER_RPC_URL="http://127.0.0.1:5555" # External IP - Update as needed.
# Used for retrieving blocks and order commitments from the transaction orderer.
SEQUENCER_EXTERNAL_RPC_URL="http://127.0.0.1:5556" # External IP - Update as needed.
# ---------------------------------
# 🔐 DKG (Distributed Key Generator)
# ---------------------------------
# Used for retrieving the decryption key from the DKG.
DISTRIBUTED_KEY_GENERATOR_RPC_URL="http://127.0.0.1:7100" # External DKG RPC URL - Update as needed.
# ---------------------------------
# 🌱 Seeder Configuration
# ---------------------------------
# Used for registering the transaction orderer's IP and providing the IPs of other transaction orderers in the cluster.
SEEDER_RPC_URL="http://127.0.0.1:6000" # External Seeder RPC URL - Update as needed.
```
{% endcode %}
sequencer/scripts/rpc-call/env.sh
#!/bin/bash
# ============================
# Tx. Orderer Configuration
# ============================
# ⚠️ NOTE: The following values are for the Ethereum Holesky testnet.
# ⚠️ If you're deploying to a different network, update them accordingly.
# ---------------------------------
# 🔄 Tx. Orderer RPC Configuration
# ---------------------------------
# The RPC endpoint for registering the transaction orderer for both the Liveness and Validation services.
SEQUENCER_INTERNAL_RPC_URL="http://127.0.0.1:4000" # Internal IP - Update this with your correct IP.
# ============================
# 🔵 LivenessServiceManager Contract
# ============================
# ⚠️ DO NOT CHANGE THESE VALUES ⚠️
# The blockchain on which the LivenessServiceManager contract is deployed, currently Ethereum.
LIVENESS_PLATFORM="ethereum" # Options: [ethereum]
# The network that provides liveness service, currently Radius.
LIVENESS_SERVICE_PROVIDER="radius" # Options: [radius]
# Ethereum RPC & WebSocket URLs for the LivenessServiceManager contract.
LIVENESS_RPC_URL="https://ethereum-holesky-rpc.publicnode.com"
LIVENESS_WS_URL="wss://ethereum-holesky-rpc.publicnode.com"
# 📍 LivenessServiceManager contract address (provided by Radius).
LIVENESS_CONTRACT_ADDRESS="0xBE32Ae8d955747FD4Ab0818C927c3926F373E05E"
# 🏗️ Cluster ID (provided by the network/rollup team).
# A unique identifier for the cluster.
CLUSTER_ID="radius" # ⚠️ Update this if necessary.
# ============================
# 🟡 ValidationServiceManager Contract
# ============================
# ⚠️ DO NOT CHANGE THESE VALUES ⚠️
# The blockchain on which the ValidationServiceManager is deployed, currently Ethereum.
VALIDATION_PLATFORM="ethereum" # Options: [ethereum]
# The network providing validation services, either Symbiotic or EigenLayer.
VALIDATION_SERVICE_PROVIDER="symbiotic" # Options: [eigen_layer / symbiotic]
# Ethereum RPC & WebSocket URLs for the ValidationServiceManager contract.
VALIDATION_RPC_URL="https://ethereum-holesky-rpc.publicnode.com"
VALIDATION_WS_URL="wss://ethereum-holesky-rpc.publicnode.com"
# 📍 ValidationServiceManager contract (provided by the network/rollup team).
# The address of the deployed ValidationServiceManager, used for validating block commitments and other restaking-related matters.
VALIDATION_SERVICE_MANAGER_CONTRACT_ADDRESS="0x886404D7b959B01E351FC975Aa298e4c2b6F9d55"
# Run Secure RPC
Repository: [Secure RPC GitHub](https://github.com/radiusxyz/secure-rpc.git)
1. Clone the repository
```sh
git clone https://github.com/radiusxyz/secure-rpc
```
2. Build the binary
```sh
cd secure-rpc
cargo build --release
```
3. Set up environment variables in `./scripts/execute/env.sh`.
4. Initialize the service:
```sh
./scripts/execute/01_init_secure_rpc.sh
```
5. Start the service:
```bash
./scripts/execute/02_run_secure_rpc.sh
```
**Environment Variables**
secure-rpc/scripts/execute/env.sh
```bash
#!/bin/bash
SCRIPT_PATH="$( cd -- "$(dirname "$0")" >/dev/null 2>&1 ; pwd -P )"
PROJECT_ROOT_PATH="$( cd $SCRIPT_PATH/../.. >/dev/null 2>&1 ; pwd -P )"
BIN_FILE_NAME="secure-rpc"
BIN_PATH="$PROJECT_ROOT_PATH/scripts/$BIN_FILE_NAME"
DATA_PATH=$PROJECT_ROOT_PATH/data
CONFIG_FILE_PATH=$DATA_PATH/Config.toml
# Copy the new version's binary to the scripts directory
if [[ -f "$PROJECT_ROOT_PATH/target/release/$BIN_FILE_NAME" ]]; then
cp $PROJECT_ROOT_PATH/target/release/$BIN_FILE_NAME $PROJECT_ROOT_PATH/scripts
fi
# Check if the binary exists
if [[ ! -f "$BIN_PATH" ]]; then
echo "Error: Secure RPC binary not found at $BIN_PATH"
echo "Please run this command 'cp $PROJECT_ROOT_PATH/target/release/$BIN_FILE_NAME $PROJECT_ROOT_PATH/scripts' after building the project"
exit 1
fi
# ONLY THE FOLLOWING VARIABLES SHOULD BE CHANGED
# ============================
# 🔒 Secure RPC Configuration
# ============================
# 🎯 Used to configure the RPC endpoint that can be identified and accessed
# by users and transaction orderers.
SECURE_RPC_EXTERNAL_RPC_URL="http://127.0.0.1:6666" # 🌐 External IP - Please update this.
# ============================
# 🔵 Rollup Configuration
# ============================
# 🏗️ Due to the ordering of transactions across multiple rollups,
# the Rollup ID is required to identify the target rollup executor.
ROLLUP_ID="nodeinfra_rollup" # ⚠️ Please update this Rollup ID.
# 💡 Since wallets support adding only a single network RPC URL, Secure-RPC must provide
# all the methods that would be accessible without it when directly communicating
# with the blockchain. Therefore, ROLLUP_RPC_URL is used to retrieve rollup information
# and forward it to the wallet or client.
ROLLUP_RPC_URL="http://131.153.159.15:8123" # 🌐 Please update this Rollup RPC URL.
# ============================
# 🔄 Sequencer Configuration
# ============================
# 🎯 Used to identify the target IP of the transaction orderer (tx. orderer)
# responsible for receiving encrypted transactions and responding with order commitments.
SEQUENCER_RPC_RPC_URL="http://127.0.0.1:7777" # 🌐 Please update this Sequencer (external) RPC URL.
# ============================
# 🔐 Encrypted Transaction Type
# ============================
# 🔏 Specifies the cryptographic scheme used for encrypting the user's transactions.
# Options: skde / pvde
ENCRYPTED_TRANSACTION_TYPE="skde"
# ============================
# 🔑 DKG (Distributed Key Generator)
# ============================
# 🔓 Used for retrieving SKDE parameters, encryption keys, and decryption keys from the DKG.
DISTRIBUTED_KEY_GENERATOR_RPC_URL="http://127.0.0.1:7100" # 🌐 Please update this Distributed Key Generator (external) RPC URL.
```
# Contracts
The system involves two key contracts:
1. **LivenessRadius**
* Ensures the overall **liveness** of the **SBB**.
* Coordinates multiple entities, including:
* **Transaction Orderers**
* **Seeder**
* **Clusters**
* **Rollups** and their **Executors**
* Plays a **crucial role** in maintaining network activity and availability.
2. **ValidationServiceManager**
* Manages **operators, network participation, vaults, stakes, and rewards**.
* Every **rollup** that registers with the **LivenessRadius contract** must also **add their ValidationServiceManager contract**.
* This is required to **participate in the Symbiotic restaking protocol**.
These contracts work together to **maintain network liveness, coordination, and incentive mechanisms**.
# Liveness Service Manager
### Overview
The purpose of this contract is to facilitate the management of clusters, rollups, and tx. orderers in a decentralized system. It provides the framework to organize clusters, where each cluster contains rollups, and the rollups are coordinated by tx. orderers. The contract ensures security, modularity, and upgradability using industry-standard libraries.
This system is designed to be highly customizable, allowing owners to define and manage their clusters, control rollups, and ensure proper registration of participants such as tx. orderers and executors.
***
### Key Concepts
1. **Clusters**\
A cluster represents a logical grouping managed by an owner. Within a cluster, there are limits on how many participants can be active at any time. The cluster owner is responsible for configuring the cluster and ensuring proper operation.
2. **Rollups**\
Rollups are components within clusters that process transactions. They carry specific properties, such as types, transaction encryption methods, and validation mechanisms. Rollups also support executors who perform specific operations within the rollup.
3. **Tx. orderers**\
Tx. orderers are responsible for ensuring liveness and ordering of operations within clusters. Each cluster has a fixed capacity for tx. orderers, and new participants must register to fill available slots.
***
### Process Overview
#### Contract Setup
The contract is designed to prevent unauthorized modifications. It starts in an uninitialized state and must be explicitly initialized before it can be used. During this initialization, important configurations and security mechanisms are set up to ensure safe and secure operation.
#### Cluster Management
One can create a new cluster by defining its unique identifier and specifying how many tx. orderers it can support. Once a cluster is created, it is ready to have rollups added and participants registered. Clusters are fully owned and controlled by their creators, ensuring that no unauthorized entity can make changes.
#### Adding Rollups
To expand the functionality of a cluster, rollups can be added by the cluster owner. Each rollup is uniquely identified and comes with specific configuration details. These include its type, the transaction methods it supports, and validation rules. Additionally, an executor—a participant responsible for executing the transactions—can be assigned during the setup process.
Currently, the `ValidationServiceManager` contract address is emitted during this process. This contract serves as a critical component for coordinating the network, its operators, and associated vaults. It is also responsible for defining stake limits, managing rewards, and enforcing slashing conditions to maintain network integrity.
The details of the `ValidationServiceManager.sol` contract, which is a part of the symbiotic-middleware-contract framework, will be explained in the next section. This explanation will provide further clarity on its role in ensuring efficient and secure operations within the network.
#### Registering Participants
Clusters require tx. orderers to ensure operations run smoothly. When a new participant wants to join as a tx. orderer, they must register with the cluster. This process checks for available slots and ensures that the participant has not already been registered. If successful, the tx. orderer is assigned a position in the cluster.
#### Deregistering Participants
A tx. orderer can be deregistered if needed. This process involves removing their association with the cluster or rollup and making their slot available for others.
#### Retrieving Information
The contract provides detailed visibility into its state. Owners and participants can query information about clusters, including the list of active tx. orderers, details about rollups, and registered executors. Additionally, participants can discover all clusters they are associated with, and anyone can retrieve a complete list of all cluster identifiers in the system.
***
### How the System Ensures Integrity
1. **Ownership-Based Control**\
Only the owner of a cluster or rollup has permission to make changes, ensuring that unauthorized entities cannot interfere.
2. **Limits and Validation**\
The system enforces limits, such as the maximum number of tx. orderers per cluster, and validates input to prevent duplicate or invalid registrations.
3. **Event Emission**\
Every significant action, such as adding a rollup or registering a tx. orderer, triggers an event. These events create an immutable record that can be reviewed externally.
4. **Fault Tolerance**\
Deregistration processes are designed to handle cleanup gracefully, ensuring that the system remains consistent even when participants leave.
***
### Use Cases
1. **Managing a Decentralized Rollup Ecosystem**\
A developer or organization can use this system to manage a decentralized network of rollups, assigning specific roles to participants and maintaining overall control.
2. **Participant Registration**\
It provides a structured process for participants, such as tx. orderers or executors, to join or leave clusters dynamically.
3. **Real-Time Queries**\
It lets accessing detailed, up-to-date information about clusters, rollups, and participants for decision-making or monitoring purposes.
***
# Validation Service Manager
### Overview
The `ValidationServiceManager` is a contract designed to coordinate and manage a decentralized network of operators, tokens, and vaults. It operates on an epoch-based system, enabling dynamic interactions while maintaining a high degree of security and accountability. This contract ensures proper registration, staking, and task execution in a modular and scalable manner.
At its core, the contract aims to create a seamless environment for managing decentralized validation services, providing mechanisms for operators, tokens, and vaults to participate in a structured network.
***
### Key Concepts
1. **Epochs**\
Time is divided into discrete intervals called epochs. Each epoch serves as a logical unit for calculating staking, task execution, and operator activity.
2. **Operators**\
Operators are key participants in the network, responsible for tasks such as validation or staking. They must meet certain criteria, such as opting into the network and maintaining a minimum stake.
3. **Tokens**\
Tokens represent assets that can be staked by operators. They are registered with the network and require owner approval to be added or removed.
4. **Vaults**\
Vaults are associated with tokens and represent collateral-backed mechanisms in the system. They ensure that only valid assets are included in the staking and task-execution processes.
5. **Tasks**
Tasks are the operational units in the system. They are created, assigned, and executed by operators, ensuring the network functions smoothly. In the task creation process, the leader tx. orderer takes the initiative by submitting a block commitment to the contract. This submission creates a new task. Once the task is created, follower tx. orderers monitor the contract for the emitted event indicating the new task. Upon detecting the event, they calculate their own block commitment based on the provided data and respond to the task accordingly. The leader's role is critical in initiating the task, while the followers' responses validate and strengthen the integrity of the system. The `ValidationServiceManager` contract plays a key role in facilitating this interaction, emitting relevant events and ensuring that all task-related activities are tracked and verified within the network. This seamless interaction between the leader and follower tx. orderers is a cornerstone of the contract’s operational design, ensuring the network operates efficiently and securely.
***
### Process Overview
#### System Initialization
The contract is initialized by defining the network, registry, and opt-in service parameters. Additionally, the epoch duration is set, dividing time into manageable intervals for operations.
#### Epoch Management
Epochs are used to organize and track network activity. The start time of the system is recorded, and the current epoch is determined based on the duration elapsed since initialization. Epoch-specific calculations, such as staking or operator activity, are performed relative to these intervals.
#### Operator Management
Operators are the backbone of the network, and their management involves several steps:
* **Registration**: An operator can join the network after opting in and providing an operational address. This registration is approved by the contract owner.
* **Pausing and Resuming**: Operators can be paused to temporarily disable their activity, ensuring the network remains secure.
* **Unregistration**: Operators can be removed if they are inactive for a specified grace period. This process also clears their operational data.
Operators are required to maintain a minimum stake in approved tokens to participate in tasks or other network activities.
#### Token Management
Tokens are added to the system by the contract owner and represent the assets that can be staked. The management process includes:
* **Registration**: New tokens can be registered and enabled for use.
* **Pausing and Unpausing**: Tokens can be temporarily disabled if necessary.
* **Unregistration**: Tokens can be removed if they are no longer active in the system.
Each token is subject to a minimum staking requirement, which is defined by the owner. Operators must meet this threshold to remain active.
#### Vault Management
Vaults are associated with collateral and are linked to the tokens in the network. They provide the infrastructure for staking. The vault management process involves:
* **Registration**: Vaults are added after verifying they are valid entities in the registry.
* **Pausing and Resuming**: Vaults can be disabled temporarily, similar to tokens.
* **Unregistration**: Vaults can be removed after ensuring they have completed their activity gracefully.
#### Staking Management
Staking ensures that operators remain accountable within the network. The system calculates and caches stake information for tokens and operators during each epoch. This includes:
* **Total Staked Amounts**: The total stake for each token is tracked and updated.
* **Operator Stakes**: Individual operator stakes are calculated and compared against the minimum staking threshold.
* **Caching and Validation**: Stake information is cached to optimize network performance and validated periodically to ensure accuracy.
#### Task Management
Tasks are critical for network operations, providing a mechanism for operators to contribute. The task process includes:
* **Creation**: Tasks are created with specific parameters, such as the block number and commitment hash. Only eligible operators can create tasks.
* **Responses**: Operators can respond to tasks, and their participation is recorded. Each operator can only respond once to a specific task.
* **Validation**: Responses are validated to ensure operators meet all requirements and are actively participating in the network.
#### Querying Information
The contract provides comprehensive tools for querying the state of the network. Users can retrieve:
* The list of active operators, tokens, or vaults for the current epoch.
* Detailed information about specific operators, including their stakes and operational status.
* Cached stake data for tokens and operators, optimized for quick access.
***
### Security and Integrity
1. **Ownership Control**\
All critical actions, such as registering operators, tokens, and vaults, require approval from the contract owner. This ensures that only authorized entities can modify the system.
2. **Opt-In Mechanism**\
Operators must explicitly opt into the network before registration, ensuring that they acknowledge and comply with the network's rules.
3. **Grace Periods**\
Both tokens and operators have a defined grace period before they can be removed.
4. **Stake Requirements**\
Minimum staking amounts are enforced to ensure operators have sufficient collateral to back their participation.
5. **Epoch-Based Activity**\
The use of epochs ensures that all operations are time-bound, reducing ambiguity and improving coordination across the network.
***
# Seeder
Repository: [Seeder GitHub](https://github.com/radiusxyz/seeder.git)
The **Seeder** plays a crucial role in coordinating **transaction orderers (tx-orderers)** by providing the necessary information for network communication.
To become a tx. orderer, a node must first **register itself in the LivenessRadius contract**. Once registered, it can join a cluster through the Seeder. The Seeder then **verifies the node’s wallet address** in the Liveness Contract before storing its **IP address**.
After successful registration, the **tx. orderer receives the IP addresses of other peers in the cluster**, enabling seamless **internal communication** between nodes.
Seeder - Tx. Orderer Interaction
Seeder - Rollup Operator Interaction
### **Seeder: Managing Tx. Orderer RPC URLs**
The **Seeder** functions as a **key-value store**, mapping tx. orderer addresses to their corresponding RPC URLs.
#### **Key Responsibilities**
* Stores **tx. orderer addresses** as keys and their **RPC URLs** as values.
* Ensures that only **tx. orderers registered in the LivenessServiceManager contract** can register on the Seeder.
***
### **Registration Process**
To register, a **tx. orderer** must send a **signed message** containing:
* **Tx. Orderer Address**
* **External RPC URL** (handles user transactions)
* **Cluster RPC URL** (for inter-cluster messages with signature verification)
* **Cluster ID** (received upon registering with the LivenessServiceManager contract)
#### **Validation Steps**
When a **registration request** is received, the Seeder:
1. **Verifies the message signature**.
2. **Confirms that the tx. orderer is registered on the LivenessServiceManger contract**.
3. **Checks the accessibility of the external RPC URL** via the `/health` endpoint.
**Upon successful validation, the tx. orderer's address and RPC URLs are stored in the Seeder**, making them available to **Secure RPC, Tx. Orderers, and Rollups**.
***
### **Deregistration Process (TBD)**
A **tx. orderer** can deregister by sending a **signed message** containing:
* **Tx. Orderer Address**
* **Cluster ID**
#### **Validation Steps**
When a **deregistration request** is received, the Seeder:
1. **Verifies the message signature**.
2. **Checks if the tx. orderer has been removed from the LivenessServiceManager contract**.
If confirmed, the **Seeder removes the tx. orderer’s address**, making its **RPC URLs unavailable**.
# Distributed Key Management System (DKG)
Repository: [Distributed Key Generation GitHub](https://github.com/radiusxyz/distributed_key_generation)
## Overview of DKG
## Distributed Key Generation (DKG) Overview
The Distributed Key Generation (DKG) service is a core component of Radius’s Single Key Delay Encryption (SKDE) method. It ensures secure encryption and decryption by distributing key generation across multiple nodes. Each node contributes a partial key, which is aggregated into an encryption key. A delay function is then applied to derive the decryption key later. This enables:
* Users and secure-RPC to encrypt transactions.
* The transaction orderer to obtain the decryption key for secure processing.
### SBB with SKDE
#### Background
SKDE powers encrypted mempool operations within SBB. Traditionally, each blockchain network requires independent SKDE systems, which introduces inefficiencies. Since networks have different block generation cycles, managing unique encryption schemes for each is impractical.
A unified DKG network addresses this by supporting all block intervals, optimizing key management across blockchain ecosystems. This Proof of Concept (PoC) lays out a scalable DKG protocol designed to enhance security, interoperability, and efficiency.
#### SKDE Workflow
1. **Partial Key Generation**
* Participants generate partial keys and validity proofs using RSA-based parameters and time-lock puzzles to distribute trust.
2. **Partial Key Verification**
* Ensures the authenticity of generated partial keys.
3. **Partial Key Aggregation**
* A block proposer collects and combines partial keys using Multi-Party Computation (MPC).
4. **Transaction Encryption**
* Users encrypt transactions with the aggregated key to prevent pre-execution visibility, mitigating MEV and censorship risks.
5. **Puzzle Solving**
* A solver derives the decryption key by solving a time-lock puzzle, ensuring transactions remain encrypted until processing time.
6. **Transaction Decryption**
* Transactions are decrypted in an ordered manner for execution.
### Key Assumptions
* **Key Committee**: A designated committee ensures secure and efficient operation.
* **Minimal Delay Impact**: Time fluctuations should not disrupt protocol effectiveness.
* **Network Latency**: Assumed round-trip time (RTT) is 100–200ms.
* **Key Rotation**: New keys are generated every second, with overlapping cycles ensuring availability.
* **Participation Requirements**: Nodes must stake tokens to participate in the DKG network.
### Key Life Cycle & Usage
#### Life Cycle
A defined key committee generates partial keys and aggregates them into a master encryption key (AggKey). Until it is decrypted, transactions remain encrypted. The decryption key (DevKey) is used once the delay function is solved.
#### Key-Related Periods
* **Key Request Period**: Users request encryption keys before submission deadlines.
* **Transaction Submission**: Encrypted transactions must be submitted within the given timeframe.
* **Key Solve Period**: Decryption keys are computed with a 2-second delay.
* **Order Commit Period**: Transactions are committed to blocks in an ordered sequence.
### DKG Protocol with Fast Consensus
#### Overview
Committees precompute partial keys and proofs ahead of time, maintaining two key instances to optimize encryption order commitments. Initial blocks include valid key lists, followed by decryption key releases.
#### Protocol Workflow
1. **Setup**: Nodes exchange and validate partial keys, forming a consensus on a valid key list.
2. **Key Aggregation**: All nodes independently compute the aggregated encryption key.
3. **Transaction Encryption**: Users encrypt transactions with the aggregated key (AggKey).
4. **Order Commitment**: SBB nodes establish transaction order before decryption.
5. **Puzzle Solving**: Anyone can solve the time-lock puzzle to reveal the decryption key.
6. **Decryption & Execution**: The decrypted key is shared with SBB nodes to execute transactions.
7. **Key Cycle Reiteration**: New keys are continuously generated to maintain security and efficiency.
### Consensus Considerations
* **Without Consensus (Ethereum Dependency)**: Relies on Ethereum for validation.
* **With Consensus**: A decentralized approach where committee members reach agreement independently.
By leveraging a unified DKG system, this protocol enhances encryption efficiency, reduces redundant infrastructure, and ensures seamless blockchain interoperability.
# Tx. Orderer Cluster
**Overview**
The cryptographic approach employed by the system ensures a trustless environment for the tx. orderer operation. However, the architecture still faces the challenge of a Single Point of Failure (SPOF). To mitigate this risk, Radius adopts a distributed tx. orderer network. This network comprises multiple tx. orderers operating concurrently to ensure system reliability and continuity.
**Functionality**
In the event of a tx. orderer failure, the distributed nature of the network allows the remaining tx. orderers to continue operations without interruption. This redundancy enhances the robustness of the system against individual node failures.
**Communication and Decision making**
To ensure efficient communication and syncing among multiple nodes, Radius adopts a leader-based decision-making process. This strategy eliminates the need for consensus regarding the order and formation of blocks. It clearly outlines the roles and duties of the tx. orderers in the network, distinguishing between the leader and the followers.
**Key Benefits**
* **Reliability:** The distributed tx. orderer network significantly reduces the risk associated with a single point of failure, ensuring higher system uptime.
* **Efficiency:** By eliminating the need for consensus between network members, Radius ensures efficient decision-making among tx. orderers, leading to a swift and reliable sequencing process.
* **Scalability:** The distributed architecture allows for scalability, accommodating an increasing number of tx. orderers as the network grows.
**Conclusion**
The implementation of a distributed tx. orderer network represents a strategic approach to enhancing the reliability, scalability, and decision making efficiency of tx. orderer set. This ensures that the system remains robust against failures and maintains continuous operation.
# Liveness
A key advantage of distributed systems is their fault tolerance. In the current architecture, since the main actions depend on the leader, a robust recovery mechanism is essential. This mechanism should ensure the system's liveness by:
1. **Quick Transition to a New Leader:** Ensuring that a new leader can be quickly established if the current leader fails.
2. **Data Synchronization:** Keeping data synchronized across all nodes to maintain continuous operation even during a leader transition.
These measures ensure the system remains operational and efficient, even in the event of a leader failure.
# Leader Selection
## Leader selection
Dynamic leader selection is a crucial part of the current product to ensure the fair distribution of reward and ensure the liveness of the tx. orderer set. Unlike the RAFT algorithm, which involves voting based leader election process, in the Eigenlayer Testnet we introduce the new algorithmic method of leader selection.
## Algorithm
**Arguments**
* **L1 Block Number**: Provides access to the instance of the tx. orderer list stored on Ethereum for a given block number.
* **Rollup Block Number**: The number of the rollup's next block.
**Method**
1. Access the tx. orderer list using the L1 block number.
2. Compute the index:
$$
\text{index} = (\text{rollup block number})\bmod(\text{number of elements in the tx. orderer list})
$$
3. Determine the leader as the ***index***-th element of the cluster.
## Corner Cases
* The rollup will provide the necessary arguments to the leader responsible for building the current block. However, if the leader tx. orderer is unresponsive, the rollup will send the same request to any of the followers. The leader for the next block will be determined in the usual manner. For the current block, the follower contacted by the rollup will assume the [role of the leader](https://docs.theradius.xyz/overview/internal-secure-block-building-sbb/tx.-orderer-cluster/liveness/pages/ESbJQd5rQb0Rr7PlfU7j#id-2.-improved-system-performance).
* Tx. orderers must verify that the L1 block number provided by the rollup falls within a predefined block margin. This ensures that the rollup adheres to the fair leader change mechanism and prevents the rollup from using an L1 block number that would result in the same index as the previous block.
## Benefits
* **Encourages Participation**: Ensures that every member of cluster has an equal opportunity to become a leader and earn rewards, motivating more participants to opt in.
* **Promotes Decentralization**: Enhances decentralized sequencing even with a leader-based system. Although a single entity orders transactions for each block, the frequent rotation of leaders reduces centralization.
* **Ensures Consistent Leader Selection**: Eliminates the need for voting or trust among nodes. Since the contract block number and rollup block number are shared with all nodes, the calculation of the next leader will consistently produce the same result for everyone.
# Syncing
### Normal Operation
* A well functioning leader tx. orderer consistently shares its state with the followers in a concurrent manner, who then synchronize their states to match that of the leader. This synchronization process ensures consistency across the network.
### Failover Operation
When the leader becomes unresponsive or fails, the following process ensures continuity and proper synchronization within the system:
1. **Leader Recovery and Request**:
* Upon recovery, the leader makes a request to all other members of the cluster to check if any of them have received the "build block" request from the rollup.
2. **No Build Block Request Received**:
* If no other peer has received the "build block" request from the rollup, the leader resumes its leadership role.
3. **Build Block Request Received by Follower**:
* If another peer has received the build block request, the recovered members of the cluster will synchronize its block height with that of the new leader, as the leadership role has been transferred to it.
This process ensures that the leader can either continue its role seamlessly or synchronize appropriately with the follower to maintain the integrity and continuity of the system.
This mechanism ensures that the network remains robust and consistent, aligning the states of all nodes with the selected leader's state, whether it includes the latest transactions and commitments or necessitates a rollback to maintain network integrity.
# Block Validation
#### Block Commitment Verification Process
In this process, each follower is synchronized with the encrypted transactions and their respective order commitments. This synchronization allows each member of the cluster to build the block similarly to the leader. The following steps outline the block commitment verification process:
#### Block Commitment Verification Process Documentation
Since each follower is synchronized with leader's encrypted transactions and respective order commitments, this enables them to build the block similarly to the leader. The following steps outline the block commitment verification process:
Block Validation Flow
1. **Initiating the Build**:
* Upon receiving the build block request, the leader initiates the build function.
* The leader propagates the close message to all followers, prompting them to close their blocks and begin building.
2. **Submitting Block to Rollup Operator**:
* The rollup operator requests a block from the leader.
* The leader submits the block to the rollup operator.
3. **Generating Block Commitments**:
* The leader and followers generate a block commitment based on the encrypted transactions and order commitments.
* This process occurs in parallel across all members of the cluster.
4. **Submitting Block Commitment by Leader**:
* The leader creates a task and submits its block commitment to ValidationServiceManager contract, triggering an event that followers listen to.
5. **Submitting Block Commitment by Followers**:
* The followers submit their block commitments as a respond to the same task.
6. **Commitment Validation**:
* ValidationServiceManager contract aggregates commitments from all members of the cluster.
* It validates the commitments by comparing them with the leader's block commitment through a smart contract.
* Rewards are determined based on the validation results.
This process ensures that block commitments are accurately validated.
**Validation Scenarios**
* **Scenario 1: Majority Coincidence**
* If the majority of the followers' commitments coincide with the leader's commitment, the leader's commitment is considered valid.
* The leader is rewarded.
* **Scenario 2: Majority Discrepancy**
* If the majority of the followers' commitments do not coincide with the leader's commitment, the leader's commitment is considered invalid.
* The leader is not rewarded.
**Assumptions**
* There is no slashing of the tx. orderer in this flow as of now, regardless of the result of the evaluation of block commitments.
* It is assumed that all members of the cluster, both followers and the leader, are motivated to earn fees and thus will not act maliciously.
This process ensures that the block commitments are verified in a decentralized manner, promoting fairness and accuracy in the blockchain network.
# Leader-based
The cluster members are divided into two categories: leaders and followers. Followers are responsible for routing data to and from the leader and users, as well as synchronizing the state. Meanwhile, the leader takes on more complex tasks such as sequencing transactions into blocks, providing order commitments, signing transactions, and interacting with rollups. This method offers several advantages.
#### 1. Simplified Decision Making
* **Simplicity:** With a single leader responsible for sequencing, the system simplifies the decision-making process. This centralized approach reduces the complexity and overhead associated with achieving consensus among multiple nodes.
* **Efficiency:** Leader-based systems can implement more efficient ordering and syncing related decisions since the leader node acts as the authoritative source for sequencing. This streamlines the process of agreeing on the state of the system, as there's no need for multiple nodes to negotiate each sequence.
#### 2. Improved System Performance
* **Reduced Latency:** By centralizing the sequencing tasks, leader-based systems can often reduce communication latency. Messages do not need to traverse multiple nodes to reach a consensus, as the leader directly sequences and processes requests. However, note that the leader manages all processing, meaning its performance directly influences the overall network's functionality.
* **Optimized Throughput:** The leader can optimize sequencing and resource allocation based on the current system load and priorities, potentially improving the overall throughput of the system.
To avoid confusion, the details regarding the leader-follower interaction were not included in the previous sections. This was done to simplify the concept, allowing readers to view the cluster as a singular entity. However, below is an overview of how leader-follower interactions are handled:
For every RPC request made to any of the followers, the request and its associated data are redirected to the leaders. This redirection mechanism is evident in the tx. orderer's RPC methods:
The leader distributes the data to the followers to maintain a synchronized and updated state across the entire cluster. Generally, synchronization in the sequencing process involves every piece of data being propagated among the follower nodes. Syncing encrypted transactions, time-lock puzzles, order commitments are carried out.
Leader's Responsibilities
The sequence diagram illustrates the actions that are managed by the leader, eliminating the need for consensus:
1. **Verification of zk-proof:** The leader verifies the zk-proof.
2. **Ordering of Encrypted Transactions:** The leader arranges the encrypted transactions for the upcoming block.
3. **Generating an Order Commitment:** The leader creates order commitments with PRE Merkle proofs for the encrypted transactions.
4. **Signing the Order Commitment:** The leader signs the order commitments.
5. **Forwarding the Order Commitments:** The leader forwards the order commitments, encrypted transactions and other relevant data to the followers
6. **Receiving RPC call for providing the block the rollup operator:** Upon receiving the call for providing the block to the rollup operator, leader broadcasts this message to all the peers and starts the process of block building.
7. **Transaction Decryption:** The leader decrypts the transactions using the key obtained from the Secure RPC.
* SKDE allows decryption of all transactions using a single key obtained from solving a single time-lock puzzle.
8. **Interacting with Rollup Operator for Block Provision:** The leader responds to the rollup operator by providing the blocks.
9. **Creating task on ValidationServiceManager contract:** Upon completion and submission of the block, the leader generates the block commitment and submits it to the ValidationServiceManager contract as initialization of the block validation process.
Although currently in the development stage leader also generates POST Merkle proofs, which users can use together with the PRE Merkle Proof to verify the order and inclusion of their transactions.
# Secure RPC
Repository: [Secure RPC GitHub](https://github.com/radiusxyz/secure-rpc.git)
### Introduction
The **secure-rpc** framework enables **confidential transmission** of transaction data by:
* Encrypting transactions before sending them to any external system (e.g., a tx. orderer).
* Decrypting the transactions on the receiving end (or in any client context) when needed.
* Managing encryption and decryption keys via a **Distributed Key Generation (DKG)** service.
This approach ensures sensitive transaction data is protected both **at rest** and **in transit**.
***
### System Overview
The **secure-rpc** framework is designed to safeguard sensitive transaction data in a blockchain or rollup environment. Its core objective is to ensure that whenever a transaction needs to be broadcast, it can be protected by powerful encryption mechanisms after leaving the client environment. This encryption can later be undone by the **tx-orderer**. At the heart of the system lies a Distributed Key Generation (DKG) service, which manages the cryptographic keys needed to execute these operations.
Rather than manually tracking encryption keys or pre-sharing them among participants, the **secure-rpc** approach offloads most key-related responsibilities to this DKG service. The DKG is capable of serving the latest encryption keys for encrypting new transactions, while also storing and providing the corresponding decryption keys.
1. **Encryption Flows**
* **SKDE**\
A default encryption method that uses a distributed key approach. A “delay” aspect is introduced ensuring data is only decryptable after a certain time or condition.
* **PVDE**\
Leverages time-lock puzzles to enforce a minimum waiting period before decryption is possible.
2. **Decryption Flows**
* The system fetches the correct decryption key from the DKG service based on a `key_id`.
* Applies the corresponding decryption mechanism.
* Reconstructs the original transaction.
3. **RPC Endpoints**
* **Send Raw Transaction** (`send_raw_transaction`): Based on the configuration the tx can be encrypted or tx. encryption type can be changed.
4. **Distributed Key Generation Service**
* Provides encryption keys, decryption keys, and SKDE parameters.
* Manages key rotation or updates so that the client always uses the latest encryption key.
***
### Key Components & Flows
#### DKG Integration
* The secure-rpc client retrieves:
* **Encryption Key** for encrypting outgoing transactions.
* **Decryption Key** for decrypting incoming or stored transactions.
* **SKDE Parameters** needed for the SKDE algorithm.
#### Encryption Flow (SKDE Example)
1. **Raw Transaction** (e.g., Ethereum transaction) is provided.
2. **Transaction Splitting**:
* **Open Data**: Non-sensitive metadata or fields that must remain unencrypted.
* **Encrypted Data**: Sensitive fields that should remain confidential.
3. **Key Retrieval** from the DKG service (latest or specific `key_id`).
4. **Encryption** using SKDE routines (`skde::delay_encryption`) along with the **encryption\_key**.
5. **Result** is an `EncryptedTransaction` with a reference to the `key_id` used.
#### Time-Lock Puzzle (PVDE)
Though currently a minimal or “unsupported” flow in the provided code, the concept is:
1. Generate a puzzle parameter (`time_lock_puzzle_param`) which involves a carefully chosen modulus `n`, base `g`, and exponent `y`.
2. The encryption includes a puzzle, meaning that *even with the correct key*, it takes a certain number of sequential operations to unlock the data.
3. The puzzle is combined with zero-knowledge proofs (`sigma_protocol_public_input`) to prove that data was encrypted correctly without revealing it.
### Usage Scenario
Secure RPC data flow
1. **Client** needs to submit a transaction to a tx. orderer, but data is sensitive.
2. **AppState / Config** indicates encryption is enabled with SKDE.
3. Client calls `send_raw_transaction`, which internally:
* Calls `encrypt_transaction` → obtains an `EncryptedTransaction`.
* Sends this encrypted data to the tx. orderer via a chosen RPC endpoint from a configured URL list.
4. The tx. orderer provides the secure-rpc with order-commitment.
5. The secure RPC forwards it to the user.
6. Later, the tx-orderer needs to retrieve the original transaction.
* Tx. orderer fetches the decryption key from the DKG system and obtains the original transaction.
# Client (User)
Clients have two ways to submit their transactions to the transaction orderer.
1. **Using secure-rpc**:\
Clients send their signed raw transactions to secure-rpc. The secure-rpc retrieves the necessary encryption key and other data from the DKG, encrypts the transaction, and forwards it to the sequencer. When the sequencer responds with an encrypted pre-confirmation, the secure-rpc then provides the decryption key. This ensures that transactions can only be decrypted after encrypted pre-confirmations are received.
2. **Using radius-snap**:\
Clients can generate or import their private key through the radius-snap. This allows the snap to sign raw transactions and encrypt them using an encryption key obtained from the DKG locally. Once signed and encrypted, the transaction is sent directly to the sequencer.
### Client ↔ Secure RPC ↔ Tx. Orderer
via Secure RPC
1. **Client** sends a raw transaction to Secure RPC.
2. **Secure RPC** fetches SKDE parameters and the encryption key from the Distributed Key Generation (DKG) Service.
3. **Secure RPC** encrypts the transaction.
4. **Secure RPC** sends the encrypted transaction to the Sequencer.
### Client ↔ Snap ↔ Tx. Orderer
via radius-snap
1. **Client** generates or imports a private key.
2. **Client** sends a raw transaction to the Snap.
3. **Snap** fetches skde parameters and the encryption key from the Distributed Key Generation (DKG) Service.
4. **Snap** encrypts the transaction using `.wasm`.
5. **Snap** sends the encrypted transaction to the Sequencer.
For details on **radius-snap**, refer to its [GitHub repository](https://github.com/radiusxyz/radius-snap).
# Introduction
### **The Problem**
Deploying a rollup isn’t enough—scaling sustainably is hard. Challenges include unstable revenue, high security costs, fragmented networks, liquidity struggles, and complex onboarding.
### **The Solution: Alpha Engine**
Alpha Engine provides a modular infrastructure stack with three core components:
* **Radius**: MEV capture for revenue.
* **Symbiotic**: Shared security protocol.
* **Avail**: Scalable data availability & cross-rollup interoperability.
### **Why It Matters to Rollup**
* **Earn sustainable revenue** beyond transaction fees.
* **Reduce security costs** with shared staking models.
* **Enable seamless cross-rollup interactions** via Avail Nexus.
### **Nitro Program**
Rollups integrating Alpha Engine’s components qualify for **tiered incentives** to boost TVL and adoption. Full-stack adopters receive the highest rewards.
Alpha Engine transforms rollups from just functional to **economically sustainable, secure, and interconnected.**
# Alpha Engine by Radius, Symbiotic, Avail
## **1. Introduction**
#### **1.1 The Challenge of Sustainable Rollup Growth**
Rollups have improved Ethereum’s scalability by executing transactions off-chain while maintaining Ethereum’s security. However, deploying a rollup is not enough to ensure long-term sustainability. Key challenges include:
* **Revenue Instability:** Transaction fees alone are unpredictable and insufficient.
* **High Security Costs:** Robust security requires significant capital.
* **Network Fragmentation:** Limited interoperability leads to isolated ecosystems.
* **Liquidity Barriers:** Acquiring liquidity is competitive.
* **User Onboarding Complexity:** Poor user experiences hinder adoption.
* **Diverse, Costly Infrastructure:** Selecting tailored infrastructure is challenging.
#### 1.2 What is Alpha Engine?
Alpha Engine is a modular infrastructure stack designed to support the **sustainable growth of rollups**. It integrates three key components:
* **Radius (MEV capture):**
* [Lighthouse](/overview/lighthouse/lighthouse) enables rollups to capture and internalize MEV (Maximal Extractable Value), turning it into a new revenue source beyond transaction fees.
* This revenue can incentivize users, subsidize projects, and fuel ecosystem growth.
* **Symbiotic (Shared Security Protocol):**
* [Symbiotic protocol](https://blog.symbiotic.fi/symbiotic-intro/) provides a flexible, sovereign security layer that rollups can integrate plug-and-play solution without building in-house solutions.
* Allows tailored security collaborations across networks.
* **Avail (High-Throughput Data Availability):**
* [Avail DA](https://www.availproject.org/da) supplies scalable, verifiable data availability at low costs, critical for high-throughput operations.
* [Avail Nexus](https://blog.availproject.org/the-avail-vision-accelerating-the-unification-of-web3/#avail-nexus) enables cross-chain transactions between Avail-powered rollups, enhancing interoperability, liquidity, and user onboarding by connecting fragmented ecosystems.
In addition, Symbiotic infrastructure providers (Networks) and Fuel partners of Alpha Engine contribute to delivering a comprehensive solution for economic sustainability, security, and interoperability.
***
## **2. Alpha Engine Components**
### 2.1. Radius : SBB & Lighthouse
Radius enables **rollups to capture MEV revenue** with Secure Block Building(SBB) and Lighthouse.
#### 2.1.1 [Lighthouse](/overview/lighthouse/lighthouse): Cross-rollup MEV capture
[Lighthouse](/overview/lighthouse/lighthouse) is a decentralized network that runs auctions to monetize rollup blockspace during block production. Rollups offer blockspace, and searchers bid to include MEV transactions—such as arbitrage and liquidations—that enhance market efficiency.
* **Expanded MEV Market**: Enables cross-rollup arbitrage and L1-L2 arbitrage, alongside CEX-DEX arbitrage, atomic arbitrage, and liquidations.
* **Higher Revenue**: Increases MEV opportunities to attract more searchers while auction mechanisms minimize spam, resulting in higher bids and greater rollup profits.
* **Aligned Incentives**: Distributes MEV profits between rollups and searchers through a transparent and competitive system.
{% hint style="info" %}
*Lighthouse seamlessly connects to rollups via Secure Block Building (SBB). Once rollups integrate SBB, no extra work is needed to integrate Lighthouse. This guide walks through SBB integration.*
{% endhint %}
#### **2.1.2** [**Secure Block Building (SBB)**](/overview/secure-block-building-sbb/secure-block-building-sbb)**: User-safe MEV Capture**
[Secure Block Building (SBB)](/overview/secure-block-building-sbb/secure-block-building-sbb) enhances L2 block building to capture MEV, collaborating with searchers to increase revenue.
SBB provides three key benefits:
* **More Revenue**: Works with searchers to capture MEV. This creates a flexible revenue stream that adapts to market conditions and scales with rollup adoption beyond transaction fees.
* **User Safety**: Stops harmful MEV practices like frontrunning and sandwich attacks using one-second encryption and proof generation. This keeps user transactions secure while letting rollups profit from MEV.
* **Easy Integration**: Fits into existing rollup frameworks without added complexity. It’s a simple way to increase revenue.
### 2.2 Symbiotic: Shared Security Protocol
Symbiotic is a [**shared security protocol**](https://blog.symbiotic.fi/symbiotic-intro/) that enables rollups to retain full control over their security implementations which includes management of collateral assets, operator selection, and slashing mechanisms.
Rollup developers can leverage **Symbiotic's slashable, restaked assets** to secure their rollups efficiently. By utilizing **Symbiotic network services**, developers can bring applications to market more quickly and cost-effectively. The process works as follows:
1. **User Deposits:** Users deposit funds into Symbiotic vaults.
2. **Economic Security for Rollups:** Rollup developers use these assets to secure their rollups, with slashing mechanisms in place to penalize misbehavior.
3. **Fee Distribution:** Rollups pay fees(rewards) for these services, which Symbiotic redistributes to token stakers.
#### 2.2.1 Core Participants
* **Stakers** - Entities looking to earn rewards by providing their assets as a stake through vault deposits. They can be individual token holders, institutions, or liquid (re)staking protocols. Stakers deposit funds into specialized smart contracts (vaults) managed by curators who handle delegation decisions.
* **Networks** - Systems that need economic security to operate safely. These can be Layer 1 blockchains, Layer 2 solutions, or other decentralized systems that require stake-based security guarantees. Currently, Symbiotic’s infrastructure providers(a.k.a. Networks) includes [**Radius**](https://www.theradius.xyz) and the following.
* [RedStone](https://x.com/redstone_defi), [Hyve DA](https://x.com/Hyve_DA), [Capx Cloud](https://x.com/0xCapx), [Kalypso](https://x.com/KalypsoProver), [Drosera](https://x.com/KalypsoProver), [Cycle Network](https://x.com/cyclenetwork_GO), and [Ditto](https://x.com/Ditto_Network)
* **Operators** - Professional entities that maintain network infrastructure by running validators, nodes, or other required systems. They receive stake allocations to perform their duties and are responsible for network operations.
### 2.3 Avail: Avail DA & Avail Nexus
#### 2.3.1 [Avail DA](https://blog.availproject.org/avails-core-features-explained/): Scalable Data Availability Layer
[Avail’s DA Layer](https://docs.availproject.org/docs/the-avail-trinity/avail-da?ref=blog.availproject.org) is a decentralized blockchain network. It produces and secures blockspace that other blockchains can use as their own ‘pluggable’ data availability layer.
Using a dedicated AppID, blockchains publish transaction data to Avail which gets committed and made available.
* Avail’s data availability blockchain can support any blockchain network.
* The data published on Avail’s blocks is validated by the Avail network, but not executed.
* After block finalization by validator, validity proofs guarantee immediate data availability.
* Developers and users can verify data availability independently by using validity proofs.
* Avail applies erasure encoding to published data, generating extra pieces for redundancy and ensuring recoverability even if some parts are lost.
* Avail embeds data footprints in the Avail block headers using KZG commitments.
* Avail’s nominated proof of stake (NPoS) blockchain was built using the Polkadot SDK, and it will support up to 1,000 external validators.
#### 2.3.2 [Avail Nexus](https://blog.availproject.org/the-avail-vision-accelerating-the-unification-of-web3/): Cross-Rollup Interoperability
The ability to easily spin up rollups means there will be thousands of rollups. That means, the end-user experience of interacting with these rollups will be fragmented. Blockchain user's experience already suffers in the multichain world with a few chains and by increasing the number further without having fundamental changes in composability will lead to even bigger issues. **That is why Avail is building Avail Nexus, which acts as the verification hub unifying the rollups, using Avail DA as the root of trust.**
[Avail Nexus](https://docs.availproject.org/docs/the-avail-trinity/avail-nexus?ref=blog.availproject.org) is a custom ZK coordination rollup on top of Avail that consists of:
* Proof aggregation and verification layer
* Sequencer selection/slot auction mechanism
Nexus also submits the aggregated proof periodically to Ethereum and the Avail DA layer for verification. A custom module within Avail DA verifies the aggregate proof.
#### 2.3.3 Avail Fusion
A unifying layer needs unified security. The biggest value proposition for spinning up a new rollup rather than creating a separate L1 is the ability to inherit security from the base layer. For Avail to be the web3 coordination layer, it needs to be extremely secure - as the crypto-economic guarantees along with cryptographic ones will ultimately define the Avail ecosystem.
To cater to that, we are developing [Fusion Security](https://docs.availproject.org/docs/the-avail-trinity/avail-fusion?ref=blog.availproject.org), which takes the native assets of the most mature ecosystems such as BTC, ETH and more and allows them to contribute to the Avail consensus. Not only that, it allows the new rollup tokens to also play a role in securing the base layer which empowers them.
***
## **3. Integrated System Architecture & Data Flow**
### 3.1 Architecture Overview
#### 3.1.1 Supported Rollup Stacks
| | Polygon CDK | OP Stack | Orbit | ZKSync |
| ---------- | ----------- | -------- | ----- | ------ |
| **Radius** | O | O | TBD | TBD |
| **Avail** | O | O | O | O |
Avail DA offers a plug-and-play solution compatible with all major rollup stacks, including Polygon CDK, [OP Stack](https://docs.availproject.org/docs/build-with-avail/deploy-rollup-on-avail/Optimium/op-stack), [Orbit](https://docs.availproject.org/docs/build-with-avail/deploy-rollup-on-avail/Optimium/arbitrum-nitro/overview), and [zkSync](https://docs.availproject.org/docs/build-with-avail/deploy-rollup-on-avail/Validium/zksync/zksync). Comprehensive integration guides are available for each stack.
Radius currently supports Polygon CDK and OP Stack, and integration guides are available upon request.
#### 3.1.2 Integration Options
The system can be deployed in various configurations based on project requirements:
* **Radius X Symbiotic X Avail**: Full integration with MEV capture, data availability, cross-rollup interoperability, and economic security.
* **Radius X Symbiotic**: MEV capture, and economic security without Avail DA/Nexus.
* **Symbiotic X Avail**: Data availability, cross-rollup interoperability, and economic security without MEV capture.
This document focuses on two real-world cases: **Radius X Symbiotic X Avail** and **Radius X Symbiotic**.
### 3.2 Fully Integrated System (Radius X Symbiotic X Avail)
#### 3.2.1 Radius with Symbiotic
Maximal Extractable Value (MEV) is a additional revenue source for rollups but is often harmful to users when exploited through frontrunning and sandwich attacks. A robust MEV capture model must protect users while enabling sustainable value extraction.
Radius proposes two core components to address this: SBB and Lighthouse. Among these, SBB utilizes the Symbiotic Security Protocol to support secure decentralized ordering. In this architecture:
* Vaults stake user-delegated funds to Operators, providing security to the network.
* Operators run the SBB TX Orderers, earning rewards for maintaining transaction integrity.
* Slashing mechanisms automatically penalize Operators for malicious behavior, ensuring honest participation.
Since close coordination between Operators and Vaults is essential for secure and efficient operations, contractual agreements are typically established. While Rollups can independently source both Operators and Vaults when using the Radius Network (SBB & Lighthouse), Radius also offers comprehensive support for Rollups that encounter difficulties in sourcing these components.
#### 3.2.2 Avail with Symbiotic
Integrating Symbiotic with Avail’s modular data availability network, offers [validity proofs](https://blog.availproject.org/avails-core-features-explained/#validity-proofs) and [data availability sampling](https://blog.availproject.org/avails-core-features-explained/#data-availability-sampling-das), making the launch of blockchain apps and services that are trust minimized, publicly verifiable and game theoretically robust far less complicated. It’s a powerful combination, enabling builders to sharply accelerate their go-to-market and significantly reduce development costs.
It also introduces a new class of innovative, validated services within the Avail network to provide critical services for a future built on horizontally scalable blockchains. These validated services can cover everything from custom intent networks, insurance networks, policy engines, computation engines, coprocessors, validation and sequencing services, and a whole lot more.
Symbiotic's modular architecture allows for rapid development and seamless integration with existing systems. By pairing Symbiotic with Avail's native staking mechanism, Fusion becomes truly asset agnostic, enabling a diverse range of cryptocurrencies to participate in securing the network. This approach not only strengthens the overall security by distributing risk across multiple assets but also enhances the economic resilience of the Avail ecosystem. The flexibility of Symbiotic's framework allows Fusion to dynamically adjust its security parameters based on market conditions and network requirements. This adaptability ensures that Avail can maintain optimal security levels and handle any external conditions.
Avail's integration showcases how Symbiotic can be seamlessly integrated into any protocol at any stage of development:
* **Enhancing the Fusion Security Layer**: Symbiotic enables Avail Fusion to pool different tokens, including established assets like ETH and BTC, to bolster the overall security of the Avail network.
* **Complementing the Unification Stack**: Symbiotic’s modular design allows Avail to integrate shared security exactly where it's needed, complementing the DA layer and Nexus aggregation layer.
* **Future-Proofing Security**: As Avail's ecosystem grows, Symbiotic's flexible framework can easily adapt to secure new components and include new assets.
#### 3.2.3. Data Flow Overview
1. **User Encryption**: Users encrypt transactions in-browser using Radius-provided sample code or Secure-RPC, ensuring protection from censorship, frontrunning, and reordering.
2. **Transaction Ordering**: Multiple TX Orderers provide cryptographic preconfirmation of transaction inclusion, preventing manipulation.
3. **Decryption and Execution**: The SBB Plugin requests transaction lists from TX Orderers. Transactions are decrypted using DKG-generated keys and forwarded to the Rollup Executor.
4. **Proof Aggregation and Storage**: The Executor aggregates proofs via the Avail Plugin and submits them to Avail Nexus. Proofs are stored on Ethereum and Avail DA, ensuring low-cost verification and enabling interoperability across multiple rollups.
***
## 4. Nitro Program
Nitro is an initiative designed to accelerate rollup adoption by leveraging the Alpha Engine. It enables rollups to access various ecosystem incentives, driving growth in total value locked (TVL) and user adoption.
#### **4.1 Incentive Structure**
The incentive structure is tiered based on the number of Alpha Engine cores adopted by the rollup. The three key cores are:
* **Radius: Lighthouse & SBB**
* **Symbiotic: Shared Security Protocol**
* **Avail: DA & Avail Nexus**
Rollups that adopt the full stack of Alpha Engine cores receive higher incentives, encouraging comprehensive integration and maximizing benefits for user acquisition and ecosystem growth.
#### **4.1.1 Tier Breakdown**
**Tier 1 (50% of Total Incentives)**
* **Eligibility:** Rollups using all three cores (Radius, Symbiotic, Avail).
* **Key Advantage:** Full-stack adoption leads to maximum incentives, promoting user growth and network effects.
* **Current Candidates:** Fuse, CapX, Ternoa.
**Tier 2 (30% of Total Incentives)**
* **Eligibility:** Rollups using any two cores, with the following combinations:
1. Symbiotic + Avail
2. Radius + Avail
3. Symbiotic + Radius
* **Incentive Distribution:**
* Avail supports combinations (1) and (2).
* Radius supports combinations (2) and (3).
**Tier 3 (20% of Total Incentives)**
* **Eligibility:** Rollups using only one core.
* **Incentives:** Allocated based on the specific core utilized.
#### 4.1.2 Most Optimal Case for Tier 1 Rollup
**Scenario:** A rollup utilizing all three cores (Radius, Symbiotic, Avail), integrated with Symbiotic Networks and Nucleus.
* A user of rollup will be able farm all these incentives at once by conducting two actions
1. Depositing ETH (diverse form) through Nucleus into the rollup.
2. Depositing stAvail into Rollup
* Rollup will be able to attract more users / TVL by utilizing these incentives based on their own criteria.
* Bridge, Trading Volume, Txs and etc.
* Once rollups acquire meaningful number of users / TVL, they can leverage Alpha Engine at its maximum.
* Acquire users from Incentives → Utilize Alpha Engine to provide best value → attract more users (Positive flywheel)
* Depositing ETH (diverse form) through Nucleus into the rollup.
* Depositing stAvail into Rollup
***
## 5. Real world use cases
### **5.1 Fuse : Full Integration with Radius, Symbiotic, and Avail**
[Fuse](https://www.fuse.io/) provides a blockchain-based financial infrastructure for small-to-medium-sized businesses (SMBs) and emerging markets. It is designed to improve accessibility and efficiency, particularly for those underserved by traditional financial systems.
Fuse have worked on breaking down the barriers that keep many businesses and individuals locked out of the global financial system, paving the way for a decentralized, borderless, and fair economy. The latest upgrade increases scalability, moving toward a target of 9,000 TPS to approach VISA’s transaction processing capacity in web2 environments.
Fuse utilizes the combined capabilities of **Radius**, **Symbiotic**, and **Avail**, positioning it as a **1st Tier** network in the **Nitro system**. The integration includes:
* **Radius**: By using **SBB**, Fuse captures MEV revenue through backrunning arbitrage and distributes it to its stakers.
* **Symbiotic Security Protocol**: Ensures validator integrity through staking and slashing mechanisms.
* **Avail**: **Avail DA** for efficient data availability, making zkEVM payments cheaper and more scalable.
#### **5.1.1 Data Flow Overview**
The data flow in Fuse’s L2 network mirrors the standardized process used by Tier 1 rollups, as described in Section 3.2.3.
#### 5.1.2 Incentive Flow
Symbiotic points are transferred to the Network, not directly to Rollups. In this context, they are sent to Radius, which then forwards both its own points and Symbiotic points to fuse. Since fuse is also integrated with Avail, The incentive provided by Avail will be sent to fuse as well.
### 5.2 Silicon : Integration with Radius, Symbiotic, and Ethereum L1
[**Silicon**](https://silicon.network/) is designed to address Ethereum’s scalability challenges by leveraging rollup technology. It aggregates multiple transactions off-chain and settles them on Ethereum mainnet as a single batch, thereby:
* **Increasing throughput** by processing more transactions per second.
* **Reducing gas fees** by lowering the cost per transaction.
* **Maintaining security** by inheriting Ethereum's base-layer security guarantees.
#### **5.2.1 Key Partnerships**
* **Ozys**: Provides technical expertise and development support. Ozys is known for blockchain infrastructure solutions and cross-chain protocols like Orbit Bridge.
* **Korbit**: As one of Korea’s leading crypto exchanges, Korbit’s involvement is expected to facilitate integration between Silicon and trading platforms, enhancing user access and liquidity.
#### **5.2.2 Integration with Radius and Symbiotic**
Silicon is based on Polygon CDK, and fully integrated with **Radius** and **Symbiotic**, operating as a **second-tier rollup** within the **Nitro system**. The integration includes:
* **Radius**: By using SBB, Silicon captures MEV revenue through backrunning arbitrage wㅍhile providing MEV protection and decentralized ordering through the SBB component.
* **Symbiotic Security Protocol**: Secures validator integrity via staking and slashing mechanisms.
#### **5.2.3 Data Flow Overview**
The data flow in Silicon’s L2 network mirrors the standardized process used by Symbiotic-Radius-integrated rollups:
1. **User Transaction Encryption**: Users encrypt transactions in-browser using Radius-provided sample code or Secure-RPC, ensuring protection from censorship, frontrunning, and reordering.
2. **Transaction Ordering**: Multiple TX Orderers provide cryptographic preconfirmation of transaction inclusion, preventing manipulation.
3. **Decryption and Execution**: The SBB Plugin requests transaction lists from TX Orderers. Transactions are decrypted using DKG-generated keys and forwarded to the Rollup Executor.
4. **Proof Aggregation and Storage**: The Rollup Executor generates proofs for each batch, and Proofs are stored directly on Ethereum L1.
#### 5.2.4 Incentive Flow
Symbiotic points are transferred to the Network, not directly to Rollups. In this context, they are sent to Radius, which then forwards both its own points and Symbiotic points to fuse.
***
## 6. Symbioitic Networks and Fuel Partners
### **6.1 Symbiotic Networks**
Networks are the systems that need economic security to operate safely. These can be Layer 1 blockchains, Layer 2 solutions, or other decentralized systems that require stake-based security guarantees.
Symbiotic supports diverse networks serving as essential building blocks for shared security. The Alpha Engine ecosystem is secured by Symbiotic’s infrastructure providers, which enhance rollup growth:
* [**RedStone**](https://x.com/redstone_defi): RedStone is the fastest-growing oracle in 2024, specialising in yield-bearing collateral for lending markets. Its Total Value Secured (TVS) grew from below $1bn in January to $6bn+ now.
* [**Hyve DA**](https://x.com/Hyve_DA): Hyve is the first Data Availability (DA) solution designed to power any data-intensive Layer 2s, rollups, appchains, and even Layer 1s. Fully chain- and token-agnostic, HyveDA seamlessly supports any blockchain, regardless of its settlement layer, virtual machine, or native token.
* [**Capx Cloud**](https://x.com/0xCapx) : Capx Cloud is a Symbiotic network that enables decentralized AI agent deployment, crypto-economically secured through Symbiotic protocol
* [**Kalypso**](https://x.com/KalypsoProver)**:** Kalypso by Marlin is a circuit-agnostic ZK Proof Marketplace supporting private inputs, using Symbiotic restaking to provide liveness and response times guarantees for proof generation.
* [**Drosera**](https://x.com/KalypsoProver)**:** Drosera is an automated risk management protocol for addressing any risk within the EVM (not just smart contract exploits).
* [**Cycle Network**](https://x.com/cyclenetwork_GO) : Cycle Network offers bridgeless liquidity abstraction through verifiable state aggregation, supporting all Bitcoin and EVM blockchain ecosystems and secured by Symbiotic.
* [**Ditto**](https://x.com/Ditto_Network)**:** Ditto is building a trustless execution protocol to run event driven workflows on-chain with economic guarantees from restaking protocols.
### **6.2 Fuel Partners**
Fuel partners are integral to the Alpha Engine, providing specialized infrastructure that further enhances rollup growth capabilities. Rollups can tap into these partners to strengthen key aspects of their ecosystem:
* **Swell:** Focused on security.
* **Nucleus:** Offers yield generation and liquidity solutions.
* **Ternoa IVS:** Delivers trust-minimization mechanisms.
* **Fuse:** Provides SDKs and APIs for consumer applications.
* **More:** Additional partners expanding the ecosystem's potential.
***
## 7. Conclusion
Deploying a rollup is just the first step toward building a sustainable blockchain ecosystem. Long-term success requires addressing fundamental challenges such as revenue instability, high security costs, network fragmentation, liquidity constraints, user onboarding friction, and infrastructure complexity.
By leveraging innovative solutions, rollups can overcome these barriers and create a more resilient and interconnected ecosystem:
* **Revenue Stability:** Mechanisms like backrunning from SBB and Lighthouse introduce additional revenue streams beyond volatile transaction fees.
* **Enhanced Security:** Symbiotic Shared Security enables capital-efficient protection, reducing the burden on individual rollups.
* **Interoperability & Connectivity:** Avail’s Unification Layer via Nexus and modular DA layers facilitate seamless cross-rollup communication.
* **Liquidity Efficiency:** Nucleus enhances liquidity access and yield opportunities, while Avail ensures liquidity mobility across networks.
* **Seamless User Onboarding:** Connected rollups improve user experience by abstracting complexity and simplifying interactions.
* **Optimized Infrastructure:** Alpha Engine integrates best-in-class solutions—including Avail, Radius, Symbiotic, Redstone, and others—to provide scalable, cost-effective, and modular infrastructure.
***
## 8. Get Started
Please feel free to reach out to Sunshine from Radius: Telegram (@realsunny16)
***
## 9. Additional References
* [Alpha Engine blog post](https://mirror.xyz/0x957084A1F20AB33cfA0cE07ed57F50c05954999C/tTVKHPhlqYGmzou71_7NrUvMkqT0bujMvQhW4vf4tVQ)
* [Alpha Engine by Avail](https://x.com/availproject/status/1887263843673354320?s=46)
* [Symbiotic Network Highlight: Radius Secure Block Building](https://blog.symbiotic.fi/network-highlight-radius-secure-block-building/)
* [Symbiotic Docs](https://docs.symbiotic.fi/)
* [Avail & Symbiotic Partner to Create a Unified Framework for Innovation](https://blog.availproject.org/avail-symbiotic-partner-to-create-a-unified-framework-for-innovation/?utm_source=chatgpt.com)
* [Avail's Vision: The unification layer for web3](https://blog.availproject.org/the-avail-vision-accelerating-the-unification-of-web3/)
* [Fuse Network](https://x.com/Fuse_network/status/1891888959808233841)
# Loggia Testnet with Radius AVS
Radius launches Loggia Testnet, offering decentralized sequencing for rollups. Powered by Radius AVS (Actively Validated Services) built on Eigenlayer, Loggia enables rollups to achieve censorship resistance, while economically securing sequencing liveness and block safety with restaked ETH.
Architecture Overview
A decentralized rollup includes the following components:
* Proposer: A decentralized sequencer set responsible for ordering transactions.
* Full Node: Receives and executes blocks from the proposer.
Developers can configure Radius AVS by considering the proposer's setup and the rollup block creation time. Initially, rollups must run their own full node, which includes an adapter to interact with the proposer.
# Encrypted Preconfirmations
### **Introduction**
Users are entities that submit transactions to the proposer, aiming to safeguard themselves against malicious proposers.
In the context of preventing malicious Miner Extractable Value (MEV) actions, users interact with the proposer through a sequence of steps designed to ensure transaction integrity and order. This process involves encryption techniques to protect transactions from being censored or reordered maliciously. Radius uses a cryptographic method called [Practical Verifiable Delay Encryption (PVDE)](https://ethresear.ch/t/mev-resistant-zk-rollups-with-practical-vde-pvde/12677), which relies on a time-lock puzzle to conceal transaction details until a predetermined time is reached.
User's actions before receiving order commitment
### **Receiving The Order Commitment**
1. **Generate transaction**: Users initiate the process by generating a transaction intended for submission to the proposer.
2. **Generate symmetric encryption key**: Utilizing the time-lock puzzle, a symmetric encryption key is generated. This key is specifically designed to encrypt the transaction and ensure its security until the appropriate time for decryption.
3. **Encrypt transaction**: With the symmetric key, the user encrypts the transaction. This encryption step is critical for protecting the transaction from premature exposure or manipulation.
4. **Generate zk-SNARK Proof**: To ensure that decryption is achievable and to avoid wasting proposer's resources, the user generates a zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK) proof. This proof verifies the integrity of both the time-lock puzzle and the encrypted transaction, ensuring that the transaction has not been tampered with. The proposers can independently decrypt the transaction by successfully solving the time-lock puzzle.
5. **Send Encrypted Transaction:** The user sends the encrypted transaction to the proposer, awaiting the arrival of the order before the decryption time elapses.
6. **Receive Order Commitment**: Prior to decryption, users receive an order-commitment. This commitment assures the user that their transaction's order has been preserved and will not be altered.
7. ***Optional: Send Decryption Key*****:** The user sends the decryption key to the proposer immediately upon receiving the order commitment, aiming to reduce fees.
8. ***Request and receive cryptographic proof of inclusion*****:** The user requests the Merkle Proof needed for verification of inclusion and order from the proposer.
9. ***Verify inclusion and the order of transaction*****:** The user verifies the inclusion and order of the transaction through the contract.
Once the time-lock puzzle and its corresponding zk-proof are prepared, and the transaction is encrypted, the user sends these components to the proposer. It's important to highlight that encrypting the transaction is not mandatory; users have the flexibility to submit transactions directly to the proposer in their original, unencrypted form. However, choosing to submit a transaction without encryption means that the system cannot ensure protection against Miner Extractable Value (MEV) risks. This optionality allows users to balance their need for security against MEV with their preferences for transaction processing.
#### Order Commitment
If a user receives the order-commitment before a specified time $$t$$ has elapsed, it confirms that the proposer has sequenced the transaction without decrypting it. This is due to the encryption mechanism that makes it impossible to decrypt the transaction before time $$t$$. In case the proposer attempts to reorder transactions after providing the user with this order commitment, the user has a basis to challenge such actions. The order commitment includes critical details such as the exact promised order of the transaction within the block, the partial Merkle Proof, the rollup block number, and the proposer's signature. These elements serve as evidence of the original commitment made by the proposer. How exactly the verification of the order works, will be explained in the **Claim** section.
It's important to note that users have the option to reduce transaction fees by sending the decryption key to the proposer immediately after receiving the order commitment. This action relieves the proposer of the computational resources and time needed to solve the time-lock puzzle, making the process more efficient.
### Processing of the encrypted transaction by the Proposer
#### **Importance of zk-Proof**
Encrypting the transaction and tying its decryption to a time-lock puzzle primarily **protect users** by ensuring their transactions remain confidential until a predetermined time. This mechanism safeguards against premature decryption and manipulation. The zk-proof validates the solvability of the time-lock puzzle, serving to **protect proposers**. Without this proof, proposers have no assurance the puzzle is solvable, risking excessive resource consumption and vulnerability to denial of service (DOS) attacks.
The process by which the proposer interacts with user-submitted data involves several critical steps, designed to ensure the security and efficiency of transactions. Here’s a simplified breakdown:
**Processing by the Proposer**:
1. **Receive User Data**: The proposer receives three key pieces of information from the user: the encrypted transaction, the time-lock puzzle, and the zk-proof.
2. **Validate and Verify zk-proof**: Upon receipt, the proposer verifies the zk-proof. If the proof is validated, the process proceeds.
3. **Determine Transaction Order In The Block**: The order of transactions is determined on a First-Come, First-Served (FCFS) basis.
4. **Sign The Order-Commitment**: The proposer (leader) signs the order-commitment, which contains details such as block height, transaction order, raw transaction hash, rollup type, using its private key.
5. **Provide Order Commitment to User**: Finally, the proposer sends order-commitment to the user, serving as proof of the transaction's position and integrity within the block.
6. **Solve Time-Lock Puzzle:** The leader proposer solves the time-lock puzzle to retrieve the decryption key.
7. **Decrypt The Encrypted Transaction:** The proposer decrypts the transaction using the key obtained during the previous step.
8. **Provide Block to Rollup:** The leader proposer set provides the block to the rollup operator upon request.
9. **Generate Merkle Root:** The leader proposer generates the Merkle root, which serves as the block commitment and plays a crucial role in block validation.
10. **Store the Merkle Root on L1:** The Merkle root is stored on Ethereum for trustless verification.
This structured approach ensures that transactions are processed securely, efficiently, and transparently, balancing the protection of both users and proposers.
Currently, transaction ordering is managed on a First Come First Serve (FCFS) basis. We are planning to introduce a Fee Auction mechanism in the future.
For a clearer understanding, take a look at the sequence diagram below.
Proposer Actions
### Order Verification
Order Verification with Order Commitment
#### Purpose and Structure of the Order Commitment
Each component of the order commitment serves a specific purpose:
1. **Signature**
* Ensures that the order commitment was authentically issued by the leader proposer.
2. **Block Number**
* Indicates the rollup block associated with the given transaction.
3. **Order**
* Denotes the committed index of the transaction in the upcoming block as determined by the proposer.
4. **Partial Merkle Proof**
* **Purpose**: Even though the promised index (order) of a transaction cannot be taken by any other transaction, the user lacks information about the transactions in the preceding indexes. This gap allows the proposer to potentially leave those indexes blank and insert its own transactions after decrypting the user's transaction. Such a violation would go unnoticed since the order of the user's transaction itself remains unviolated.
* **Solution**: To prevent this, the user must be provided with a commitment that includes information about the previous indexes. An unviolated block can be visualized as a Merkle Tree of transactions growing in one direction (assume to the right). The Merkle Proof for any given transaction in the subtree containing all previous transactions (to the left) will remain unchanged regardless of how large the tree grows by adding leaves to the right side.
* **Consistency**: Even though the final Merkle Proof for the given transaction will differ in the final tree, the earlier partial Merkle Proof will consist of elements that form the initial parts of the final Merkle Tree. This ensures the integrity of the transaction order and prevents the proposer from inserting unauthorized transactions.
Partial Merkle Proof vs Final Merkle Proof
#### Finalization and Verification Process
Once the block is finalized, the user requests the final Merkle Proof with the leader proposer's signature and invokes the verify function in the smart contract. This function performs the following checks:
1. **Blank Space Verification**:
* Ensures there are no blank spaces filled after the order commitment by comparing the partial Merkle Proof with the final Merkle Proof.
2. **Order Verification**:
* Confirms the order of the transaction by checking if the Merkle Root computed from the Merkle Proof matches the Merkle Root stored on L1 by the leader proposer.
### Complete Sequence Diagram
Transaction Lifecycle
# Decentralized Sequencing
**Overview**
The cryptographic approach employed by the system ensures a trustless environment for the proposer operation. However, the architecture still faces the challenge of a Single Point of Failure (SPOF). To mitigate this risk, Radius adopts a distributed proposer network. This network comprises multiple proposers operating concurrently to ensure system reliability and continuity.
**Functionality**
In the event of a proposer failure, the distributed nature of the network allows the remaining proposers to continue operations without interruption. This redundancy enhances the robustness of the system against individual node failures.
**Communication and Decision making**
To ensure efficient communication and syncing among multiple nodes, Radius adopts a leader-based decision-making process. This strategy eliminates the need for consensus regarding the order and formation of blocks. It clearly outlines the roles and duties of the proposers in the network, distinguishing between the leader and the followers.
**Key Benefits**
* **Reliability:** The distributed proposer network significantly reduces the risk associated with a single point of failure, ensuring higher system uptime.
* **Efficiency:** By eliminating the need for consensus between network members, Radius ensures efficient decision-making among proposers, leading to a swift and reliable sequencing process.
* **Scalability:** The distributed architecture allows for scalability, accommodating an increasing number of proposers as the network grows.
**Conclusion**
The implementation of a distributed proposer network represents a strategic approach to enhancing the reliability, scalability, and decision making efficiency of proposer set. This ensures that the system remains robust against failures and maintains continuous operation.
# Leader-based
The proposer entities are divided into two categories: leaders and followers. Followers are responsible for routing data to and from the leader and users, as well as synchronizing the state. Meanwhile, the leader takes on more complex tasks such as sequencing transactions into blocks, providing order commitments, signing transactions, and interacting with rollups. This method offers several advantages.
#### 1. Simplified Decision Making
* **Simplicity:** With a single leader responsible for sequencing, the system simplifies the decision-making process. This centralized approach reduces the complexity and overhead associated with achieving consensus among multiple nodes.
* **Efficiency:** Leader-based systems can implement more efficient ordering and syncing related decisions since the leader node acts as the authoritative source for sequencing. This streamlines the process of agreeing on the state of the system, as there's no need for multiple nodes to negotiate each sequence.
#### 2. Improved System Performance
* **Reduced Latency:** By centralizing the sequencing tasks, leader-based systems can often reduce communication latency. Messages do not need to traverse multiple nodes to reach a consensus, as the leader directly sequences and processes requests. However, note that the leader manages all processing, meaning its performance directly influences the overall network's functionality.
* **Optimized Throughput:** The leader can optimize sequencing and resource allocation based on the current system load and priorities, potentially improving the overall throughput of the system.
To avoid confusion, the details regarding the leader-follower interaction were not included in the previous sections. This was done to simplify the concept, allowing readers to view the proposer set as a singular entity. However, below is an overview of how leader-follower interactions are handled:
For every RPC request made to any of the followers, the request and its associated data are redirected to the leaders. This redirection mechanism is evident in the proposer's RPC methods:
The leader distributes the data to the followers to maintain a synchronized and updated state across the entire cluster. Generally, synchronization in the sequencing process involves every piece of data being propagated among the follower nodes. Syncing encrypted transactions, time-lockm puzzles, order commitments are carried out.
Leader's responsibilities
The sequence diagram illustrates the actions that are managed by the leader proposer, eliminating the need for consensus:
1. **Verification of zk-proof:** The leader proposer verifies the zk-proof.
2. **Ordering of Encrypted Transactions:** The leader proposer arranges the encrypted transactions for the upcoming block.
3. **Generating an Order Commitment:** The leader proposer creates order commitments for the encrypted transactions.
4. **Signing the Order Commitment:** The leader proposer signs the order commitments.
5. **Decrypting Transactions:**
* While single-node decryption of all transactions typically introduces overhead with PVDE, the new Single Key Delay Encryption (SKDE) mechanism resolves this issue.
* SKDE allows decryption of all transactions using a single key obtained from solving a single time-lock puzzle.
6. **Interacting with Rollup for Block Provision:** The leader proposer coordinates with the rollup to provide blocks.
7. **Generating Merkle Proofs:** The leader proposer generates Merkle proofs, which users can use to verify the order and inclusion of their transactions according to the issued order commitment.
# Liveness
A key advantage of distributed systems is their fault tolerance. In the current architecture, since the main actions depend on the leader, a robust recovery mechanism is essential. This mechanism should ensure the system's liveness by:
1. **Quick Transition to a New Leader:** Ensuring that a new leader can be quickly established if the current leader fails.
2. **Data Synchronization:** Keeping data synchronized across all nodes to maintain continuous operation even during a leader transition.
These measures ensure the system remains operational and efficient, even in the event of a leader failure.
# Leader Selection
## Leader selection
Dynamic leader selection is a crucial part of the current product to ensure the fair distribution of reward and ensure the liveness of the proposer set. Unlike the RAFT algorithm, which involves voting based leader election process, in the Eigenlayer Testnet we introduce the new algorithmic method of leader selection.
## Algorithm
**Arguments**
* **L1 Block Number**: Provides access to the instance of the proposer list stored on Ethereum for a given block number.
* **Rollup Block Number**: The number of the rollup's next block.
**Method**
1. Access the proposer list using the L1 block number.
2. Compute the index:
$$
\text{index} = (\text{rollup block number})\bmod(\text{number of elements in the proposer list})
$$
3. Determine the leader as the ***index***-th element of the proposer set.
## Corner Cases
* The rollup will provide the necessary arguments to the leader responsible for building the current block. However, if the leader proposer is unresponsive, the rollup will send the same request to any of the follower proposers. The leader for the next block will be determined in the usual manner. For the current block, the follower proposer contacted by the rollup will assume the [role of the leader](https://docs.theradius.xyz/testnet/loggia-testnet-with-radius-avs/decentralized-sequencing/liveness/pages/ESbJQd5rQb0Rr7PlfU7j#id-2.-improved-system-performance).
* Proposers must verify that the L1 block number provided by the rollup falls within a predefined block margin. This ensures that the rollup adheres to the fair leader change mechanism and prevents the rollup from using an L1 block number that would result in the same index as the previous block.
## Benefits
* **Encourages Participation**: Ensures that every proposer has an equal opportunity to become a leader and earn rewards, motivating more participants to opt in.
* **Promotes Decentralization**: Enhances decentralized sequencing even with a leader-based system. Although a single entity orders transactions for each block, the frequent rotation of leaders reduces centralization.
* **Ensures Consistent Leader Selection**: Eliminates the need for voting or trust among nodes. Since the contract block number and rollup block number are shared with all nodes, the calculation of the next leader will consistently produce the same result for everyone.
# Syncing
### Normal Operation
* A well functioning leader proposer consistently shares its state with the followers in a concurrent manner, who then synchronize their states to match that of the leader. This synchronization process ensures consistency across the network.
### Failover Operation
When the leader proposer becomes unresponsive or fails, the following process ensures continuity and proper synchronization within the system:
1. **Leader Recovery and Request**:
* Upon recovery, the leader proposer makes a request to all other proposers to check if any of them have received the "build block" request from the rollup.
2. **No Build Block Request Received**:
* If no other proposer has received the "build block" request from the rollup, the leader proposer resumes its leadership role.
3. **Build Block Request Received by Follower**:
* If another proposer has received the build block request, the recovered proposer will synchronize its block height with that of the new leader proposer, as the leadership role has been transferred to it.
This process ensures that the leader proposer can either continue its role seamlessly or synchronize appropriately with the follower to maintain the integrity and continuity of the system.
This mechanism ensures that the network remains robust and consistent, aligning the states of all nodes with the selected leader's state, whether it includes the latest transactions and commitments or necessitates a rollback to maintain network integrity.
# Block Validation
#### Block Commitment Verification Process
In this process, each follower proposer is synchronized with the encrypted transactions and their respective order commitments. This synchronization allows each proposer to build the block similarly to the leader. The following steps outline the block commitment verification process:
#### Block Commitment Verification Process Documentation
Since each follower proposer is synchronized with leader proposer's encrypted transactions and respective order commitments, this enables them to build the block similarly to the leader. The following steps outline the block commitment verification process:
1. **Initiating the Build**:
* Upon receiving the build block request, the leader proposer initiates the build function.
* The leader proposer propagates the close message to all follower proposers, prompting them to close their blocks and begin building.
2. **Submitting Block to Rollup**:
* The rollup requests a block from the leader proposer.
* The leader proposer submits the block to the rollup.
3. **Generating Block Commitments**:
* The leader proposer and follower proposers generate a block commitment based on the encrypted transactions and order commitments.
* This process occurs in parallel across all proposers.
4. **Submitting Block Commitment by Leader**:
* The leader proposer submits its block commitment to Ethereum, triggering an event that follower proposers listen to.
5. **Submitting Block Commitment by Followers**:
* The follower proposers submit their block commitments to an off-chain or on-chain solution designed to aggregate these commitments.
* In the Eigenlayer Testnet implementation, this entity is referred to as the Aggregator.
6. **Commitment Aggregation and Validation**:
* The solution aggregates commitments from all proposers.
* It validates the commitments by comparing them with the leader's block commitment through a smart contract.
* Rewards are determined based on the validation results.
This process ensures that block commitments are accurately validated.
Block Validation
**Validation Scenarios**
* **Scenario 1: Majority Coincidence**
* If the majority of the proposers' commitments coincide with the leader's commitment, the leader's commitment is considered valid.
* The leader proposer is rewarded.
* **Scenario 2: Majority Discrepancy**
* If the majority of the proposers' commitments do not coincide with the leader's commitment, the leader's commitment is considered invalid.
* The leader proposer is not rewarded.
**Assumptions**
* There is no slashing of the proposer in this flow, regardless of the result of the evaluation of block commitments.
* It is assumed that all proposers, both followers and the leader, are motivated to earn fees and thus will not act maliciously.
This process ensures that the block commitments are verified in a decentralized manner, promoting fairness and accuracy in the blockchain network.
# L1 Security
The contract deployed on Ethereum performs several critical functions for the system, including block validation, order validation, registering and deregistering proposers, and distributing rewards to the leader proposer in the case of successful block validation.
1. **Order Validation with Order Commitment**
* Using the order commitment issued by the leader proposer and the Merkle Proof, users can verify the inclusion and order of their transaction through a smart contract. This is done by computing the Merkle Root, which should match the Merkle Root stored by the leader proposer.
2. **Block Validation**
* The aggregator verifies block commitments submitted by follower proposers through a smart contract.
3. **Slashing / Reward**
* In case of failed order validation with an order commitment, the leader proposer can be slashed. Conversely, in the case of successful block validation, the leader proposer can be rewarded.
4. **Proposer Management**
* When new proposers register or deregister, or when block commitments are submitted to Ethereum, the contract notifies all entities of these events.
This structured approach ensures that all critical functions are managed efficiently, maintaining the integrity and performance of the system.
# Code References
## Encrypted Mempool
request_encrypt_tx
```rust
// RPC request for encrypting the transaction
pub async fn request_encrypt_tx(
rpc_endpoint: Endpoint,
parameter: EncryptTx,
) -> Option
```
encrypt_tx_with_zkp
```rust
pub fn encrypt_tx_with_zkp(
raw_tx: String,
time_lock_puzzle_param: TimeLockPuzzleParam,
key_validation_zkp_param: ParamsKZG,
key_validation_proving_key: ProvingKey,
encryption_zkp_param: ParamsKZG,
encryption_proving_key: ProvingKey,
) -> Result<(EncryptedTx, DecryptionKey, Option)
```
EncryptTxResponse
## Sequencer Set ↔ User
send_encrypted_tx
```rust
if do_verify_tx_with_zkp {
// zkp verification
}
match true => {
let database: Database = runtime::context().load(DB).await?;
// the rollup information is retrieved from the local database.
let rollup: Rollup = get_rollup(&database, &self.rollup_id)?;
// ...code
// the block height and the transactions order is determined
let (block_height, tx_order) = self.add_encrypted_tx().await?;
let raw_tx_hash = self.encrypted_tx.raw_tx_hash.clone();
// the decryption_offloader is passed to offload the task of decryption,
// to run it asynchronously without blocking the main execution flow.
runtime::spawn(decryption_offloader(
self.rollup_id.clone(),
block_height.clone(),
tx_order.clone(),
self.encrypted_tx.clone(),
3000,
));
// the sequencer's private key is loaded from environment
let sequencer_private_key: PrivateKey =
runtime::context().load(SEQUENCER_PRIVATE_KEY).await?;
// block height, transaction order, raw transaction hash,
// sequencer's private key and rollup type are signed with sequencer's private key
let signature = sign_for_order_commitment(
&block_height,
&tx_order,
raw_tx_hash,
sequencer_private_key,
&rollup.rollup_type,
)?;
// the order of the transaction, the block height and the signature
// is sent to the user as the pre-confirmation
Ok(SendEncryptedTxResponse {
block_height,
tx_order,
signature,
})
}
```
add_encrypted_tx
## Sequencer Set ↔ Rolup
AddRollup
```rust
pub struct AddRollup {
pub rollup_id: RollupId,
pub rollup_type: RollupType,
pub operator: Operator,
pub da_info: Option,
}
```
RollupType
```rust
pub enum RollupType {
Madara = "madara",
}
impl Default for RollupType {
fn default() -> Self {
Self::Madara
}
}
```
Operator
```rust
pub struct Operator {
address: Address,
public_key: PublicKey,
}
```
add_rollup
```rust
pub async fn add_rollup(&self) -> Result {
// loads database
match get_rollup(&database, &self.rollup_id) {
// throws an error if successful, meaning the given rollup is already registered
// or
// registers new rollup if unsuccessful by
// adding it to the list of rollups
// adding it to the database
// adding its metadata to the database
}
}
```
GetRawTxList
```rust
pub struct GetRawTxList {
pub rollup_id: RollupId,
pub block_height: Option,
pub operator_signature: Option,
}
```
GetRawTxListResponse
```rust
pub struct GetRawTxListResponse {
pub is_building_block: bool,
pub raw_tx_list: RawTxList,
}
```
get_raw_tx_list
```rust
let database: Database = runtime::context().load(DB).await?;
let rollup = get_rollup(&database, &self.rollup_id)?;
// if block_height is None, get rollup's current block height
let block_height: BlockHeight =
get_block_height(&database, &self.rollup_id, &self.block_height)?;
// ...code for checking if block_height is greater than
// rollup's current block height, return error
```
BlockMetadata
```rust
pub struct BlockMetadata {
is_decrypted_tx_info_list: Vec,
is_closed: bool,
}
```
Block
```rust
pub struct Block {
block_height: BlockHeight,
encrypted_tx_list: EncryptedTxList,
raw_tx_list: RawTxList,
sequencer_address: Address,
signature: Signature,
rollup_signature: Signature,
timestamp: Timestamp,
}
```
impl BlockMetadata
```rust
impl BlockMetadata {
pub fn increment_encrypted_tx_order(&mut self) -> TxOrder {
// implementation of FCFS ↓
// 1. gets the length of the current list, which is going to be the order of the next tx
// 2. pushes it's `false` decryption status into the decrypted_tx_info_list
// 3. returns the tx order
}
pub fn set_decypted_tx(&mut self, tx_order: &TxOrder) {
// sets the tx of order tx_order as decrypted
}
pub fn is_decryption_done(&self) -> bool {
// checks if all the transactions in the tx info list are decrypted
}
pub fn set_closed(&mut self) {
// closes the block
}
pub fn is_closed(&self) -> bool {
// checks is the block is closed
}
}
```
block is not closed
// if there was not block request from the rollup operator, the block is not closed
if !block_metadata.is_closed() {
// only the registered operator can close the block for getting raw_tx_list,
// therefore, the sequencer checks if the operator's signature is valid
// if all the validations and verifications are valid
// 1. the block is closed
// 2. the current block height is incremented
// 3. an empty metadata is set for the future block
// in any other case, an appropriate error is thrown
}
block is empty, no decrypted transactions
// 1. check if the block is empty
if block_metadata.is_decrypted_tx_info_list.is_empty() {
// if indeed there is none
// 1.1. record, timestamp, generate empty encrypted and raw transaction lists,
// 1.2. sign the block by passing the lists, timestamp, block height,
// sequencer's private key, and rollup type into the signer function
// 1.3. build the block by calling
build_block(
&database,
block_metadata,
&self.rollup_id,
&block_height,
&sequencer_address,
&block_signature,
&rollup_signature,
current_time,
);
// 1.4. return the empty raw tx list and its status of not building
return Ok(GetRawTxListResponse {
is_building_block: false,
raw_tx_list: RawTxList::default(),
});
block is not empty, all transactions are decrypted
```rust
// 2. if there are transactions, check if they all are decrypted
match block_metadata.is_decryption_done() {
// 2.1. if they are, attempt to get the raw transaction list and if successful, return it
true => match get_raw_tx_list(&database, &self.rollup_id, &block_height) {
Ok(value) => {
let get_raw_tx_list_response = GetRawTxListResponse {
is_building_block: false,
raw_tx_list: value,
};
Ok(get_raw_tx_list_response)
}
Err(error) => {
// 2.1.1 get encrypted and raw transaction lists from the db
// 2.2.2 ~ repeat 1.2, 1.3 and return the raw transaction list
Ok(GetRawTxListResponse {
is_building_block: false,
raw_tx_list,
})
}
},
}
```
block is not empty, not all transactions are decrypted
```rust
// ...code from the Case 2
// otherwise, if any encrypted transaction isn't decrypted, the sequencing layer returns
// an empty list of raw transactions along with the status is_building_block: true,
// signaling that the building block remains incomplete
false => {
Ok(GetRawTxListResponse {
is_building_block: true,
raw_tx_list: RawTxList::default(),
})
}
```
# Portico Testnet
### Overview
The Portico Testnet introduces two essential rollup functionalities: **Sequencing Liveness** and **Multi-Rollup Sequencing**. This guide helps developers understand how Radius ensures these functionalities while preserving the fundamental values of rollups.
Explore the integration of the shared sequencing layer with rollups on [Portico Testnet](https://x.com/radius_xyz/status/1765272246891974761) (closed).
### What is Sequencing Liveness?
Sequencing liveness involves the continuous processing of transactions and block production within rollups, guaranteeing uninterrupted sequencing of transactions even in the face of potential rollup disruptions or failures. This is crucial for a seamless user experience and fostering trust in rollups while preventing any transaction delays.
Before delving into how Radius ensures sequencing liveness, let's examine two key approaches it employs:
* [**Leader-Based Sequencing**](/testnet/portico-testnet/distributed-sequencing/leader-based): Radius adopts a leader-based sequencing approach enabled by the encrypted mempool. A designated sequencer node (known as the leader) takes the lead in block sequencing. Other sequencer nodes (followers) receive the sequenced block from the leader. This design choice significantly enhances block production efficiency without exposing the network to censorship or sandwich attacks*.*
* [**Pre-Confirmation Mechanism**](/testnet/portico-testnet/encrypted-mempool#pre-confirmation): The leader provides order commitment (pre-confirmations) of ordered transactions to the users before decrypting the transactions. This step prevents manipulative behavior and mitigates centralization risks*.*
### Sequencing Liveness Failure Scenarios
Two potential scenarios of sequencing liveness failures can disrupt rollup operation:
* [**Failure due to malicious users**](/testnet/portico-testnet/sequencing-layer-user#importance-of-zk-proof): Delays in the sequencer providing the block to the rollup operator may occur due to potential attacks by malicious users. Practical Verifiable Delay Encryption (PVDE) enables users to generate proofs for the decryption key, helping the sequencer in identifying transactions that might lead to decryption failures. (Refer to [*Curie Testnet*](https://docs.theradius.xyz/testnet/curie-testnet)*)*
* **Leader Failure**: Leader failure can result in interruptions during the block sequencing process
### RAFT Algorithm for Sequencing Liveness During Leader Failure
To ensure sequencing liveness during leader failure, Radius employs the RAFT algorithm for leader recovery where a new leader is elected from among the followers. This algorithm is effective for leader-based sequencing, ensuring high availability, consistency, and fault tolerance in leader election, log replication, and security.
The shared sequencing layer involves a designated leader determining the order and broadcasting transactions to the followers. The RAFT algorithm, based on the Crash Fault Tolerance (CFT) consensus algorithm, enhances broadcasting efficiency and minimizes communication overhead compared to the Byzantine Fault Tolerance (BFT) algorithm.
A modification to the RAFT algorithm ensures data consistency among followers during leader election. In the original RAFT model, followers lacked an identical view of the data. However, in our modified version, the candidate requesting votes to become a new leader must have data identical to the majority of followers. This modification ensures the block inclusion of pre-confirmations determined by a failed leader.
### [**Leader election within the RAFT Algorithm:**](/testnet/portico-testnet/distributed-sequencing/fault-tolerant#leader-election)
1. **Initial:** All nodes begin as followers.
2. **Timeout:** If a follower doesn’t receive a message from a leader or candidate during the election timeout, it transitions to a candidate state, initiating a new round.
3. **Voting Request:** The candidate sends a vote request to all nodes, including a vote for itself and its data.
4. **(Modified) Voting Process:** Nodes vote for the candidate only if their data matches the candidate's data.
5. **Leader Election:** The candidate with the majority of votes becomes the leader.
### **Sequencing Liveness in Portico Testnet**
Explore a demonstration of Sequencing Liveness on the Portico Testnet (closed).
* *Please note that the speed of interactions in the testnet has been adjusted for demonstration purposes and does not reflect the actual speed of sequencing events*
* *To view all sequencing events in real-time, refer to the* [*real-time log*](https://portico-logs.theradius.xyz/)*, which is synchronized with the visualization on the testnet*
The transaction ordering process within the shared sequencing layer involves four components: User, Leader (Sequencer), Follower (Sequencer), and Rollup.
For sequencing liveness, the leader ensures that the majority of followers receive the order commitment (pre-confirmation) before it is sent to the user. For example, with a total of 10 followers, the leader ensures at least 6 followers receive the order commitment before sending it to the user.
### Potential Scenarios in the Shared Sequencer Network
The following scenarios illustrate the diverse interactions within the shared sequencer network.
#### Scenario 1: User Receives Order Commitment from Leader
1. User submits encrypted transactions to the leader.
2. Leader orders transactions in an encrypted state.
3. Leader provides order commitment (pre-confirmation) to followers before sending it to the user.
4. Rollup operator receives the transaction list (block) from the leader.
**Scenario 2: Majority of Followers Receive Order Commitment Before User**
1. User submits encrypted transactions to an initial follower.
2. Initial follower forwards encrypted transactions to the leader.
3. Leader orders transactions in an encrypted state.
4. Leader provides order commitment to the majority of followers before sending it to the initial follower. *Example: In a set of 5 sequencers, the leader ensures order commitment to at least 3 followers before reaching the user (including itself, initial follower, and another follower).*
5. Initial follower forwards the order commitment to the user.
6. Rollup operator receives the block from the leader.
#### **Scenario 3: Leader Failure**
1. In case of leader failure, a new leader is elected among follower nodes.
2. Rollup receives the transaction list (block) from the newly elected leader.
### **Leader Election**
In the event of a leader's failure, candidates receive votes based on their latest status ([see more](/testnet/portico-testnet/distributed-sequencing/fault-tolerant#leader-election)). The eligible candidate securing the majority of votes becomes the newly elected leader. Once elected, the new leader synchronizes data with all followers, ensuring identical order commitment data across the network.
### **Vote Eligibility**
Nodes cast votes for a candidate only if the candidate's data matches theirs. This ensures the newly elected leader possesses identical order commitment data with the majority of followers to guarantee sequencing liveness for the rollup in the event of leader failure.
## Multi-Rollup Sequencing
Now that we've explored how Radius ensures sequencing liveness for rollups, let's delve into multi-rollup sequencing.
### **Overview**
*Shared* sequencing involves multiple rollups sharing the same sequencer. This sequencer sequences blocks and submits them to respective rollup operators.
To manage multiple rollups, the shared sequencer must distinguish data associated with each rollup. Using *rollup identification*, it selectively provides relevant transactions when a rollup operator requests the transaction list (block) for execution.
### [Rollup Identification](/testnet/portico-testnet/sequencing-layer-rollup#adding-a-rollup)
Rollup identification is facilitated through a unique Rollup ID assigned to each rollup, issued by the rollup itself. The rollup operator registers its address (Operator Address) with the shared sequencing layer, allowing it to associate each operator with the correct rollup.
Each rollup is assigned a unique identifier known as the **Rollup ID**, issued by the rollup itself. The rollup operator registers its address (referred to as the **Operator Address**) with the shared sequencing layer. The mapping of the Rollup ID and the Operator Address allows the shared sequencing layer to associate each operator with the correct rollup.
* **Rollup ID**: Unique identifier assigned to each rollup
* **Operator Address**: Address of the rollup node operator
* **Operator Public Key**: Public key of the rollup node operator
To identify transactions for each rollup, the leader manages the following information and provides it to the followers:
* Transaction Hash
* Rollup ID
* Block Height
* Order
* Sequencer Signature
### [Rollup Identification Process](/testnet/portico-testnet/sequencing-layer-rollup#getting-the-block-from-the-sequencing-layer)
1. **Transaction Identification**: Leader pre-determines execution order and assigns and stores the rollup identification data, including Rollup ID, Block Height, Transaction Order, and Sequencer's Signature.
2. **Block Request**: Rollup node operator requests a block (a list of transactions to be executed) from the shared sequencing layer, including Rollup ID, Operator Address, and Operator Signature.
3. **Operator Verification**: Leader verifies the node operator based on the requested data, validating the operator's signature using the rollup’s Operator Address list.
4. **Block Height Update**: After verification, the leader provides the next block height (current block height +1) as a pre-confirmation for subsequent user transactions, closing the current block height.
5. **Transaction Decryption**: Leader checks the decryption status of all transactions in the requested block. If any transactions remain undecrypted, the operator is informed that the block is still being generated. Once all transactions are decrypted, the leader provides the complete transaction list to the operator."
### **Multi-Rollup Sequencing in Portico Testnet**
Explore a demonstration of Multi-Rollup Sequencing on Portico Testnet (closed). The shared sequencer submits blocks to two rollup operators in Rollup A and B, both deployed with the [Madara](https://www.madara.build/) rollup framework.
The latest block and block times for each rollup are displayed as transactions are sequenced.
Rollup block explorer
# Introduction
This document provides a detailed explanation of the Radius shared sequencing layer, focusing on the roles of entities involved in processing transactions. The explanation is structured into sections detailing the entities involved and their interactions.
Let’s start starting with an overview of the transaction flow.
#### **User:**
1. Generates an encryption key through a time-lock puzzle and encrypts the transaction symmetrically.
2. Sends the encrypted transaction, along with the time-lock puzzle and a zero-knowledge proof (zk-proof), to the sequencer. The zk-proof ensures that the sequencer can derive the decryption key by solving the time-lock puzzle, enabling the decryption of the transaction.
#### **Sequencing Layer:**
1. Validates the zk-proof to confirm the transaction's validity.
2. Orders transactions. Transactions remain encrypted at this stage, pending decryption key access through the time-lock puzzle solution.
3. Issues an order-commitment (pre-confirmation) to the user.
4. After obtaining the decryption key by solving the time-lock puzzle, decrypts the transactions and collects them into a block according to protocol.
5. Transmits the block to the rollup operator.
#### **Rollup Operator:**
1. Acquires the block from the sequencer.
2. Executes the transactions in the specified order.
3. Based on the rollup model, either submits the updated state and state proof or a list of transactions to the settlement layer.
#### **Settlement Layer:**
1. Reviews the submitted state and state proof from the rollup, validating the proof to confirm the state.
This explanation breaks down the complex transaction process into understandable parts, showing how each component contributes to the system's overall function.
# Encrypted Mempool
## User
Users are entities that submit transactions to the rollup, aiming to safeguard themselves against malicious sequencers.
## User-Specific Actions for Secure Transaction Processing
### **Introduction**
In the context of preventing malicious Miner Extractable Value (MEV) actions, users interact with the shared sequencing layer through a sequence of steps designed to ensure transaction integrity and order. This process involves encryption techniques to protect transactions from being censored or reordered maliciously. Radius uses a cryptographic method called [Practical Verifiable Delay Encryption (PVDE)](https://ethresear.ch/t/mev-resistant-zk-rollups-with-practical-vde-pvde/12677), which relies on a time-lock puzzle to conceal transaction details until a predetermined time is reached.
User specific actions
### **Process Overview**
1. **Generate transaction**: Users initiate the process by generating a transaction intended for submission to the shared sequencing layer.
2. **Generate symmetric encryption key**: Utilizing the time-lock puzzle, a symmetric encryption key is generated. This key is specifically designed to encrypt the transaction and ensure its security until the appropriate time for decryption.
3. **Encrypt transaction**: With the symmetric key, the user encrypts the transaction. This encryption step is critical for protecting the transaction from premature exposure or manipulation.
4. **Generate zk-SNARK Proof**: To ensure that decryption is achievable and to avoid wasting sequencing layer's resources, the user generates a zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK) proof. This proof verifies the integrity of both the time-lock puzzle and the encrypted transaction, ensuring that the transaction has not been tampered with. The sequencers can independently decrypt the transaction by successfully solving the time-lock puzzle.
5. **Send Encrypted Transaction:** The user sends the encrypted transaction to the sequencing layer, awaiting the arrival of the order before the decryption time elapses.
6. **Receive Pre-Confirmation**: Prior to decryption, users receive an order-commitment. This commitment assures the user that their transaction's order has been preserved and will not be altered.
7. ***Optional: Send Decryption Key*****:** The user sends the decryption key to the sequencing layer immediately upon receiving the pre-confirmation, aiming to reduce fees.
### **Implementation in Portico Testnet**
To simulate real-world user interactions and validate the efficacy of this process, the Portico Testnet features a client bot. This bot mimics potential user actions, demonstrating the practical application and security of the transaction encryption and sequencing process.
Once the time-lock puzzle and its corresponding zk-proof are prepared, and the transaction is encrypted, the user is set to engage with the sequencing layer. It's important to highlight that encrypting the transaction is not mandatory; users have the flexibility to submit transactions directly to the sequencer in their original, unencrypted form. However, choosing to submit a transaction without encryption means that the system cannot ensure protection against Miner Extractable Value (MEV) risks. This optionality allows users to balance their need for security against MEV with their preferences for transaction processing.
* [request\_encrypt\_tx](/testnet/portico-testnet/code-references#request_encrypt_tx)
* [encrypt\_tx\_with\_zkp](/testnet/portico-testnet/code-references#encrypt_tx_with_zkp)
* [EncryptTxResponse](/testnet/portico-testnet/code-references#encrypttxresponse)
## User ↔ Sequencer
After preparing the time-lock puzzle, generating the zk-proof, and encrypting the transaction, the user proceeds to send these components to the sequencer.
* [EncryptedTx](/testnet/portico-testnet/code-references#encryptedtx)
* [SendEncryptedTx](/testnet/portico-testnet/code-references#sendencryptedtx)
### Pre-Confirmation
If a user receives the order-commitment before a specified time $$t$$ has elapsed, it confirms that the sequencer has sequenced the transaction without decrypting it. This is due to the encryption mechanism that makes it impossible to decrypt the transaction before time $$t$$. In case the sequencer attempts to reorder transactions after providing the user with this pre-confirmation, the user has a basis to challenge such actions. The pre-confirmation includes critical details such as the exact promised order of the transaction within a block, the rollup block height, and the sequencer's signature, serving as evidence of the original commitment made by the sequencer.
It's important to note that users have the option to reduce transaction fees by sending the decryption key to the sequencing layer immediately after receiving the pre-confirmation. This action relieves the sequencing layer of the computational resources and time needed to solve the time-lock puzzle, making the process more efficient.
* [SendEncryptedTxResponse](/testnet/portico-testnet/code-references#sendencryptedtxresponse)
* [provide\_decryption\_key](/testnet/portico-testnet/code-references#provide_decryption_key)
* [ProvideDecryptionKey](/testnet/portico-testnet/code-references#providedecryptionkey)
# Sequencing Layer ↔ User
The shared sequencing layer specializes in assembling blocks of transactions and submitting them to rollups. Its design ensures two key features: liveness, meaning it maintains operation even in the presence of faults (fault-tolerance), and interoperability, allowing it to work seamlessly with various systems.
#### **Importance of zk-Proof**
Encrypting the transaction and tying its decryption to a time-lock puzzle primarily **protect users** by ensuring their transactions remain confidential until a predetermined time. This mechanism safeguards against premature decryption and manipulation. The zk-proof validates the solvability of the time-lock puzzle, serving to **protect sequencers**. Without this proof, sequencers have no assurance the puzzle is solvable, risking excessive resource consumption and vulnerability to denial of service (DOS) attacks.
The process by which the shared sequencing layer interacts with user-submitted data involves several critical steps, designed to ensure the security and efficiency of transactions. Here’s a simplified breakdown:
**Processing by the Sequencing Layer**:
1. **Receive User Data**: The sequencing layer receives three key pieces of information from the user: the encrypted transaction, the time-lock puzzle, and the zk-proof.
2. **Validate and Verify zk-proof**: Upon receipt, the sequencing layer verifies the zk-proof. If the proof is validated, the process proceeds.
3. **Retrieve Rollup Information**: Essential details such as rollup information are fetched from the local database.
4. **Determine Transaction Order In The Block**: The order of transactions is determined on a First-Come, First-Served (FCFS) basis.
5. **Sign The Order-Commitment**: The sequencer (leader) signs the order-commitment, which contains details such as block height, transaction order, raw transaction hash, rollup type, using its private key.
6. **Provide Pre-Confirmation to User**: Finally, the sequencing layer sends pre-confirmation (order-commitment) to the user, serving as proof of the transaction's position and integrity within the block.
7. **Offload The Decryption**: To minimize the workload on the leader sequencer, the task of decryption is offloaded to other sequencers. This allows the decryption process to occur independently and concurrently, without impacting the main sequencer's operations.
This structured approach ensures that transactions are processed securely, efficiently, and transparently, balancing the protection of both users and sequencers.
* [send\_encrypted\_tx](/testnet/portico-testnet/code-references#send_encrypted_tx)
Currently, transaction ordering is managed on a First Come First Serve (FCFS) basis. This approach is evident in the `add_encrypted_tx` function, where the transaction order is determined by incrementing the current number of transactions in the list. We plan to introduce a Fee Auction mechanism in the future.
* [add\_encrypted\_tx](/testnet/portico-testnet/code-references#add_encrypted_tx)
For a clearer understanding, take a look at the sequence diagram below.
Sequencing layer - User interaction
# Sequencing Layer ↔ Rollup
## Adding a rollup
To begin functioning as a sequencing layer for a rollup, the initial step involves registering the rollup within the sequencing layer's list of rollups. In Radius, a rollup is defined using a specific structure, that contains rollup's id, type, and operator.
* [AddRollup](/testnet/portico-testnet/code-references#addrollup)
By default, the rollup type is set to "Madara", since, currently, Radius only supports Madara. Additional rollup types will be introduced in the future.
* [RollupType](/testnet/portico-testnet/code-references#rolluptype)
### Rollup operator's description
The rollup operator is described by its address and public\_key.
* [Operator](/testnet/portico-testnet/code-references#operator)
### Saving the rollup
The `add_rollup()` function verifies if a rollup with the specified ID already has a corresponding key in the database. If not, it adds the rollup along with its metadata to the database.
* [add\_rollup](/testnet/portico-testnet/code-references#add_rollup)
## Getting the block from the sequencing layer
Getting the block of raw transactions from the sequencing layer
After the rollup has been added to the list of rollups, sequencing can commence. The process involves the rollup initiating a request for a block of raw transactions. This is done by making an RPC call to the `get_raw_tx_list` method on the sequencing layer. The method, in response, returns a structure named `GetRawTxListResponse`.
1. **Request Structure (`GetRawTxList`):**
* This structure defines the request format for fetching raw transaction lists. It includes:
* `rollup_id`: Identifier for the specific rollup within the blockchain from which to fetch the block's transactions.
* `block_height`: An optional field specifying the height of the block for which the raw transaction list is requested. If not provided, the current block height of the rollup is used.
* `operator_signature`: An optional digital signature from the operator, potentially used for authorization or validation purposes.
2. **Response Structure (`GetRawTxListResponse`):**
* This structure outlines the format of the response to the request. It includes:
* `is_building_block`: A boolean indicating whether the block is currently in the process of being built (true) or is completed (false).
* `raw_tx_list`: The list of raw transactions from the specified block.
* [GetRawTxList](/testnet/portico-testnet/code-references#getrawtxlist)
* [GetRawTxListResponse](/testnet/portico-testnet/code-references#getrawtxlistresponse)
### Block and BlockMetadata for optimized request processing
To minimize the overhead associated with database operations, the `BlockMetadata` structure along with its traits has been implemented.
The `Block` structure holds various pieces of information including its height, lists of transactions in both encrypted and unencrypted forms, rollup signature, the address and the signature of the leader sequencer, and a timestamp marking when it was created.
The `BlockMetadata` structure keeps track of which transactions in a block have been decrypted and whether the block is open or closed for adding more transactions. It's a straightforward way to manage the state of transactions within a block and the block's overall status in the blockchain.
* [Block](/testnet/portico-testnet/code-references#block)
* [BlockMetadata](/testnet/portico-testnet/code-references#blockmetadata)
* [Methods of BlockMetadata](/testnet/portico-testnet/code-references#impl-blockmetadata)
The `BlockMetadata` structure is designed to manage transactions within a block, focusing on their encryption status and the block's availability for adding new transactions. It includes functionality to add new encrypted transactions and mark them as decrypted over time. Additionally, it can check if all transactions have been decrypted and manage the block's open or closed status, indicating whether new transactions can be added. Essentially, it's a system for overseeing transaction processing and ensuring the block moves from an active state, where transactions are being processed, to a finalized state, where all transactions are decrypted and the object returned to rollup is determined.
### Possible states of block formation
When the rollup operator requests a block, the sequencing layer verifies several conditions, including the operator's credentials, before closing the block by setting `is_closed` to true.
Initially, it checks if a block is already closed. If the block is still open, the system then ensures that only a recognized operator can initiate the closure by verifying the operator's signature. If the signature is verified along with all other required validations, three actions are taken: the block is closed, the blockchain's current height is increased to account for the addition of the newly closed block, and a new, empty metadata structure is prepared for the next block. If any validation fails, the system will halt the process and report an error. This mechanism ensures that blocks are closed securely and orderly, preparing the blockchain for subsequent blocks.
* [if the block is not closed](/testnet/portico-testnet/code-references#block-is-not-closed)
Once the block is closed, three specific cases are checked to determine the return value to the rollup.
### Case 1: No decrypted transactions
When a block is closed, the system evaluates the transactions to determine the appropriate response for the rollup process. Here's a simplified explanation for the first case scenario:
If there are no decrypted transactions present, the system first checks if the transaction list within the block metadata is empty. If it finds no transactions:
1. It records the current state, noting the absence of transactions. It then creates empty lists for both encrypted and raw transactions.
2. The block is signed. This involves taking the empty transaction lists, the current timestamp, the block's height, the sequencer's private key, and the type of rollup, and passing them to a function designed to officially sign the block.
3. A new block is constructed. This step involves calling a `build_block` function with several parameters, including the database, block metadata, rollup ID, block height, sequencer address, and the signatures obtained from the previous step, along with the current time.
4. Finally, the process returns a response indicating that the block is not in the process of being built and includes the default (empty) raw transaction list.
In essence, this scenario deals with the situation where a closed block contains no decrypted transactions, outlining the steps to officially close and sign off the block while preparing for future transactions.
* [empty block, no decrypted txs](/testnet/portico-testnet/code-references#block-is-empty-no-decrypted-transactions)
### Case 2: All transactions are decrypted
\
In this part of the code, the process checks for the presence and decryption status of transactions in a block once it is closed. Here's the simplified flow:
1. The system checks if all transactions in the block have been decrypted.
2. If all transactions are decrypted:
* It attempts to retrieve the raw transaction list from the database. If successful, this list is returned as part of the response, indicating that the block is not currently being built, and provides the raw transaction list directly.
3. In case of an error while retrieving the raw transaction list:
* The system fetches both encrypted and raw transaction lists from the database.
* It follows a similar procedure to record, timestamp, generate transaction lists, and sign the block, similar to the process outlined in the first case.
* After these steps, it returns the raw transaction list in the response, indicating again that the block is not being built.
This process ensures that, for blocks with decrypted transactions, an attempt is made to fetch and return the raw transaction list directly. If there's an issue in fetching this list, the block is processed similarly to the case of an empty block, ensuring that the transactions are recorded, signed, and a response is provided.
* [all transactions are decrypted](/testnet/portico-testnet/code-references#block-is-not-empty-all-transactions-are-decrypted)
### Case 3: Not all transactions are decrypted
In this continuation, the focus is on handling the scenario where not all transactions within the block are decrypted after it has been closed. Here's what happens:
* If it's determined that any of the transactions remain encrypted, meaning not every transaction has been decrypted successfully, the system takes a different approach compared to when all transactions are decrypted.
* Instead of proceeding with building the block or fetching raw transactions from the database, the system acknowledges that the block cannot be completed at this moment. This is due to the presence of encrypted transactions that haven't been decrypted yet.
* To reflect this, the system returns a response indicating that the block is still in the process of being built (`is_building_block: true`). This response also includes an empty list for the raw transactions (`raw_tx_list: RawTxList::default()`), signaling that, without all transactions decrypted, the block's construction isn't finalized.
Essentially, this part deals with the situation where the block remains incomplete due to undecrypted transactions, informing the rollup process that the block is still under construction and not ready for finalization.
* [not all transactions are decrypted](/testnet/portico-testnet/code-references#block-is-not-empty-not-all-transactions-are-decrypted)
This finalizes the sequencing layer's interaction with the rollup's operator.
# Distributed Sequencing
**Overview**
The cryptographic approach employed by the system ensures a trustless environment for the sequencer operation. However, the architecture still faces the challenge of a Single Point of Failure (SPOF). To mitigate this risk, Radius adopts a distributed sequencer network. This network comprises multiple sequencers operating concurrently to ensure system reliability and continuity.
**Functionality**
In the event of a sequencer failure, the distributed nature of the network allows the remaining sequencers to continue operations without interruption. This redundancy enhances the robustness of the system against individual node failures.
**Communication and Decision making**
To ensure efficient communication and syncing among multiple nodes, Radius adopts a leader-based decision-making process grounded in the RAFT algorithm. This strategy eliminates the need for consensus regarding the order and formation of blocks. It clearly outlines the roles and duties of the sequencers in the network, distinguishing between the leader and the followers.
**Key Benefits**
* **Reliability:** The distributed sequencer network significantly reduces the risk associated with a single point of failure, ensuring higher system uptime.
* **Efficiency:** By leveraging a modified RAFT algorithm, Radius ensures efficient decision making mechanisms among sequencers, facilitating swift and reliable sequencing state.
* **Scalability:** The distributed architecture allows for scalability, accommodating an increasing number of sequencers as the network grows.
**Conclusion**
The implementation of a distributed sequencer network, complemented by a modified RAFT algorithm, represents a strategic approach to enhancing the reliability, scalability, and decision making efficiency of Radius. This ensures that the system remains robust against failures and maintains continuous operation.
# Leader-based
The RAFT algorithm divides entities into two categories: leaders and followers. Followers are responsible for routing data to and from the leader and users, as well as synchronizing the state. Meanwhile, the leader takes on more complex tasks such as sequencing transactions into blocks, providing preliminary confirmations, signing transactions, and interacting with rollups. This method offers several advantages.
#### 1. Simplified Coordination and decision making
* **Simplicity:** With a single leader responsible for sequencing, the system simplifies the decision-making process. This centralized approach reduces the complexity and overhead associated with achieving consensus among multiple nodes.
* **Efficiency:** Leader-based systems can implement more efficient ordering and syncing related decisions since the leader node acts as the authoritative source for sequencing. This streamlines the process of agreeing on the state of the system, as there's no need for multiple nodes to negotiate each sequence.
#### 2. Improved System Performance
* **Reduced Latency:** By centralizing the sequencing tasks, leader-based systems can often reduce communication latency. Messages do not need to traverse multiple nodes to reach a consensus, as the leader directly sequences and processes requests. However, note that the leader manages all processing, meaning its performance directly influences the overall network's functionality.
* **Optimized Throughput:** The leader can optimize sequencing and resource allocation based on the current system load and priorities, potentially improving the overall throughput of the system.
To avoid confusion, the details regarding the leader-follower interaction were not included in the previous sections. This was done to simplify the concept, allowing readers to view the sequencing layer as a singular entity. However, below is an overview of how leader-follower interactions are handled:
For every RPC request made to any of the followers, the request and its associated data are redirected to the leaders. This redirection mechanism is evident in the sequencer's RPC methods:
* [forwarding to the leader](/testnet/portico-testnet/code-references#forwarding-to-the-leader)
The leader distributes the data to the followers to maintain a synchronized and updated state across the entire sequencing layer. Generally, synchronization in the sequencing process involves every piece of data being propagated during the follower RAFT nodes. For the `RaftNode` structure, syncing encrypted transactions, syncing raw transactions, syncing block, and syncing block metadata implementations are carried out.
* [requesting followers to sync](/testnet/portico-testnet/code-references#request-from-followers-to-sync)
Follower ↔ Leader communication
# Fault-tolerant
A key advantage of distributed systems is their fault tolerance. In the Radius sequencing layer, because the main actions requiring consensus depend on the leader, there needs to be a robust mechanism in place. This mechanism should ensure the system's liveness by quickly recovering a new leader and synchronizing the data across the other nodes to maintain continuous operation even in the event of a leader failure.
### There are cases of transaction flow:
#### Case 1: Normal flow
Well-functioning leader
#### Case 2: Failed to deliver order commitment to majority of the followers
Fail before syncing with majority
#### Case 3: Failed after successfully delivering the order commitment to the majority of the followers
Fail after syncing with majority
## Leader election
In scenarios where the leader fails, rapid recovery and election of a new leader are critical. Unlike the original RAFT algorithm, which primarily considers the terms of the candidates in the leader election process, Radius introduces an additional significant factor: the state containing order-commitments.
Here's how the leader election process works in Radius when a leader fails:
1. **Transitioning to the candidate state**: The node that times out first declares itself as a candidate and solicits votes from other nodes.
2. **Vote Request and Comparison**: When a node receives a vote request, it compares its own state with that of the requesting node's state.
* **If the states match**, the node resets its own timeout and casts its vote for the requesting node.
* **If the states do not match**, the node abstains from voting. Upon reaching its own timeout, it then declares itself as a candidate and the process starts over from step 1.
3. **Leader election**: The node that secures more than half of the votes becomes the leader and periodically sends out heartbeats to indicate its active status.
4. **Heartbeat Reception and Timeout Reset**: Nodes receiving heartbeats verify their leader status and reset their timeouts accordingly.
This enhanced election process in Radius ensures that the system can quickly recover from leader failures while taking into account the synchronization of order-commitments, thereby maintaining the integrity and continuity of the distributed system.
This mechanism ensures that only candidates who share the majority's common state can assume leadership. This is crucial because user protection is a top priority for Radius. Consequently, the selection of a new leader indirectly depends on whether users have received their order-commitments. To achieve this, Radius has put a specific strategy in place.
The process involves the leader signing the order-commitment and distributing it to half of the nodes before it reaches the user. This approach can lead to two potential scenarios in the event of the leader's failure:
1. **Leader Fails After Distribution Completion**:
* The order-commitment has been disseminated among the majority of followers and the user. Consequently, only a candidate who has received the most current order-commitment will be eligible for leadership. This ensures continuity and acknowledges the transactions that have been adequately communicated.
2. **Leader Fails Before Distribution Completion**:
* The order-commitment could not be circulated among the majority of followers nor the user. In this case, only a candidate lacking the latest order-commitment will ascend to leadership. This precaution ensures that no user's transaction is incorporated into the block without the user's acknowledgment of their order.
This mechanism safeguards the integrity of transactions and user notifications, ensuring that the system remains transparent and reliable even amidst leadership transitions. The following image illustrates the process of electing a leader:
State based voting
Every node can vote for a candidate that matches its own data state. Consequently, the only node that can become the leader is the one that aligns with the majority's data state, as it will receive the majority of votes. In the given scenario, nodes possessing the most recent encrypted transaction and order commitment are eligible for a maximum of 3 votes, indicated by blue arrows. On the other hand, nodes lacking this information can receive a maximum of 2 votes, denoted by red arrows.
## Syncing
Upon the election of a leader, it shares its state with the followers, who then synchronize their states to match that of the leader. This synchronization process ensures consistency across the network:
1. **If the Leader Has the Latest Transactions and Order-Commitments**: Followers update their states to reflect the leader's state, ensuring that the entire network is consistent and up-to-date with the latest transactions and commitments.
Case 1: Order commitment has been shared among the majority
2. **If the Leader Lacks the Latest Transactions and Order-Commitments**: Followers disregard the most recent transaction and order-commitment information received from the leader. This step is crucial to maintain the integrity of the network, ensuring that only verified and acknowledged transactions are processed and included in the block.
Case 2: Order commitment has not been shared among the majority
This mechanism ensures that the network remains robust and consistent, aligning the states of all nodes with the elected leader's state, whether it includes the latest transactions and commitments or necessitates a rollback to maintain network integrity.
# Code References
## Encrypted Mempool
request_encrypt_tx
```rust
// RPC request for encrypting the transaction
pub async fn request_encrypt_tx(
rpc_endpoint: Endpoint,
parameter: EncryptTx,
) -> Option
```
encrypt_tx_with_zkp
```rust
pub fn encrypt_tx_with_zkp(
raw_tx: String,
time_lock_puzzle_param: TimeLockPuzzleParam,
key_validation_zkp_param: ParamsKZG,
key_validation_proving_key: ProvingKey,
encryption_zkp_param: ParamsKZG,
encryption_proving_key: ProvingKey,
) -> Result<(EncryptedTx, DecryptionKey, Option)
```
EncryptTxResponse
## Sequencing Layer ↔ User
send_encrypted_tx
```rust
if do_verify_tx_with_zkp {
// zkp verification
}
match true => {
let database: Database = runtime::context().load(DB).await?;
// the rollup information is retrieved from the local database.
let rollup: Rollup = get_rollup(&database, &self.rollup_id)?;
// ...code
// the block height and the transactions order is determined
let (block_height, tx_order) = self.add_encrypted_tx().await?;
let raw_tx_hash = self.encrypted_tx.raw_tx_hash.clone();
// the decryption_offloader is passed to offload the task of decryption,
// to run it asynchronously without blocking the main execution flow.
runtime::spawn(decryption_offloader(
self.rollup_id.clone(),
block_height.clone(),
tx_order.clone(),
self.encrypted_tx.clone(),
3000,
));
// the sequencer's private key is loaded from environment
let sequencer_private_key: PrivateKey =
runtime::context().load(SEQUENCER_PRIVATE_KEY).await?;
// block height, transaction order, raw transaction hash,
// sequencer's private key and rollup type are signed with sequencer's private key
let signature = sign_for_order_commitment(
&block_height,
&tx_order,
raw_tx_hash,
sequencer_private_key,
&rollup.rollup_type,
)?;
// the order of the transaction, the block height and the signature
// is sent to the user as the pre-confirmation
Ok(SendEncryptedTxResponse {
block_height,
tx_order,
signature,
})
}
```
add_encrypted_tx
## Sequencing Layer ↔ Rolup
AddRollup
```rust
pub struct AddRollup {
pub rollup_id: RollupId,
pub rollup_type: RollupType,
pub operator: Operator,
pub da_info: Option,
}
```
RollupType
```rust
pub enum RollupType {
Madara = "madara",
}
impl Default for RollupType {
fn default() -> Self {
Self::Madara
}
}
```
Operator
```rust
pub struct Operator {
address: Address,
public_key: PublicKey,
}
```
add_rollup
```rust
pub async fn add_rollup(&self) -> Result {
// loads database
match get_rollup(&database, &self.rollup_id) {
// throws an error if successful, meaning the given rollup is already registered
// or
// registers new rollup if unsuccessful by
// adding it to the list of rollups
// adding it to the database
// adding its metadata to the database
}
}
```
GetRawTxList
```rust
pub struct GetRawTxList {
pub rollup_id: RollupId,
pub block_height: Option,
pub operator_signature: Option,
}
```
GetRawTxListResponse
```rust
pub struct GetRawTxListResponse {
pub is_building_block: bool,
pub raw_tx_list: RawTxList,
}
```
get_raw_tx_list
```rust
let database: Database = runtime::context().load(DB).await?;
let rollup = get_rollup(&database, &self.rollup_id)?;
// if block_height is None, get rollup's current block height
let block_height: BlockHeight =
get_block_height(&database, &self.rollup_id, &self.block_height)?;
// ...code for checking if block_height is greater than
// rollup's current block height, return error
```
BlockMetadata
```rust
pub struct BlockMetadata {
is_decrypted_tx_info_list: Vec,
is_closed: bool,
}
```
Block
```rust
pub struct Block {
block_height: BlockHeight,
encrypted_tx_list: EncryptedTxList,
raw_tx_list: RawTxList,
sequencer_address: Address,
signature: Signature,
rollup_signature: Signature,
timestamp: Timestamp,
}
```
impl BlockMetadata
```rust
impl BlockMetadata {
pub fn increment_encrypted_tx_order(&mut self) -> TxOrder {
// implementation of FCFS ↓
// 1. gets the length of the current list, which is going to be the order of the next tx
// 2. pushes it's `false` decryption status into the decrypted_tx_info_list
// 3. returns the tx order
}
pub fn set_decypted_tx(&mut self, tx_order: &TxOrder) {
// sets the tx of order tx_order as decrypted
}
pub fn is_decryption_done(&self) -> bool {
// checks if all the transactions in the tx info list are decrypted
}
pub fn set_closed(&mut self) {
// closes the block
}
pub fn is_closed(&self) -> bool {
// checks is the block is closed
}
}
```
block is not closed
// if there was not block request from the rollup operator, the block is not closed
if !block_metadata.is_closed() {
// only the registered operator can close the block for getting raw_tx_list,
// therefore, the sequencer checks if the operator's signature is valid
// if all the validations and verifications are valid
// 1. the block is closed
// 2. the current block height is incremented
// 3. an empty metadata is set for the future block
// in any other case, an appropriate error is thrown
}
block is empty, no decrypted transactions
// 1. check if the block is empty
if block_metadata.is_decrypted_tx_info_list.is_empty() {
// if indeed there is none
// 1.1. record, timestamp, generate empty encrypted and raw transaction lists,
// 1.2. sign the block by passing the lists, timestamp, block height,
// sequencer's private key, and rollup type into the signer function
// 1.3. build the block by calling
build_block(
&database,
block_metadata,
&self.rollup_id,
&block_height,
&sequencer_address,
&block_signature,
&rollup_signature,
current_time,
);
// 1.4. return the empty raw tx list and its status of not building
return Ok(GetRawTxListResponse {
is_building_block: false,
raw_tx_list: RawTxList::default(),
});
block is not empty, all transactions are decrypted
```rust
// 2. if there are transactions, check if they all are decrypted
match block_metadata.is_decryption_done() {
// 2.1. if they are, attempt to get the raw transaction list and if successful, return it
true => match get_raw_tx_list(&database, &self.rollup_id, &block_height) {
Ok(value) => {
let get_raw_tx_list_response = GetRawTxListResponse {
is_building_block: false,
raw_tx_list: value,
};
Ok(get_raw_tx_list_response)
}
Err(error) => {
// 2.1.1 get encrypted and raw transaction lists from the db
// 2.2.2 ~ repeat 1.2, 1.3 and return the raw transaction list
Ok(GetRawTxListResponse {
is_building_block: false,
raw_tx_list,
})
}
},
}
```
block is not empty, not all transactions are decrypted
```rust
// ...code from the Case 2
// otherwise, if any encrypted transaction isn't decrypted, the sequencing layer returns
// an empty list of raw transactions along with the status is_building_block: true,
// signaling that the building block remains incomplete
false => {
Ok(GetRawTxListResponse {
is_building_block: true,
raw_tx_list: RawTxList::default(),
})
}
```
## Leader-based
forwarding to the leader
```rust
/*
The following code can be found in all of the methods, such as:
add_raw_tx, add_rollup, get_block_metadata, get_block, get_current_block_height,
get_encrypted_tx_list, get_encrypted_tx, get_raw_tx_list, get_raw_tx,
get_rollup_list, get_rollup, provide_decryption_key, send_encrypted_tx, send_raw_tx
*/
fn method_name() -> &'static str {
// method's name
}
async fn handler(self) -> Result {
match is_leader().await? {
true => {
// perform leader's actions and send syncing proposal message to the
// if needed follower's
}
false => forward_to_leader(self).await,
}
}
```
request from followers to sync
```rust
RaftNode::send_proposal_message(...).await?;
```
```rust
RaftNode::sync_encrypted_txs(
&raft_endpoint_list,
rollup_id,
&merged_rollup_snapshot.rollup.current_block_height,
&merged_rollup_snapshot.block_metadata,
)
.await?;
RaftNode::sync_raw_txs(
&raft_endpoint_list,
rollup_id,
&merged_rollup_snapshot.rollup.current_block_height,
&merged_rollup_snapshot.block_metadata,
)
.await?;
RaftNode::sync_block(
&raft_endpoint_list,
rollup_id,
&BlockHeight::from(block_height),
)
.await?;
RaftNode::sync_block_metadata(
&raft_endpoint_list,
&rollup_id,
&block_height,
)
.await
```
# Curie Testnet
### **Overview**
In November 2023, Radius launched its first testnet: Curie.
This testnet is a resource for rollup developers looking to integrate a decentralized shared sequencing layer. Curie features the encrypted mempool, a foundational feature of Radius. The encrypted mempool utilizes a cryptographic zero-knowledge scheme is used to encrypt transactions, providing an effective solution for censorship and harmful MEV resistance caused by centralized sequencers on rollups.
As part of the Curie Testnet, testers can engage with a decentralized exchange interface, offering a firsthand experience of encrypted mempool-based sequencing and pre-confirmations for transactions.
### **Build with Radius**
We are prepared to support rollups networks and applications with the encryption sequencing module, as demonstrated in this testnet. The upcoming version of our testnet, scheduled for Q1 2024, will focus on additional features like block building, transaction order validation, and liveness with leader election, with rollup integration(s).
If you are working on a rollup network or application developer and interested in achieving decentralization, get in touch with us on [Twitter](https://twitter.com/radius_xyz).
# Encrypted Mempool
### **Encrypted Mempool for Trustless Sequencing**
Radius introduces a unique encrypted mempool solution for decentralization through trustless sequencing.
In this trustless sequencing model, transactions remain encrypted, keeping them encrypted from the sequencer until their order is determined. This approach ensures a fully trustless process, distinguishing it from traditional encrypted mempools where users must trust sequencers.
Here's a breakdown of the transaction handling process:
1. **Encryption**: Transactions are encrypted using a timelock puzzle.
2. **Order Commitment:** The sequencer determines the order of encrypted transactions for inclusion in the next block and issues an order commitment.
3. **Decryption**: The sequencer solves the timelock puzzle to decrypt the transactions.
4. **Sequencing**: Following the commitment, the sequencer constructs the block according to the predetermined order.
For details, refer to [encrypted mempool](https://docs.theradius.xyz/developer/encrypted-mempool) in the documentation.
### **Encrypted Mempool Open Source for Madara**
[Madara](https://www.madara.build/) is an open-source rollup stack for building scalable, modular Starknet appchains or L3. Madara plays a crucial role in the Starknet ecosystem as it allows for everyone to easily deploy their customized chains on top of Starknet.
Last year, we have open-source the encrypted mempool development for Madara stack. The introduction of the encrypted mempool for Madara is pivotal towards achieving decentralization in rollups. We invite Starknet and Madara developers to explore our open-sourced code on [GitHub](https://github.com/radiusxyz/madara) and refer to the guidelines on [ReadMe](https://github.com/radiusxyz/madara/blob/encrypted-mempool/docs/getting-started-with-encrypted-mempool.md) for using the encrypted mempool.
We are actively building the shared sequencing layer, built upon the foundation of the Radius encrypted mempool including trustless encryption. Our first testnet [Curie](https://twitter.com/radius_xyz/status/1722570451237634049?s=20), demonstrated a successful implementation and functionality of the encrypted mempool.
Refer to our [blog](https://mirror.xyz/0x957084A1F20AB33cfA0cE07ed57F50c05954999C/I77x90l_fyMjSnKjPuFtPymy153xlQXTjCeboQd08vA) for further details.
# Testnet Guide
### Getting Started
This guide will walk you through the process of interacting with Curie Testnet.
To get started, make sure you have MetaMask installed, added the Polygon Mumbai Network, and test tokens in your wallet.
1. **Install MetaMask:** Install the [MetaMask](https://MetaMask.io/) wallet extension in your browser.
2. **Add Network:** For this testnet, we use Polygon Mumbai Network.
1. In MetaMask, click on the network selection icon in the upper left corner and choose `Add network`.
2. Select `Add a network manually`.
3. Enter the following fields and click `Save`.
* Network Name: **Matic Mumbai**
* New RPC URL:
* Chain ID: **80001**
* Currency Symbol: **MATIC**
* Block Explorer URL:
4. Once added successfully, you will be switched to Polygon Mumbai Network.
### Request **and Add Testnet Tokens**
1. **Requesting Testnet Tokens**: To request testnet tokens, submit your MetaMask wallet address using this [form](https://7r9olam1w6v.typeform.com/to/k3fkrwY6). We will send you a set of test tokens: CI and DIA.
2. **Adding CI and DIA Test Tokens to MetaMask:** On MetaMask, click `+ Import Tokens`.
Enter the following fields:
Token contract address: **0x0B9373fe8F12df3bBE2342336a20C4D26cb695F2**
Token symbol: **CI**
Token contract address: **0xB5D73C9864223197AD8A1de1e743064D340670c7**
Token symbol: **DIA**
Once added, you should see the tokens listed in your wallet. Please allow up to 24 hours to receive your tokens via the faucet. Happy testing!
###
### Start Testing
To begin testing, follow these steps:
1. Visit the Testnet page.
2. Connect your MetaMask wallet.
3. Select either CI or DIA token and enter a swap amount. Make sure the entered amount is less than your token balance.
4. Select the other token and `Request approval`. Sign on MetaMask to approve.
5. Once approved, go back to Curie then click `Swap`. Sign again on MetaMask.
6. While the swap is processing, you'll see a **round and order number** (See Image). This indicates where the transactions will be placed in the bundle.
7. After the swap is completed, a green check mark will pop up in the bottom right corner. Head to **History** and **Completed** section, where you can confirm the same commitment number was processed as promised.
### **Trustless Sequencing and Fast Pre-confirmation**
Users encrypt transactions to prevent the sequencer from manipulating the transaction order. To ensure a secure and trustless process, we use cryptography and zero-knowledge proofs to verify the integrity of the encryption.
The **round** and **order numbers** shown indicate where the transactions will be placed in the bundle for fast pre-confirmations and transaction inclusion guarantee in the order determined by the sequencer.
To verify that the transactions were ordered properly, we suggest having multiple testers swap simultaneously and checking each other’s order numbers.
We also have a demonstration of how proofs are submitted to DA layer in this [video demo](https://twitter.com/radius_xyz/status/1659582423053783042), reducing data availability costs for transaction order validation.