The Merge and ultrasound.money

A closer look at the insights ultrasound.money provided around the merge.

Here is what https://ultrasound.money looked like just before the merge:

All but the Eth Supply widget here communicate the same insight: when is the merge happening? The merge was agreed to happen when a certain total difficulty was reached. This number was named Total Terminal Difficulty or TTD for short. Each execution chain block as returned by an execution client API returns a total_difficulty. Therefore, the Total Difficulty Progress as seen above is total_difficulty / total_terminal_difficulty as a percent.

The next widget down, Merge Estimate instead takes the difference total_terminal_difficulty - total_difficulty = remaining_difficulty. The “difficulty” of a block is a measure of work done. Knowing this, we can then divide the remaining_difficulty by the difficulty of the last block to get an estimate of the number of blocks remaining before total_terminal_difficulty is reached. I say estimate, as difficulty may increase or decrease slightly every block depending on how much time passed since the last block. In the screenshot above, 96,000 blocks are estimated to remain. Add in the observation that blocks on the execution chain on average take about 13.5 seconds to find, and we can translate the number of bocks to a duration of time. Add this duration to the current time to find the moment we expect the merge to occur.

Percentage to TTD remembers the percent progress for each block to make progress more visual. It also allows estimating visually how much difficulty remains.

A small post-merge data insight lurks here in that time pre-merge was something irregular. Transactions would happen at irregular intervals, and so would “progress” towards the merge. Post-merge, blocks appear or are missed at a regular 12-second interval. Great for charts like the ones above.

I won’t explain into detail Eth Supply widget but will highlight an interesting pre- and post-merge difference. If you pop open the explainer tooltip you find an overview as seen below:

This tooltip explains how we calculate the total amount of ETH in existence. Pre-merge, the execution chain would issue newly minted ETH to miners for finding blocks. Named block rewards and uncle rewards. This meant Evm Balances could be seen to jump up significantly, whenever less ETH was burned than issued. In the past few months, that is most blocks. However, post-merge, no more ETH is issued on the execution chain! So this number is seen to tick down small amounts each block. That is, until Beacon Chain withdrawals are implemented and this number may tick up as people withdraw to the Execution Chain, from the Beacon Chain.

Post-merge

The above screenshots show the Eth Supply and Supply Change under post-merge and pre-merge issuance conditions. Post-merge the above widgets focus on the change in supply which shows interesting differences, especially when using the “simulate proof-of-work” toggle. Let’s go through them.

First, Ethereum supply growth given the current demand and supply for blockspace has been dancing right on the line between deflationary and inflationary. Visible by the Eth Supply line trending up the first weeks post-merge, then down.

In the lower screenshot, the white line visualizes Eth Supply as-if proof of work issuance is still happening. Firstly, any proof of stake issuance becomes imperceptible, as seen by the blue line being flat now, showing issuance reduction is huge (~90%)! Secondly, current amounts of burn are invisible compared to proof of work issuance. This is visible because we know burn bends the line downwards, but can see the ETH (PoW) line is looking straight as an arrow.

Finally, Supply Change with proof of work simulated shows ~539,000 ETH would’ve been mined and given to miners, which now isn’t. 859.2M USD! Mere weeks after the merge. A great indicator of how much Ethereum was paying for network security under proof of work vs. the new proof of stake.

The underlying data

For those interested, some quick final insights into the underlying data for Eth Supply. The base formula used is evm_balances + beacon_balances - beacon_deposits. Collecting this data in practice is hard.

Collecting beacon balances can be done by asking a Beacon client for a complete overview of balances for a given slot and summing them. Below are a few example rows.

"timestamp","state_root","gwei"
2020-12-01 06:00:23.000 -0600,"0x7e76880eb67bbdc86250aa578958e9d0675e64e714337855204fb5abaaf82c2b",674144000000000
2020-12-01 18:00:11.000 -0600,"0x4ea46b6d7c487bfbf446b27321190441ab3671a1df9770f37c77ae7fd5590c5f",880700571394272
2020-12-02 18:00:11.000 -0600,"0xd0a68b2b54461dbeff96decb21fe88d7c184ecabe6c02c7ad7c0a3471e1e3871",933617796634689
2020-12-03 18:00:11.000 -0600,"0xb34580e1e6b482b3fa0dd5fb999402b2e82d6e036f2a1348fffc3be8d9a99c11",983796883608657

Beacon deposits means collecting for each slot how much was deposited, and aggregating it in a sum. A few example slots in which deposits happened shown below.

"slot","deposit_sum","deposit_sum_aggregated"
0,674144000000000,674144000000000
1229,512000000000,674656000000000
1231,512000000000,675168000000000
1232,512000000000,675680000000000

Evm balances is a step more complicated still. Until the following PR by karalabe (and a little bit me) gets merged, you’ll have to build and run the fork yourself. It includes a command to ask a synced Geth client to compute the total EVM balances accounting for block rewards, uncle rewards, self-destruct destroyed ETH, and burnt fees. If you want the information block-by-block the PR also includes a method to get this data. After putting this all together you may have rows of data looking something like this.

"block_hash","block_number","balances_sum"
"0x7876a0d144c9e68ebf17b41a883d6418501e610d8d96f8eecb0f00665ee66e6f",15863430,119677604720096370434349255
"0xb4f3e1806e99f03d11c24691d596762ced826d01fcc35a5c057584de5313a58f",15863429,119677604745428997269511045
"0xc96087fc272440f6adf42eab5a06c5d764640bd6c07cc7fab0e5d6b9b5202961",15863428,119677604952387891386635686
"0xd80aa938c4892f3831ecfe42d21e0d0779e08362d36738e1b45d0b26cc61f2bb",15863427,119677605004327218414504998