structured-concept: Eos--blockchain-network (Eos-net)
{2018-06-14}

McsHitp-creation: {2018-02-18}

overview of Eos-net

description::
Eos-network is a-blockchain-network that uses a-Delegated-Proof-of-Stake consensus-algorithm designed to enable vertical and horizontal scaling of decentralized-applications.
[hmnSgm.2018-12-13]
===
Current technologies for blockchain fall short of providing what developers and end-users need in order to contract together and to build large scale businesses.
We propose EOS, a performance-based and self-governing blockchain that provides an operating system for building large-scale consumer facing distributed applications.
[http://iang.org/papers/EOS_An_Introduction.pdf]
===
EOS is a consensus blockchain operating system that provides databases, account permissions, scheduling, authentication, and internet-application communication to massively improve the efficiency of smart business development that uses parallelization to make possible blockchain scalability to millions of users and millions of transactions per second.
[https://steemit.com/eos/@trogdor/introduction-to-eos-the-epic-blockchain-operating-system]

name::
* Mcs.filMcsDtcbnetEos.last.html,
* Mcs.dirTchInf/filMcsDtcbnetEos.last.html,
* Mcs.Eos-network,
* Mcs.Eos-network-(Eos-net),
* Mcs.Eos-net,
* Mcs.Eos-net-(Eos-network),
* Mcs.Đ-Eos,

protocol of Eos-net

name::
* Mcs.Eos-net'protocol,
* Mcs.Eos-protocol,

generic-chain::
* blockchain-protocol,

white-paper of Eos-protocol

name::
* Mcs.Eos-net'protocol'white-paper,
* Mcs.Eos-net'white-paper,
* Mcs.Eos-white-paper,

generic-chain::
* blockchain-net'white-paper,

specific::
* last: https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md,
* v2: {2018-03-16}: https://github.com/EOSIO/Documentation/blob/c36ffeb47863b925b7f24d02cdd959a15f2301df/TechnicalWhitePaper.md,
* v1: {2017-06-26}: https://github.com/EOSIO/Documentation/blob/6982de21cea2e2c16d751fa869708351587746c2/TechnicalWhitePaper.md,
* DRAFT: {2017-06-05}: https://github.com/EOSIO/Documentation/blob/f715ee9066e67453c20af719954ee09b060e5be2/TechnicalWhitePaper.md,

white-paper-v2.2018-03-16 of Eos-protocol

name::
* Mcs.Eon-net'white-paper-v2.2018-03-16,

addressWpg::
* https://github.com/EOSIO/Documentation/blob/a95c3236b8fd94c8546954ce63367df29de33a02/TechnicalWhitePaper.md,

EOS.IO Technical White Paper v2

March 16, 2018

Abstract:
The EOS.IO software introduces a new blockchain architecture designed to enable vertical and horizontal scaling of decentralized applications.
This is achieved by creating an operating system-like construct upon which applications can be built.
The software provides accounts, authentication, databases, asynchronous communication, and the scheduling of applications across many of CPU cores or clusters.
The resulting technology is a blockchain architecture that may ultimately scale to millions of transactions per second, eliminates user fees, and allows for quick and easy deployment and maintenance of decentralized applications, in the context of a governed blockchain.

PLEASE NOTE:
CRYPTOGRAPHIC TOKENS REFERRED TO IN THIS WHITE PAPER REFER TO CRYPTOGRAPHIC TOKENS ON A LAUNCHED BLOCKCHAIN THAT ADOPTS THE EOS.IO SOFTWARE.
THEY DO NOT REFER TO THE ERC-20 COMPATIBLE TOKENS BEING DISTRIBUTED ON THE ETHEREUM BLOCKCHAIN IN CONNECTION WITH THE EOS TOKEN DISTRIBUTION.

Copyright © 2018 block.one

Without permission, anyone may use, reproduce or distribute any material in this white paper for non-commercial and educational use (i.e., other than for a fee or for commercial purposes) provided that the original source and the applicable copyright notice are cited.

DISCLAIMER:
This EOS.IO Technical White Paper v2 is for information purposes only.
block.one does not guarantee the accuracy of or the conclusions reached in this white paper, and this white paper is provided “as is”.
block.one does not make and expressly disclaims all representations and warranties, express, implied, statutory or otherwise, whatsoever, including, but not limited to:
(i) warranties of merchantability, fitness for a particular purpose, suitability, usage, title or noninfringement;
(ii) that the contents of this white paper are free from error; and
(iii) that such contents will not infringe third-party rights.
block.one and its affiliates shall have no liability for damages of any kind arising out of the use, reference to, or reliance on this white paper or any of the content contained herein, even if advised of the possibility of such damages.
In no event will block.one or its affiliates be liable to any person or entity for any damages, losses, liabilities, costs or expenses of any kind, whether direct or indirect, consequential, compensatory, incidental, actual, exemplary, punitive or special for the use of, reference to, or reliance on this white paper or any of the content contained herein, including, without limitation, any loss of business, revenues, profits, data, use, goodwill or other intangible losses.

1.Background

Blockchain technology was introduced in 2008 with the launch of the Bitcoin currency, and since then entrepreneurs and developers have attempted to generalize the technology to support a wider range of applications on a single blockchain platform.

While a number of blockchain platforms have struggled to support functional decentralized applications, application specific blockchains such as the BitShares decentralized exchange (2014) and Steem social media platform (2016) have become heavily used blockchains with tens of thousands of daily active users.
They have achieved this by increasing performance to thousands of transactions per second, reducing latency to 1.5 seconds, eliminating per-transaction fees, and providing a user experience similar to those currently provided by existing centralized services.

Existing blockchain platforms are burdened by large fees and limited computational capacity that prevent widespread blockchain adoption.

2.Requirements for Blockchain Applications

In order to gain widespread use, applications on the blockchain require a platform that is flexible enough to meet the following requirements:

Support Millions of Users

Competing with businesses such as eBay, Uber, AirBnB, and Facebook, require blockchain technology capable of handling tens of millions of active daily users.
In certain cases, an application may not work unless a critical mass of users is reached and therefore a platform that can handle very large numbers of users is paramount.

Free Usage

Application developers need the flexibility to offer users free services; users should not have to pay in order to use the platform or benefit from its services.
A blockchain platform that is free to use for users will likely gain more widespread adoption.
Developers and businesses can then create effective monetization strategies.

Easy Upgrades and Bug Recovery

Businesses building blockchain based applications need the flexibility to enhance their applications with new features.
The platform must support software and smart contract upgrades.

All non-trivial software is subject to bugs, even with the most rigorous of formal verification.
The platform must be robust enough to fix bugs when they inevitably occur.

Low Latency

A good user experience demands reliable feedback with a delay of no more than a few seconds.
Longer delays frustrate users and make applications built on a blockchain less competitive with existing non-blockchain alternatives.
The platform should support low latency of transactions.

Sequential Performance

There are some applications that just cannot be implemented with parallel algorithms due to sequentially dependent steps.
Applications such as exchanges need enough sequential performance to handle high volumes.
Therefore, the platform should support fast sequential performance.

Parallel Performance

Large scale applications need to divide the workload across multiple CPUs and computers.

3.Consensus Algorithm (BFT-DPOS)

EOS.IO software utilizes the only known decentralized consensus algorithm proven capable of meeting the performance requirements of applications on the blockchain, Delegated Proof of Stake (DPOS).
Under this algorithm, those who hold tokens on a blockchain adopting the EOS.IO software may select block producers through a continuous approval voting system.
Anyone may choose to participate in block production and will be given an opportunity to produce blocks, provided they can persuade token holders to vote for them.

The EOS.IO software enables blocks to be produced exactly every 0.5 second and exactly one producer is authorized to produce a block at any given point in time.
If the block is not produced at the scheduled time, then the block for that time slot is skipped.
When one or more blocks are skipped, there is a 0.5 or more second gap in the blockchain.

Using the EOS.IO software, blocks are produced in rounds of 126 (6 blocks each, times 21 producers).
At the start of each round 21 unique block producers are chosen by preference of votes cast by token holders.
The selected producers are scheduled in an order agreed upon by 15 or more producers.

If a producer misses a block and has not produced any block within the last 24 hours they are removed from consideration until they notify the blockchain of their intention to start producing blocks again.
This ensures the network operates smoothly by minimizing the number of blocks missed by not scheduling producers who are proven to be unreliable.

Under normal conditions a DPOS blockchain does not experience any forks because, rather than compete, the block producers cooperate to produce blocks.
In the event there is a fork, consensus will automatically switch to the longest chain.
This method works because the rate at which blocks are added to a blockchain fork is directly correlated to the percentage of block producers that share the same consensus.
In other words, a blockchain fork with more producers on it will grow in length faster than one with fewer producers, because the fork with more producers will experience fewer missed blocks.

Furthermore, no block producer should be producing blocks on two forks at the same time.
A block producer caught doing this will likely be voted out.
Cryptographic evidence of such double-production may also be used to automatically remove abusers.

Byzantine Fault Tolerance is added to traditional DPOS by allowing all producers to sign all blocks so long as no producer signs two blocks with the same timestamp or the same block height.
Once 15 producers have signed a block the block is deemed irreversible.
Any byzantine producer would have to generate cryptographic evidence of their treason by signing two blocks with the same timestamp or blockheight.
Under this model a irreversible consensus should be reachable within 1 second.

Transaction Confirmation

Typical DPOS blockchains have 100% block producer participation.
A transaction can be considered confirmed with 99.9% certainty after an average of 0.25 seconds from time of broadcast.

In addition to DPOS, EOS.IO adds asynchronous Byzantine Fault Tolerance (aBFT) for faster achievement of irreversibility.
The aBFT algorithm provides 100% confirmation of irreversibility within 1 second.

Transaction as Proof of Stake (TaPoS)

The EOS.IO software requires every transaction to include part of the hash of a recent block header.
This hash serves two purposes:
1. prevents a replay of a transaction on forks that do not include the referenced block; and
2. signals the network that a particular user and their stake are on a specific fork.

Over time all users end up directly confirming the blockchain which makes it difficult to forge counterfeit chains as the counterfeit would not be able to migrate transactions from the legitimate chain.

4.Accounts

The EOS.IO software permits all accounts to be referenced by a unique human readable name of up to 12 characters in length.
The name is chosen by the creator of the account.
The account creator must reserve the RAM required to store the new account until the new account stakes tokens to reserve its own RAM.

In a decentralized context, application developers will pay the nominal cost of account creation to sign up a new user.
Traditional businesses already spend significant sums of money per customer they acquire in the form of advertising, free services, etc.
The cost of funding a new blockchain account should be insignificant in comparison.
Fortunately, there is no need to create accounts for users already signed up by another application.

Actions & Handlers

Each account can send structured Actions to other accounts and may define scripts to handle Actions 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.

To support parallel execution, each account can also define any number of scopes within their database.
The block producers will schedule transaction in such a way that there is no conflict over memory access to scopes and therefore they can be executed in parallel.

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.

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.

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.

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.

Named Permission Levels

Using the EOS.IO software, accounts can define named permission levels each of which can be derived from higher level named permissions.
Each named permission level defines an authority; an authority is a threshold multi-signature check consisting of keys and/or named permission levels of other accounts.
For example, an account's "Friend" permission level can be set for an Action on the account to be controlled equally by any of the account's friends.

Another example is the Steem blockchain which has three hard-coded named permission levels: owner, active, and posting.
The posting permission can only perform social actions such as voting and posting, while the active permission can do everything except change the owner.
The owner permission is meant for cold storage and is able to do everything.
The EOS.IO software generalizes this concept by allowing each account holder to define their own hierarchy as well as the grouping of actions.

Permission Mapping

EOS.IO software allows each account to define a mapping between a contract/action or contract of any other account and their own Named Permission Level.
For example, an account holder could map the account holder's social media application to the account holder's "Friend" permission group.
With this mapping, any friend could post as the account holder on the account holder's social media.
Even though they would post as the account holder, they would still use their own keys to sign the Action.
This means it is always possible to identify which friends used the account and in what way.

Evaluating Permissions

When delivering an Action of type "Action", from @alice to @bob the EOS.IO software will first check to see if @alice has defined a permission mapping for @bob.groupa.subgroup.Action.
If nothing is found then a mapping for @bob.groupa.subgroup then @bob.groupa, and lastly @bob will be checked.
If no further match is found, then the assumed mapping will be to the named permission group @alice.active.

Once a mapping is identified then signing authority is validated using the threshold multi-signature process and the authority associated with the named permission.
If that fails, then it traverses up to the parent permission and ultimately to the owner permission, @alice.owner.

Default Permission Groups

The EOS.IO technology also allows all accounts to have an "owner" group which can do everything, and an "active" group which can do everything except change the owner group.
All other permission groups are derived from "active".

Parallel Evaluation of Permissions

The permission evaluation process is "read-only" and changes to permissions made by transactions do not take effect until the end of a block.
This means that all keys and permission evaluation for all transactions can be executed in parallel.
Furthermore, this means that a rapid validation of permission is possible without starting costly application logic that would have to be rolled back.
Lastly, it means that transaction permissions can be evaluated as pending transactions are received and do not need to be re-evaluated as they are applied.

All things considered, permission verification represents a significant percentage of the computation required to validate transactions.
Making this a read-only and trivially parallelizable process enables a dramatic increase in performance.

When replaying the blockchain to regenerate the deterministic state from the log of Actions there is no need to evaluate the permissions again.
The fact that a transaction is included in a known good block is sufficient to skip this step.
This dramatically reduces the computational load associated with replaying an ever growing blockchain.

Actions with Mandatory Delay

Time is a critical component of security.
In most cases, it is not possible to know if a private key has been stolen until it has been used.
Time based security is even more critical when people have applications that require keys be kept on computers connected to the internet for daily use.
The EOS.IO software enables application developers to indicate that certain Actions must wait a minimum period of time after being included in a block before they can be applied.
During this time, they can be cancelled.

Users can then receive notice via email or text message when one of these Actions is broadcast.
If they did not authorize it, then they can use the account recovery process to recover their account and retract the Action.

The required delay depends upon how sensitive an operation is.
Paying for a coffee might have no delay and be irreversible in seconds, while buying a house may require a 72 hour clearing period.
Transferring an entire account to new control may take up to 30 days.
The exact delays are chosen by application developers and users.

Recovery from Stolen Keys

The EOS.IO software provides users a way to restore control of their account when keys are stolen.
An account owner can use any owner key that was active in the last 30 days along with approval from their designated account recovery partner to reset the owner key on their account.
The account recovery partner cannot reset control of the account without the help of the owner.

There is nothing for the hacker to gain by attempting to go through the recovery process because they already "control" the account.
Furthermore, if they did go through the process, the recovery partner would likely demand identification and multi-factor authentication (phone and email).
This would likely compromise the hacker or gain the hacker nothing in the process.

This process is also very different from a simple multi-signature arrangement.
With a multi-signature transaction, another entity is made a party to every transaction that is executed.
By contrast, with the recovery process the recovery partner is only a party to the recovery process and has no power over the day-to-day transactions.
This dramatically reduces costs and legal liabilities for everyone involved.

5.Deterministic Parallel Execution of Applications

Blockchain consensus depends upon deterministic (reproducible) behavior.
This means all parallel execution must be free from the use of mutexes or other locking primitives.
Without locks there must be some way to guarantee that transactions that may be executed in parallel do not create non-deterministic results.

The June 2018 release of EOS.IO software will run single threaded, yet it contains the data structures necessary for future multithreaded, parallel execution.

In an EOS.IO software-based blockchain, once parallel operation is enabled, it will be the job of the block producer to organize Action delivery into independent shards so that they can be evaluated in parallel.
The schedule is the output of a block producer and will be deterministically executed, but the process for generating the schedule need not be deterministic.
This means that block producers can utilize parallel algorithms to schedule transactions.

Part of parallel execution means that when a script generates a new Action it does not get delivered immediately, instead it is scheduled to be delivered in the next cycle.
The reason it cannot be delivered immediately is because the receiver may be actively modifying its own state in another shard.

Minimizing Communication Latency

Latency is the time it takes for one account to send an Action to another account and then receive a response.
The goal is to enable two accounts to exchange Actions back and forth within a single block without having to wait 0.5 seconds between each Action.
To enable this, the EOS.IO software divides each block into cycles.
Each cycle is divided into shards and each shard contains a list of transactions.
Each transaction contains a set of Actions to be delivered.
This structure can be visualized as a tree where alternating layers are processed sequentially and in parallel.


    Block
      Region
        Cycles (sequential)
          Shards (parallel)
            Transactions (sequential)
              Actions (sequential)
                Receiver and Notified Accounts (parallel)
    

Transactions generated in one cycle can be delivered in any subsequent cycle or block.
Block producers will keep adding cycles to a block until the maximum wall clock time has passed or there are no new generated transactions to deliver.

It is possible to use static analysis of a block to verify that within a given cycle no two shards contain transactions that modify the same account.
So long as that invariant is maintained a block can be processed by running all shards in parallel.

Read-Only Action Handlers

Some accounts may be able to process an Action on a pass/fail basis without modifying their internal state.
If this is the case, then these handlers can be executed in parallel so long as only read-only Action handlers for a particular account are included in one or more shards within a particular cycle.

Atomic Transactions with Multiple Accounts

Sometimes it is desirable to ensure that Actions are delivered to and accepted by multiple accounts atomically.
In this case both Actions are placed in one transaction and both accounts will be assigned the same shard and the Actions applied sequentially.

Partial Evaluation of Blockchain State

Scaling blockchain technology necessitates that components are modular.
Everyone should not have to run everything, especially if they only need to use a small subset of the applications.

An exchange application developer runs full nodes for the purpose of displaying the exchange state to its users.
This exchange application has no need for the state associated with social media applications.
EOS.IO software allows any full node to pick any subset of applications to run.
Actions delivered to other applications are safely ignored if your application never depends upon the state of another contract.

Subjective Best Effort Scheduling

The EOS.IO software cannot obligate block producers to deliver any Action to any other account.
Each block producer makes their own subjective measurement of the computational complexity and time required to process a transaction.
This applies whether a transaction is generated by a user or automatically by a smart contract.

On a launched blockchain adopting the EOS.IO software, at a network level all transactions are billed a computational bandwidth cost based on the number of WASM instructions executed.
However, each individual block producer using the software may calculate resource usage using their own algorithm and measurements.
When a block producer concludes that a transaction or account has consumed a disproportionate amount of the computational capacity they simply reject the transaction when producing their own block; however, they will still process the transaction if other block producers consider it valid.

In general, so long as even 1 block producer considers a transaction as valid and under the resource usage limits then all other block producers will also accept it, but it may take up to 1 minute for the transaction to find that producer.

In some cases, a producer may create a block that includes transactions that are an order of magnitude outside of acceptable ranges.
In this case the next block producer may opt to reject the block and the tie will be broken by the third producer.
This is no different than what would happen if a large block caused network propagation delays.
The community would notice a pattern of abuse and eventually remove votes from the rogue producer.

This subjective evaluation of computational cost frees the blockchain from having to precisely and deterministically measure how long something takes to run.
With this design there is no need to precisely count instructions which dramatically increases opportunities for optimization without breaking consensus.

Deferred Transactions

EOS.IO Software supports deferred transactions that are scheduled to execute in the future.
This enables computation to move to different shards and/or the creation of long-running processes that continuously schedule a continuance transaction.

Context Free Actions

A Context Free Action involves computations that depend only on transaction data, but not upon the blockchain state.
Signature verification, for example, is a computation that requires only the transaction data and a signature to determine the public key that signed the transaction.
This is one of the most expensive individual computations a blockchain must perform, but because this computation is context free it can be performed in parallel.

Context Free Actions are like other user Actions, except they lack access to the blockchain state to perform validation.
Not only does this enable EOS.IO to process all Context Free Actions such as signature verification in parallel, but more importantly, this enables generalized signature verification.

With support for Context Free Actions, scalability techniques such as Sharding, Raiden, Plasma, State Channels, and others become much more parallelizable and practical.
This development enables efficient inter-blockchain communication and potentially unlimited scalability.

6.Token Model and Resource Usage

PLEASE NOTE:
CRYPTOGRAPHIC TOKENS REFERRED TO IN THIS WHITE PAPER REFER TO CRYPTOGRAPHIC TOKENS ON A LAUNCHED BLOCKCHAIN THAT ADOPTS THE EOS.IO SOFTWARE.
THEY DO NOT REFER TO THE ERC-20 COMPATIBLE TOKENS BEING DISTRIBUTED ON THE ETHEREUM BLOCKCHAIN IN CONNECTION WITH THE EOS TOKEN DISTRIBUTION.

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:
1. Bandwidth and Log Storage (Disk);
2. Computation and Computational Backlog (CPU); and
3. 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.

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.

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.

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.

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.

Objective and Subjective Measurements

As discussed earlier, instrumenting computational usage has a significant impact on performance and optimization; therefore, all resource usage constraints are ultimately subjective, and enforcement is done by block producers according to their individual algorithms and estimates.
These would typically be implemented by a block producer via the writing of a custom plugin.

That said, there are certain things that are trivial to measure objectively.
The number of Actions delivered, and the size of the data stored in the internal database are cheap to measure objectively.
The EOS.IO software enables block producers to apply the same algorithm over these objective measures but may choose to apply stricter subjective algorithms over subjective measurements.

Receiver Pays

Traditionally, it is the business that pays for office space, computational power, and other costs required to run the business.
The customer buys specific products from the business and the revenue from those product sales is used to cover the business costs of operation.
Similarly, no website obligates its visitors to make micropayments for visiting its website to cover hosting costs.
Therefore, decentralized applications should not force its customers to pay the blockchain directly for the use of the blockchain.

A launched blockchain that uses the EOS.IO software does not require its users to pay the blockchain directly for its use and therefore does not constrain or prevent a business from determining its own monetization strategy for its products.

While it is true that the receiver can pay, EOS.IO enables the sender to pay for bandwidth, computation, and storage.
This empowers application developers to pick the method that is best for their application.
In many cases sender-pays significantly reduces complexity for application developers who do not want to implement their own rationing system.
Application developers can delegate bandwidth and computation to their users and then let the “sender pays” model enforce the usage.
From the perspective of the end user it is free, but from the perspective of the blockchain it is sender-pays.

Delegating Capacity

A holder of tokens on a blockchain launched adopting the EOS.IO software who may not have an immediate need to consume all or part of the available bandwidth, can delegate or rent such unconsumed bandwidth to others; the block producers running EOS.IO software on such blockchain will recognize this delegation of capacity and allocate bandwidth accordingly.

Separating Transaction costs from Token Value

One of the major benefits of the EOS.IO software is that the amount of bandwidth available to an application is entirely independent of any token price.
If an application owner holds a relevant number of tokens on a blockchain adopting EOS.IO software, then the application can run indefinitely within a fixed state and bandwidth usage.
In such case, developers and users are unaffected from any price volatility in the token market and therefore not reliant on a price feed.
In other words, a blockchain that adopts the EOS.IO software enables block producers to naturally increase bandwidth, computation, and storage available per token independent of the token's value.

A blockchain using EOS.IO software also awards block producers tokens every time they produce a block.
The value of the tokens will impact the amount of bandwidth, storage, and computation a producer can afford to purchase; this model naturally leverages rising token values to increase network performance.

State Storage Costs

While bandwidth and computation can be delegated, storage of application state will require an application developer to hold tokens until that state is deleted.
If state is never deleted, then the tokens are effectively removed from circulation.

Block Rewards

A blockchain that adopts the EOS.IO software will award new tokens to a block producer every time a block is produced.
In these circumstances, the number of tokens created is determined by the median of the desired pay published by all block producers.
The EOS.IO software may be configured to enforce a cap on producer awards such that the total annual increase in token supply does not exceed 5%.

Worker Proposal System

In addition to electing block producers, pursuant to a blockchain based on the EOS.IO software, token holders can elect a number of Worker Proposals designed to benefit the community.
The winning proposals will receive tokens of up to a configured percent of the token inflation minus those tokens that have been paid to block producers.
These proposals will receive tokens proportional to the votes each application has received from token holders, up to the amount they request for performing their work.
The elected proposals can be replaced by newly elected proposals by token holders.

The system contracts that implement Worker Proposals may not be in place at initial launch in June 2018, but the funding mechanism will.
It will begin to accumulate funds at the same time block producer awards start.
Since the Worker Proposal System will be implemented in WASM it can be added at a later date without a fork.

7.Governance

Governance is the process by which people in a community:
1. Reach consensus on subjective matters of collective action that cannot be captured entirely by software algorithms;
2. Carry out the decisions they reach; and
3. Alter the governance rules themselves via Constitutional amendments.

An EOS.IO software-based blockchain implements a governance process that efficiently directs the existing influence of block producers.
Absent a defined governance process, prior blockchains relied ad hoc, informal, and often controversial governance processes that result in unpredictable outcomes.

A blockchain based on the EOS.IO software recognizes that power originates with the token holders who delegate that power to the block producers.
The block producers are given limited and checked authority to freeze accounts, update defective applications, and propose hard forking changes to the underlying protocol.

Embedded into the EOS.IO software is the election of block producers.
Before any change can be made to the blockchain these block producers must approve it.
If the block producers refuse to make changes desired by the token holders then they can be voted out.
If the block producers make changes without permission of the token holders then all other non-producing full-node validators (exchanges, etc) will reject the change.

Freezing Accounts

Sometimes a smart contact behaves in an aberrant or unpredictable manner and fails to perform as intended; other times an application or account may discover an exploit that enables it to consume an unreasonable amount of resources.
When such issues inevitably occur, the block producers have the power to rectify such situations.

The block producers on all blockchains have the power to select which transactions are included in blocks which gives them the ability to freeze accounts.
A blockchain using EOS.IO software formalizes this authority by subjecting the process of freezing an account to a 15/21 vote of active producers.
If the producers abuse the power they can be voted out and an account will be unfrozen.

Changing Account Code

When all else fails and an "unstoppable application" acts in an unpredictable manner, a blockchain using EOS.IO software allows the block producers to replace the account's code without hard forking the entire blockchain.
Similar to the process of freezing an account, this replacement of the code requires a 15/21 vote of elected block producers.

Constitution

The EOS.IO software enables blockchains to establish a peer-to-peer terms of service agreement or a binding contract among those users who sign it, referred to as a "constitution".
The content of this constitution defines obligations among the users which cannot be entirely enforced by code and facilitates dispute resolution by establishing jurisdiction and choice of law along with other mutually accepted rules.
Every transaction broadcast on the network must incorporate the hash of the constitution as part of the signature and thereby explicitly binds the signer to the contract.

The constitution also defines the human-readable intent of the source code protocol.
This intent is used to identify the difference between a bug and a feature when errors occur and guides the community on what fixes are proper or improper.

Upgrading the Protocol & Constitution

The EOS.IO software defines the following process by which the protocol, as defined by the canonical source code and its constitution, can be updated:

  1. Block producers propose a change to the constitution and obtains 15/21 approval.
  2. Block producers maintain 15/21 approval of the new constitution for 30 consecutive days.
  3. All users are required to indicate acceptance of the new constitution as a condition of future transactions being processed.
  4. Block producers adopt changes to the source code to reflect the change in the constitution and propose it to the blockchain using the hash of the new constitution.
  5. Block producers maintain 15/21 approval of the new code for 30 consecutive days.
  6. Changes to the code take effect 7 days later, giving all non-producing full nodes 1 week to upgrade after ratification of the source code.
  7. All nodes that do not upgrade to the new code shut down automatically.

By default, configuration of the EOS.IO software, the process of updating the blockchain to add new features takes 2 to 3 months, while updates to fix non-critical bugs that do not require changes to the constitution can take 1 to 2 months.

Emergency Changes

The block producers may accelerate the process if a software change is required to fix a harmful bug or security exploit that is actively harming users.
Generally speaking it could be against the constitution for accelerated updates to introduce new features or fix harmless bugs.

8.Scripts & Virtual Machines

The EOS.IO software will be first and foremost a platform for coordinating the delivery of authenticated messages (called Actions) to accounts.
The details of scripting language and virtual machine are implementation specific details that are mostly independent from the design of the EOS.IO technology.
Any language or virtual machine that is deterministic and properly sandboxed with sufficient performance can be integrated with the EOS.IO software API.

Schema Defined Actions

All Actions sent between accounts are defined by a schema which is part of the blockchain consensus state.
This schema allows seamless conversion between binary and JSON representation of the Actions.

Schema Defined Database

Database state is also defined using a similar schema.
This ensures that all data stored by all applications is in a format that can be interpreted as human readable JSON but stored and manipulated with the efficiency of binary.

Generic Multi Index Database API

Developing smart contracts requires a defined database schema to track, store, and find data.
Developers commonly need the same data sorted or indexed by multiple fields and to maintain consistency among all the indices.

Separating Authentication from Application

To maximize parallelization opportunities and minimize the computational debt associated with regenerating application state from the transaction log, EOS.IO software separates validation logic into three sections:
1. Validating that an Action is internally consistent;
2. Validating that all preconditions are valid; and
3. Modifying the application state.

Validating the internal consistency of a Action is read-only and requires no access to blockchain state.
This means that it can be performed with maximum parallelism.
Validating preconditions, such as required balance, is read-only and therefore can also benefit from parallelism.
Only modification of application state requires write access and must be processed sequentially for each application.

Authentication is the read-only process of verifying that an Action can be applied.
Application is actually doing the work.
In real time both calculations are required to be performed, however once a transaction is included in the blockchain it is no longer necessary to perform the authentication operations.

9.Inter Blockchain Communication

EOS.IO software is designed to facilitate inter-blockchain communication.
This is achieved by making it easy to generate proof of Action existence and proof of Action sequence.
These proofs combined with an application architecture designed around Action passing enables the details of inter-blockchain communication and proof validation to be hidden from application developers, enabling high level abstractions to be presented to developers.

Merkle Proofs for Light Client Validation (LCV)

Integrating with other blockchains is much easier if clients do not need to process all transactions.
After all, an exchange only cares about transfers in and out of the exchange and nothing more.
It would also be ideal if the exchange chain could utilize lightweight merkle proofs of deposit rather than having to trust its own block producers entirely.
At the very least a chain's block producers would like to maintain the smallest possible overhead when synchronizing with another blockchain.

The goal of LCV is to enable the generation of relatively light-weight proof of existence that can be validated by anyone tracking a relatively light-weight data set.
In this case the objective is to prove that a particular transaction was included in a particular block and that the block is included in the verified history of a particular blockchain.

Bitcoin supports validation of transactions assuming all nodes have access to the full history of block headers which amounts to 4MB of block headers per year.
At 10 transactions per second, a valid proof requires about 512 bytes.
This works well for a blockchain with a 10 minute block interval, but is no longer "light" for blockchains with a 0.5 second block interval.

The EOS.IO software enables lightweight proofs for anyone who has any irreversible block header after the point in which the transaction was included.
Using the hash-linked structure shown it is possible to prove the existence of any transaction with a proof less than 1024 bytes in size.

Given any block id for a block in the blockchain, and the headers a trusted irreversible block.
It is possible to prove that the block is included in the blockchain.
This proof takes ceil(log2(N)) digests for its path, where N is the number of blocks in the chain.
Given a digest method of SHA256, you can prove the existence of any block in a chain which contains 100 million blocks in 864 bytes.

There is little incremental overhead associated with producing blocks with the proper hash-linking to enable these proofs which means there is no reason not to generate blocks this way.

When it comes time to validate proofs on other chains there are a wide variety of time/ space/ bandwidth optimizations that can be made.
Tracking all block headers (420 MB/year) will keep proof sizes small.
Tracking only recent headers can offer a trade off between minimal long-term storage and proof size.
Alternatively, a blockchain can use a lazy evaluation approach where it remembers intermediate hashes of past proofs.
New proofs only have to include links to the known sparse tree.
The exact approach used will necessarily depend upon the percentage of foreign blocks that include transactions referenced by merkle proof.

After a certain density of interconnectedness, it becomes more efficient to simply have one chain contain the entire block history of another chain and eliminate the need for proofs all together.
For performance reasons, it is ideal to minimize the frequency of inter-chain proofs.

Latency of Interchain Communication

When communicating with another outside blockchain, block producers must wait until there is 100% certainty that a transaction has been irreversibly confirmed by the other blockchain before accepting it as a valid input.
Using an EOS.IO software-based blockchain and DPOS with 0.5 second blocks and the addition of Byzantine Fault Tolerant irreversibility, this takes approximately 0.5 second.
If any chain's block producers do not wait for irreversibility it would be like an exchange crediting a deposit that was later reversed and could impact the validity of the blockchain's consensus.
The EOS.IO Software uses both DPOS and aBFT to provide rapid irreversibility.

Proof of Completeness

When using merkle proofs from outside blockchains, there is a significant difference between knowing that all transactions processed are valid and knowing that no transactions have been skipped or omitted.
While it is impossible to prove that all of the most recent transactions are known, it is possible to prove that there have been no gaps in the transaction history.
The EOS.IO software facilitates this by assigning a sequence number to every Action delivered to every account.
A user can use these sequence numbers to prove that all Actions intended for a particular account have been processed and that they were processed in order.

Segregated Witness

The concept of Segregated Witness (SegWit) is that transaction signatures are not relevant after a transaction is immutably included in the blockchain.
Once it is immutable the signature data can be pruned and everyone else can still derive the current state.
Since signatures represent a large percentage of most transactions, SegWit represents a significant savings in disk usage and syncing time.

This same concept can apply to merkle proofs used for inter-blockchain communication.
Once a proof is accepted and irreversibly logged into the blockchain, the 2KB of sha256 hashes used by the proof are no longer necessary to derive the proper blockchain state.
In the case of inter-blockchain communication, this savings is 32x greater than the savings on normal signatures.

Another example of SegWit would be for Steem blog posts.
Under this model a post would contain only the sha256(blog content) and the blog content would be in the segregated witness data.
The block producer would verify that the content exists and has the given hash, but the blog content would not need to be stored in order to recover the current state from the blockchain log.
This enables proof that the content was once known without having to store said content forever.

10.Conclusion

The EOS.IO software is designed from experience with proven concepts and best practices, and represents fundamental advancements in blockchain technology.
The software is part of a holistic blueprint for a globally scalable blockchain society in which decentralized applications can be easily deployed and governed.

EOS.IO-Storage of Eos-protocol

description::
EOS.IO Storage is a proposed decentralized file system designed to give everyone the ability to permanently store and host files accessible by any web browser.
Unlike some other proposed alternatives, there would be no upfront fee or ongoing charge for storage or bandwidth on EOS.IO Storage aside from a completely refundable deposit.
Users must hold tokens while they need storage and bandwidth and may sell tokens when storage and bandwidth is no longer required.
Built on the InterPlanetary File System (IPFS) and the EOS.IO software, EOS.IO Storage will be a service provided by block producers for those who hold tokens on a blockchain that adopts the EOS.IO software.
The block producers would be incentivized to replicate and host these files, allowing anyone with an Internet browser to access them.
[https://github.com/EOSIO/Documentation/blob/master/EOS.IO%20Storage.pdf]
===
EOS.IO Storage is a decentralized file system designed to give everyone in the world with Internet access the ability to permanently store and host legal files which are accessible by any browser. Unlike current alternatives, there are no fees for storage or bandwidth on EOS.IO Storage. Built on IPFS, EOS.IO Storage is a service provided by block producers for those who hold a blockchain’s native tokens. EOS.IO block producers will replicate and host token-holders’ files on the IPFS network as well as provide https endpoints allowing anyone with a browser to access the files.
Collectively the producers will reach consensus on how much storage they are willing to provide in exchange for their compensation (block rewards). Block producers who offer more storage for the same reward are likely to earn more votes from token holders.
[https://steemit.com/eos/@eosio/introducing-eos-io-application-stack]

name::
* Mcs.Eos-net'protocol.storage,
* Mcs.Eos-storage-protocol,
* Mcs.EOS.IO-Storage,

addressWpg::
* https://github.com/EOSIO/Documentation/blob/master/EOS.IO%20Storage.pdf,

node of Eos-net

name::
* Mcs.Eos-net'node,
* Mcs.Eos-node,

generic-chain::
* blockchain-net'node,

node.BLOCK-PRODUCER (BP)

name::
* Mcs.Eos-block-producer-node,
* Mcs.Eos-net'block-producer-node,
* Mcs.Eos-net'BP,
* Mcs.Eos-net'node.block-producer,
* Mcs.Eos-node.block-producer,

addressWpg::
* {2018-02-28} EOS Block Producer Candidacy: https://steemit.com/eos-blockproducers/@xebb/,

votes of BP

name::
* Mcs.Eos-net'BP'vote,

voting for block-producer-node

description::
According to the EOS ‘Constitution’ the 21 elected block producers do not keep their position forever.
In fact, EOS voting is a never-ending process, with votes being recalculated every two minutes to ensure that the set of "active" BPs is constantly changing.
So, if BPs want to keep their "job", they need to make sure they are doing a good job; otherwise some of the "standby" BPs could get more votes and take over from them.
You can vote and change your vote as many times you want.
[https://www.cryptoglobe.com/latest/2018/06/eos-is-officially-live-as-15-voting-threshold-is-met/]
===
"If you are not voting on at least 15 BPs, you are leaving the network vulnerable to attacks."
- @bytemaster7
[https://twitter.com/EOSTribe/status/1009082599564873733]

name::
* Mcs.Eos-block-producer-node'voting,
* Mcs.Eos-net'voting,

jurisdiction of BP

name::
* Mcs.Eos-net'BP'jurisdiction,

server of BP

name::
* Mcs.Eos-net'BP'server,

unpaid-block of BP

name::
* Mcs.Eos-net'BP'unpaid-block,

reward of BP

name::
* Mcs.Eos-net'BP'reward,

Url of BP

name::
* Mcs.Eos-net'BP'Url,

evaluation of BP

name::
* Mcs.Eos-net'BP'evaluation,

specific::
* mereo-rating-system: http://www.mereo.io/,
* https://blog.goodaudience.com/ranking-50-top-eos-block-producers-on-governance-best-practices-value-add-7fc47817fbbc,

BP.SPECIFIC

name::
* Mcs.Eos-net'BP.specific,

BP.PAID

description::
"Further, there aren’t just 21 nodes. There are 21 nodes producing blocks at a time, but the total number of possible nodes is unlimited, with every node competing to be among the top ~80, which are paid."
[https://www.theblockcrypto.com/2018/12/21/eos-is-a-dao/]

name::
* Mcs.Eos-net'BP'paid,

BP.TOP21

name::
* Mcs.Eos-producing-node,
* Mcs.Eos-net'BP.top21,

BP.STANDBY

name::
* Mcs.Eos-net'BP.standby,

BP.CONNECTED

description::
· any connected block-producer-node producing or not blocks.
· see live info: https://eosportal.io/chain/12/info,

name::
* Mcs.Eos-net'BP.connected,

BP.eosDAC

description::
A Decentralised Autonomous Community (DAC) is governed by it’s constitution, which is encoded in smart contracts on the blockchain. This revolutionary way of bringing a community together as a cooperative is made possible by the EOS software. The DAC is controlled by it’s token holders and the board members they vote to run it’s operations.
eosDAC is being created and launched by BlockMaker Ltd. Once eosDAC is launched BlockMaker Ltd will not have any ownership or control over eosDAC, nor own any eosDAC tokens. BlockMaker Ltd has invested heavily in people, infrastructure and processes, in order to ensure that eosDAC can serve as a main block producer should it receive sufficient votes from EOS token holders.
[http://eosdac.io/]

name::
* Mcs.Eos-net'BP.eosDAC,
* Mcs.Eos-net'eosDAC,
* Mcs.eosDAC,

addressWpg::
* https://steemit.com/@eosdac,
===
{2018-03-26} Calling all EOS Token Holders - Get Ready for the eosDAC Snapshot: https://steemit.com/eos/@eosdac/,

RAM-resource of Eos-net

description::
· RAM is a-resource you need to make transactions.
· you have to BUY it.
· it is-measured in bytes.
===
"What is RAM?
In computer science, RAM (Random Access Memory) is a form of computer data storage that stores data and machine code currently being used. When running an application, RAM is used to hold active data for a short period of time because RAM is very fast when it comes to reading and writing. Such data includes keys, balances and contract state.
However, EOS RAM is a more complicated concept. It does not precisely correspond to the RAM concept in computer science. Simply put, it is all the resources used except CPU and bandwidth in EOS, roughly corresponding to RAM and database in computer science sense."
[https://medium.com/coinmonks/eos-ram-101-non-technical-guidebook-for-beginners-6f971322042e]
===
"For CPU and Network allocations, if you stake 10 EOS, you will receive 10 EOS back when you unstake. However, the RAM market is different. The pricing of a byte of RAM fluctuates based on the available RAM left in the marketplace. This means that someone could profit or take a loss on their RAM purchases/sales. The goal was to incentivize developers and users from sitting on their unused RAM, encouraging them to release it back to the network."
[https://www.eoscanada.com/en/what-does-staking-and-unstaking-eos-tokens-mean]

name::
* Mcs.Eos-net'RAM,
* Mcs.Eos-net'storage,
* Mcs.Eos-RAM,

addressWpg::
* market: https://eos.feexplorer.io/,
* real time RAM price: https://explorer.eosvibes.io/,
* {2018-07-17} EOSREAL, EOS RAM 101: Non-Technical Guidebook for Beginners, https://medium.com/coinmonks/eos-ram-101-non-technical-guidebook-for-beginners-6f971322042e,

CPU-resource of Eos-net

description::
· you have to stake|freeze EOS to get CPU.
===
"CPU -Processing Power
CPU bandwidth is used when transactions or actions are put into play. Just like a normal Processor on a computer, the longer you run a program the more CPU is required."
[https://bit-media.org/cryptocurrency/eos-ram-cpu-net-staking-and-unstaking-explained/]
===
"CPU bandwidth signifies the processing time of an action, measured in microseconds. So if you were to make an EOS token transfer from your account to a friend’s account, this action would take some amount of time to complete. This amount of transaction time would come off of your allocation, and then regenerate over time."
[https://www.eoscanada.com/en/what-does-staking-and-unstaking-eos-tokens-mean]

name::
* Mcs.Eos-CPU,
* Mcs.Eos-net'CPU,
* Mcs.Eos-net'CPU-usage,

NET|bandwidth-resource of Eos-net

description::
· you have to stake|freeze EOS to get NET.
===
"Network bandwidth signifies the throughput capacity of the EOS network, measured in bytes. In the same example as above where you moved EOS tokens to a friend’s account, that transaction would require some of the network’s capacity. Same as with CPU, this transaction data would come off of your allocation, and then regenerate over time."
[https://www.eoscanada.com/en/what-does-staking-and-unstaking-eos-tokens-mean]

name::
* Mcs.Eos-bandwidth,
* Mcs.Eos-net'bandwidth,
* Mcs.Eos-net'net-usage,

blockchain of Eos-net

name::
* Mcs.Eos-blockchain,
* Mcs.Eos-net'blockchain,

generic-chain::
* blockchain,

block of Eos-blockchain

name::
* Mcs.Eos-block,
* Mcs.Eos-net'block,

generic-chain::
* blockchain-net'block,

number of Eos-block

name::
* Mcs.Eos-net'block'number,

timestamp of Eos-block

name::
* Mcs.Eos-net'block'timestamp,

producer of Eos-block

name::
* Mcs.Eos-net'block'producer,

transaction of Eos-block

name::
* Mcs.Eos-net'block'transaction,

block.IRREVERSIBLE

description::
"Once a block is deemed irreversible, it means that it has been verified and signed by at least 15 Block Producers, and can now be fully trusted."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-net'block.irreversible,

block.LAST-IRREVERSIBLE-BLOCK

description::
"LIB - Last Irreversible Block
If a block is deemed irreversible, it means that you can trust with 100% confidence that that transaction is final, fully confirmed, and immutable. If the block number of a block is lower than the Last Irreversible Block, that means it is considered final. Commonly abbreviated as LIB."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-net'block.last-irreversible-block,
* Mcs.Eos-net'LIB,

finality of Eos-net

description::
"Finality
Unlike on other blockchains where one can only have a high degree of confidence that a transaction is accepted by waiting for enough confirmations, on EOSIO software it is possible to reach definite finality. Transactions behind the Last Irreversible Block are actually final and cannot be removed through a longer chain coming into existence through an attack. This will be extremely important once Inter-Blockchain Communication is functional."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-net'finality,

block-explorer of Eos-blockchain

name::
* Mcs.Eos-block-explorer,
* Mcs.Eos-explorer,
* Mcs.Eos-net'block-explorer,
* Mcs.Eos-net'explorer,

generic-chain::
* blockchain-net'block-explorer,

specific::
* EOS-Tracker: https://eostracker.io/,
* EOSPark: https://eospark.com/,
* EOS EXPLORER by eosvibesbloc: https://explorer.eosvibes.io/,
* Bloks.io by EOS-CAFE and HKEOS: https://bloks.io/, vote and wallet,
* EOS Network Monitor.io: https://eosnetworkmonitor.io/,
* https://eosflare.io/,
* EOSweb: https://eosweb.net/,

consensus-algorithm of Eos-blockchain

description::
EOS.IO software utilizes the only decentralized consensus algorithm capable of meeting the performance requirements of applications on the blockchain, Delegated Proof of Stake (DPOS). Under this algorithm, those who hold tokens on a blockchain adopting the EOS.IO software may select block producers through a continuous approval voting system and anyone may choose to participate in block production and will be given an opportunity to produce blocks proportional to the total votes they have received relative to all other producers. For private blockchains the management could use the tokens to add and remove IT staff.
The EOS.IO software enables blocks to be produced exactly every 3 seconds and exactly one producer is authorized to produce a block at any given point in time. If the block is not produced at the scheduled time then the block for that time slot is skipped. When one or more blocks are skipped, there is a 6 or more second gap in the blockchain.
Using the EOS.IO software blocks are produced in rounds of 21. At the start of each round 21 unique block producers are chosen. The top 20 by total approval are automatically chosen every round and the last producer is chosen proportional to their number of votes relative to other producers. The selected producers are shuffled using a pseudorandom number derived from the block time. This shuffling is done to ensure that all producers maintain balanced connectivity to all other producers.
If a producer misses a block and has not produced any block within the last 24 hours they are removed from consideration until they notify the blockchain of their intention to start producing blocks again. This ensures the network operates smoothly by minimizing the number of blocks missed by not scheduling those who are proven to be unreliable.
Under normal conditions a DPOS blockchain does not experience any forks because the block producers cooperate to produce blocks rather than compete. In the event there is a fork, consensus will automatically switch to the longest chain. This metric works because the rate at which blocks are added to a blockchain chain fork is directly correlated to the percentage of block producers that share the same consensus. In other words, a blockchain fork with more producers on it will grow in length faster than one with fewer producers. Furthermore, no block producer should be producing blocks on two forks at the same time. If a block producer is caught doing this then such block producer will likely be voted out. Cryptographic evidence of such double-production may also be used to automatically remove abusers.
[https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md#consensus-algorithm-dpos]

name::
* Mcs.Eos-blockchain'consensus-algorithm,
* Mcs.Eos-consensus-algorithm,
* Mcs.Eos-net'consensus-algorithm,

transaction of Eos-blockchain

description::
"A block on the EOS blockchain can include many different transactions within it. Each transaction can include one or multiple different actions. Every interaction with the blockchain is classified as a transaction, not just the movement of tokens from one account to another."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-blockchain'transaction,
* Mcs.Eos-net'transaction,
* Mcs.Eos-transaction,

generic-chain::
* blockchain-net'transaction,

action of Eos-transaction

description::
"Every transaction in a block is made up of one or more actions. Each action is an instruction to perform a given task. A transaction can be built up of multiple actions that are linked together."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-net'transaction'action,

CPU-usage of Eos-transaction

name::
* Mcs.Eos-net'transaction'CPU-usage,

net-usage of Eos-transaction

name::
* Mcs.Eos-net'transaction'net-usage,

transaction-per-second-(tps) of Eos-transaction

name::
* Mcs.Eos-net'tps,
* Mcs.Eos-net'transaction'tps,

confirmation of Eos-transaction

description::
Typical DPOS blockchains have 100% block producer participation. A transaction can be considered confirmed with 99.9% certainty after an average of 1.5 seconds from time of broadcast.
There are some extraordinary cases where a software bug, Internet congestion, or a malicious block producer will create two or more forks. For absolute certainty that a transaction is irreversible, a node may choose to wait for confirmation by 15 out of the 21 block producers. Based on a typical configuration of the EOS.IO software, this will take an average of 45 seconds under normal circumstances. By default all nodes will consider a block confirmed by 15 of 21 producers irreversible and will not switch to a fork that excludes such a block regardless of length.
It is possible for a node to warn users that there is a high probability that they are on a minority fork within 9 seconds of the start of a fork. After 2 consecutive missed blocks there is a 95% probability a node is on a minority fork. With 3 consecutive missed blocks there is a 99% certainty of being on a minority fork. It is possible to generate a robust predictive model that will utilize information about which nodes missed, recent participation rates, and other factors to quickly warn operators that something is wrong.
The response to such a warning depends entirely upon the nature of the business transactions, but the simplest response is to wait for 15/21 confirmations until the warning stops.
[https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md#transaction-confirmation]

name::
* Mcs.Eos-net'transaction'confirmation,
* Mcs.Eos-transaction'confirmation,

account of Eos-net

description::
"Account
On an EOSIO blockchain, the principle identifier for a user is an account name, rather than public key. An account can be controlled through public key/private key pairs. By default, an account name is 12 characters long, and must be made up of the lowercase letters a through z, and the numbers 1 through 5. There is a mechanism to obtain shorter account names, through Namespace Bidding. An account can have many different permissions associated to different actions that can be done on the EOS network. These permissions are controlled through various private keys, or specific authorities can be delegated to other accounts."
[https://www.eoscanada.com/en/abc-eos]
===
"The EOS.IO software permits all accounts to be referenced by a unique human readable name of 2 to 32 characters in length. The name is chosen by the creator of the account. All accounts must be funded with the minimal account balance at the time they are created to cover the cost of storing account data. Account names also support namespaces such that the owner of account @domain is the only one who can create the account @user.domain.
In a decentralized context, application developers will pay the nominal cost of account creation to sign up a new user. Traditional businesses already spend significant sums of money per customer they acquire in the form of advertising, free services, etc. The cost of funding a new blockchain account should be insignificant in comparison. Fortunately, there is no need to create accounts for users already signed up by another application."
[https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md#accounts]

name::
* Mcs.Eos-account,
* Mcs.Eos-net'account,

generic-chain::
* blockchain-net'account,

name of Eos-account

description::
"On the EOS mainnet, account names are limited to 3 criteria by default. They must contain exactly 12 characters, consisting only of lowercase letters a through z, and numbers 1 through 5."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-net'account'name,

namespace of Eos-account

name::
* Mcs.Eos-net'account'namespace,

addressWpg::
* https://www.eoscanada.com/en/everything-you-need-to-know-about-namespace-bidding-about-eos,

EOS-token of Eos-account

description::
· the-aggregate EOS-tokens stored in an-account.

name::
* Mcs.Eos-net'account'EOS,
* Mcs.Eos-net'account'holdings,
* Mcs.Eos-net'account'stake,

permission of Eos-account

description::
"Here is a documentation that talks about accounts, permissions, and owner/active keys: https://developers.eos.io/eosio-nodeos/docs/accounts-and-permissions
The documentation is a bit technical. Basically the point is that an account has keys associated with it, and each key has a certain permission, i.e. a certain ability to do things with that account. For example you could generate a keypair and give it a permission so that it only has the ability to buy/sell RAM for your account, but not to transfer your coins. If you give the private key of this keypair to someone else they will be able to buy/sell RAM for your account, but they can't transfer your coins to another account. Kind of ridiculous, but hey it's just an example.
Anyone can make custom permissions that do whatever you want, but the owner and active permissions are standard permissions that every account has. The owner permission is the "root access" to your account; when someone has the private key for your owner permission, they can do anything with your account. The active permission is a little bit more restricted."
[https://www.reddit.com/r/eos/comments/8xce8z/what_are_active_and_owner_keys/]
===
"As EOSIO operates with an account structure - a new feature amongst blockchains - a user can assign a unique permission structure to their account to delegate authority over different functions. For example, this can be used to increase security around more sensitive actions, such as transferring tokens, while not being as worried about securing a private key that can only be used to interact with a specific on-chain game."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-net'account'permission,
* Mcs.Eos-net'permission,
* Mcs.Eos-permission,

permission.child

description::
"Child
Within the permissions structure of an account, owner is the top-level authority, with all other permissions being nested underneath it. Any permission nested under a permission heading is known as a child. By default, an EOS account will come with the active permission as a child to the owner permission."

name::
* Mcs.Eos-net'permistion.child,

key of Eos-account

description::
By default, all EOS accounts have two sets of keys: owner and active.

name::
* Mcs.Eos-net'account'key,

human of Eos-account (link)

getting Eos-account

name::
* Mcs.Eos-net'account'getting,
* Mcs.Eos-net'creating-account,

addressWpg::
* https://eos-account-creator.com/,
* https://support.get-scatter.com/article/33-creating-an-eos-account,
* https://everipedia.org/wiki/lang_en/everipedia-tutorial-english/#getting-an-eos-account,
* https://0x.games/creating-eos-account/,

Eos-account.AGGREGATE

name::
* Mcs.Eos-net'account.aggregate,

addressWpg::
* https://eospark.com/MainNet/,

Eos-account.PROXY

description::
"In the EOSIO software, proxies are accounts that participate in governance using voting power from other users."
[https://www.auroraeos.com/blog/an-overview-of-proxy-voting/]

name::
* Mcs.Eos-net'account.proxy,

addressWpg::
* list of proxies: https://www.alohaeos.com/vote/proxy,

asset of Eos-net

name::
* Mcs.Eos-net'asset,

generic-chain::
* blockchain-net'asset,

exchange-ogn of Eos-asset

name::
* Mcs.Eos-net'asset'exchange-organization,

generic-chain::
* exchange-organization--of--blockchain-asset,

resource of Eos-asset

addressWpg::
* {2018-10-28} New Protocol Lets EOS dApps ‘Teleport’ Tokens from Ethereum, https://www.ccn.com/new-protocol-lets-eos-dapps-teleport-tokens-from-ethereum/,

Eos-asset.AGGREGATE

name::
* Mcs.Eosn-net'asset.aggregate,

addressWpg::
* https://eospark.com/MainNet/,

Eos-asset.EOS-token

description::
· EOS is the-consensus-blockchain-asset of the-Eos-net.

name::
* Mcs.EOS,
* Mcs.EOS-mainnet-token,
* Mcs.Eos-net'EOS-token,

generic-chain::
* consensus-blockchain-asset,

EOS.INFLATION

description::
"The mechanism through which new tokens are created on the EOS mainnet. 20% of these are used to pay Block Producers and Standby Producers, with the remainder going into the eosio.saving account. Currently, inflation is set at 5%."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-inflation,
* Mcs.Eos-net'EOS.inflation,

addressWpg::
* https://www.eoscanada.com/en/inflation-on-eos-what-do-i-need-to-know,

EOS.STAKED

description::
"Tokens on the EOS network can have two states, delegated and undelegated. When a token is delegated, it provides an allocation of network resources for an account. You can delegate resources towards your own account, or to another account, using your tokens. (also known as stake)"
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-net'EOS.delegated,
* Mcs.Eos-net'EOS.staked,
* Mcs.Eos-net'staked-token,

EOS.STAKED.NO

description::
"Unstaked tokens are free to be moved around, transferred to another user, or used to make another account."
[https://www.eoscanada.com/en/voting-faqs]

name::
* Mcs.Eos-net'EOS.unstaked,
* Mcs.Eos-net'unstaked-token,

EOS.REFUND

description::
"When unstaking tokens, it takes 72 hours for a refund to be issued. Some block explorers will show the amount of tokens that are in the process of being released as ‘awaiting refund’."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-refund,
* Mcs.Eos-net'EOS.refund,

governance of Eos-net

description::
Governance is the process by which people reach consensus on subjective matters that cannot be captured entirely by software algorithms. An EOS.IO software-based blockchain implements a governance process that efficiently directs the existing influence of block producers. Absent a defined governance process, prior blockchains relied ad hoc, informal, and often controversial governance processes that result in unpredictable outcomes.
A blockchain based on the EOS.IO software recognizes that power originates with the token holders who delegate that power to the block producers. The block producers are given limited and checked authority to freeze accounts, update defective applications, and propose hard forking changes to the underlying protocol.
Embedded into the EOS.IO software is the election of block producers. Before any change can be made to the blockchain these block producers must approve it. If the block producers refuse to make changes desired by the token holders then they can be voted out. If the block producers make changes without permission of the token holders then all other non-producing full-node validators (exchanges, etc) will reject the change.
[https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md#governance]

name::
* Mcs.Eos-governance,
* Mcs.Eos-net'governance,

generic-chain::
* blockchain-net'governance,

constitution of Eos-net

description::
"Constitution
The EOS.IO software enables blockchains to establish a peer-to-peer terms of service agreement or a binding contract among those users who sign it, referred to as a "constitution". The content of this constitution defines obligations among the users which cannot be entirely enforced by code and facilitates dispute resolution by establishing jurisdiction and choice of law along with other mutually accepted rules. Every transaction broadcast on the network must incorporate the hash of the constitution as part of the signature and thereby explicitly binds the signer to the contract.
The constitution also defines the human-readable intent of the source code protocol. This intent is used to identify the difference between a bug and a feature when errors occur and guides the community on what fixes are proper or improper."
[https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md#constitution]

name::
* Mcs.Eos-constitution,
* Mcs.Eos-net'constitution,

addressWpg::
* https://github.com/EOS-Mainnet/governance/blob/master/eosio.system/eosio.system-clause-constitution-rc.md,

text of Eos-constitution

This Constitution is a multi-party contract entered into by the Members by virtue of their use of this blockchain.

Article I - No Initiation of Violence

Members shall not initiate violence or the threat of violence against another Member.
Lawful prosecution of crimes with the goal of preserving life, liberty and property does not constitute initiation of violence.

Article II - No Perjury

Members shall be liable for losses caused by false or misleading attestations and shall forfeit any profit gained thereby.

Article III - Rights

The Members grant the right of contract and of private property to each other, therefore no property shall change hands except with the consent of the owner, by a valid Arbitrator’s order, or via community referendum.
This Constitution creates no positive rights for or between any Members.

Article IV - No Vote Buying

No Member shall offer nor accept anything of value in exchange for a vote of any type, nor shall any Member unduly influence the vote of another.

Article V - No Fiduciary

No Member nor EOS token holder shall have fiduciary responsibility to support the value of the EOS token.
The Members do not authorize anyone to hold assets, borrow, nor contract on behalf of EOS token holders collectively.
This blockchain has no owners, managers or fiduciaries; therefore, no Member shall have beneficial interest in more than 10% of the EOS token supply.

Article VI - Restitution

Each Member agrees that penalties for breach of contract may include, but are not limited to, fines, loss of account, and other restitution.

Article VII - Open Source

Each Member who makes available a smart contract on this blockchain shall be a Developer.
Each Developer shall offer their smart contracts via a free and open source license, and each smart contract shall be documented with a Ricardian Contract stating the intent of all parties and naming the Arbitration Forum that will resolve disputes arising from that contract.

Article VIII - Language

Multi-lingual contracts must specify one prevailing language in case of dispute and the author of any translation shall be liable for losses due to their false, misleading, or ambiguous attested translations.

Article IX - Dispute Resolution

All disputes arising out of or in connection with this Constitution shall be finally settled under the Rules of Dispute Resolution of the EOS Core Arbitration Forum by one or more arbitrators appointed in accordance with the said Rules.

Article X - Choice of Law

Choice of law for disputes shall be, in order of precedence, this Constitution and the Maxims of Equity.

Article XI - Amending

This Constitution and its subordinate documents shall not be amended except by a vote of the token holders with no less than 15% vote participation among tokens and no fewer than 10% more Yes than No votes, sustained for 30 continuous days within a 120 day period.

Article XII - Publishing

Members may only publish information to the Blockchain that is within their right to publish.
Furthermore, Members voluntarily consent for all Members to permanently and irrevocably retain a copy, analyze, and distribute all broadcast transactions and derivative information.

Article XIII - Informed Consent

All service providers who produce tools to facilitate the construction and signing of transactions on behalf of other Members shall present to said other Members the full Ricardian contract terms of this Constitution and other referenced contracts.
Service providers shall be liable for losses resulting from failure to disclose the full Ricardian contract terms to users.

Article XIV - Severability

If any part of this Constitution is declared unenforceable or invalid, the remainder will continue to be valid and enforceable.

Article XV - Termination of Agreement

A Member is automatically released from all revocable obligations under this Constitution 3 years after the last transaction signed by that Member is incorporated into the blockchain.
After 3 years of inactivity an account may be put up for auction and the proceeds distributed to all Members according to the system contract provisions then in effect for such redistribution.

Article XVI - Developer Liability

Members agree to hold software developers harmless for unintentional mistakes made in the expression of contractual intent, whether or not said mistakes were due to actual or perceived negligence.

Article XVII - Consideration

All rights and obligations under this Constitution are mutual and reciprocal and of equally significant value and cost to all parties.

Article XVIII - Acceptance

A contract is deemed accepted when a member signs a transaction which incorporates a TAPOS proof of a block whose implied state incorporates an ABI of said contract and said transaction is incorporated into the blockchain.

Article XIX - Counterparts

This Constitution may be executed in any number of counterparts, each of which when executed and delivered shall constitute a duplicate original, but all counterparts together shall constitute a single agreement.

Article XX - Interim Constitution

This constitution is interim and is intended to remain in effect until a permanent constitution is written and ratified in a referendum.

voting of Eos-governance

description::
"With on-chain governance being at the forefront of EOSIO software, voting is a fundamental part of the system. The most widely used application of voting is to elect which Block Producers will actually produce blocks for the network. Voting will also be used to help collect the communal decisions through which we will change the course of the network - through referendums to alter the Constitution, to elect members to any boards that may form, and to vote things through the Worker Proposal System, amongst others."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-net'goverance'voting,
* Mcs.Eos-net'voting,
* Mcs.Eos-voting,

generic-chain::
* chain-net'voting,

cost of voting

description::
· nothing

name::
* Mcs.Eos-net'voting'cost,

vote-decay of voting

description::
"Vote Decay
To discourage users from casting a vote for Block Producers and then not updating their vote periodically, a decay in the relative vote strength of old votes was introduced. To maintain maximum vote strength, a user should vote at least once per week"
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-net'voting'decay-of-vote,

number-of-BP-you-can-vote

description::
"users can vote for up to 30 Block Producer Candidates at the same time."
===
"How does the voting work? If I vote for only 5 BPs does all my votes get equally divided between the 5
Your vote weight is the same if you voted for 1 or 30. It is best to vote on 30, it helps secure the network more. You can also use a vote proxy (like lukeeosproxy - Luke Stokes) to ensure your votes are going to the right candidates."
[https://eosdac.zendesk.com/hc/en-us/articles/360009852212-How-does-the-voting-work-If-I-vote-for-only-5-BPs-does-all-my-votes-get-equally-divided-between-the-5]

name::
* Mcs.Eos-net'voting'number-of-BP-you-can-vote,

aproval-voting

description::
"Approval Voting
There are many different ways to structure voting mechanisms in a society. EOSIO uses Approval Voting. Approval Voting is a system in which a voter can vote an equal weight towards multiple candidates. It allows for a much flatter distribution of votes due to the fact that an account can vote for 1 to 30 different Block Producers, versus if each account could only select a single candidate."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-net'voting.aproval,

tool for voting

name::
* Mcs.Eos-net'voting'tool,

addressWpg::
* https://bloks.io/,
* https://eosc.app/,
* https://eosrio.io/simpleos/,
* https://github.com/greymass/eos-voter,

time of voting

description::
* "How often votes are counted when voting for blockproducers?
Votes are calculated every 2 minutes and 6 seconds. There is no stop to the voting process in EOS"
[https://eosdac.zendesk.com/hc/en-us/articles/360010098231-How-often-votes-are-counted-when-voting-for-blockproducers-]
* "How often should I vote for a blockproducer?
You can vote for your favorite block producers as often as you'd like. Once you vote your vote will be valid for as long as you change it or remove it. To keep your support strong it is advisable to vote every week as voting power decays gradually by about 1% every week and diminishes completely over the course of 2 years."
[https://eosdac.zendesk.com/hc/en-us/articles/360010097931-How-often-should-I-vote-for-a-blockproducer-]
* "When will voting end?
There is no end date on voting. You can vote and change your vote as many times you want. Votes will keep being accepted as long as EOS network is available (forever)."
[https://eosauthority.com/voting]

name::
* Mcs.Eos-net'voting'time,

resource of voting

name::
* Mcs.Eos-net'resource.voting,
* Mcs.Eos-net'voting'resource,

addressWpg::
* https://www.auroraeos.com/blog/voting-guide/,
* https://coincentral.com/how-to-vote-for-an-eos-block-producer/,
* https://eosauthority.com/voting,
* https://votetracker.io/,
* https://www.eoscanada.com/en/how-is-your-vote-strength-calculated-on-eos,
* {2018-10-02} Ana-Berman, EOS Developer Acknowledges Claims of ‘Collusion’ and ‘Mutual Voting’ Between Nodes, https://cointelegraph.com/news/eos-developer-acknowledges-claims-of-collusion-and-mutual-voting-between-nodes,
* {2018-10-01} https://www.ccn.com/block-one-vows-to-use-its-eos-tokens-to-prevent-voting-cartels/,
* https://thenextweb.com/hardfork/2018/10/01/eos-voter-corruption-huobi/,

voting.PROXY

description::
"What is Proxy voting?
A proxy is someone who you delegate your voting power and authority to vote on your behalf. Once a user registers as proxy, other users can delegate their voting power to the proxy. You votes then directly go the the candidates your proxy votes for."
[https://eosdac.zendesk.com/hc/en-us/articles/360010098111-What-is-Proxy-voting-]

name::
* Mcs.Eos-net'voting.proxy,

proxy-account (link)

arbitration of Eos-governance

description::
"Arbitration
A means of dispute resolution. Arbitration is performed by an arbitrator, who belongs to an Arbitration Forum. Arbitration is a recognized method of dispute resolution in 159 countries around the world. Within EOS, the default Arbitration Forum is the EOS Core Arbitration Forum (ECAF). Users and developers are free to name and use other Arbitration Forums, however this is the current default forum."
[https://www.eoscanada.com/en/abc-eos]
===
"Arbitration is a way of resolving disputes without going to court. Both parties in the dispute present their side to a professional arbitrator who thoroughly reviews the dispute and comes to a reasonable resolution."
[https://eoscorearbitration.io/faq/]

name::
* Mcs.Eos-arbitration,
* Mcs.Eos-net'arbitration,
* Mcs.Eos-net'dispute-resolution,

addressWpg::
* https://eoscorearbitration.io/,
* {2018-11-20} Aurora-EOS, https://medium.com/aurora-eos/against-mandatory-arbitration-on-eos-32334ba3af9f,

ECAF of Eos-governance

description::
"ECAF - EOS Core Arbitration Forum
EOS Core Arbitration Forum; the default arbitration forum for the EOS Mainnet. It is named in the current Constitution in Article IX. Users and developers are free to name and use other Arbitration Forums, however this is the current default forum."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-ECAF,
* Mcs.Eos-net'ECAF,
* Mcs.Eos-net'EOS-Core-Arbitration-Forum,

addressWpg::
* https://eoscorearbitration.io/,

referendum of Eos-governance

description::
"Referendums are used to poll a community to discover a communal opinion on a topic/question. As a 'governed blockchain', users use their stake to vote on proposals. The current referendum contract - eosio.forum - was written by EOS Canada."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-referendum,
* Mcs.Eos-net'governance'referendum,

worker-proposal-system of Eos-governance

description::
"WPS - Worker Proposal System
A system through which communal funds would be used to support chain-enhancements, community projects, and anything that the community felt was deserving of public funding. It is set up to be funded through a portion of inflation."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-worker-proposal-system,
* Mcs.Eos-net'governance'worker-proposal-system,
* Mcs.Eos-net'governance'WPS,

resouce of Eos-governance

name::
* Mcs.Eos-governance'resource,
* Mcs.Eos-net'resource.governance,

addressWpg::
* https://github.com/EOS-Mainnet/governance,
===
* {2018-06-20} Daniel-Larimer, Decentralized Blockchain Governance, https://medium.com/@bytemaster/,

program of Eos-net

name::
* Mcs.Eos-net'program,
* Mcs.Eos-program,

generic-chain::
* blockchain-net'program,

addressWpg::
* Directory of Projects based around EOS: eosindex.io,
* https://eosprojects.org/projects/,

Eos-program.SPECIFIC

specific::
* EOS.IO-software,
* application-of--Eos-net,
* smart-contract-of--Eos-net,

program.EOSIO-software of Eos-net

description::
EOS.IO software enables developers to create and deploy high-performance, horizontally scalable, blockchain infrastructure upon which decentralized applications can be built.
[https://github.com/eosio/eos]

name::
* Mcs.EOS.IO-software,
* Mcs.EOSIO-software,
* Mcs.Eos-client,
* Mcs.Eos-net'client,
* Mcs.Eos-net'EOSIO-software,

installing Eos-client

name::
* Mcs.Eos-client'installing,
* Mcs.Eos-net'EOSIO'installing,

addressWpg::
* https://github.com/EOSIO/eos/releases,
* https://developers.eos.io/eosio-home/docs,
* https://developers.eos.io/eosio-nodeos/docs/docker-quickstart,

eosd of Eos-client

description::
eosd
The core EOS daemon that can be configured with plugins to run a node.
Example uses are block production, dedicated API endpoints and local development.
[https://github.com/EOSIO/eos/wiki/Programs-&-Tools#eosd]

name::
* Mcs.eosd,
* Mcs.Eos-net'EOSIO'eosd,

eosc of Eos-client

description::
eosc is a command line tool that interfaces with the REST api exposed by eosd.
In order to use eosc you will need to have the end point (IP address and port number) to an eosd instance and also configure eosc to load the 'eosio::chain_api_plugin'.
eosc contains documentation for all of its commands.
[https://github.com/EOSIO/eos/wiki/Programs-&-Tools#eosc]

name::
* Mcs.eosc,
* Mcs.Eos-net'EOSIO'eosc,

resource of Eos-client

name::
* Mcs.Eos-client'resource,
* Mcs.Eos-net'EOSIO'resource,

addressWpg::
* repository: https://github.com/eosio/eos,
* documentation: https://eosio.github.io/eos/,
* wiki: https://github.com/eosio/eos/wiki,
===
* https://www.eoscanada.com/en/abc-eos,
===
* {2018-06-02} EOSIO 1.0 Release, https://block.one/news/eosio-1-0-release/,
* https://forums.eosgo.io/categories/developers,
* https://steemit.com/@eosphere,

GENERIC of Eos-client

generic-chain::
* blockchain-client,

name::
* Mcs.Eos-net'EOSIO'generic,

program.smart-contract of Eos-net

description::
Each account can send structured messages to other accounts and may define scripts to handle messages when they are received.
The EOS.IO software gives each account its own private database which can only be accessed by its own message handlers.
Message handling scripts can also send messages to other accounts.
The combination of messages and automated message handlers is how EOS.IO defines smart contracts.
[https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md#messages--handlers]

name::
* Mcs.Eos-contract,
* Mcs.Eos-net'contract,
* Mcs.Eos-net'smart-contract,
* Mcs.Eos-program.smart-contract,
* Mcs.Eos-smart-contract,
* Mcs.smart-contract.Eos,

generic-chain::
* smart-contract,

addressWpg::
* wiki: https://github.com/EOSIO/eos/wiki/Smart%20Contract,
=== examples:
* https://github.com/kesar/eos-awesome-contracts/,
* https://github.com/EOSIO/eos/tree/master/contracts,
===
* {2018-12-13} Daniel-Larimer, Developing Efficient Contracts, https://medium.com/@bytemaster/developing-efficient-contracts-8a8e62011c6d,
* {2017-07-13} https://steemit.com/eos/@dan/eos-example-exchange-contract-and-benefits-of-c,

Ricardian-contract of smart-contract

description::
"A human readable contract that defines the intention of the associated smart contract written in a computer scripting language. According to Article 7 of the Constitution, all smart contracts on the EOS blockchain must also have a Ricardian Contract."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-net'smart-contract'Ricardian-contract,
* Mcs.Eos-Ricardian-contract,

addressWpg::
* https://www.eoscanada.com/en/introduction-to-ricardian-contracts,

smart-contract.SUDO

description::
"Sudo is a short-hand term based on the name of a Linux command that means 'super user do,' which is used to obtain elevated privileges when running a command. In EOSIO, 15 of 21 Block Producers can sign a transaction on behalf of a user. To simplify this process, a sudo contract was created to reduce the amount of individual steps needed to coordinate amongst the Block Producers. It has been deployed to the network under the account eosio.wrap."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-net'smart-contract.sudo,

program.application of Eos-net

name::
* Mcs.Dapp.Eos-net,
* Mcs.Eos-app,
* Mcs.Eos-Dapp,
* Mcs.Eos-net'Dapp,
* Mcs.Eos-program.application,

generic-chain::
* blockchain-net'Dapp,
* chain-net'Dapp,

addressWpg::
* https://eosindex.io/posts/tags/Dapp,
===
* {2018-08-08} Christoph-Michel, Learnings from building my first dapp on EOS blockchain, https://cmichel.io/releasing-my-first-eos-dapp/,
* {2018-06-14} Infinite-X-Labs, THE ULTIMATE END-TO-END EOS DAPP DEVELOPMENT TUTORIAL – PART 2, https://infinitexlabs.com/eos-development-tutorial-part-2/,
* {2018-02-12} Bitfinex, Announcing EOSfinex: Bitfinex to Build High Performance Decentralized Exchange on the EOS.IO Platform, https://medium.com/bitfinex/,
* {2017-09-12} https://steemit.com/eos/@eosio/introducing-eos-io-application-stack,

Eos-Dapp.SPECIFIC

name::
* Mcs.Eos-net'Dapp.specific,

generic-chain::
* blockchain-net'Dapp,

specific::
* https://dappradar.com/eos-dapps,
===
* GAME,
* GAMBLING,
* EXCHANGE,
===
* Everipedia,

Eos-Dapp.GAME

name::
* Mcs.Eos-Dapp.game,
* Mcs.Eos-net'Dapp.game,

specific::
* EOS-Poker: https://eospoker.win/,

wallet of Eos-net

name::
* Mcs.Eos-net'wallet,
* Mcs.Eos-wallet,

generic-chain::
* blockchain-net'wallet,

addressWpg::
* https://unhashed.com/cryptocurrency-terms-faq/best-eos-wallets/,
* https://coinswitch.co/news/top-5-eos-wallets,
===
* https://get-scatter.com/,
* https://guarda.co/,
* https://www.exodus.io/,
* http://eoslynx.com/,

human of Eos-net

name::
* Mcs.Eos-human,
* Mcs.Eos-net'human,

generic-chain::
* blockchain-net'human,

addressWpg::
* https://medium.com/@eosio,
* https://steemit.com/@eosio,
* https://forums.eosgo.io/,

specific::
* user,
* operator,
* developer,
===
* Brendan-Blumer: CEO
* Daniel-Larimer, CTO: https://medium.com/@bytemaster
* Kokuei-(Guo)-Yuan: President
* Greg-Lee, VP of Engineering: https://medium.com/@greg_80499
* Wendy-Lee: CLO
* Thomas-Cox, VP of Product: https://medium.com/@thomas.cox_39839
* Andrew-Bliss: CFO
* Michael-Cao: partner
* Ian-Grigg: partner
* Brock-Pierce: partner
* Li-Xiao Lai: partner
* Bo-Shen: partner

Eos-human.AGGREGATE

name::
* Mcs.Eos-community,
* Mcs.Eos-human.aggregate,

Eos-human.BLOCK-PRODUCER

name::
* Mcs.Eos-block-producer-human,
* Mcs.Eos-human'block-producer,

doing::
=== provide infrastracture:
With the EOS.IO software, we, at block.one, envision a world where block producers provide general purpose infrastructure that allows developers to build and deploy their applications without having to run any servers themselves. This includes applications as complex as steemit, DTube, and decentralized exchanges.
[https://steemit.com/eos/@eosio/introducing-eos-io-application-stack]

Eos-human.TOKEN-HOLDER

description::
· Eos-token-holder is any human who holds EOS-tokens.
· in other words, s|he controls an-account.
· an-account could-have MANY owners.
· a-human could-owns MANY accounts.

name::
* Mcs.Eos-account-owner,
* Mcs.Eos-human'token-holder,
* Mcs.Eos-member,
* Mcs.Eos-net'account'owner,
* Mcs.Eos-net'human.token-holder,
* Mcs.Eos-net'token-holder,
* Mcs.Eos-token-holder,
* Mcs.Eos-user,

Eos-human.VOTER

description::
· voter is an-token-holder with staked-tokens.

name::
* Mcs.Eos-voter,

Eos-human.WHALE

description::
· Eos-whale is any-human that owns account|s with very large EOS-token quantities.

name::
* Mcs.Eos-whale,
* Mcs.Eos-net'human.whale,

Eos-human.Larimer.Daniel

description::
Daniel Larimer is a software programmer.[1] Larimer created the cryptocurrency platform BitShares (2014), was co-founder of the blockchain social platform Steemit (2016), and is CTO of EOS, with the company block.one (2017).
[https://en.wikipedia.org/wiki/Daniel_Larimer]

name::
* Mcs.Daniel-Larimer.human,
* Mcs.Larimer.Daniel.human,
* Mcs.human.Larimer.Daniel,

addressWpg::
* http://bytemaster.github.io/,
* https://medium.com/@bytemaster,
* https://steemit.com/@dan,
* https://steemit.com/@dantheman,
* https://en.wikipedia.org/wiki/Daniel_Larimer,
* https://www.steem.center/Dan_Larimer,
===
* {2017-09-04} Historical Facts about Daniel Larimer and his Contributions to the Blockchain Industry: https://steemit.com/eosio/@xeroc/,
* {2017-06-11} Leah Stella Stephens, DAN LARIMER: Visionary Programmer of BitShares, Steem and EOS: https://hackernoon.com/,
* {2016-11-14} Grand Unified Political Theory - Anarchy, Libertarianism, Capitalism, and Socialism: https://steemit.com/basicincome/@dantheman/,

organization of Eos-net

name::
* Mcs.Eos-net'organization,
* Mcs.Eos-organization,

generic-chain::
* blockchain-net'organization,

Eos-ogn.Block.one

description::
"2. Who is building the EOS.IO Software?
block.one, a Cayman Islands exempted company, is building the EOS.IO Software. With employees and advisors based around the world, the company focuses on business-grade technology solutions, including blockchain software development."
[https://eos.io/faq.html]
===
"Block.one is the company that created the EOSIO software. The CEO is Brendan Blumer and the CTO is Daniel Larmier. Block.one held the largest and longest ICO in history, lasting 350 days, and raising over $4 Billion USD. They have committed $1 Billion USD towards Venture Capital firms who will help to build technologies that leverage the EOSIO software."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Block.one,
* Mcs.Eos-net'Block.one,

generic-chain::
* company,

addressWpg::
* https://block.one/,

human of Block.one

specific::
* Brendan-Blumer​, CEO,

evaluation of Eos-net

name::
* Mcs.Eos-evaluation,
* Mcs.Eos-net'evaluation,

addressWpg::
=== CON:
* {2018-12-07} Arjun-Balaji, Why do we take EOS seriously when it’s clearly a plutocracy?, https://www.theblockcrypto.com/2018/12/07/why-do-we-take-eos-seriously-when-its-clearly-a-plutocracy/,
* {2018-06-07} https://twitter.com/plaincrypt/status/1004559742847541253,
* {2018-04-30} matteoleibowitz, EOS: Don’t Believe The Hype, https://medium.com/@matteoleibowitz/,

evaluation.PRO

description::
"It’s the most user-friendly blockchain platform, with features like
* human-readable account names,
* customizable account permissions,
* zero individual transaction fees,
* high-throughput,
* low latency,
* deferred transactions, and more."
[https://www.theblockcrypto.com/2018/12/21/eos-is-a-dao/]

name::
* Mcs.Eos-net'evaluation.pro,

pro.mobile-use

description::
"The ecosystem that’s been built around mobile use for EOS is far more advanced than most onlookers recognize: you can use a mobile wallet to send tokens, play games, trade on a DEX, and more, signing all transactions with TouchID, on EOS today. The user experiences built on EOS are far and away the best of blockchain-based applications."
[https://www.theblockcrypto.com/2018/12/21/eos-is-a-dao/]

name::
* Mcs.Eos-net'evaluation.pro.mobile-use,

evaluation.CON

description::
· vote control:
"As creators, Block.one actually own enough EOS to control 25 percent of votes, raising significant conflict of interest concerns – not to mention if this centralizes any decision making."

name::
* Mcs.Eos-net'evaluation.con,
* Mcs.Eos-net'evaluation.proNo,

resource of Eos-net

Name::
* Mcs.Eos-net'resource,
* Mcs.Eos-resource,

addressWpg::
* https://eos.io/,
* https://github.com/eosio,
* https://developers.eos.io/,
* https://www.eosdocs.io/,
* https://www.eosdocs.io/resources/,
===
* https://github.com/EOSIO/eos/wiki,
* https://eosio.stackexchange.com/,
* http://www.blocktivity.info/,
* https://eosprojects.org/,
* starter guide: https://kylin.eosx.io/guides/welcome,
===
* {2018-05-05} Daniel-Larimer, Introducing EOSIO Dawn 4.0, https://medium.com/@bytemaster/,
* {2018-02-13} https://steemit.com/eos/@eosio/the-eos-io-blog-has-moved,
* {2017-07-05} Ian-Grigg, EOS - An Introduction: http://iang.org/papers/EOS_An_Introduction.pdf,
* {2017-05-24} Introduction to EOS: the Epic (blockchain) Operating System, https://steemit.com/eos/@trogdor/,
=== development:
* {2017-06-18} https://steemit.com/eos/@dantheman/web-assembly-on-eos-50-000-transfers-per-second,

DOING of Eos-net

name::
* Mcs.Eos-doing,
* Mcs.Eos-net'doing,

generic-chain::
* blockchain-net'doing,

ENVIRONMENT of Eos-net

name::
* Mcs.Eos-net'environment,

relation-to--Ethereum-net of Eos-net

name::
* Mcs.Eos-net'relation-to--Ethereum-net,

addressWpg::
* {2018-03-25} Ian-Macalinao,The Cryptoeconomics of EOS vs Ethereum: https://medium.com/texascrypto/,

oracle of Eos-net

description::
"An oracle is a system that makes off-chain data available on-chain. An example of this would be an oracle that takes the score of a basketball game and puts it on-chain for smart contracts to consume and base decisions on."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-net'oracle,
* Mcs.Eos-oracle,

GENERIC of Eos-net

Generic-chain::
* blockchain-network,
* chain-network,
...
* entity,

Eos-net.SPECIFIC

name::
* Mcs.Eos-net.specific,
* Mcs.Eos-netAsSpecific,

specific::

Eos-net.MAINNET

description::
"The main EOSIO blockchain. As the EOSIO software is open source and freely available, there can be many instances of it. The first one to be spun up for public usage was the one with chain ID: aca376f206b8fc25a6ed44dbdc66547c36c6c33e3a119ffbeaef943642f0e906."
[https://www.eoscanada.com/en/abc-eos]

name::
* Mcs.Eos-mainnet,
* Mcs.Eos-net.mainnet,

addressWpg::
* info: https://bloks.io/chain,

Eos-net.PUBLIC-TESTNET

description::
Differences between Testnet and Mainnet
There are several differences between the Public Testnet and the public Mainnet. As of this writing, they include:
* Existence. The public mainnet doesn't exist yet, and the public testnet does.
* Genesis block. The mainnet genesis block is different from the testnet genesis block. The Testnet genesis block includes a faucet account and several "initx" accounts (inita - initu) used by the core development team during testing. At least some of these initx accounts are also present in the provided genesis block of standalone private testnets.
* Resets. The Testnet is subject to resets as needed to support testing.
* Versions. The Testnet can actually include multiple testnets with different addresses and different reset cycles, depending on the needs and desires of the development community.
* Hosting. The Testnet is currently configured such that block-producing nodes will only be run on hosts set up and operated by the core developers. The Mainnet's block producing nodes will run on hosts selected by a vote of the token holders.
[https://github.com/EOSIO/eos/wiki/Testnet%3A%20Public#differences-between-testnet-and-mainnet]

name::
* Mcs.Eos-net.public-testnet,
* Mcs.Eos-net.testnet.public,

Eos-testnet.JUNGLE

name::
* Mcs.Eos-Jungle-testnet,
* Mcs.Eos-net.testnet.Jungle,

addressWpg::
* http://jungle.cryptolions.io/,

Eos-net.SIDECHAIN (Eos-token)

description::
"Sidechains are EOSIO blockchains that utilize the EOS mainnet token for resource allocation (access to bandwidth, RAM, etc)."
[https://www.getrevue.co/profile/auroraeos/issues/sidechains-and-sister-chains-on-eos-an-explainer-142851]

name::
* Mcs.Eos-net.sidechain,
* Mcs.Eos-sidechain,

Eos-net.SISTER-CHAIN (Own-token)

description::
"Sister chains are blockchains that utilize the EOSIO software but that have their own native token used for resource allocation."
[https://www.getrevue.co/profile/auroraeos/issues/sidechains-and-sister-chains-on-eos-an-explainer-142851]

name::
* Mcs.Eos-net.sister-chain,
* Mcs.Eos-sister-chain,

Eos-net.EVOLUTING

name::
* Mcs.Eos-net.evoluting,

{time.2018-06-14}::
=== LAUNCH:
At press time the EOS blockchain has received over 169,000 votes (16.933%) that determines the group of ‘block producers’ that will be tasked with maintaining the EOS network. The successful launch comes as a relief to EOS investors after a nervously slow voting process.
The complex voting system caused worries that EOS holders were apathetic as voters, which could have resulted in votes never exceeding the critical 15% threshold. However, at approximately 18:45 UTC the 15% threshold was met and the 21 temporary and random BPs have been replaced with the 21 officially elected BPs.
[{2018-06-14} John-Medley, EOS Is Officially Live as 15% Voting Threshold Is Met, https://www.cryptoglobe.com/]

{time.2017-06-26}::
=== EOS-Ethereum-token:
To date, block.one, the developer of the software that runs the EOS blockchain (short EOS), a new blockchain operating system designed to support commercial-scale decentralized applications, has successfully received multiple hundred millions worth of ETH in connection with its ongoing distribution of EOS ERC-20 compatible tokens on the Ethereum blockchain which began on June 26, 2017.
[https://steemit.com/eosio/@xeroc/historical-facts-about-daniel-larimer-and-his-contributions-to-the-blockchain-industry]

meta-info

this page was-visited times since {2018-02-18}

page-path: synagonism.net / Mcs-worldview / dirTchInf / Eos-network

SEARCH::
· this page uses 'locator-names', names that when you find them, you find the-LOCATION of the-concept they denote.
LOCAL-SEARCH:
· TYPE CTRL+F "Mcs.words-of-concept's-name", to go to the-LOCATION of the-concept.
GLOBAL-SEARCH:
· clicking on the-green-TITLE of a-page you have access to the-global--locator-names of my-site.
· a-preview of the-description of a-global-name makes reading fast.

footer::
• author: Kaseluris.Nikos.1959
• email:
 imgMail
• twitter: @synagonism
• steemit: https://steemit.com/@synagonism,
• github: https://github.com/synagonism/Mcsw/blob/master/dirTchInf/filMcsDtcbnetEos.last.html,

webpage-versions::
• version.last.dynamic: FilMcsDbcnetEos.last.html,
• version.0-1-0.2018-02-18.draft-created:

support (link)

comments

specific::
* on Disqus,
* on Steemit,