A Look at Eth’s Uncle Rate
By bloXroute Labs Co-Founder and COO Eyal Markovich
Two weeks ago we implemented several performance improvements. The effect of this version can be seen by looking at the uncle rate performance over time: there is a continuous drop in the uncle rate over the last few months since the BDN is active and the last 2 weeks show very strong results.
We are planning to release another performance improvement in the next few days and expect to see a similar effect.
Why is the uncle rate not close to zero?
Forks can occur when a new block is mined, but hasn’t yet been received by the entire network. When the network is out of sync in this manner, a mining pool (or less likely, a single miner) which hasn’t received the latest block might mine a new block on top of the previous block — creating a fork. To avoid forks, pools must:
- Receive the latest block
- Process the block, create a new block template to mine, and send it to its miners
bloXroute helps with the former by propagating blocks extremely fast (averaging ~150ms) but not the latter, as this is controlled by the mining pools and their miners. Thus, even if bloXroute manages to reduce block propagation to 0m, there will still be forks and the uncle rate will not be zero.
There are several reasons for this. We’ve highlighted a couple below.
For context, let’s briefly review how mining pools work.
Miners may choose to join a mining pool to combine their hashpower with other miners and thus increase the frequency of winning the block reward. Doing this requires a bit of coordination to ensure that all miners are working on the same problem and rewards are distributed proportional to each miner’s effort. This coordination is carried out by the mining pool admin.
The mining pool admin will build a new block template (mining work) from pending transactions in the txpool and provide the block template to the various miners around the globe. These miners then work to solve the cryptographic puzzle based on this template and send the winning answer to the admin for propagation.
Pool validation time
Since every node in a cryptocurrency peer-to-peer (P2P) network is mistrustful of every other node, when a new block is received from the P2P the node first performs some validation on the block (PoW) and then creates new mining work for the miners (starting with an empty template). This validation should take less than a few ms, but in some cases can take a long time (especially if the node is busy). During this time, the window for forks (which will result in uncles) is open.
Miners take a long time to update the block template
Once a block is validated and added to the chain, the mining admin builds a new block template and then sends the mining work to the miners to repeat this process. A fork can happen if it takes a miner a long time to switch to the newest mining work or if it takes a long time for the pool to receive the found block back from the miner. The block template can be slow to update for many reasons, such as poor miner connectivity to the pool.
Network Propagation
The network propagation is still the most important contributor to the uncle rate. However, as enumerated, the uncle rate can stay above zero because of reasons that are outside of pure network propagation.
We can see this is true by looking at the data.
The BDN entrypoint is a measurement that I use to understand if improving the network propagation could have helped a specific uncle block. That is, the time that the first Gateway sent the block to the BDN.
- If two blocks with the same height (one of which will become an uncle) have a small entrypoint delta, then an improvement in block propagation will have a high impact. This is because the race will be won by telling the most nodes about your block first.
- On the other hand, if an uncle is sent 2 seconds after the matching block completed propagating, then this is not a block propagation issue. A large delta may imply that a lucky miner was still working on an old block template due to another reason, as we know that blocks with bloXroute are propagating at ~150ms to the entire network.
Over the last 2 weeks we examined the BDN entrypoint for each block and uncle block, totaling 3727 blocks. The data below shows the histogram of the uncle block entrypoint distribution.
An entry in the Bin of 1500 means that the Uncle block entered the BDN between 1–1.5 seconds before/after the other block in the fork.
As can be seen, in half the cases (Bin 500), block propagation would have a huge impact. However, for 12.15% of the cases, uncle blocks were propagated a full two seconds or more before/after the same height block. This is a clear indication that the network is not the only reason for the uncle rate.
What can a pool do to improve its Uncle rate?
Hope is not lost, there are several things miners can do to improve their mining operations.
Mining pools / miners should:
- Connect to the BDN with as many Gateways as active nodes. Gateways should run from a server having low latency to the node.
- Configure the Gateway as a trusted peer. This ensures that the Gateway will stay connected and will propagate blocks to and from the node.
- Make sure that the Gateway hears about the mined blocks ASAP. The node sends a full block (high-bandwidth broadcasting) for a square root number of peers and just an announcement (low-bandwidth announcing) for the remaining peers. Some pools configure their nodes to send the full block (vs just the announcement) to their Gateways.
To summarize, we are moving in the right direction. Uncle rates are going down as more pools join the bloXroute BDN, and as we improve the BDN performance it will just get better. It’s time for pools to start thinking about increasing the block size again.
