Accounts and Permissions in EOSIO

EOS Account Permissions

What makes EOS different from other blockchains is the accounting system it possesses. EOS holds A 12 character name account. Whenever an end-user needs to transact funds, he is required to sign a transaction for the account. 

The user is equipped with one or more keys within the chain, which are adaptable to changes. One can alter the keys,  setting varied permission management system to the account.

EOS Account

An EOS account acts as a human-readable identifier on the blockchain with fixed 12 characters encompassing format (a-z) and (1-5). Unlike other blockchains, EOS account names are unique and others identify them via this name. The most fascinating feature that EOS offer to its clientele is the creation of different accounts from a single pair of keys. And these accounts can be owned by an individual or group of individuals depending on the configured permission settings. Every EOS account has two native named permissions (owner and active).

EOS Permissions

EOS permissions are mainly Owner and Active and these are the standard permissions that every account possesses. While creating an account both permissions will be set up default with a set of key pairs (private and public). 

It is even possible for an account to set different keys for its owner and active.

For an EOS account, the owner permission acts as the  "root access" to enter it...If someone has the private key for owner permission, they are prone to do anything with your EOS account. Whereas the active permission acts much more safeguarding your EOS account.

In an EOS account permission, the owner permission set the permission for adding new owner and changing the existing authorities within the account. Also adding the new keys to the authorities are within the pursuit of owner permission. Active permission is mainly into pushing the transactions.

Apart from this anyone can make custom permissions in EOS making it more flexible to use. The owner and active permissions are standard permissions that every account has. 

In addition to the native permissions, an account can even have custom permissions. It is normally done for further extension of account management. Usually, these are done with contract accounts that are deployed with some dapp contracts. Permission for any given authority can be assigned to one or multiple public keys or a valid account name. That is an authority can have multiple keys or accounts as its permission level.

Default Account Configuration 

When an account is created it has a single key for both the owner and active permissions,  both will be having a weight 1 and also a threshold of 1. This configuration is the default configuration while creating an account and it requires only a single signature to authorize an action. The given below is an example of a default configuration.

This table shows that the two permission levels of the account that are active and the owner has different keys with a weight of 1.  

The user needs to sign the transaction with the corresponding private key in order to push it under the owner or the active authority. The transaction will only be valid if the pushed authority or account has a weight that is not lower than the threshold.

Multi-sig Account 

Now let us see the case where there are multiple keys and accounts in the authority.

The below scenario, two users are authorized to both the owner and active permissions of an account. Here the owner has two accounts in its permission level one, is an account acc1 and other is a public key, where active has two different accounts in its permission level.

In this case, a weight threshold of 2 is required to make changes to the owner permission level. This is since that only two parties available with weight 1, all are required to sign the transaction for it to be fully authorized.

To send a transaction which requires active authority which is of threshold 1, only 1 signature is required. since all the available signatures have a weight of 1.

It is to be noted that the permission level to this authorities is not restricted to two or three accounts or keys, it may vary according to the user's intention for the safety of the account

Setting Permission

Below is the code to set the permission of account, where the activation key of the account is updated. This transaction is pushed by the owner of accounts 

./cleos.sh set account permission accountA active '{"threshold": 2,"keys": [{"key": "EOS4zz1xrs715WjjHA2cdBaWpJAkixcFTEnXK9wVpR3fHbrF5kVjw","weight": 1}],"accounts":[{"permission":{"actor":"accountB","permission":"active"},"weight":1},{"permission":{"actor":"accountC","permission":"active"},"weight":1}]}' owner -p accountA

It is to be noted that the number of accounts and keys in the permission level has no restrictions yet.

After the above transaction, the active list of account A will be like below, 

This shows that the activation key of the accounts account B and account C has the authority to push a transaction of account A and it will be considered as a valid transaction if it achieves the required threshold value.

Permission @ eosio.code

When it comes to development and smart contract creation, setting permission level and accessing them makes some sense.

For example, in order to call an inline action, that is to call an action of contract A from contract B, there is a need to set some special permission. In this case, the Ram payer for the action in contract B must-have “accountname A@eosio.code” permission in its active. In a case, if account C needs to call an action in account A through a contract in account B, then account C need to set the accountB@eosio.code in its active.

./cleos.sh set account permission accountC active '{"threshold": 2,"keys": [{"key": "EOS4zz1xrs715WjjHA2cdBaWpJAkixcFTEnXK9wVpR3fHbrF5kVjw","weight": 1}],"accounts":[{"permission":{"actor":"accountB","permission":"eosio.code"},"weight":1}]}' owner -p accountC.