# On Bandwidth Requirements For Validators

:::info
**Summary**

- With Inclusion Lists, we recommend:
- 50 Mbps download and 25 Mbps upload for users using MEV-boost
- 100 Mbps download and 50 Mbps upload for local block builders
- Without Inclusion Lists, if a local block builder does not have enough bandwidth, we recommend that they fill up enough of the block to match their bandwidth constraints. E.g. no blobs.
:::

## Introduction

In this document, we recommend bandwidth requirements for validators, and propose several solutions for local block builders who cannot meet the bandwidth requirements.

We also note that one can still miss slots even if they meet the bandwidth requirements due to latency. If your node is geographically isolated from the rest of the network, messages will take longer to be received by the rest of the network, than a node who is not isolated, all else being the same.

## Understanding the User's perspective

When a user submits a transaction, they have the expectation that their transaction will be confirmed in a block at *some* point in the future, if the transaction is valid. We do not define what it means to be valid, however, without loss of generality, one can think of the case where a user has enough funds in their account to spend from.

## What could prevent transaction inclusion?

Block builders are the entities responsible for including transactions in blocks.

We classify two types:

- Centralized block builders (currently dominated by two major entities)
- Local block builders (individual validators building their own blocks)

Block builders can prevent transaction inclusion in two ways:

- Actively ignoring a transaction while including others (Selective Transaction Exclusion)
- Passively abstaining from block building entirely (Block Building Abstention)

We aim to make these behaviors either prohibitively expensive or inconsequential to whether your transaction *eventually* gets included.

The first issue is solved by forcing the block builder to include transactions in their blocks, while the second issue is solved by local building in the worse case, however it is a rare occurrence.

## Threat 1: Selective Transaction Exclusion

### The problem

Block building done by sophisticated entities has the tendency to lean towards centralization. Currently, two major centralized builders produce the majority of blocks in Ethereum. These builders can choose (or be coerced) to systematically ignore certain transactions while including others. This is not a theoretical issue, as we have seen this happen with transactions from addresses that interacted with Tornado Cash.

### Inclusion Lists

Inclusion lists are a mechanism that forces the block builder to include a set of transactions. If a block builder, centralized or not, creates a block, the protocol uses inclusion lists to penalize the block builder if they do not include the transactions on the inclusion lists in the created block.

**FOCIL**

The most promising design is known as **Fo**rk **C**hoice **I**nclusion **L**ist([FOCIL](https://eips.ethereum.org/EIPS/eip-7805)). If a block builder does not include a valid transaction, then the block will be deemed as invalid unless the block is full. In other words:

- Without FOCIL, the cost of ignoring a transaction is merely the missed transaction's priority fee or Maximal Extractable Value(MEV).
- With FOCIL, the cost of ignoring a valid transaction is the cost to fill up the block or to [bribe all IL committee members](https://ethresear.ch/t/towards-attester-includer-separation/21306/4). The maximum theoretical cost increases with the gas limit.

**Mitigation Through Local Block Building**

We are in a situation where we do not have inclusion lists. We therefore have a reliance on local builders for mitigating the selective transaction exclusion threat because:

- The barrier for entry to become a local builder is significantly lower than that for a centralized block builder. It is 32 ETH.
- Individual participants with the economic utility to become a local block builder are typically harder to coerce than sophisticated entities, due to the lower barrier to entry.

## Threat 2: Abstaining from Block building

### The Problem

Block builders could choose to abstain from building a block, if they are forced to include a censored transaction.

> Note: Technically, if the centralized block builder does not produce a block, then the block is built by a local block builder. This is inconsequential to the formulation of the problem.

> Note: There can be other reasons why a centralized block builder produces an invalid block or not produce a block (timing games), for simplicity we view these as the same.

### How likely is this scenario?

This scenario is only likely given inclusion lists because centralized block builders are free to ignore censored transactions right now with minimal repercussions. Lets therefore assume that we have Inclusion Lists.

**The nature of centralized block building**

Centralized block building is a hyper competitive landscape. If the top block builders decide to abstain from building blocks, then given the amount of profit they will be losing, another centralized block builder will eventually start creating blocks.

It is therefore not in the interest of centralized block builders to not build blocks.

Moreover, in the world of inclusion lists, censoring block builders are put at an economical disadvantage because their choices are to either abstain from block building or ensure that every block is full such that they can ignore the inclusion list. While non-censoring block builders need only build the best block from all of the available transactions.

We also emphasize that in the world of inclusion lists, censoring block builders can be targeted such that they must ensure that every block they build is full. This can be done by constantly adding censored transactions to the inclusion list.

Ultimately, the scenario where a top block builder is both censoring and profitable is an unlikely event given inclusion lists.

Nonetheless, this is where local block building can be helpful.

**What properties do we expect from local builders in this scenario?**

So local builders serve as a crucial fallback mechanism in the rare and worse case that all centralized block builders abstain from building a block.

Clearly we cannot assume that local block builders are as powerful as centralized block builders. Therefore, we should expect *some* performance degradation in the protocol if a block is being built by a local block builder versus a centralized block builder.

However, we note that in a world where inclusion lists are implemented, *all* block builders must be able to build a block with the contents of the inclusion lists. This means that, for example, if the number of blobs in the inclusion list is 6, and a local block builder has sub-par bandwidth, they may not be able to produce a valid block.

> In the case of blobs, the IL committee could seed the network, to make sure that the blobs on their lists are seen as available. If FOCIL (with blobs) includes this, then we perhaps don't need the local block builders to have that much bandwidth.
>
> Especially given that the IL list gets sent in the slot before. This only works for PeerDAS and not 2D DAS since the IL committee cannot assume that the block builder will not add more blobs.

## Local Block Builders Without IL

Without Inclusion Lists, we are in a world where local block builders are important for the including censored transactions. Local block builders can choose how much censorship resistance they want to provide based on how much bandwidth they have to propagate the block.

For example, if a block builder only has 50 Mbps download and 20 Mbps upload, then that user should modify their configurations to include as many transactions as they can. This might be in the form of zero blobs, but full blocks or one blob but a half full block.

**Configuring block building for bandwidth constraints**

It is hard to specify when an individual node should configure how many blobs or transactions to include in a block because it is not only dependent on your bandwidth, but your modem, ISP and how far other nodes are from you (latency).

We instead recommend to have the user determine when they do not meet the minimum by checking the following:

- Constantly missing slots
- Peak node bandwidth usage vs your home's average bandwidth usage

It is then the block builder's responsibility to adjust the number of blobs they include and or the number of total transactions they include.

A local block builder _could_ also choose to use mev-boost in this case.

## Local block builders with IL

With Inclusion Lists, the role of a local block builder becomes less important for censorship resistance as noted above.

The local block builder will need to ensure that they have the necessary bandwidth requirements to satisfy the inclusion list, if it were full.

**Configuring block building for bandwidth constraints**

Since it is not possible for local block builders to adjust the amount of transactions or blobs they include in a block, and the amount of bandwidth is directly linked to the gas limit and blob target, if a local block builder's bandwidth is not able to keep up with the data needed for a full inclusion list, then they can either:

- Upgrade their bandwidth
- Turn on MEV-boost to reduce the amount of bandwidth needed

In short, once we have inclusion lists, local block builders will only be needed for censorship resistance in the rare and worse case that all centralized block builders stop building blocks.

## Average Bandwidth

**Targeting average bandwidth**

Targeting a strict lower bound for bandwidth is difficult, especially if the network topology is changing as it is in Ethereum, and there are different entities who may need more than others.

For example, full nodes are not expected to need as much upload bandwidth as local block builders because they do not need the majority of the network to attest to a block within a certain time limit.

This means that they can be below the average. Moreover, we know that some nodes have gigabit per second bandwidth while others have megabit per second.

This document recommends we use average bandwidth based off of the global average bandwidth.

**Average network bandwidth**

[Statista states](https://www.statista.com/statistics/896779/average-mobile-fixed-broadband-download-upload-speeds/) that the global average download is 92 Mbps and the global average upload is 45 Mpbs. We note that one could reside in a country that has good bandwidth, but live in a city that does not have great bandwidth.

For validators whom want to build block locally, we recommend 100 Mbps download and 50 Mbps upload to be inline with the global average.

For validators, whom want to use MEV-boost, we recommend half; 50 Mbps download and 25 Mbps upload. This was chosen for two reasons:
- For the majority of countries, we observed that this was attainable.
- Simulations done by the panda ops team showed that a network with 40% gigabit connections needed 60% of the network to be around 25 Mbps to avoid degradation. This is of course not representative of Mainnet, however it allows us to extrapolate a rough ball park estimate.

## Miscellaneous Research Data on bandwidth speeds and Fibre adoption

- [Eth staker bandwidth survey](https://paragraph.xyz/@ethstaker/staking-bandwidth-survey-fall-2024)
- Fibre development index
- [world broadband assosciation](https://worldbroadbandassociation.com/wp-content/uploads/2021/08/FDI-White-Paper-Final_151020.pdf)
- [Omdia](https://omdia.tech.informa.com/-/media/tech/omdia/marketing/commissioned-research/pdfs/fiber-development-index-analysis-2023.pdf?rev=0ec487802cde443da62f20bccc2708c4)
- [According to GSMA](https://www.gsma.com/r/wp-content/uploads/2024/10/The-State-of-Mobile-Internet-Connectivity-Report-2024.pdf?utm_source=website&utm_medium=button&utm_campaign=somic24), global **mobile** average download speeds are 48Mbps. This is mobile and should give at least a good indicator for what the trend is for Least Developed Countries(LDC). Page 39, shows the average upload is about 20Mbps
- [Cisco annual internet report for 2018-2023](https://www.cisco.com/c/en/us/solutions/collateral/executive-perspectives/annual-internet-report/white-paper-c11-741490.pdf) has analysis on bandwidth trends and adoption of technologies such as 5G
- Reports on Australia
- [Australia broadband performance 2021](https://www.infrastructure.gov.au/sites/default/files/documents/bcarr--australias-broadband-performance--march2022.pdf) with link to [broader methodology](https://www.infrastructure.gov.au/research-data/bureau-communications-arts-and-regional-research/communications/communications-australias-fixed-broadband-performance)
- [Measuring broadband Australia program 2024](https://www.accc.gov.au/system/files/measuring-broadband-australia-report-27.pdf?ref=0&download=y) with link to the [project overview](https://www.accc.gov.au/by-industry/telecommunications-and-internet/telecommunications-monitoring/measuring-broadband-australia-program)
- Germany [median country speeds from speedtest](https://www.speedtest.net/global-index/germany)
- [statista global average download and upload](https://www.statista.com/statistics/896779/average-mobile-fixed-broadband-download-upload-speeds/)

## Acknowledgements

With contributions from Parithosh Jayanthi, Kevaundray Wedderburn, Josh Rudolf, Dankrad Feist, Justin Traglia, Ignacio Hagopian, George Kadianakis, Carl Beekhuizen and Barnabé Monnot.

# Notes

- Carl Beekhuizen's plot of population weighted download speeds taken from speedtest, shows that at least 50% of the population has download speeds of 72 Mbps or more


- Carl Beekhuizen's plot of median download and upload speed. Suggestion is to not overindex on this too much as it uses median and it is not very granular. The interesting point from this is that choosing 100/50 means that we only include ~37% of the population. Carl also noted that this is being dragged down by India. choosing 64/32 includes 66% of the population.