diff --git a/docs/chia-blockchain/consensus/forks.md b/docs/chia-blockchain/consensus/forks.md index d18107e5fd..cc2b1dc831 100644 --- a/docs/chia-blockchain/consensus/forks.md +++ b/docs/chia-blockchain/consensus/forks.md @@ -3,7 +3,7 @@ title: Forks slug: /chia-blockchain/consensus/forks --- -The following table is a comprehensive list of all forks (planned and activated) on Chia's blockchain. It was last updated on 2024-12-19. +The following table is a comprehensive list of all forks (planned and activated) on Chia's blockchain. It was last updated on 2026-03-03. | Activation Block | Activation Date | Type | Build | Status | Description | | :--------------- | :-------------- | :--- | :---- | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -15,3 +15,5 @@ The following table is a comprehensive list of all forks (planned and activated) | `5 716 000` | 2024-07-30 | Soft | 2.3.0 | Activated | [CHIP-25](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0025.md) -- Chialisp Message Conditions | | `5 940 000` | 2024-09-17 | Soft | 2.4.0 | Activated | Disallow infinity G1 points | | `6 800 000` | 2025-03-22 | Soft | 2.5.0 | Activated | [CHIP-36](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0036.md) -- keccak256 CLVM operator | +| `8 655 000` | 2026-04 | Soft | 2.6.0 | Released | Increased preliminary support for V2 plot format -- [Release notes](https://github.com/Chia-Network/chia-blockchain/releases/tag/2.6.0) | +| `9 562 000` | 2026-11 | Hard | 3.0.0 | Planned | [CHIP-48](https://github.com/Chia-Network/chips/pull/160), [CHIP-49](https://github.com/Chia-Network/chips/pull/161) -- New Proof of Space | diff --git a/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-faq.md b/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-faq.md index eade3baf73..da0c4989ca 100644 --- a/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-faq.md +++ b/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-faq.md @@ -9,7 +9,7 @@ import TabItem from '@theme/TabItem'; :::note -This information was updated on 5/20/2025. +This information was updated on March 3, 2026. ::: @@ -17,90 +17,167 @@ This page will answer your most common questions. Expect it to grow with time. ### What will this break/change? -Initially nothing, to give everyone time to upgrade. When the hard fork becomes activated six months after the release of Chia 3.0 there will be changes to the blockchain consensus which will cause non-upgraded full nodes and wallets to break. The upgrades software vendors will need to make before then are small and will be included in the reference codebase. Farmers will have to replot during the transition period and use upgraded plotters and harvesters. The computational requirements for harvesting will be slightly larger than with the original plot file format but vastly less than for compressed plots. +When the hard fork activates at block `9'562'000` (November 2026), there will be changes to the blockchain consensus which will cause non-upgraded full nodes and wallets to break. The upgrades software vendors will need to make before then are small and will be included in the reference codebase. Farmers will have to replot during the transition period. The min spec hardware from farming will be increased to a Raspberry Pi 5 with 8 GB of RAM (currently, it's a Pi 4). + +### If I use the reference wallet, but I’m not a farmer, will I need to upgrade anything? + +Yes, you will need to upgrade your wallet to version 3.0 before block 9,562,000. If you fail to do so, then your wallet may fall out of sync until you perform the upgrade. However, the funds contained within your wallet will remain secure. + +### If I use the Cloud Wallet, will I need to upgrade anything? + +CNI runs several nodes to host the Cloud Wallet infrastructure, so all you will need to do is occasionally refresh your browser window to pick up any changes. + +### How about if I use Sage or another ecosystem wallet? + +If you use any ecosystem wallet including Sage, you will need to make sure to stay upgraded to the latest version of your wallet software. The operators of those wallets will be responsible for upgrading their own infrastructure. ### When will I be able to farm with new plots on mainnet? -After the hard fork date, currently expected at height 8’800’000. This is expected to happen around 2026-06-01 (see [timeline](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline)). +You will be able to farm with PoS2 plots when the 3.0 hard fork activates. This is currently scheduled for block `9'562'000`, expected to occur in November 2026. See our [timeline](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline) for more details. ### When will the old plot format be fully phased out? -By the end of the transition period, currently expected 1H 2027 (see [timeline](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline)). +After the fork activates, there will be a transition period of 256 days, during which PoS1 plots will become less likely to win. The last block in which PoS1 plots are expected to be valid is `10'741'648`, which should occur in June or July 2027. See our [timeline](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline)) for more details. ### When should I replot? Sometime during the transition period. When will be best for you will depend on your setup, but there will be a long enough time that the plots compliant with the new format will be neutral in weight to your existing plots so you can do it at your leisure. We will provide guidelines on how to evaluate which time window would be ideal to transition for your setup. -### With a modern GPU such as a 3090, what will be my expected plot times? +### With a modern GPU such as a 5090, what will be my expected plot times? -Around - minutes for a - plot (Pending Plot ID Filter and Plot Difficulty settings. Aim will be for 3060 to plot >20TiB/day). See our table of [expected plot times](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-plotting-requirements#plotting-performance-and-requirements). +Around 2 seconds per plot, or 40 TiB per day for minimum-strength plots. See our table of [expected plot times](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-plotting-requirements#plotting-performance-and-requirements). ### Will you also support CPU plotting, and if so, what will be my expected plot times? -CPU plotting will be supported but will not be recommended for plotting any significant amount. A multi-threaded CPU will be about - slower than a 3090, potentially completing a k30 in - minutes. The more CPU threads and memory channels your system has will reduce this time. (Pending Plot ID Filter and Plot Difficulty settings. Aim will be for 3060 to plot >20TiB/day) +CPU plotting will be supported, but will be slower than GPU plotting. A 6-core Ryzen 5600 will plot create minimum-strength plots in around 30 seconds, or around 4 TiB per day. + +### How much RAM/VRAM will I need to plot? + +For all-RAM plotting with a GPU, the current usage without swapping is around 12 GB of VRAM. It might be possible to lower this number, but this is not a guarantee. As for all-RAM CPU plotting, 16 GB will be the maximum amount needed. ### What will the hardware requirements be for harvesters? -Harvesting consists of two main components: plot retrieval and proof solving when a good proof is found. +The minimum spec hardware for harvesting and farming is a Raspberry Pi 5 with 8 GB of RAM. This computer will be able to farm around 2 PiB of storage without any issues. + +See our [farming requirements](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-farming-requirements) for more detailed information. -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. +### What is plot strength? -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. +This term refers to the amount of compute that was needed to generate a plot. Each increment in strength will require around double the compute. The hardware requirements to create a plot, as well as its final size are unaffected. -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. +The minimum strength will begin at 0, and we will raise it as needed to maintain the network’s security. However, we do not intend to increase the minimum strength until at least 2036. -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. +### Why would I want to plot at a higher strength than the minimum? -See our [farming requirements](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-farming-requirements) for more detailed information. +The primary reason would be to reduce disk usage. Plots created at a higher strength will need to be accessed less frequently. A second reason would be to increase your plots’ longevity. However, we expect (though can’t guarantee) plots created at the minimum strength today to remain valid for a decade, so we don’t expect many farmers to plot at higher strengths for this reason alone. + +### Will there be a maximum plot strength? + +Yes. The maximum strength will start at 8, and will increment as the base filter is decreased. Strength needs to be capped in order to ensure that the network’s minimum spec hardware can validate all proofs in a timely manner. + +### Will “stronger” plots win more often? Less often? Neither? + +Neither. If plot B is twice as “strong” as plot A, then it will pass the filter half as often, and it will be twice as likely to find a valid proof once it does pass the filter. As a result, the long-term expected earnings of both plots will be identical. + +### How much longer will the creation time be for plots created at strengths higher than the minimum? + +At the lowest strength intervals, increasing the strength by one level will require slightly less than double the creation time. This is due to some overhead in the creation process. After around strength=4, the overhead will be negligible, so plots created at higher strengths will need almost exactly twice as long to be created. + +### Can I use an HDD as a temporary drive while creating large groups, or is RAM or an SSD required? + +An HDD will typically write at 250MB/s, which takes 4 seconds per plot in the group to write. This could be done in a background thread while creating the next plot for the group. So, it becomes a bottleneck only if you are plotting faster than 1 plot every 4 seconds. And even in that case, you could alleviate the bottleneck by increasing the plot strength so that it takes longer than 4 seconds to create each plot. + +Once all plots in the group have been written to temporary storage, you can run another single-thread to merge them into the final grouped plot. That will take as long as the HDD takes to read all data and rewrite it to the target destination. CPU load would only take 1 thread, and memory load could be less than 1 GB. During this process, you could begin creating plots for a new group with a different process. + +TLDR: Yes, you could use a spare HDD to make the big grouped plots without much impact on your plotting times. + +### How are groups stored on disk? As a single file? Multiple files? + +It’s possible to divide a group into as many files as needed. If you follow our recommendations and use groups of 64 or 128 plots, then you will probably want each of your groups to consist of a single file. + +### Why would I want to separate my group into multiple files? -### What is the difficulty level in the new format? +To avoid having to use a large temporary space. Recall that while creating plots to be included in a single group, you need to store the completed plots somewhere temporarily. -The new plot format allows us to tune a difficulty setting to directly influence plot time. The higher the plot time, the more compression resistant the format becomes. However, we need to balance the difficulty with what should be an acceptable plotting time for most farmers, yet still have enough difficulty for significant compression resistance. +Let’s say you have a 20 TB HDD and you decide to fill it with a single group of 20,000 plots. If you only created one file, then you would need another 20 TB on which to store the plots temporarily, before combining them into a single file. This could be slow and cumbersome to achieve. If instead, you created 200 files of 100 GB each, then you would only need 100 GB of storage, which would allow for in-RAM temp storage on many systems. In both cases, the result is a single group of 20 TB, but in the former case you have one file, and in the latter case you have 200 files. -Each plot in the new format has a difficulty setting, which must be between 0 and 255. With each increment of the setting, the plot will require approximately twice as much time to be created. (The hardware requirements to create a plot, as well as its final size are unaffected.) +### Why shouldn’t I break down a group even further? Why not use 1000 files? -After the hard fork activates, the network will have a minimum difficulty level for all plots created with the new format. Any plots that were created with an easier difficulty level will be invalid. In order to plan for advancements in technology, the minimum difficulty level will be set to increase every two years going forward. The timeline is intentionally aggressive -- we can relax this schedule with a soft fork if needed. +To prevent taking too long to submit a valid proof. By definition, each file from the same group will pass the filter together. When this happens, each file will undergo two disk seeks. On an HDD, each seek might take 10 ms. If you have 1000 files in the same group, then 2000 disk seeks will be needed, and this will require upwards of 20,000 ms, or 20 seconds. This is too much time – taking more than 8 seconds risks being too much time to find and submit a proof. -As a result of the minimum difficulty adjustments, each plot will have an effective expiration time. Farmers can use this data to replot to a difficulty level that makes sense for their setup. [CHIP-49](https://github.com/Chia-Network/chips/pull/161) contains a section titled `Plot difficulty adjustments`, which goes into greater detail. +### Will I need to use meta groups? Why or why not? + +Meta groups are not required. The primary use case for meta groups is to smooth disk usage as much as possible. The vast majority of farmers today can forgo meta groups without any noticeable difference. Meta groups should be considered an advanced feature. + +### Why even include meta groups if almost nobody will use them? + +They could be quite helpful in the future. Whereas today, most HDDs used for farming are around 20-24 TB, a decade from now they could be 200 TB, or even larger. A 200 TB HDD filled with groups of 128 plots would require over 1500 files to be stored on disk. In this case, the load might spike so much that the disk isn’t able to keep up at certain signage points. We wanted to include this feature today so that it will be available when it is needed in the future. + +### If I don’t want to use meta groups, will I still need to specify a meta group, or will there be a default? + +Each group will be assigned the default meta group of 0 if left unspecified. + +### If I have 10 groups with one meta group, are they guaranteed to pass the filter at the same time? + +No. If you have 10 groups with one meta group, then each group will pass (or not pass) the filter independently. It would be like rolling 10 dice. You might roll zero 1s or ten 1s, or anything in between. Each die acts independently of each other die. + +On the other hand, if you have 10 groups, each of which is assigned a unique meta group, then you have a guarantee that at most one of your plots groups will pass the filter at a given signage point. + +### What is the largest farm size supported in PoS v2? + +There is no effective limit. This is because each group can declare its own meta groups. For example, group A can have plots with group indices 0..65535 within meta group 0. The same group can then have an additional 65,536 plots within meta group 1, and so. Each of the 256 available meta groups can have 65,536 plots assigned to it, so the maximum group size is 2^8 \* 2^16 = 2^24 (16,777,216) plots, or around 16.8 PB for a single group. Farmers can create as many groups as they want, so there farm can grow arbitrarily large (there technically is a limit due to the length of a plot ID, but this is such a large number, it's essentially unlimited). ### How do you know that compression won’t be possible with the new format? Compression is always possible, but the incentive will be severely limited. For instance, you could compress 100% of the plot by constructing a plot on the fly in under 30 seconds when a signage point comes in. However, this would require a cluster of the latest GPUs to achieve, and would cost hundreds of thousands of dollars, just to spoof the space taken up by less than a TB. Alternatively, a farmer could make a plot with just 1 bit dropped per entry, and save ~0.5% of space. However, even this could incur more energy per TiB than the honest farmer. -In the future we expect extremely high efficiency in compute, however, storage will also improve in cost and efficiency during that time. With the advent of extremely low power SSDs when on idle, most farmers will be better off staying with the default plot format. Those farmers looking to squeeze the most out of their system by bit-dropping for extra levels of compression might achieve marginal gains despite higher energy costs per eTiB, but risk needing to replot and adjust their systems based on price fluctuations. If compute efficiency significantly outpaces gains in storage cost and efficiency, we could see bit-dropping with recompute reaching up to 10% space savings with marginal extra % gains in net rewards. +In the future we expect extremely high efficiency in compute, however, storage will also improve in cost and efficiency during that time. With the advent of extremely low power SSDs when on idle, most farmers will be better off staying with the default plot format. Those farmers looking to squeeze the most out of their system by bit-dropping for extra levels of compression might achieve marginal gains despite higher energy costs per eTiB, but risk needing to replot and adjust their systems based on price fluctuations. ### Will there still be a plot filter after the new format is available? -Yes -- it is a similar concept to the plot filter for the existing proof format. [CHIP-48](https://github.com/Chia-Network/chips/pull/160) 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. +In PoS2, there are two related filters to consider: the network's base filter, and the effective filter for a plot or a group. + +The base filter indicates the lowest filter allowed for all plots across the network. This filter will start `512` and will automatically be adjusted downward every 3-6 years at pre-defined block heights, until it reaches `1`, where it will remain. The following table shows the built-in reductions to the base filter: + +| Block height | Year | Base Filter Bits | Base Filter | +| :----------- | :--- | :--------------- | :---------- | +| ` 9'562'000` | 2026 | 9 | 512 | +| `19'663'000` | 2032 | 8 | 256 | +| `24'708'000` | 2035 | 7 | 128 | +| `29'759'000` | 2038 | 6 | 64 | +| `34'809'000` | 2041 | 5 | 32 | +| `39'860'000` | 2044 | 4 | 16 | +| `44'905'000` | 2047 | 3 | 8 | +| `49'956'000` | 2051 | 2 | 4 | +| `55'006'000` | 2054 | 1 | 2 | +| `60'056'000` | 2057 | 0 | 1 | -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. +In the scenario where we feel comfortable with delaying these reductions, we will do so with a soft fork. -### How many times will I have to replot? +Each plot will also have its own `effective filter`, which determines the likelihood that it is eligible to participate in a challenge at a given signage point. The effective filter is calculated based on a given plot's strength -- for each level above the minimum strength, a plot's effective filter is doubled. For example, if a plot's strength is 1 level above the minimum, and the base filter is 512, then that plots's effective filter is 1024. -This depends on your plots' difficulty level, [as explained above](#what-is-the-difficulty-level-in-the-new-format). For example, if you want to delay replotting for at least six years, you can create your plots with a difficulty level at least three levels above the minimum. +There is also a `maximum effective filter` of `8192`, regardless of the plot's strength. This is imposed to prevent certain attacks that could occur with very high strengths. ### What's this about different HDD and SSD plot formats (i.e. what is benes compression)? -As the new Proof of Space was being developed, one consideration was whether Benes Compression would be possible on HDDs and initially it was proposed that there would be an HDD format without Benes compression and an SSD format with Benes compression. -Prior to publishing [CHIP-48](https://github.com/Chia-Network/chips/pull/160) it was determined that Benes Compression can be performed on HDDs so now there will be only one format for both HDD and SSD. +While our original thinking was to release two separate formats, we have now simplified the design so that only a single format is needed for both HDDs and SSDs. As for Benes compression, while it originally was an intriguing way to reduce plots by a few percent, this is no longer needed in our simplified design, so we have also dropped our plans to use it. ### How much space will someone be able to save using GPU compression? -It will be possible to save a few percent of space using bit dropping but the costs will go up exponentially. Currently we expect a 4090 on a large farm may be incentivized to compress up to 2-3% of the plot size, although this is still subject to change based on the final tuning parameters for the proof of space. +PoS2 uses a single-table design, in which plots are one continuous blob of sorted data, with no additional table pointers, back-references, or structural redundancies. This design effectively eliminates economically viable plot compression. In theory, one could save 2-3% via bit-dropping, but it would require multiple orders of magnitude in additional compute to reconstruct the plots in real time. ### For an energy-conscious farmer, what will be the optimal CPU or GPU for farming? -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. +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. This would result in a 3-6% increase in energy consumption when using k28 instead of k32 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. - -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. +For HDD-based farms, HDDs consume more power (typically around 50 to 100% more) when actively reading compared to being idle. While more benchmarking will be needed, it may make sense over the long run for some farmers to plot at a high difficulty level so that they can idle (or even power down) their HDDs most of the time. They will use more compute/energy when initially creating their plots, in exchange for reduced ongoing energy consumption; there is not a straightforward equation to determine which approach will be more energy-efficient without taking multiple factors into account. ### When do you expect the CHIP to be made publicly available? -On 05/19/2025 we published [CHIP-48](https://github.com/Chia-Network/chips/pull/160) for the new PoS specification and [CHIP-49](https://github.com/Chia-Network/chips/pull/161) for the timelines associated with its integration. +There are two publicly available CHIPs related to PoS2: + +- [CHIP-48](https://github.com/Chia-Network/chips/pull/160) describes the specification for PoS2 +- [CHIP-49](https://github.com/Chia-Network/chips/pull/161) details the timelines for PoS2, as well as some other unrelated changes that will go into the hard fork ### When can I review the source code for plotting? @@ -108,34 +185,20 @@ The source code is located in the [pos2-chip](https://github.com/Chia-Network/po ### Have you decided how long the transition period will be? -6-12 months. To provide feedback and discuss this transition period please refer to [CHIP-49](https://github.com/Chia-Network/chips/pull/161). +The transition period will last 256 days, starting with the fork's activation. To provide feedback and discuss this transition period please refer to [CHIP-49](https://github.com/Chia-Network/chips/pull/161). ### How will grinding be prevented? -[CHIP-48](https://github.com/Chia-Network/chips/pull/160) contains a detailed analysis of various grinding attacks and how the new PoS protects from them. - -### What metrics should we look at in determining whether grinding will be possible (plot size, plot speed, filter size, etc)? - -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. +Plot grinding will be possible, but not economical. For example, a 5090 GPU `($3700)` will be only able to mimic around 20 TB `($20)` of storage via plot grinding. This nearly 200x price difference doesn't take into account the ongoing electricity usage of running a 5090 continuously, versus what an HDD might use. -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. +[CHIP-48](https://github.com/Chia-Network/chips/pull/160) contains a detailed analysis of various grinding attacks and how the new PoS protects from them. ### Under the current settings for the new format, for how long do you expect to be able to support k-28? -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. +We have no plans for dropping support for k28 plots. It is expected to be the only valid plot size going forward. 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. - ### What are the settings that could be changed in a hard/soft fork to prevent grinding or other techniques to turn PoSpace into PoW? [CHIP-49](https://github.com/Chia-Network/chips/pull/161) contains a detailed analysis of the various settings that can be changed to protect from grinding and other techniques. diff --git a/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-farming-requirements.md b/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-farming-requirements.md index 1aa8acb108..3f817e1b33 100644 --- a/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-farming-requirements.md +++ b/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-farming-requirements.md @@ -9,32 +9,69 @@ import TabItem from '@theme/TabItem'; :::note -This information was updated on 5/20/2025. +This information was updated on March 3, 2026. ::: -In general, the larger your farm, the more powerful your harvesters will need to be. However, keep in mind that one farm can be broken into multiple harvesters, so it is possible to run a large farm without any high-end equipment. - ## 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 security has been tuned for the Pi 5 to solve a k28 proof in under 8 seconds. +After a sufficiently high-quality Quality String is found, the solver reconstructs the full 128 x-values for network verification. Solve time depends on the maximum plot strength in the farm. The Pi5 solves a k=28 proof in under 8 seconds at strengths up to +4. + +| Strength | Raspberry Pi 5 | M3 Pro | Ryzen 9 9950X | +| -------- | -------------- | ----------------- | ---------------- | +| base | ~4.3 s | ~340 ms | ~220 ms | +| +1 | ~4.5 s | ~370 ms | ~240 ms | +| +2 | ~4.9 s | ~450 ms | ~280 ms | +| +3 | ~5.7 s | ~660 ms | ~400 ms | +| +4 | ~7.3 s | ~1.1 s | ~615 ms | +| +5 | ~10 s | ~1.9 s | ~1.1 s | +| +6 | ~17 s | ~3.7 s | ~1.9 s | +| +7 | ~30 s | ~7.3 s | ~3.7 s | +| +8 | — | ~14.5 s | ~7.3 s | +| +n | — | ~2^(n−8) × 14.5 s | ~2^(n−8) × 7.3 s | + +Strengths +5 and above are capped at effective plot filter 8192 until the scheduled filter adjustments take effect. :::note See the [reference code](https://github.com/Chia-Network/pos2-chip) for benchmarking your own system on the Solver. ::: -| Plot Size | Raspberry Pi 5 | Ryzen 5600 (6-core) | Threadripper | Nvidia 3060 | -| --------- | -------------- | ------------------- | ------------ | ----------- | -| k28 | ~6.8 seconds | ~1 seconds | < 1 second | 60 ms | -| k30 | ~15.6 seconds | ~3.3 seconds | < 3 seconds | 240 ms | -| k32 | N/A | ~11.7 seconds | < 8 seconds | 960 ms | +#### HDD Activity + +HDD activity depends on plot grouping, plot strength, and disk capacity. The table below assumes 10 ms random access and 250 MB/s sequential read. Higher plot strength increases the Effective Plot Filter proportionally, reducing average load. + +| Disk Capacity | Strength (eff. plot filter) | Group Size | Max load/challenge | Avg load | Bandwidth/day | +| ------------- | --------------------------- | ---------- | ------------------ | -------- | ------------- | +| 5 TB | base (512) | 1 | ~4.48% | ~2.09% | ~42 MB | +| 5 TB | base (512) | 16 | ~0.85% | ~0.13% | ~42 MB | +| 5 TB | +1 (1024) | 16 | ~0.64% | ~0.07% | ~21 MB | +| 5 TB | +2 (2048) | 16 | ~0.43% | ~0.03% | ~10 MB | +| 5 TB | +3 (4096) | 16 | ~0.21% | ~0.01% | ~5 MB | +| 20 TB | base (512) | 1 | ~12.4% | ~8.4% | ~170 MB | +| 20 TB | base (512) | 2 | ~7.4% | ~4.2% | ~170 MB | +| 20 TB | base (512) | 16 | ~2.2% | ~0.52% | ~170 MB | +| 20 TB | base (512) | 32 | ~1.31% | ~0.27% | ~170 MB | +| 20 TB | base (512) | 64 | ~0.89% | ~0.14% | ~170 MB | +| 20 TB | base (512) | 100 | ~0.69% | ~0.09% | ~170 MB | +| 20 TB | base (512) | 1000 | ~0.47% | ~0.01% | ~170 MB | +| 100 TB | base (512) | 32 | ~3.42% | ~1.32% | ~850 MB | +| 100 TB | base (512) | 64 | ~2.15% | ~0.65% | ~850 MB | +| 100 TB | base (512) | 100 | ~1.85% | ~0.46% | ~850 MB | +| 100 TB | base (512) | 1000 | ~0.47% | ~0.05% | ~850 MB | + +Plots in a group can be assigned a `meta_group` (up to 256). The effective plot filter guarantees that grouped plots with different meta groups never pass the same challenge, reducing peak load toward the average. For example, 202 meta groups × 100 grouped plots = 20,200 plots, where peak load converges to ~0.09%. + +Total daily bandwidth is low, so even large group counts can be read well within the challenge response window. -### HDD Activity +#### Harvester Farm Size Support -Lower k-sizes increase disk activity but reduce minimum hardware requirements for proof solving (see previous section). For SSDs, k28 plots are recommended due to their minimal impact on farming performance, although large farms could benefit from larger k sizes for a proportional reduction in harvesting compute energy to process the Quality Chains. The Plot ID Filter will tune HDD disk activity to the levels shown in the table. Depending on plot filter scheduling and further security analysis we may relax these requirements to lower hdd usage levels. +Chaining Proof Fragments at challenge time is the primary CPU cost. The table below shows single-thread Pi5 limits (conservative, since the Pi5 has 4 threads and other harvester tasks are comparatively light). -| Plot Size | Full 5TiB Disk Activity | Full 20TiB Disk Activity | -| --------- | ----------------------- | ------------------------ | -| k28 | ~2.5% | ~10% | -| k30 | ~0.6% | ~2.4% | -| k32 | ~0.23% | ~0.9% | +| CPU | Avg Plot Strength | Supported Farm Size (PiB) | +| ----------------- | ----------------- | ------------------------------------------------- | +| Pi5 single-thread | base | 1.2 | +| Pi5 single-thread | +1 | 2.4 | +| Pi5 single-thread | +2 | 4.8 | +| Pi5 single-thread | +3 | 9.6 | +| Pi5 single-thread | +4 | 19.2 | +| Pi5 single-thread | +n | 1.2 × 2^n (capped by effective plot filter at +4) | diff --git a/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-introduction.md b/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-introduction.md index 073d84cde0..b453515daa 100644 --- a/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-introduction.md +++ b/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-introduction.md @@ -9,13 +9,13 @@ import TabItem from '@theme/TabItem'; :::note -This information was updated on 5/20/2025. +This information was updated on March 3, 2026. ::: ## New Proof Format -In 2024 we announced that we were developing a new Proof of Space format. This is a long-term project which is not expected to be finalized until the end of 2026. All farmers will need to replot in the year leading up to that date. This will be a gradual process, so farmers will have plenty of time to plan ahead. +In 2024 we announced that we were developing a new Proof of Space format. This is a long-term project which is not expected to be finalized until 2027. All farmers will need to replot if they want to continue farming. This will be a gradual process, so farmers will have plenty of time to plan ahead. See our [timeline](/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline) for more info. :::warning @@ -27,18 +27,13 @@ While the development of this technology is ongoing, we have put together severa ## Current Blogs and CHIPs -The best place to start learning about the new Proof of Space is to read the blogs. - -- The new Proof of Space [blog](https://www.chia.net/2025/05/19/understanding-the-next-generation-proof-of-space/) -- The timelines for the new Proof of Space [blog](https://www.chia.net/2025/05/19/the-future-of-farming-is-green-and-secure/) - -To dive more into the specifications and provide your feedback please refer to the appropriate CHIPs: +The best place to start learning about the new Proof of Space is our [latest blog post](https://www.chia.net/2026/02/27/changes-coming-to-3-0/) on the topic. To dive more into the specifications and provide your feedback, please refer to the appropriate CHIPs: - The new Proof of Space [CHIP-48](https://github.com/Chia-Network/chips/pull/160) -- The timelines for the new Proof of Space [CHIP 49](https://github.com/Chia-Network/chips/pull/161) +- The timelines for the new Proof of Space [CHIP-49](https://github.com/Chia-Network/chips/pull/161) :::note -All the latest information regarding the new Proof of Space and its associated timelines can be found in those CHIPs, if you have questions that you do not feel are appropriate for the CHIPs they can be asked in our [discord server's](https://discord.gg/chia) "Plot format discussion" thread. +All the latest information regarding the new Proof of Space and its associated timelines can be found in those CHIPs. If you have questions that you do not feel are appropriate for the CHIPs they can be asked in our [Discord server's](https://discord.gg/chia) "Plot format discussion" thread. ::: We have consolidated the high level information from the CHIPs into the below documents but please take note that the CHIPs will contain the most up-to-date information: @@ -52,5 +47,10 @@ We have consolidated the high level information from the CHIPs into the below do ## Blog Archive -- A [blog post](https://www.chia.net/2024/12/11/upcoming-changes-for-chias-new-proof-of-space-format) by Dr. Nick, which takes a deep dive into the plans as of 12/11/2024 -- The original [blog post](https://www.chia.net/2024/08/08/approaching-the-next-generation-of-proof-of-space/) by Dr. Nick, which takes a deep dive into the initial plans for the new Proof Format. Note that this blog is outdated and the new blog should be used for the latest information. +These blog poss are listed in reverse chronological order. The newest posts will contain the most up-to-date information. + +- [Changes Coming to 3.0](https://www.chia.net/2026/02/27/changes-coming-to-3-0/) -- 2026-02-27 +- [Understanding the Next Generation of Proof of Space](https://www.chia.net/2025/05/19/understanding-the-next-generation-proof-of-space/) -- 2025-05-19 +- [The Future of Farming is Green and Secure](https://www.chia.net/2025/05/19/the-future-of-farming-is-green-and-secure/) -- 2025-05-19 +- [Upcoming Changes for Chia’s New Proof of Space Format](https://www.chia.net/2024/12/11/upcoming-changes-for-chias-new-proof-of-space-format) -- 2024-12-11 +- [Approaching the Next Generation of Proof of Space](https://www.chia.net/2024/08/08/approaching-the-next-generation-of-proof-of-space/) -- 2024-08-08 diff --git a/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-plotting-requirements.md b/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-plotting-requirements.md index b97d634774..6cf0bdb146 100644 --- a/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-plotting-requirements.md +++ b/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-plotting-requirements.md @@ -9,35 +9,52 @@ import TabItem from '@theme/TabItem'; :::note -This information was updated on 5/20/2025. +This information was updated on March 3, 2026. ::: ## Plot Sizes -The new proof of space format supports plots as small as 1.6 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. +Whereas the original Proof of Space format supported a variety of plot sizes, Proof of Space 2 only supports k28 (around 1 GB per plot). The PoS2 documentation will rarely mention k-size because only a single size is supported. Future proofing will mainly come from automatically reducing the network's base filter, as described in [CHIP-49](https://github.com/Chia-Network/chips/pull/161). -:::note -Subject to change pending final parameters. -::: +## Other Settings -| Plot Size | All RAM | -| :-------- | :------------- | -| k32 | ~10.6 GiB | -| k30 | ~4.2 GiB | -| k28 | ~1.6 GiB | +Farmers will need to choose a _strength_ for their plots, as well as a group size and an optional meta group index. Each of these settings will be documented here when the specification is finalized. For now, refer to [CHIP-48](https://github.com/Chia-Network/chips/pull/160) and [CHIP-49](https://github.com/Chia-Network/chips/pull/161) for more details. ## Plotting Performance and 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. - -:::note -Pending Plot ID Filter and Plot Difficulty settings. Aim will be for 3060 to plot >20TiB/day -::: - -| Plot Size | RAM Requirement | Raspberry Pi 5 | Ryzen 5600 (6-core) | Nvidia 3090 | -| --------------------- | ----------------- | -------------- | ------------------- | ----------------------------- | -| k28 | - GiB (min - MiB) | ~- minutes | ~- minutes | ~ seconds _(min - MiB VRAM)_ | -| k30 | - GiB (min - MiB) | N/A | ~- minutes | ~- seconds _(min - MiB VRAM)_ | -| k32 | - GiB (min - GiB) | N/A | ~- hours | ~- minutes _(min - GiB VRAM)_ | -| **Plotted space/day** | — | Up to - GiB | Up to - GiB | Up to - TiB | +CPU plotting is supported but less efficient than GPU. All times below are for all-RAM plotting; farmers may substitute temporary SSD storage for RAM at a modest speed penalty. + +| | Raspberry Pi 5 8GB | Mac M3 Pro 12GB | Ryzen 5600 (6-core) | Nvidia 5090 | +| --------------------------------- | ------------------ | --------------- | ------------------- | ----------- | +| **Time per plot** (base strength) | 240s | 60s | 30s | 2s | +| **Plotted space/day** | ~360 GiB/day | ~2 TiB/day | ~4 TiB/day | ~40 TiB/day | + +Plotting time approximately doubles with each strength increment. At lower strengths, general memory-management overhead is still a factor; at higher strengths, matching performance dominates and doubling is consistent. + +| Strength | CPU Time (s) | GPU Time (s) | +| -------- | ------------ | ------------ | +| base | 21.8 | 1.1 | +| +1 | 35.5 | 1.9 | +| +2 | 64.7 | 3.7 | +| +3 | 124.4 | 7.3 | +| +4 | 243.1 | 14.4 | +| +5 | 481.3 | 28.6 | +| +6 | 955.8 | 57.0 | +| +7 | 1904.7 | 113.7 | +| +8 | 3802.5 | 227.3 | + +RAM and storage requirements depend on group size: + +| # plots in group | Min CPU RAM | Min GPU RAM (optional) | Total RAM + storage needed | +| ---------------- | ----------- | ---------------------- | -------------------------- | +| 1 | 4 GB | 2 GB | 12 GB | +| 2 | 4 GB | 2 GB | 13 GB | +| 5 | 4 GB | 2 GB | 16 GB | +| 21 | 4 GB | 2 GB | 32 GB | +| 53 | 4 GB | 2 GB | 64 GB | +| 117 | 4 GB | 2 GB | 128 GB | +| 245 | 4 GB | 2 GB | 256 GB | +| 1 + n | 4 GB | 2 GB | (12 + n) GB | + +Temporary storage can substitute for RAM. At higher strengths the relative impact of swap latency decreases. diff --git a/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline.md b/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline.md index a1d0926833..9f1d38c13d 100644 --- a/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline.md +++ b/docs/chia-blockchain/consensus/proof-of-space-2.0/new-proof-timeline.md @@ -9,16 +9,16 @@ import TabItem from '@theme/TabItem'; :::note -This information was updated on 5/20/2025. -For the latest information, refer to [CHIP-49](https://github.com/Chia-Network/chips/pull/161) +This information was updated on March 3, 2026. +For the latest information, refer to [CHIP-49](https://github.com/Chia-Network/chips/pull/161). ::: This table gives a _rough_ timeline of what to expect with the new format. We will know the exact timeline (to within a few days) when we enter the locked in period. -| Time frame | Name | Begins when | Ends when | Description | -| :----------------------- | :---------------------- | :------------------------------- | :------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| 1H 2024 -
2H 2025 | Proposal
period | New format
announced | Chia 3.0
released | \* [CHIP-48](https://github.com/Chia-Network/chips/pull/160) and [CHIP-49](https://github.com/Chia-Network/chips/pull/161) released
\* Feedback welcome | -| 2H 2025 -
1H 2026 | Locked in
period | Chia 3.0
released | Hard fork
activated | \* CHIP is finalized
\* Farmers must upgrade to 3.0
\* Only old plots are valid | -| 1H 2026 -
1H 2027 | Replotting
period | Hard fork
activated | Old format
becomes invalid | \* New plots become valid
\* Old plots remain valid
\* Replot during this period | -| 2H 2027
and beyond | A new era | Old format
becomes invalid | - | \* Only new plots are valid | +| Time frame | Name | Begins when | Ends when | Description | +| :------------------------------------------------- | :---------------------- | :------------------------------- | :------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 1H 2024 -
1H 2026 | Proposal
period | New format
announced | Chia 3.0
released | \* [CHIP-48](https://github.com/Chia-Network/chips/pull/160) and [CHIP-49](https://github.com/Chia-Network/chips/pull/161) released
\* Feedback welcome | +| 1H 2026 -
Nov 2026 (block `9'562'000`) | Locked in
period | Chia 3.0
released | Hard fork
activated | \* CHIPs are finalized
\* Farmers must upgrade to 3.0
\* Only old plots are valid | +| Nov 2026 -
Jun/Jul 2027 (block `10'741'648`) | Replotting
period | Hard fork
activated | Old format
becomes invalid | \* New plots become valid
\* Old plots remain valid
\* Replot during this period | +| 2H 2027
and beyond | A new era | Old format
becomes invalid | - | \* Only new plots are valid | diff --git a/docs/chia-blockchain/resources/generator-identity/technical-specification.md b/docs/chia-blockchain/resources/generator-identity/technical-specification.md index 550475031e..55f3cb03c5 100644 --- a/docs/chia-blockchain/resources/generator-identity/technical-specification.md +++ b/docs/chia-blockchain/resources/generator-identity/technical-specification.md @@ -267,7 +267,7 @@ This roughly **doubles the potential storage per block** for someone willing to ### Cost Coefficient Fitting -**Tools**: Analysis scripts in this repository (see [ANALYSIS_WORKFLOW.md](ANALYSIS_WORKFLOW.md) for details) +**Tools**: Analysis scripts are in GitHub; see [ANALYSIS_WORKFLOW.md](https://github.com/richardkiss/generator-identity-hf-analysis/blob/main/docs/ANALYSIS_WORKFLOW.md) **Data**: @@ -418,7 +418,7 @@ This means: The following design questions need reviewer input before finalizing the cost model: -> **Note**: For a more radical alternative approach, see [Generator as Witness Proposal](GENERATOR_AS_WITNESS_PROPOSAL.md), which proposes not committing to the generator at all (treating it as pure witness). This is presented for discussion but is not part of the current implementation plan. +> **Note**: For a more radical alternative approach, see [Generator as Witness Proposal](https://github.com/richardkiss/generator-identity-hf-analysis/blob/main/docs/GENERATOR_AS_WITNESS_PROPOSAL.md), which proposes not committing to the generator at all (treating it as pure witness). This is presented for discussion but is not part of the current implementation plan. ### Question 1: Unifying SHA256 Tree Hash Cost Models