Welcome back to the EOS 101. If you are wondering why I am welcoming you back, then you should take a look at this previous post…
EOS 101: Getting started with EOS, Part 1 - Hacker Noon_This post marks the first in a new EOS series I am starting in an effort to provide some easy to read instructions…_hackernoon.com
Now assuming you have read the above post, let’s get started where we left last time. In today’s post we are going to explore Accounts in EOS; it’s architecture and permission structure in simplest possible way.
Overview: a 10,000 ft perspective
Account architecture and permission structure
Let’s break down the above diagram a bit:
Wallets
Wallets are clients that store keys like we see in the above diagram. These keys may or may not be associated with the permissions of one or more accounts. For instance, each of the 3 keys above is associated with an account. key1 is associated with owner permission level whereas key2 and key3 are associated with active permission level of the account.Ideally, a wallet has a locked (encrypted) and unlocked (decrypted) state that is protected by a high entropy password. The EOS repository comes bundled with a command line interface client called cleos which gives you an interface with which you can interact with a lite-client called keosd(EOSIO wallet daemon that loads wallet related plugins).
Accounts
An account is a human-readable name that is stored on the blockchain. It can be owned by an individual or group of individuals depending on permissions configuration. In the above case, the account is owned by an individual(person holding key1). An account is required to transfer or otherwise push a transaction to the blockchain.
Every account in EOS can be referenced by a unique human readable name of up to 12 characters in length, given by the account creator.
Now, to understand the significance of permission structure we have to understand actions and handlers.
Actions and handlers
Each account can send structured Actions(for eg. sending some steem to another account on Steemit) to other accounts and may define scripts to handle Actions(for eg. getting notified on receiving steem) when they are received. The EOS.IO software gives each account its own private database which can only be accessed by its own action handlers. Action handling scripts can also send Actions to other accounts. The combination of Actions and automated action handlers is how EOS.IO defines smart contracts.
Authorities and Permissions
As we have seen above, there are many actions that can be performed. Also, multiple keys are associated with each account, for different actions. This can be a real mess to handle.
what does the EOS permission structure solve?
Fortunately, the permission structure is capable to handle this mess. Let’s see how.
Authorities determine whether or not any given action is properly authorized.
Every account has two native named permissions
ownerauthority symbolizes ownership of an account. There are only a few transactions that require this authority, but most notably, are actions that make any kind of change to the owner authority. Generally, it is suggested that owner is kept in cold storage and not shared with anyone.ownercan be used to recover another permission that may have been compromised.activeauthority is used for transferring funds, voting for producers and making other high-level account changes.
In addition to the native permissions, an account can possess custom named permissions that are available to further extend account management. Custom permissions are incredibly flexible and address numerous possible use cases when implemented. Much of this is up to the developer community in how they are employed, and what conventions if any, are adopted.
Permission for any given authority can be assigned to one or multiple public keys or a valid account name.
Now let’s put all the things together, that we learned and see them through some working examples.
Putting things together
We will go go through 2 different examples in order to see the how it actually works.
Default account config (Single-Sig)
This is how an account is configured after it has been created, it has a single key for both the owner and active permissions, both keys with a weight of 1 and permissions both with a threshold of 1. The default configuration requires a single signature to authorize a action for the native permissions.
@bob account
Single-Sig Account
In the @bob account example, this table shows that @bob's owner key has a permissioned weight of 1, and the required threshold to push a transaction under that authority is 1.
To push a transaction under the owner authority, only @bob needs to sign the transaction with his owner key for the transaction to be eligible for validation. This key would be stored in a wallet, and then processed using cleos.
Multi-sig Account & Custom Permissions
The below examples are authorities for a fictional account named @multisig. In this scenario, two users are authoritized to both the owner and active permissions of a fictional @multisigaccount, with three users permissioned to a custom publish permission with varying weight.
Multi-Sig Account
In this scenario, a weight threshold of 2 is required to make changes to the owner permission level, which means that because all parties have a weight of 1, all users are required to sign the transaction for it to be fully authorized.
To send a transaction which requires the active authority, the threshold is set to 1. This implies that only 1 signature is required authorize a action from the active authority of the account.
There’s also a third custom named permission called publish. For the sake of this example, the publish permission is used to publish posts to the @multisig’s blog using a theoretical blog dApp. The publish permission has a threshold of 2, @bob and @stacy both have a weight of 2, and a public key has a weight of 1. This implies that both @bob and @stacy can publish without an additional signature, whereas the public key requires an additional signature in order for a action under the public permission to be authorized.
Thus the above permissions table implies that @bob and @stacy, as owners of the account, have elevated priviledges similar to a moderator or editor. While this primitive example has limitations particularly with scalability and is not necessarily a good design, it does adequately demonstrate the flexible nature of the EOSIO permissions system.
Also, notice in the above table, permissions are set using both an account name and a key. At first glance this may seem trivial, however it does suggest some added dimensions of flexibility.
Observations
- @bob and @stacy can be explicitly identified as the owners of this account
- The public key cannot push a action under publish authority without an additional signature from @bob or @stacy
- @bob and @stacy can push a action under publish authority without any additional signatures.
Well, this is how EOS account architecture and permission structure works. I hope that it was useful for you. In the next article we will learn how to write smart contracts in EOS. So, stay tuned…
stay tuned!
Learned something? Click the 👏 to say “thanks!” and help others find this article.
Hold down the clap button if you liked the content! It helps me gain exposure .
Want to learn more? Checkout my previous articles.
Quorum 101: Getting started with Quorum_This post marks the first in a new Quorum series I am starting in an effort to provide some easy to read instructions…_medium.com
13 sidechain projects every blockchain developer should know about_The whole world is going through the blockchain revolution. But wait…is this really what we dreamed of? Present…_medium.com
Setting up your first distributed private storage network on IPFS: Part 1_IPFS Private Storage Network Series_medium.com
Clap 50 times and follow me on Twitter: @vasa_develop