Ethereum censorability monitor

Table of Contents

• Introduction
• Dataset and dashboard
• Building hypothesis
  • Full sample dataset
  • Truncated dataset for potentially censored transactions
• Censorship analysis (10.02.2023 - 14.02.2023)
  • Exploratory Data Analysis
  • Statistical analysis
  • Potentially censored sample dataset
• Conclusions
• Future plans

Introduction

This article is our submission to Lido’s Ethereum censorability monitor grant.

Ever since the Ethereum merge, MEV-boost has become a significant part of the ecosystem. At the same time, the US government via the Office of Foreign Assets Control (OFAC) have imposed sanctions on certain digital addresses. MEV-relays are now divided between those which are OFAC-compliant and those which are not.

The main goal of this article is to demonstrate the influence of this censorship on blockchain degradation and propose a solution to monitor the censorship problem in the Ethereum blockchain.

For the purpose of this paper, we will refer to the time difference between when a transaction enters the mempool and is included in a block as "delay".

Dataset and dashboard

Our sources of data:

1. Mempool public data.
   This data was collected via a web3 python package and kept in our Data warehouse (DWH) and only one node was used (located in Europe). The data was streamed 24/7 and we parsed approximately 1-1.2m potential transactions per day. Our mempool sample covers about 95% of all transactions in the public Ethereum dataset.
2. Public Ethereum Dataset
3. Level of censorship applied by relays
4. Block information obtained directly from Relays (e.g. flashbots)
5. Government-sanctioned list of digital addresses
6. Lido validator pubkeys. We used the validator dataset from Lido.

After the data was processed, we created a large dataset. The table below contains a description of the main variables:

This dataset is available on Google BigQuery in the table `p2p-data-warehouse.p2p_public.eth_mev_censored`.

Based on the data described above, we’ve created a dashboard with the main characteristics of Ethereum transactions.

Dashboard description

Our dashboard has 6 parts:

1. General data info. Data about transactions and blocks within the Ethereum blockchain, delay and transaction cost.
2. Censorship between relays. Here we showcase the share of blocks for each MEV relay and the average delay for censorship and non-censorship MEV relays.
3. Censorship addresses. Here we showcase all the available information about addresses that are under the OFAC-sanctioned list.
4. Lido vs Other validators. Here we divide transactions between those validated by Lido and other validators for comparison.
5. Censorship between MEV-builders. Here we showcase a few metrics for every MEV-builder in the Ethereum ecosystem.

Building hypothesis

Full sample dataset

Our main goal is to estimate the level of blockchain degradation, i.e. longer time to verify transactions and higher transaction costs, that may be caused by censorship. We hypothesize that longer delays and higher transaction costs could be a sign of censorship.

We hypothesize that our main metrics (delay and transaction costs) could be statistically different in the following subgroups:

• MEV-boost / non-MEV-boost
• Relays (OFAC-compliant/non-compliant)
• Lido validators versus others

We also want to check the level of censorship employed by Lido validators so we are going to check the following hypothesis:

1. MEV transactions may be under censorship and it can lead to a slowdown in operations compared to non-MEV.
2. Delay and cost of transactions could be different between Lido validators and other validators.
3. Relays that censor transactions can have a longer delay than other relays.
4. OFAC-compliant relays could take longer to process transactions compared to other relays
5. The probability of some transaction being included in the Nth block in the case of OFAC/not-OFAC could be different.
6. The probability to be included in the OFAC block for Lido validators could be different, compared to non-Lido validators.

Truncated dataset for potentially censored transactions

We want to highlight a certain amount of transactions whose high time delay could not be explained by normal network conditions. Such transactions will be suspect of being subject to censorship. To realise this, we must take into account the following transaction properties.

High delay

We will start by choosing all the transactions over a certain threshold for the time delay in seconds.

Successful transactions

Next, we will only consider successful transactions since failure could be a reason for the delay.

Low transaction fees

Another reason for a transaction to have a high delay could be low fees. That is why we should account for that and start by checking the transaction fee.

Previous transaction pending

Sometimes transactions could delayed simply because a previous transaction from the same sender had not yet finished. We use nonce parameters to exclude these transactions in our analysis.

After forming the truncated dataset, we will try to find out the reasons for the high delay in censored transactions: government-driven or ethical censorship. We will check the receiver and sender addresses against the sanctioned list and share OFAC/ethical censoring MEV-relays. Results across the full daily dataset can be found in our dashboard.

Censorship analysis (10.02.2023 - 14.02.2023)

The code required to reproduce our results is available here

Exploratory Data Analysis

Our sample dataset has 4 798 993 transactions and of those, 153 847 (~3%) are failed transactions.

The delay for most transactions does not exceed 27 seconds (95% quantile) and almost every transaction has been delayed for only one block (block_diff = 1).

Most transactions have fees with a skewness of zero. The difference between the 99.5% quantile and the 95% quantile is greater than 4 times the fee. The table below shows the transaction time delay and fees.

Main quantiles for delay and fees