EOS whitepaper walk-through: Token model and resource usage.

bluabaleno (55)in #eos • 6 years ago

Read the Whitepaper here

Last time we took a deeper dive into deferred transactions and context-free actions and how they can lighten the computational load.

In this article we'll go over the utility aspect of the EOS token.

All blockchains are resource constrained and require a system to prevent abuse. With a blockchain that uses EOS.IO software, there are three broad classes of resources that are consumed by applications:

Bandwidth and Log Storage (Disk);
Computation and Computational Backlog (CPU); and
State Storage (RAM).

Bandwidth and computation have two components, instantaneous usage and long-term usage. A blockchain maintains a log of all Actions and this log is ultimately stored and downloaded by all full nodes. With the log of Actions, it is possible to reconstruct the state of all applications.

Bandwidth refers to the available transaction capacity of the blockchain. This is commonly measured in transaction per second.

Following the convention, Bitcoin's bandwidth is 3 transactions per second, while Ethereum's bandwidth is 15 transactions per second. This use of bandwidth terminology reflects better the demands on the storage capacity and computational capacity that each transaction 'consumes' per second.

That's the per second capacity of the blockchain. However, these transaction still has to be recorded in order for anyone who joins the network later to replay the transactions to arrive at the current state of the blockchain.

Transactions take time to process, this is because computers must perform calculation to verify transactions and apply them. This computational resource is also limited and not all transactions are processed at the time they are received. This creates a backlog of computation that needs to be done.

The computational debt is calculations that must be performed to regenerate state from the Action log. If the computational debt grows too large then, it becomes necessary to take snapshots of the blockchain's state and discard the blockchain's history. If computational debt grows too quickly then it may take 6 months to replay 1 year worth of transactions. It is critical, therefore, that the computational debt be carefully managed.

Taking a snapshot of a blockchain state is akin to saving points in a video game. They provide a state of events that can be the new reference point from which action before can be safely ignored.

Only actions after the snapshot needs to be taken into consideration when replaying from the snapshot to arrive at the current state. This will drastically reduce the computational load required for someone who is setting up a new node.

If computational debt is not managed carefully, there might be a point where new computation is added faster than it can be replayed, creating a situation where no new nodes can be started.

Blockchain state storage is information that is accessible from application logic. It includes information such as order books and account balances. If the state is never read by the application, then it should not be stored. For example, blog post content and comments are not read by application logic, so they should not be stored in the blockchain's state. Meanwhile the existence of a post/comment, the number of votes, and other properties do get stored as part of the blockchain's state.

Applications usually do not depend on the content of some event, but rather the occurrence of said event. An blogging platform's logic does not depend on what is written in the blog post, only that a new blog post has been published.

What the blogging platform logic requires is the information about the blog post: the author, time, tags, etc. With this information it is possible to generate the current state of the application, though without the content.

Block producers publish their available capacity for bandwidth, computation, and state. The EOS.IO software allows each account to consume a percentage of the available capacity proportional to the amount of tokens held in a 3-day staking contract. For example, if a blockchain based on the EOS.IO software is launched and if an account holds 1% of the total tokens distributable pursuant to that blockchain, then that account has the potential to utilize 1% of the state storage capacity.

Relatively straight forward. If you own 1% of the EOS tokens then you have access to 1% of the resources of the network bandwidth, computation, and state capacity provided you have staked the token in a contract that prohibits you to remove it for 3 days.

Each Block Producer is responsible for publishing the statistics of capabilities of their equipment. An average is taken and that becomes the network's capacity.

Adopting the EOS.IO software on a launched blockchain means bandwidth and computational capacity are allocated on a fractional reserve basis because they are transient (unused capacity cannot be saved for future use). The algorithm used by EOS.IO software is similar to the algorithm used by Steem to rate-limit bandwidth usage.

A fractional reserve means that during times of low traffic, users can use bandwidth exceed their percentage of bandwidth. But unused capacity cannot be saved and used in the future, so it might be a good idea to delegate, or rent out your network bandwidth if you are not using it. Since it most likely will be used anyways, just you will not get compensated for it.

Useful links:

https://steemit.com/eos/@eosio/storage-costs-on-blockchains-using-eos-io-software

~~------------------------------------------------------------------------------------------------------------------~~

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