RC have an internal market that dinamically updates the "price" of each transaction type based on three metrics:
- Transaction size.
- State
- Replay time
Attacking the network with custom json operations will increase the price of them and limit the attack. That would suck for everyone else.
The witnesses can also decline transactions coming from specific accounts with another softfork so an attack would not last for a long time...maybe.
Posted Using LeoFinance
Yeah that's my concern, because if you start blocking accounts with softforks just because they are posting data to the blockchain, then the blockchain is 100% broken. Witnesses don't get to decide which operations have value and which ones don't. You pay the network cost to transact, you get to post the operation. End of story.
What if I start posting books to the blockchain or code from GitHub? Does a witness get to come along and tell me: "no! that doesn't have value!" ??? If they do it shows the entire system is broken.
I agree, it's still possible if the top 20 agree on doing it. It then would be up to stakeholders to remove them from consensus. It's more likely to happen on steem though. I am wondering how long would it take for the internal RC market to adjust to the increased demand.
Technically the blockchain would not stop with "spam" operations it would just be more expensive to transact and witness nodes would have an increased cost over time and replay time will get bigger with blocks filled to the max.
I think that right now it's cheaper to transact on steem because the effective SP being used is about half that of hive (less transactions = lower RC cost) so it's easier to "spam" it.
Posted Using LeoFinance
Tbh there's a much easier way than soft forks. Node operators (RPC nodes), which are the true gateway between the interfaces and the blocks, can easily implement a filter to block accounts which cause heavy load (higher than average cost, spammers, attackers).
That type of "blacklist" can be maintained without need for a softfork. And even be implemented by multiple node operators as well.
You can still broadcast a transaction with a different node or maintain your own..easier said than done.
It is a weakness, as shown multiple times by EOS, yes. But it does require advanced understanding already.
Soft forks don't scale tho and there is the theoretical possibility that you hit two successive backup witnesses (in two different queue rounds) who don't run the soft fork and make the tx immutable. Luckily the chance for that to happen is very minimal.