access to extended CPU/Net virtual resources should be subjective

[wanderingbort]

Problem

As currently designed, when the chains ephemeral resources are below a consensus managed threshold, the resource system will "relax" and overcommit the actual hard resource limit creating a virtual resource pool much larger. This allows accounts with relatively small amounts of stake to still use an idle chain even if they would be heavily throttled if it was purely stake-weighted.

However, this also means that a malicious actor can impose a higher load on an idle network than their stake should allow. Congestion mechanics will prevent this from being a sustainable situation but, accounts which repeatedly abuse this feature should lose access to it.

Proposal

Allow producers to subjectively deny access to the virtual pool of resource and instead impose a strict interpretation of stake-weighted resource allotment. Note, this would not prevent an account from transacting on chain nor would it impede the burst mechanics built into the system. It would only deny access to the additional resources that result from an idle chain in a "relaxed" state.

• Allow a mode of transaction processing where the resource calculations are done with hard chain maximums for CPU and Net and not the virtual maximums
  • failure in this mode should not be considered "objective" so, it should not result in any slashing conditions being imposed
  • failure in this mode should not be considered as a failure which invokes the error handler or hard_fail mechanics of scheduled and implied transactions
  • failure in this mode should return an immediate error to the user if their RPC node rejects a transaction on the basis of it being over the hard limit.
  • failure in this mode should be considered normal failure if the chain's virtual limit === the real limit (aka the chain is in a fully congested state)
• Allow specification in config.ini and CLI of "greylisted" accounts, where greylisting indicates that the account is denied access to the extended virtual pool of resources

[taokayan]

Hi, would you review my pull request #4410?

[taokayan]

brief of changes:

Greylisted accounts are not allowed to access extended(elastic) cpu/net limit in a subjective way.

When a block is being produced, if a transaction violates the cpu/net subjective limit, it will be rejected by the node immediately and immediate error will be returned. This includes normal transactions and deferred transactions.

block replay & apply_block will always use the objective cpu/net limit for validation. In this case the greylist will not have any effect.

related commands:

cloes get account will return the subjective cpu/net limit.

to start nodeos with greylist parameters:

./programs/nodeos/nodeos --data-dir=/Users/jiaendu/workspaces/eos/build/data-dir --config-dir=/Users/jiaendu/workspaces/eos/build/data-dir --greylist-account "a11111111111"

add greylist accounts in real-time:

curl --data-binary '{"accounts":["aaa","bbb"]}' http://localhost:8888/v1/producer/add_greylist_accounts

get current grey listed accounts:

curl --data-binary '' http://localhost:8888/v1/producer/get_greylist
{"accounts":["a11111111111","aaa","bbb"]}

remove greylist accounts:

curl --data-binary '{"accounts":["aaa","bbb"]}' http://localhost:8888/v1/producer/remove_greylist_accounts

[winlin]

if we depend on the greylist configure in the config file, it will be an delayed response. I suggest the resource limit will be done automatically.

[heifner]

Resolved by #4410