39
40

ATTENTION MINERS: Recommending miners lower the gas limit target to 2 million (self.ethereum)

SouptacularEthereum - Hudson Jameson[M] が 投稿 - announcement

Although the hard fork yesterday was successful and network health improved, there is an ongoing attack that causes increased block processing times on certain blocks. Mitigation strategies are being investigated. In order to subvert some of the negative affects of the current attack, we are asking miners to lower their gas limit target to 2 million.

More details: https://www.reddit.com/r/ethereum/comments/589l6b/lol_i_think_its_another_attack_contract_burns/

全 45 件のコメント
並べ替え:
トップ (提案されたアイデア)
ベスト新着論争中古い順Q&A

[–]vbuterinJust some guy 37ポイント38ポイント  (30子コメント)

To clarify, the attack is based on making a large number of state reads with BALANCE. This was fixed by previous caching changes, but unfortunately the state is currently too big for caches to work well. A successful hard fork round two would resolve this for the short and medium term as it would make the state possible to put in memory again, but in the mean time we are also working on improvements to how state is read from disk that should further reduce disk reading times.

There is another weaker attack using the EXP opcode; this will also be fixed by HF round 2.

EDIT: more info on the "improvements to how state is read" - basically, the idea is to store an on-disk cache of address => account RLP object, so that it can be accessed directly instead of going through O(log(n)) trie nodes. Something like this is definitely needed in the long term, as we can't count on the state being memory-sized forever.

[–]InstantDossier 7ポイント8ポイント  (6子コメント)

This was fixed by previous caching changes, but unfortunately the state is currently too big for caches to work well.

If the performance of the software relies entirely on being able to keep massive portions of the state in memory you're probably going to have a bad time in the future. The state is never (disregarding null accounts) going to be getting smaller, the balance lookup is going to be bloated just with normal usage of the network let alone adversarial situations. If the lookup is slow, use that as your baseline, as an adversary can always cause you to miss your cache (like they are here).

[–]vbuterinJust some guy 11ポイント12ポイント  (5子コメント)

I totally agree. The state reading improvements are absolutely necessary.

[–]cyounessi 1ポイント2ポイント  (1子コメント)

Within this context, then, is it truly the case that these attacks are "good" because they give us an indication of how the network would behave given a much higher level of adoption?

[–]vbuterinJust some guy 4ポイント5ポイント  (0子コメント)

They definitely provide lots of data that informs future scaling decisions; in this regard I am happy that they are happening so relatively early in the game.

[–]_gst_ 0ポイント1ポイント  (2子コメント)

Are these "state reading improvements" changes to the spec, or only implementation changes?

[–]hodlor 3ポイント4ポイント  (0子コメント)

Protocol doesn't specify cacheing strategies - that's up to the client to implement. So I believe this enhancement could be a "simple" software update to geth, parity and other clients.

[–]vbuterinJust some guy 1ポイント2ポイント  (0子コメント)

Implementation changes.

[–]arrnx 7ポイント8ポイント  (1子コメント)

I believe the attacker created about ~8 millions empty accounts. Both parity and geth have some difficulties in handling many BALANCE instructions, but its not a big number, about 6000 instructions per block. I counted a cost of creating 8 millions new accounts on a blockchain (normal accounts, with balance), and it is about ~4000 ETH, just by sending normal transactions. How do you plan to solve that long-term?

[–]InstantDossier 0ポイント1ポイント  (0子コメント)

If we made say, a "proof of existence" service that sent some dust to an Ethereum account for every entry, that's way cheaper than doing with an OP_RETURN in Bitcoin by probably 2 orders of magnitude. Only, in Bitcoin it doesn't have to be indexed and stored for all time, and in memory to make nodes fast enough. There's ways in which there needs be no attacker bloating the set, people will happily do it for you.

[–]mmitech 7ポイント8ポイント  (14子コメント)

even though raising the gas prices for certain OPCODES will solve the short term issues, it seems that the whole design is flawed.

if the network can't handle a kid playing in his moms basement I am really wondering if it can properly scale so to solve real world problems...

[–]vbuterinJust some guy 6ポイント7ポイント  (9子コメント)

Bitcoin would actually have the exact same problems if it's state were to get too big for memory - you could create transactions that maximize the number of disk reads required to verify them.

Ethereum's node software is currently O(log(n)) worse but this can be fixed (and is going to be fixed).

[–]InstantDossier 6ポイント7ポイント  (3子コメント)

Bitcoin would actually have the exact same problems if it's state were to get too big for memory

Ha, no. The state (UTXO) is 2GB, and it totally isn't all kept in memory. You can tell that without even looking at code, nodes are able to operate using way less than that. It's stored in a disk based key value store, leveldb, with minimal write caching. Bitcoin has no abusable opcodes that let you randomly cause lookups for any other purpose than actually spending some outputs which helps a lot.

[–]vbuterinJust some guy 0ポイント1ポイント  (2子コメント)

The OS does a lot of caching too, so more is in memory than you think.

[–]adh0033 1ポイント2ポイント  (1子コメント)

I'm confused. The minimum RAM requirement for a Bitcoin node is 512MB. So what do you mean?

More generally, what is hard about opcode pricing? My naive understanding is that you want an pair (opcode -> gas price, gas limit) such that time/memory for a transaction stays under a reasonable bound.

If that's the case, couldn't you just model the worst cases (assuming no caching, no optimisations, a small machine) and converge to a safe opcode -> price function?

[–]vbuterinJust some guy 1ポイント2ポイント  (0子コメント)

With my calculations in bitcoin, in the worst case a single block can contain ~20,000 reads+writes (~50 bytes per UTXO to spend, assuming the UTXO is OP_TRUE, ~50 bytes per UTXO to create). That's ~333 per second, and you want to be processing blocks much faster than they're coming in so you really want something like 3330 per second. Each leveldb read is several disk reads, an SSD read is ~100 microseconds (see http://www.thessdreview.com/featured/ssd-throughput-latency-iopsexplained/). So with no memory caching in bitcoin you're cutting it close; if you want to have reasonably fast sync times you do need the memory caching. Ethereum actually isn't much worse; the BALANCE attack would do ~13000 with our eventual planned 5.5m gas limit, which is ~933 per second. Our current problem is basically that reading is done inefficiently, making O(log(n)) hops through the entire state tree, and we're working on solving this; once it's solved then there's nothing specific about ethereum that makes things much more difficult.

My naive understanding is that you want an pair (opcode -> gas price, gas limit) such that time/memory for a transaction stays under a reasonable bound.

Yes, that's basically it. The challenge is that the benchmarking so far was not done in a worst-case setting. That said, the attacker is quite kindly helping point out the defects in the original 1.0 gas schedule and it's getting to the point where after the next fork it should be fairly robust.

[–]_gst_ 2ポイント3ポイント  (2子コメント)

One thing that helps Bitcoin is the dust prevention. So it's not easily possible for an attacker to create a large UXTO state with lots of microtransactions, as there's a minimum size for each output.

Would Ethereum benefit from similar anti-dust measures? There's the planned mitigation for 0-valued accounts, but wouldn't I be able to just send 1 wei instead of nothing, to work around this?

[–]vbuterinJust some guy 1ポイント2ポイント  (1子コメント)

There is a gas cost of 25000 for creating a new account already. One thing we can do is increase it; we could also introduce some storage rent solution, but then we need to agree on which one...

[–]pixicause 0ポイント1ポイント  (0子コメント)

/u/vbuterin

I like the idea of rent solution a lot.

For me

value of a blockchain = Value of all Dapps - cost to store their immutability

If the cost to store their immutability is too high in terms of faisability or if all dapps are useless, then the value of the blockchain collapse.

[–]mmitech 1ポイント2ポイント  (1子コメント)

This DDos would be almost impossible to pull on Bitcoin, thats one of the things that bitcoin got right (UTXO)

[–]vbuterinJust some guy 0ポイント1ポイント  (0子コメント)

Not really. You can create a transaction with lots of inputs and lots of outputs. Each one is ~50 bytes (remember, the UTXOs can be OP_TRUE, so no need for a signature), so that gets you to ~20000 in a 1 MB block (~333 per second); ethereum's current attack lets you do ~130000 reads per 14 seconds (~920 per second) if you assume a 5.5m gas limit. Right now there's a deficiency in geth that means it's doing more reads than it needs to but that's solvable.

[–]Atyzze 1ポイント2ポイント  (2子コメント)

That's a severe overstatement. The network is handeling it just fine. And you have no idea who or how many are behind it.

[–]mmitech 2ポイント3ポイント  (1子コメント)

sounds like you want to say that people are holding the network with their hands.... but after all it seems that is exactly how this is working.

[–]CommodoreHodlor 0ポイント1ポイント  (0子コメント)

If only there weren't 400 lb hackers :-)

[–]FantomLancer 3ポイント4ポイント  (0子コメント)

Stay strong! You can do it. :)

[–]huntingisland 4ポイント5ポイント  (1子コメント)

I really think the network is going to have to move to a dynamic opcode pricing model and also add state antispam measures (like charging more gas for creating new accounts that add to state vs. sending to an already existing account).

Also, relying on cache is probably not going to work much longer.

[–]InstantDossier 3ポイント4ポイント  (0子コメント)

The awkward bit is that the most recent changes probably made actually deploying non malicious contracts an order of magnitude more expensive. You can only go so far with taxing attacking scripts before benevolent ones become uneconomical as well.

[–]mukuloo7 2ポイント3ポイント  (0子コメント)

so the 2nd hardfork won't fix it completely?

[–]0xf3e 0ポイント1ポイント  (1子コメント)

Can you also adjust the costs of all other opcodes which could be abused by an attacker to prevent further attacks? I don't think it's a good strategy to only adjust the opcodes that are being abused right now.

[–]vbuterinJust some guy 3ポイント4ポイント  (0子コメント)

That's what we've already been doing; we've looked carefully.

[–]truewavebreak 2ポイント3ポイント  (4子コメント)

Hope the pools are listening they hold a ton of the hash power :)

[–]Jargc 0ポイント1ポイント  (3子コメント)

Yes, I'm wondering how much of that hash power will move to another coin at the end of this month and if that will change mining difficulty or will it stay the same due to difficulty fixing in the code. I note that ETC is planning a HF to delay the difficulty fixing code.

[–]InstantDossier 2ポイント3ポイント  (0子コメント)

Miners have already shown it's a lot easier to just not put any transactions in blocks, the only person actually filling them with lots of hard to validate work is objectively attacking the network. To a miner the only transaction that matters is the one from their mining reward to their exchange.

[–]truewavebreak 1ポイント2ポイント  (1子コメント)

I would imagine we wont loose too much the pools holding the most power are often the most active when it comes to updates/price changes ect it's in their interest to change the price. Eth is still the most profitable to mine as far as I'm aware but I'm mining for future price not current :).

[–]Jargc 0ポイント1ポイント  (0子コメント)

Eth is still the most profitable to mine as far as I'm aware but I'm mining for future price not current :).

Yes, zcash futures price caught my attention, over USD130 and a number of Eth miners preparing to switch to it, guess we will have to wait and see what happens :)

[–]justjoe1987 2ポイント3ポイント  (3子コメント)

How much evidence is needed before saying that this is a direct attack from an individual or group with bitcoin interest? This laundry list of attacks that were premeditated have already cost Ethereum's lead developers valuable time that could have been spent on innovative projects. For many in this community, it is not a race... (i.e. lighting vs raiden) but it's obvious the btc community does not share that same sentiment.

EDIT: I'm not trying to start a war, I just think there are people that need to be held accountable.

[–]alsomahler 0ポイント1ポイント  (2子コメント)

It doesn't matter who is doing this. The important thing is that it is helping us figure out how to (or whether we can) make the Ethereum VM fully resistant against spam attacks. No need to hold anybody accountable, they already paid their ether in the transaction-cost. The network just sold it to them at the wrong price.

[–]justjoe1987 0ポイント1ポイント  (1子コメント)

Except, in many countries, this is illegal. You cant just DDOS Google and get away with it. I agree this is hardening the network, but Christ... Ethereum is only a year old... does it really need to be battle-hardened right now? :(

[–]TotesMessenger 0ポイント1ポイント  (0子コメント)

I'm a bot, bleep, bloop. Someone has linked to this thread from another place on reddit:

If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads. (Info / Contact)

[–]imar00 0ポイント1ポイント  (0子コメント)

Of course these attacks are good guys. They only make the network stronger. This is exactly the roadmap needed for a much more secure network. I'm happy to see attacks and hope to see more.