Plotting
The second phase of the Subspace Protocol
Last updated
Was this helpful?
The second phase of the Subspace Protocol
Last updated
Was this helpful?
Plotting is the process of creating and maintaining plots on a disk, during which pieces are gathered and organized into plots of several sectors.
Each sector contains an encoded replica of a uniformly random sample of pieces across all archived history. This sampling ensures that the data is distributed among farmers proportionally to their pledged disk space and replicated evenly.
Plotting is based on two core ideas:
Erasure coding helps protect the data against loss in the event of failures and network partitions.
Memory-bandwidth-bound encoding provides a more cost-effective and eco-friendly alternative to proofs-of-work, while providing provable time/memory trade-offs and security guarantees.
Combining these two ideas allows us to create unique, provable replicas for each farmer that are difficult to fake with computation or to compress. This scheme also makes scanning and verifying the plots easier, ensuring the chain history data is recoverable. Our memory-bandwidth-bound encoding construction is inspired by the Chia protocol paper 'Beyond Hellman's Time-Memory Trade-Offs with Applications to Proofs of Space'. The Subspace Protocol adopts a custom implementation of the Chia Proof-of-Space (PoS) plotting function as a memory-bandwidth-bound function to encode, or 'mask', the pieces in farmer plots.
In short, the PoS plotter generates a table of permuted outputs from a set of random functions. The table size is determined by a memory bandwidth requirement parameter k set to 20, and the random functions are determined by a seed. When challenged at an index, the table outputs a short proof-of-space that can be efficiently verified. We do not use the proof-of-space directly to verify that a farmer has pledged a certain amount of space, as Chia does. Instead, we use it to prove that a farmer utilized the required memory bandwidth for encoding the plot.
A plot can cover an entire disk or span across multiple disks, and there is no limit to the amount of storage a farmer can pledge to the network. Plots consist of equally-sized sectors (around 1 GiB each). Each sector is a pseudorandom selection of 1,000 pieces, uniformly sampled throughout the history up to that point. For example, if the farmer creates a new sector when the history consists of 50,000 pieces (50 GiB), the 1,000 pieces for this sector will be a uniform selection from the existing 50,000 pieces. In addition, the farmer must save the current history size, as it will determine when the sector will need to be updated with newer pieces.
Once a farmer has obtained all 1,000 pieces for a sector from the network, they create an encoded replica. Only the piece’s historical data (the record) is encoded. The KZG commitment and witness included in a piece are saved separately in the sector metadata as they will be needed later for farming.
For each record, the plotting algorithm performs the following steps in memory:
Erasure code (extend) the record data by interpolating a polynomial over chunks of the record.
Derive a unique pseudorandom and verifiable seed.
Based on this seed, generate a proof-of-space table using memory bandwidth resources set by the global protocol memory requirement parameter k. This memory-intensive computation prevents malicious farmers from creating replicas after the new block challenge is announced, making it more rational for them to store the replica rather than try to compute it on the fly every time.
Encode each extended record chunk by XOR-masking it with the corresponding proof-of-space value.
After all records in the sector have been encoded as described, the farmer spreads them into s-buckets chunk-wise. Ultimately, each bucket will contain chunks from all records. The first bucket will have the first chunks of each record; the second bucket will have the second chunks, and so on. The s-buckets are then written to disk, and the plotting process of the sector is complete in a single write operation.
Each bucket represents a potential winning ticket in the block proposer lottery. For each challenge, a farmer will scan one s-bucket (containing one chunk of each record they store in a sector) to check whether any of them are eligible to win a block. As a result, a farmer has a unique encoded replica that is difficult to compress or compute on demand. An economically rational farmer is incentivized to store as many honestly encoded replicas as possible to maximize their chances of winning a block.
As the chain grows, we need to ensure that new data is replicated as much as older data in the blockchain history. To keep this replication factor constant, farmers must periodically update their plots by replotting expired sectors with a new selection of pieces.
The expiry point for a sector is determined by the history size at the time the farmer initially plotted the sector, and is randomly assigned to occur sometime before the history size quadruples (i.e., if a farmer plotted a sector when the history size was 50 GiB, the expiry point will occur before the history reaches 200 GiB). When a sector reaches its expiry point, the block proposer challenge solutions coming from this sector will no longer be accepted by other peers, incentivizing the farmer to update their plot. When replotting, farmers erase the expired sector and repeat the plotting process anew, replicating a fresh history sample. Each replotting creates a new sector in memory and saves it to disk in a single write operation.
In a plot spanning multiple GBs, sectors will be updated randomly, one at a time, so replotting is amortized over a long period, meaning a farmer never needs to erase and re-create their whole plot and miss out on challenges. The plot refreshing will be practically invisible to the farmer and allow their uninterrupted participation in consensus. The bigger the chain grows, and the longer the farmer participates in the network, the less frequent the replotting on their disks will be.
After genesis, the network was seeded with 20 GiB of history, meaning farmers who joined after the seeding started plotting with an initial history size of 160 segments. Assuming a 1 TB SSD plot, a farmer would thus need to replot 3.5 TB of data on average by the time the chain history reaches 1TB in size, 6.2 TB of data by the time history reaches 10 TiB, and 8 TB by the time history reaches 50 TiB. Given the common TBW (Total Bytes Written) for consumer grade 1 TB SSDs of 300-600 TB, Autonomys farming requires under 3% of the SSD's total endurance to farm over several years (for comparison, Ethereum's full chain data size is ~21 TiB as of February 2025 via Etherscan).
The next and final phase of Subspace Protocol consensus is farming.
Query the generated table for enough () proof-of-space values to mask every chunk of the record.
