├── EOS.IO Storage.pdf ├── README.md ├── Roadmap.md ├── TechnicalWhitePaper.md ├── crowdin.yml ├── ko-KR └── TechnicalWhitePaper.md ├── ru-RU └── TechnicalWhitePaper.md └── zh-CN └── TechnicalWhitePaper.md /EOS.IO Storage.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/EOSIO/Documentation/835e3c3d952cf363d6243259bf6783a2d5375cf8/EOS.IO Storage.pdf -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # EOS.IO documentation is now located at http://developers.eos.io 2 | 3 | ## EOS.IO Technical White Paper 4 | 5 | - [English](TechnicalWhitePaper.md) 6 | - [Russian](ru-RU/TechnicalWhitePaper.md) translated by [@blockchained](https://steemit.com/@blockchained) 7 | - [Chinese](zh-CN/TechnicalWhitePaper.md) translated by [@dayzh](https://steemit.com/@dayzh) 8 | - [Korean](ko-KR/TechnicalWhitePaper.md) translated by [@clayop](https://steemit.com/@clayop) 9 | 10 | ## Translation Guide 11 | 12 | [![Crowdin](https://d322cqt584bo4o.cloudfront.net/eos-docs/localized.svg)](https://crowdin.com/project/eos-docs) 13 | 14 | If you want to add new language, review/update existing translation or help to finish specific translations, you can join and do that by following link: 15 | https://crowdin.com/project/eos-docs 16 | -------------------------------------------------------------------------------- /Roadmap.md: -------------------------------------------------------------------------------- 1 | EOS.IO Software Roadmap 2 | ----------------------- 3 | 4 | This document outlines the development plan from a high level and will be updated as progress is made toward version 1.0. It should be noted that this roadmap applies only to the blockchain software and not to the other tools and utilities such as wallets and block explorers which will have their own teams and dedicated roadmaps once Phase 1 is complete. 5 | 6 | ***Everything contained in this document is in draft form and subject to change at any time and provided for information purposes only. block.one does not guarantee the accuracy of the information contained in this roadmap and the information is provided “as is” with no representations or warranties, express or implied.*** 7 | 8 | # Phase 1 - Minimal Viable Testing Environment - Summer 2017 9 | 10 | The goal of this phase is to establish the APIs that developers will require to start building and testing applications on EOS.IO. In order for developers to start testing their applications they will require the following to be implemented: 11 | 12 | ### Standalone Node (Dan & Nathan) 13 | 14 | A standalone node operates a test blockchain and produces blocks while exposing an API. This node does not need to concern itself with any P2P networking code. 15 | 16 | ### Native Contracts (Nathan) 17 | 18 | The EOS.IO software has a number of native contracts. These are contracts that manage the core operations of the blockchain and exist outside the Web Assembly interface. These contracts include: 19 | 20 | 1. @eos - manages EOS token transfers 21 | 2. @stake - manages locked EOS, voting, and Producer Election 22 | 3. @system - manages permissions, messages, and contact code updates 23 | 24 | ### Virtual Machine API (Dan) 25 | 26 | Contracts are compiled to WebAssembly (WASM) and WASM must interface with the blockchain via a defined API. This API is what developers depend upon to build applications and be relatively stable before developers can really start to build on EOS. 27 | 28 | ### RPC Interface (Arhag, Nathan) 29 | 30 | A simple JSON RPC over HTTP interface will be provided that enables developers to broadcast transactions and query application state. This is critical for both publishing and interacting with test applications. 31 | 32 | ### Command line Tools (Arhag) 33 | 34 | Command line tools facilitate integrating the RPC interface with developer build environments. 35 | 36 | ### Basic Developer Documentation (Josh) 37 | 38 | Documents that teach developers how to get started with building on EOS.IO blockchains. This includes documentations of the WASM API, RPC Interface, and Command Line Tools. 39 | 40 | # Phase 2 - Minimal Viable Test Network - Fall 2017 41 | 42 | Everything in Phase 1 assumes a trusted environment that only runs the developer's own code. Before a test network can be deployed several additional features need to be implemented and tested. 43 | 44 | ### P2P Network Code (Phil) 45 | 46 | This is a plugin that is responsible for synchronizing the blockchain state between two standalone nodes. 47 | 48 | ### WASM Sanitation & CPU Sandboxing (Brian) 49 | 50 | The WASM code needs to be sanitized to check for non-deterministic behavior such as floating point operations and infinite loops. 51 | 52 | ### Resource Usage Tracking & Rate Limiting (Arhag) 53 | 54 | To prevent abuse the resource monitoring and usage tracking rate limits users accoding to staked EOS. 55 | 56 | ### Genesis Import Testing (DappHub) 57 | 58 | Tools need to be developed to export data from the EOS Token Distribution state and create a genesis configuration file. This will enable anyone participating in the Token Distribution to acquire some initial test EOS (TEOS). 59 | 60 | ### Interblockchain Communication (Nathan) 61 | 62 | This feature involves verifying the Merkle hashing of transactions is proper. 63 | 64 | # Phase 3 - Testing & Security Audits - Winter 2017, Spring 2018 65 | 66 | During this phase the platform will undergo heavy testing with a focus on finding security issues and bug. At the end of Phase 3 version 1.0 will be tagged. 67 | 68 | ### Develop Example Applications 69 | 70 | Example applications are critical to proving the platform provides the features required by real developers. 71 | 72 | ### Bounties for Succesfully Attacking Network 73 | 74 | Attacking the network with spam, virtual machine exploits, and bug crashes, and non-deterministic behavior will be a heavily involved process but necessary to ensure that version 1.0 is stable. 75 | 76 | ### Language Support 77 | 78 | Adding support for additional langauges to be compiled to WASM: C++, Rust, etc. 79 | 80 | ### Documentation & Tutorials 81 | 82 | # Phase 4 - Parallel Optimization Summer / Fall 2018 83 | 84 | After getting a stable 1.0 product released, we will move toward optimizing the code for parallel execution. 85 | 86 | # Phase 5 - Cluster Implementation The Future 87 | -------------------------------------------------------------------------------- /TechnicalWhitePaper.md: -------------------------------------------------------------------------------- 1 | # EOS.IO Technical White Paper v2 2 | 3 | **March 16, 2018** 4 | 5 | **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. 6 | 7 | **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.** 8 | 9 | Copyright © 2018 block.one 10 | 11 | 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. 12 | 13 | 14 | **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. 15 | 16 | 17 | 18 | - [Background](#background) 19 | - [Requirements for Blockchain Applications](#requirements-for-blockchain-applications) 20 | * [Support Millions of Users](#support-millions-of-users) 21 | * [Free Usage](#free-usage) 22 | * [Easy Upgrades and Bug Recovery](#easy-upgrades-and-bug-recovery) 23 | * [Low Latency](#low-latency) 24 | * [Sequential Performance](#sequential-performance) 25 | * [Parallel Performance](#parallel-performance) 26 | - [Consensus Algorithm \(BFT-DPOS\)](#consensus-algorithm-bft-dpos) 27 | * [Transaction Confirmation](#transaction-confirmation) 28 | * [Transaction as Proof of Stake \(TaPoS\)](#transaction-as-proof-of-stake-tapos) 29 | - [Accounts](#accounts) 30 | * [Actions & Handlers](#actions--handlers) 31 | * [Role Based Permission Management](#role-based-permission-management) 32 | + [Named Permission Levels](#named-permission-levels) 33 | + [Permission Mapping](#permission-mapping) 34 | + [Evaluating Permissions](#evaluating-permissions) 35 | - [Default Permission Groups](#default-permission-groups) 36 | - [Parallel Evaluation of Permissions](#parallel-evaluation-of-permissions) 37 | * [Actions with Mandatory Delay](#actions-with-mandatory-delay) 38 | * [Recovery from Stolen Keys](#recovery-from-stolen-keys) 39 | - [Deterministic Parallel Execution of Applications](#deterministic-parallel-execution-of-applications) 40 | * [Minimizing Communication Latency](#minimizing-communication-latency) 41 | * [Read-Only Action Handlers](#read-only-action-handlers) 42 | * [Atomic Transactions with Multiple Accounts](#atomic-transactions-with-multiple-accounts) 43 | * [Partial Evaluation of Blockchain State](#partial-evaluation-of-blockchain-state) 44 | * [Subjective Best Effort Scheduling](#subjective-best-effort-scheduling) 45 | * [Deferred Transactions](#deferred-transactions) 46 | * [Context Free Actions](#context-free-actions) 47 | - [Token Model and Resource Usage](#token-model-and-resource-usage) 48 | * [Objective and Subjective Measurements](#objective-and-subjective-measurements) 49 | * [Receiver Pays](#receiver-pays) 50 | * [Delegating Capacity](#delegating-capacity) 51 | * [Separating Transaction costs from Token Value](#separating-transaction-costs-from-token-value) 52 | * [State Storage Costs](#state-storage-costs) 53 | * [Block Rewards](#block-rewards) 54 | * [Worker Proposal System](#worker-proposal-system) 55 | - [Governance](#governance) 56 | * [Freezing Accounts](#freezing-accounts) 57 | * [Changing Account Code](#changing-account-code) 58 | * [Constitution](#constitution) 59 | * [Upgrading the Protocol & Constitution](#upgrading-the-protocol--constitution) 60 | + [Emergency Changes](#emergency-changes) 61 | - [Scripts & Virtual Machines](#scripts--virtual-machines) 62 | * [Schema Defined Actions](#schema-defined-actions) 63 | * [Schema Defined Database](#schema-defined-database) 64 | * [Generic Multi Index Database API](#generic-multi-index-database-api) 65 | * [Separating Authentication from Application](#separating-authentication-from-application) 66 | - [Inter Blockchain Communication](#inter-blockchain-communication) 67 | * [Merkle Proofs for Light Client Validation \(LCV\)](#merkle-proofs-for-light-client-validation-lcv) 68 | * [Latency of Interchain Communication](#latency-of-interchain-communication) 69 | * [Proof of Completeness](#proof-of-completeness) 70 | * [Segregated Witness](#segregated-witness) 71 | - [Conclusion](#conclusion) 72 | 73 | 74 | 75 | # Background 76 | 77 | 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. 78 | 79 | 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. 80 | 81 | Existing blockchain platforms are burdened by large fees and limited computational capacity that prevent widespread blockchain adoption. 82 | 83 | # Requirements for Blockchain Applications 84 | 85 | In order to gain widespread use, applications on the blockchain require a platform that is flexible enough to meet the following requirements: 86 | 87 | ## Support Millions of Users 88 | 89 | 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. 90 | 91 | ## Free Usage 92 | 93 | 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. 94 | 95 | ## Easy Upgrades and Bug Recovery 96 | 97 | Businesses building blockchain based applications need the flexibility to enhance their applications with new features. The platform must support software and smart contract upgrades. 98 | 99 | 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. 100 | 101 | ## Low Latency 102 | 103 | 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. 104 | 105 | ## Sequential Performance 106 | 107 | 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. 108 | 109 | ## Parallel Performance 110 | 111 | Large scale applications need to divide the workload across multiple CPUs and computers. 112 | 113 | # Consensus Algorithm (BFT-DPOS) 114 | 115 | 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)](https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper). 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. 116 | 117 | 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. 118 | 119 | 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. 120 | 121 | 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. 122 | 123 | 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. 124 | 125 | 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. 126 | 127 | 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. 128 | 129 | ## Transaction Confirmation 130 | 131 | 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. 132 | 133 | 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. 134 | 135 | ## Transaction as Proof of Stake (TaPoS) 136 | 137 | The EOS.IO software requires every transaction to include part of the hash of a recent block header. This hash serves two purposes: 138 | 139 | 1. prevents a replay of a transaction on forks that do not include the referenced block; and 140 | 2. signals the network that a particular user and their stake are on a specific fork. 141 | 142 | 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. 143 | 144 | # Accounts 145 | 146 | 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. 147 | 148 | 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. 149 | 150 | ## Actions & Handlers 151 | 152 | 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. 153 | 154 | 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. 155 | 156 | ## Role Based Permission Management 157 | 158 | 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. 159 | 160 | 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. 161 | 162 | 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. 163 | 164 | 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. 165 | 166 | ### Named Permission Levels 167 | 168 | 169 | 170 | 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. 171 | 172 | 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. 173 | 174 | ### Permission Mapping 175 | 176 | 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. 177 | 178 | ### Evaluating Permissions 179 | 180 | 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**. 181 | 182 | 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**. 183 | 184 | 185 | 186 | #### Default Permission Groups 187 | 188 | 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". 189 | 190 | #### Parallel Evaluation of Permissions 191 | 192 | 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. 193 | 194 | 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. 195 | 196 | 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. 197 | 198 | ## Actions with Mandatory Delay 199 | 200 | 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. 201 | 202 | 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. 203 | 204 | 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. 205 | 206 | ## Recovery from Stolen Keys 207 | 208 | 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. 209 | 210 | 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. 211 | 212 | 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. 213 | 214 | 215 | # Deterministic Parallel Execution of Applications 216 | 217 | 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. 218 | 219 | The June 2018 release of EOS.IO software will run single threaded, yet it contains the data structures necessary for future multithreaded, parallel execution. 220 | 221 | 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. 222 | 223 | 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. 224 | 225 | 226 | ## Minimizing Communication Latency 227 | 228 | 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. 229 | 230 | Block 231 | 232 | Region 233 | 234 | Cycles (sequential) 235 | 236 | Shards (parallel) 237 | 238 | Transactions (sequential) 239 | 240 | Actions (sequential) 241 | 242 | Receiver and Notified Accounts (parallel) 243 | 244 | 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. 245 | 246 | 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. 247 | 248 | 249 | ## Read-Only Action Handlers 250 | 251 | 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. 252 | 253 | ## Atomic Transactions with Multiple Accounts 254 | 255 | 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. 256 | 257 | ## Partial Evaluation of Blockchain State 258 | 259 | 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. 260 | 261 | 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. 262 | 263 | 264 | ## Subjective Best Effort Scheduling 265 | 266 | 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. 267 | 268 | 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. 269 | 270 | 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. 271 | 272 | 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. 273 | 274 | 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. 275 | 276 | ## Deferred Transactions 277 | 278 | 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. 279 | 280 | ## Context Free Actions 281 | 282 | 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. 283 | 284 | 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. 285 | 286 | 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. 287 | 288 | # Token Model and Resource Usage 289 | 290 | **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.** 291 | 292 | 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: 293 | 294 | 1. Bandwidth and Log Storage (Disk); 295 | 2. Computation and Computational Backlog (CPU); and 296 | 3. State Storage (RAM). 297 | 298 | 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. 299 | 300 | 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. 301 | 302 | 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. 303 | 304 | 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. 305 | 306 | 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. 307 | 308 | ## Objective and Subjective Measurements 309 | 310 | 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. 311 | 312 | 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. 313 | 314 | ## Receiver Pays 315 | 316 | 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. 317 | 318 | 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. 319 | 320 | 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. 321 | 322 | ## Delegating Capacity 323 | 324 | 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. 325 | 326 | ## Separating Transaction costs from Token Value 327 | 328 | 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. 329 | 330 | 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. 331 | 332 | ## State Storage Costs 333 | 334 | 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. 335 | 336 | ## Block Rewards 337 | 338 | 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%. 339 | 340 | ## Worker Proposal System 341 | 342 | 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. 343 | 344 | 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. 345 | 346 | 347 | # Governance 348 | 349 | Governance is the process by which people in a community: 350 | 351 | 1. Reach consensus on subjective matters of collective action that cannot be captured entirely by software algorithms; 352 | 2. Carry out the decisions they reach; and 353 | 3. Alter the governance rules themselves via Constitutional amendments. 354 | 355 | 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. 356 | 357 | 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. 358 | 359 | 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. 360 | 361 | ## Freezing Accounts 362 | 363 | 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. 364 | 365 | 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. 366 | 367 | ## Changing Account Code 368 | 369 | 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. 370 | 371 | ## Constitution 372 | 373 | 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. 374 | 375 | 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. 376 | 377 | ## Upgrading the Protocol & Constitution 378 | 379 | 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: 380 | 381 | 1. Block producers propose a change to the constitution and obtains 15/21 approval. 382 | 2. Block producers maintain 15/21 approval of the new **constitution** for 30 consecutive days. 383 | 3. All users are required to indicate acceptance of the new constitution as a condition of future transactions being processed. 384 | 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. 385 | 5. Block producers maintain 15/21 approval of the new **code** for 30 consecutive days. 386 | 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. 387 | 7. All nodes that do not upgrade to the new code shut down automatically. 388 | 389 | 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. 390 | 391 | ### Emergency Changes 392 | 393 | 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. 394 | 395 | # Scripts & Virtual Machines 396 | 397 | 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. 398 | 399 | ## Schema Defined Actions 400 | 401 | 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. 402 | 403 | ## Schema Defined Database 404 | 405 | 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. 406 | 407 | ## Generic Multi Index Database API 408 | 409 | 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. 410 | 411 | ## Separating Authentication from Application 412 | 413 | 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: 414 | 415 | 1. Validating that an Action is internally consistent; 416 | 2. Validating that all preconditions are valid; and 417 | 3. Modifying the application state. 418 | 419 | 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. 420 | 421 | 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. 422 | 423 | # Inter Blockchain Communication 424 | 425 | 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. 426 | 427 | 428 | 429 | ## Merkle Proofs for Light Client Validation (LCV) 430 | 431 | 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. 432 | 433 | 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. 434 | 435 | 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. 436 | 437 | 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. 438 | 439 | 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. 440 | 441 | 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. 442 | 443 | 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. 444 | 445 | 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. 446 | 447 | 448 | ## Latency of Interchain Communication 449 | 450 | 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. 451 | 452 | ## Proof of Completeness 453 | 454 | 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. 455 | 456 | ## Segregated Witness 457 | 458 | 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. 459 | 460 | 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. 461 | 462 | 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. 463 | 464 | # Conclusion 465 | 466 | 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. 467 | -------------------------------------------------------------------------------- /crowdin.yml: -------------------------------------------------------------------------------- 1 | files: 2 | - source: /TechnicalWhitePaper.md 3 | translation: /%locale%/%original_file_name% 4 | - source: /Roadmap.md 5 | translation: /%locale%/%original_file_name% 6 | -------------------------------------------------------------------------------- /ko-KR/TechnicalWhitePaper.md: -------------------------------------------------------------------------------- 1 | # EOS.IO 기술 백서 2 | 3 | **초안 작성일: 2017년 6월 26일, 번역: 이태민 (taeminlee), 감수: 조재우 (@clayop (https://steemit.com/@clayop))** 4 | 5 | **초록:** EOS.IO 소프트웨어는 탈중앙화 애플리케이션의 수직 및 수평 확장이 가능하도록 디자인된 새로운 블록체인 아키텍처를 소개합니다. 이는 애플리케이션을 구축할 수 있는 운영체제와 유사한 구조를 생성함으로 완성됩니다. 본 소프트웨어는 수백 개의 CPU 코어 또는 클러스터에 계정(accounts), 인증(authentication), 데이터베이스(databases), 비동기 통신(asynchronous communication), 애플리케이션 스케쥴링(application scheduling) 기능을 제공합니다. 그 결과 초당 수백만 건의 트랜잭션 처리 능력을 갖추면서도, 수수료가 없고, 빠르고 쉽게 애플리케이션을 개발할 수 있는 블록체인 아키텍처 기술이 탄생했습니다. 6 | 7 | **주의사항: 본 백서에서 언급되는 암호화폐 토큰은 EOS.IO 소프트웨어를 사용할 수 있는 블록체인 상에 존재하는 토큰을 지칭합니다. 이 토큰은 EOS 분배에 사용되는 이더리움 블록체인 상에 존재하는 ERC-20 기반 토큰을 가리키는 것이 아닙니다.** 8 | 9 | 저작권 소유 © 2017 block.one 10 | 11 | 누구든지 허가 없이 원래의 출처와 해당 저작권 고지가 언급된 경우 비영리적이고 교육적인 용도 (즉, 유료 또는 상업적 목적 이외의 목적)로 본 백서의 자료를 사용, 복제 또는 배포할 수 있습니다. 12 | 13 | **면책 조항:** EOS.IO 기술 백서 초안은 오직 정보 제공의 목적으로써 제공됩니다. 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. 14 | 15 | - [탄생 배경 (Background)](#background) 16 | - [블록체인 애플리케이션의 요구사항 (Requirements for Blockchain Application)](#requirements-for-blockchain-applications) 17 | - [수백만의 사용자 허용 (Support Millions of Users)](#support-millions-of-users) 18 | - [무료 사용 (Free Usage)](#free-usage) 19 | - [간편한 업그레이드 및 버그 해소 (Easy upgrades and Bug Recovery)](#easy-upgrades-and-bug-recovery) 20 | - [짧은 지연 시간 (Low Latency)](#low-latency) 21 | - [순차(sequential) 처리 성능 (Sequential Performance)](#sequential-performance) 22 | - [병렬 처리 성능 (Parallel Performance)](#parallel-performance) 23 | - [합의 알고리즘 (DPOS) (Consensus Algorithm)](#consensus-algorithm--dpos-) 24 | - [트랜잭션 확인 (Transaction Confirmation)](#transaction-confirmation) 25 | - [트랜잭션 기반 지분 증명 (Transaction as Proof of Stake, TaPoS)](#transaction-as-proof-of-stake--tapos-) 26 | - [계정 (Accounts)](#accounts) 27 | - [메시지와 처리기 (Messages & Handlers)](#messages---handlers) 28 | - [역할 기반 권한 관리 (Role Based Permission Management)](#role-based-permission-management) 29 | - [명명된 권한 수준 (Named Permission Levels)](#named-permission-levels) 30 | - [명명된 메시지 처리기 그룹 (Named Message Handler Groups)](#named-message-handler-groups) 31 | - [권한 매핑 (Permission Mapping)](#permission-mapping) 32 | - [권한 검사 (Evaluating Permissions)](#evaluating-permissions) 33 | - [기본 권한 그룹( Default Permission Groups)](#default-permission-groups) 34 | - [권한 검사의 병렬화 (Parallel Evaluation of Permissions)](#parallel-evaluation-of-permissions) 35 | - [메시지의 필수 지연 시간 (Messages with Mandatory Delay)](#messages-with-mandatory-delay) 36 | - [키 도난 상태에서의 복구 (Recovery from Stolen Keys)](#recovery-from-stolen-keys) 37 | - [애플리케이션의 결정론적 병렬 실행 (Deterministic Parallel Execution of Applications)](#deterministic-parallel-execution-of-applications) 38 | - [통신 지연 최소화 (Minimizing Communication Latency)](#minimizing-communication-latency) 39 | - [읽기 전용 메시지 처리기 (Read-Only Message Handlers)](#read-only-message-handlers) 40 | - [다중 계정의 원자적 트랜잭션 (Atomic Transactions with Multiple Accounts)](#atomic-transactions-with-multiple-accounts) 41 | - [블록체인 상태의 부분 검사 (Partial Evaluation of Blockchain State)](#partial-evaluation-of-blockchain-state) 42 | - [주관적 최선 스케쥴링 (Subjective Best Effort Scheduling)](#subjective-best-effort-scheduling) 43 | - [토큰 모델과 리소스 사용 (Token Model and Resource Usage)](#token-model-and-resource-usage) 44 | - [객관적 측정과 주관적 측정 (Objective and Subjective Measurements)](#objective-and-subjective-measurements) 45 | - [수취인 부담 (Receiver Pays)](#receiver-pays) 46 | - [리소스 허용량 위임 (Delegating Capacity)](#delegating-capacity) 47 | - [토큰의 가치와 트랜잭션 비용의 분리 (Separating Transaction costs from Token Value)](#separating-transaction-costs-from-token-value) 48 | - [상태 저장 비용 (State Storage Costs)](#state-storage-costs) 49 | - [블록 보상 (Block Rewards)](#block-rewards) 50 | - [커뮤니티 혜택 애플리케이션 (Community Benefit Applications)](#community-benefit-applications) 51 | - [거버넌스 (Governance)](#governance) 52 | - [계정 동결 (Freezing Accounts)](#freezing-accounts) 53 | - [계정 코드 변경 (Changing Account Code)](#changing-account-code) 54 | - [약관 (Constitution)](#constitution) 55 | - [프로토콜과 약관의 개정 (Upgrading the Protocol & Constitution)](#upgrading-the-protocol---constitution) 56 | - [응급 변경 (Emergency Changes)](#emergency-changes) 57 | - [스크립트와 가상 머신 (Scripts & Virtual Machines)](#scripts---virtual-machines) 58 | - [스키마 정의 메시지 (Schema Defined Messages)](#schema-defined-messages) 59 | - [스키마 정의 데이터베이스 (Schema Defined Database)](#schema-defined-database) 60 | - [애플리케이션과 인증 분리 (Separating Authentication from Application)](#separating-authentication-from-application) 61 | - [가상 머신 독립 아키텍처 (Virtual Machine Independent Architecture)](#virtual-machine-independent-architecture) 62 | - [웹어셈블리 (WASM; Web Assembly)](#web-assembly) 63 | - [이더리움 가상 머신 (EVM; Ethereum Virtual Machine)](#ethereum-virtual-machine--evm-) 64 | - [블록체인 간 통신 (Inter Blockchain Communication)](#inter-blockchain-communication) 65 | - [경량화된 클라이언트 검증(LCV)을 위한 머클 증명 (Merkle Proofs for Light Client Validation)](#merkle-proofs-for-light-client-validation--lcv-) 66 | - [체인 간 통신의 지연 시간 (Latency of Interchain Communication)](#latency-of-interchain-communication) 67 | - [완전성 증명 (Proof of Completeness)](#proof-of-completeness) 68 | - [결론 (Conclusion)](#conclusion) 69 | 70 | # 탄생 배경 (Background) 71 | 72 | 블록체인 기술은 2008년 비트코인 화폐의 출현과 함께 시작되었으며, 이후 기업가와 개발자는 하나의 블록체인 플랫폼에서 다양한 애플리케이션을 지원하기 위해 기술의 일반화를 시도해 왔습니다. 73 | 74 | 다수의 블록체인 플랫폼은 제대로 작동하는 탈중앙화 애플리케이션을 지원하기 위해 노력하는 동안, BitShares 탈중앙화 거래소(2014) 및 Steem 소셜 미디어 플랫폼(2016)과 같은 애플리케이션 특화 블록체인은 이미 수만 명의 일일 사용자를 가진 블록체인으로 성장하였습니다. 이는 초당 수천 건의 트랜잭션 지원과 1.5초의 지연시간과 같은 성능 향상, 사용 수수료의 제거, 현재 서비스되는 중앙 집중형 서비스와 유사한 수준의 사용자 경험 제공을 통해 가능하게 되었습니다. 75 | 76 | 현존하는 블록체인 플랫폼들은 비싼 수수료와 연산능력의 한계 때문에 블록체인의 광범위한 사용에 있어서 어려움을 겪고 있습니다. 77 | 78 | # 블록체인 애플리케이션의 요구사항 (Requirements for Blockchain Application) 79 | 80 | 블록체인 위에서 돌아가는 애플리케이션이 대중적으로 사용되기 위해서는 다음의 요구사항을 만족하는 유연한 플랫폼을 갖춰야 합니다. 81 | 82 | ## 수백만의 사용자 허용 (Support Millions of Users) 83 | 84 | Ebay, Uber, AirBnB, Facebook 과 같은 기존 서비스와 경쟁력을 갖추기 위해서 수천만의 일일 사용자를 수용할 수 있는 블록체인 기술이 필요합니다. 또한 많은 사용자가 이용하지 않을 경우 작동하지 않는 애플리케이션도 있으므로 많은 사용자를 수용하는 플랫폼은 무엇보다 중요합니다. 85 | 86 | ## 무료 사용 (Free Usage) 87 | 88 | 애플리케이션 개발자는 사용자들에게 무료 서비스를 제공할 수 있는 유연성이 필요하며, 사용자들은 플랫폼을 사용하거나 플랫폼의 서비스를 통해 편익을 얻기 위해 비용을 지불해서는 안됩니다. 사용자가 무료로 이용할 수 있는 블록체인 플랫폼이 더 널리 전파될 것입니다. 빠른 대중화로 인해 기업가와 개발자는 효율적인 수익 창출 전략을 만들어 낼 수 있을 것입니다. 89 | 90 | ## 간편한 업그레이드 및 버그 해소 (Easy upgrades and Bug Recovery) 91 | 92 | 블록체인 기반 애플리케이션을 만드는 기업은 그들의 애플리케이션에 새로운 기능을 추가하고 개선할 수 있어야 합니다. 93 | 94 | 많은 소프트웨어들은 엄격한 공식적인 검사를 진행함에도 버그가 발생합니다. 플랫폼은 애플리케이션에서 버그가 발생하였을 때 버그를 수정할 수 있을 만큼 안정적이어야 합니다. 95 | 96 | ## 짧은 지연 시간 (Low Latency) 97 | 98 | 좋은 사용자 경험은 수 초 이하의 지연시간을 통한 안정적인 피드백을 필요로 합니다. 긴 지연 시간은 사용자의 불만을 일으키며, 이러한 블록체인 애플리케이션은 블록체인을 사용하지 않는 기성 시장의 애플리케이션에 비해 경쟁력이 떨어집니다. 99 | 100 | ## 순차(sequential) 처리 성능 (Sequential Performance) 101 | 102 | 몇몇 애플리케이션은 순차적인 처리 단계를 거쳐야 하기 때문에 병렬 알고리즘으로 구현될 수 없습니다. 거래소(exchange)와 같은 애플리케이션들은 많은 양의 거래를 순차적으로 처리하는 충분한 성능을 요구하므로, 플랫폼은 빠른 순차 처리 성능이 필요합니다. 103 | 104 | ## 병렬 처리 성능 (Parallel Performance) 105 | 106 | 거대 규모의 애플리케이션은 하나의 작업을 다수의 CPU와 컴퓨터에 분배하여 처리할 수 있어야 합니다. 107 | 108 | # 합의 알고리즘 (DPOS) (Consensus Algorithm) 109 | 110 | EOS.IO 소프트웨어는 블록체인 애플리케이션의 성능 요구사항을 충족할 수 있는 유일한 탈중앙화 합의 알고리즘인 [지분 위임 증명(DPOS; Deleteged Proof-Of-Stake)을 사용합니다](https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper). 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. 111 | 112 | EOS.IO 소프트웨어는 정확히 3초마다 블록이 만들어질 수 있게 하며, 각 시점마다 오직 한 명의 블록 생산자만이 블록을 생성할 수 있습니다. 만약 정해진 시간에 블록이 생산되지 않을 경우 해당 시점의 블록은 무시됩니다. 1개 혹은 그 이상의 블록이 무시될 경우 블록체인에는 6초 혹은 그 이상의 간격(gap)이 나타납니다. 113 | 114 | EOS.IO 소프트웨어를 이용하여 블록들은 21번의 단계로 구성되는 라운드로 생성되며. 각 라운드가 시작될 때 21명의 블록 생산자가 정해집니다. 라운드마다 많은 득표를 받은 상위 20명의 블록 생산자가 자동으로 배정되며, 마지막 생산자는 다른 생산자와의 상대적인 투표수에 비례하여 선출됩니다. 블록 시간으로 유도되는 의사 난수(pseudorandom number)에 따라 선출된 생산자들의 블록 생성 순서를 랜덤하게 섞습니다. 블록 생성 순서를 섞는 것은 모든 생산자가 다른 생산자들과 균형적인 연결(balanced connectivity)을 유지하도록 진행합니다. 115 | 116 | 생산자가 블록 생성에 실패하고 지난 24시간 동안 어떠한 블록을 생성하지 않는다면, 블록체인에 블록 생성 참여 의사를 알려주기 전까지 후보군에서 제외됩니다. 신뢰할 수 없는 사람을 참가시키지 않으므로 놓치는 블록의 수를 최소화하고 네트워크가 원활하게 동작하도록 보장합니다. 117 | 118 | 일반적인 상황에서 지분 위임 증명(DPOS) 알고리즘을 사용하는 블록체인은 어떠한 포크(fork)도 일어나지 않습니다. 이는 블록 생성자가 경쟁이 아닌 협력을 하기 때문입니다. 포크가 일어난 경우, 합의 알고리즘은 자동으로 가장 긴 블록 체인(chain)을 선택합니다. 이 방법이 동작하는 이유는, 특정 블록체인 포크에 블록들이 추가되는 속도는 같은 합의를 공유하는 블록 생성자의 비율과 직접 연관되기 때문입니다. 다수의 생산자 존재하는 블록체인 포크는 적은 생산자를 가진 것에 비하여 빠르게 증가합니다. 추가로, 어떠한 블록 생성자도 동시에 두 개의 포크에 블록을 생성할 수 없습니다. 이러한 경우가 적발될 경우 해당 블록 생성자는 탄핵당할 것입니다. 이러한 이중 생산에 대한 암호학적 증거(cryptographic evidence)는 정당하지 않은 방법으로 이득을 취한 사람을 자동으로 제거하는 데 사용될 수 있습니다. 119 | 120 | ## 트랜잭션 확인 (Transaction Confirmation) 121 | 122 | 일반적인 DPOS 블록체인은 100%의 블록 생산자 참여율을 가집니다. 전파(braodcasting) 시간부터 평균 1.5초의 시간이 흐르면 트랜잭션은 99.9%의 신뢰도로 확인(confirm)되었다 판단할 수 있습니다. 123 | 124 | 소프트웨어 버그, 인터넷 속도 저하, 비정상적 블록 생산자와 같은 특수한 상황에서 두 개 혹은 그 이상의 포크가 생성될 수 있습니다. 트랜잭션의 바뀌지 않음(irreversible)을 확정하기 위해서, 노드는 21명의 블록 생산자 중 15명의 확인(confirmation)을 기다릴 수 있습니다. EOS.IO 소프트웨어의 기본 설정에 따르면 보통 상황에서 45초의 시간이 소요됩니다. 기본적으로 모든 노드는 21명 중 15명이 확인할 경우 해당 블록이 바뀌지 않음을 확정하고 블록의 길이와 상관없이 다른 포크로 전환하지 않습니다. 125 | 126 | 노드는 포크가 분기된 후 9초 이내에 속한 노드가 소수 포크(minority fork)에 속해있음을 높은 확률로 사용자에게 알려줄 수 있습니다. 노드가 속한 블록체인에 2개의 블록이 연속적으로 추가되지 않을 경우 95% 확률로 소수 포크에 속하게 됩니다. 3번 연속으로 추가되지 않을 경우 99%의 소수 포크 확률을 가집니다. 블록이 Qkwls 노드, 최근 참여 비율 등의 정보를 토대로 관리자에게 잘못된 상황에 대한 경보를 신속하게 제공하는 안정적인 예측 모형을 만들 수 있습니다. 127 | 128 | 경보에 대한 대응은 비즈니스 트랜잭션의 성격에 따라 다르며, 가장 간단한 대응 방법은 15/21 확인이 이루어져 경보가 끝나는 시점까지 기다리는 것입니다. 129 | 130 | ## 트랜잭션 기반 지분 증명 (Transaction as Proof of Stake, TaPoS) 131 | 132 | EOS.IO 소프트웨어는 모든 트랜잭션이 최근 블록 헤더의 해쉬값을 포함하도록 요구합니다. 해쉬 값은 두 가지 용도로 사용됩니다. 133 | 134 | 1. 참조 블록(referenced block)이 포함되지 않은 포크에서 트랜잭션이 재실행 되는 것을 방지합니다. 135 | 2. 특정 사용자가 가진 자산이 어떤 포크에서 존재하는지 네트워크에 알려줍니다. 136 | 137 | 시간이 지날수록 모든 사용자는 직접 블록체인을 확인(confirm)하게 되며, 합법적 체인의 거래를 위조 체인으로 옮길 수 없으므로 위조 체인을 만드는 것은 어렵게 됩니다. 138 | 139 | # 계정 (Accounts) 140 | 141 | EOS.IO 소프트웨어는 모든 계정이 2~32글자의 읽을 수 있는 고유 이름으로 참조되도록 합니다. 계정 이름은 생성자가 선택합니다. 모든 계정은 생성되는 시점에 계정 정보를 담는 저장 비용을 초과하는 잔액을 보유해야 합니다. 계정 이름은 네임스페이스를 지원합니다. 예를 들어, @domain 계정의 소유자만이 @user.domain을 생성할 수 있도록 합니다. 142 | 143 | 탈중앙화 환경에서, 애플리케이션 개발자는 새로운 사용자가 가입하여 계정을 생성하는 최소한의 비용을 부담해야 합니다. 일반적인 기업들은 이미 광고나 무료 서비스 제공의 명목으로 단위 사용자당 상당액의 돈을 지출하고 있습니다. 이와 비교할 때 새로운 블록체인 계정에 부담하는 비용은 상대적으로 미미할 것입니다. 이미 다른 애플리케이션에 가입한 사용자의 계정을 중복하여 가입할 필요는 없습니다. 144 | 145 | ## 메시지와 처리기 (Messages & Handlers) 146 | 147 | 한 계정에서 다른 계정으로 구조화된 메시지(structured message)를 전송할 수 있으며, 이를 송신하였을 때 처리하는 스크립트(script)를 정의할 수 있습니다. EOS.IO 소프트웨어는 각각의 계정이 독립된 프라이빗 데이터베이스를 가지도록 하며, 자신의 메시지 처리기만이 접근하도록 허용합니다. 메시지 처리 스크립트에서 다른 계정으로 메시지를 전송할 수도 있습니다. EOS.IO는 스마트 컨트렉트(smart contract)를 메시지와 자동화된 메시지 처리기의 조합으로 정의합니다. 148 | 149 | ## 역할 기반 권한 관리 (Role Based Permission Management) 150 | 151 | 권한 관리는 메시지가 정상적으로 인증(authorized)되었는지 결정하는 것을 포함됩니다. 가장 단순한 형태의 권한 관리는 트랜잭션의 서명 여부를 검사하는 것이나, 이는 이미 필요한 서명을 알고 있을 때 가능합니다. 일반적으로 권한은 사용자와 그룹에 부여되며 이는 종종 구분됩니다. EOS.IO 소프트웨어는 계정별로 누가, 언제, 어떤 작업을 할 수 있는지에 대하여 세부적으로 제어하는 선언적 권한 관리 시스템을 제공합니다. 152 | 153 | 인증과 권한 관리를 표준화하고 애플리케이션의 비즈니스 로직과 분리하는 것이 중요합니다. 이것은 권한 관리가 범용적인 관점에서 이루어지도록 하는 도구를 개발할 수 있게 하며, 또한 성능 최적화의 큰 가능성이 열리게 합니다. 154 | 155 | 모든 계정은 다른 계정들(other accounts)과 개인키들(private keys)의 가중치 조합(weighted combination)으로 제어될 수 있습니다. 이를 통해 현실의 권한 구성 방식과 유사한 위계적 인증 구조(hierarchical authority structure)를 생성할 수 있으며, 또한 기금(funds)에 대한 다중 사용자 제어(multi-user control)를 보다 쉽게 하도록 합니다. 다중 사용자 제어는 보안 관점에서 큰 의의가 있으며, 이를 올바르게 사용할 경우 해킹으로 인한 도난의 위험을 큰폭으로 감소시킬 수 있습니다. 156 | 157 | EOS.IO 소프트웨어를 통해 각 계정은 특정 종류의 메시지를 다른 계정으로 전송하는데 필요한 키 조합을 정의할 수 있습니다. 예를 들어, 사용자의 소셜 미디어 계정의 키와 별도로 거래 권한의 키를 가질 수 있습니다. 다른 계정에 키를 할당하지 않고도 다른 계정이 사용자의 계정을 대신하여 활동할 수 있도록 할 수도 있습니다. 158 | 159 | ### 명명된 권한 수준 (Named Permission Levels) 160 | 161 | 162 | 163 | EOS.IO 소프트웨어를 이용하여 계정은 상위 명명된 권한 수준들로부터 파생되는 명명된 권한 수준을 정의할 수 있습니다. 각각 명명된 권한 수준은 인증 방식(authority)을 정의합니다. 인증 방식은 다른 계정의 키와 명명된 권한 수준의 자유로운 조합에 대한 역치 다중서명 확인(threshold multi-signature check)입니다. 예를 들어, 한 계정의 "친구" 권한 수준은 해당 계정에 대해 어떠한 친구 계정으로도 동등하게 제어될 수 있게 할 수 있습니다. 164 | 165 | 다른 예제로서 Steem 블록체인이 있으며, 여기에는 3가지 하드 코딩된 명명된 권한 수준을 가지고 있습니다. 소유자(owner), 활동(active), 포스팅(posting) 입니다. 포스팅 권한은 투표나 글쓰기와 같은 소셜 활동을 할 수 있으며, 활동 권한은 소유자 변경 외 모든 활동이 가능합니다. 소유자(owner) 권한은 콜드 스토리지(cold storage)를 의미하며 모든 활동이 가능합니다. The EOS.IO software generalizes this concept by allowing each account holder to define their own hierarchy as well as the grouping of actions. 166 | 167 | ### 명명된 메시지 처리기 그룹 (Named Message Handler Groups) 168 | 169 | EOS.IO 소프트웨어는 각각의 계정이 독자적인 메시지 처리기를 명명(named)하고 중첩 그룹화(nested groups)하는 것을 허용합니다. 명명된 메시지 핸들러 그룹(names message handler group)들은 권한 수준을 설정할 때 다른 계정으로부터 참조될 수 있습니다. 170 | 171 | 최상위 수준의 메시지 처리기 그룹은 계정 이름이며, 가장 낮은 수준은 특정 계정으로부터 받은 개별적인 메시지 타입입니다. 이러한 그룹들은 다음과 같이 참조될 수 있습니다. @계정명.그룹A.하위그룹B.메시지타입 (@accountname.groupa.subgroupb.MessageType) 172 | 173 | 이러한 모형을 이용하여 거래소의 계약을 거래 단위로 그룹화하여 입금과 출금을 별개로 다룰 수 있게 됩니다. 이러한 거래 계약의 그룹화는 교환소의 사용자에게 편의성을 제공합니다. 174 | 175 | ### 권한 매핑 (Permission Mapping) 176 | 177 | EOS.IO 소프트웨어는 계정별로 어떠한 계정의 명명된 메시지 처리기 그룹과 보유하고 있는 명명된 관리 수준 간의 매핑을 진행할 수 있도록 합니다. 예를 들어, 계정 소유자는 해당 계정 소유자의 소셜 미디어 애플리케이션을 "친구" 관리 그룹과 매핑할 수 있습니다. 이 매핑을 통해, 어떤 친구들이라도 계정 소유자처럼 계정 소유자의 소셜 미디어에 포스팅할 수 있습니다. 친구들이 계정 소유자처럼 포스팅할지라도 그들이 가진 키로 메시지에 서명합니다. 이는 어떤 친구가 계정을 사용했고 무엇을 하였는지 알 수 있음을 뜻합니다. 178 | 179 | ### 권한 검사 (Evaluating Permissions) 180 | 181 | @앨리스가 @밥에게 "액션" 타입의 메시지를 보낸다 가정해봅시다. EOS.IO 소프트웨어는 먼저 @앨리스가 @밥.그룹A.하위그룹.액션 처리기에 대한 권한을 매핑하였는지 확인합니다. 만약 매핑되어 있지 않다면 매핑이 발견될 때 까지 @밥.그룹A.하위그룹, @밥.그룹A, @밥의 순서로 검사합니다. 만약 메시지 처리기에 대한 매핑이 없으면 @앨리스.활동(active) 명명된 권한 그룹 매핑을 가정합니다. 182 | 183 | 만약 매핑이 확인이 되면 역치 다중서명 절차와 명명된 권한에 대한 인증을 통해 서명된 인증에 대한 유효성을 검증합니다. 실패할 경우 상위 권한으로 검사를 수행하며 최종적으로 소유자 권한인 @앨**리스.소유자(owner)까지** 검사를 진행합니다. 184 | 185 | 186 | 187 | #### 기본 권한 그룹( Default Permission Groups) 188 | 189 | 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. 그외 다른 권한은 "활동(active)"으로부터 파생됩니다. 190 | 191 | #### 권한 검사의 병렬화 (Parallel Evaluation of Permissions) 192 | 193 | 권한 검사 절차는 "읽기 작업만" 필요로 하며 트랜잭션으로 인한 권한의 변경은 블록이 종료될 때까지는 어떠한 영향도 발휘하지 못합니다. 이것은 모든 트랜잭션의 모든 키와 권한 검사가 병렬적으로 진행될 수 있음을 뜻합니다. 더 나아가, 롤백을 고려해야 할 수도 있어 처리 비용이 많이 발생하는 애플리케이션 로직이 없는 신속한 권한 검사의 가능함도 뜻합니다. 마지막으로, 이는 보류 중인 트랜잭션이 수신될 때 트랜잭션 권한을 평가할 수 있으며, 승인된 트랜잭션은 다시 검사할 필요가 없습니다. 194 | 195 | 전체적인 관점에서, 권한 검사는 트랜잭션 유효성 검사에서 많은 연산 비중을 가집니다. 그러므로 권한 검사를 읽기 연산만으로 구성하여 병렬화하면 전체 성능의 큰 향상을 얻게 됩니다. 196 | 197 | 메시지 로그(message log)로부터 블록체인의 결정된 상태(deterministic state)로 재구축(replay)하는 과정에서 권한 검사를 다시 수행할 필요는 없습니다. 정상적인 블록에 트랜잭션이 포함되어 있으므로 이 과정을 넘길 수 있습니다. 점진적으로 과대해지는 블록체인의 재구축에 드는 계산 비용을 큰 폭으로 감소시킬 수 있습니다. 198 | 199 | ## 메시지의 필수 지연 시간 (Messages with Mandatory Delay) 200 | 201 | 시간은 보안의 핵심 요소입니다. 대부분의 경우, 개인 키(private key)가 도난당한 경우 사용되기 전까지 알기 어렵습니다. 인터넷에 연결된 컴퓨터에 보관되는 키를 사용하는 애플리케이션을 일상적으로 사용하는 사람들에게 시간 기반의 보안은 더욱더 중요합니다. EOS.IO 소프트웨어는 애플리케이션 개발자가 특정 메시지가 블록에 포함되기 시작하고 적용되기 이전에 지정한 시간 만큼을 기다리도록 표시할 수 있게 합니다. During this time they can be cancelled. 202 | 203 | 사용자는 이메일이나 단문으로 메시지가 전송되었음을 안내받을 수 있습니다. 만약 본인이 한 것이 아니라면, 계정 복구 절차를 통해 계정 복구와 메시지 철회를 할 수 있습니다. 204 | 205 | 요구되는 지연 시간은 작업의 중요도에 따라 다릅니다. 커피 한잔을 구매하는 것은 지연시간을 갖지 않아 몇 초 내로 취소 불가 상태가 되며, 집을 사는 문제라면 72시간의 거래 완료 조정 기간을 둘 수 있습니다. 전체 계정을 새로운 환경으로 전환하는 것은 30일의 유예기간을 둘 수도 있습니다. 실제 지연 시간은 애플리케이션 개발자와 사용자가 정하게 될 것입니다. 206 | 207 | ## 키 도난 상태에서의 복구 (Recovery from Stolen Keys) 208 | 209 | EOS.IO 소프트웨어는 사용자의 키가 도난당하였을 때 계정에 대한 복구 작업을 제공합니다. 계정 소유자는 최근 30일 이내에 사용한 키를 가지고 지정된 계정 복구 협력자와 협력하여 계정을 재설정할 수 있습니다. 계정 복구 협력자는 소유자의 허가 없이 계정에 작업할 수 없습니다. 210 | 211 | 키를 가진 해커는 이미 계정을 제어할 수 있으므로 복구 프로세스를 시도하여 얻을 수 있는 것은 없습니다. 복구 프로세스에 진입하여도 복구 협력자는 추가적인 신분 증명이나 2채널 인증(핸드폰이나 이메일)을 요구할 것입니다. 이 과정에서 해커의 정체가 노출되거나 아무것도 얻지 않을 수 있습니다. 212 | 213 | 이 과정은 단순한 다중서명 합의(multi-signature arrangement)와 매우 다릅니다. 다중서명 트랜잭션의 경우 모든 트랜잭션에 관여하는 별도의 회사가 존재하는 것입니다. 복구 처리 과정을 이용하면 복구 협력자는 복구과정에만 관여하며 트랜잭션에 관해서는 어떠한 영향력도 행사하지 않습니다. 이로 인해 참여자들에 대한 비용과 법적 책임을 큰폭으로 감소시킬 수 있습니다. 214 | 215 | # 애플리케이션의 결정론적 병렬 실행 (Deterministic Parallel Execution of Applications) 216 | 217 | 블록체인 합의(consensus)는 재현 가능한 결정론적 행위(deterministic behavior)에 달려있습니다. 이는 모든 병렬 실행은 뮤텍스(mutex)나 다른 기초 라킹 연산(locking primitive) 없이 수행되어야 함을 뜻합니다. 락(lock)이 없다면 다른 방식으로 모든 계정이 보유한 프라이빗 데이터베이스에만 읽기/쓰기 연산할 수 있도록 보장하여야 합니다. 또한 각각의 계정안의 메시지들을 순차적으로 처리하며, 연산의 병렬성은 계정 단위에서 수행됨을 뜻합니다. 218 | 219 | In an EOS.IO software-based blockchain, it is the job of the block producer to organize message delivery into independent threads so that they can be evaluated in parallel. 각각의 계정의 상태(state)는 전달받은 메시지에 달려있습니다. 블록 생산자의 결과물로 실행 스케쥴이 나오게 되며, 이는 결정론적으로 실행됩니다. 다만, 스케쥴을 만드는 과정까지 결정론적일 필요는 없습니다. 이는 블록 생산자가 트랜잭션을 스케쥴링 할 때 병렬 알고리즘을 활용할 수 있음을 뜻합니다. 220 | 221 | 스크립트가 새로운 메시지를 만들 때, 바로 전달되지 않고 다음 사이클(cycle)에 전달되도록 스케쥴을 구성하는 것을 부분적 병렬 실행이라 합니다. 메시지를 바로 전달할 수 없는 이유는 수신자(receiver)가 다른 쓰레드로 인해 상태가 변경되고 있을 수 있기 때문입니다. 222 | 223 | ## 통신 지연 최소화 (Minimizing Communication Latency) 224 | 225 | 지연 시간은 한 계정에서 다른 계정으로 메시지를 보내고 응답을 받기까지의 시간입니다. 기술적 목표는 두 계정 사이의 메시지 교환이 단일 블록에서 이루어지며 메시지 간 간격이 3초 이내에 들어가게 하는 것입니다. 목표를 달성하기 위해 EOS.IO 소프트웨어는 블록을 사이클 단위로 나눕니다. 각 사이클에는 여러 개의 스레드가 있으며, 각 스레드는 트랜잭션들을 포함합니다. 각각의 트랜잭션은 전달하는 메시지의 집합으로 구성됩니다. 이러한 구조는 트리(tree) 형태로 시각화 가능하며, 레이어 단위로 순차(sequentially) 처리되거나 병렬(parallel) 처리됩니다. 226 | 227 | 블록(Block) 228 | 229 | 사이클(Cycles) (순차 처리) 230 | 231 | 쓰레드(Threads) (병렬 처리) 232 | 233 | 트랜잭션(Transactions) (순차 처리) 234 | 235 | 메시지(Messages) (순차 처리) 236 | 237 | 수신자 및 계정 알림(Receiver and Notified Accounts) (병렬 처리) 238 | 239 | 240 | 하나의 사이클에서 생성된 트랜잭션들은 이후 사이클 혹은 블록에서 전달됩니다. 블록 생산자는 블록에 지정된 시간(3초)이 지나거나 더 전달할 트랜잭션이 없을 때까지 사이클을 계속 추가합니다. 241 | 242 | 정적 분석(static analysis)으로 한 블록에서 동일 사이클에 같은 계정을 수정하는 2개 이상의 쓰레드를 가진 트랜잭션이 없는지 알 수 있습니다. 없으면, 하나의 블록은 여러 개의 쓰레드로 병렬 처리할 수 있습니다. 243 | 244 | ## 읽기 전용 메시지 처리기 (Read-Only Message Handlers) 245 | 246 | 특정 계정의 메시지는 내부 상태의 수정이 아닌 통과/실패(pass/fail) 기반으로 처리할 때도 있습니다. 이러면 특정 사이클에 하나 이상의 쓰레드가 포함될 경우 해당 작업을 수행하는 메시지 처리기는 병렬 처리가 가능합니다. 247 | 248 | ## 다중 계정의 원자적 트랜잭션 (Atomic Transactions with Multiple Accounts) 249 | 250 | 종종 다수의 계정에 메시지의 전달 및 적용에 대한 원자성(atomicity)을 보장해야 합니다. 이 경우, 두 메시지는 하나의 트랜잭션에 위치하고, 두 계정은 같은 쓰레드에 할당되며, 메시지는 순차적으로 적용됩니다. 이 방식은 성능 면에서 이상적이지 않습니다. 사용량에 대한 "청구(billing)"를 수행할 때 트랜잭션에 참고된 계정의 수 만큼 비용이 청구됩니다. 251 | 252 | 성능과 비용 측면에서 2개 이상의 계정이 참여하는 원자적 트랜잭션을 줄이는 것이 좋습니다. 253 | 254 | ## 블록체인 상태의 부분 검사 (Partial Evaluation of Blockchain State) 255 | 256 | 블록체인 기술의 확장성을 보장하려면 구성 요소는 모듈화되어야 합니다. 애플리케이션의 일부만 사용할 때 전체를 다 구동할 필요는 없습니다. 257 | 258 | 거래소 애플리케이션의 개발자는 거래 상태를 사용자들에게 보여주기 위해 풀 노드(full node)를 구동하여야 합니다. 이러한 거래소 애플리케이션은 소셜 미디어 애플리케이션과 연동하여 동작할 필요가 없습니다. EOS.IO 소프트웨어는 풀 노드가 애플리케이션 중 일부를 한정 지어 구동할 수 있도록 합니다. 전달받은 메시지를 통해 애플리케이션의 상태가 전이되기 때문에, 다른 애플리케이션에서 이루어지는 메시지 전송은 안전하게 무시됩니다. 259 | 260 | 이것은 다른 계정과의 통신에 중요한 의미를 가집니다. 특히 다른 계정의 상태를 동일 기계(machine)로 접근할 수 있다고 가정하면 안 됩니다. 또한, 다른 계정과의 동기화 콜(call)을 호출하도록 로크(lock)를 사용할 때, 다른 계정이 메모리에 상주하지 않으면 이 디자인 패턴은 손상됩니다. 261 | 262 | 계정 간 상태 통신(state communication)은 블록체인의 메시지로 전달되어야 합니다. 263 | 264 | ## 주관적 최선 스케쥴링 (Subjective Best Effort Scheduling) 265 | 266 | EOS.IO 소프트웨어는 블록 생산자가 어떤 계정으로 어떻게 메시지를 보낼지에 대하여 강제할 수 없습니다. 각각의 블록 생산자는 계산 복잡도와 트랜잭션을 처리하기 위한 요구 시간에 대한 주관적인 측정을 수행합니다. 이것은 트랜잭션이 사용자에 의해 생성되거나 스크립트에 의해 자동으로 생성될 때 모두 적용됩니다. 267 | 268 | On a launched blockchain adopting the EOS.IO software, at a network level all transactions are billed a fixed computational bandwidth cost regardless of whether it took .01ms or a full 10 ms to execute it. 블록 생산자가 한 트랜잭션 혹은 계정이 과도한 양의 연산 자원을 사용한다고 판단이 되면 해당 트랜잭션을 본인이 생산하는 블록에 추가하는 것을 거부할 수 있습니다. 물론 이 경우에도 다른 블록 생산자는 그 트랜잭션이 적합하다고 판단하여 처리할 수 있습니다. 269 | 270 | 일반적으로 한명 의 블록 생산자라도 트랜잭션이 리소스 사용 제한을 넘지 않아 적합하다고 간주하면 다른 블록 생산자도 승인하게 됩니다. 그러나, 이 경우 트랜잭션이 받아주는 블록 생산자를 찾기까지 1분 가까운 시간이 소요될 수 있습니다. 271 | 272 | 간혹 블록 생산자가 허용 가능한 범위를 몇 배나 넘어가는 트랜잭션을 블록에 포함 시킬 수도 있습니다. 이 경우 다음 블록 생산자는 그 블록을 아예 거절해버릴 수 있으며, 승인과 거절이 동률인 상태는 다음 블록 생산자에 의해 판결됩니다. 이는 거대 블록으로 인해 네트워크 전파 지연이 발생하는 경우와 차이가 없습니다. 커뮤니티는 이상 패턴을 파악하고 이러한 불량 생산자에게 표를 주지 말아야 할 것입니다. 273 | 274 | 이러한 블록 생산자의 주관적 평가가 있기에 블록체인은 정확하고 명확한 실행 시간 계산의 측정을 하지 않아도 됩니다. 이러한 디자인은 정확한 계수 명령(count instruction)을 요구하지 않으며, 이로 인해 합의를 해치지 않는 최적화 기회가 열리게 됩니다. 275 | 276 | # 토큰 모델과 리소스 사용 (Token Model and Resource Usage) 277 | 278 | **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.** 279 | 280 | 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: 281 | 282 | 1. 대역폭과 로그 저장소 (디스크) 283 | 2. 연산과 연산 로그 (CPU) 284 | 3. 상태 저장소 (램) 285 | 286 | 대역폭과 연산은 즉시 사용과 장기 사용의 2개의 구성요소가 있습니다. 블록체인은 모든 메시지의 로그를 관리합니다. 로그는 저장되며 풀 노드(full node)에 다운로드 됩니다. 메시지의 로그를 통해 모든 애플리케이션의 상태를 재구축할 수 있습니다. 287 | 288 | 메시지 로그로부터 상태를 재구축하기 위해 수행되는 계산을 연산 부채(compudational debt)라 합니다. 만약에 연산 부채가 과다하게 증가하면 블록체인의 상태의 스냅샷(snapshot)을 저장하고, 과거 이력을 제거할 필요성이 생깁니다. 만약에 연산 부채가 너무 빠르게 증가하면 때론 1년의 트랜잭션을 재현하기 위해 6개월의 시간이 필요할 수도 있습니다. 이는 매우 치명적이므로 연산 부채는 주의 깊게 관리되어야 합니다. 289 | 290 | 블록체인 상태 저장소는 애플리케이션 로직이 접근할 수 있는 정보입니다. 이는 계정 잔액과 거래 내용 등의 정보를 담고 있습니다. 만약에 애플리케이션이 특정 상태를 읽는 일이 없다면 굳이 저장할 필요가 없습니다. 예를 들어, 블로그 작성 글의 내용과 댓글 내용은 애플리케이션 로직에 의해 읽히지 않으므로 블록체인 상태에 저장할 필요가 없습니다. 반면에 글/댓글의 존재 여부와 투표 횟수 등의 속성값은 블록체인 상태에 기록되어야 합니다. 291 | 292 | 블록 생산자는 그들이 가용 가능한 대역폭, 연산 능력, 상태 허용량을 알려주어야 합니다. EOS.IO 소프트웨어는 각각의 계정이 3일간 누적한 계약의 토큰 양에 비례하여 자원을 사용하게 허용합니다. 예를 들어, EOS.IO 기반의 블록체인이 출시한 후 한 계정이 배포 가능한 전체 토큰의 1%를 가지고 있으면 해당 계정은 전체 상태 저장소의 1%를 사용할 수 있습니다. 293 | 294 | 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. 295 | 296 | ## 객관적 측정과 주관적 측정 (Objective and Subjective Measurements) 297 | 298 | 연산 사용량의 계측은 성능과 최적화에 큰 영향을 미칩니다. 그러므로 모든 리스스 사용 제한은 궁극적으로 블록 생산자의 개별적인 측정 방식과 알고리즘에 의하여 주관적으로 이루어져야 합니다. 299 | 300 | 객관적으로 측정 가능한 것들도 있습니다. 메시지 전달 수와 내부 데이터베이스에 저장하는 데이터의 양은 객관적으로 측정할 수 있습니다. EOS.IO 소프트웨어는 블록 생산자가 객관적 측정을 위한 같은 알고리즘을 적용할 수 있게 합니다. 물론 주관적 측정 방식을 위한 주관적 알고리즘만 적용하게 할 수도 있습니다. 301 | 302 | ## 수취인 부담 (Receiver Pays) 303 | 304 | 전통적으로, 사업을 하기 위해서는 오피스 공간, 연산 능력, 그 외의 요소들을 구매해야 하며 여기에서 비용이 발생합니다. 고객이 특정 물품을 구매할 때, 벌어들인 이익 일부는 이러한 사업 비용을 결재할 때 사용됩니다. 고객이 직접 사업 비용을 내지는 않습니다. 비슷하게 생각해보면, 어떠한 웹사이트도 고객이 소액결제를 할 때 호스팅 비용을 요구하지 않습니다. 그러므로, 탈중앙화 애플리케이션 역시 고객으로 하여금 블록체인을 사용할 때 블록체인 사용료를 요구하여서는 안 됩니다. 305 | 306 | 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. 307 | 308 | ## 리소스 허용량 위임 (Delegating Capacity) 309 | 310 | 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 give 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. 311 | 312 | ## 토큰의 가치와 트랜잭션 비용의 분리 (Separating Transaction costs from Token Value) 313 | 314 | EOS.IO 소프트웨어의 큰 장점 중 하나는 애플리케이션에서 필요한 대역폭은 어떠한 토큰 가격과도 독립적이라는 것입니다. 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. 315 | 316 | A blockchain using EOS.IO software also awards block producers tokens every time they produce a block. 토큰의 가치는 블록 생산자가 구매할 수 있는 대역폭, 저장소, 연산장치에 영향을 줍니다. 이러한 모델은 토큰 가치의 상승을 이용하여 네트워크 성능을 향상합니다. 317 | 318 | ## 상태 저장 비용 (State Storage Costs) 319 | 320 | 대역폭과 연산 능력은 위임할 수 있지만, 애플리케이션 상태가 제거되기 전까지 애플리케이션 상태 저장소 유지를 위한 토큰을 보유해야 합니다. 만약에 상태가 영원히 유지된다면, 해당 토큰은 순환과정을 통해 효과적으로 제거됩니다. 321 | 322 | 모든 사용자 계정은 어느 정도의 저장 공간이 필요합니다. 그러므로 모든 계정은 최소한의 잔액을 가지고 있어야 합니다. 네트워크의 저장 능력이 향상되면 최소 잔액은 줄어들 것입니다. 323 | 324 | ## 블록 보상 (Block Rewards) 325 | 326 | 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. EOS.IO 소프트웨어는 생산자 보상의 총량이 연 토큰 증가분의 5%를 넘지 못하도록 제한을 걸 수 있습니다. 327 | 328 | ## 커뮤니티 혜택 애플리케이션 (Community Benefit Applications) 329 | 330 | In addition to electing block producers, pursuant to a blockchain based on the EOS.IO software, users can elect 3 community benefit applications also known as smart contracts. 커뮤니티 애플리케이션은 설정된 연간 토큰 공급량에서 블록 생산자에게 지급한 양을 제외한 토큰을 가지게 됩니다. 이 스마트 컨트렉트들이 받는 토큰의 양은 각 어플리케이션이 토큰 소유자들로부터 받은 투표 수에 비례하여 결정됩니다. 선정된 애플리케이션 혹은 스마트 컨트렉트는 토큰 소유자들의 투표 결과에 따라 바뀔 수 있습니다. 331 | 332 | # 거버넌스 (Governance) 333 | 334 | 거버넌스는 사람들이 소프트웨어 알고리즘으로 결정할 수 없는 주관적 문제에 대하여 합의를 이루는 과정을 뜻합니다. An EOS.IO software-based blockchain implements a governance process that efficiently directs the existing influence of block producers. 정의된 가버넌스 과정의 부재로 인해 이전의 블록체인들은 즉흥적이고, 비공식적이고, 때로는 논란을 일으키는 거버넌스 과정을 겪었고 예측할 수 없는 결과가 나타났습니다. 335 | 336 | A blockchain based on the EOS.IO software recognizes that power originates with the token holders who delegate that power to the block producers. 블록 생산자가 가지는 권한은, 계정을 동결하고, 결함이 있는 애플리케이션을 판올림하며, 기본 프로토콜의 변경을 가하는 하드포크를 제안하는 것으로 한정합니다. 337 | 338 | Embedded into the EOS.IO software is the election of block producers. 블록체인의 모든 변경사항은 블록 생산자에 의해 검수받아야 합니다. 만약에 블록 생산자가 토큰 소유자에 반하는 결정을 내린다면 투표에 의해 지위를 상실할 수 있습니다. 블록 생산자가 토큰 소유자의 허가 없이 변경을 가한다면 모든 비생산 풀 노드 검사자(non-producing full-node validators)(거래소 등)들은 변경을 거부할 수 있습니다. 339 | 340 | ## 계정 동결 (Freezing Accounts) 341 | 342 | 가끔 스마트 컨트렉트는 비정상적이거나 예측하지 못한 방식으로 동작하여 의도했던 기능이 동작하지 않을 수 있습니다. 이외에도 비정상적인 양의 리소스를 소비하는 것을 인지하여 애플리케이션이나 계정에 문제가 있음을 알 수 있습니다. 이러한 문제점이 발생했을 때, 블록 생산자는 이러한 상황을 바로 잡을 방법을 가집니다. 343 | 344 | 모든 블록체인의 블록 생산자들은 블록에 포함되는 트랜잭션을 선택하는 능력을 갖추고 있으며, 이를 이용하여 계정을 동결할 수 있습니다. A blockchain using EOS.IO software formalizes this authority by subjecting the process of freezing an account to a 17/21 vote of active producers. 만약에 블록 생산자들이 이 기능을 악용한다면 투표에 의해 지위를 상실할 수 있으며 이 경우 동결된 계정은 복원됩니다. 345 | 346 | ## 계정 코드 변경 (Changing Account Code) 347 | 348 | 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. 계정 동결과 유사하게 코드의 교체 작업은 선출된 블록 생산자들 간의 17/21 투표가 필요합니다. 349 | 350 | ## 약관 (Constitution) 351 | 352 | EOS.IO 소프트웨어는 블록체인에서 P2P 서비스 약정을 체결하거나, 서명 한 사용자 간의 구속력 있는 계약인 "약관"을 수립하도록 합니다. 약관으로 코드로 제약을 가하기 어려운 사용자 간의 의무를 규정하며, 상호 간의 관할권을 확립하고 법률을 제정함으로 분쟁 해결을 쉽게 합니다. 네트워크로 전파되는 모든 트랜잭션은 약관의 해시(hash)를 서명에 포함해야 하며, 이를 통해 서명자가 명시적으로 계약에 구속되도록 합니다. 353 | 354 | 약관은 사람이 읽을 수 있는 형식으로 소스코드 프로토콜의 의도를 정의합니다. 이를 통해 오류가 발생하였을 때 버그와 기능의 차이를 인식할 수 있도록 하며, 커뮤니티가 수정사항이 적합한지 아닌지 판단하도록 해줍니다. 355 | 356 | ## 프로토콜과 약관의 개정 (Upgrading the Protocol & Constitution) 357 | 358 | The EOS.IO software defines a process by which the protocol as defined by the canonical source code and its constitution, can be updated using the following process: 359 | 360 | 1. 블록 생산자들은 약관의 개정을 제안하고 17/21 승인을 받습니다. 361 | 2. 블록 생산자들은 17/21 승인을 30일간 유지합니다. 362 | 3. 모든 사용자는 새 약관의 해시를 사용하여 거래에 서명해야 합니다. 363 | 4. 블록 생산자들은 약관의 변화를 반영하도록 소스 코드의 변경을 채택하며, git 커밋의 해시값을 이용하여 블록체인에 제안합니다. 364 | 5. 블록 생산자들은 17/21 승인을 30일간 유지합니다. 365 | 6. 코드 변경은 7일간의 소스코드 적용 유예기간을 주며, 7일이 지난 이후 적용됩니다. 366 | 7. 새 코드로 판올림하지 않은 노드는 강제로 종료됩니다. 367 | 368 | EOS.IO 소프트웨어의 기본 설정에 따르면, 새로운 기능을 추가하는 블록체인의 판올림 작업은 23달이 걸리며, 약관의 개정이 필요 없는 치명적이지 않은 버그의 수정은 12달 소요됩니다. 369 | 370 | ### 응급 변경 (Emergency Changes) 371 | 372 | 치명적인 버그나 공격자로 인한 보안 문제가 발생할 경우 블록 생산자는 판올림 과정을 빠르게 해야합니다. 일반적으로 새로운 기능을 도입하거나 치명적이지 않은 버그를 수정하기 위해 판올림을 빠르게 하는 것은 약관에 어긋납니다. 373 | 374 | # 스크립트와 가상 머신 (Scripts & Virtual Machines) 375 | 376 | EOS.IO 소프트웨어는 인증된 메시지를 계정으로 전달하는 과정을 조정하는 최초이자 가장 중요한 플랫폼입니다. 스크립트 언어와 가상 머신(virtual machine)의 세부 내용은 EOS.IO의 기술 설계와 독립적인 세부 구현 사항입니다. EOS.IO 소프트웨어 API를 이용하여 어떠한 언어나 성능을 보장하는 샌드박스 처리되며 결정론적으로 동작하는 가상 머신을 통합할 수 있습니다. 377 | 378 | ## 스키마 정의 메시지 (Schema Defined Messages) 379 | 380 | 계정 간의 모든 메시지는 블록체인 합의 상태의 일부인 스키마(schema)에 따라 정의됩니다. 이 스키마는 바이너리와 JSON 형식의 메시지의 경계 없는(seamless) 대화를 허용합니다. 381 | 382 | ## 스키마 정의 데이터베이스 (Schema Defined Database) 383 | 384 | 데이터베이스 상태는 유사한 스키마를 이용하여 정의됩니다. 모든 애플리케이션에서 저장되는 모든 데이터는 사람이 읽을 수 있는 JSON으로 처리될 뿐만 아니라 효율적인 바이너리 형태로 저장 관리됨을 보장합니다. 385 | 386 | ## 애플리케이션과 인증 분리 (Separating Authentication from Application) 387 | 388 | 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: 389 | 390 | 1. 메시지의 내적 일관성(internal consistency) 검증 391 | 2. 모든 전제 조건의 유효성 검증 392 | 3. 애플리케이션 상태의 변경 393 | 394 | 메시지의 내적 일관성 검증은 읽기 연산으로만 구성되며, 블록체인 상태에 대한 확인을 요구하지 않습니다. 이는 최대한의 병렬성을 가질 수 있음을 뜻합니다. 요구불 잔액 확인과 같은 전제 조건의 유효성 검증 역시 읽기 연산만으로 구성되며, 병렬 처리의 이점을 가지게 됩니다. 오직 애플리케이션 상태 변경만 쓰기 연산을 해야 하며, 각각의 애플리케이션마다 순차적으로 처리되어야 합니다. 395 | 396 | 인증(authentication)은 메시지의 적용 가능 여부를 검증하는 읽기 연산 작업입니다. 애플리케이션은 실제 작업을 수행합니다. 두 가지 계산은 실시간으로 수행되어야 하지만 트랜잭션이 블록체인에 포함되었다면 더 이상 인증 작업을 수행할 필요가 없습니다. 397 | 398 | ## 가상 머신 독립 아키텍처 (Virtual Machine Independent Architecture) 399 | 400 | It is the intention of the EOS.IO software-based blockchain that multiple virtual machines can be supported and new virtual machines added over time as necessary. 그러므로 본 백서에서는 특정 언어나 가상머신에 세부적인 내용에 관하여 기술하지 않습니다. That said, there are two virtual machines that are currently being evaluated for use with an EOS.IO software-based blockchain. 401 | 402 | ### 웹어셈블리 (WASM; Web Assembly) 403 | 404 | 웹어셈블리는 고성능의 웹 애플리케이션을 제작하기 위하여 새로이 등장한 웹 표준입니다. 웹어셈블리을 일부 수정하여 결정론적이며 샌드박스인 형태로 만들 수 있습니다. 웹어셈블리의 장점은 산업 현장에서 폭넓게 수용되고 있으며, 친숙한 언어인 C나 C++로 컨트렉트를 개발할 수 있습니다. 405 | 406 | 이더리움 개발자들은 [Ethereum flavored Web Assembly (EWASM)](https://github.com/ewasm/design) 으로 웹어셈블리를 수정하여 샌드박싱하고 결정론적으로 변환하는 작업에 착수하였습니다. EWASM은 EOS.IO 소프트웨어에 쉽게 적용하고 통합할 수 있습니다. 407 | 408 | ### 이더리움 가상 머신 (EVM; Ethereum Virtual Machine) 409 | 410 | 이 가상머신은 현존하는 대부분의 스마트 컨트렉트를 구동할 수 있으며, 이를 이용하여 그들의 작업물을 EOS.IO 블록체인에 적용할 수 있습니다. It is conceivable that EVM contracts could be run within their own sandbox inside an EOS.IO software-based blockchain and that with some adaptation EVM contracts could communicate with other EOS.IO software blockchain applications. 411 | 412 | # 블록체인 간 통신 (Inter Blockchain Communication) 413 | 414 | EOS.IO 소프트웨어는 블록체인 간 통신이 쉽도록 설계되었습니다. 이는 메시지 존재 증명과 메시지 순서 증명의 생성을 손쉽게 함으로 이루어집니다. 이러한 증명들은 메시지 전달을 감싸는 애플리케이션 아키텍처와 결합하여 블록체인간 통신과 증명 검증 과정이 애플리케이션 개발자로부터 은닉되도록 합니다. 415 | 416 | 417 | 418 | ## 경량화된 클라이언트 검증(LCV)을 위한 머클 증명 (Merkle Proofs for Light Client Validation) 419 | 420 | 클라이언트가 모든 트랜잭션을 처리할 필요가 없을 때 블록체인들을 결합하는 것이 쉬워집니다. 사실, 모든 거래소는 전체 블록체인 중 거래소의 입/출금에 대해서만 관리하면 됩니다. 교환 체인(exchange chain)의 입금 이력에 대한 경량화된 머클 증명을 이용하는 것은 블록 생산자 전체에 대한 신뢰성을 유지하는 것 보다 이상적입니다. 적어도 해당 체인의 블록 생산자들은 다른 블록체인과 동기화를 위해 최소한의 연산 부담을 받길 원합니다. 421 | 422 | LCV(경량화된 클라이언트 검증)의 목표는 상대적 경량 데이터 집합을 보고 있는 누구든지 검증할 수 있는 상대적 경량 증명을 만들 수 있게 하는 것입니다. 특정 트랜잭션이 어떤 블록에 포함되어 있고, 그 블록이 블록체인의 인증 이력(verified history)에 포함되어 있는지를 증명하는 것을 목표로 합니다. 423 | 424 | 비트코인은 모든 노드가 블록 헤더에 기록된 4MB 가량의 모든 기록을 접근하는 것을 가정하고 트랜잭션의 검증을 수행합니다. 초당 10개의 트랜잭션이 발생할 경우, 유효한 증명(valid proof)은 512 바이트를 필요로 합니다. 10분의 블록 간격을 가지는 블록체인에서 이 방법은 사용할 수 있지만, 3초의 블록 간격을 가지는 블록체인에는 "경량"이 아닙니다. 425 | 426 | EOS.IO 소프트웨어는 트랜잭션이 바뀌지 않는(irreversible) 블록 헤더에 포함된 이후, 해당 블록 헤더를 가진 누구나 경량 증명을 가능하게 합니다. 아래에 보이는 해쉬 연결 구조(hash-linked structure)를 이용하여 1,024바이트 이하의 증명(proof)을 가지는 모든 트랜잭션에 대한 존재 증명(existance prove)이 가능합니다. 유효성 검사 노드가 지난 하루 간(2MB의 데이터)의 모든 블록 헤더를 유지한다 가정하면, 트랜잭션의 검증을 위해서 200바이트의 증명이면 충분합니다. 427 | 428 | 경량 검증 방식을 도입하기 위해 적절한 해쉬-연결(hash-linking)이 포함된 블록을 생성하는 것의 추가 비용은 매우 적으므로, 이 방식으로 블록을 생성하지 않을 이유는 없습니다. 429 | 430 | 다른 체인에 속한 증명들을 검증할 경우 다양한 연산 시간/공간/대역폭 최적화가 가능합니다. 모든 블록 헤더(연간 420MB)의 추적(tracking)은 증명의 크기를 작게 유지하게 할 것입니다. 최근 발생한 헤더만 추적하는 것은 장기적 관점의 저장소 관리와 증명 크기 간의 절충이 발생합니다. 대안으로, 블록체인은 과거 증명의 중간 해쉬를 기억하는 지연 평가(lazy evaluation) 방식을 사용할 수 있습니다. 새로운 증명은 이미 알려진 희소 트리(sparse tree)에 대한 링크를 포함하면 됩니다. 어떤 방식을 사용할지는 머클 증명을 참조하는 트랜잭션을 포함하는 외부 블록의 비율에 따라 결정됩니다. 431 | 432 | 상호 연결이 일정 비율 이상 이루어진다면, 단순하게 다른 체인의 모든 블록 기록을 해당 체인이 가지게 하여 검증을 위해 두 체인을 볼 필요가 없게 하는 것이 효율적입니다. 성능 관점에서 체인 간 증명의 비율을 낮추는 것이 좋습니다. 433 | 434 | ## 체인 간 통신의 지연 시간 (Latency of Interchain Communication) 435 | 436 | 외부의 다른 블록체인과 통신할 때, 블록 생산자는 적합한 입력값으로 받아들이기 이전에 다른 블록체인에서 바뀌지 않는 확인 상태에 돌입하였음을 100% 확신할 때까지 기다려야 합니다. Using an EOS.IO software-based blockchain and DPOS with 3 second blocks and 21 producers, this takes approximately 45 seconds. If a chain's block producers do not wait for irreversibility it would be like an exchange accepting a deposit that was later reversed and could impact the validity of the blockchain's consensus. 437 | 438 | ## 완전성 증명 (Proof of Completeness) 439 | 440 | 블록체인 외부의 머클 증명을 사용할 때, 모든 트랜잭션이 수행 된 것을 확인하는 것과 무시하거나 빠진 트랜잭션이 없음을 확인하는 것은 상당한 차이가 있습니다. 최근의 모든 트랜잭션을 모두 알고 있음을 증명하기는 불가능하지만, 트랜잭션 이력의 빈틈(gap)이 없음을 증명하는 것은 가능합니다. EOS.IO는 모든 계정간 메시지 전달에 순서 번호를 부여하여 이를 가능하게 합니다. 사용자는 특정 계정에 대한 모든 메시지가 정상적으로 처리되었으며, 순서에 맞추어 처리되었음을 증명할 때 이러한 순서 번호를 사용할 수 있습니다. 441 | 442 | # 결론 (Conclusion) 443 | 444 | EOS.IO 소프트웨어는 검증된 개념과 실질적인 경험을 통해 설계되었으며, 블록체인 기술의 근본적인 발전을 대표하는 제품입니다. 이 소프트웨어는 전 세계적 규모의 블록체인의 탈중앙화 애플리케이션을 쉽게 구현하고 운영(governing)하는 전체적인 청사진의 일부입니다. -------------------------------------------------------------------------------- /ru-RU/TechnicalWhitePaper.md: -------------------------------------------------------------------------------- 1 | # EOS.IO, техническая белая бумага 2 | 3 | **26 июня 2017, переведено @blockchained (https://steemit.com/@blockchained)** 4 | 5 | **Аннотация:** EOS.IO представляет собой программный комплекс, реализованный в новой блокчейн-архитектуре и позволяющий осуществлять вертикальное и горизонтальное масштабирование децентрализованных приложений. Возможность масштабирования достигается путем создания схемы, аналогичной операционной системе, поверх которой предполагается разработка самих приложений. Разрабатываемый программный комплекс включает в себя управление аккаунтами и аутентификацией, базы данных, асинхронный обмен данными, а также управление очередями выполнения для приложений с возможностью распределения задач между сотнями процессорных ядер или целыми [серверными] кластерами. Результатом является технология, представляющая собой блокчейн-архитектуру, масштабируемую до миллионов транзакций в секунду, не требующую от пользователей комиссионных платежей за использование, а также позволяющую развертывать децентрализованные приложения легко и быстро. 6 | 7 | **Замечание: криптографические токены, о которых идет речь в данной белой бумаге это криптографические токены уже работающего под управлением EOS.IO блокчейна. Эти токены не являются ERC-20 совместимыми токенами блокчейна Ethereum, связанными с процессом распределения токенов EOS.** 8 | 9 | Копирайт © 2017 block.one 10 | 11 | Допускается использование, воспроизведение и распространение любых материалов из данного документа для немоммерческого использования, а также в образовательных целях (например, любое использование, не предполагающее вознаграждения или коммерческого применения) без специального разрешения, при условии цитирования оригинального источника и соответствующего упоминания авторских прав. 12 | 13 | **Отказ от ответственности:** Настоящий драфт технической белой бумаги EOS.IO публикуется исключительно в информационных целях. block.One не гарантирует точность или выводы, сделанные в этом документе, и этот документ предоставляется «как есть». block.one не гарантирует точность заключений, сделанных в этой бумаге, выпускает ее "как есть", без гарантий полноты покрытия и явного или неявного гарантирования перечисленных (но не ограниченных ими) условий: (i) коммерческая пригодность, возможность конкретного применения, именования или несоблюдения (прав); (ii) отсутствие ошибок в тексте, возможность использования по конкретному назначению; а также (iii) ненарушение содержимым данной бумаги прав третьих лиц. block.one и любые аффилированные структуры отказываются от любых обязательств и возможного ущерба, причиной которых может стать использование, упоминание или полагание на информацию, содержащуюся в данной бумаге, а также любые рекомендации относительно возможности наступления таких последствий. Ни в коем случае block.one или ее аффилированные лица не несут ответственность ни перед какими лицами или организациями за любой ущерб, убытки, обязательства, издержки или расходы любого рода, будь то прямые или не прямые, косвенные, компенсационные, случайные, фактические, примерные, или понесенные из-за обоснования или планирования работ на основе этой белой бумаги или любого содержания настоящего документе, включая, без ограничений, любые потери бизнеса, доходов, прибыли, данных, доступности, доброй воли или другие нематериальные убытки. 14 | 15 | - [Вступление](#background) 16 | - [Требования к приложениям на блокчейне](#requirements-for-blockchain-applications) 17 | - [Поддержка миллионов пользователей](#support-millions-of-users) 18 | - [Возможность бесплатного использования](#free-usage) 19 | - [Возможность простого обновления и восстановления после сбоев](#easy-upgrades-and-bug-recovery) 20 | - [Скорость отклика](#low-latency) 21 | - [Последовательная производительность](#sequential-performance) 22 | - [Параллельная производительность](#parallel-performance) 23 | - [Алгоритм консенсуса (DPOS)](#consensus-algorithm--dpos-) 24 | - [Подтверждение транзакций](#transaction-confirmation) 25 | - [Транзакции как Доказательство Владения Долей (TaPoS)](#transaction-as-proof-of-stake--tapos-) 26 | - [Аккаунты](#accounts) 27 | - [Сообщения и обработчики](#messages---handlers) 28 | - [Управление правами доступа на основе ролей](#role-based-permission-management) 29 | - [Именованные уровни доступа](#named-permission-levels) 30 | - [Именованные группы обработчиков сообщений](#named-message-handler-groups) 31 | - [Привязка прав доступа](#permission-mapping) 32 | - [Применение прав доступа](#evaluating-permissions) 33 | - [Исходные группы прав доступа](#default-permission-groups) 34 | - [Параллельный разбор прав доступа](#parallel-evaluation-of-permissions) 35 | - [Сообщения с отложенной доставкой](#messages-with-mandatory-delay) 36 | - [Восстановление украденных ключей](#recovery-from-stolen-keys) 37 | - [Детерминированное параллельное выполнение приложений](#deterministic-parallel-execution-of-applications) 38 | - [Минимизация коммуникационной задержки](#minimizing-communication-latency) 39 | - [Только читающие сообщение обработчики](#read-only-message-handlers) 40 | - [Атомарные транзакции с несколькими аккаунтами](#atomic-transactions-with-multiple-accounts) 41 | - [Частичная оценка состояния блокчейна](#partial-evaluation-of-blockchain-state) 42 | - [Субъективное планирование наилучших результатов](#subjective-best-effort-scheduling) 43 | - [Модель токена и использование ресурсов](#token-model-and-resource-usage) 44 | - [Объективные и субъективные измерения](#objective-and-subjective-measurements) 45 | - [Бизнес платит](#receiver-pays) 46 | - [Делегирование мощностей](#delegating-capacity) 47 | - [Отделение стоимости транзакции от ценности токена](#separating-transaction-costs-from-token-value) 48 | - [Стоимость хранения состояния](#state-storage-costs) 49 | - [Вознаграждение за блок](#block-rewards) 50 | - [Полезные сообществу приложения](#community-benefit-applications) 51 | - [Управление](#governance) 52 | - [Замораживание аккаунтов](#freezing-accounts) 53 | - [Изменение кода аккаунта](#changing-account-code) 54 | - [Конституция](#constitution) 55 | - [Обновление Протокола & Конституции](#upgrading-the-protocol---constitution) 56 | - [Экстренные изменения](#emergency-changes) 57 | - [Скрипты & виртуальные машины](#scripts---virtual-machines) 58 | - [Определяемые схемой сообщения](#schema-defined-messages) 59 | - [Определяемая схемой база данных](#schema-defined-database) 60 | - [Отделение аутентификации от приложения](#separating-authentication-from-application) 61 | - [Независимая архитектура виртуальной машины](#virtual-machine-independent-architecture) 62 | - [Web Assembly (WASM)](#web-assembly) 63 | - [Виртуальная машина Ethereum (EVM)](#ethereum-virtual-machine--evm-) 64 | - [Межблокчейновая связь](#inter-blockchain-communication) 65 | - [Доказательство Меркла для проверки легкого клиента (Light Client) (LCV)](#merkle-proofs-for-light-client-validation--lcv-) 66 | - [Задержка связи между блокчейнами](#latency-of-interchain-communication) 67 | - [Доказательство целостности](#proof-of-completeness) 68 | - [Заключение](#conclusion) 69 | 70 | # Вступление 71 | 72 | Технология блокчейн была представлена в 2008 году вместе с запуском валюты биткойн, и с этого момента предприниматели и разработчики пытались обобщить технологию с целью реализации поддержки более широкого спектра приложений в рамках единой блокчейн платформы. 73 | 74 | В то время как многие блокчейн-платформы старались реализовать поддержку функциональных децентрализованных приложений, специализированные платформы, такие как децентрализованная биржа BitShares (2014) и социальная медиа-платформа Steem (2016), превратились в интенсивно используемые сообществом блокчейны с десятками тысяч активных пользователей ежедневно. Такие результаты были достигнуты благодаря увеличению производительности до тысяч операций в секунду, снижению задержки ответа до 1.5 секунд, снижению комиссий, а также предоставлению пользователям тех же возможностей, к которым они уже успели привыкнуть в существующих централизованных сервисах. 75 | 76 | Высокие комиссии и ограничения, накладываемые потребностями в вычислительных мощностях, препятствуют широкому распространению технологии блокчейн и ее адаптации под нужды сообщества. 77 | 78 | # Требования к приложениям на блокчейне 79 | 80 | Для широкого распространения блокчейн-приложений необходима платформа, достаточно гибкая для того, чтобы удовлетворять следующим требованиям: 81 | 82 | ## Поддержка миллионов пользователей 83 | 84 | Выдающиеся компании, такие как Ebay, Uber, AirBnB и Facebook, испытывают потребность в блокчейн-технологии, позволяющей обслуживать миллионы активных пользователей ежедневно. В отдельных случаях приложение просто не может работать до достижения определенного критического количества пользователей, а следовательно, платформа, способная справиться с массовым наплывом пользователей, крайне востребована. 85 | 86 | ## Возможность бесплатного использования 87 | 88 | Разработчикам прийдется быть гибкими и предлагать пользователям бесплатные сервисы; пользователи не должны платить за использование платформы или получать доход от ее сервисов. Бесплатная в использовании платформа, вероятно, сможет получить более широкое распространение. В результате у разработчиков и предпринимателей появится возможность построения эффективных стратегий монетизации. 89 | 90 | ## Возможность простого обновления и восстановления после сбоев 91 | 92 | Предприятиям, разрабатывающим приложения на блокчейне, требуется гибкость для расширения и улучшения функциональности. 93 | 94 | Любое, кроме тривиального, программное обеспечение может содержать ошибки даже после тщательнейших проверок. Платформа должна позволять справляться с неизбежными в процессе ее функционирования проблемами. 95 | 96 | ## Скорость отклика 97 | 98 | Удобство использования диктует потребность в устойчивой обратной связи с задержкой, не превышающей нескольких секунд. Длительные задержки ухудшают впечатление пользователей о блокчейн-приложении в сравнении с существующими аналогами, не базирующимися на блокчейн. 99 | 100 | ## Последовательная производительность 101 | 102 | Некоторые приложения не могут реализовывать параллельные алгоритмы из-за наличия последовательно зависимых шагов. Например, биржевые приложения должны обеспечивать достаточную производительность последовательных вычислений для поддержания высоких объемов [торгов]. Поэтому и разрабатываемая платформа должна иметь высокую производительность последовательных вычислений. 103 | 104 | ## Параллельная производительность 105 | 106 | Крупномасштабным приложениям необходимо распределять нагрузку на несколько процессоров и компьютеров. 107 | 108 | # Алгоритм консенсуса (DPOS) 109 | 110 | EOS.IO использует единственный децентрализованный алгоритм консенсуса, способный удовлетворить потребности в производительности приложений на блокчейне: [Делегированное Доказательство Владения Долей (Delegated Proof of Stake, DPOS)](https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper). Согласно этому алгоритму, обладатели токенов блокчейна, адаптированного под EOS.IO, могут выбирать производителей блоков в ходе непрекращающегося голосования, и любой может решить участвовать в производстве блоков и получить право произвести количество блоков, пропорциональное полученному количеству голосов относительно всех других производителей. В закрытых блокчейнах руководство могло бы использовать токены для найма и увольнения IT персонала. 111 | 112 | В EOS.IO блоки будут создаваться каждые 3 секунды, при этом в каждый момент времени правом создать блок будет обладать только один производитель. Если блок не был создан согласно расписанию, соответствующий отрезок времени пропускается. Если пропущен один или несколько блоков, то в блокчейне остается разрыв в 6 или более секунд. 113 | 114 | В EOS.IO блоки создаются раундами. В одном раунде создается 21 блок. Каждый раунд начинается с выбора 21 уникального производителя. 20 лучших из утвержденных производителей автоматически участвуют в каждом раунде, а один выбирается в соответствии с набранным количеством голосов в сравнении с другими производителями. Выбранные для раунда производители выстраиваются в очередь в соответствии с псевдослучайными номерами, полученными из времени блока. Такое перемешивание производителей призвано обеспечить сбалансированность связей между ними. 115 | 116 | Если производитель пропускает блок и не производит ни одного блока в течение 24 часов, то он исключается из рассмотрения до специального уведомления, которое такой производитель должен послать в блокчейн для подтверждения намерения продолжения работы. Это обеспечивает слаженную работу сети и минимизирует количество пропускаемых блоков путем исключения ненадежных производителей из расписания. 117 | 118 | Обычно DPOS блокчейны не подвержены ветвлению (возникновению форков), т. к. производители блоков не конкурируют между собой, а кооперируются. В случае, если ветвление цепи все-таки происходит, алгоритм консенсуса автоматически переключается на самую длинную последовательность блоков. Эта схема работает, потому что скорость добавления блоков в ветку цепи напрямую зависит от процента разделяющих текущий консенсус производителей блоков. Другими словами, ветка блокчейна с большим количеством производителей просто растет в длину быстрее в сравнении с веткой с меньшим количеством производителей. Более того, производитель блоков не может производить их для нескольких веток одновременно. Производитель, попавшийся за этим занятием, вероятнее всего будет исключен из процесса путем голосования. Для автоматизации исключения нарушителей могут использоваться криптографические доказательства. 119 | 120 | ## Подтверждение транзакций 121 | 122 | В типичных DPOS блокчейнах в работе участвуют все производители блоков. Транзакция может считаться подтвержденной с вероятностью 99.9% в течение 1.5 секунд с момента её отправки. 123 | 124 | Есть вероятность возникновения некоторых экстраординарных ситуаций, вызванных сбоем в ПО, отключением от интернета или намеренным вредительством со стороны производителя блоков - в таком случае возникает ответвление (форк). Для абсолютной уверенности в необратимости транзакции узлу сети может потребоваться дождаться подтверждения от 15 из 21 производителей блоков. Для стандартной конфигурации EOS.IO в нормальных условиях на это потребуется 45 секунд. По умолчанию все узлы будут считать блок необратимым после получения подтверждения от 15 из 21 производителей и не станут переключаться на ветку, в которой нет этого блока, независимо от длины ветки. 125 | 126 | Узел сети имеет возможность предупреждать пользователей о высокой вероятности нахождения на ветке меньшинства уже в течение первых 9 секунд с момента перехода на такую ветку. После 2-х последовательно пропущенных блоков вероятность нахождения узла на ветке меньшинства равна 95%. После 3-х вероятность достигает 99%. Существует возможность создания надежной модели прогнозирования, которая на основе информации об отключенных узлах, недавних рейтингах участия и других факторов могла бы быстро предупреждать пользователей о проблемах. 127 | 128 | Реакция на подобные предупреждения полностью зависит от природы бизнес-транзакций, но самой простой реакцией будет дождаться 15 из 21 подтверждений, после чего предупреждение исчезнет. 129 | 130 | ## Транзакции как Доказательство Владения Долей (TaPoS) 131 | 132 | EOS.IO требует включения в каждую транзакцию хеша от заголовка предыдущего блока. Этот хеш выполняет две функции: 133 | 134 | 1. предотвращает повторение транзакции в ветке, которая не включает в себя упомянутый блок; и 135 | 2. уведомляет сеть о нахождении определенного пользователя и его доли на определенной ветке. 136 | 137 | С течением времени все пользователи прямо подтвердят блокчейн как основной, что делает затруднительной подделку цепи ввиду отсутствия у злоумышленника возможности переноса транзакций из настоящей цепи. 138 | 139 | # Аккаунты 140 | 141 | EOS.IO позволяет использовать в качестве идентификатора аккаунта уникальные, доступные для человеческого восприятия имена длиной от 2 до 32 символов. Имя выбирается создателем аккаунта. Для обеспечения возможности хранения данных счет аккаунта должен быть пополнен минимальной суммой в момент создания. Кроме того, имена аккаунтов могут содержать указатель на пространство имен (namespace), при этом только владелец аккаунта @domain может создавать аккаунты вида @user.domain. 142 | 143 | В контексте децентрализации разработчики приложений будут оплачивать номинальные издержки на создание аккаунтов для своих новых пользователей. Традиционный бизнес уже тратит значительные суммы на привлечение каждого нового клиента, будь то рекламные расходы, бесплатные услуги и т. п. В сравнении с текущими расходами стоимость создания нового аккаунта в блокчейне будет несущественной. К счастью, аккаунты, которые уже были созданы пользователем в других приложениях, регистрировать заново не потребуется. 144 | 145 | ## Сообщения и обработчики 146 | 147 | Каждый аккаунт имеет возможность отправлять структурированные сообщения другим аккаунтам, а также может определять процедуры обработки поступающих сообщений (скрипты). EOS.IO выделяет каждому аккаунту защищенную базу данных, доступ к которой имеют только собственные обработчики сообщений этого аккаунта. Обработчики сообщений могут посылать сообщения другим аккаунтам. Сочетание сообщений и их автоматизированных обработчиков и представляет собой смарт-контракты в EOS.IO. 148 | 149 | ## Управление правами доступа на основе ролей 150 | 151 | Управление правами доступа включает в себя определение наличия прав доступа у сообщений. Простейшей формой управления правами доступа является проверка наличия у транзакции необходимых подписей, однако это предполпгает, что требующиеся подписи уже известны. Обычно власть привязана к некоторым сотрудникам или группам сотрудников, и зачастую разделена на отдельные ветви. EOS.IO предоставляет декларативную систему управления правами доступа, дающую аккаунтам тщательный многоуровневый контроль над тем, кто, что и когда может делать. 152 | 153 | Стандартизация аутентификации и управления правами доступа и отделение их от бизнес-логики приложения являются критически важными факторами. Это делает возможным создание инструментов управления правами доступа в обычных средах разработки, а также обеспечивает широкие возможности для оптимизации производительности. 154 | 155 | Каждый аккаунт может контролироваться комбинацией других аккаунтов и приватных ключей, взвешенной по их долям. Это формирует иерархическую административную структуру, отражающую реальную организацию прав доступа, и делает совместное управление средствами проще, чем когда-либо. Совместное управление само по себе вносит наибольший вклад в безопасность и при правильном применении способно значительно снизить риск кражи путем взлома. 156 | 157 | EOS.IO позволяет аккаунтам задавать комбинации ключей и/или других аккаунтов, которые могут отправлять сообщения определенных типов другим аккаунтам. Например, существует возможность наличия одного ключа для социальных сетей пользователя и другого - для доступа к бирже. Возможна даже передача прав доступа одного аккаунта другому на выполнение действий от его лица без передачи при этом ключей. 158 | 159 | ### Именованные Уровни прав доступа 160 | 161 | 162 | 163 | Аккаунты EOS.IO имеют возможность задавать именованные уровни прав доступа с возможностью наследования разрешений от более высокого уровня (иерархия прав доступа). Каждый именованный уровень доступа определяет единицу администрирования; такая единица при этом представляет собой процедуру проверки мульти-подписи с указанием порогов действия, ключей и/или именованных уровней доступа других аккаунтов. Например, уровень доступа "Друг" может быть установлен для аккаунта, который может контролироваться в равной степени аккаунтами всех друзей пользователя. 164 | 165 | Другим примером может служить блокчейн Steem, имеющий три зафиксированных в коде именованных уровня прав доступа: владелец, активное право, и право на публикацию. Право на публикацию дает возможность осуществлять только социальные действия, такие как голосование и публикация записей, в то время как активное право позволяют делать всё, кроме смены владельца. Право владельца имеет смысл хранить на холодном носителе (не подключенном к сети), т. к. оно дает возможность осуществления с аккаунтом любых действий. Программное обеспечение EOS.IO обобщает такой подход, давая возможность каждому владельцу аккаунта задавать свою собственную иерархию прав доступа, а также группировать действия. 166 | 167 | ### Именованные группы обработчиков сообщений 168 | 169 | EOS.IO обеспечивает каждому аккануту возможность объединять обработчики сообщений в иерархические именованные группы. Такие именованные группы обработчиков могут использоваться другими аккаунтами в процессе конфигурации их настроек уровней доступа. 170 | 171 | Обработчики сообщений верхнего уровня именуются по имени аккаунта, а нижнего - по индивидуальным типам сообщений, которые получает аккаунт. Такие группы могут быть вызваны как **@accountname.groupa.subgroupb.MessageType**. 172 | 173 | Такая модель позволяет биржевому контракту группировать создание и отмену ордеров отдельно от депозитов и вывода. Подобная группировка по биржевому контракту является общепринятой для пользователей бирж. 174 | 175 | ### Привязка прав доступа 176 | 177 | EOS.IO дает возможность каждому аккаунту задавать соответствие Именованных обработчиков сообщений любого аккаунта его Именованному уровню доступа. Например, владелец аккаунта может задать соответствие между своей социальной сетью и группой прав доступа "Друг". С такой привязкой публиковать сообщения в социальной сети владельца аккаунта от его лица имеет право любой друг владельца. И даже несмотря на то, что публикация будет осуществляться от лица владельца, для подписания сообщений друзья будут использовать свои собственные ключи. Это делает возможным определить, кто из друзей использовал аккаунт, и как именно он был использован. 178 | 179 | ### Применение прав доступа 180 | 181 | В процессе доставки сообщения типа **Action** от **@Алисы** к **@Бобу** EOS.IO первым делом проверит, обладает ли **@Алиса** соответствующими правами доступа для **@bob.groupa.subgroup.Action**. В случае, если соответствие не найдено, будут последовательно проверены права на **@bob.groupa.subgroup**, затем **@bob.groupa**, и в конечном итоге, на **@bob**. Если не найдено никаких соответствий, предполагается применение именованной группы разрешений **@alice.active**. 182 | 183 | Как только соответствие найдено, право подписи проверяется с учетом порога мульти-подписи и права именованного разрешения. Если проверка заканчивается неудачно, проверяются родительские разрешения вплоть до прав доступа владельца, **@alice.owner**. 184 | 185 | 186 | 187 | #### Исходные группы прав доступа 188 | 189 | Технология EOS.IO предоставляет всем аккаунтам возможность содержать группу доступа "владелец", члены которой имеют полный доступ ко всем функциям, и группу "активные права доступа", которая может все, кроме изменения группы "владелец". Все прочие группы прав доступа исходят от группы "активные права доступа". 190 | 191 | #### Параллельный разбор прав доступа 192 | 193 | Разбор прав доступа является процессом в режиме "только чтение", а изменение прав осуществляется посредством транзакций, которые вступают в силу только по окончании формирования блока. Это позволяет осуществлять параллельный разбор ключей и разрешений для транзакций. Более того, это также делает возможной проверку всех разрешений до запуска логики самого приложения, результаты работы которой в случае нарушения прав доступа пришлось бы откатить. И наконец, такой подход позволяет проверять разрешения транзакций не в момент их применения, а в момент получения. 194 | 195 | С учетом всего вышесказанного проверка разрешений занимает значительную часть общего процесса проверки транзакции. Распараллеливание и отсутствие возможности внесения каких-либо изменений делает процесс проверки разрешений значительно более производительным. 196 | 197 | В процессе воспроизведения цепочки блоков по логам сообщений с целью восстановления состояния необходимость в повторной проверке разрешений отсутствует. Сам факт того, что транзакция включена в подтвержденный ранее блок, является достаточным, чтобы пропустить этап проверки прав доступа. Это значительно снижает вычислительную нагрузку, связанную с повторным воспроизведением транзакций всегда растущей цепочки блоков. 198 | 199 | ## Сообщения с отложенной доставкой 200 | 201 | Время является критичным компонентом безопасности. В большинстве случаев узнать о том, что приватный ключ был похищен, невозможно до тех пор, пока он не будет использован. Безопасность, основанная на времени, становится еще критичнее в случаях, когда приложение требует хранения ключей на компьютерах, подключенных к сети и использующихся каждый день. EOS.IO дает возможность разработчикам приложений применять определенные сообщения не в момент включения в блок, а с некоторой установленной минимальной задержкой. В течение такой принудительной задержки сообщение может быть отменено. 202 | 203 | В момент рассылки таких сообщений пользователи могут получать оповещения по e-mail или sms. В случае, если сообщение не было авторизовано, пользователь может воспользоваться процедурой восстановления аккаунта и отозвать такое сообщение. 204 | 205 | Время задержки при этом определяется важностью операции, содержащейся в сообщении. Так, оплата кофе может не иметь задержки и быть необратимой через несколько секунд, в то время как покупка недвижимости может потребовать 72 часа в качестве периода для утверждения. Передача самого аккаунта целиком под чье-то управление может занять до 30 дней. Точное значение времени задержки устанавливается разработчиками приложения и пользователями. 206 | 207 | ## Восстановление украденных ключей 208 | 209 | Программное обеспечение EOS.IO дает пользователям возможность восстановить контроль над своим аккаунтом, когда их ключи украдены. Владелец аккаунта может использовать любой ключ владельца, который был активен в течение последних 30 дней, вместе с одобрением своего указанного партнера по восстановлению аккаунта, чтобы переустановить ключ владельца на его аккаунт. Аккаунт партнера по восстановлению не может перезагрузить контроль над аккаунтом без помощи владельца. 210 | 211 | У хакеров нет возможности извлечь выгоду, пытаясь пройти через процесс восстановления, потому что они уже “контролируют” аккаунт. Кроме того, если хакер попробует пройти через процесс, партнер по восстановлению скорее всего потребует идентификации и многофакторной проверки подлинности (телефон и электронная почта). Это скомпрометирует хакера или не даст ему никакой выгоды в процессе. 212 | 213 | Этот процесс очень отличается от простого соглашения с мульти-подписью. В случае с мульти-подписанной транзакцией есть еще другая сторона, которая является частью каждой проведенной транзакции; но в процессе восстановления агент - это только часть восстановительного процесса, и он не имеет власти над ежедневными транзакциями. Это значительно сокращает расходы и юридические обязательства всех участников. 214 | 215 | # Детерминированное параллельное выполнение приложений 216 | 217 | Консенсус блокчейна зависит от детерминированного (воспроизводимого) поведения. Это означает, что все параллельные выполнения должны быть свободны от взаимоисключений или других блокирующих примитивов. В отсутствии блокировок должен быть какой-то способ гарантировать, что все аккаунты могу только читать и записывать их собственные частные базы данных. Это также означает, что каждый аккаунт обрабатывает сообщения последовательно и что параллельность будет на уровне аккаунта. 218 | 219 | В блокчейне на EOS.IO в задачи производителя блоков входит организация доставки сообщений в независимые потоки с целью распараллеливания обработки. Состояние каждого аккаунта зависит только от доставленных ему сообщений. Расписание транзакций - это вывод производителя блоков, оно будет детерминистически выполнено, но процесс его создания не должен быть детерминистическим. Это означает, что производителям блоков можно использовать параллельные алгоритмы для составления расписания транзакций. 220 | 221 | Роль параллельного выполнения такова, что когда скрипт создает новое сообщение, оно не доставляется немедленно, вместо этого его доставка запланирована на следующий цикл. Причина, по которой оно не может быть доставлено немедленно, состоит в том, что получатель может активно изменять собственное состояние в другом потоке. 222 | 223 | ## Минимизация коммуникационной задержки 224 | 225 | Задержка - это время, требующееся для отправки сообщения от одного аккаунта к другому аккаунту, а затем на получение ответа. Цель состоит в том, чтобы позволить двум аккаунтам совершать двухсторонний обмен сообщениями внутри одного блока без трёхсекундного ожидания между каждым сообщением. Чтобы предоставить такую возможность, программное обеспечение EOS.IO делит каждый блок на циклы. Каждый цикл делится на потоки, а каждый поток содержит список транзакций. Каждая транзакция содержит набор сообщений, которые будут доставлены. Эту структуру можно изобразить в виде дерева, где чередующиеся слои обрабатываются последовательно и параллельно. 226 | 227 | Блок 228 | 229 | Циклы (последовательные) 230 | 231 | Потоки (параллельные) 232 | 233 | Транзакции (последовательные) 234 | 235 | Сообщения (последовательные) 236 | 237 | Получатель и уведомленные аккаунты (параллельные) 238 | 239 | 240 | Транзакции, произведенные в одном цикле, могут быть доставлены в любой последующий цикл или блок. Производители блоков будут добавлять циклы в блок, пока время настенных часов не выйдет, или пока не перестанут создаваться новые транзакции для доставки. 241 | 242 | Можно использовать статический анализ блока, чтобы убедиться, что в данном цикле нет двух потоков, содержащих транзакции, которые изменяют один и тот же аккаунт. До тех пор, пока такая инвариантность сохраняется, блок может быть обработан параллельным запуском всех потоков. 243 | 244 | ## Только читающие сообщение обработчики 245 | 246 | Некоторые аккаунты могут быть в состоянии обрабатывать сообщение по схеме прошло/не прошло без изменения его внутреннего состояния. В таком случае эти обработчики могут выполняться параллельно столь долго, насколько читающие сообщение обработчики для конкретного аккаунта включены в один или более потоков в рамках определенного цикла. 247 | 248 | ## Атомарные транзакции с несколькими аккаунтами 249 | 250 | Иногда желательно гарантировать, что сообщения доставлены и приняты несколькими аккаунтами атомарно. В этом случае оба сообщения размещают в одной транзакции, и оба аккаунта будут присвоены одному потоку и сообщения применятся последовательно. Эта ситуация не идеальна для производительности, и когда дело доходит до "выставления счетов" пользователям за использование, они будут начисляться по количеству уникальных аккаунтов, ссылающихся на транзакцию. 251 | 252 | Исходя из соображений производительности и стоимости, лучше всего минимизировать атомарные операции с использованием двух или более часто используемых аккаунтов. 253 | 254 | ## Частичная оценка состояния блокчейна 255 | 256 | Для масштабирования технологии блокчейн необходимо, чтобы компоненты были модульными. Никто не должен запускать всё подряд, особенно если им необходимо использовать только небольшую часть приложения. 257 | 258 | Разработчик биржевого приложения запускает полные узлы с целью отображения состояния биржи для своих пользователей. Этому приложению-бирже не требуется состояние связанности с социальными приложениями. Программное обеспечение EOS.IO позволяет любому полному узлу выбрать любую подгруппу приложений для работы. Сообщения, доставленные другим приложениям, спокойно игнорируются, потому что состояние приложения полностью взято из доставленных ему сообщений. 259 | 260 | Это существенно сказывается на связи с другими аккаунтами. Наиболее значительное влияние оказывает невозможность предположения, что состояние другого аккаунта доступно на этой же машине. Это также означает, что как ни заманчиво включение "блокировок", которые позволяют одному аккаунту синхронно вызывать другой аккаунт, такая схема ломается, если другой аккаунт не находится в памяти. 261 | 262 | Все состояния связи между аккаунтами должны быть переданы через сообщения, включенные в блокчейн. 263 | 264 | ## Субъективное планирование наилучших результатов 265 | 266 | Программное обеспечение EOS.IO не может обязать производителей блоков доставлять любое сообщение любому другому аккаунту. Каждый производитель блоков проводит свою собственную субъективную оценку вычислительной сложности и времени, необходимого для проведения транзакции. Это применяется как для транзакций, созданных пользователем, так и для автоматически созданных скриптом. 267 | 268 | Программное обеспечение EOS.IO предусматривает, что на уровне сети все транзакции оплачиваются фиксированной стоимостью пропускной способности, независимо от того, занимает ли их выполнение .01 ms или полные 10 ms. Однако каждый производитель блоков, использующий программное обеспечение, может рассчитать потребление ресурсов, используя свой собственный алгоритм и измерения. Когда производитель блоков делает вывод, что транзакция или аккаунт потребляет непропорциональное большое количество вычислительной мощности, он попросту отказывается от транзакции, когда производит собственный блок; тем не менее, он всё равно обработает транзакцию, если другие производители блоков сочтут ее действительной. 269 | 270 | В целом, пока хотя бы 1 производитель блоков считает транзакцию действительной и не выходящей за лимиты использования ресурсов, то все остальные производители также примут ее, но поиск транзакцией такого производителя может занять до 1 минуты времени. 271 | 272 | В некоторых случаях производитель может создать блок, включающий транзакции, на порядок превышающие допустимые лимиты. В таком случае следующий производитель блоков может решить отклонить блок, и равный счет будет нарушен третьим производителем. Это ничем не отличается от того, что происходит, когда большой блок становится причиной сетевых задержек. Сообщество заметило бы злоупотребление и в конечном счете удалило бы свои голоса за производителя-мошенника. 273 | 274 | Эта субъективная оценка вычислительных затрат освобождает блокчейн от необходимости четко и детерминировано определять, как долго что-нибудь будет запускаться. Благодаря такой конструкции не нужно четко рассчитывать инструкции, что резко увеличивает возможности для оптимизации без нарушения консенсуса. 275 | 276 | # Модель токена и использование ресурсов 277 | 278 | **Замечание: криптографические токены, о которых идет речь в данной белой бумаге это криптографические токены уже работающего под управлением EOS.IO блокчейна. Эти токены не являются ERC-20 совместимыми токенами блокчейна Ethereum, связанными с процессом распределения токенов EOS.** 279 | 280 | Все блокчейны ограничены в ресурсах и нуждаются в защитной системе. В блокчейне на EOS.IO есть три широких класса ресурсов, потребляемых приложениями: 281 | 282 | 1. Пропускная способность и хранение логов (диск); 283 | 2. Вычисления и вычислительное отставание (CPU); и 284 | 3. Хранилище состояния (RAM). 285 | 286 | Пропускная способность и вычисления состоят из двух компонентов: мгновенного использования и использования в течение длительного срока. Блокчейн хранит журнал всех сообщений и этот журнал хранится и загружается всеми полными узлами. С журналом сообщений возможно восстановление состояния всех приложений. 287 | 288 | Вычислительная задолженность - это расчеты, которые должны быть выполнены для восстановления состояния из журнала сообщений. Если вычислительная задолженность становится слишком большой, тогда возникает необходимость делать снапшоты состояния блокчейна и отбросить прошлую историю блокчейна. Если вычислительная задолженность растет слишком быстро, то воспроизведение одного года транзакций может занять полгода. Поэтому очень важно, чтобы вычислительный долг тщательно контролировался. 289 | 290 | Хранилище состояния блокчейна - это информация, которая доступна из логики приложения. Оно включает в себя такую информацию как реестры ордеров и балансы счетов. Если состояние никогда не читалось приложением, тогда его не следует хранить. К примеру, содержание поста в блоге и комментарии не читаются логикой приложения, значит их не следует хранить в состоянии блокчейна. Между тем существование поста/комментариев, число голосов и другие свойства хранятся как часть состояния блокчейна. 291 | 292 | Производители блоков публикуют свой доступный объем пропускной способности, вычислений и состояния. EOS.IO позволяет каждому аккаунту потреблять процент от доступной мощности, пропорциональный количеству токенов, удерживаемых в заключенном 3-дневном контракте. Например, если запущен блокчейн, основанный на программном обеспечении EOS.IO, и если аккаунт держит 1% от общего количества токенов, распространяемых в соответствии с этим блокчейном, тогда этот аккаунт обладает потенциалом использовать 1% емкости хранилища состояния. 293 | 294 | При внедрении программного обеспечения EOS.IO в уже запущенный блокчейн пропускная способность и вычислительная мощность распределяются на основе частичного резервирования, потому что они являются преходящими (неиспользуемые мощности не могу быть сохранены для использования в будущем). Алгоритм, используемый программным обеспечением EOS.IO, схож с алгоритмом, который используется в Steem для ограничения использования пропускной способности. 295 | 296 | ## Объективные и субъективные измерения 297 | 298 | Как обсуждалось ранее, инструментарий использования вычислений оказывает существенное влияние на производительность и оптимизацию; поэтому, все ограничения на использование ресурсов в конечном счете субъективны и их исполнение контролируется производителями блоков с учетом их индивидуальных алгоритмов и оценок. 299 | 300 | Тем не менее, есть определенные вещи, которые поддаются объективному измерению. Количество доставленных сообщений и размер данных, сохраненных во внутренней базе данных, дешевы для объективного измерения. Программное обеспечение EOS.IO позволяет производителям блоков применять тот же самый алгоритм к этим объективным измерениям, но может применить и более строгие субъективные алгоритмы для более субъективных измерений. 301 | 302 | ## Бизнес платит 303 | 304 | Традиционно, именно бизнес платит за офисное пространство, вычислительную мощность и другие затраты, необходимые для его работы. Клиент покупает у бизнеса определенные продукты, и доход от продаж этого продукта используется для покрытия издержек бизнеса. Аналогично, веб-сайт не обязывает своих посетителей производить микроплатежи за посещение этого веб-сайта, чтобы покрыть расходы на хостинг. Поэтому децентрализованные приложения не должны заставлять своих клиентов напрямую платить блокчейну за его использование. 305 | 306 | Программное обеспечение EOS.IO не требует, чтобы его пользователи платили непосредственно блокчейну за его использование и, следовательно, не ограничивает и не препятствует бизнесам в определении своей стратегии монетизации продуктов. 307 | 308 | ## Делегирование мощностей 309 | 310 | Держатель токенов на блокчейне, запущенном на программном обеспечении EOS.IO, которому не нужно немедленно воспользоваться всей или частью доступной мощности, может отдать или сдать в аренду неиспользуемую пропускную способность другим аккаунтам; производители блоков, работающие на программном обеспечении EOS.IO на таком блокчейне, распознают это делегирование мощности и соответственно распределят пропускную способность. 311 | 312 | ## Отделение стоимости транзакции от ценности токена 313 | 314 | Одним из главных преимуществ программного обеспечения EOS.IO является то, что доступная для приложения пропускная способность полностью независима от цены любого токена. Если владелец приложения держит соответствующее количество токенов на блокчейне с внедренным в него программным обеспечением EOS.IO, тогда приложение может работать бесконечно в пределах фиксированного состояния и пропускной способности. В этом случае разработчики и пользователи не зависят от любых колебаний цен на рынке токена и, следовательно, не зависят от котировок. Другими словами, блокчейн, который использует программное обеспечение EOS.IO позволяет производителям блоков естественно увеличивать пропускную способность, вычислительную мощность и имеющееся у токена место для хранения данных независимо от его ценности. 315 | 316 | Блокчейн, который использует программное обеспечение EOS.IO также вознаграждает производителей блоков токенами каждый раз, когда они производят блок. Ценность токенов влияет на суммарную пропускную способность, место для хранения и вычислительную мощность, которую производитель может позволить купить. Эта модель естественно использует возрастающую стоимость токенов для повышения производительности сети. 317 | 318 | ## Стоимость хранения состояния 319 | 320 | В то время как пропускная способность и вычислительная мощность может быть делегирована, хранение состояния приложения потребует от разработчика приложения держать токены до тех пор, пока состояние не будет удалено. Если состояние никогда не будет удалено, то токены будут эффективно изъяты из обращения. 321 | 322 | Каждый пользовательский аккаунт требует определенного места для хранения; таким образом, каждый аккаунт должен поддерживать минимальный баланс. С увеличением емкости хранилища сети этот минимальный требуемый баланс будет уменьшаться. 323 | 324 | ## Вознаграждение за блок 325 | 326 | Блокчейн на программном обеспечении EOS.IO будет вознаграждать производителя блоков новыми токенами каждый раз, когда он производит блок. В таких обстоятельствах количество созданных токенов определяется средней желаемой платой, опубликованной всеми производителями блоков. В настройках программного обеспечения EOS.IO можно задать ограничение на вознаграждение производителей, чтобы общее годовое увеличение запаса токенов не превышало 5%. 327 | 328 | ## Полезные сообществу приложения 329 | 330 | Помимо избрания производителей блоков, основываясь на блокчейне на программном обеспечении EOS.IO, пользователи могут выбрать 3 полезных сообществу приложения, также известных как смарт-контракты. Эти 3 приложения будут получать токены до заданного процента от общего количества токенов в год минус токены, которые были выплачены производителям блоков. Эти смарт-контракты будут получать токены пропорционально количеству голосов, которое было получено каждым приложением от держателей токенов. Выбранные приложения или смарт-контракты могут быть заменены вновь избранными приложениями или смарт-контрактами владельцами токенов. 331 | 332 | # Управление 333 | 334 | Управление - это процесс, с помощью которого люди достигают консенсуса по субъективным вопросам, которые не могут быть полностью охвачены алгоритмами программного обеспечения. Блокчейн на программном обеспечении EOS.IO реализует процесс управления, который эффективно руководит существующим влиянием производителей блоков. Отсутствие четко определенного процесса управления в предшествующих блокчейнах, как и полагание на специальные, неофициальные и часто противоречивые процессы управления приводит к непредсказуемым результатам. 335 | 336 | Блокчейн на программном обеспечении EOS.IO признает, что власть исходит от держателей токенов, которые делегируют эту власть производителям блоков. Производителям блоков даются ограниченные и проверяемые полномочия по замораживанию аккаунтов, обновлению дефектных приложений и внесению предложений о хардфорках в базовый протокол. 337 | 338 | Процесс выбора производителей блоков встроен в программное обеспечение EOS.IO. Прежде чем какое-либо изменение будет внесено в блокчейн, эти производители блоков должны одобрить его. Если производители блоков отказываются вносить изменения по желанию держателей токенов, тогда они могут быть устранены. Если производители блоков вносят изменения без разрешения держателей токенов, тогда все остальные не производящие заверители полных узлов (биржи и т. п.) отклонят изменения. 339 | 340 | ## Замораживание аккаунтов 341 | 342 | Иногда смарт-контракт ведет себя аномальным и непредсказуемым образом и не выполняет своего назначения. В других случаях приложение или аккаунт может найти уязвимость, что позволит ему потреблять слишком много ресурсов. На случай неминуемого возникновения таких проблем у производителей блоков есть власть для улаживания подобных ситуаций. 343 | 344 | Производители блоков во всех блокчейнах имеют право сами выбирать, какие транзакции включаются в блоки, что дает им возможность замораживать аккаунты. Блокчейн на программном обеспечении EOS.IO формализует это влияние, предлагая процесс замораживания аккаунта при наличии 17 из 21 голоса активных производителей. Если производители злоупотребляют властью, они могут быть устранены, и аккаунт будет разморожен. 345 | 346 | ## Изменение кода аккаунта 347 | 348 | Когда всё остальное не возымело результата и “неостановимое приложение” продолжает действовать в непредсказуемой манере, блокчейн на программном обеспечении EOS.IO позволяет производителям блоков заменить код аккаунта без хардфорка всего блокчейна. Подобно процессу заморозки аккаунта, эта замена кода требует 17 из 21 голоса избранных производителей блоков. 349 | 350 | ## Конституция 351 | 352 | Программное обеспечение EOS.IO позволяет блокчейнам установить peer-to-peer условия использования или юридически обязывающий для подписавших его пользователей договор, называемый "конституцией". Содержание этой конституции определяет обязательства среди пользователей, которые не могут быть полностью исполнены кодом, и облегчает урегулирование споров путем установления юрисдикции и избранного права наряду с другими взаимно принятыми правилами. Каждая транслируемая в сеть транзакция должна содержать хэш конституции как часть подписи и тем самым явным образом связывать подписавшего с договором. 353 | 354 | Конституция также читаемо определяет назначение протокола исходного кода. Это назначение используется для определения разницы между багом и функцией, когда возникают ошибки, и руководит сообществом при выборе метода исправления. 355 | 356 | ## Обновление Протокола & Конституции 357 | 358 | Программное обеспечение EOS.IO задает процесс, в котором протокол, определенный каноническим исходным кодом и его конституцией, может быть обновлен следующим образом: 359 | 360 | 1. Производители блоков предлагают изменения конституции и получают 17/21 голосов одобрения. 361 | 2. Производители блоков поддерживают одобрение 17/21 в течение 30 дней подряд. 362 | 3. Все пользователи обязаны подписывать транзакции, используя хэш новой конституции. 363 | 4. Производители блоков вносят соответствующие изменения в исходный код, чтобы отразить изменения конституции, и предлагают их блокчейну, используя хэш гита изменений кода. 364 | 5. Производители блоков поддерживают одобрение 17/21 в течение 30 дней подряд. 365 | 6. Изменения в коде вступают в силу 7 дней спустя, давая всем полным узлам одну неделю для обновления после ратификации исходного кода. 366 | 7. Все узлы, не перешедшие на новый код, автоматически отключаются. 367 | 368 | По умолчанию в конфигурации программного обеспечения EOS.IO процесс обновления блокчейна для добавления новых функций занимает от 2 до 3 месяцев, а время обновления для исправления некритичных ошибок, не требующих изменения конституции, составляет от 1 до 2 месяцев. 369 | 370 | ### Экстренные изменения 371 | 372 | Производители блоков могут ускорить процесс, если изменение в программном обеспечении требуется для устранения опасной ошибки или уязвимости в безопасности, которая активно вредит пользователям. Вообще говоря, ускоренные обновления для внедрения новых функций или устранения мелких ошибок могут не соответствовать установленной конституции. 373 | 374 | # Скрипты & виртуальные машины 375 | 376 | Программное обеспечение EOS.IO станет первой и передовой платформой для координации доставки подлинных сообщений аккаунтам. Детали скриптового языка и виртуальной машины относятся к деталями внедрения, которые по большей части независимы от архитектуры технологии EOS.IO. Любой детерминистический язык или виртуальная машина, правильно собранные и обладающие достаточной производительностью, могут быть интегрированы с API программного обеспечения EOS.IO. 377 | 378 | ## Определяемые схемой сообщения 379 | 380 | Все передаваемые между аккаунтами сообщения определяются схемой, которая является частью состояния консенсуса блокчейна. Эта схема позволяет легко выполнять преобразование между двоичной и JSON системами представления сообщений. 381 | 382 | ## Определяемая схемой база данных 383 | 384 | Состояние базы данных также определяется аналогичной схемой. Это гарантирует, что все данные, хранимые всеми приложениями, записаны в формате, который может быть интерпретирован в читаемый JSON, но хранятся и обрабатываются с эффективностью двоичного языка. 385 | 386 | ## Отделение аутентификации от приложения 387 | 388 | Для максимального использования возможностей распараллеливания и минимизации вычислительного долга, связанного с регенерацией состояния приложения из журнала транзакций, программное обеспечение EOS.IO разделяет логику проверки на три раздела: 389 | 390 | 1. Проверка того, что сообщение является внутренне согласованным; 391 | 2. Проверка того, что все предварительные условия действительны; и 392 | 3. Изменение состояния приложения. 393 | 394 | Проверка внутренней согласованности сообщения доступна только для чтения и не требует доступа к состоянию блокчейна. Это значит, что она может производиться с максимальным параллелизмом. Проверка предварительных условий, таких как требуемый баланс, доступна только для чтения и поэтому также может выигрывать от параллелизма. Только изменение состояния приложения требует доступа с правом записи и должно обрабатываться последовательно для каждого приложения. 395 | 396 | Аутентификация - это доступный только для чтения процесс проверки того, что сообщение может быть применено. На самом деле приложение делает всю работу само. В режиме реального времени должны быть выполнены оба вычисления, однако как только транзакция включена в блокчейн, необходимость выполнять операции проверки подлинности отпадает. 397 | 398 | ## Независимая архитектура виртуальной машины 399 | 400 | Замысел блокчейна на программном обеспечении EOS.IO состоит в том, что одновременно может поддерживаться несколько виртуальных машин, и новые виртуальные машины добавляются по мере необходимости. По этой причине эта бумага не будет предоставлять детали какого-либо языка или виртуальной машины. Тем не менее есть две виртуальные машины, которые в настоящее время рассматриваются для использования в блокчейне на программном обеспечении EOS.IO. 401 | 402 | ### Web Assembly (WASM) 403 | 404 | Web Assembly является новым веб-стандартом для построения высокопроизводительных веб-приложений. С несколькими небольшими изменениями Web Assembly может быть сделан детерминистическим и стать песочницей. Преимущество Web Assembly - это широкая поддержка со стороны индустрии и то, что он позволяет разработку контрактов на знакомых языках, таких как С или C++. 405 | 406 | Разработчики Эфириума уже начали модифицировать Web Assembly для предоставления соответствующей песочницы и детерминизма в их [Ethereum flavored Web Assembly (WASM)](https://github.com/ewasm/design). Этот подход может быть легко адаптирован и интегрирован в программное обеспечение EOS. 407 | 408 | ### Виртуальная машина Ethereum (EVM) 409 | 410 | Эта виртуальная машина была использована для большинства существующих смарт-контрактов и может быть адаптирована для работы в блокчейне EOS.IO. Вполне возможно, что EVM контракты могут быть запущены в рамках их собственной песочницы внутри блокчейна на программном обеспечении EOS, и что с некоторой адаптацией EVM контракты смогут связываться с другими приложениями на таком блокчейне. 411 | 412 | # Межблокчейновая связь 413 | 414 | Программное обеспечение EOS.IO создано с мыслью облегчить связь между блокчейнами. Это достигается путем упрощения доказательства существования сообщения и доказательства последовательности сообщений. Эти доказательства в сочетании с архитектурой приложения, разработанной для передачи сообщений, позволяют скрыть детали межблокчейновой связи и проверку действительности от разработчиков приложений. 415 | 416 | 417 | 418 | ## Доказательство Меркла для проверки легкого клиента (Light Client) (LCV) 419 | 420 | Интеграция с другими блокчейнами намного проще, если клиентам не нужно обрабатывать все транзакции. В конце концов, биржа заботится только о входящих и исходящих трансферах биржи, и ни о чем больше. Также было бы идеально, если цепь биржи могла бы использовать легковесные доказательства депозита меркла вместо того, чтобы обязательно и полностью доверять собственным производителям блоков. По меньшей мере производители блоков этой цепи захотят понести минимально возможные издержки при синхронизации с другим блокчейном. 421 | 422 | Цель LCV - позволить генерацию относительно легковесных доказательств существования, которые могут быть проверены любым, кто отслеживает относительно легковесный набор данных. В таком случае цель - доказать, что определенная транзакция была включена в определенный блок, и что блок включен в проверенную историю определенного блокчейна. 423 | 424 | Биткоин поддерживает подтверждение транзакций, предполагая, что все узлы имеют доступ к полной истории заголовков блоков, что составляет 4 Мб заголовков в год. С 10 транзакциями в секунду действительное доказательство требует около 512 байт. Это хорошо работает на блокчейне с 10-минутным интервалом между блоками, но это больше не является "легким" для блокчейнов с 3-секундным интервалом. 425 | 426 | Программное обеспечение EOS.IO разрешает пользоваться легковесными доказательствами каждому, кто имеет какой-либо необратимый заголовок блока после точки, где была включена транзакция. Используя хеш-связанную структуру, изображенную ниже, можно доказать существование любой транзакции с доказательством, занимающим менее 1024 байт. Если предполагается, что проверяющие узлы шли одновременно со всеми заголовками блоков весь последний день (2Мб данных), то для подтверждения этих транзакций потребуется только доказательство длиной 200 байт. 427 | 428 | Существует незначительная дополнительная нагрузка, связанная с производством блоков с надлежащими хэш-ссылками, необходимая для указанных доказательств, что означает, что нет ни одной причины не создавать блоки таким способом. 429 | 430 | Когда приходит врем проверить доказательства на других цепях, можно применить множество оптимизаций времени/пространства/пропускной способности. Отслеживание всех заголовков блоков (420 Мб в год) будет сохранять размер доказательств небольшим. Отслеживание же только последних заголовков может предложить компромисс между минимальным долгосрочным хранением и размером доказательств. Аналогично блокчейн может использовать ленивый подход к оценке, где он запоминает промежуточные хэши прошлых доказательств. Новые доказательства должны содержать только ссылки на известное разреженному дереву. Точнее, используемый подход будет обязательно зависим от процента чужих блоков, которые включают транзакции, на которые ссылается доказательство Меркла. 431 | 432 | После определенной плотности взаимосвязей становится более эффективным просто иметь одну цепь, содержащую всю историю блоков другой цепи, и вовсе устранить необходимость доказательства. По причинам производительности идеально было бы минимизировать частоту межблокчейновых доказательств. 433 | 434 | ## Задержка связи между блокчейнами 435 | 436 | Когда идет коммуникация с другим блокчейном, производители блоков должны ждать до тех пор, пока не будет 100% уверенности, что эта транзакция была необратимо подтверждена другим блокчейном, прежде чем принять ее в качестве действительных входных данных. При использовании блокчейна на программном обеспечении EOS.IO и алгоритма DPOS с 3-секундными блоками и 21 производителем это займет около 45 секунд. Если производители блоков цепи не станут ждать необратимости, то это как если бы биржа приняла депозит, который впоследствии был отменен, что могло бы повлиять на действительность консенсуса блокчейна. 437 | 438 | ## Доказательство целостности 439 | 440 | Когда используются доказательства Меркла от других блокчейнов, есть существенная разница между знанием, что все обработанные транзакции являются действительными, и знанием, что ни одной транзакции не было отклонено или пропущено. И если доказать, что все последние транзакции известны, невозможно, то можно доказать, что в истории транзакций не было никаких пробелов. Программное обеспечение EOS.IO облегчает этот процесс, присваивая порядковый номер каждому сообщению, доставленному каждому аккаунту. Пользователь может использовать эти порядковые номера, чтобы доказать, что все сообщения, предназначенные для конкретного аккаунта, были обработаны, и что они были обработаны по порядку. 441 | 442 | # Заключение 443 | 444 | Программное обеспечение EOS.IO разработано с учетом нашего опыта с использованием проверенных концепций и наилучших практик, и представляет собой фундаментально новый уровень в технологии блокчейн. Программное обеспечение является частью цельного плана по построению глобального масштабируемого блокчейн-общества, в котором создавать децентрализованные приложения и управлять ими совсем просто. -------------------------------------------------------------------------------- /zh-CN/TechnicalWhitePaper.md: -------------------------------------------------------------------------------- 1 | # EOS.IO 技术白皮书 2 | 3 | **草案：2017 年 6 月 26 日 (@dayzh (https://steemit.com/@dayzh))** 4 | 5 | **摘要：** EOS.IO 软件引入一种新的区块链架构设计，它使得去中心化的应用可以横向和纵向的扩展。 这通过构建一个仿操作系统的方式来实现，在它之上可以构建应用程序。 该软件提供帐户、身份验证、数据库、异步通信和跨越数百个 CPU 内核或集群的应用程序调度。 由此产生的技术是一种区块链架构，它可以扩展至每秒处理百万级交易，消除用户的手续费，并且允许快速和轻松的部署去中心化的应用。 6 | 7 | **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.** 8 | 9 | Copyright © 2017 block.one 10 | 11 | 未经允许，在非用于商业和教育用途的前提下 (即，除了收取费用或商业目的)，如果注明原始出处并适用声明的版权，任何人可以使用、复制或发布本白皮书内的任何内容。 12 | 13 | **免责声明：** 本 EOS.IO 技术白皮书草案仅供参考。 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. 14 | 15 | - [背景](#background) 16 | - [区块链应用的要求](#requirements-for-blockchain-applications) 17 | - [支持成百上千的用户](#support-millions-of-users) 18 | - [免费的使用](#free-usage) 19 | - [简单升级和 bug 修复](#easy-upgrades-and-bug-recovery) 20 | - [低延时](#low-latency) 21 | - [时序性能](#sequential-performance) 22 | - [并发性能](#parallel-performance) 23 | - [共识算法 (DPOS)](#consensus-algorithm--dpos-) 24 | - [交易确认](#transaction-confirmation) 25 | - [股权证明的交易 (TaPoS)](#transaction-as-proof-of-stake--tapos-) 26 | - [帐户](#accounts) 27 | - [消息 & 处理](#messages---handlers) 28 | - [基于角色的权限管理](#role-based-permission-management) 29 | - [命名的权限级别](#named-permission-levels) 30 | - [命名的消息处理群组](#named-message-handler-groups) 31 | - [权限映射](#permission-mapping) 32 | - [评估权限](#evaluating-permissions) 33 | - [默认权限群组](#default-permission-groups) 34 | - [权限并行评估](#parallel-evaluation-of-permissions) 35 | - [带强制性延时的消息](#messages-with-mandatory-delay) 36 | - [恢复被盗窃的密钥](#recovery-from-stolen-keys) 37 | - [应用程序的确定性并行执行](#deterministic-parallel-execution-of-applications) 38 | - [最小化通信延迟](#minimizing-communication-latency) 39 | - [只读信息的处理](#read-only-message-handlers) 40 | - [多帐户的原子化交易](#atomic-transactions-with-multiple-accounts) 41 | - [区块链状态的部分评估](#partial-evaluation-of-blockchain-state) 42 | - [自主最优调度](#subjective-best-effort-scheduling) 43 | - [Token 模型与资源使用](#token-model-and-resource-usage) 44 | - [客观与主观的度量](#objective-and-subjective-measurements) 45 | - [接收方付费](#receiver-pays) 46 | - [委托能力](#delegating-capacity) 47 | - [分离交易成本与 Token 价值](#separating-transaction-costs-from-token-value) 48 | - [状态存储成本](#state-storage-costs) 49 | - [区块奖励](#block-rewards) 50 | - [社区效益应用](#community-benefit-applications) 51 | - [治理](#governance) 52 | - [冻结帐户](#freezing-accounts) 53 | - [更改帐户代码](#changing-account-code) 54 | - [宪法](#constitution) 55 | - [升级协议 & 宪法](#upgrading-the-protocol---constitution) 56 | - [紧急变更](#emergency-changes) 57 | - [脚本 & 虚拟机](#scripts---virtual-machines) 58 | - [模式定义的消息](#schema-defined-messages) 59 | - [模式定义的数据库](#schema-defined-database) 60 | - [分离授权与应用](#separating-authentication-from-application) 61 | - [虚拟机独立架构](#virtual-machine-independent-architecture) 62 | - [Web 组建 (WASM)](#web-assembly) 63 | - [以太访虚拟机 (EVM)](#ethereum-virtual-machine--evm-) 64 | - [跨链通信](#inter-blockchain-communication) 65 | - [用于轻客户端的 Merkle 证明 (LCV)](#merkle-proofs-for-light-client-validation--lcv-) 66 | - [跨链通信的延时](#latency-of-interchain-communication) 67 | - [完备性证明](#proof-of-completeness) 68 | - [结论](#conclusion) 69 | 70 | # 背景 71 | 72 | 区块链技术是通过 2008 年诞生的比特币货币得以被认知，自从那之后企业家和开发者就不断的尝试推广这一技术，以便在单一的区块链平台上支持更为广泛的应用程序。 73 | 74 | 而一些区块链平台努力的支持可运作的去中心化应用，具体的应用比如 BitShares 去中心化交易所 (2014) 和 Steem 社交媒体平台 (2016) 已经成为每天被成千上万活跃用户重度使用的区块链。 他们能做到这些，是通过性能的提升达到每秒处理上千交易，消除手续费和提供堪比已经存在的中心化服务的用户体验。 75 | 76 | 已存在的区块链平台承担着大量的交易费和有限的可计算能力，这都阻碍了区块链技术的大面积应用。 77 | 78 | # 区块链应用的要求 79 | 80 | 为了赢得广泛的应用，构建在区块链之上的应用需要一个灵活性足以满足以下要求的平台： 81 | 82 | ## 支持成百上千的用户 83 | 84 | 像 Ebay、Uber、AirBnB 和 Facebook 这样企业，他们需要区块链技术能处理每日数以千万的活跃用户。 在某些情况下，除非用户群体达到一个极庞大的量级否则应用并无用武之地，因此一个可以处理极其庞大用户的平台是至关重要的。 85 | 86 | ## 免费的使用 87 | 88 | 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. 一个可以免费供用户使用的区块链平台或许将赢得更为广泛的使用。 开发者和企业可以制订有效的货币化战略。 89 | 90 | ## 简单升级和 bug 修复 91 | 92 | 企业构建区块链基础的应用需要能够为应用增加新特性的灵活性。 93 | 94 | 所有非同凡响的软件都会受到 bug 的影响，即便是经过了最严格意义上的验证。这个平台必须具有足够的鲁棒性以便应对不可避免出现的 bug。 95 | 96 | ## 低延时 97 | 98 | 一个好的用户体验需要延时时间在数秒内就能收到可靠的反馈。 高延时会阻碍用户，并且会让构建在区块链上的应用比已有的非区块链应用缺乏竞争力。 99 | 100 | ## 时序性能 101 | 102 | 一些应用因为顺序依赖关系的执行步骤而不能使用并发算法实现。 比如交易所就需要足够的时序性能来处理很高的交易量，因此高时序性能处理的平台是必须的。 103 | 104 | ## 并发性能 105 | 106 | 大型可扩展应用需要将工作量分配到多 CPU 和计算机之上。 107 | 108 | # 共识算法 (DPOS) 109 | 110 | EOS.IO 软件使用唯一能满足区块链之上应用性能需求的去中心化共识算法，[委托股权证明 (DPOS)](https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper)。 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. 111 | 112 | EOS.IO 软件使得区块准确的每 3 秒生成一个并且在任何时间点都只有一个被授权的生产者来生成区块。 如果一个区块在规定时间之内未被生产出来则这一区块将被跳过。 当一个或多个区块被跳过发生时，在区块链中会有一个 6 秒及以上的间隔。 113 | 114 | 在 EOS.IO 软件中，区块通过 21 名生产者轮流产生。 在每一轮的开始时，21 个唯一的区块生产者被选出。 获票最高的前 20 名自动在没轮被选中，剩余的一个生产者通过得票比例选出。 被选中的生产者通过从区块取到的时间作为伪随机数来打乱其顺序。 打乱顺序是为确保这些生产者与其他生产者保持均衡的连通性。 115 | 116 | 如果一个生产者错过了一个区块并且在过去的 24 小时内没有生产任何的区块，那么它将被从候选中移除，直到它在区块链中通知它要开始再次生产区块的意图。 这样通过最小化区块丢失数量（因被证实不可靠的节点不作为导致）来确保网络操作的稳定性。 117 | 118 | 在一般情况下，一个 DPOS 区块链不会经历任何的分叉，因为区块生产者是通过合作而非竞争的方式来生产区块。 即便真的出现了分叉，共识也将自动的切换到最长的链上。 之所以会这样运作，是因为区块添加到一个区块链分叉的速率与公用同一共识的区块生产者比例是相关的。 换句话说，具有更多生产者的区块链分叉会比拥有较少生产的那一个条增长的速度更快。 而且，没有一个生产者会同时在两个分叉上同时生产区块。 如果一个区块生产者被抓到做这样的事儿，那么这个生产者将很可能被投票投出。 这些双重生产行为对应密码学凭证可以用来自动的删除这些滥用者。 119 | 120 | ## 交易确认 121 | 122 | 通常 DPOS 区块链 100% 会有区块生产者参与。一个交易从广播开始后平均 1.5 秒就可以 99.9% 被认为是确认了。 123 | 124 | 在一些特殊情况下例外，软件出现 bug，网络拥塞，或一个恶意的区块生产者制造了两个或更多的分叉。 为了确保一个交易绝对是不可逆的，一个节点可以选择等待 21 个区块生产者中的 15 个给出确认。 基于通常的 EOS.IO 软件配置，在一般情况下这需要平均 45 秒的时间。 默认情况下，所有的节点将认为当 21 个生产者中有 15 个给出确认后这一区块就是不可逆的了，并且不管长度如何都不会切换到没有这一区块的分叉。 125 | 126 | 在分叉开始的 9 秒内，一个节点就可以警告用户他们极可能正处于分叉中。 在连续丢失 2 个区块后，有 95% 的概率可以确认一个节点处于分叉中。 在连续丢失 3 个区块后就有 99% 的概率确认。 可以通过节点丢失、近期参与比率和其他参数来构建鲁棒性预测模型，从而快速的警告操作者出现了问题。 127 | 128 | 对于这种警告的反应完全取决于商业交易的性质，但最简单的做法就是等待 15/21 的确认直到警告消失。 129 | 130 | ## 股权证明的交易 (TaPoS) 131 | 132 | EOS.IO 软件需要每一个交易包含最近一个区块头的哈希值。这个哈希值有两个目的： 133 | 134 | 1. 防止不包含区块引用的交易在分叉时重放发生；和 135 | 2. 通知网络对应的用户和他们的股份当前在某个具体的分叉上。 136 | 137 | 随着时间的推移，所有的用户直接确认区块链，在这一链条上难以伪造假的链条，因为假的链条根本无法从合法链条上迁移交易。 138 | 139 | # 帐户 140 | 141 | EOS.IO 软件允许所有的帐户使用一个唯一的人类可读的名称来索引，长度在 2 到 32 个字符之间。 这个名称由帐户创建者自己选择。 所有的帐户必须在创建时用极少的帐户余额来注资，从而覆盖存储帐户信息的成本。 帐户名称也支持命名空间，比如 @domain 这个帐户的拥有者是唯一可以创建 @user.domain 帐户的人。 142 | 143 | 在一个去中心化的场景中，应用开发者将会为新用户注册成本买单。 Traditional businesses already spend significant sums of money per customer they acquire in the form of advertising, free services, etc. 比起来，资助一个新的区块链帐户的花费简直微不足道。 值得庆幸的是，对一个已经在另一个应用注册过的用户并不需要再创建新的帐户。 144 | 145 | ## 消息 & 处理 146 | 147 | 每个帐户可以发送结构化的消息给其他的帐户，并且可以定义脚本来处理他们接收到的消息。 EOS.IO 软件给每个帐户提供了只有自己的消息处理脚本能访问的私有数据库。 消息处理脚本同样可以给其他帐户发送消息。 消息和自动化的消息处理的结合决定了 EOS.IO 如何定义智能合约的。 148 | 149 | ## 基于角色的权限管理 150 | 151 | 权限管理涉及判定一条消息是否被正确的授权。 权限管理最简单的形式就是检查一个交易包含必须的签名，但这意味着必须的签名是已知的。 一般情况下，权威必然是独立的个体或者个体组成的群体，并且是被划分开的。 EOS.IO 软件提供了声明式的权限管理系统，通过管理谁可以在什么时间做什么来给用户细力度和高维度的控制。 152 | 153 | 授权和权限管理被标准化和脱离应用的商业逻辑是不可取的。 这使得管理权限的工具得以被开发，既满足常规的需求又为性能优化提供了重要的可能性。 154 | 155 | 每一个帐户可以被任何权重组合的其他帐户和私钥管控。 这创建了分层级的权利结构，这反映了现实中的权限分配方式，并且让多用户共同管理资产变得从未如此简单。 多用户控制是安全最大的贡献者，并且，当用户使用得当，它可以极大的消除因被黑而导致被盗窃的风险。 156 | 157 | EOS.IO software allows accounts to define what combination of keys and/or accounts can send a particular message type to another account. 举个例子，可以指定一个密钥给一个用户的社交媒体账号，同时另一个密钥访问交易所。 甚至可以给其他帐户权限来代表自己而无需分配给他们密钥。 158 | 159 | ### 命名的权限级别 160 | 161 | 162 | 163 | 在 EOS.IO 软件中，帐户可以定义命名的权限级别，每一个是由更高级别的命名权限派生而来。 每一个命名的权限级别定义了一个权威；一个权威是多重签名阈值校验，它包含密钥和／或其他帐户的命名权限级别。 打个比方，一个帐户的“朋友”权限级别可以被设置为由该帐户的任何一个朋友无差别的控制。 164 | 165 | 另一个例子在 Steem 区块链中，它包含三个硬编码的命名权限级别：拥有，活跃和发帖。 发帖权限就只能进行如投票和发帖的社交活动，而活跃权限可以做除了变更拥有之外的所有的事情。 拥有权限的意思是冷存储并且有能力做任何事。 The EOS.IO software generalizes this concept by allowing each account holder to define their own hierarchy as well as the grouping of actions. 166 | 167 | ### 命名的消息处理群组 168 | 169 | EOS.IO 软件允许每个帐户将他们自己的消息组织到一个命名和嵌套的群组中。 这个命名的消息处理群组可以在其他帐户配置他们权限级别时被引用。 170 | 171 | 最高级别的消息处理群组是帐户名称，最低级别的是一个帐户接收到的单独的消息类型。 这些群组可以被这样的方式引用： **@accountname.groupa.subgroupb.MessageType**. 172 | 173 | 在这样的模型之下，交易所合约可以通过将挂单的创建和取消分组，从而与充值提现分离开。 交易所合约的这样分组对用户而言带来了方便。 174 | 175 | ### 权限映射 176 | 177 | EOS.IO 软件允许每个帐户定义从任意帐户的一个命名的消息处理群组与自己的命名的权限级别之间建立映射。 举个例子，一个帐户所有者可以将自己社交媒体应用与自己的“朋友”权限群组建立映射。 有了这个映射，任何朋友可以以这一帐户的身份在这一帐户的社交媒体上发帖。 尽管他们将以帐户所有者的身份发帖，他们仍然使用自己的密钥来签名消息。 这意味着总是可以辨识出是哪一个朋友在以何种方式使用帐户。 178 | 179 | ### 评估权限 180 | 181 | 当 **@alice** 以 "**Action**" 类型发送一条消息给 **@bob** 时，EOS.IO 软件首先会检查 **@alice** 是否为 **@bob.groupa.subgroup.Action** 定义过权限映射。 如果什么都没有找到，紧接着检查 **@bob.groupa.subgroup** 映射，然后是 **@bob.groupa**，最后 **@bob** 将被检查。 如果都没有找到，那么假定映射为命名的权限群组 **@alice.active**。 182 | 183 | 一旦一个映射被识别，则通过阈值多签名流程验证签名权威，并且关联权威与命名的权限。 如果失败了，则跃迁至父权限，直至拥有者权限，**@alice.owner**。 184 | 185 | 186 | 187 | #### 默认权限群组 188 | 189 | 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. 所有其他的全新群组派生自“活动”群组。 190 | 191 | #### 权限并行评估 192 | 193 | 权限评估过程是“只读”的，并且通过交易对权限的变更在一个区块结束之前不会起作用。 这意味着对所有的交易对应的密钥和权限评估可以被并行执行。 此外，这意味着一个快速的权限验证是可行的，它无需启动会引起回滚需求的高成本的应用逻辑。 最后，这意味着交易权限可以被评估即便接收到等待的交易，并且之后无需再重新评估。 194 | 195 | 从各方面考虑，权限验证占据了验证交易计算量的很大比例。 让其只读和普遍的并发处理将会使得性能有一个质的飞跃。 196 | 197 | 当从消息日志中重新生成确定性状态时不再需要重复的权限验证。 事实是一个交易如果被包含近了一个被认为不存在问题的区块时它就有足够的理由跳过这 步这将极大减少因为区块链增长拉去过去记录时的计算量。 198 | 199 | ## 带强制性延时的消息 200 | 201 | 时间是安全中的一个关键组成部分。 在大多数情况下，一个私钥在没有被使用前都无从知晓它是否被偷窃。 当人们有需要密钥的应用在每天联网使用的电脑上运行时，基于时间的安全会更为重要。 EOS.IO 软件让应用开发者可以指明消息必须在被加到一个区块之前等待最小的时间间隙。 During this time they can be cancelled. 202 | 203 | 用户可以在消息广播出去后通过邮件或者文字消息的形式收到通知。 如果他们没有授权，那么他们可以使用帐户恢复流程来恢复帐户，并收回消息。 204 | 205 | 这个必须的延时由操作敏感性决定。 为一杯咖啡付款可以没有任何的延时，几秒之内就不可逆了，而购买一个房子也许需要 72 消失的结算期。 转移整个帐户到一个新的控制可能需要长达 30 天。 具体的延时选择由开发者和用户自己来做选择。 206 | 207 | ## 恢复被盗窃的密钥 208 | 209 | EOS.IO 软件提供给用户一种找回自己失窃密钥控制权的方式。 一个帐户的所有者可以使用过去 30 天任何活跃的拥有者密钥与事先指定的合作者帐户给出的批准来重置自己帐户的密钥。 帐户的恢复合作者在没有所有人帮助的情况下无法重置帐户的控制权。 210 | 211 | 黑客尝试进行恢复流程是无意义的，因为他们已经“控制”了帐户。 此外，就算他们真的进行这一流程，恢复合作者也会询问身份证明和多因素认证 (手机和邮件)。 这会让黑客脱作出让步或者无功而返。 212 | 213 | 这一流程与简单的多重签名有很大差异。 在多重签名中，另一个公司要参与所有转账的执行，但在恢复流程中，它却只在恢复时才起作用对每天的转账无从干预。 这大大的降低了参与者的成本和法律责任。 214 | 215 | # 应用程序的确定性并行执行 216 | 217 | 区块链共识取决于确定性 (可重现的) 的行为。 这意味着所有的并行计算必须是不能互斥或者具有其他锁特性的。 没有了锁就必须有一些方式可以确保所有的帐户只可以读取和写入他们自己的私有数据库。 这也意味着每个帐户处理消息是顺序的，而并发只能在帐户层面进行。 218 | 219 | In an EOS.IO software-based blockchain, it is the job of the block producer to organize message delivery into independent threads so that they can be evaluated in parallel. 每个帐户的状态由且只由发送给它的消息决定。 进度表由区块生产者输出并且会被确定性的执行，但是生成进度表的过程却不一定是确定性的。 这意味着区块生产者可以使用并发算法来调度交易。 220 | 221 | 并行执行的一方面意味着当一个脚本生成了一个新的消息，它不会立即被发送，而被安排在下一个轮训中发送。 不能立马发出的原因是接受者可能在另一个线程中活跃的变更自己的状态。 222 | 223 | ## 最小化通信延迟 224 | 225 | 延迟是一个帐户从发出一条消息给另一个帐户，直到收到回应的这段时间。 我们的目标是在一个单独的区块中包含两个帐户交换消息的来去信息，而不用在每条消息间等待 3 秒钟。 为了做到这一点，EOS.IO 软件将每个区块划分为循环。 每个循环划分为线程，每个线程包含了交易的一个列表。 每一个交易包含了待发送的消息集合。 这个结构可以被可视化为一个树，其中交互层彼此并行，各自被顺序的执行。 226 | 227 | 区块 228 | 229 | 循环 (顺序) 230 | 231 | 线程 (并行) 232 | 233 | 交易 (顺序) 234 | 235 | 消息 (顺序) 236 | 237 | 接受者和被通知帐户 (并行) 238 | 239 | 240 | 在一个循环中生成的交易可以在后续的任何一个循环或者区块中被发送。 区块生产者会持续不断的向区块中添加循环直到最大的墙上时间到了或者没有更多的新交易要发送。 241 | 242 | 可以对一个区块使用静态分析来验证同一个循环内不存在两个线程包含同一帐户下对交易的变更。 只要保持不变一个区块就可以并行的运行所有的线程。 243 | 244 | ## 只读消息的处理 245 | 246 | 有些帐户可以在传递/失败的基础上处理消息而不修改内部状态。 如果是这样的话，那么这些处理程序可以并行执行，只要只有一个特定的帐户的只读消息处理程序包含在一个或多个线程在一个特定的周期。 247 | 248 | ## 多帐户的原子化交易 249 | 250 | 有时我们需要确保消息自动的被多个账户传递和接收。 在这种情况下，消息会被放在同一个交易内，账户会被分配到同一个线程，并且消息被顺序的添加。 这种情况对性能是不理想的，当用户使用涉及到“账单”时，他们将在交易内以账户唯一索引被列入其中。 251 | 252 | 基于性能和成本原因最好减少涉及两个或多个重度帐户的原子性操作。 253 | 254 | ## 区块链状态的部分评估 255 | 256 | 扩展区块链技术使得组件化成为必要。每个人不应该执行所有的事务，尤其是当其只需要运行应用的一个小的子集。 257 | 258 | 一个交易所应用开发者运行一个完整节点位的是为其用户展现所有的状态。 这个交易所应用没有与社交网络建立关联的必要性。 EOS.IO 软件允许任何的完整节点选择应用的任何子集来执行。 传递给其他应用的消息可以被安全的忽略掉，因为应用程序的状态完全由传递给它的消息派生。 259 | 260 | 这与其他帐户的沟通有一些重要的影响。 最重要的是，不能假定其他帐户的状态可以在同一台机器上访问。 这也意味着，虽然很容易启用“锁”来允许一个帐户同步调用另一个帐户，如果其他帐户不驻留在内存中，这种设计模式就会出现问题。 261 | 262 | 所有账户帐户间的状态通信必须通过包含在区块链中的消息进行。 263 | 264 | ## 自主最优调度 265 | 266 | EOS.IO 软件并不能为区块生产生者为任何其他帐户送达的任何信息负责。 每个区块生产者要对计算的发杂读和处理一个消息的时间自己进行主观上的预测。 这同时适用于用户生成的和脚本自动生成的交易。 267 | 268 | On a launched blockchain adopting the EOS.IO software, at a network level all transactions are billed a fixed computational bandwidth cost regardless of whether it took .01ms or a full 10 ms to execute it. 然而，每个单独的区块生产者要通过自己的算法来计算资源的消耗。 当一个区块生产者断定一个交易或者帐户消耗了不相称的大量的计算资源时，他们可以在生成自己的区块时拒绝该交易；但是，如果其他区块生产者认为交易是有效的，他们就仍需要处理交易。 269 | 270 | 一般而言，只要一个区块生产者认为交易在资源使用限度内是有效的，那么其他区块生产者就也要接受，但可能交易传递给生产者就要花费 1 分钟。 271 | 272 | 在某些情况下，生产者可以创建包含可接受范围之外的数量级的块。 在这种情况下，下一个区块生产者可能会选择拒绝区块和束缚将被第三个生产者打破。 这和因为区块过大导致的网络延时没什么打不同。 社区会注意到模式的异常并最终会将票从流氓生产者哪里删掉。 273 | 274 | 这种对计算成本的主观评估将区块链从必须精确和确定的预测一些东西要花多长时间来运行这一问题中解放出来。 有了这一设计就不需要精确的数指令，将极大的增加优化的可能性又不必打破共识。 275 | 276 | # Token 模型与资源使用 277 | 278 | **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.** 279 | 280 | 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: 281 | 282 | 1. 带宽和日志存储 (磁盘)； 283 | 2. 计算与计算储备 (中央处理器)； 284 | 3. 状态存储 (内存)。 285 | 286 | 带宽和计算有两部分，瞬时使用和长期使用。 一个区块链维持着所有消息的日志，这些日志最终由完全节点存储和下载。 通过消息日志可以重现所有应用的状态。 287 | 288 | 可计算债务是一个必须通过消息日志重新构建状态的计算结果。 如果可计算债务增长变得臃肿则有必要通过快照方式记录区块链状态，并丢弃区块链历史。 如果可计算债务增长过快，则它需要花费 6 个月时间来重放等值与 1 年的交易。 这很不可取，因此，可计算债务需要被细心的管理。 289 | 290 | 区块链状态存储是通过访问应用逻辑获取的信息。 它包括诸如挂单和账户余额等信息。 如果状态从未被应用读取则它不会被存储。 比如，博客发布的内容和评论如未被应用逻辑读取则他们就不应该存储在区块链状态中。 同时，发布的内容／评论的存在、投票的数量和其他属性要作为区块链状态的部分被存储下来。 291 | 292 | 区块生产者对外发布她们可用的带宽，计算能力和状态。 EOS.IO 允许帐户按比例消耗一个 3 天对赌合约中的可用资源。 举个例子，如果一个基于 EOS.IO 的区块链启动了，一个帐户持有所有 token 发行总量的 1%，那么帐号就具有使用 1% 状态存储空间的能力。 293 | 294 | 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. 295 | 296 | ## 客观与主观的度量 297 | 298 | 如前所述，检测计算使用的性能和优化的影响很大；因此，所有资源的使用限制，最终都是主观的，执行依靠个人的算法和区块生产者进行估计。 299 | 300 | 也就是说，有一些事情是微不足道的客观衡量。 发送的消息数和存储在内部数据库中的数据的大小是便宜的客观衡量。 的 EOS.IO 软件让区块生产者采用相同的算法应对客观的量，但可以在主观量上选择采用更严格的主观测量算法。 301 | 302 | ## 接收方付费 303 | 304 | 传统上来说，企业为办公场地、计算力和其他为了运行企业而需要的成本买单。 客户从企业购买具体的产品，产品销售产生的利润来盖过企业运作的成本。 类似的，没有哪个网站要求来访者为盖过运作成本而支付。 因此，去中心化应用也不应该强制用户因为使用了区块链而直接为区块链支付。 305 | 306 | 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. 307 | 308 | ## 委托能力 309 | 310 | 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 give 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. 311 | 312 | ## 分离交易成本与 Token 价值 313 | 314 | EOS.IO 软件的一个主要优点就是应用可用的带宽完全独立于 token 的价格。 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. 315 | 316 | A blockchain using EOS.IO software also awards block producers tokens every time they produce a block. Token 的值将影响其能购买的带宽、存储和计算资源；这一模型会自然的利用 token 值的上涨来增加网络的性能。 317 | 318 | ## 状态存储成本 319 | 320 | 由于带宽和计算资源可以被委托，因此应用的状态存储需要应用程序的开发者持有 token 直到状态被删除。 如果状态永远不会被删除那么 token 实质上从流通中被抹除。 321 | 322 | 每一个用户帐户需要一个确定数量的存储；因此每一个帐户必须保持一个最小的余额。随着网络存储能力的不断提升，余额的最小余额需求将会下降。 323 | 324 | ## 块奖励 325 | 326 | 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. EOS.IO 软件可以配置限定生产者回报的上限从而确保 token 的每年增长比例不会超过 5%。 327 | 328 | ## 社区效益应用 329 | 330 | In addition to electing block producers, pursuant to a blockchain based on the EOS.IO software, users can elect 3 community benefit applications also known as smart contracts. 这三个应用将接收至多一个按照配置百分比对应的 token 年供应量减去每年提供给区块生产者的 token 量。 这些智能合约将按照每个应用接收到的 token 持有者的票的比例对应的 token。 这些应用或者智能合约可以被 token 持有者选出的新的应用或智能合约所替代。 331 | 332 | # 治理 333 | 334 | 治理是人们在主观问题上达成共识的过程，而这无法完全用软件算法来捕获。 An EOS.IO software-based blockchain implements a governance process that efficiently directs the existing influence of block producers. 没有了定义好的治理流程，之前的区块链依赖临时的、非正式和常常充满争议的方式治理，直接导致不可预知的结果。 335 | 336 | A blockchain based on the EOS.IO software recognizes that power originates with the token holders who delegate that power to the block producers. 区块生产者被授予有限的检查权威来冻结帐户，升级有缺陷的应用程序，对底层协议提出硬分叉的改进建议。 337 | 338 | Embedded into the EOS.IO software is the election of block producers. 在对区块链没有做任何变更之前他们必须认可它。 如果区块生产者拒绝 token 持有者所预期的变更他们就会被投出。 如果区块生产者未经 token 持有者的授权作出变更，其他的非生产、完整验证 (交易所等) 会拒绝这些变更。 339 | 340 | ## 冻结帐户 341 | 342 | 有时一个智能合约的行为处于一种一场或不可预测的状态并且无法按照预期执行；另一些时候一个应用或帐户也许发现了一个可以销毁不可想像数量资源的漏洞。 当这些问题不可避免的发生时，区块生产者有能力来扭转这一局面。 343 | 344 | 所有区块链上的区块生产者都有能力来决定哪些交易被加到区块中，这给了他们冻结帐户的能力。 A blockchain using EOS.IO software formalizes this authority by subjecting the process of freezing an account to a 17/21 vote of active producers. 如果生产者滥用权利他们会被投出，而对应冻结帐户就将解冻。 345 | 346 | ## 更改帐户代码 347 | 348 | 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. 与冻结一个帐户类似，更改帐户代码需要 17/21 这样的生产者票形。 349 | 350 | ## 宪法 351 | 352 | EOS.IO 应用使得区块链创建了一个点对点的服务条款协议或者绑定用户到一个合约，这都需要用户对其签名，简称“宪法”。 宪法的内容定义了仅仅依靠代码无法在用户间履行的义务，同时通过建立管辖权和可选的法律来解决相互间的争端。 每个在网络广播的交易都必须将宪法的哈希值作为签名的一部分，从而显性的将签名者绑定在合约中。 353 | 354 | 宪法还定义了人类可读意图的源代码协议。 这个意图是用来识别错误和功能之间的差异，当错误发生时，引导社区对什么是适当或不当修复。 355 | 356 | ## 升级协议 & 宪法 357 | 358 | The EOS.IO software defines a process by which the protocol as defined by the canonical source code and its constitution, can be updated using the following process: 359 | 360 | 1. 区块生产者对宪法提出改建意见并获得 17/21 批准。 361 | 2. 区块生产者持续 17/21 品准连续 30 天。 362 | 3. 所有用户需要使用新的宪法来做签名。 363 | 4. 区块生产通过变更代码的方式来影响宪法并且提交一个 git 记录的哈希值。 364 | 5. 区块生产者持续 17/21 品准连续 30 天。 365 | 6. 7 天后改为会起影响的代码，给所有完整节点 1 周时间在确认源码后进行升级。 366 | 7. 所有未升级到最新代码的节点被自动关掉。 367 | 368 | 按照 EOS.IO 的默认配置，添加新特性升级区块链的流程需要 2 到 3 个月，而修复一般的 bug 不需要更改宪法需要 1 到 2 个月时间。 369 | 370 | ### 紧急变更 371 | 372 | 区块生产者可以推荐软件的变更当 bug 是伤害性 bug 或安全溢出影响用户使用的。 一般来说，这可能是对宪法的加速更新，引进新的功能或修复无害的错误。 373 | 374 | # 脚本 & 虚拟机 375 | 376 | EOS.IO 首先会是一个平台用于协同用户间认证消息的传递。 脚本语言和虚拟机的具体实现与 EOS.IO 技术的设计是分离的。 任何语言或者虚拟主机，只要确定并适合沙盒，带有足够的运行效率均可以和 EOS.IO 软件 API 对接。 377 | 378 | ## 模式定义的消息 379 | 380 | 所以用户间发送的消息都是通过模式定义定义出来的，它是区块链共识状态的一部分。 这个模式允许消息在二进制与 JSON 格式之间无缝的转换。 381 | 382 | ## 模式定义的数据库 383 | 384 | 数据库状态也是通过类似的模式来定义。 这是为了确保所有应用存储的数据是可以转化为人类可读的 JSON 但存储和控制时使用高效的二进制。 385 | 386 | ## 分离授权与应用 387 | 388 | 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: 389 | 390 | 1. 验证消息是否内部一致； 391 | 2. 验证所有前提条件是否有效； 392 | 3. 修改应用程序状态。 393 | 394 | 验证消息的内部一致性是只读的并且无需访问区块链状态。 这意味着它可以以最大并发来执行。 验证前提条件，比如需要的余额数，是只读的因此也可以受益与并行计算。 只有更改应用状态时需要写入权限并且必须顺序的执行每个应用。 395 | 396 | 身份认证是一个验证消息可被使用的只读过程。 应用程序实际上在发挥作用。 同一时间两者都需要被计算，然而一旦消息被包含进区块它就不再需要进行消息验证的操作了。 397 | 398 | ## 虚拟机独立架构 399 | 400 | It is the intention of the EOS.IO software-based blockchain that multiple virtual machines can be supported and new virtual machines added over time as necessary. 因此，本文并不讨论任何特定的语言或者虚拟机。 That said, there are two virtual machines that are currently being evaluated for use with an EOS.IO software-based blockchain. 401 | 402 | ### Web 组建 (WASM) 403 | 404 | 网络组建是一种为了构建高性能的 web 应用而新兴的 web 标准。 只需要进行少量的更改 Web 组建就可以被制作为确定性的和沙盒化的。 Web 组建的好处是它有着广泛的产业支持并且它可以让智能合约使用熟知的语言进行开发，比如 C 或 C++。 405 | 406 | 以太访开发者已经开始更改 Web 组建来提供合适的沙盒与确定性在他们的[以太访式 Web 组建 (WASM)](https://github.com/ewasm/design)。 这种方式让 EOS.IO 很容易的与之适配和对接。 407 | 408 | ### 以太访虚拟机 (EVM) 409 | 410 | 这个虚拟机已经被众多已有的智能合约所采用并且可以通过适配应用与 EOS.IO 区块链中。 It is conceivable that EVM contracts could be run within their own sandbox inside an EOS.IO software-based blockchain and that with some adaptation EVM contracts could communicate with other EOS.IO software blockchain applications. 411 | 412 | # 跨链通信 413 | 414 | EOS.IO 软件被设计为跨区块链通信友好的。 这是通过生成消息存在证明与消息时序证明变的简单而实现的。 这些证明与应用架构设计相结合，即围绕消息细节的跨链传输和有效性验证时隐藏应用程序开发者的架构设计。 415 | 416 | 417 | 418 | ## 用于轻客户端的 Merkle 证明 (LCV) 419 | 420 | 如果客户端不需要处理所有的交易会让多区块链间的整合更为轻松。 毕竟，一个交易所只需要关心交易所的入账和出账，别无他求。 如果交易所链条可以使用资金的轻量 merkle 证明，而不必非要完全依赖对它区块生产者的信任会是一个不错的主意。 至少一个链的区块生产者在与其他区块链同步时更乐意保持尽可能小的开销。 421 | 422 | LCV 的目标能产生相对轻量存在性证明，使得任何追踪相对轻量数据集的人可以验证其有效性。 在这种情况下，目的是为了证明一个特定的交易是包含在一个特定的区块中，区块包含在一个特定的区块链的已验证历史中。 423 | 424 | 比特币支持通过全节点的完整记录获取每年 4MB 大小的区块头信息来验证交易。 每秒 10 个交易，一个有效的证明需要 512 个字节。 这对于有 10 分钟间隔的区块链没有问题，但是对于 3 秒间隔区块链就显得不那么“轻量”了。 425 | 426 | EOS.IO 软件使得任何一个人只要他拥有包含交易所对应区块之后的随意一个不可逆的区块头，他就可以进行轻量证明。 使用下面展示的哈希链结构就可以使用少于 1024 字节的大小来完成任意交易的存在性证明。 如果假设校验节点在过去几天内所有的区块头一直增长 (2MB 的数据)，那么验证这些交易将只需要 200 字节就够了。 427 | 428 | 将生产的区块与恰当的哈希链做关联使得开销增幅很小，这意味着没有理由不使用这种方式来生成区块。 429 | 430 | 当需要验证其他链时，有譬如 时间/ 空间/ 带宽 的多样化优化可以做。 追踪全部区块头 (420 MB/年) 将保持证明体积的轻巧。 只追踪最近的头可以提供最小长期存储和证明大小来获得。 另外，一个区块链可以使用懒惰的评估方法，即它记住过去证明的中间值哈希。 新证明只需要包含指向已知稀疏树的链接。 确切的方法将取决于那些包含对 Merkle 证明引用的交易所在的外部区块的比例。 431 | 432 | 一定密度的联系后，将变得更为高效，一个链会包含另一个链整个区块的历史和消除证据一起，这样就不需要通信便可以验证了。 出于性能原因，应最小化的跨链证明的频率。 433 | 434 | ## 跨链通信的延时 435 | 436 | 当与外部区块链进行通信时，区块生产者必须等待直到 100% 确信一个交易已经被另一个区块链确认为不可逆后才会接收它成为一个有效的输入。 Using an EOS.IO software-based blockchain and DPOS with 3 second blocks and 21 producers, this takes approximately 45 seconds. If a chain's block producers do not wait for irreversibility it would be like an exchange accepting a deposit that was later reversed and could impact the validity of the blockchain's consensus. 437 | 438 | ## 完备性证明 439 | 440 | 当使用来自外部区块链的 Merkle 证明时，在已知所有交易均已验证和已知没有交易被跳过或遗忘之间有一个重要的差异。 虽然不可能证明所有最近的交易是已知的，但有没有间隙的交易历史是可以被证明的。 EOS.IO 软件在每个用户的每个传递的消息上分配了一个序列号。 一个用于可以使用这些序列号来证明所有的消息由某个特定帐户处理，只需要看它是否是按序执行的。 441 | 442 | # 总结 443 | 444 | EOS.IO 软件是从证明概念的经验和最佳实践设计而来，它代表了区块链技术的重要进步。 该软件是全球可扩展区块链社会伟大蓝图中的一部分，它将应用去中心化并得以轻松的发布和治理。 --------------------------------------------------------------------------------