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:

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.

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:

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.