SMT hard fork testing report #4 : Found an exploit, crashed the testnet

in #smt4 years ago (edited)

image.png

Hey !

This last week was mostly spent polishing my script to create as many smts as I could. And while I was doing that, I noticed that there was more and more timeouts in the testnet, until it completely crashed.

Success ! I found another chain breaking bug :D

Here's how the logs from @drakos 's testnet node looked like :

    database.cpp:2989 apply_block
3515352ms db_with.hpp:125               ~pending_transaction ] Postponed 59239 pending transactions. 393 were applied.
3515426ms witness_plugin.cpp:343        block_production_loo ] Generated block #1 with timestamp 1970-01-01T00:00:00 at time 2019-12-22T20:58:33

At some point the chain crashed so hard that his witness re-generated a first block haha

The exploit

So here's what happened : there are some automated actions on every block, and there's a limit of how many you can put on a single block. And since I was creating 10 smts per block with 10 emissions (which is an automated action). At some point the maximum of automated actions per block would be reached, and the chain would be in a weird state where it can't find the automated action it needs to proceed, since it is assuming that the automated action would have been executed but it didn't since the block was full.

An analogy would be as if you tried to make pasta, you take the pot, want to put water but postpone it, then, expecting water that isn't there (since you postponed it). You put it on the stove. Something is not going to go right

Anyways, this exploit took a few days of spamming the tesnet. This is an extreme case, nobody will create that many smts at that rate in the real world.

Basically by my calculations it took about 57 600 smts creation with emission to crash the testnet. Which would cost a ton for an attacker to exploit (smt have a cost of 1 sbd currently, but might very well be 10 or 100 sbd)

Real world threat

But this is where this attack can be done for much cheaper and much quicker, the problematic part is the emission, not the creation of smt. FYI, you cannot add an emission more than once per block per smt.

If it took me two days with 10 emission per block, it means that if I create 10 smts and emit 10 times per block, without creating more smts, the chain will crash all the same. But with a much lower cost.

But wait there is more ! What if I create 100 smts and then emit 100 times per block ? then the two days is now 5 hours. You get the idea.

And emission is just one of the automated actions, there are probably ways to do this even faster/cheaper.

Good thing we caught this one in the testing phase :)

As always you can see the code that I use for my test cases here : https://github.com/drov0/hf23-testing/

Please consider voting my proposal and steempress as witness

The reason I'm able to do this work and allocate time to it is thanks to the funds from the sps, but I am not too far from not getting funding again, please consider voting on it or unvoting the return proposal : https://steemproposals.com/proposal/50

And finally I am also doing this as part of the witness @steempress if you like what I'm doing please consider voting on it as well. Every bit counts ! It will take you but a few minutes but will greatly help me test the network and the more we test the more steemit and the witnesses will feel confident enough to launch on the main net

Sort:  

Is it your understanding that this is an easy fix for the Steemit team? Or do feel like this could take some time to sort out?

Mmh I don't think it should be too hard.

Now what happens next?

Not much, testnet will stay down for a bit until the steemit team fixes it, then they will put the testnet back up, I'll run my test script to see if I can break it again or not and if I can't (meaning it's fixed) we'll move onto other things.

.

On the whole blockchain you can only create 10 new smts per block. As for the other limits they are the usual limit, for instance you can only comment once every 3 seconds etc.

... please consider voting on it or unvoting the return proposal ...

Done and witness voted having had 3 open up with retirements. Nice work with the debugging!

Thanks !

NIce! One less post HF disaster :)

Wow. Great work

Posted using Partiko Android

Congratulations @howo!
Your post was mentioned in the Steem Hit Parade in the following category:

  • Pending payout - Ranked 3 with $ 57,2