What limits does an API endpoint impose on transactions which fail due to assertions?

Question

Scenario: I connect to an API endpoint and repeatedly send transactions (with cleos) which are all ultimately rejected with eosio_assert_message. Such transactions don't seem to eat up CPU or network resources of my account. Still, the API endpoint has to actually execute the code to get to the assertion, so it consumes at least the CPU of the endpoint.

In practice, after a few such API calls, I'm getting the "overdrawn balance" response, as if my CPU or network resource was spent. But it persists only for a few seconds. And no spendings are reflected on my account details.

So, what is the mechanism for the API endpoint to limit the transactions which actually don't make it because of failed assertions?

Answer 1

According to the responses in this GitHub issue, the mechanisms that are meant to mitigate this issue are as follows:

• There's a maximum cpu time(30ms) for every transaction.
• If a transaction failed, it will not be broadcast to other nodes, which means that hackers can only exhausts one see node rather than the whole network.
• greylist feature further prevents from hackers stealing elastic CPU/NET resources.

To read more about greylisting, see this GitHub issue for a technical explanation or this article for a less technical explanation. Briefly, accounts that are subjectively considered to spam the network are restricted from using the unused bandwidth that accounts are entitled to otherwise.

Overall, it seems that there is no protocol-level defense that stops an attacker from incessantly broadcasting 30ms failing transactions to BPs at no costs (beside electricity) to waste BP resources.