Permission Evaluation

in #permission4 years ago

Permission Evaluation

When an operation of type "Action" is passed from @alice to @bob, the EOS.IO software will first check whether @alice has defined permission mapping for @bob.groupa.subgroup.Action. If no results are found, then @bob.groupa.subgroup will be checked, then @bob.groupa, and finally @bob will be checked. If no further matches are found, the assumed mapping will be the named permission group @alice.active.

Once the mapping is identified, the multi-signature threshold and the permissions associated with the named permissions are used to verify the signature permissions. If it fails, then it will traverse the permissions of the parent class, and finally traverse the permissions of the owner, which is @alice.owner.

Default permission group

EOS.IO technology also allows all accounts to have an "owner" permission group that can complete all operations, and an "active" permission group can perform all operations except for changing all groups. All other permission groups are derived from the "active" group.

Concurrent evaluation permissions

The permission evaluation process is "read-only", and permission changes made to the transaction will not take effect until the end of the block. This means that all keys and permission evaluations for all transactions can be executed concurrently. In addition, this means that permissions can be verified quickly without the need to restart expensive application logic. Finally, this means that transaction permissions can be evaluated when pending transactions are received, without re-evaluation when applying them.

On the whole, authorization verification accounts for a large part of the calculation required to verify transactions. Making permission verification a read-only and concurrent process can significantly improve performance.

When replaying the blockchain to regenerate the deterministic state from the action log, there is no need to evaluate permissions again. Because the transaction is contained in a block that is known to be in good condition, it can skip this step. This greatly reduces the amount of calculation consumed when replaying the blockchain.