Hacker News new | ask | show | jobs
by ForHackernews 3560 days ago
Isn't this the kind of thing that a decentralized network should be resilient against? Maybe I just don't understand blockchains.
6 comments

From the article:

> miners and nodes need to spend a very long time processing some blocks. This is due to the EXTCODESIZE opcode, which has a fairly low gasprice but which requires nodes to read state information from disk;

AIUI, the data in the blockchain isn't just "data". It's actually small bits of code that execute inside a VM, which each node needs to execute in order to "understand" the blockchain. "EXTCODESIZE" would be one of the instructions in this particular VM.

I think that most blockchains either have a complexity limit per record/transaction, or have a complexity "cost", so that complex code is more costly to insert into the blockchain.

However, in this case, it sounds like someone has figured out how to insert some code that is actually more complex than the complexity-measuring code thinks it is, and is therefore causing all miners (all users?) to perform higher-than-expected amounts of computation to parse the blockchain, to the point where they can't keep up with the network.

(Corrections welcome)

The transactions are verified by all full nodes (which are basically all users).
This is exactly correct.
It's not a network flooding attack, it's a "please each of you do this time-wasting thing" attack.
But that's also a DoS attack. If they're doing the time-wasting thing, they can't do other things... Denying service.
Sure but I think the person you replied to thinks the person the person you replied to replied to thinks it's a network attack because s/he said "shouldn't decentralized networks be resilient against this".
That's why the proposed solution is 'Sure, we'll do the time-wasting thing, but it's going to cost you more to pay us to do it'.
The network protocol agrees that operation F is priced at X, with an understanding that operation F costs Y. The decentralized nature is exactly what makes it hard to suddenly and unilaterally make a policy change of "F is now forbidden, or F now costs 100x more". This is a good thing. It means that people can't make sudden unilateral changes :)
This looks more like a bug, where the attacker exploited a function which is particularly slow and forced the nodes to run this function many times.

If the nodes had different implementations, chances would be that only some nodes would be slown down, but the reality -i assume- is that there's only 1 implementation.

Think to mail servers, if they were all running the same os/sw then attacks to the whole system could be easier.

There are actually 10+ independent implementations of Ethereum (including one in Haskell): https://www.reddit.com/r/ethereum/comments/3pdskt/how_many_e...

This was part of the development philosophy, to implement the client (based on the yellow paper http://gavwood.com/paper.pdf that specifies the protocol) in multiple languages in order to find bugs: if 2 clients don't agree on something, then we found a bug.

There are two widely-used implementations, and more that don't have as much adoption: https://github.com/ethereum/go-ethereum https://github.com/ethcore/parity
Decentralized networks benefit from no single entity being a bottle neck on connections. All a conventional DDOS does is slow down that single entity- here someone is employing the network to slow down most entities which uphold the network, achieving a very similar result.
Me neither. I thought the same. Is there some centralized single point of failure? That would invalidate the premise of decentralization surely?