TLDR:
- SPICE separates transaction ordering, data availability, and execution into three distinct components.
- Blocks will carry signed statements from participating nodes instead of user transaction payloads.
- Validators check state witnesses without storing the full state of a shard, using stateless validation.
- SPICE targets faster blocks, lower latency on near.com and NEAR Intents, and complex transactions.
SPICE architecture is a planned upgrade for NEAR Protocol that separates consensus from execution. The Near One team detailed the design in a technical deep dive.
The change moves transaction execution off the critical path of block production. Once SPICE launches, the network expects faster blocks and lower latency across near.com and NEAR Intents.
It will also support longer-running, more complex transactions. The design also lays the groundwork for atomic execution across shards.
Why NEAR Protocol Is Changing Its Design
NEAR is a sharded blockchain that presents a single state to users. Currently, each step of inter-shard communication needs agreement from the consensus algorithm.
Receipts are units of execution that touch only one shard, and they carry messages between shards. The Near One team argues that this requirement is unnecessary.
At present, ordering, execution, and data availability are tightly coupled. A new block can be produced only after the previous one is executed and verified. The data a block references must also be replicated across several nodes first.
As a result, block production and execution often wait on each other. Execution time and block latency also vary from one block to the next. Pipelining reduces the effect, but the report says its benefit is limited.
In a post on X, NEAR Protocol described the SPICE architecture as a major architectural upgrade. The post said the chain can produce blocks at a high rate. Execution and data availability would then run asynchronously.
How SPICE Splits the Chain, Data Store, and Execution
The SPICE architecture rests on three parts: the Chain, the Data Store, and the Execution component. The Chain produces blocks that hold statements instead of user transactions.
Participating nodes with adequate stake sign and submit these statements. Doomslug remains the consensus algorithm that orders them.
The Data Store holds transaction payloads and confirms their availability. Data owner nodes sign a statement once they store a blob. The Chain then assembles these statements into an availability certificate.
The Execution component downloads the payloads and runs the transactions. Replicas hold shard state and produce a state witness for each chunk. Validators then re-compute the result without storing the full shard state.
Quorum certificates currently confirm both availability and execution. According to the report, threshold signatures or succinct proofs could replace them later. Each component can also be updated without changing the others.
Performance Gains and the Rollup Comparison
Under the SPICE architecture, blocks stay small and carry little data. This lowers the computation needed to produce them. Smaller blocks also support a higher block rate. Nodes with limited hardware can participate as well.
The three components can fall behind the Chain during load spikes. They then catch up once traffic eases. Meanwhile, the Chain alone decides how state evolves, so the result is defined before anyone computes it.
The report also compares NEAR shards to Ethereum rollups. Each shard resembles a rollup, and the NEAR chain resembles Ethereum’s L1. Unlike Ethereum, NEAR builds this functionality directly into the protocol under the SPICE architecture.
Shard communication is part of the system specification, which allows direct data flow. However, shards still depend on each other’s receipts, so they cannot evolve independently.
The authors say this limit is not fundamental and may be relaxed in future work. Near One also plans further posts on the challenges and on data dissemination between shards.
