EOS 101: Getting started with EOS, Part 2

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… _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 EOS 101: Getting started with EOS, Part 1 - Hacker Noon 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. is associated with owner permission level whereas and 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). key1 key2 key3 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 ). An account is required to transfer or otherwise push a transaction to the blockchain. key1 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 ) to other accounts and may define scripts to handle Actions(for eg. getting notified on receiving ) 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. Steemit steem 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 named permissions native authority 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. can be used to recover another permission that may have been compromised. owner owner authority is used for transferring funds, voting for producers and making other high-level account changes. active In addition to the 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. native Permission for any given authority can be assigned to one or multiple or a valid . public keys 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 and permissions, both keys with a and permissions both with a . The default configuration requires a single signature to authorize a action for the native permissions. owner active weight of 1 threshold of 1 @bob account Single-Sig Account In the 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. @bob 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 , and then processed using . wallet cleos Multi-sig Account & Custom Permissions The below examples are authorities for a fictional account named . In this scenario, two users are authoritized to both the and permissions of a fictional account, with three users permissioned to a custom permission with varying weight. @multisig owner active @multisig publish Multi-Sig Account In this scenario, a weight threshold of 2 is required to make changes to the 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. owner To send a transaction which requires the authority, the threshold is set to 1. This implies that only 1 signature is required authorize a action from the authority of the account. active active There’s also a third called . For the sake of this example, the permission is used to publish posts to the @multisig’s blog using a theoretical blog dApp. The permission has a threshold of 2, @bob and @stacy both have a weight of , 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. custom named permission publish publish publish 2 Thus the above permissions table implies that @bob and @stacy, as owners of the account, have 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. elevated priviledges 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. _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 Quorum 101: Getting started with Quorum _The whole world is going through the blockchain revolution. But wait…is this really what we dreamed of? Present…_medium.com 13 sidechain projects every blockchain developer should know about _IPFS Private Storage Network Series_medium.com Setting up your first distributed private storage network on IPFS: Part 1 Clap 50 times and follow me on Twitter: @ vasa_develop