What has been upgraded in the latest version 2.7.2 of Arweave?

Recently, #Arweave underwent a hard fork at block height 1391330, upgrading the consensus mechanism to version 2.7.2. What updates does this version bring? This article provides a detailed interpretation for you.

✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨

1. Coordinated Mining

Coordinated mining is a mining mode that allows multiple nodes to use the same mining address without worrying about losing block rewards or being blacklisted. When miners do not use this mode, if two nodes publish blocks at the same height using the same mining address, it will be considered a violation. This not only causes miners to lose mining rewards but also puts the mining address on a blacklist. Therefore, this allows multiple nodes that store different subsets of Weave to gain more computational advantages for two-chunk solutions.

You might be confused about the term two-chunk solutions mentioned here; what is it?

As explained in previous articles in the white paper series, for each VDF (which can be understood as per second), miners have a maximum of 2 attempts per second per partition to find a successful mining solution. Here, we will refer to each attempt as Attempt. The first Attempt involves randomly finding a data chunk in the partition stored by the miner to perform a Hash; once the miner has the Hash from this first Attempt, they then use it to find a second random data chunk in all Weave partitions and perform a Hash on it to complete the second Attempt. If the miner finds a solution in the second Attempt, it means they completed mining using two chunks, hence the term two-chunk solutions.

In version 2.7.2, the difficulty of the first Attempt has been greatly increased, making it very difficult for miners to find one-chunk solutions. As a result, miners must perform a second Attempt, with a rough ratio of 100 two-chunk solutions for every one-chunk solution opportunity. The purpose of this is to incentivize miners to store as many Weave partitions as possible. In the newly updated coordinated mining mode, miners are allowed to maximize mining efficiency through collaboration with other miners without having to store all Weave.

Basic System

There are two roles in the coordinated mining mode:

1. Exit Node
2. Miner

All nodes in the cluster share the same mining address. Each miner generates an H1 hash for the partitions they store. Sometimes, the required H2 hash falls within a partition they do not store. In this case, they can find miners who store the corresponding partition in the coordinated mining cluster and send H1 to them for H2 calculation. Once a valid solution is found (one-chunk or two-chunk), this solution is sent to the exit node. The exit node is the only node in the coordinated mining cluster that is not at risk of being slashed and can publish blocks. The exit node is also the only node that stores the private key for this mining address (thus only the exit node can sign blocks).

Each node in the coordinated mining cluster can connect peer-to-peer with any other node on the network as usual.

Single Miner One-Chunk Process

https://pbs.twimg.com/media/GLQiwonXoAANcx9?format=jpg&name=medium

Note: Miner1 stores enough partitions to obtain both H1 and H2 simultaneously.

Coordinated Two-Chunk Process

https://pbs.twimg.com/media/GLQi6aDWgAEnnGD?format=jpg&name=medium

Configuration

1. All nodes in the coordinated mining cluster must configure the coordinated_mining parameter.
2. All nodes in the coordinated mining cluster must configure the same secret parameter through cmapisecret. It can be a string of any length.
3. All miners in the coordinated mining cluster should use the cmpeer parameter to identify other miners in the cluster. Note: The exit node can also optionally mine; in this case, it is also considered a miner and should be identified by the cmpeer parameter.
4. All miners (excluding the exit node) should use the cmexitpeer parameter to identify the exit node.
5. All nodes in the coordinated mining cluster can be configured normally, but they should all specify the same mining address mining_addr.

There are also two additional parameters available to adjust performance:

• cmoutbatch_timeout: The frequency (in milliseconds) of sending a batch of H1 values from other nodes in the coordinated mining settings. A higher value can reduce network traffic, while a lower value can reduce hash latency. The default value is 20.
• cminbatch_timeout: The frequency (in milliseconds) of processing batches of H1 received from peer nodes. A higher value can reduce redundant disk reads, while a lower value can reduce hash latency. The default value is 20.

In early tests, 200 to 300 may be a good compromise in many mining settings. However, the optimal value may vary significantly depending on specific mining cluster configurations and hardware.

2. Local Support for Pool Mining

Currently, Arweave nodes have built-in support for pool mining.

New parameters related to pool mining:

• ispoolserver
• ispoolclient
• poolapikey
• poolserveraddress

3. Mining Performance Optimization

The new version implements several optimizations and bug fixes to enable more miners to achieve maximum hash rates.

Update Summary:

• Increased the level of horizontal distribution used during mining to eliminate performance bottlenecks at higher partition counts.
• Optimized memory allocation, management, and garbage collection for the Erlang virtual machine.
• Fixed several out-of-memory errors that could occur at higher partition counts.
• Fixed a bug that could cause valid data chunks to be discarded before hashing.

Updated Mining Performance Report:

https://pbs.twimg.com/media/GLQjeH4WwAAD6lV?format=png&name=medium

Where:

• H1 Solutions / H2 Solutions refers to the count of types of mining solutions found, showing the count of those found under H1 hash versus those found under H2 hash.
• Confirmed Blocks shows the count of blocks mined by this node.
• Cur value refers to the most recent value (e.g., the average over the past 10 seconds).
• Avg value refers to the overall average.
• Ideal refers to the best rate given the current VDF speed and the amount of data being packaged.
• % of Max refers to how much of the given partition (or the entire Weave) has been packaged.

4. Protocol Changes

The 2.7.2 hard fork took place at block 1391330, activating the following protocol changes:

• The difficulty of one-chunk solutions increased by 100 times to better incentivize the storage of complete Weave copies.
• An additional pricing transition phase is planned to start in November 2024.
• Implementation of a pricing cap of 340 Winston per GB/minute until the pricing transition in November.
• Reduced checkpoint depth from 50 blocks to 18 blocks.
• To prevent low-impact spam attacks, unnecessary poa2 blocks will be rejected in advance. Even in the worst-case scenario, this attack has a minimal impact on blockchain bloat, so it is not a practical exploit. Closing this vector is considered good hygiene.

More details can be found in the relevant documentation: https://github.com/ArweaveTeam/arweave/releases/tag/N.2.7.2