Partnered With:

Bandwidth usage after enabling Ethereum withdrawal feature.

Read this article in 10 Minutes

Data shows that the upgrade in Shanghai has led to a significant increase in network traffic for the Geth network.

Original Title: "Bandwidth Usage after Ethereum Withdrawals"

Original Author: Alex Miller

Original Translation: Kxp, BlockBeats

On April 12th, Ethereum underwent the Shapella upgrade. In fact, this is a combination of two different upgrades: the Capella upgrade for the consensus layer and the Shanghai upgrade for the execution layer. This joint upgrade includes various features, but the most anticipated one is the withdrawal of validators, breaking the staking loop. Once the upgrade is live, all validators with 0x01 type credentials can withdraw their stake in one of two ways:

1. Users can instruct their consensus client to fully exit the validator. This will put the validator in a queue, and all of the validator's balance will be dispersed to the withdrawal address of the execution layer afterwards.

2. Validators who do not exit will automatically "clear" their balance exceeding 32ETH every 4 days or so. The key point is that this is done automatically - users do not need to instruct their consensus client to perform this operation, and even if they want to keep their validator balance, they cannot execute it.

The first option is used to unlock the pledge and set a limit on the user's pledge risk. Specifically, the exiting validator still needs to provide proof/proposal until it passes the queue, and the length of the queue determines the expected punishment for validators who cannot continue to operate (for example, a 4-day offline punishment in the queue equals 4 days).

However, from a network perspective, the second option is more interesting because these messages will be continuously broadcasted by each validator in the withdrawal queue (different from the exit queue).

Shapella has added two new constantly broadcasting message types: consensus withdrawal and executable EIP4895. This means that all nodes on the network have two new Gossip topics, and we should expect an increase in bandwidth consumption. But the question is, how much has the bandwidth increased?

Capella Before and After Data Snapshot

I am running a staking box and monitoring the system myself, so I checked whether there was any significant change in bandwidth consumption after upgrading to Shapella. I have about a week's worth of data before and after the upgrade, and the results are quite clear. Each type of data was tracked for pre-upgrade from April 3 to 12 and post-upgrade from April 12 to 18. Please note that the following content is not a detailed analysis, but a simple presentation of the data.

Notice: First of all, when Capella goes live, the cache of BLSToExecutionChange messages - another consensus message type that converts 0x00 withdrawal vouchers to 0x01 type - has been cleared, resulting in a surge in Gossip traffic in the consensus layer. Since each validator can only change the voucher once, this is a temporary state. Secondly, a large number of exiting validators - mainly from Kraken, due to its SEC settlement-induced exit task - have also been absorbed by the network, but I don't think this factor is very significant in terms of traffic peaks.

Overall System Bandwidth

The most important metric is the overall bandwidth used by my collateral portfolio. This is a Linux-level measurement that tracks the number of bits flowing through the network interface, which in my case is Ethernet.

· Outbound traffic: 8.5 Mb/s -- 10.41 Mb/s (+22%)

· Inbound traffic: 7.19 Mb/s -- 8.48 Mb/s (+18%)

Client Usage

Next, I looked at individual clients (execution and consensus). I used geth as the execution client and lighthouse as the consensus client. Please note that the following chart uses kB/s, but I have converted the values to Mb/s to match the overall system bandwidth usage displayed above.

Note: The bandwidth usage of two clients does not equal the usage of the entire network, so it is clear that there are other sources of traffic that have not appeared in these monitoring views. However, observing the relative differences of each client is very interesting.

Geth

The change in consensus client bandwidth is a bit strange because they show a very large average growth, but this is mainly due to some very large peaks. I'm not sure what caused these peaks because they seem to be concentrated around the upgrade (4/12 evening - 4/13 morning) and have become more dispersed since then. If you know what caused these peaks, please provide it in the comments.

· Inbound traffic: 0.404 Mb/s -- 0.614 Mb/s (+52%)

· Outbound traffic: 0.888 Mb/s -- 1.448 Mb/s (+63%)

Editor's note: After the article was published, I want to check the Ethereum transaction fees during this time range to see if it may be strongly correlated with the peak traffic of geth mentioned above. Since the upgrade, the average transaction fee has been consistently high, which I believe explains some of the peaks, but it is by no means the only reason for the huge difference in traffic peaks.

Observation of Ethereum network fees within the observed data range (source: ultrasound.money)

Lighthouse

Unlike other dashboards, my Lighthouse monitor combines inbound and outbound traffic into one view. The result is clear, but much smaller than Geth. However, like Geth, bandwidth differences sharply increase after upgrading to production.

Attention: This dashboard does not provide numerical averages, so I must estimate these numbers based on the chart below.

· Comprehensive flow rate: ~9.6 Mb/s -- ~11.2 Mb/s (+ ~16.6%)

Conclusion

It is still too early to draw too many conclusions from these data, but here are some findings that I believe are worth emphasizing:

· The overall network traffic has indeed increased significantly: by about 20%. This is basically as expected, but higher than I had imagined. Adding new message types to a Gossip protocol always has some impact on traffic.

· The average flow of bandwidth consumption for the consensus layer and execution layer has increased significantly (with greater changes in the execution layer), but the variance has increased even more. After 6 days of measurement, it appears that this variance has not decreased.

· Shanghai upgrade (execution upgrade) caused a significant increase in geth network traffic. I am not sure what caused this behavior, but it is worth paying attention to. Please note that it has been about 48 hours so far, but there have been no major spikes, so it is possible that the density of these spikes is a temporary phenomenon.

Perhaps we can observe these traffic measurement values for a long time and may discover some interesting phenomena.