EOS whitepaper walk-through: Account & Role Based Permission Management.

                                                        

Read the Whitepaper here 

Last time we finished going over the abstract, note and disclaimer, and took a brief overview of the EOS whitepaper.

And we went over the two of the ten parts, Background, and Requirement.

Then we went over the Consensus Algorithm in three parts. Part One, Part Two, Part Three.

Role Based Permission Management

Permission management involves determining whether or not an Action is properly authorized. The simplest form of permission management is checking that a transaction has the required signatures, but this implies that required signatures are already known. Generally, authority is bound to individuals or groups of individuals and is often compartmentalized. The EOS.IO software provides a declarative permission management system that gives accounts fine grained and high-level control over who can do what and when.

EOS account have a built-in smart-contract that allows one or more party to control the account or the specific actions that can be performed by the account.

This is like multi-sign addresses of Bitcoin or Ethereum, only with a lot more flexibility.

Because Account can have any number of Actions that can perform any number of things; from updating a record to sending a transaction to adding or removing an account from different permission levels. 

These action constitutes the basic operations of a company. 

It is critical that authentication and permission management be standardized and separated from the business logic of the application. This enables tools to be developed to manage permissions in a general-purpose manner and also provide significant opportunities for performance optimization.

Steemconnect, a project that allows Steem users to connect to different applications, is an example of what is being described here.

Each application on the Steem blockchain has a shared business logic, namely that of posting, upvoting, delegation and transfers. But each application's access to user's account is restricted to the permission level the user set for the account.

some application ask for delegation powers of the users, i.e Steembottracker, other ask for only posting permission, i.e Busy.org.

A standardize permission and authentication system allows businesses to comply to industry standards that protect the user account from unsavory actors who wish, through tailor-made actions, comprise user accounts.

This allows businesses to share contract code thus making business development much more efficient. 

On the software side, this separation means different scopes in contract data, thus allowing for these evaluation to happen in parallel. 

Every account may be controlled by any weighted combination of other accounts and private keys. This creates a hierarchical authority structure that reflects how permissions are organized in reality and makes multi-user control over accounts easier than ever. Multi-user control is the single biggest contributor to security, and, when used properly, it can greatly reduce the risk of theft due to hacking.

Unlike multi-sig wallets, EOS accounts permission level are dynamic. 

Where as multi-sig wallets operate on a simple x out-of y signature model, EOS accounts operate base on the weight of the signature. 

A wallet can be constructed such that Alice, Bob, and Charles are the Owner, Trustee, and Lawyer of the account. Alice, as the Owner, can send transaction with only her signature, or Bob the Trustee and Charles the Lawyer can send a transaction with both of their signatures without Alice.

This could not be done with a 2 out-of 3 multi sig as Alice would still need either Bob or Charles' signature before sending her own funds.

We'll go into detail how this is done in the next article.

EOS.IO software allows accounts to define what combination of keys and/or accounts can send a particular Action type to another account. For example, it is possible to have one key for a user's social media account and another for access to the exchange. It is even possible to give other accounts permission to act on behalf of a user's account without assigning them keys.

Since the account can specified different action-handlers, these handlers can be registered with different account names that allows them to perform action. This allows for accounts to act on behalf of other accounts without assigning them keys. 

------------------------------------------------------------------------------------------------------------------

If you would like to know more about me and what I'm doing you can read my introduction post here.

Read my series on the Steem blockchain:

Steem: Welcome to the Matrix. Part One

Steem: Operating in the Matrix. Part Two

Steem: Construction of the Matrix. Part Three

Read my series on the EOS blockchain:

EOS whitepaper walk-through. Abstract

EOS whitepaper walk-through. Note and Disclaimer

EOS whitepaper walk-through. Overview

EOS whitepaper walk-through. Background

EOS whitepaper walk-through. Requirement.

EOS whitepaper walk-through. Consensus Algorithm. Part One, Part Two, Part Three.

And you can contact me in the following way:

Twitter

@bluabaleno on Steem.chat

[email protected]