Eos. IO Technical white Paper V2__eos

EOS. IO Technical White Paper v2

This document is translated by Wang Tao, Minghua, Shang, Li Xiaoyu, brisk violet, Chen Weixian, Zhaoyu, and two other unnamed people, and the final manuscript is by Wang Fan revisers, thank you.

Summary: EOS. The IO software adopts a new design block chain architecture, which realizes the horizontal and vertical extension of the central application. The specific approach is to build a class operating system architecture where developers can build applications. Eos. IO software provides cross CPU across clusters of account systems, authentication, databases, asynchronous communications, and support for scheduling between applications. The technology used to achieve these characteristics is a specific block chain architecture that can be extended to deal with millions transactions per second in a controlled block chain environment, eliminating user fees, and allowing for rapid and easy deployment and maintenance of central applications.

Please note: The cryptographic tokens mentioned in this paper refer to the use of EOS. The encrypted tokens on the block chain released by the IO software, rather than the ERC-20 compatible tokens that are distributed on the Ethernet block chain and are related to the distribution of EOS tokens.

Copyright ©2018 Block.one

The contents of this white paper are not authorized and can be reproduced or distributed for non-commercial or educational purposes only by stating the original source and applying the copyright notice, but not for charges or commercial purposes.

Disclaimer: This EOS. The IO technical white Paper version 2.0 is available only for informational purposes. Block.one does not guarantee the accuracy of the contents or conclusions of the white Paper, for informational purposes only. Block.one will not make, and expressly deny, all the express or implied statutory or other forms of declaration and warranty, including but not limited to: (i) warranties of merchantability, fitness for a particular purpose, suitability, use, title and non-infringement; (ii) there is no warranty of error in this white paper (iii) The contents of this white paper will not infringe upon the rights of third parties. Block.one and its subsidiaries shall not be liable for any loss caused by the use, reference or trust of the content contained in this white paper and this statement, even if the damage may have been cautioned. Any person or entity who, by reason of the use of the content contained in this white paper and this statement, any damage, loss, liability, cost or expense, whether direct or indirect, as a result, as compensation, incidental, actual, disciplinary, punitive, or specific, arising out of any form of reference, or trust, including but not limited to any business, income, profit, data, utility, goodwill or other intangible loss, Block.one or its subsidiaries shall not be liable under any circumstances. background

With the birth of Bitcoin, block-chain technology came out in 2008, since then, entrepreneurs and developers have been trying to make the block chain technology universal, in order to achieve in a single block chain platform for the application of the central to the broader support.

Among the many competing implementations of the block chain platform that can be applied to the central application, some of the block chains for specific application scenarios stand out and are widely used, attracting tens of thousands of users. For example go to the Central Exchange Bitshares (2014) and social media platform Steem (2016). Similar projects are accepted by many users because they not only improve performance so that they can handle up to thousands of transactions per second, shorten the confirmation time to 1.5s and eliminate transaction costs, while providing a user experience comparable to existing central services.

However, more existing block chain platform (use) requires high transaction costs, and computational capacity is limited, these are obstacles to block chain technology is more widely accepted and use of factors. requirements for application of block chain

To achieve a wider application, the application on the block chain requires a flexible platform that meets the following requirements: support millions users

Competing with companies such as Ebay, Uber, AirBnB and Facebook, block-chain technology should be able to handle millions's active users. In some scenarios, applications are useless unless the user reaches an extremely large order of magnitude. Therefore, a platform that can support a fairly large number of users is critical. free use

Application developers need enough flexibility to provide users with free services, and users should not pay for the benefits of using the platform or from services on the platform. Free use of the block chain platform will be more popular, developers and businesses can also create more effective profit strategy. Easy upgrades and Bug fixes

Applications based on commercial block chains need flexibility to support the addition of new features, so the platform itself must support upgrades of software and smart contracts.

As long as the software reaches a certain scale, it must be a bug, even if the adoption of strict verification is no exception. So the platform must be robust enough (robust) and support fixing the inevitable bugs. Low Latency

A good user experience requires reliable feedback in a few seconds. High delay will not only upset users, but also lead to the application of the block chain based on the competitiveness of the existing central application. Therefore, the platform needs to support low latency transactions. Timing Performance

Because of the sequential dependencies of the execution steps, some applications cannot be implemented using concurrent algorithms. For example, an exchange would need enough timing performance to handle high volumes. Therefore, the platform needs to have high timing performance. Concurrency Performance

Large-scale applications need to allocate work to multiple CPUs and computers, so the platform needs built-in concurrency support. consensus algorithm (BFT-DPOS)

Eos. The IO software adopts the algorithm of Authorization entrustment (DPOS), and only the algorithm is proved to meet the performance requirements of the application on block chain. According to this algorithm, all token holders on the EOS block chain can select the block producers through a continuous voting system. Want to participate in block production, as long as can persuade the token holder to vote for themselves, the final (the highest votes of those nodes) was selected as a block producer.

Eos. The IO software can produce exactly one block every 0.5 seconds, and only one producer is entitled to the production block at any one time. If there is no block build within the scheduled time, the block is skipped. Correspondingly, when one or more blocks are skipped, there is a time interval greater than or equal to 0.5 seconds in the block chain.

Use EOS. IO software, each round generates 126 blocks (a total of 21 block producers, each with a specific producer responsible for generating 6 blocks, i.e. one round of time for 63 seconds). At the beginning of each round, 21 different block producers were elected according to the vote of the holder of the token. The production order of the selected producers is unanimously decided by 15 or more producers.

If a producer misses a block and does not produce any block in the last 24 hours, it is removed from the producer's list until he informs the block chain that he intends to start production again. This approach can eliminate unreliable producers to minimize the number of missed chunks, thereby ensuring smooth operation of the network.

Under normal circumstances, dpos block chains do not produce any bifurcation, as producers produce blocks in the form of cooperation rather than competition. If bifurcation is present, the consensus approach is to automatically switch to the longest chain. The principle is that the added speed of a new block on the fork of a block chain is directly related to the amount of producers who agree on the bifurcation. In other words, the number of forks in a producer is growing faster than that of a producer with fewer forks, because the number of forks that many producers are missing is often less.

In addition, no block producers should compete on two forks at the same time. If a piece of producer is found to do so, it may be voted out. This dual production will leave cryptography evidence, so it is feasible to identify and automatically remove the producers of such blocks.

The DPOS algorithm, which adds Byzantine fault-tolerant mechanisms, requires all the producers to sign all blocks, but prohibits the same manufacturer from signing two timestamps or heights of the same block. Once a block is signed by 15 producers, the block can be considered irreversible. Once any producer signs two blocks of the same timestamp or the same block height, this dishonest behavior will leave a cryptographic evidence. Under this model, the irreversible consensus will be reached within 1 seconds. Transaction Confirmation

In a typical block chain based on dpos consensus algorithm, the block producer will have 100% participation degree. After an average of 0.25 seconds after the broadcast, a transaction can be 99.9% sure the deal is irreversible.

and EOS. In addition to the Dpos consensus algorithm, IO software also introduces asynchronous Byzantine fault-tolerant (ABFT), allowing transactions to reach an irreversible state faster, in 1 seconds 100% to determine the transaction reached an irreversible state. transaction as proof of interest (Tapos)

Eos. IO software requires that each transaction must include a partial hash of the nearest chunk header. This hash value has two purposes:

1. Prevent one transaction from being broadcasted on another fork that does not contain the transaction.

2. Inform the entire network that a particular user and his interests exist on a particular fork.

In this way, forging a counterfeit chain will become very difficult because the forger cannot migrate the transactions in the legal chain to the counterfeit chain. Account System

Eos. IO software stipulates that all accounts are identified by a unique name, with a maximum length of 12 characters. The name is specified by the creator of the account. The account creator must reserve RAM using the EOS token to store the new account until the new account pledges its own tokens to reserve its own RAM.

In the context of going to the center, the application developer will pay the account creation fee symbolically when the new user registers. Traditional enterprises for the acquisition of customers, has been advertising, free services and other forms for each user to spend a lot of money. By contrast, the cost of creating a new block-chain account is negligible. But fortunately, if a user has created an account while registering another application, there is no need to create it again. Operations (actions) and handlers

Each account can send structured actions (actions) to other accounts, and the program code can be defined to handle the actions received. Eos. IO software provides its own private database for each account and can only be accessed by the Operation handler (action Handler) of the account. An action handler can also send an operation to another account. The combination of operations and automated action handlers is the way Eos.io defines smart contracts.

To support concurrent execution, each account can define any number of scopes within its database. Block producers arrange transactions in this way so that transactions do not conflict with the scope's memory access, so transactions can be executed concurrently. role-based Privilege Management

Rights management includes confirming that an operation is properly authorized. The simplest privilege management is to check that the transaction has the required signature, which also means that the required signature is known. Generally speaking, authorization involves individuals or groups and is often categorized. Eos. IO Software provides a declarative rights management system that allows fine-grained, high-level control over accounts to determine who can do what.

Authentication and permissions management must be standardized and separate from the business logic of the application, which is critical. This allows development tools to manage permissions in a common way and provide significant space for optimizing performance.

Each account can be controlled by a combination of other accounts and private keys. This creates a hierarchical authority structure that truly reflects the organization of the right in the real world, and makes it easier for multiuser accounts to control than ever before. Multi-user control is the most important to enhance security. If used properly, it will greatly reduce the risk of theft caused by hacker attacks.

Eos. IO software allows an account to define what kind of account and key combination can send a specific operation to another account. For example, you can use one key to access a user's social media account and another key to access the exchange. You can even authorize other billing Shalai to operate on behalf of this account without having to assign keys to other accounts. named permission level

Account by using EOS. IO software, you can define the level of named permissions, and each permission level can derive from higher-level naming permissions. Each named permission level defines a permission. A permission is a multiple-signature threshold Check that consists of the key and/or naming permission levels of other accounts. For example, you can set a "friend" permission level for an operation on an account that has the same level of control over the operation as a friend of that account.

Another example is the Steem area chain, which has three hard-coded named permission levels: Owner, active, and posting. Posting permissions can only perform social operations such as polling and publishing, and active permissions may perform all operations except changing the owner. Owner permission should be stored cold, it can do everything. Eos. IO promotes this concept by allowing each account owner to customize the permission level and the grouping of operations. Permission Mappings

Eos. IO software allows each account to define a mapping from a contract/operation or other account contract to its own named permission level. For example, an account holder can map his social media application to the "Friends" permission group of the account owner. With this mapping, any friend of the account can publish information as an account owner in social media. Although these friends can publish information as account owners, they still use their own keys to sign. This means that it is always possible to determine which friends are using the account in any way.

Permission Assessment

When you send an action of type "action" from the account @alice to the @bob, EOS. The IO software first checks whether the @alice is @bob. groupa.subgroup.Action defines the permission mappings. If no results are found, the @bob. Groupa.subgroup is checked, and then the @bob. Groupa is checked, and the @bob is finally checked. If no further matches are found, the mapped named permission Group is assumed to be @alice. Active.

Once the mapped naming permission is determined, the signature is validated with a multiple signature threshold and the permissions associated with the named permission are obtained. If it fails, it traverses the parent class permission, and finally traverses the owner's permission, that is, @alice.owner. Default permission Group

Eos. The IO software assigns two default permission groups to all accounts. One is the "owner" permission group, and you can perform any action. There is also an "active" permission group that can perform all actions in addition to changing the owner permission group. All other permission groups are derived from the "active" group. Concurrent Evaluation Permissions

The permission evaluation process is read-only, and the update transaction for the permission is not effective until it is packaged into the block. This means that all key and privilege evaluations for all transactions can be performed concurrently. In addition, this also shows that fast permission validation is feasible and does not require expensive application logic to be started (and rollback of application logic when validation fails). Finally, this means that the transaction authority can be evaluated when the transaction is to be processed and no reassessment is required when the pending transaction is processed.

On the whole, permission validation accounts for a large portion of the calculation required for transaction validation. Allowing the permission validation process to be read-only and executed concurrently can significantly improve performance.

When we replay the history of the block chain, we do not need to evaluate the permissions again when trying to regenerate the deterministic state from the action log. The objective fact that a transaction is contained in a known irreversible block is sufficient to allow it to bypass the ill-conceived steps of the authority evaluation. This greatly reduces the amount of computation that is consumed when replaying a growing chunk chain. operation with forced delay

Time is a key factor in security. Typically, the owner of the private key will know that it was stolen only after the private key was used by the person who robbed it. Time-based security is even more important when people's applications need to keep their keys on a connected computer for daily use. Eos. IO software allows developers to specify that certain actions (actions) must wait at least a short period of time before they are recorded in a block. During this time, the operation can be canceled.

When an operation is broadcast, the user can receive the notification by email or text message. If they do not authorize this operation, they can use the account recovery process to recover the account and undo the operation.

The required operation to confirm the delay depends on the degree of sensitivity of the operation. Payment of coffee money can be without any delay, in a few seconds to achieve irreversible, and the purchase may require 72 hours of settlement period. Transferring the entire account to new control may take up to 30 days. The exact latency is determined by both the application developer and the user.