Print Page - An attack strategy on the Ethereum network based on Block Stuffing.

An attack strategy on the Ethereum network based on Block Stuffing technique and the Deathstar smart contract.
By gbianchi (https://bitcointalk.org/index.php?action=profile;u=140582) bitcointalk.org
Translated by fillippone (https://bitcointalk.org/index.php?action=profile;u=1852120).

This study stems from some observations:

in the Ethereum network there is no concept of a "forbidden smart contract", the network is permissionless, meaning any user could possibly enter any type of code on the network, as long as the code is formally correct and pays for executing and running the code;
the only mechanism to "govern" the execution of the code is the fact that the execution of any smart contract costs gas, proportional to the number of instructions executed and the type of each instruction. Not necessarily each smart contract has to execute useful operations: it can create a meaningless gas-burning loop.
once it is entered in the network, the code is immutable, so there is no way to “get rid” of the smart contract from the network unless a hard fork-type like what happened with The DAO. But while the hacker of The Dao just exploited a bug in the contract to fund its child DAOs, Ethereum's core architecture is used here, making it really difficult to design a fairly effective hard fork.
Each block has a maximum size defined not by the size in Bytes, but by the maximum GAS that can be spent in the block.
After the London hard fork, the "normal" size of the block is variable around an average of 15,000,000 of gas and can increase up to 30,000,000 of gas based on the demand of the network, with a process called tâtonnement.
Briefly, the maximum size of a block is given by BlockGasLimit.
In the past, attacks have already been performed with the BlockStuffing technique and no effective structural solutions have been found. [3] (#post_three)

Quote
3.3.3 DoS with Block Stuffing (V31).
This vulnerability was first observed from the Fomo3D contract [23].
The vulnerability entails only the attacker's transactions being included in the newly mined blocks
while others are abandoned by miners for a period of time. This can happen when the attacker offers a higher
gasPrice to incentivize the miners to select the attacker's transactions. This vulnerability is caused by the greedy
mining incentive mechanism. At the moment of writing, there is no solution to prevent this vulnerability.
Advanced MEV technologies can also be used [4] (#post_four)[5] (#post_five) to maximize the possibility that our smart contract is included in the next block, scanning the mempool and verifying what are the fees with the highest gwei/gas to execute the transaction with the highest probability of being included.

Based on these observations, it is possible to design a "DeathStar" smart contract whose execution costs exactly the amount of gas needed to fill the block, so that it "burns" ethers only to compete with the other smart contracts for block inclusion.

Briefly, the transaction is buying the entire space of an ethereum block, and therefore does not remain any available for the execution of other smart contracts.

Reasons for a BlockStuffing attack

A group of attackers could be incentivized for various reasons to burn ethers to jeopardize the network, for example:

Being supporters of another competing blockchain protocol.
Organizing a short on Ethereum before the attack, congesting the Ethereum network and short covering at lower prices, covering the initial costs of the attack and eventually profiting from it.
Cause problems/slow down/ profit from one or more of the various smart contracts running on Ethereum to take advantage of certain conditions (prize draws, online auctions, ICOs, financial transactions on DEX, Defi, etc ... as it already is been done [2] (#post_two))

In general, any person or group with sufficient economical and technical means and with any type of interest in the decline of the Ethereum network and/or the smart contracts running on it , could use this line of attack.

To estimate the cost involved, consider that an ethereum block is mined every approximately 15 seconds. Estimating the average block size of 15,000,000 gas, and a gas cost of 100 gwei, that's about 1.5 ETH per block. Let’s add a 10% fee to be the most competitive, we could then estimate a cost per block of about 1.65 ETH. At this cost of gas, at the current exchange rate of about $ 4,000 for an eth, an attack lasting 60 minutes would cost about 400 ETH, or about $ 1,600,000, a very small figure in relation to the value of the network of hundreds of billions of dollars.

Obviously, this estimate varies according to the current cost of gas in gwei, and the eth/usd exchange rate, both of which are extremely variable.

DeathStar technical description

Using the solidity language, a smart contract is encoded executing a loop burning all the gas
passed by the calling transaction with the GasLimit parameter.

Eventually, you can create various slightly different versions of DeathStar, to make it more difficult to identify them by a possible HardFork or from a filter software added by miners or nodes, but each one of them working according to the same logic as in the examples that I will report here:

Examples Code of DeathStar code:

Code:

pragma solidity ^0.6.0;

// this version just before running out the gas stops,
// leaving a small margin of gas to execute the return instructions without error
pragma solidity ^ 0.6.0;
contract DeathStar_a
   {
   function DeathLoop_a () public payable returns (bool)
      {
      uint left = 0;
 
      while (true)
              {
              left = gasleft ();
 
              // just before finishing the gas stops,
              // leave a small margin of gas to execute the return statements without error
              if (left <1000)
                {
                break;
                }
              }
 
      return (true);
     }

Code:

// this version loops until it reaches the out of gas error.
pragma solidity ^ 0.6.0;
contract DeathStar_b
   {
   function DeathLoop_b () public payable returns (bool)
      {
      while (true)
              {
              }
 
      return (true);
     }
   }
   }

Brief description of the dynamics of the BlockStuffing attack:

1) launch your own geth node: geth --syncmode "light" --mainnet
It will instantly synchronize because it downloads the previous blockchain.
We will be necessarily autonomous and not pass trough proprietary API’s that could ban us during the attack.

2) pre-load a certain number of deathStar smart-contracts on the network,
each at a different address and with slightly different code (DeathStar_a, DeathStar_b, etc. ), to make it difficult either for mining pools to recognize us or for developer recognise the necessity of a possible hard fork,
3) Find an adequate number of ETH, based on the duration of the attack and the current gas coast in gwei, and pre-load them on a certain number of source addresses.
(15,000,000 average block size * (gas cost in gwei + incentive fee (Tip) to be certainly included in hte block)) / 1,000,000,000= cost in ETH for a 15 seconds attack)

4) create a script (python, perl, c, go .... or any language of your choice) that uses RPC calls on geth and does more or less the things summarized here:

Code:

# if DeathLoop_a stops working,
# switch to DeathLoop_b and so on.
CalledDeathStar = Deathloop_a

while (newly mined block)
   {
   reads the current baseFeePerGas and BlockGasLimit.  
   calculates GasBurned = BlockGasLimit-X (where X is used to leave a small space for other transactions as well, to be decided if X> 0)
   calculates the transaction fees: MaxFeePerGas (in gwei) = BaseFeePerGas + Tip  
       (where Tip is the percentage that goes to miners, let's say 20%, to be sure to be included in the next block, eventually use MEV techniques to maximize efficiency)
   create a transaction with gasLimit = GasBurned, MaxFeePerGas, which executes the CalledDeathStar smart contract from a random address selected amongst the origin address list.
       (the origin address also should vary to avoid being easily recognized and blocked )

   # optional
   while (our transaction is not included in a mined block)
     {
     use MEV techniques to check in the mempool the fees of other transactions
     If higher fees transactions have been loaded 
            Eventually adjust the fees for our transaction by re-entering a transaction with the same nonce and modified fee.
     }
   }

5) run the script.

Thanks to the guys from the Italian community of bitcointalk.org (filippone, acquafredda, HostFat, jack0m and others) who gave me interesting ideas for the realization of this study.

References:

[1]ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER (https://ethereum.github.io/yellowpaper/paper.pdf)
[2]The Anatomy of a Block Stuffing Attack (https://medium.com/hackernoon/the-anatomy-of-a-block-stuffing-attack-a488698732ae)
[3]A Survey on Ethereum Systems Security: Vulnerabilities, Attacks, and Defenses (https://dl.acm.org/doi/fullHtml/10.1145/3391195)
[4]How to Fix Ethereum’s MEV Problem and Give Traders the Best Price (https://www.coindesk.com/markets/2021/07/27/how-to-fix-ethereums-mev-problem-and-give-traders-the-best-price/)
[5]Ethereum is a Dark Forest (https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/)
[6]How Bitcoin and Ethereum solved the Halting Problem differently (https://infernaltoast.medium.com/how-bitcoin-and-ethereum-solved-the-halting-problem-differently-cffbb4e3045c)
[7]Why is Bitcoin not Turing complete? (https://www.quora.com/Why-is-Bitcoin-not-Turing-complete)

Bitcoin Forum

Alternate cryptocurrencies => Altcoin Discussion => Topic started by: gbianchi on September 27, 2021, 01:03:52 PM