This release introduces a hard fork that activates at height 1391330, approximately 2024-03-26 14:00 UTC.

Coordinated Mining

When coordinated mining is configured multiple nodes can cooperate to find mining solutions for the same mining address without the risk of losing reserved rewards and blacklisting of the mining address. Without coordinated mining if two nodes publish blocks at the same height and with the same mining address, they may lose their reserved rewards and have their mining address blacklisted (See the Mining Guide for more information). This allows multiple nodes which each store a disjoint subset of the weave to reap the hashrate benefits of more two-chunk solutions.

Basic System

In a coordinated mining cluster there are 2 roles:

1. Exit Node
2. Miners

All nodes in the cluster share the same mining address. Each Miner generates H1 hashes for the partitions they store. Occasionally they will need an H2 for a packed partition they don't store. In this case, they can find another Miner in the coordinated mining cluster who does store the required partition packed with the required address, send them the H1 and ask them to calculate the H2. When a valid solution is found (either one- or two-chunk) the solution is sent to the Exit Node. Since the Exit Node is the only node in the coordinated mining cluster which publishes blocks, there's no risk of slashing. This point can be further enforced by ensuring only the Exit Node stores the mining address private key (and therefore only the Exit Node can sign blocks for that mining address)

Every node in the coordinated mining cluster is free to peer with any other nodes on the network as normal.

Single-Miner One Chunk Flow

Note: The single-miner two chunk flow (where Miner1 stores both the H1 and H2 partitions) is very similar

Coordinated Two Chunk Flow

Configuration

1. All nodes in the Coordinated Mining cluster must specify the coordinated_mining parameter
2. All nodes in the Coordinated Mining cluster must specify the same secret via the cm_api_secret parameter. A secret can be a string of any length.
3. All miners in the Coordinated Mining cluster should identify all other miners in the cluster using the cm_peer multi-use parameter.
   • Note: an exit node can also optionally mine, in which case it is also considered a miner and should be identified by the cm_peer parameter
4. All miners (excluding the exit node) should identify the exit node via the cm_exit_peer parameter.
   • Note: the exit node should not include the cm_exit_peer parameter
5. All miners in the Coordinated Mining cluster can be configured as normal but they should all specify the same mining_addr.

There are 2 additional parameters which can be used to tune performance:

• cm_out_batch_timeout: The frequency in milliseconds of sending other nodes in the coordinated mining setup a batch of H1 values to hash. A higher value reduces network traffic, a lower value reduces hashing latency. Default is 20.
• cm_in_batch_timeout: The frequency in milliseconds of processing H1 batches that this node has received from peers. A higher value reduces redundant disk reads, a lower value reduces hashing latency. Default is 20.
  • In early tests 200 to 300 might be a good compromise for many mining setups - but the optimal value can vary significantly based on the the specific mining cluster configuration and hardware.

Native Support for Pooled Mining

The Arweave node now has built-in support for pooled mining.

New configuration parameters (see arweave node help for descriptions)::

• is_pool_server
• is_pool_client
• pool_api_key
• pool_server_address

Mining Performance Improvements

Implemented several optimizations and bug fixes to enable more miners to achieve their maximal hashrate - particularly at higher partition counts.

A summary of changes:

• Increase the degree of horizontal distribution used by the mining processes to remove performance bottlenecks at higher partition counts
• Optimize the erlang VM memory allocation, management, and garbage collection
• Fix several out of memory errors that could occur at higher partition counts
• Fix a bug which could cause valid chunks to be discarded before being hashed

Updated Mining Performance Report:

=========================================== Mining Performance Report ============================================

VDF Speed:  3.00 s
H1 Solutions:     0
H2 Solutions:     3
Confirmed Blocks: 0

Local mining stats:
+-----------+-----------+----------+-------------+-------------+---------------+------------+------------+--------------+
| Partition | Data Size | % of Max |  Read (Cur) |  Read (Avg) |  Read (Ideal) | Hash (Cur) | Hash (Avg) | Hash (Ideal) |
+-----------+-----------+----------+-------------+-------------+---------------+------------+------------+--------------+
|     Total |   2.0 TiB |      5 % |   1.3 MiB/s |   1.3 MiB/s |    21.2 MiB/s |      5 h/s |      5 h/s |       84 h/s |
|         1 |   1.2 TiB |     34 % |   0.8 MiB/s |   0.8 MiB/s |    12.4 MiB/s |      3 h/s |      3 h/s |       49 h/s |
|         2 |   0.8 TiB |     25 % |   0.5 MiB/s |   0.5 MiB/s |     8.8 MiB/s |      2 h/s |      2 h/s |       35 h/s |
|         3 |   0.0 TiB |      0 % |   0.0 MiB/s |   0.0 MiB/s |     0.0 MiB/s |      0 h/s |      0 h/s |        0 h/s |
+-----------+-----------+----------+-----------+---------------+---------------+------------+------------+--------------+

(All values are reset when a node launches)

• H1 Solutions / H2 Solutions display the number of each solution type discovered
• Confirmed Blocks displays the number of blocks that were mined by this node and accepted by the network
• Cur values refer to the most recent value (e.g. the average over the last ~10seconds)
• Avg values refer to the all-time running average
• Ideal refers to the optimal rate given the VDF speed and amount of data currently packed
  % of Max refers to how much of the given partition - or whole weave - is packed

Protocol Changes

The 2.7.2 Hard Fork is scheduled for block 1391330 (or roughly 2024-03-26 14:00 UTC), at which time the following protocol changes will activate:

• The difficulty of a 1-chunk solution increases by 100x to better incentivize full-weave replicas
• An additional pricing transition phase is scheduled to start November, 2024
• A pricing cap of 340 Winston per GiB/minute is implemented until the November pricing transition
• The checkpoint depth is reduced from 50 blocks to 18
• Unnecessary poa2 chunks are rejected early to prevent a low impact spam attack. Even in the worst case this attack would add minimal bloat to the blockchain and thus wasn't a practical exploit. Closing the vector as a matter of good hygiene.

Additional Bug Fixes and Improvements

• Enable Randomx support for OSX and arm/aarch64
• Simplified TLS protocol support
  • See new configuration parameters tls_cert_file and tls_key_file to configure TLS
• Add several more prometheus metrics:
  • debug-only metrics to track memory performance and processor utilization
  • mining performance metrics
  • coordinated mining metrics
  • metrics to track network characteristics (e.g. partitions covered in blocks, current/scheduled price, chunks per block)
• Introduce a bin/data-doctor utility
  • data-doctor merge can merge multiple storage modules into 1
  • data-doctor bench runs a series of read rate benchmarks
• Introduce a new bin/benchmark-packing utility to benchmark a node's packing peformance
  • The utility will generate input files if necessary and will process as close to 1GiB of data as possible while still allowing each core to process the same number of whole chunks.
  • Results are written to a csv and printed to console