From 51683268140ab28674bf04c4075a36bf5ea00308 Mon Sep 17 00:00:00 2001 From: danieljperry Date: Mon, 19 May 2025 21:22:33 +0800 Subject: [PATCH 1/6] Add CHIP for fork timelines and assign 49, Draft --- CHIPs/chip-0049.md | 172 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 CHIPs/chip-0049.md diff --git a/CHIPs/chip-0049.md b/CHIPs/chip-0049.md new file mode 100644 index 00000000..d4e8dea8 --- /dev/null +++ b/CHIPs/chip-0049.md @@ -0,0 +1,172 @@ +CHIP Number | 0049 +:------------|:---- +Title | Proof Format Fork Timelines +Description | Provide all necessary timelines for the hard fork to support the new proof format +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 adjustments to the plot ID filter, proof fragment scan filter, and minimum plot difficulty. 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 two new parameters with periodic modifications: the plot ID filter, and the plot difficulty. + +### 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. + +### 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 in the fourth quarter of 2025. This upgrade 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. + +| For blocks whose previous TX block is at or above | i | win probability 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 difficulty adjustments +As detailed in CHIP-48, every plot will include a “difficulty” parameter, which will adjust how much time is required to create Table 3, _ceteris paribus_. If a given plot's difficulty 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 difficulty.) At a given block height, the network will only accept plots that meet the current minimum difficulty threshold, which will increase over time, as detailed below. + +By increasing the minimum threshold, the network will continue to be resistant to rental attacks for the foreseeable future. If required, we can push the dates of these adjustments further into the future with a soft fork. + +Another aspect of the difficulty parameter is that it will give each plot a _de facto_ expiration date. Farmers who want to get set up as quickly as possible can create plots with the current minimum difficulty, with the tradeoff being that their plots will expire the next time the threshold is increased. Farmers who expect to keep their farms running for many years can create plots with a higher difficulty level. This will increase the time required to plot their farms, but it will also mean that they won’t need to replot for a longer period of time. + +One thing to note is that a given farm can contain plots with various difficulty levels. Some farmers may choose a strategy of plotting their entire farm at the minimum current difficulty, and then gradually replacing their plots with higher-difficulty plots over time. The difficulty level doesn’t affect the size of plots. + +The current proposal is to start the difficulty at `2`, adjust it to `4` after two years, and increase it by one every two years thereafter. The difficulty parameter will be an 8-bit integer, so the maximum difficulty will be `255`, which will be reached at least 506 years after the hard fork’s activation. + +The reason to skip difficulty `3` is because this parameter only affects one table, so the plot times don’t exactly double with each increment. In addition, only the first three tables are used for grinding attacks, so their resistance is affected by a higher relative amount as the difficulty is adjusted upward. Finally, the initial difficulty is always applied to every table aside from Table 3. The following table demonstrates this effect for the first several difficulty levels: + +| Difficulty | Table 1 | Table 2 | Table 3 | Table 4 | Table 5 | Plot time | Grinding resistance | +| :--------- | :------ | :------ | :------ | :------ | :------ | :--------- | :------------------ | +| 2 | 4 | 4 | 4 | 4 | 4 | 20 | 12 | +| 4 | 4 | 4 | 16 | 4 | 4 | 32 (1.6x) | 24 (2x) | +| 5 | 4 | 4 | 32 | 4 | 4 | 48 (1.5x) | 40 (1.67x) | +| 6 | 4 | 4 | 64 | 4 | 4 | 80 (1.67x) | 72 (1.8x) | +| 7 | 4 | 4 | 128 | 4 | 4 | 144 (1.8x) | 136 (1.89x) | + +The difficulty adjustments will continue until the difficulty reaches 255. The plot time and grinding resistance will both approach 2x the previous level as the difficulty increases. + +The following table shows the block height and approximate month and year when the minimum plot difficulty will be adjusted. + +| Block height | Month/Year (app.) | Min. difficulty | +| :----------- | :---------------- | :-------------- | +| 8’800’000 | May 2026 | 2 | +| 12’160’000 | May 2028 | 4 | +| 15’530’000 | May 2030 | 5 | +| 18’890’000 | May 2032 | 6 | +| 22’250’000 | May 2034 | 7 | +| 25’620’000 | May 2036 | 8 | + +These adjustments will continue until the minimum difficulty level reaches 255. As with the plot ID filter and the proof fragment scan filter, we can delay these adjustments with a future soft fork. + +### 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; Except for the first 100 conditions (which will not incur an additional cost) conditions will have a cost of 500. 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/). From 5ff939e8e4084c51afb3bda4e94654ae28b08dba Mon Sep 17 00:00:00 2001 From: danieljperry Date: Mon, 19 May 2025 21:35:43 +0800 Subject: [PATCH 2/6] Fix formatting --- CHIPs/chip-0049.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/CHIPs/chip-0049.md b/CHIPs/chip-0049.md index d4e8dea8..53aed90a 100644 --- a/CHIPs/chip-0049.md +++ b/CHIPs/chip-0049.md @@ -1,15 +1,15 @@ CHIP Number | 0049 :------------|:---- -Title | Proof Format Fork Timelines +Title | Proof Format Fork Timelines Description | Provide all necessary timelines for the hard fork to support the new proof format -Author | [Arvid Norberg](https://github.com/arvidn) +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 +Status | Draft +Category | Standards Track Sub-Category | Core Created | 2025-05-19 -Requires | [0048](https://github.com/Chia-Network/chips/pull/160) +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 adjustments to the plot ID filter, proof fragment scan filter, and minimum plot difficulty. This CHIP also proposes a few other hard-fork changes, unrelated to the new proof format. @@ -68,16 +68,16 @@ Just like the hard fork activation, each increment of `i` happens immediately fo 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. -| For blocks whose previous TX block is at or above | i | win probability 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 | +| 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 From 71133daecb3ed2663b0c0180931b6967a8c7fd4a Mon Sep 17 00:00:00 2001 From: danieljperry Date: Mon, 15 Sep 2025 11:13:10 +0800 Subject: [PATCH 3/6] Update Plot Difficulty to Plot Strength --- CHIPs/chip-0049.md | 52 +++++++++++++++++++++++----------------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/CHIPs/chip-0049.md b/CHIPs/chip-0049.md index 53aed90a..c99a2894 100644 --- a/CHIPs/chip-0049.md +++ b/CHIPs/chip-0049.md @@ -12,7 +12,7 @@ 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 adjustments to the plot ID filter, proof fragment scan filter, and minimum plot difficulty. This CHIP also proposes a few other hard-fork changes, unrelated to the new proof format. +[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 adjustments to the plot ID filter, proof fragment scan filter, and minimum plot strength. This CHIP also proposes a few other hard-fork changes, unrelated to the new proof format. ## Motivation ### New proof format @@ -26,7 +26,7 @@ Neither of these issues is an attack on the network itself, but in both cases, t 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 two new parameters with periodic modifications: the plot ID filter, and the plot difficulty. +We will future-proof the new format by introducing two new parameters with periodic modifications: the plot ID filter, and the plot strength. ### 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. @@ -112,41 +112,41 @@ The following table shows when both the plot ID filter, and the proof fragment s 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 difficulty adjustments -As detailed in CHIP-48, every plot will include a “difficulty” parameter, which will adjust how much time is required to create Table 3, _ceteris paribus_. If a given plot's difficulty 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 difficulty.) At a given block height, the network will only accept plots that meet the current minimum difficulty threshold, which will increase over time, as detailed below. +### 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, which will increase over time, as detailed below. By increasing the minimum threshold, the network will continue to be resistant to rental attacks for the foreseeable future. If required, we can push the dates of these adjustments further into the future with a soft fork. -Another aspect of the difficulty parameter is that it will give each plot a _de facto_ expiration date. Farmers who want to get set up as quickly as possible can create plots with the current minimum difficulty, with the tradeoff being that their plots will expire the next time the threshold is increased. Farmers who expect to keep their farms running for many years can create plots with a higher difficulty level. This will increase the time required to plot their farms, but it will also mean that they won’t need to replot for a longer period of time. +Another aspect of the strength parameter is that it will give each plot a _de facto_ expiration date. Farmers who want to get set up as quickly as possible can create plots with the current minimum strength, with the tradeoff being that their plots will expire the next time the threshold is increased. Farmers who expect to keep their farms running for many years can create plots with a higher strength level. This will increase the time required to plot their farms, but it will also mean that they won’t need to replot for a longer period of time. -One thing to note is that a given farm can contain plots with various difficulty levels. Some farmers may choose a strategy of plotting their entire farm at the minimum current difficulty, and then gradually replacing their plots with higher-difficulty plots over time. The difficulty level doesn’t affect the size of plots. +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. The strength level doesn’t affect the size of plots. -The current proposal is to start the difficulty at `2`, adjust it to `4` after two years, and increase it by one every two years thereafter. The difficulty parameter will be an 8-bit integer, so the maximum difficulty will be `255`, which will be reached at least 506 years after the hard fork’s activation. +The current proposal is to start the minimum strength at `2`, adjust it to `4` after two years, and increase it by one every two years thereafter. The strength parameter will be an 8-bit unsigned integer, so the maximum strength will be `255`, which will be reached at least 506 years after the hard fork’s activation. -The reason to skip difficulty `3` is because this parameter only affects one table, so the plot times don’t exactly double with each increment. In addition, only the first three tables are used for grinding attacks, so their resistance is affected by a higher relative amount as the difficulty is adjusted upward. Finally, the initial difficulty is always applied to every table aside from Table 3. The following table demonstrates this effect for the first several difficulty levels: +The reason to skip strength `3` is because this parameter only affects one table, so the plot times don’t exactly double with each increment. In addition, only the first three tables are used for grinding attacks, so their resistance is affected by a higher relative amount as the strength is adjusted upward. Finally, the initial strength is always applied to every table aside from Table 3. The following table demonstrates this effect for the first several strength levels: -| Difficulty | Table 1 | Table 2 | Table 3 | Table 4 | Table 5 | Plot time | Grinding resistance | -| :--------- | :------ | :------ | :------ | :------ | :------ | :--------- | :------------------ | -| 2 | 4 | 4 | 4 | 4 | 4 | 20 | 12 | -| 4 | 4 | 4 | 16 | 4 | 4 | 32 (1.6x) | 24 (2x) | -| 5 | 4 | 4 | 32 | 4 | 4 | 48 (1.5x) | 40 (1.67x) | -| 6 | 4 | 4 | 64 | 4 | 4 | 80 (1.67x) | 72 (1.8x) | -| 7 | 4 | 4 | 128 | 4 | 4 | 144 (1.8x) | 136 (1.89x) | +| Strength | Table 1 | Table 2 | Table 3 | Table 4 | Table 5 | Plot time | Grinding resistance | +| :------- | :------ | :------ | :------ | :------ | :------ | :--------- | :------------------ | +| 2 | 4 | 4 | 4 | 4 | 4 | 20 | 12 | +| 4 | 4 | 4 | 16 | 4 | 4 | 32 (1.6x) | 24 (2x) | +| 5 | 4 | 4 | 32 | 4 | 4 | 48 (1.5x) | 40 (1.67x) | +| 6 | 4 | 4 | 64 | 4 | 4 | 80 (1.67x) | 72 (1.8x) | +| 7 | 4 | 4 | 128 | 4 | 4 | 144 (1.8x) | 136 (1.89x) | -The difficulty adjustments will continue until the difficulty reaches 255. The plot time and grinding resistance will both approach 2x the previous level as the difficulty increases. +The strength adjustments will continue until the strength reaches 255. The plot time and grinding resistance will both approach 2x the previous level as the strength increases. -The following table shows the block height and approximate month and year when the minimum plot difficulty will be adjusted. +The following table shows the block height and approximate month and year when the minimum plot strength will be adjusted. -| Block height | Month/Year (app.) | Min. difficulty | -| :----------- | :---------------- | :-------------- | -| 8’800’000 | May 2026 | 2 | -| 12’160’000 | May 2028 | 4 | -| 15’530’000 | May 2030 | 5 | -| 18’890’000 | May 2032 | 6 | -| 22’250’000 | May 2034 | 7 | -| 25’620’000 | May 2036 | 8 | +| Block height | Month/Year (app.) | Min. strength | +| :----------- | :---------------- | :------------ | +| 8’800’000 | May 2026 | 2 | +| 12’160’000 | May 2028 | 4 | +| 15’530’000 | May 2030 | 5 | +| 18’890’000 | May 2032 | 6 | +| 22’250’000 | May 2034 | 7 | +| 25’620’000 | May 2036 | 8 | -These adjustments will continue until the minimum difficulty level reaches 255. As with the plot ID filter and the proof fragment scan filter, we can delay these adjustments with a future soft fork. +These adjustments will continue until the minimum strength level reaches 255. As with the plot ID filter and the proof fragment scan filter, we can delay these adjustments with a future soft fork. ### 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. From 8d7ab9e42aa710628071d52430a95eae671c9ef9 Mon Sep 17 00:00:00 2001 From: danieljperry Date: Thu, 25 Sep 2025 15:48:06 +0800 Subject: [PATCH 4/6] Update minimum plot strength strategy to use manual increases instead of automated --- CHIPs/chip-0049.md | 43 +++++++++---------------------------------- 1 file changed, 9 insertions(+), 34 deletions(-) diff --git a/CHIPs/chip-0049.md b/CHIPs/chip-0049.md index c99a2894..4faf6197 100644 --- a/CHIPs/chip-0049.md +++ b/CHIPs/chip-0049.md @@ -12,7 +12,7 @@ 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 adjustments to the plot ID filter, proof fragment scan filter, and minimum plot strength. This CHIP also proposes a few other hard-fork changes, unrelated to the new proof format. +[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 @@ -26,7 +26,7 @@ Neither of these issues is an attack on the network itself, but in both cases, t 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 two new parameters with periodic modifications: the plot ID filter, and the plot strength. +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. @@ -46,7 +46,7 @@ Even though the original plot format will be disabled by this CHIP, it will rema The specification for each of this CHIP’s features will be listed individually. ### Fork activation -We will release Chia version 3.0.0 in the fourth quarter of 2025. This upgrade 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. +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. @@ -113,40 +113,15 @@ The following table shows when both the plot ID filter, and the proof fragment s 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, which will increase over time, as detailed below. +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`. -By increasing the minimum threshold, the network will continue to be resistant to rental attacks for the foreseeable future. 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 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. -Another aspect of the strength parameter is that it will give each plot a _de facto_ expiration date. Farmers who want to get set up as quickly as possible can create plots with the current minimum strength, with the tradeoff being that their plots will expire the next time the threshold is increased. Farmers who expect to keep their farms running for many years can create plots with a higher strength level. This will increase the time required to plot their farms, but it will also mean that they won’t need to replot for a longer period of time. +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. -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. The strength level doesn’t affect the size of plots. +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. -The current proposal is to start the minimum strength at `2`, adjust it to `4` after two years, and increase it by one every two years thereafter. The strength parameter will be an 8-bit unsigned integer, so the maximum strength will be `255`, which will be reached at least 506 years after the hard fork’s activation. - -The reason to skip strength `3` is because this parameter only affects one table, so the plot times don’t exactly double with each increment. In addition, only the first three tables are used for grinding attacks, so their resistance is affected by a higher relative amount as the strength is adjusted upward. Finally, the initial strength is always applied to every table aside from Table 3. The following table demonstrates this effect for the first several strength levels: - -| Strength | Table 1 | Table 2 | Table 3 | Table 4 | Table 5 | Plot time | Grinding resistance | -| :------- | :------ | :------ | :------ | :------ | :------ | :--------- | :------------------ | -| 2 | 4 | 4 | 4 | 4 | 4 | 20 | 12 | -| 4 | 4 | 4 | 16 | 4 | 4 | 32 (1.6x) | 24 (2x) | -| 5 | 4 | 4 | 32 | 4 | 4 | 48 (1.5x) | 40 (1.67x) | -| 6 | 4 | 4 | 64 | 4 | 4 | 80 (1.67x) | 72 (1.8x) | -| 7 | 4 | 4 | 128 | 4 | 4 | 144 (1.8x) | 136 (1.89x) | - -The strength adjustments will continue until the strength reaches 255. The plot time and grinding resistance will both approach 2x the previous level as the strength increases. - -The following table shows the block height and approximate month and year when the minimum plot strength will be adjusted. - -| Block height | Month/Year (app.) | Min. strength | -| :----------- | :---------------- | :------------ | -| 8’800’000 | May 2026 | 2 | -| 12’160’000 | May 2028 | 4 | -| 15’530’000 | May 2030 | 5 | -| 18’890’000 | May 2032 | 6 | -| 22’250’000 | May 2034 | 7 | -| 25’620’000 | May 2036 | 8 | - -These adjustments will continue until the minimum strength level reaches 255. As with the plot ID filter and the proof fragment scan filter, we can delay these adjustments with a future soft fork. +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. @@ -154,7 +129,7 @@ The `keccak256` operator was previously added via soft fork, and is therefore on ### Condition cost After the hard fork activates, the limit of 1024 announcement conditions per spend will be removed. -Instead, for each CoinSpend; Except for the first 100 conditions (which will not incur an additional cost) conditions will have a cost of 500. 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. +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. From 7e767e1daeecdf4cfa915fba1692633476e5e159 Mon Sep 17 00:00:00 2001 From: danieljperry Date: Wed, 1 Oct 2025 12:46:17 +0800 Subject: [PATCH 5/6] Add shatree operator to CHIP-49 --- CHIPs/chip-0049.md | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/CHIPs/chip-0049.md b/CHIPs/chip-0049.md index 4faf6197..44da19a7 100644 --- a/CHIPs/chip-0049.md +++ b/CHIPs/chip-0049.md @@ -1,7 +1,7 @@ CHIP Number | 0049 :------------|:---- -Title | Proof Format Fork Timelines -Description | Provide all necessary timelines for the hard fork to support the new proof format +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) @@ -28,9 +28,26 @@ In the first half of 2024, we made the decision to sunset the existing proof for 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 +### 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. + +### shatree +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 `shatree` in the CLVM is that it will be cheaper to call, both in terms of CPU compute and CLVM cost. + +#### Technical info about shatree + +Opcode: todo + +Argument: Exactly one valid CLVM tree + +Returns: The `sha256` puzzle hash (Merkle root) of the input tree + +Usage: (shatree (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. From 3a537d7db74daf5d7a32aca1a101074f7335377d Mon Sep 17 00:00:00 2001 From: danieljperry Date: Mon, 3 Nov 2025 12:11:48 +0800 Subject: [PATCH 6/6] Update name of shatree to sha256tree --- CHIPs/chip-0049.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/CHIPs/chip-0049.md b/CHIPs/chip-0049.md index 44da19a7..adddea96 100644 --- a/CHIPs/chip-0049.md +++ b/CHIPs/chip-0049.md @@ -33,18 +33,18 @@ The hard fork gives us the opportunity to promote the keccak256 CLVM operator fr The usage and CLVM cost of this operator are provided in CHIP-36. -### shatree -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 `shatree` in the CLVM is that it will be cheaper to call, both in terms of CPU compute and CLVM cost. +### 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 shatree +#### Technical info about sha256tree -Opcode: todo +Opcode: 63 Argument: Exactly one valid CLVM tree Returns: The `sha256` puzzle hash (Merkle root) of the input tree -Usage: (shatree (TREE)) +Usage: (sha256tree (TREE)) CLVM Cost: todo