Ethereum Founder Suggests Hard Fork To Stop DoS Attacks
After weeks of multiple denial-of-service attacks, Vitalik Buterin has suggested that a EIP150 hard fork will likely be needed to repair the network.
By executing the EIP150 (Ethereum Improvement Proposal) hard fork, gas costs will be reduced. The current constant activity has driven gas prices up to prevent these DoS attacks. With the EIP150 hard fork, it will re-stabilize the gas price markets for verifying transactions.
Since the attacks, transactions have slowed down and Ether deposits and withdrawals have been delayed due to the rising cost of gas. Exchanges like Kraken have notified their customers that delays in processing transactions may take a few days. In the case of ShapeShift, the exchanged moved ETH offline for some time in hopes to reduce the attacks. ETH did return to ShapeShift that same day.
The Foundation and its developers have been working non-stop to halt these attacks. In the process, they have released five different Geth versions. However, none have fixed the problem.
The hard fork was recommended by Ethcore’s founder, Gavin Wood, last week. Wood said since there is no way to tell when these attacks will end, causing a hard fork will resolve these attacks.
He continues, “I have been calling for a fast hard fork since day 1. It would be around 4 minor changes to the yellow paper and each implementation, yet there has been little movement on it.”
Ethcore, which operates Parity and is also struggling with these attacks, suggested miners should “retarget” their gas limit to 500k until the hard fork is sorted. The tweet continued by saying the Ethereum Foundation will soon make a statement.
Ethereum is not the only one under attack. Ethereum Classic announced they were also suffering from DoS attacks, which has caused the value of ETC to drop more than 10 percent.
We have reached out to the Ethereum Foundation for a comment and are waiting for a response. ETHnews will continue to update this story as more information is available.
Read Vitalik’s full statement below:
On Gas Price Markets self.ethereum
In response to the set of gas price changes proposed in EIP 150 to remedy recent denial-of-service issues, a number of commenters have asked: rather than tweaking gas prices manually, is there not some more general mechanism that could be introduced that could adjust gas prices automatically? EIP 150 is a response to the fact that hard drive access as a category is currently underpriced, but as technology inevitably changes it may well be the case that in the future other imbalances will emerge. What if, ten years from now, bandwidth improves by 50x but computing only improves by 5x? What if hard disk storage space ends up costing almost nothing? What if the virtual machine becomes highly optimized, but calling continues to be as inefficient as it is today?
There are several categories of solutions that have been considered, including:
- Miner voting - allow miners to vote on the price of each individual opcode
- Market-based schemes - allow transactions to specify what gas schedule they execute with, and allow miners to choose what gas schedules they accept
- Timing games - come up with an in-protocol challenge-response algorithm to encourage transaction senders to find transactions that take a long time to process, and use this information to determine which opcodes need to be made more expensive
These solutions have also been explored since at least 2014 in a different context - namely, automatically lowering gas prices for precompile contracts that all client implementations have optimized. In that case, all such approaches were ultimately abandoned, the primary argument being that the scheme would be too easy to exploit: a malicious actor could come up with a contract that could under normal circumstances be executed quickly, but which had a few "worst-case inputs" known only to the attacker where all optimizations are impossible. Coming up with such a contract and getting it accepted as a gas-discounted precompile would lead quickly to a denial-of-service opportunity. Another category of exploit is in creating a contract which an attacker could execute quickly, but all others could not; this was the Achilles' heel of all timing-based approaches. Hence, the present status quo, where new precompiles can only be added via hardfork, was the only feasible option.
In the context of opcodes, many of those arguments do not apply. No one has the ability to "create their own" opcode; all that we have are the opcodes that are included as part of the protocol, and so it seems much less likely that an attacker could discover some hidden edge case or trapdoor for them. Thus, a dynamic gas pricing scheme is in fact much more likely to be successful. However, even still a number of additional concerns remain.
- Secondary purposes of a gas limit - many gas pricing proposals have in mind a notion that the gas limit is only about limiting block processing time. However, the gas schedule also serves other important purposes; a particularly important one is limiting the growth of the state size, and in the future limiting the size of the Merkle proof needed to show validity of a block. Allowing miners full freedom in choosing the gas schedule would lead to such concerns being neglected since individual miners have no incentive to pay attention to them due to the tragedy-of-the-commons problem.
- The global block gas limit - there is a global block gas limit, and it is an intention of this limit that it actually places a hard cap on the total quantity of computational and other resources that need to be consumed in the process of verifying the block. However, if miners can somehow accept gas schedules where every opcode is much cheaper, then this creates an opportunity to circumvent this limit.
- Loss of guarantees - it is considered desirable to try to avoid adjusting gas costs upwards if at all possible, as such an action could break any calls that are made with a static amount of gas. Fortunately, today almost all calls simply pass all the gas to the callee, but in the future (eg. if total-functional high-level languages become popular) this may change.
However, there is one "partial path" that can get us quite far: segregate gas costs by category. That is, instead of having a single gas cost that covers everything, we can have several categories of gas cost, representing:
- Computation time
- Size of the Merkle proof for the block
- Bytes added to history
- Bytes added to state
- Polluting the bloom filter
- Transaction data / bandwidth
There have already been proposals for separating out storage costs with a "storage rent" scheme. But we can theoretically go further. One other very cleanly divisible change that could follow is a separate gas cost schedule for computation and for transaction data, so users would specify a gas price per execution-time gas and a gas price per byte. Transaction data is paid for only at the top level of execution, and miners have just as much of a disincentive to create data-heavy blocks as they do computation-heavy blocks, so none of the above objections would apply.
It could be possible to create a gas schedule for opcodes that enforces a minimum gas price to pay for history, state and Merkle proof bloat, and allow a dynamic scheme to handle the execution time component. In essence, we would rely on the uncle rate disincentive (the fact that computation or data-heavy blocks are more likely to become uncles, and so miners themselves have an incentive to avoid including too much of either) to guide gas costs for computation and data, and have other stricter formulas to limit the other dimensions of resource consumption that miners have no private incentive to control.
Coming up with such models is still a research topic; it's not reasonable to expect something like this to be researched and reviewed in time for the EIP150 hard fork, and so in the short term "Starcraft-style rebalancing" is the only realistic way forward. In the longer term, there certainly are ways that the gas schedule can be made much more flexible.