Skip to content

CHIP-0049: 3.0 Fork Info #161

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
danieljperry wants to merge 6 commits into
base: main
Choose a base branch
from
+164 −0
Open

CHIP-0049: 3.0 Fork Info #161

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
5168326
Add CHIP for fork timelines and assign 49, Draft
danieljperry May 19, 2025
5ff939e
Fix formatting
danieljperry May 19, 2025
71133da
Update Plot Difficulty to Plot Strength
danieljperry Sep 15, 2025
8d7ab9e
Update minimum plot strength strategy to use manual increases instead…
danieljperry Sep 25, 2025
7e767e1
Add shatree operator to CHIP-49
danieljperry Oct 1, 2025
3a537d7
Update name of shatree to sha256tree
danieljperry Nov 3, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
164 changes: 164 additions & 0 deletions CHIPs/chip-0049.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,164 @@
CHIP Number | 0049
:------------|:----
Title | 3.0 Fork Info
Description | Provide all info that will be included in the 3.0 fork
Author | [Arvid Norberg](https://github.com/arvidn)
Editor | [Dan Perry](https://github.com/danieljperry)
Comments-URI | [CHIPs repo, PR #161](https://github.com/Chia-Network/chips/pull/161)
Status | Draft
Category | Standards Track
Sub-Category | Core
Created | 2025-05-19
Requires | [0048](https://github.com/Chia-Network/chips/pull/160)

## Abstract
[CHIP-48](https://github.com/Chia-Network/chips/pull/160), which introduces the new proof format, requires a hard fork of the Chia blockchain. This document describes how the new proof of space will be integrated with the blockchain as well as how original plots will be phased out, gradually. In anticipation of advancing technology, we plan to make automated adjustments to the plot ID filter and the proof fragment scan filter. We will adjust the minimum plot strength manually when needed. This CHIP also proposes a few other hard-fork changes, unrelated to the new proof format.

## Motivation
### New proof format
The current proof format was released in July 2020, during the Chia blockchain’s beta phase. Five years later, the format remains secure. However, two broad issues exist, one of which remains hypothetical, and the other of which is in production today.

The hypothetical issue is plot grinding. This is where a farmer creates an entire plot and submits a proof within around 28 seconds. Plot grinding is described in detail in [CHIP-12](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0012.md).

The other issue is plot "compression," where bits are dropped during a plot's creation, and added back in while farming. The result is a farm that squeezes more proofs into the same space. Plot compression is described in detail in a [blog post](https://www.chia.net/2023/01/21/plot-compression-is-here/).

Neither of these issues is an attack on the network itself, but in both cases, they make time-space tradeoffs, which cause the plots’ Proof of Space to begin to resemble Proof of Work (PoW). As a consequence, the network is consuming more energy than what was originally intended.

In the first half of 2024, we made the decision to sunset the existing proof format in favor of a new one that will be significantly more resilient to bit dropping and other time-space tradeoffs. Farmers will need to replace their existing plots with new ones, so we have built this format with minimizing future disruptions in mind.

We will future-proof the new format by introducing a new parameter with periodic modifications for the plot ID filter and the proof fragment scan filter.

### keccak256
The hard fork gives us the opportunity to promote the keccak256 CLVM operator from [CHIP-36](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0036.md) to be allowed outside the `softfork` guard. This makes it easier to use.

The usage and CLVM cost of this operator are provided in CHIP-36.

### sha256tree
Many puzzles use the [sha256tree](https://github.com/Chia-Network/chia_puzzles/blob/0b46a6ebfc3b432d68edf9b91e6cef0ec13da2e7/puzzles/sha256tree.clib) library, which calculates the puzzle hash of a given puzzle program. This library is used so frequently, in fact, that it makes sense to include it as a native CLVM operator in the hard fork. Another advantage of including `sha256tree` in the CLVM is that it will be cheaper to call, both in terms of CPU compute and CLVM cost.

#### Technical info about sha256tree

Opcode: 63

Argument: Exactly one valid CLVM tree

Returns: The `sha256` puzzle hash (Merkle root) of the input tree

Usage: (sha256tree (TREE))

CLVM Cost: todo

### Conditions
Currently, only `CREATE_COIN`, the `AGG_SIG_*`-family and `SOFTFORK` conditions have a cost. All other conditions are free and could therefore risk being a DoS vector. The full node currently limits the number of announce-family conditions, per coin spend, to 1024 (See [CHIP-25](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0025.md#clvm-cost)). Conditions in this family are expensive because they require memory allocation during validation.
With [Vaults](https://www.chia.net/2025/01/31/chia-vaults-a-secure-and-flexible-way-to-manage-your-digital-assets/), each coin spend requires a message to be sent from the vault to the coin. This makes the 1024 limit at risk of being hit by legitimate uses.

This CHIP proposes replacing the hard upper limit of some conditions with a cost applied to all conditions beyond a certain number in a given coin spend.

## Backwards Compatibility
This CHIP proposes a hard fork to upgrade the proof format. Hard forks relax rules. Blocks that are invalid by the existing rules will be considered valid by the new rules (and sometimes vice versa). This is why every node must update for a hard fork to be accepted. If this CHIP is accepted, then there will be a window of at least six months prior to its activation for all full nodes, farmers, and harvesters to be upgraded.

Even though the original plot format will be disabled by this CHIP, it will remain valid until the end of a phase-out period, which starts at hard fork activation.

## Specification
The specification for each of this CHIP’s features will be listed individually.

### Fork activation
We will release Chia version 3.0.0, which will implement the hard fork. The fork will activate in the block immediately following the first *transaction* block, with a later signage point, at or above height 8’800’000. This is expected to happen around 2026-06-01.
A signage point may have multiple blocks. If the block immediately following the transaction block at the activation height happens to be on the same signage point, it will also be pre-activation. The hard fork activates with the next signage point.

Starting with the block in which the hard fork is activated, the new proof-of-space will be accepted.

This hard fork is different from previous forks in that it affects the validity of proofs of space. When farming a block, the harvester does not know (exactly) at what height its proof may be infused. However, it *can* know what the most recent transaction block was.

### Phase-out period
During the phase-out period, original proofs of space will become increasingly unlikely to win a block. The probability of winning a block will be scaled down, linearly, starting at the activation block, to reach 0 probability after 256 days (technically, 4608 x 256 blocks).

In order for a plot to win a block, it first needs to pass the plot filter. The proof’s quality then needs to yield a low enough required iterations, lower than the signage point interval iterations. The required iterations count is part of the block’s infusion point calculation:

```infusion_iterations = (signage_point_iterations + 3 * signage_point_interval_iterations + required_iterations) % sub-slot_iterations```

A higher required iteration count means the proof is less likely to be valid.

The phase-out counter (`i`) starts at 0 at the hard fork activation. Every 4608 blocks, it’s incremented by 1. When computing `required_iterations` for original proofs of space, we add `signage_point_interval_iterations * i // 256` to required iterations.

Just like the hard fork activation, each increment of `i` happens immediately following the first transaction block whose height is 8’800’000 + i * 4608 or above.

Once `i` reaches 256, we end up adding `signage_point_interval_iterations` (or more) to the required iterations, so no original proof will ever be valid. This ends the phase-out period and effectively disables the original proof-of-space.

| Blocks w/prev. TX block >= | i | Win prob. factor |
|:-------------------------- | :-- | :--------------- |
| 8800000 | 0 | 1.000 |
| 8804608 | 1 | 0.996 |
| 8809216 | 2 | 0.992 |
| 8813824 | 3 | 0.988 |
| … | … | … |
| 9970432 | 254 | 0.008 |
| 9975040 | 255 | 0.004 |
| 9979648 | 256 | 0.000 |


### Protocol
A `FullNode` object contains a `ProofOfSpace` which has these fields:
```
size: u8,
proof: Bytes,
```
The `size` is not allowed to be less than 32 or greater than 50. After the hard fork, the most significant bit in the `size` field indicates whether the proof is the original proof-of-space (0) or the new proof-of-space (1). The remaining 7 bits then indicate the k-size of the plot that produced the proof.

Valid k-sizes in the new proof-of-space are 28, 30 and 32.
The `proof`s are either v1 or v2 proof-of-space, depending on the most significant bit in the `size` field.

### Plot ID filter adjustments
This is a similar concept to the plot filter for the existing proof format. CHIP-48 provides the technical details of this filter. If required, we can push the dates of these adjustments further into the future with a soft fork.

The current proposal is to start the plot ID filter at 32 and cut it in half every two years until it reaches 1. The block heights of the filter adjustments are shown in the table in the next section.

### Proof fragment scan filter adjustments
Only certain proof fragments will pass the proof fragment scan filter. The current proposal is to start the proof fragment scan filter at 32 (1/32 proof fragments will pass it) and cut it in half every two years until it reaches 1.

The following table shows when both the plot ID filter, and the proof fragment scan filter will initially be set to adjust, as well as their values after the adjustments. This table is identical for both of the filters.

| Block height | Month/Year (app.) | ID and fragment filters |
|:------------ | :---------------- | :---------------------- |
| 8’800’000 | May 2026 | 32 |
| 12’163’840 | May 2028 | 16 |
| 15’527’680 | May 2030 | 8 |
| 18’891’520 | May 2032 | 4 |
| 22’255’360 | May 2034 | 2 |
| 25’619’200 | May 2036 | 1 |

It is difficult to predict advancements in technology, so these filters are intentionally set to be rather aggressive in their scheduled adjustments. If we feel that we can delay one or both of the filters, then this can be done in a future soft fork.

### Plot strength adjustments
As detailed in CHIP-48, every plot will include a “strength” parameter, which will adjust how much time is required to create Table 3, _ceteris paribus_. If a given plot's strength is `n`, then creating Table 3 will require `2^n` times longer than the minimum amount of time. (Harvesting time is unaffected by the plot’s strength.) At a given block height, the network will only accept plots that meet the current minimum strength threshold. The strength parameter will be an 8-bit unsigned integer, so the maximum strength will be `255`.

The current proposal is to start the minimum strength at `2`, and to adjust it upward as needed. Adjusting the minimum strength will require a soft fork. Each increase in the minimum strength will require some portion of the netspace to be replotted in order to continue farming. Therefore, the plan will be to propose a lengthy lead time before any increases in the minimum strength take effect.

For example, if we proposed to increase the minimum strength from `2` to `5`, then all plots with strength `2`, `3`, or `4` would no longer be able to farm after the increase went into effect. We therefore would provide a lengthy warning (perhaps six or twelve months) for the fork to activate.

In order to decrease the number of expected replots, some farmers might initially choose to plot to a high strength. In order to keep up with advances in technology, we might need to increase the minimum strength every two years (though keep in mind that this is a rough estimate). If a farmer estimated that the lifespan of their farm's HDDs would be eight years, then they might consider initially plotting to four levels above the current minimum strength. That way, by the time of the next expected replot, their HDDs would have already exceeded their expected lifespan.

One thing to note is that a given farm can contain plots with various strength levels. Some farmers may choose a strategy of plotting their entire farm at the minimum current strength, and then gradually replacing their plots with higher-strength plots over time. Plots of the same k-size will be approximately the same size, regardless of strength.

### keccak256
The `keccak256` operator was previously added via soft fork, and is therefore only available under the `softfork` operator. Its usage (both inside and outside the `softfork` guard) is described in [the Specification section of CHIP-36](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0036.md#specification). After block 8,800,000, the `keccak256` operator will become part of the core CLVM, so it will be usable by calling it directly. It will also continue to be usable from inside the `softfork` guard.

### Condition cost
After the hard fork activates, the limit of 1024 announcement conditions per spend will be removed.

Instead, for each CoinSpend, conditions will have a cost of 500, **except** for the first 100 conditions, which will not incur an additional cost. This is in addition to any existing cost for the condition. This cost applies to all conditions, including unknown conditions, `SOFTFORK`, `CREATE_COIN` and `AGG_SIG_*` conditions.

## Test Cases
We will add any needed test cases prior to this CHIP’s completion.

## Reference Implementation
We will include links to the reference implementation prior to this CHIP’s completion.

## Security
The majority of the security work for the new proof format can be found in CHIP-48. That said, CNI will also perform an internal audit of the code updates involved with this CHIP.

## Additional Assets
None

## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).