CHIP-0048: New Proof of Space

[danieljperry]

We propose a new Proof of Space protocol for the Chia blockchain that addresses weaknesses in energy efficiency, rental attack resistance, and plot format stability.

[danieljperry]

This CHIP from Dr. Nick has been assigned CHIP-48 and is now a Draft. It proposes the new Proof of Space format for Chia's blockchain. Feel free to comment here. We will also post links to the two scheduled Q and A sessions after they become available.

[BrandtH22]

Note that timelines associated with integrating PoS 2.0 can be found in CHIP 49 and Dr Nick created an overview video of the new PoS which can be accessed here

[danieljperry]

The term plot difficulty could be confused with the network's global block difficulty. In addition, while "difficulty" in this context describes the amount of time required to create a plot, it could easily be confused for the time required to create/solve a proof. With these considerations in mind, we have decided to update the term plot difficulty to plot strength.

[Jsewill]

Regarding the naming of plot strength, while the term itself is probably fine, here are some of the suggestions, humorous and not, from discord:

• Plot Tier
• Gravitas (Perhaps also "Gravity")
• Frequency (or it synonyms)
• Rizz

[danieljperry]

This CHIP is now in Review status. Please leave your reviews here, and feel free to discuss it in the #chips channel of our Discord.

[trgarrett]

Could you please include in the supporting documents for this CHIP a cost model for attacking PoS2 with AES ASICs? I understand the barrier imposed to GPU-based rental attacks, but that seems to incompletely capture the attack surface.

Edit: To clarify my question, I don't think there is any threat there, but I think it's important to recognize the hypotheticals to rule them out.

[danieljperry]

Could you please include in the supporting documents for this CHIP a cost model for attacking PoS2 with AES ASICs? I understand the barrier imposed to GPU-based rental attacks, but that seems to incompletely capture the attack surface.

I'll pass this request on to Dr. Nick.

[drnick23]

Could you please include in the supporting documents for this CHIP a cost model for attacking PoS2 with AES ASICs? I understand the barrier imposed to GPU-based rental attacks, but that seems to incompletely capture the attack surface.

CPU's with hardware support for AESENC are, as far as I understand, already AES ASIC's (hence the 10x speed-up over software implementation). If GPU's also had in-built AESENC hardware support this could speed up hash rate, and likely turn the gpu compute-bound hash into memory bound in the worst-case.

I could add an attack estimation based on the AES hashing portion becoming memory bound on the GPU as an ASIC attack.

Trying to guess what a potential ASIC fully built for plotting/attacking could be estimated by inputting expected hash rate and memory bandwidth for the ASIC, but I would not know what those performance differences vs a 5090 could be or the cost to build it per unit.

[trgarrett]

CPU's with hardware support for AESENC are, as far as I understand, already AES ASIC's (hence the 10x speed-up over software implementation).

A general purpose computing device is by definition not an ASIC. The Chia team commissioned a VDF ASIC. It seems like you should have the knowledge base in-house to at least get an estimate of performance and cost. From the research I've done, it looks like AES ASICs may be 50 to 100 times faster than even extension-enhanced CPUs.

Edit: the optimization progression in all PoW chains was: CPU, GPU, FPGA, ASIC. The pattern has been repeated many times.

[hoffmang9]

@trgarrett I'm borrowing this from Sonnet 4.6 but I've reviewed it and it is correct:

AES ASIC vs On-Chip AES: Feasibility of Material Speed Improvement

This is a fun question that gets at some deep hardware realities. The short answer is: extremely difficult to improve meaningfully, and essentially impossible at the same voltage/process node.

Why On-Chip AES Is Already Nearly Optimal

Modern x86 (AES-NI), ARM (AES extensions in ARMv8), and Apple Silicon all implement AES-128/256 in dedicated silicon. The key characteristics:

• Single-cycle or near-single-cycle latency for a full AES round, with pipelining giving ~1 block/cycle throughput in optimized modes (e.g., CTR, GCM)
• AES-GCM throughput on modern Intel (e.g., Sapphire Rapids) can hit ~100 Gbps per core using VAES + VPCLMULQDQ with 8-way parallelism across 512-bit vectors
• The critical path through SubBytes + ShiftRows + MixColumns + AddRoundKey is already reduced to a handful of gate delays using composite field arithmetic for the S-box

What an ASIC Could Theoretically Do

1. Massive parallelism — an ASIC could instantiate thousands of AES engines. But this is throughput scaling, not latency improvement, and a CPU core can already do this with VAES on wide vectors. A GPU does this too.

2. Remove everything else — no branch predictors, caches, out-of-order logic. But those don't sit in the AES datapath anyway; AES-NI is already a bolt-on functional unit.

3. Custom cell libraries / aggressive pipelining — you could cut latency slightly with deeper pipelining and faster standard cells, but you're fighting the same physics.

The Fundamental Bottleneck: The AES S-Box

The irreducible core is the GF(2⁸) multiplicative inverse for SubBytes. In silicon, the best implementations use a tower field decomposition (GF(2⁴) over GF(2²) over GF(2)) which reduces the critical path to roughly:

• ~4-5 XOR/AND gate delays for the inversion
• Plus linear transformations

At 3-5nm nodes, that's already sub-200ps. You're not going to get orders of magnitude out of this — maybe 20-30% with exotic cell libraries and aggressive Vt tuning, which is well within what CPU vendors already do on their AES units.

Bottom Line

For AES specifically, the CPU vendors have essentially closed the gap. An AES ASIC at the same process node would offer:

• Similar or marginally better latency (single-digit percent improvement)
• Higher aggregate throughput only through sheer parallelism — but at that point you're comparing it to a many-core CPU or GPU, which can also parallelize

The only realistic niche is in constrained IoT/embedded contexts where you want AES with minimal power and area, not speed — and even there, ARM's TrustZone Cortex-M cores with hardware AES are already extremely efficient.

The economics are brutal: by the time you tape out an AES ASIC, Intel or Apple has shipped another generation that makes the delta irrelevant.