Privacy and Permissioning
This domain tests two access-control layers: private transactions and network/account permissioning. Verify the Besu version under test, because privacy support has been deprecated and removed from recent releases.
Core rules
- Private transactions rely on a separate private transaction manager such as Tessera. Besu connects with
--privacy-enabled,--privacy-urland--privacy-public-key-file. - A private transaction names
privateFromand eitherprivateForrecipients or a privacy group ID. Only participants receive the payload; others see a hash. priv_distributeRawTransactiondistributes the payload to the enclave and returns an enclave key, which can be submitted separately from the signed transaction.- Node permissioning controls which nodes may peer. Account permissioning controls which addresses may submit transactions.
- Local permissioning uses files enabled with
--permissions-nodes-config-file-enabledor--permissions-accounts-config-file-enabled. Files list one entry per line; blank lines and#comments are ignored. - Onchain permissioning uses contracts enabled with
--permissions-nodes-contract-enabledand--permissions-accounts-contract-enabled, administered throughperm_*methods by an admin account.
Worked example
You must restrict a consortium to three organisations. Put each node ID in nodes-allowlist and each business account in accounts-allowlist, start every node with both file-based flags pointing at the same files, and add a test account that is absent from the list. Its transaction is rejected while reads still succeed, confirming that account permissioning filters transaction senders, not queries.
Traps
- Enabling permissioning on only some nodes, which partitions the network.
- Forgetting that onchain permissioning needs the contract address and an admin account.
- Expecting account permissioning to block RPC reads.
- Designing new projects around privacy without checking whether your Besu version still ships it.