Sliding Window Challenge Process for Congestion Detection

01/22/2022
by   Ayelet Lotem, et al.
Hebrew University of Jerusalem
0

Many prominent smart-contract applications such as payment channels, auctions, and voting systems often involve a mechanism in which some party must respond to a challenge or appeal some action within a fixed time limit. This pattern of challenge-response mechanisms poses great risks if during periods of high transaction volume, the network becomes congested. In this case fee market competition can prevent the inclusion of the response in blocks, causing great harm. As a result, responders are allowed long periods to submit their response and overpay in fees. To overcome these problems and improve challenge-response protocols, we suggest a secure mechanism that detects congestion in blocks and adjusts the deadline of the response accordingly. The responder is thus guaranteed a deadline extension should congestion arise. We lay theoretical foundations for congestion signals in blockchains and then proceed to analyze and discuss possible attacks on the mechanism and evaluate its robustness. Our results show that in Ethereum, using short response deadlines as low as 3 hours, the protocol has >99 to 33 also possible with a similar defense rate for attackers with up to 27 power.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

12/30/2020

TCP D*: A Low Latency First Congestion Control Algorithm

The choice of feedback mechanism between delay and packet loss has long ...
09/08/2021

BMS: Secure Decentralized Reconfiguration for Blockchain and BFT Systems

Reconfiguration of long-lived blockchain and Byzantine fault-tolerant (B...
03/13/2020

On Exploiting Transaction Concurrency To Speed Up Blockchains

Consensus protocols are currently the bottlenecks that prevent blockchai...
02/09/2021

The case for model-driven interpretability of delay-based congestion control protocols

Analyzing and interpreting the exact behavior of new delay-based congest...
05/28/2018

Dart: Divide and Specialize for Fast Response to Congestion in RDMA-based Datacenter Networks

Though Remote Direct Memory Access (RDMA) promises to reduce datacenter ...
11/20/2019

Implement Liquid Democracy on Ethereum: A Fast Algorithm for Realtime Self-tally Voting System

We study the liquid democracy problem, where each voter can either direc...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

DeFi platforms constructed over blockchains such as Ethereum have seen a recent boom of activity and interest. Their growing ecosystem allows for increasingly complex financial interactions executed in a fully decentralized manner. The main building blocks used to construct these platforms are the smart contracts that define the rules of interaction in code.

Smart contracts enable a wide range of applications, such as auctions, voting systems, and second layer protocols (e.g., payment channels) that operate above the blockchain layer. They typically provide rules that allow them to act as an automated adjudicator in case conflicts between participants arise.

For many applications, interactions with smart contracts are time dependent and are even subject to deadlines, meaning that in some cases, transactions added after a specific moment will effectively be rejected. For example in the case of auctions, a bid must be received before the end of the auction otherwise it is not valid. Another example appears in the context of payment channels 

[gudgeon2020sok] where participants have a limited interval of time to dispute the division of funds if they disagree with their peers.

A major weakness of such deadlines is that in cases where the blockchain is congested, users that submit transactions will not have them included in blocks in time. In fact, several attacks and failures can be attributed directly to this weakness (we provide some examples below). One mitigation often employed by participants is to offer higher fees for transactions with deadlines which means users are usually overpaying. Another is to extend the deadlines which greatly delays processing and settlement within the context of the relevant smart contract. In many cases, transaction fees and deadlines are decided upon in advance, before the exact conditions that will prevail when the transaction is actually transmitted are known, which causes participants to take wider safety margins and increases costs further. Due to the well-known scalability issues of blockchains [bano2019sok], we expect congested periods to become increasingly more common, which will directly impact the design of time-sensitive smart contracts.

Our Contributions. In this work we present a mechanism aimed at solving these issues. We propose to set short deadlines that are automatically extended if congestion occurs. We lay the theoretical foundations of congestion monitoring in blockchains and formalize the notion of challenge-response protocols in this context. We then propose two different protocols to detect congestion over multiple blocks: the ‘ Consecutive Blocks’ protocol defines uncongestion by the existence of consecutive uncongested blocks; its generalization, the ‘Sliding Window (K-out-of-N)’ protocol, defines uncongestion by the existence of N consecutive uncongested blocks with K uncongested blocks among them. We show that the Sliding Window protocol is more resilient to attacks than the Consecutive Blocks protocol when attacked by miners. Furthermore, we propose a new opcode for Ethereum that will provide the required functionality; we also provide an implementation (not requiring new opcodes) in Solidity, using opcodes introduced by Ethereum Improvement Proposal 1559 (EIP 1559) [buterin2019eip].

Examples of Congestion Attacks and Related Failures.

A recent well-known example of congestion-related failure took place on Crypto Black Thursday (March 12th, 2020) when the price of Ethereum dropped by more than 50% in less than 24 hours [cryptoblackthursday2]. This led to a panic-sale of coins and increased congestion. At the peak, during a 2-3 hour window, the Ethereum blockchain’s fees climbed to $1.65 on average, more than times their cost on previous days.

The drop in ETH price triggered many MakerDAO auctions to liquidate collateral (typically collateral on short positions must be sold if prices fluctuate too much). The tokens to be sold were purchased at almost no cost due to the inability of many bidders to send transactions and participate. This has, allegedly, been leveraged by one user to gain $8.3 million worth of ETH [cryptoblackthursday1].

Several studies [censorship_attacks, harris2020flood] deal with different types of attacks designed to prevent a party from responding on time to a challenge [censorship_attacks]. Harris and Zohar [harris2020flood] present an attack where the attacker forces many victims at once to flood the blockchain with claims for their funds. The ensuing congestion allows the attacker to steal the funds that cannot be claimed before the deadline. Our protocol will prevent these issues by extending the deadlines until the congestion passes.

2 Related Work

Congestion is a real-world problem faced by the most prominent cryptocurrencies. In addition to the popular examples of Crypto Black Thursday or Cryptokitties, widely discussed online [cryptoblackthursday1, cryptoblackthursday2, consensys_2018], Sokolov [sokolov2021ransomware] examined periods of congestion caused by ransomware.

One way to deal with congestion is to improve the scalability of the underlying consensus protocol [sompolinsky2018phantom, sompolinsky2015secure, sompolinsky2016spectre, croman2016scaling, eyal2016bitcoin] or to introduce higher-level layers that help to scale. Solutions ranging from sharding [wang2019sok], off-chain payment channels [gudgeon2020sok] or layer-zero optimization [tanana2019avalanche] (i.e., network-level optimization) have been considered. All these solutions improve the number of transactions per second that the network can process, but congestion may still occur even at higher rates.

Other methods that help to ensure that time-sensitive transactions are processed are rather ad-hoc. For example, the replace by fee [replace-by-fee] and child pays for parent [cpfp] mechanisms allow users to add or change the fees of their transactions. Bitcoin’s fee mechanism—equivalent to a first-price auction—is sub-optimal and often results in users paying more than what is necessary. EIP 1559 was made to change this mechanism in Ethereum [roughgarden2020eip, buterin2019eip]. EIP 1559 implements a base fee that is burned. This base fee can be seen as an indication of the level of congestion in recent blocks, and we utilize this in our implementation.

Another line of research that could potentially prevent transaction fees from spiking considers order-fairness consensus protocols [kelkar2020order, kursawe2020wendy]. The idea is to ensure that transactions are ordered in the blockchain in the same order they arrived in. This also helps to avoid problems such as front-running [daian2019flash].

3 Preliminaries and Definitions

3.1 Challenge-Response Protocols

A challenge-response protocol is an implementation of a pattern in which some party must respond to a challenge within a fixed time limit. This pattern consists of a challenge that takes effect at time and a response deadline which is the latest time by which response to the challenge will be accepted. We call the time period between and the challenge window. Responding to the challenge during the challenge window yields different results compared to responding after the deadline. The protocol we propose inspects the challenge window period and extends it (by extending ) as long as the blockchain stays congested.

3.2 Blockchain Congestion

Our protocol has two components. First it relies on a mechanism to define what it means for a block to be congested. We then use this definition to define an uncongested period. Intuitively, a period will be (un)congested if some threshold of blocks is (un)congested. We start by defining block congestion before moving on to presenting different period congestion definitions and choosing one that meets our requirements.

Blocks and Transactions.

A block is as a set of transactions (we ignore the order of transactions in the block as well as other data—such as nonce—as they are irrelevant to our problem). Transactions pending to be included in a block are kept locally by each node in their mempool until they are included in the chain. Each transaction has a size , and a fee density . The fee paid by the transaction is therefore . We define the total weight of transactions in a block with a fee density above as .

Blocks can contain transactions with total size bounded by , i.e., . For simplicity, we treat every block as full, i.e., for any (if necessary, we fill them artificially with transactions with a fee of 0).

The total amount of fees collected from a block by the miner is . If the size of the mempool is bigger than the maximum block size , we assume that honest miners choose the transactions in a way to maximize the fees they get.

Period.

A period in the blockchain is a non-empty sequence of consecutive blocks. We denote the length (number of blocks) of the period by , and write for : . For a period , we say that period is included in and note if every block in is included in .

In this work, we want to capture the notion of congestion: a phenomenon where there’s a spike in the number of transactions waiting in the mempool. Since the mempool is not part of the blockchain, we instead rely on the data in the blocks in order to define congestion. We propose the following definition for block congestion.

Definition 1 (-congestion).

We say that a single block is -conges-ted if and denote , where is the corresponding indicator function.

Per this definition, all transactions above fee density are examined and required to make up at least a -fraction of the block in terms of size. Intuitively, for the definition captures that if a block is -congested, a transaction needs to have a fee density that is at least in order to have a better chance of being included. In other words, we use the price of entering a transaction to the blockchain as a reliable signal for congestion.

For a block and a fee density , we define the -weight threshold as the maximum fraction of the block weight under which the block is -congested. From definition 1 it is clear that . Similarly, for a block and a fraction , we define the -fee density threshold as the maximum fee density under which the block is -congested ().

Block Manipulation.

One of the key measures we are interested in is when is an adversary able to manipulate blocks’ congestion signals. When a miner mines a block, they can choose to include transactions from their mempool or to add dummy transactions that move money between their accounts and pay a fee (to themselves), making the fees appear different than they ought to be. However, miners cannot manipulate blocks at arbitrary heights, and doing so would incur a cost. The miner’s chance of mining a new block depends on its relative computational power. Therefore, as is standard, we denote the computational power of an adversary by

. Each block has a probability

to be mined by the adversary, and to be mined by the other miners. Furthermore, giving up mempool transactions means missing out their fees and hence induces a loss that we compute in the next two propositions.

Proposition 1.

An adversary manipulating a block to make it -conges-ted when it is not, will lose a potential profit of at-least .

Proposition 2.

An adversary manipulating a block to reverse its signal from -congested to not congested will lose a potential profit of at-least .

The proofs for both propositions can be found in Appendix 0.A.1.

Before moving on to define period congestion, we note that there exist other ways in which block congestion could be defined. For example, in Section 5, we take the EIP 1559 base fee as a measure of congestion and use it to implement our suggested protocol. We include several other examples that are less efficient in Appendix 0.B.

Congestion Vector of a Period.

To determine whether a period

is uncongested we will refer to the congestion vector

which consists of the congestion signal of its blocks. Intuitively, if most of the blocks in the period are congested then the period is congested and vice-versa. However, we must also account for the fact that an adversary may be able to change the congestion signal of some of the blocks, as already discussed. We will consider different protocols to define period uncongestion, a situation in which the period is considered not congested. An uncongestion period protocol is a function that we denote by . This function takes as input a binary series representing the congestion signal of the blocks in the examined time period. It will return 0 if the period is congested and 1 otherwise. This function can furthermore be extended to also provide auxiliary information such as a proof in the case where the period is uncongested. For the efficiency of the protocol, we will strive for a definition that can provide a compact and easy-to-verify proof. Throughout the rest of the paper, we use

to denote the binomial distribution with parameters

and .

Definition 2 (Period Manipulation).

For a period and an adversary with a fraction of the total computational power, we associate a manipulated period defined as follows. For the adversary can replace with probability , with a block that has a congestion signal of their choice. We denote by the vector that indicates which of the blocks in the given period the adversary controls, meaning the adversary can replace the block’s congestion signal iff . We then define the adversary’s manipulation set . Intuitively, corresponds to the set of possible congestion vectors that the adversary could create by changing the signal of the blocks that it controls.

In a real world setting, even if there is a long period of uncongestion, it could be the case that one or more of the blocks are fuller than the others due to some randomness in the transactions’ arrival time (e.g., there was a temporary high transaction volume). To account for this randomness, we make a simplifying assumption that blocks are congested independently with probability and say that the blockchain is congested. We note that, in reality, congestion is often changing and is usually correlated when considering several consecutive blocks. We leave more complex models of congestion for future work. In our case, the congestion vector of a period chosen at random has a binomial distribution: . When studying attacks where the adversary tries to convert a congested period to an uncongested one, we will assume that is close to one (i.e., most of the blocks are congested), whereas when studying the opposite case, we will consider to be close to zero.

Our protocol consists in extending the deadline of challenge-response in the event of a congestion period. However, to avoid an edge case where the deadline is extended indefinitely, we define , an upper bound on the total length of the extended period.

Definition 3 (-maximum Extension).

Given a challenge-response protocol in a congested blockchain where the challenge starts at block height , we say that is the maximum extension of the challenge if the deadline cannot be extended further than height .

3.3 Desirable Properties of Protocols

In this section, we define some properties that we aim for our protocol to achieve.

In the rest of the paper we use the notation to denote that was selected randomly from the distribution . We start by describing the two types of attack that we will consider—a congestion attack and an uncongestion attack—before defining the robustness of the protocol, which captures the security of the protocol against either attack.

Definition 4 (Congestion/Uncongestion Attack on ).

Given a period , chosen at random in a -congested blockchain, we say that the adversary wins a congestion, resp. uncongestion, attack on if it can manipulate into an uncongested, resp. congested, period.

Definition 5 (-congestion Robustness).

We say an uncongestion period protocol is -congestion robust if, given an adversary with a relative computational power , his probability of winning a congestion attack, i.e., of successfully manipulating a period of blocks into a congested period , is less than .

Definition 6 (-uncongestion Robustness).

We say an uncongestion period protocol is -uncongestion robust if, given an adversary with a relative computational power , his probability of winning an uncongestion attack, i.e., of successfully manipulating a period of blocks into an uncongested period , is less than .

Definition 7 (Monotonicity).

A congestion protocol is monotone if for every two periods and , if and is considered uncongested, then so is , i.e., .

A monotone protocol is easier to verify as the prover only needs to select a portion of blocks from the time period in order to prove uncongestion. Furthermore, a monotone protocol requires only sporadic access to the blockchain. A prover can go offline and prove uncongestion when they come back online by choosing any uncongested period from the time they were offline. In the case of a non-monotonic protocol, if the prover is offline during an uncongested period, they cannot prove the uncongestion of the longer period, after they came back online, they missed the uncongested period.

Efficiency Properties.

We define two properties that capture the efficiency of the protocol.

  • Concise proof size The evidence needed to prove uncongestion of a period should be as concise as possible.

  • Concise refresh information The extra information needed to be kept when checking the congestion signal of a period that has already been extended due to congestion should be as concise as possible. Ideally, when we extend a period from to in order to check for congestion, we should not have to recheck every block in but, rather, aggregate this information.

In the next section we will discuss different period congestion protocols with the goal of finding one that will be proof efficient and robust against an attacker with reasonable hash rate with high probability.

4 Uncongested Period Protocols

In this section, we examine different protocols that fit the definition of congestion of a period . We start by presenting “naive” protocols and discuss why they are not good enough, i.e., why they lack the desirable properties defined in Section 3.3.

4.1 Strawman Protocols

Definition 8 (Cumulative M).

Period is uncongested if there exists M blocks which are uncongested: .

This protocol is monotonic but is not sufficiently robust to adversarial attacks: if we wait long enough, the probability of the adversary controlling M blocks becomes overwhelming (even if is small). We solve this in the next strawman by considering the percentage of blocks instead of a fixed number.

Definition 9 (Percentage).

A period is uncongested if of its blocks are not congested: .

This protocol is much more robust but has the drawback of not being monotonic. For example, if all blocks are uncongested during the first part of the period and congestion begins in the second part, then the beginning of the period is uncongested while the whole period may not be.

We now suggest the following monotonic rule:

Definition 10 ( Consecutive Blocks).

A period is uncongested if there exists at least L consecutive uncongested blocks included in it:
.

We show that this protocol is monotonic and inspect its efficiency in Appendix LABEL:app:proofs2. We now evaluate its robustness.

Evaluation of the Robustness of the Consecutive Blocks protocol.

We examine situations where the adversary attempts to manipulate the congestion signal for a given period. We separate this into two attacks: uncongestion and congestion attacks (as in Definition 4). We strive to achieve a high defense rate against both attacks, meaning finding a value that will give a low probability for an adversary to succeed in each of the attacks separately.

Evaluation of the Uncongestion Attack.

In order to compute the probability of an attacker to successfully manipulate into an uncongested period, we define the following matrix :

(1)

and denote by the unit vector of dimension +1 (i.e., has a 1 in the coordinate and 0’s elsewhere).

Theorem 4.1.

The probability of an attacker with a relative computational power to successfully manipulate into an uncongested period in a p-congested network equals .

Proof.

We note that, at each block, the attacker has a probability to mine the next block, which allows them to decide its congestion level. In this context, this means setting the block to be uncongested. In addition, the congestion signal of a block not mined by the attacker depends on the prevailing congestion state which is expressed by . The probability of an honest block being congested, resp. uncongested, is hence equal to , resp.

. We define the following Markov chain that describes a random walk on

’s blocks and whose states represent the number of consecutive blocks that are uncongested at a point in time.

The initial state is since it corresponds to the 0 consecutive uncongested blocks at the beginning of the walk. With each step, we move from state to state , for , if the block is uncongested, and return to state if it is not. If we reach state , we stay there since it means the adversary has reached the goal of consecutive uncongested blocks in and can manipulate it to an uncongested period.

T is the corresponding transition matrix; hence the probability of reaching state in steps is expressed by . ∎

Evaluation of the Congestion Attack.

For the attack in the opposite direction we define as follows:

(2)
Theorem 4.2.

The probability of an attacker with a relative computational power to successfully manipulate into a congested period, in a p-congested network equals .

Proof.

This time, if the attacker succeeds in mining a block, they will make it congested. Therefore the probability for a block to be uncongested is . As before, we define the following Markov chain whose states represent the number of consecutive blocks that are uncongested at a point in time in :

is the corresponding transition matrix. Therefore, the probability for the adversary to succeed in the congestion attack is equivalent to the probability that the rest of the miners will not reach the state in steps, which is expressed by: . ∎

Now that we have the attacks’ success rates, we examine the robustness of the protocol against both attacks for different values of .

Although attacks are potentially expensive for the adversary (who needs to change the contents of its block and, hence, loses transaction fees), we still desire a low success probability for the attack even for strong attackers. We assume in the following evaluations that the attacker controls of the computational power.

Given that congestion may cause period extension, we need a value for that gives protection also against attacks over longer periods. We examine the behavior of the protocol for periods as long as using different values for .

The value should represent realistic network conditions. For our analysis we pick when studying the congestion attack, to simulate more congested settings, or when studying the uncongestion attack, to simulate relatively uncongested settings. Other values can be plugged in, if needed, for other conditions. We start by examining the robustness of the protocol for a period of 1 day.

Figures 0(a)-0(b) present the probability of success in both attacks for two different period lengths: 6450 blocks in Figure 0(a) and 144 blocks in Figure 0(b). These periods correspond, roughly, to a single day in Ethereum and a single day in Bitcoin. The red curves correspond to the congestion attack and the blue curves to the uncongestion attack. We compute these probabilities for different values of .

(a) day in Ethereum
(b) day in Bitcoin
Figure 1: Attack success rate as a function of , for

The results in both figures show there is no value that gives a probability of success less than for both attacks. Formally, it shows that the Consecutive Blocks protocol cannot be simultaneously -congestion robust and -uncongestion robust. Therefore, we find the

Consecutive Blocks protocol not sufficiently secure. Intuitively, this is because more robust estimates of congestion are typically obtained over longer observation windows. The

Consecutive Blocks protocol obtains longer observations if is increased, but then the requirement for consecutive blocks to be uncongested is too strict and is not robust. As a result of this insight, we propose a new protocol that generalizes the Consecutive Blocks protocol and allows for longer observation windows with a relaxed condition for uncongestion.

4.2 Sliding Window (K-out-of-N) Protocol

Definition 11 (K-out-of-N Sliding Window).

A period is uncongested if there exists a period of length included in it in which at least blocks are uncongested.

We note that the Consecutive Blocks protocol is a special case in which .

Proposition 4.

The Sliding Window protocol is monotonic.

Proof.

Given an uncongested period , according to the Sliding Window protocol, which is included in period :

We now evaluate its efficiency.

Proof Size.

In order to provide evidence for the uncongestion of a period of size , it is enough to point to a window in which uncongestion occurs. Formally, to present s.t. .

Refresh Information.

Given a congested period , and that extends it, in order to determine the congestion level of the extended period , it is enough to check only windows that overlap blocks in .

Evaluation of the Sliding Window Protocol’s Robustness.

We consider the two attacks in Definition 4. We first note that the two attacks may differ in their consequences. While the congestion attack can cause a delay in the response deadline (i.e., a deadline will be extended even if it is not really needed), the uncongestion attack might lead participants to miss the chance to respond on time, as the deadline will not be extended even if the network is congested. The damage in each case depends on the particular use case. For example, in the case of payment channels, not responding in time is more severe and may lead to financial losses. We strive to achieve a high level of security against both types of attack, i.e., to find values for parameters () that will yield a low probability of success for both.

We begin by presenting upper bounds on the probabilities of success in each of the attacks.

Theorem 4.3.

The probability of an attacker with a relative computational power to successfully manipulate into an uncongested period, in a p-congested network, is bounded above by , for .

Proof.

The probability for a block to be uncongested during this attack is . In a period of size , there are different sliding windows. We denote by the event in which there are out of uncongested blocks in the sliding window. Therefore, the probability of a single sliding window being uncongested is . To succeed in the uncongestion attack, at least one of the sliding windows has to be uncongested, which is expressed by . We use the union bound to bound this probability and get:

Theorem 4.4.

The probability of an attacker with a relative computational power to successfully manipulate into a congested period, in a p-congested network is bounded above by , for .

Proof.

The probability for a block to be uncongested is . We denote by the event in which there are less than uncongested blocks in the sliding window. The probability of a single sliding window being congested is . To succeed in the congestion attack, all sliding windows in the period must be congested, which is expressed by . We bound this probability by , i.e., we consider a subset of events that are independent from each other (removing overlapping windows). We compute the intersection of the pairwise independent events and get: . ∎

We would like to compute the robustness of the protocol for 1 day to 1 hour sliding windows. We examine the situation where a period of size is chosen at random and the blockchain is for values of (relatively congested) and (relatively uncongested) against an attacker with computational power . In the evaluation, we allow periods to be extended up to two weeks, a reasonable time for congestion to pass. We set the -maximum extension (see Definition 3) accordingly (90300 blocks in Ethereum and 2016 blocks in Bitcoin).

We first evaluate the attack over Ethereum, computing the above bounds for different sliding window sizes. We begin with a sliding window of 1 day (), setting . Figure 2 presents the two upper bounds for the different possible period lengths . For the protocol to be considered secure, we need low values in both curves for the different period lengths (since periods might be extended). As can be seen, the probabilities in the graph are extremely low, showing the protocol to be very secure. We emphasize that the blue curve is not horizontal, as shown in the graph; all of its values are smaller than . Note that these are only upper bounds; the actual probabilities are even lower.

Figure 2: Upper bounds on the attacks’ success rates as a function of the period length, for

We evaluate the attack for smaller sliding windows. The following table summarizes our results:

N K Uncongestion Congestion 6450 (1 day) 3225 3225 (12 hours) 1612 1612 (6 hours) 815 806 (3 hours) 421

The wider the sliding window is, the greater the protection. For smaller sliding windows, such as 1 hour (), we can achieve a defense rate against each attack if we lower the attackers’ computation power to (instead of 0.33). We provide examples of values and the level of protection they provide (an upper bound), but these are configurable and subject to the user’s discretion. One can choose to increase the level of protection from one attack at the expense of the other, or to set a larger initial period length () to increase the protection.

Next, we want to know what happens with smaller periods such as in Bitcoin, which has longer block intervals. To do so, we set and begin with a sliding window of 1 day ().

We use a simulation to draw 100,000 samples of congestion vectors and to compute the success rates of both attacks among the samples (Figures 3

a,c,d). We use error plots to plot the standard error of the data; however, the errors are very small and therefore are almost invisible in the graphs.

(a) Attack success rate as a function of K, for
(b) Upper bounds on the attacks’ success rates as a function of the period length, for
(c) Congestion attack success rate as a function of the period length, for
(d) Congestion attack success rate as a function of the period length, for
Figure 3: Evaluation of the attacks’ success rates for (2 weeks in Bitcoin)

Figure 2(a) presents the probability of success in each of the attacks for different values. As the graph shows, choosing gives protection against both attacks. We compute the upper bounds (from Theorems 4.3-4.4) for this value of in Figure 2(b). The presented bounds as they appear in the graph are loose compared to the simulation results and afford a low level of defense, especially against the congestion attack. These bounds give us useful, but non-tight, upper bounds on the results for periods that are of longer length, for which the probability is extremely small. To get more precise results, we use more simulations to compute the congestion attacks’ success rate for different period lengths and present the results in Figure 2(c). Each curve corresponds to a different value of , the computational power of the attacker. The defense rate against congestion attacks is extremely low for short periods. For , we reach a defense rate only for periods of days or more. Lowering the computational power of the adversary naturally improves these results. For example, considering an attacker with computational power results in an above defense rate for period lengths starting from 2 days.

Finally, in Figure 2(d) we consider an attacker with a computational power and show the congestion attack success rate for different choices of correspondig to sliding windows of lengths 24/12/6/3 hours. We do not present the uncongestion attack results which had above defense rate for any .

We conclude that the longer the periods are, the higher and more effective the protection against attacks is. In Ethereum, we obtained very high defense rates even when choosing short sliding window sizes and against strong attackers. In Bitcoin, on the other hand, we need to compromise on the window size and on the attackers’ power to achieve higher defense.

We defined uncongested period protocols and suggested a concrete one, the Sliding Window protocol, which meets our requirements (as defined in Section 3.3). In the next section, we will describe how to use an uncongested period protocol to adjust the challenge-response protocol to deal with congested periods.

4.3 Application to Challenge-Response Protocols

A challenge-response protocol consists of a challenge that takes effect at time and a response deadline (see section 3.1). We link and to their corresponding block height and denote by the block at height .

The parties involved in the challenge decide in advance on an uncongestion period protocol UCP to use. We recall that accepts a congestion vector (a binary series representing the congestion signal of blocks in a period) and returns 1 if the period is congested and 0 otherwise. To apply the uncongestion period protocol, the parties adjust to a short deadline that gives them a reasonable time to respond to the challenge assuming an optimal case with no congestion.

The response deadline is applied only in the event that the challenge window is uncongested. In the case where the challenge window is congested, we repeatedly extend , 1 block at a time, as long as it remains congested. To avoid an edge case where the deadline is extended indefinitely, we define , an upper bound on the deadline (see Definition 3). The challenge-response protocol adjustment is summarized in the algorithm below.

while  and  do
      

We emphasize that the extension of the deadline is not necessarily carried out at the exact moment of the deadline (since smart contract actions need to be triggered by a transaction to the contract). Instead, a transaction that is submitted afterwards is determined to be either before or after the deadline given any possible extensions that are due. The uncongestion period protocol is specified in advance in the smart contract, and the deadline calculation is triggered either by a late response to the challenge or by the challenger that claims that a response did not arrive in time.

5 Implementation

We provide an implementation of the Sliding Window protocol as an Ethereum smart contract using the EIP 1559 base fee to determine block congestion. EIP 1559 implements a base fee that is adjusted up and down by the protocol according to how congested the network is. The EVM supports fetching the base fee of the highest (current) block. We suggest extending this to fetch the base fee of any block, and to add an opcode that checks whether a block is congested (without such opcodes, it is not possible to fully implement the mechanisms put forward in this paper). This opcode will receive as inputs a block and a maximum base fee (chosen by a user) and will return whether the maximum base fee exceeds the block’s base fee.

In the implementation, we set the sliding window size equal to the initial deadline of the examined period (before being granted any extension).

The full github111https://github.com/stonecoldpat/slidingwindow repository includes the smart contracts, the new opcode, and the tests. In addition, we include the Solidity code of the contracts in Appendix 0.C.

6 Conclusion

In this paper, we tackled a problem that arises when challenge-response protocols face congested periods. When the network experiences congestion, users will often miss the response deadline, which can lead to serious issues including financial loss. We formalized the problem and proposed a new protocol called the Sliding Window as a solution. Our protocol defines a reliable way to detect congested periods by looking only at the data available on-chain. We then used this to extend the challenge-response deadline when congestion occurs. We studied the security of the protocol for different parameters. Our results showed that it is possible to decrease the time settlement (deadline) of challenge-response protocols significantly, while expanding the security of the protocol to deal with cases of congestion.

For future work, it would be interesting to evaluate and optimize this protocol and its security analysis for more realistic congestion settings—in particular, settings in which congestion is correlated between consecutive blocks—and to provide more experimental analysis of these settings. Is is also of interest to explore whether Ethereum’s proposed base fee can be used as a sufficiently robust congestion signal.

7 Acknowledgments

Ayelet Lotem and Aviv Zohar are partially supported by grants from the Israel Science Foundation (grants 1504/17 & 1443/21) and by a grant from the HUJI Cyber Security Research Center in conjunction with the Israel National Cyber Bureau.

References

Appendix 0.A Proofs

0.a.1 Proofs of Section 3.2

Proof of Proposition 1.

Proposition 1.

A miner manipulating a block to make it -congested when it is not will lose a potential profit of at least .

Figure 4: Cumulative function of the -weight threshold of a block before and after miner manipulation
Proof.

Given a block which is not -congested (), it is possible to manipulate it into a block which is -congested () by replacing some of its transactions with dummy transactions that have fee density . In order to maximize its revenue, the adversary will remove the transactions with the lowest fee density. The minimum portion of transactions that the adversary needs to remove is (by the definition of ), and by doing so the miner misses the rewards associated with removing these legitimate transactions.

Using the notations from above, we compute a lower bound on the miner’s loss, which can be expressed by (see Figure 4). Note this is only a lower bound since a miner can remove transactions only in their entirety and not parts of them. ∎

Proof of Proposition 2.

Appendix 0.B Block Congestion Definition: Examples

In Definition 1, we offered to define the congestion of a block based on the fee densities. Other, less effective, ways in which block congestion could be defined are listed below:

  • By transaction with lowest fee density: A block is -congested if the lowest fee density for a transaction in it is bigger than : . However, a miner could decide to always enter a single transaction with a very low fee density (less than ) and easily change a block from congested to not congested; hence this scheme is easily manipulable.

  • By transaction with highest fee density: A block is -congested if the highest fee density of its transactions is bigger than : . A miner could decide to always enter a single (dummy) transaction with a high fee density (higher than ) and easily change a block from not congested to congested; hence this scheme is also easily manipulable.

  • By non-zero-fee transaction occupancy (”block size”): A block is -congested if it is full at -fraction of its occupancy with non-zero-fee transactions: . A miner could artificially add transactions with positive fee density to fill the block at no cost.

  • By transaction fees (instead of fee density): A block is (,)-congested if at least a fraction of it is filled with transactions with fees above some value : . A miner could prioritize transactions by their size in order to decide the congestion signal, without lowering his profit from the fees ().

Appendix 0.C Code

contract SlidingWindow is BlockchainMock {
  function isPeriodCongested(uint startBlock, uint k, uint n,
   uint maximumBaseFee) public view returns (bool)
   require(nk, ‘N should be greater than or equal to K.’);
   require(blocks.lengthn, ‘Total should be greater than or equal to N.’);
   uint totalCongested = 0;
   bool[] memory recordCongestion = new bool(blocks.length startBlock);
   for(uint i=startBlock; i startBlock+n; i++)
    // Keep a record of this block’s congestion.
    recordCongestion[i] = isCongested(i, maximumBaseFee);
    // Sum of congestion (so far).
    if(recordCongestion[i])
     totalCongested = totalCongested + 1;
    
    if(totalCongested=k)
     return true;
    
   
   // Activate the sliding window.
   for(uint i=startBlock+n; iblocks.length; i++)
    // Remove start of the window.
    if(recordCongestion[i-n]
     totalCongested = totalCongested - 1;
    
    Keep a record of this block’s congestion.
    recordCongestion[i] = isCongested(i, maximumBaseFee);
    // Add to the end of the window.
    if(recordCongestion[i])
     totalCongested = totalCongested + 1;
    
    if(totalCongested=k)
     return true;
    
  // Not congested.
  return false;
  
contract BlockchainMock {
  // Simulate block.basefee(). EVM only fetches the current basefee.
  struct Block uint baseFee;
  Block[] public blocks;
  // Should the caller consider this block congested?
  function isCongested(uint blockNumber, uint maximumBaseFee)
  public view returns (bool)
   if(blocks[blockNumber].baseFee maximumBaseFee)
    return true;
   
   return false;
  
contract Auction is SlidingWindow {
  bool start = false;
  uint startBlock;
  uint k;
  uint n;
  uint gasPriceCeiling;
  function startAuction(uint _startBlock, uint _k, uint _n,
  uint _gasPriceCeiling) public
   startBlock = _startBlock;
   k = _k;
   n = _n;
   gasPriceCeiling = _gasPriceCeiling;
   start = true; // Kick-start the auction!
  
  function finaliseAuction() public returns(bool)
   if(isPeriodCongested(startBlock, k, n, gasPriceCeiling))
    return false;
   
   return true;