Exciting updates are on the horizon for Chia farmers with the latest iteration of Chia’s new proof of space format. Earlier this year, we shared our progress on new technologies that we believe addressed two pressing issues:
- Higher Energy Consumption from Compressed Plots: Tools like DrPlotter allowed for smaller plots but required significantly higher ongoing energy, counteracting the Chia blockchain’s energy-efficient goals.
- Rental Attack Risks: Advances in GPU technology raised concern that a future attacker could potentially rent enough powerful GPUs to spoof a majority of the netspace.
The initial redesign made significant strides, improving security by making the network up to 1000x more resistant to rental attacks and greatly enhancing compression resistance with only a small upfront cost during harvesting.
Now, we’re excited to announce further advancements that build on this foundation. The latest updates should provide even greater efficiency, reduced energy consumption, enhanced security, improved compression resistance, and expanded accessibility.
Key Improvements
- Lower Minimum Specs for Harvesting: Farmers can harvest petabytes of space using lightweight compute devices like a Raspberry Pi 5.
- Support for Smaller Plots: New plot sizes as small as 3 GiB and lower RAM requirements for plotting, make farming more accessible.
- More Efficient Plotting: Plotting is now faster per TiB, with reduced memory requirements for smaller plot sizes. All-RAM plotting is accessible to more systems.
- Reduced Network Energy Consumption: The new format significantly decreases the network’s overall energy usage without compromising compression resistance or security.
- Stronger Compression Resistance: “Compressible” plots are economically nonviable, ensuring that network security remains based on physical storage space, promoting fairness and sustainability.
- Near-instant proof verification: Ensures efficient network performance.
How These Changes Work
The key innovations in this iteration are the introduction of a “frozen” quality string and a “chain of proofs.” These advancements not only significantly enhance compression resistance by shifting all security to a single, infrequent point but also reduce the energy consumption of honest farming to a negligible level.
- The “Frozen” Quality String: This feature encrypts and removes a substantial portion of the plot data required for the proof while still allowing the plot to pass the quality string test during harvesting. Full proof recomputation is only required if the quality string passes the test and wins a block or pool partial.
- The “Chain of Proofs”: To prevent attackers from exploiting frozen quality strings and selective recomputation, this system chains 8 proofs derived from the same 5 tables in the plot. Each proof is chosen based on the preceding ones, significantly hindering compression attacks by creating an overwhelming number of combinatorial false positives when attempting to drop bits in the attack.
Additionally, the plot design ensures that an honest farmer can recompute the full proof for all its elements faster than the sum of recomputing individual elements. This enables recomputation on low-spec hardware within a reasonable time. In contrast, an attacker must perform multiple recomputations for individual elements with every challenge, making attacks prohibitively expensive—even for attempts to remove a single additional bit of data.
Complete technical details will be published in the upcoming CHIP (Chia Improvement Proposal). (See our timeline for more info.)
Impact on Farming
Under the new system:
- Farmers can use lightweight devices like a Raspberry Pi 5 to harvest large amounts of space (many petabytes).
- Recomputation is required only when a quality string is valid for a block win or pool partial. This occurs infrequently, at most once every few minutes for pool farming, and less often for solo farming.
- Minimum specs depend on the largest plot size (k-size) in use—not the total number of plots.
Smaller vs. Larger Plot Sizes
- Smaller plots require less memory for plotting and recomputation but increase mechanical HDD activity.
- Larger plots reduce HDD activity but demand higher resources for plotting and recomputation.
Plot Sizes and Performance
Supported Plot Sizes:
The new proof of space format supports plots as small as 3 GiB. Due to symmetric properties of the format, only even-sized k-sizes are supported. While we currently have no plans to support sizes smaller than k28, larger k-sizes may be enabled in the future. Each even-step k-size is a little over four times larger than the previous size.
- k34: ~260 GiB
- k32: ~61 GiB
- k30: ~14 GiB
- k28: ~3 GiB
Plotting Speed (with All-RAM Requirements)
CPU plotting will be possible but will be less efficient than GPU. All times shown are for all-RAM plotting, although farmers can trade cpu RAM for temporary SSD storage, which results in slightly slower performance.
| Plot Size | Raspberry Pi 5 | Ryzen 5600 (6-core) | Nvidia 3090 |
|---|---|---|---|
| k34 (512 GiB all RAM, min 8GiB) | N/A | ~10 hours | ~6 minutes (min. 8GiB VRAM) |
| k32 (128 GiB all RAM, min 2GiB) | N/A | ~3 hours | ~1-2 minutes (min. 2GiB VRAM) |
| k30 (32 GiB all RAM, min 512MiB) | N/A | ~45 minutes | ~30 seconds (min. 512MiB VRAM) |
| k28 (8 GiB all RAM, min 128MiB) | ~40 minutes | ~12 minutes | ~5 seconds (min. 128MiB VRAM) |
| Plotted space/day | Up to 170 GiB | Up to 800 GiB | Up to 100 TiB |
Proof Solving Times
After a proof of sufficiently high quality is found it needs to be ‘solved’ which reconstructs the full proof so it can be verified by others. Proof-solving hardware requirements depend on the maximum k-size in the farm. Solve times should ideally stay under 8 seconds.
| Plot Size | Raspberry Pi 5 | Ryzen 5600 (6-core) | Threadripper | Nvidia 3060 |
|---|---|---|---|---|
| k28 | ~6.8 seconds | <2 seconds | <1 second | 60 ms |
| k30 | N/A | <8 seconds | <4 seconds | 240 ms |
| k32 | N/A | ~15 seconds | <8 seconds | 960 ms |
| k34 | N/A | N/A | N/A | <8 seconds |
HDD Disk Activity
Lower k-sizes increase disk activity but lower your minimum hardware requirements for proof solving (see previous section). For SSDs, k28 plots are recommended due to minimal impact on farming performance.
| Plot Size | Full 5TiB Disk Load | Full 20TiB Disk Load | Full 20TiB Disk Load Using Benes Compression |
|---|---|---|---|
| k28 | ~1.6% | ~6.4% | ~12.8% |
| k30 | ~0.4% | ~1.5% | ~3% |
| k32 | ~0.1% | ~0.4% | ~0.8% |
| k34 | ~0.025% | ~0.1% | ~0.2% |
Quality Strings Frequency
Quality strings are found when a plot passes several filters, including plot ID, scan, and chain filters. Once found, they are tested against a difficulty filter to determine if they qualify as a block or pool partial win.
Solo farming: The frequency of quality strings does not significantly impact farming activity.
Pool farming: Increased quality string frequency improves pool size estimation accuracy for smaller farmers, helping stabilize rewards. Farmers with few plots may experience fluctuating estimated space and rewards day-to-day, but over time, rewards will align with actual plotted space.
| Plot Size | Avg. Quality Strings per hr per TiB |
|---|---|
| k28 | ~9.1 |
| k30 | ~2.1 |
| k32 | ~0.5 |
| k34 | ~0.12 |
Trade-Offs Under Consideration
As we finalize the design of the new proof of space format, critical trade-offs are being carefully evaluated. These decisions affect key aspects like HDD activity, compression resistance, rental attack security, and quality string frequency. Below are the considerations and their implications:
- Lowering HDD Activity
- Pros: Reduces wear and tear on disks, which is especially valuable for larger farms and setups relying on HDDs.
- Cons: Reduces rental attack resistance, compression resistance, and quality string frequency, which could impact fairness and security.
- Increasing Quality String Frequency
- Pros: Improves pool size estimation accuracy for smaller farmers, leading to more consistent and predictable rewards.
- Cons: Increases HDD activity, raising disk wear and potentially shortening the lifespan of mechanical drives. Reduces rental attack resistance.
Current Tuning and Security Assurances
The current settings are optimized to balance these trade-offs:
Compression Resistance: Theoretical GPUs with 10x the performance per watt of a 4090 cannot economically compress even 1% of a plot’s size without exceeding the energy and cost requirements of honest plotting.
Rental Attack Resistance: The resistance is strong enough that an H100x8 GPU cluster could at most spoof 500 GiB of space, making rental-based attacks infeasible.
Looking Ahead
We’re pleased with the progress we’ve made as we prepare for this transition, but as we transition from prototypes and benchmarks to production-grade code, further tuning of parameters may be necessary to optimize the proof of space format for real-world conditions. Stay tuned for the official CHIP proposal, which will provide detailed specifications for the new format.
FAQ
Harvesting consists of two main components: plot retrieval and proof solving when a good proof is found.
For plot retrieval, even large farms can use low-spec computers such as original Raspberry Pis, as most of the time is spent simply reading from storage, which uses minimal compute resources.
The proof-solving hardware requirement depends on the largest plot size (k-size) in your farm, not the total number of plots. If a proof of space wins a block or pool partial, your hardware must be capable of solving proofs for the largest k-size plot within the required timeframe.
For example, if your farm includes k28, k30, and k32 plots, your proof-solving machine must meet the requirements for solving k32 proofs, even if the majority of your plots are smaller. If you want a single machine for both harvesting tasks (plot retrieval and proof solving), it should meet the k32 specs for solving proofs and can also handle plot retrieval.
For large farms or setups with multiple harvesters, you can use low-spec devices like Raspberry Pis for plot retrieval and designate a higher-spec machine capable of solving proofs for your largest k-size as the central proof-solving service. If your farm contains only k28 plots, a Raspberry Pi 5 can serve as both a plot retrieval device and the central proof-solving service for your entire farm.
Smaller k-sizes, such as k28, lead to increased disk activity, which in turn raises the energy consumption of storage media. For SSDs, this extra activity is negligible, and a low-power device like a Raspberry Pi 5 is sufficient to handle even large farms spanning multiple petabytes.
For HDD-based farms, HDDs consume more power (typically around 50 to 100% more) when actively reading compared to being idle. For example, a large 20TiB HDD filled with k28 plots will be active approximately 6% of the time, compared to 0.4% for k32 plots, and just 0.1% for k34 plots. This would result in a 3-6% increase in energy consumption when using k28 instead of k32 or k34 plots.
For farmers with a large number of drives, it may be more efficient to use a higher-performance recompute machine capable of handling larger k-size plots (e.g., k32) without consuming more power than the additional energy costs incurred by smaller plots. A system like a Mac Mini M1 offers low idle power usage and can efficiently handle k32 plots or larger.
The most energy-conscious approach is to leverage an existing system already online that meets the recomputation requirements for larger k-sizes. By running a solver on standby, this system can handle requests for full proofs as needed with negligible impact on its overall energy usage. This method avoids the need for additional dedicated hardware while keeping power consumption minimal.
Benes compression is designed to save approximately 7-8 bits per entry per plot, regardless of the k-size. This results in notable space savings, especially for smaller plots like k28, which have the fewest bits per entry. For a k28 plot, this translates to an estimated 3-4% reduction in plot size.
While the space savings are promising, constructing Benes-compressed plots comes with significant challenges:
- All-RAM Plotting: Plotting with Benes requires all-RAM construction, and demands additional system resources.
- Longer Plot Times: Plot creation using Benes compression is expected to take significantly more time and energy compared to traditional plotting methods.
- GPU Assistance Uncertainty: It is currently unclear whether GPUs can effectively assist CPUs in constructing Benes-compressed plots, as the plotting process is difficult to parallelize. This limitation raises questions about whether plotting speeds could exceed 100 GiB/day on a single system.
- Increased disk activity: Benes-compressed plots require twice the disk reads during farming. This increased disk activity may negate the energy savings achieved from smaller plot sizes, particularly for HDD-based setups.
The additional cost and energy required for Benes-compressed plotting and increased disk activity during harvesting may outweigh the benefits of 3-4% space savings. Farmers will need to assess whether these savings are sufficient to justify the increased plotting resources and time.
Despite these challenges, we plan to include an option for Benes compression in the upcoming release for those who wish to experiment with it. Farmers can decide whether the trade-offs align with their individual farming strategies and goals.
The scope of changes to the original plot format has expanded significantly due to recent technological advancements. To ensure a comprehensive and practical release, we plan to make the CHIP publicly available once development of the plotter and solver is complete and extensively tested to be near production-ready.
This approach will allow us to provide accurate performance metrics that reflect real-world usage, giving farmers a clear understanding of what to expect. Our tentative timeline for the CHIP release is now Q1 2025.
When the CHIP is released we will have code for plotting and verification available for review.
6-12 months.
Grinding, or creating a plot on the fly without storing to disk, generates rewards that are roughly the same per compute across the various k-sizes, provided the grinding fits into fast memory. With GPU clusters now having large VRAM capacities, there is no practical k-size that cannot be accommodated in some advanced GPU system. For instance, a k28 will complete a 3GiB plot in 5 seconds, and likewise, a k32, being ~18 times larger (~61 GiB), would take 18 times longer on the same GPU. However, with a cluster of 18 GPUs, the k32 plot could still be generated in approximately 5 seconds.
In the original proof of space design, grinding posed a significant risk because a grinder could exploit the plot ID filter. The filter passes plots with a 1 in 256 chance, meaning a grinder could spoof the equivalent of 256 plots by generating a plot ID that passes this filter.
The new proof of space introduces two additional filters—the scan filter and the proof chaining filter—to mitigate grinding risks. These filters significantly reduce the effectiveness of grinding by requiring that the plot passes the plot ID filter (1 in 256 chance), and also passes the scan filter and proof chaining filter, which introduce an additional 1 in 64 chance. As a result, the grinder can only spoof the equivalent of 4 plots per signage point. Across 3 signage points, this totals 12 spoofed plots before the plot ID filter changes for the next set of challenges.
For example, a 3090 could spoof a maximum of 24 k28 plots (~72GiB of storage). However, the cost of a 3090 far exceeds the cost of storing 72 GiB of data on an HDD for an honest farmer. Additionally, the energy consumption of a 3090 is vastly higher than the energy required to maintain 72 GiB of storage on an HDD.
To spoof 1 EiB of netspace, a grinder would need to rent at least 15 million 3090 GPUs. Even then, this is an order of magnitude less than the resources needed to control half of Chia’s netspace, making grinding practically and economically unfeasible on a large scale.
The feasibility of grinding can be assessed by calculating the amount of space that could be spoofed and comparing it to the resources required to achieve this.
First, we determine how quickly a system can generate plots and whether the generated space can meaningfully spoof a significant portion of netspace. Then, we assess the probability of passing filters (e.g., plot ID, scan, and proof chaining filters) and how many plots would need to be generated to spoof a given amount of space. And finally, we evaluate whether it is feasible to rent or acquire the required computational resources (e.g., GPUs or GPU clusters) to generate enough spoofed space to impact the network.
While it’s straightforward to calculate spoofed space (as demonstrated in the previous answer), the primary question is whether sufficient resources can be obtained at scale. For example: spoofing 20 EiB of netspace would require 300 million 3090 GPUs, far exceeding the global availability of GPUs today. Controlling such a large number of GPUs at a financially viable price is unlikely in the foreseeable future.
Thus, while grinding is theoretically possible, it remains economically and logistically infeasible to execute at a scale that could threaten the network.
Short answer:
K28 plots are expected to remain viable for as long as no significant vulnerabilities emerge. If any risks arise, they would likely apply to higher K-sizes as well over time, given advancements in hardware and technology.
Long answer:
Under the current settings for the new format, the primary risk to continued support for K28 plots stems from the potential development of ASICs or FPGAs. These specialized devices could potentially reduce production costs for K28 plots compared to larger K-sizes, as smaller plots require less RAM. However, the viability of ASICs is a complex issue, heavily influenced by development costs and the financial rewards they might yield. While FPGAs, known for their high efficiency, could theoretically pose a risk if optimized, they are typically slower than high-end GPUs and face similar challenges.
The new plot format has been designed to resist both rental and compression attacks, even against more powerful GPUs that may be developed in the future. This makes it uncertain whether FPGAs or other specialized hardware would gain any meaningful advantage for plot compression. Reducing plot size through bit-dropping quickly becomes impractical, as the resources required to achieve even a modest reduction escalate to nearly the same as grinding full plots.
Given these safeguards, K28 plots are expected to remain viable for the foreseeable future under the current settings. However, advancements in hardware and unexpected vulnerabilities will continue to be monitored to ensure the format’s long-term stability and security.
Currently, the plan is to maintain the plot ID filter at a level of 256, with a scheduled reduction on a periodic basis. This allows flexibility to adapt over time. The scan filter and chain filter are fixed and not expected to change. If conditions do not warrant reducing the plot filter during a given period, a soft fork can delay the reduction to the next scheduled period without disrupting the network.
In the future, if SSDs become the dominant storage medium for proof of space, the current disk activity constraints imposed by HDDs will no longer be necessary. This shift would allow for a more significant reduction in the plot filter, enhancing both grinding and compression resistance. The reduction in the plot filter is directly proportional to the increase in resistance, and we have up to two additional orders of magnitude available for tuning. This means the plot filter could eventually decrease from 256 to as low as 1, providing substantial flexibility to counter emerging risks while maintaining the integrity of the proof of space system.