You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 2, 2022. It is now read-only.
A subjective means for each node to be configured to reject speculatively executing transactions based on a whitelist or blacklist. This feature would not impact whether a node accepts a block signed by a producer.
Motivation
Nodes may want the ability to blacklist or whitelist certain contracts from executing on their node under the context of producing a block (either speculatively or as the real block producer that will then sign the block).
Such an ability, particularly whitelisting, will be quite handy early on in the first bootstrapping process of an EOSIO blockchain to provide confidence that the core functionality of the chain (system contract, token contract, multisig contract, and native actions) are all working together properly prior to opening up the chain arbitrary user-submitted contract which greatly increase the attack surface.
Even well after launch, the ability for producers to coordinate in blacklisting a buggy contract causing issues or malicious actors exploiting newly found bugs in the system (and to be able to quickly adapt the blacklists without a recompilation or replay required) can prove very useful as a temporary "soft forking" fix until a proper fix is implemented later (perhaps as a hard forking fix or maybe just by upgrading a WASM contract to a version that fixes the bug).
Description
A whitelist or blacklist can be provided just like other nodeos options (in config.ini or via command line arguments) for contracts and actors (i.e. the authorizing accounts of a transaction). In the future, an API can be provided to dynamically query and modify the whitelists and blacklists without requiring a restart of nodeos; but this will not be supported by 1.0.
A whitelist takes precedence over a blacklist. This means that if a single entry exists in a whitelist, the corresponding blacklist (if even specified) is ignored. If there are no entries in a whitelist, then the corresponding blacklist is enforced (it is allowed to also be empty of course).
Contract whitelist/blacklist
A contract whitelist/blacklist determines whether an action (whether user-specified or contract generated) will be delivered to code of an account. The contract whitelist/blacklist does not take effect if the receiver does not have any code set.
If there exists a single entry in the contract whitelist, nodeos will check to see if the receiver of the action is in the whitelist. If not, the transaction causing that action dispatch will be rejected by the local node.
If the contract whitelist is empty, nodeos will check to see if the receiver of the action is in the blacklist. If so, the transaction causing that action dispatch will be rejected by the local node.
The whitelist/blacklist enforcement does not need to apply for generating a transaction or including a delayed transaction in the blockchain (though it could). However, it should be enforced when a deferred transaction is considered for retirement.
Actor whitelist/blacklist
An actor whitelist/blacklist determines whether an input transaction (whether delayed or not) should be included into the blockchain. It does need to apply to retiring deferred transactions.
If there exists a single entry in the actor whitelist, nodeos will check to see if all of the actors authorizing an input transaction are in the whitelist. If not, that input transaction is rejected by the local node.
If the actor whitelist is empty, nodeos will check to see if any of the actors authorizing an input transaction in the blacklist. If so, that input transaction will be rejected by the local node.
The text was updated successfully, but these errors were encountered:
Summary
A subjective means for each node to be configured to reject speculatively executing transactions based on a whitelist or blacklist. This feature would not impact whether a node accepts a block signed by a producer.
Motivation
Nodes may want the ability to blacklist or whitelist certain contracts from executing on their node under the context of producing a block (either speculatively or as the real block producer that will then sign the block).
Such an ability, particularly whitelisting, will be quite handy early on in the first bootstrapping process of an EOSIO blockchain to provide confidence that the core functionality of the chain (system contract, token contract, multisig contract, and native actions) are all working together properly prior to opening up the chain arbitrary user-submitted contract which greatly increase the attack surface.
Even well after launch, the ability for producers to coordinate in blacklisting a buggy contract causing issues or malicious actors exploiting newly found bugs in the system (and to be able to quickly adapt the blacklists without a recompilation or replay required) can prove very useful as a temporary "soft forking" fix until a proper fix is implemented later (perhaps as a hard forking fix or maybe just by upgrading a WASM contract to a version that fixes the bug).
Description
A whitelist or blacklist can be provided just like other nodeos options (in config.ini or via command line arguments) for contracts and actors (i.e. the authorizing accounts of a transaction). In the future, an API can be provided to dynamically query and modify the whitelists and blacklists without requiring a restart of nodeos; but this will not be supported by 1.0.
A whitelist takes precedence over a blacklist. This means that if a single entry exists in a whitelist, the corresponding blacklist (if even specified) is ignored. If there are no entries in a whitelist, then the corresponding blacklist is enforced (it is allowed to also be empty of course).
Contract whitelist/blacklist
A contract whitelist/blacklist determines whether an action (whether user-specified or contract generated) will be delivered to code of an account. The contract whitelist/blacklist does not take effect if the receiver does not have any code set.
If there exists a single entry in the contract whitelist, nodeos will check to see if the receiver of the action is in the whitelist. If not, the transaction causing that action dispatch will be rejected by the local node.
If the contract whitelist is empty, nodeos will check to see if the receiver of the action is in the blacklist. If so, the transaction causing that action dispatch will be rejected by the local node.
The whitelist/blacklist enforcement does not need to apply for generating a transaction or including a delayed transaction in the blockchain (though it could). However, it should be enforced when a deferred transaction is considered for retirement.
Actor whitelist/blacklist
An actor whitelist/blacklist determines whether an input transaction (whether delayed or not) should be included into the blockchain. It does need to apply to retiring deferred transactions.
If there exists a single entry in the actor whitelist, nodeos will check to see if all of the actors authorizing an input transaction are in the whitelist. If not, that input transaction is rejected by the local node.
If the actor whitelist is empty, nodeos will check to see if any of the actors authorizing an input transaction in the blacklist. If so, that input transaction will be rejected by the local node.
The text was updated successfully, but these errors were encountered: