eris:db Permissioning and Account Types

Introduction

eris:db is the most advanced permissionable blockchain client currently in the open source market.

The advanced nature of eris:db also brings a threshold level of complexity which must be handled in order to reap the benefits of the system.

This deck will cover typical account types, how these typical accounts work together to formulate a typical enterprise grade POC, and finally, advanced account types.

Four Typical Account Types For Enterprise POCWhile eris:db offers a very broad range of account types and permissions, a typical enterprise grade POC will include the following four account types:

1. Administrator accounts. Typically the head of innovation or equivalent, along with the head developer from the integrator. These accounts can do anything and everything on the chain, use with caution;

2. Developer accounts. Typically a range of developers will be given accounts which allow them to take most of the actions necessary to build out the smart contract application;

3. Validator accounts. Typically running within a data center or in the cloud, these accounts typically only have responsibility for validating and “moving the chain forward”; and

4. Participant accounts. Typically these would be other participants in the POC who only need limited permissions in order to interact with the application rather than to build it, such as sponsoring business unit.

N.B., instead of “nodes” we use the term “accounts” but the idea is roughly analogous

Four Typical Account Types For Enterprise POC

Account Type Who Usually Given? How Many Usually Given?

Administrator Accounts ● Client Lead Dev● Integrator Lead Dev● Eris Account Dev (if needed)

2-3

Developer Accounts ● Client Dev Team● Integrator Dev Team

5-7

Validator Accounts ● Data Center or Cloud Nodes 7 (tolerates 2 down nodes)to10 (tolerates 3 down nodes)

Participant Accounts ● Client biz unit● Client lab/innovation hub

15-20

What’s Needed to “Make A Chain”When anyone makes (or instantiates) an eris:db chain, what they need is to create a small table similar to the one on the previous slide which outlines the account types they need (note the previous two slides are typical examples rather than requirements) and the number of each account type.

Then whomever is instantiating the blockchain needs to either generate or gather public keys for each account. Eris always recommends that all users generate their own keys.

Finally, they will need to give the account types their proper permissioning and formulate an accounts.csv which has the public key, amount of tokens, and permission level of the account as well as a validators.csv which contains analogous information for the validators.

What’s Needed to “Make A Chain”Public Key Tokens Name Perms

What a typical accounts.csv looks like.

Typical Permissioning Specifics

Permission Administrator Developer Validator Participants

root Y N N N

send Y Y N Y

call Y Y N Y

create_contract Y Y N N

create_account Y Y/N N N

bond Y N Y N

name Y Y N Y

N.B., for more info please see Eris’ Documentation

Typical Permissioning Specifics

Permission Administrator Developer Validator Participants

has_base Y N N N

set_base Y N N N

unset_base Y N N N

set_global Y N N N

has_role Y Y N Y

add_role Y Y/N N N

rm_role Y Y/N N N

N.B., for more info please see Eris’ Documentation

Do We Have To Use the Typical Account Types?No.

eris:db permissioning uses capabilities based permissioning where all of the capabilities included in our permissions documentation can either be turned ON or OFF for any given account. This allows very fine grained control over accounts and what they are able to do within the network.

Yet, it, admittedly, also adds a bit of complexity into the system. We use the Four Typical Account Types as a way to reduce the complexity for a typical POC. However, we have built in flexibility to deal with many more account types.