Onchain permissioning uses smart contracts to store and administer the node, account, and admin allowlists. Using onchain permissioning enables all nodes to read the allowlists from a single source, the blockchain.
When using onchain account permissioning, a node checks permissions when importing blocks. Meaning, a node only imports blocks in which all transactions are from authorized senders. If you disable onchain account permissioning and your node accepts blocks without enforcing this rule, your node cannot re-synchronize with other nodes that enforce onchain account permissioning rules (your node goes into forked state).
Custom smart contracts and dapps can be implemented to work with onchain permissioning.
Permissioning implements three allowlists:
- Accounts, which can submit transactions to the network.
- Nodes, which can join the network.
- Admins, which are accounts able to update the accounts and nodes allowlists.
If using account permissioning and privacy, a signing key must be specified using the
--privacy-marker-transaction-signing-key-file command line option and the corresponding public key included in the accounts allowlist.
If nodes are not connecting as expected, set the log level to
TRACE and search for messages containing
Node permissioning to identify the issue.
--p2p-host command line option has been correctly configured for all nodes with the externally accessible address.
If you change your network configuration, you may need to update the node allowlist.
When a node joins the network, the node connects to the bootnodes until it synchronizes to the chain head, regardless of node permissions. After synchronization, the Account Rules and Node Rules smart contracts apply the permissioning rules.
If a synchronized node loses all peer connections (that is, it has zero peers), it reconnects to the bootnodes to rediscover peers.
All bootnodes must be on the nodes allowlist.