Chia Editor’s Note [2024-03-06]: We’ve updated this blog to reflect the release of 2.2.1.
Version 2.2.1 of the Chia reference client is now available for download! We recommend everyone to upgrade.
This release comes packed with a number of new features and enhancements, which we have divided into three categories:
- Farming and Wallet Improvements
- Network Improvements
- Developer Tools
Farming and Wallet Improvements
Enhanced harvester protocol
Plotting on Chia has become significantly more efficient since the network’s early days, when ChiaPoS was the only game in town. Today there are many competing plotters; a healthy ecosystem has emerged. Farming on Chia also has greatly improved with the implementation of decentralized pooling.
However, some plotters have eschewed the official pooling protocol in favor of a proprietary model that uses closed-source plotters, farmers and harvesters. This has led to increased netspace centralization.
After meeting with multiple creators of closed-source plotting and farming software, we learned that their primary motivation behind this architecture was ease of use – they wanted a simple way to collect developer fees without making large changes to Chia’s source code.
Armed with this information, we set out to enhance Chia’s harvester protocol, as outlined in CHIP-22. This upgrade allows closed-source harvesters to interact with the reference farmer. Proprietary pools can now collect a dev fee for their hard work, without compromising on Chia’s decentralization. This should be a big win for farmers, pools, and the Chia ecosystem in general.
Increased block utilization
Since the launch of Chia’s mainnet three years ago, block utilization has been capped at 50%. The main reason for this was to ensure that low-power nodes such as the Raspberry Pi could keep up with the network.
We have added a series of optimizations over time to make it easier for these systems to stay in sync. Today, we feel confident that we can begin to increase the block utilization without losing many (or possibly any) nodes. The first step comes in this release, where we will add a modest uptick to 60%.
We plan to ramp up this utilization over time, until we reach the consensus-enforced limit of 100%. As the block fill rate increases, so will the network’s transactions per second (TPS), as well as the average fees when the mempool contains enough transactions to fill a block. When the fill rate reaches 100%, the maximum TPS of the network will top out at around 40.
See our dashboard for a view of the current fill rate.
Improved mempool logic
Recall from our recent blog post that each node is able to select whichever transactions it wants when creating a block. However, most nodes use the default mempool logic, which should maximize the blockchain fees paid to the farmer.
Now that the blockchain is experiencing sustained fee pressure, we have identified some edge cases where we could improve the logic for selecting transactions. For example, in the rare occasion of a re-org, if the latest block was a not transaction block, the mempool did not get updated until the next transaction block occurred. Starting in 2.2.1, the full node will update the mempool immediately when a re-org occurs.
We have also improved the default block-filling algorithm. Previously, the node filled a new block by repeatedly selecting the highest-priority transaction from the mempool. When the next transaction would overfill the block, the node would consider the block finished and submit it to the network.
This was inefficient in some cases. For example, if a block was less than half full, but the next transaction in the queue was large enough to overfill the block, the node would stop looking for more transactions. The resulting block would be filled to nowhere near capacity, even though it could have held many smaller transactions.
This is a difficult problem to solve – if the block-fill algorithm is too simple, many blocks will be underfilled. But if the algorithm is too complex, the node might take too long in deciding which transactions to include. This would result in the block being empty, or worse – not even added to the chain.
The new block-fill algorithm attempts to strike a balance, filling blocks efficiently, while also being careful not to take too much time in selecting transactions.
Improved wallet syncing
Wallets that use the wallet protocol can now sync their coin state efficiently in batches rather than downloading all of the state in a single response.
Network Improvements
Re-org protection from redundant plots
We have improved the full-node messaging that is propagated across the network, which should result in fewer re-orgs.
Farmers should never store multiple copies of the same plot, even when using multiple full nodes (which is also not recommended). When a winning proof is found in this setup, each node will submit a block containing the proof to the network, but the timelords will only infuse one of them. In fact, the redundant space creates an opportunity cost that results in reduced rewards: the space occupied by the redundant plot could have been filled with a unique plot, resulting in higher rewards.
Despite this guideline, occasionally farmers do copy their plots to redundant full nodes. In this scenario, each node stores a unique copy of the mempool. Because of this, when the redundant farmers each create a transaction block from the same proof, the resulting blocks might be different. Because of how block propagation happens, each timelord might only see one of the blocks. If different timelords infuse different blocks with the same proofs, then they will temporarily create competing blockchains.
This situation does not present a security risk to the network. In fact, it is typically resolved one block later in a re-org. However, re-orgs are inconvenient for farmers, which have to revalidate the last few blocks. A better solution would be to avoid the re-orgs altogether.
Starting in version 2.2.1, nodes will propagate each occurrence of unfinished blocks to the whole network. The timelords will see both copies of the blocks, allowing them to deterministically select which one to infuse. Because only one copy will be added to the blockchain to begin with, a re-org won’t occur.
*Note that this update only addresses one type of re-org; other types are still possible, and indeed normal.
Singleton fast-forward
This is a type of singleton spend aggregation that will only be used when the spend contains certain properties, such as when the singleton’s puzzle hash is not altered by the spend. Fast-forward will therefore be most useful with oracle spends. It was added in two parts:
Developer Tools
Testnet11
We are committed to maintaining a public network where developers can test new features. For the last two years, this has been testnet10. We want the process of syncing a testnet node to remain quick and easy. However, the database for testnet10 has grown quite large with time. Because of this, a few months ago we launched testnet11 as an eventual replacement network.
The time has come to sunset testnet10. Starting in version 2.2.1, testnet11 will be the default network applied when running “chia configure –testnet true”. We encourage all developers to use testnet11 if they are not already doing so.
We will continue to run timelords for testnet10 for one month after the release of 2.2.1. Afterward, we will no longer support the old network. Of course, because testnet10 is a public blockchain, anyone can run a timelord and farmer to keep the network alive if desired.
For more information on running a testnet node, see our documentation.
Consistent peer connections
You can now connect to a consistent set of peers each time you start your node. This could be useful in various situations, such as when connecting to a private testnet where all of the peers are known. See our documentation for more information. Special thanks to Felix Brucker for creating this feature!
Improved logging
We have improved our logging in several areas, including when the mempool is organized, and during validation warnings. The new logging should help developers in their debugging efforts.
Block validation profiler
We have added a new profiler specifically for block validation. Previously, the only available profiler was for the whole full node task. The new profiler will be helpful for debugging in cases where block validation takes longer than two seconds.
Full node aggsig additional data
The full node RPC now allows you to request the additional data required for an aggsig_me condition. This makes it easier for developers to create signatures that work on testnets, simulators, mainnet, and even other Chia forks.
Improvements to get_offer_summary response
When using the get_offer_summary wallet RPC, the “additions” and “removals” will now be included in the response. This will help wallets to determine if an offer is being canceled or accepted by giving them the ability to compare the RPC results against the coin IDs for additions and removals. Special thanks to Mike White for creating this feature!
Verify signatures generated with Tangem cards
The verify_signature wallet RPC now has the ability to verify a signature generated with a Tangem card. This was not previously possible because Tangem uses a different puzzle for signing than the one used by the reference wallet. Special thanks to Marvin Quevedo for creating this feature!
