Eco-Friendly Blockchain Evolution: Explore Chia’s Latest Update 2.2.0

In a significant leap forward for blockchain technology and sustainable farming practices, Chia Network has unveiled its latest software update, version 2.2.0, marking a milestone in the platform’s evolution. This update introduces a suite of enhancements and new features designed to streamline operations, bolster security, and expand the network’s capabilities. As the digital currency landscape continues to evolve at a breakneck pace, Chia’s latest release stands out as a testament to the company’s commitment to innovation, sustainability, and user-centric development. Industry insiders and enthusiasts alike are keenly watching as Chia paves the way for a greener, more efficient future in blockchain technology.

 

Chia Editor notes how they updated their blog to reflect the unfinished block selection issue and ask to revert to version 2.1.4.

Chia found an unfinished block selection issue with 2.2.0, which can create corrupted blocks in the impacted user’s local database. They recommend users revert to 2.1.4.

The Issue
2.2.0 may potentially cause users nodes to ban peers erroneously or to be banned by them in turn.

Next steps
Work is underway to provide a tool for validating synced blocks in users’ local database and an up-to-date Chia DB checkpoint (validated with the tool) for download – users should download this snapshot DB if their node becomes unable to sync or acquire peers. Chia will notify users when both are available to use.

Download 2.1.4 Here↓

Chia is also available in #support on Discord.

Install Notes
For Mac and Linux Users, simply install 2.1.4. For PC users, Chia recommend uninstalling 2.2.0 and installing 2.1.4 – Please take care to preserve the configuration files.

Chia are also working to get 2.2.1 put together and out to users soon™

---

Version 2.2.0 of the Chia reference client is now available for download! Everyone is recommended to upgrade.

This release comes packed with a number of new features and enhancements, which have been 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, Chia 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.

Chia have added a series of optimizations over time to make it easier for these systems to stay in sync. Today, they say they 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 Chia will add a modest uptick to 60%.

Chia plan to ramp up this utilization over time, until they 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 the dashboard for a view of the current fill rate.

Improved mempool logic

Recall from the 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, Chia have identified some edge cases which 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.0, the full node will update the mempool immediately when a re-org occurs.

Chia 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

Chia 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.0, 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:

Testnet11

Chia are committed to maintaining a public network where developers can test new features. For the last two years, this has been testnet10. They 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 Chia launched testnet11 as an eventual replacement network.

The time has come to sunset testnet10. Starting in version 2.2.0, testnet11 will be the default network applied when running “chia configure –testnet true”. All developers are encouraged to use testnet11 if they are not already doing so.

Chia will continue to run timelords for testnet10 for one month after the release of 2.2.0. Afterward, they 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 the 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 the documentation for more information. Chia offered special thanks to Felix Brucker for creating this feature!

Improved logging

Chia have improved 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

They 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. Chia offer 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. Chia offer special thanks to Marvin Quevedo for creating this feature!