Spicenet is an optimistic sovereign rollup built on Celestia and designed specifically for the PepperDEX derivatives exchange. It uses the Sovereign SDK, which allows developers to create rollups on various data availability layers like Celestia, Solana, and Bitcoin.
Spicenet prioritizes speed and reliability with a goal of achieving soft confirmation times under 1ms and end-to-end latency between 30â200ms for users.
This article will explore Spicenetâs design choices, architecture, community airdrop and research efforts.
Spicenet is a sovereign rollup, distinguishing it from the more common âsettled rollupsâ like Arbitrum, Optimism, and zkSync. This distinction lies in how the canonical chain of the rollup is determined:
Settled rollups: The base layer determines the canonical chain. While this approach inherits the security of the base layer, it also ties the rollup to the rules and consensus of that base layer. Essentially, settled rollups outsource settlement, data availability, and consensus to the base layer, retaining control only over execution. They cannot independently hardfork and must follow the base layerâs upgrades.
Sovereign rollups: The rollupâs full nodes, representing its social consensus, determine the canonical chain. This allows the rollup to manage its own settlement, relying on the base layer solely for consensus and data availability. While inheriting the censorship and re-org resistance of the DA layer, sovereign rollups enjoy greater freedom and can execute hardforks independent of the base layer.
Sovereign rollups offer a more decentralized and flexible approach where the rollup community dictates its evolution and governance.
The sovereign rollup construction also presents advantages in interoperability. Settled rollups need to prove their state to the base layer (a costly process) to interact with other rollups, while sovereign rollups can directly interact using light clients or ZK proofs. This streamlines interoperability, reduces latency, and improves the user experience.
Spicenet utilizes Celestia as its data availability (DA) layer, opting not to rely on the Solana L1 for this purpose. Celestia offers a specialized service dedicated to providing DA for rollups. Hereâs why Celestia was chosen:
Proven Stability and Reliability: Celestia has been operational on mainnet for over six months, giving it a track record of stability and reliability compared to newer DA layers like EigenDA and Avail.
High Bandwidth and Low Fees: Celestia boasts high data bandwidth and sustainably low fees. This is crucial for Spicenetâs high-performance requirements, ensuring efficient and cost-effective data storage and retrieval.
Congestion-Free Environment: As a dedicated DA layer without a virtual machine, Celestia avoids the congestion often found on general-purpose L1s like Solana.
Data Availability Sampling (DAS): Celestiaâs potential use of DAS further enhances security. DAS enables rollup nodes to verify the DA layerâs state securely, contributing to the overall robustness of the system.
Spicenet has deliberately chosen a VM-less design, meaning it does not rely on a virtual machine like the EVM or WASM to execute transactions. This decision stems from Spicenetâs focus on application-specific optimization for the PepperDEX exchange. Hereâs why this approach is beneficial:
Eliminating Unnecessary Overhead: VMs introduce overhead by compiling instructions to native code. By bypassing the VM layer, Spicenet avoids this overhead and maximizes performance.
Leveraging Native Rust Performance: Spicenetâs application logic is written in pure Rust, compiled using traditional Rust tools, and implemented as âmodulesâ. This provides direct access to native code execution, offering greater efficiency and performance.
Simplified Development: The VM-less approach simplifies the development process, allowing developers to work with familiar Rust tools and avoid the intricacies of smart contract languages.
Spicenet implements asynchronous execution, separating the transaction flow and increasing efficiency. This is inspired by L1s like Monad and Solana, where asynchronous execution either exists or is being explored.
How it works:
Decoupling Consensus and Execution: In traditional rollup designs, pre-confirmations are only given after transactions are executed and a batch is prepared. Asynchronous execution allows nodes to reach consensus first without executing transactions. This is possible because execution is deterministic, meaning the result is always the same given a specific order of transactions.
Pipelining Execution and Batching: The sequencer can execute older transactions while simultaneously ordering and batching newer transactions. This âpipeliningâ significantly increases the execution budget of the sequencer, enabling higher throughput and reduced latency.
Scalability Boost: The sequencer is no longer bound to execute every transaction immediately, allowing it to handle a much larger volume of transactions.
Latency Reduction: By separating execution from the critical path, pre-confirmation times are significantly reduced.
Simplified Transaction Flow: The overall transaction flow becomes simpler and more efficient, leading to a smoother user experience.
Despite its advantages, asynchronous execution introduces certain challenges:
1. Resource Pricing:
Problem: As transactions are not executed instantly, invalid transactions may not pay the full gas cost for the resources they consume. This can lead to imbalances and potential spamming with invalid transactions.
Solution: Spicenet aims to mitigate this by introducing gas fees for pre-flight checks, ensuring that even invalid transactions incur a cost. These checks might include validating signatures and checking account balances.
2. Malicious Full Node Behavior:
Problem: Asynchronous execution means the sequencer doesnât post Merkle roots with the batch, creating an opportunity for malicious full nodes to manipulate the state by using arbitrary execution rules to produce incorrect roots.
Solution: Spicenet is exploring mechanisms to address this, such as using light nodes to verify the roots produced by full nodes and the sequencer. This would involve light nodes verifying Merkle proofs and attesting to the validity of the correct root, penalizing nodes that produce incorrect proofs.
Spicenet prioritizes the reliability and validity of its internal state, which includes critical components like oracle prices and internal data structures. This is achieved through a deterministic state transition function (STF) and mechanisms designed to ensure the sequencer prioritizes keeping the exchange state updated.
Ensuring State Updates: SpiceNet uses âCapabilities,â a feature of the Sovereign SDK, to incentivize the sequencer to include specific transactions that keep the exchange state up-to-date.
Incentivized Rulesets: These capabilities include rulesets that, when not met, penalize the sequencer by withholding rewards.
Prioritizing Critical Transactions: Examples of such rulesets include checking for recent oracle updates or the presence of liquidatable accounts. By enforcing these rules, the sequencer is economically motivated to prioritize transactions that are essential for the smooth operation of the exchange.
Ensuring Transaction Initiation: Spicenet employs a two-pronged approach to ensure a consistent supply of transactions that update the internal state.
Keeper Network: A network of keeper nodes is incentivized to periodically create new transactions, such as oracle price updates. The concurrent actions of these nodes minimize the risk of unresponsiveness or single points of failure.
Sequencer as Backup: If the keeper network fails, the sequencer can be used as a last resort to initiate these critical transactions.
To further manage the priority of state transitions, Spicenet uses âCall Messagesâ. These can be thought of as pre-defined state transitions with specific parameters and expected results. For instance, a UpdateOracle
call message would specify the oracle feeds to update and the price updates themselves. This allows Spicenet to prioritize certain state transitions over others, ensuring the smooth and efficient operation of the exchange.
One of the biggest bottlenecks in blockchain systems is committing to state, a process that involves recalculating the root of a Merkle tree. To address this, the Sovereign SDK, and consequently Spicenet, utilizes the Nearly Optimal Merkle Tree (NOMT).
Binary Tree Structure: Shifting from a 16-ary or larger tree to a binary tree structure simplifies the tree and reduces the number of nodes needed for recalculation.
Optimized Disk Layout: Improving the layout of the tree on disk further enhances efficiency and reduces access times.
Metadata Compression: Compression techniques, including the use of discriminants, minimize the storage requirements for metadata.
Padding-Free Hashing: A padding-free hasher reduces the size of compressed data.
Blake3 Hash Function: The use of the Blake3 hash function allows for significantly larger leaf nodes, improving efficiency.
Aggressive Caching: Regularly accessed nodes are cached, minimizing repeated accesses to disk.
Batch Writing: Writing to the tree in batches reduces overhead.
Avoiding Unnecessary Commitments: The system avoids committing to the Merkle tree unless absolutely necessary, further reducing overhead.
Spicenet is building upon the NOMT with its own optimizations focused on managing database load. These include using asynchronous I/O and pipelining techniques to improve state access mechanisms, leading to better read/write performance.
Spicenet currently employs sequential execution, meaning transactions are processed one after the other. While the current trend in blockchain development emphasizes parallel execution for increased performance, Spicenet recognizes that state commitment remains the primary bottleneck.
Distributing work across multiple cores without addressing state commitment overhead leads to performance degradation.
Sequential execution, when combined with a highly scalable state commitment scheme like NOMT, results in superior performance.
Spicenet plans to incorporate parallel execution as part of its Velocity runtime upgrade, but only after ensuring a robust and scalable state commitment engine.
Parallelism will involve optimizing various aspects of the execution pipeline beyond just transaction processing, including sub-tree computation and recursive ZK proof generation.
To further enhance scalability and decentralization, Spicenet is exploring sharding. Sharding involves running different instances of the network concurrently, each handling a portion of the overall workload, effectively scaling compute and state access horizontally. This approach becomes particularly relevant as Spicenet aims to expand its product offerings beyond just crypto derivatives.
A less radical approach to sharding, sequencer clustering involves distributing the tasks of the centralized sequencer across multiple specialized machines.
This setup allows for horizontal scaling by adding more machines as demand increases while maintaining a degree of centralized control.
The SequencerDAG manages ordering and directs transactions to different includers, while the executor processes transactions based on the SequencerDAGâs instructions.
This approach involves a more complex architecture where multiple execution shards operate concurrently alongside a consensus shard.
Execution shards handle specific product verticals, while the consensus shard ensures consistency and manages cross-shard communication.
Stake versatility allows validators to secure both the consensus and execution shards, simplifying the system and enhancing security.
Sharding would allow Spicenet to scale horizontally while maintaining a high level of performance and decentralization.
Spicenet is developing the Velocity stack, a major upgrade aimed at significantly improving its performance and scalability. This upgrade targets various aspects of the Spicenet architecture, including networking, runtime, and state commitment.
Optimized Transaction Ingestion: The Velocity stack introduces âtilingâ to improve the node softwareâs ability to handle incoming transaction load. Tiling enables multiple processes within a node, each handling a portion of the traffic and distributing workloads across available cores. This significantly reduces Time To Pre-Confirmation (TTPC).
Novel Gossip Protocol: A new, lightweight gossip protocol based on QUIC aims to replace heavier and more complex libraries like libp2p. This change simplifies the protocol, enhancing scalability and efficiency in node-to-node communication.
Parallelized Execution: Tiling is also implemented within the runtime, allowing for horizontal scaling of execution workloads by dividing the execution process across multiple tiles.
Block-STM for Concurrency Control: Spicenet is considering Block-STM for managing concurrency and fault tolerance in its parallelized runtime. Block-STM, known for its optimistic concurrency protocol, allows for high parallelism and dynamic dependency estimation.
Pipelining Between Tiles: Pipelining between tiles ensures that one tile doesnât have to wait for others to finish processing, leading to more efficient resource utilization and faster execution.
Asynchronous I/O: Spicenet plans to introduce asynchronous I/O to interact with the NOMT state database more efficiently. This allows the execution engine to initiate read/write operations without blocking, improving responsiveness and reducing idle time.
Namespaced Merkle Tree: Namespacing the Merkle tree is being considered to allow for parallelized computation of the tree root, potentially speeding up insertions and updates.
Spicenet is initially an optimistic rollup, meaning the sequencer proposes state transitions without formal proofs.
However, Spicenet uses Zero-Knowledge (ZK) fraud proofs to ensure the validity of these transitions and provide security. This hybrid approach aims to strike a balance between the speed of optimistic rollups and the security of ZK rollups.
Traditional optimistic rollups rely on interactive verification games (IVGs) to challenge incorrect state transitions. IVGs involve a back-and-forth process between the challenger and the asserter, which can be complex and time-consuming.
ZK fraud proofs offer a simpler and more efficient alternative. In case of a challenge, a ZK proof is generated to prove the correct computation of the state transition. This proof can be verified much faster than an IVG, significantly reducing the challenge period.
Simplicity and Reduced Complexity: ZK fraud proofs simplify the challenge process and reduce the risk of implementation bugs compared to IVGs.
Faster Challenge Resolution: Verification of a ZK fraud proof requires only a single on-chain transaction, reducing the challenge period from days to hours.
Improved User Experience: Faster challenge resolution leads to shorter withdrawal periods, enhancing the user experience.
Prover Robustness: The reliability of the ZK prover is critical to the security of the system.
Mitigation: Spicenet is considering using ZK VMs to minimize the risks associated with custom provers. ZK VMs are more readily auditable, have a lower bug surface, and can be reused across multiple applications.
Spicenet plans to transition to a full ZK-rollup when the technology matures, specifically when the cost and efficiency of continuous ZK proving improve. This transition will be facilitated by Project Artemis, which utilizes ZK technology for trust-minimized bridging and secure interoperability.
Spicenet offers both preferred and based sequencing options to provide users with flexibility and promote decentralization.
A single, centralized sequencer handles transaction ordering and execution, offering the benefits of speed and efficiency associated with centralized systems.
The preferred sequencer has control over the state and can provide pre-confirmations, offering a low-latency experience for users.
Users can choose to self-sequence their transactions, acting as their own sequencer, particularly if their transactions exceed a certain size limit.
This option provides increased decentralization and potentially better inclusion metrics as users are not reliant on the preferred sequencer.
Based sequencing offers faster confirmation times than traditional force inclusion mechanisms like those used in Arbitrum, as finality is achieved within a few Celestia blocks (around 30 seconds).
SpiceNetâs based sequencing model aims to overcome the limitations of force inclusion mechanisms found in other rollups:
User-Friendly Sequencing: Users can easily switch between preferred and based sequencing within the Spicenet wallet.
Improved Performance: Based sequencing offers significantly faster confirmation times compared to the day-long delays found in force inclusion systems.
Based Pre-confirmations: Spicenet is exploring the possibility of based pre-confirmations, allowing the current Celestia block proposer to offer inclusion guarantees.
The preferred sequencer generally offers the fastest path to transaction inclusion with instant pre-confirmations. However, based sequencing provides a decentralized alternative and faster confirmation times compared to force inclusion mechanisms. This dual approach allows Spicenet to maintain low latency in most scenarios while offering a more decentralized option when needed.
Spicenet has a vibrant community that plays a crucial role in its ecosystem. Members can participate in various community activities and initiatives to earn rewards and contribute to the projectâs development.
Community Roles:
Chillis: The default role assigned to all verified community members.
Spice Chads: Active members who participate in community activities and engage in meaningful discussions. They are eligible for 20% of the ecosystem airdrops.
Spice Kings: More dedicated members who contribute significantly to the community, earning them 30% of the airdrops and priority access to new features.
Spice Gods: The most impactful members who receive 50% of the airdrops, highest priority access, and potential whitelist opportunities.
Participation in PepperDEX community activities, such as calls, game nights, and poker games.
Engagement in Spicenet-related Twitter spaces and with the Spiceconekt platform.
Creation and sharing of community-based memes, GIFs, and social media posts about PepperDEX and Spicenet.
Community contributions earn members âSpoints,â which can be traded for roles within the Spiceconekt marketplace.
Roles are acquired progressively: Chad, then King, then God.
The community receives a total of 5% of the SPICE tokens at Token Generation Event (TGE).
Spice Gods: 2.5%, capped at 200 slots, each eligible for 12,500 SPICE.
Spice Kings: 1.5%, capped at 800 slots, each eligible for 1,875 SPICE.
Spice Chads: 1%, with no cap on the number of eligible members.
This community structure encourages active participation and rewards those who contribute to the growth and development of the Spicenet ecosystem.
Spicenet represents a unique approach to building a high-performance, decentralized trading platform. By combining the sovereignty and flexibility of sovereign rollups with the efficiency of a dedicated DA layer and a VM-less design, Spicenet aims to deliver a trading experience that rivals centralized exchanges. Its focus on continuous research and development, as demonstrated by the Velocity stack and the exploration of sharding, indicates a strong commitment to pushing the boundaries of whatâs possible in the decentralized trading landscape.
Through community engagement and a clear focus on user experience, Spicenet is poised to play a significant role in the future of decentralized finance.