diff --git a/README.md b/README.md index 5911f8a8..c3ac1659 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ - [English](TechnicalWhitePaper.md) - [Russian](ru-RU/TechnicalWhitePaper.md) translated by [@blockchained](https://steemit.com/@blockchained) -- [Chinese](zh-CN/TechnicalWhitePaper.md) translated by [@dayzh](https://steemit.com/@dayzh) +- [Chinese](zh-CN/TechnicalWhitePaper.md) translated by [@eureka](https://eureka.name) and other people - [Korean](ko-KR/TechnicalWhitePaper.md) translated by [@clayop](https://steemit.com/@clayop) # EOS Wiki diff --git a/zh-CN/TechnicalWhitePaper.md b/zh-CN/TechnicalWhitePaper.md index 2d05ec65..efe4fd23 100644 --- a/zh-CN/TechnicalWhitePaper.md +++ b/zh-CN/TechnicalWhitePaper.md @@ -1,444 +1,770 @@ -# EOS.IO 技术白皮书 +# EOS.IO Technical White Paper v2 +# EOS.IO 技术白皮书 第二版 -**草案：2017 年 6 月 26 日 (@dayzh (https://steemit.com/@dayzh))** +译者： Harvey老狼，谭智勇，宋承根@OracleChain，梓岑@YOYOW，荆凯，Eureka@ee-studio.com + +整理： Eureka@ee-studio.com (https://eureka.name) 中英文对照版：http://dac.xyz/project/eos/tech_whitepaper + +**March 16, 2018** +**2018年3月16** + +**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. + +**摘要：** EOS.IO软件引入了新的区块链架构，旨在实现去中心化应用的纵向和横向扩展。这是通过创建一个类似操作系统的架构来实现的，可以在上面构建应用。该软件提供了帐户，身份验证，数据库，异步通信以及跨越多个CPU内核或集群的程序调度。该技术的最终形式是一个区块链架构，在治理区块链的场景下，可以最终扩展，足以支持每秒数百万笔交易，消除用户费用，实现去中心化应用的轻松快速地部署和维护。 -**摘要：** EOS.IO 软件引入一种新的区块链架构设计，它使得去中心化的应用可以横向和纵向的扩展。 这通过构建一个仿操作系统的方式来实现，在它之上可以构建应用程序。 该软件提供帐户、身份验证、数据库、异步通信和跨越数百个 CPU 内核或集群的应用程序调度。 由此产生的技术是一种区块链架构，它可以扩展至每秒处理百万级交易，消除用户的手续费，并且允许快速和轻松的部署去中心化的应用。 **PLEASE NOTE: CRYPTOGRAPHIC TOKENS REFERRED TO IN THIS WHITE PAPER REFER TO CRYPTOGRAPHIC TOKENS ON A LAUNCHED BLOCKCHAIN THAT ADOPTS THE EOS.IO SOFTWARE. THEY DO NOT REFER TO THE ERC-20 COMPATIBLE TOKENS BEING DISTRIBUTED ON THE ETHEREUM BLOCKCHAIN IN CONNECTION WITH THE EOS TOKEN DISTRIBUTION.** -Copyright © 2017 block.one +**请注意: 本文中提到的加密代币指的是使用EOS.IO软件所构建的区块链上的加密代币，并不是在EOS 代币发行相关的ETH区块链上的ERC-20兼容代币。** + +Copyright © 2018 block.one + +Without permission, anyone may use, reproduce or distribute any material in this white paper for non-commercial and educational use (i.e., other than for a fee or for commercial purposes) provided that the original source and the applicable copyright notice are cited. + +无需授权，出于非商业目的和教育用途（即，除了收费或商业目的)，任何人都可以使用、复制或者分发本白皮书中的任意材料，需要注明原文出处和适用的版权声明。 + + +**DISCLAIMER:** This EOS.IO Technical White Paper v2 is for information purposes only. block.one does not guarantee the accuracy of or the conclusions reached in this white paper, and this white paper is provided “as is”. block.one does not make and expressly disclaims all representations and warranties, express, implied, statutory or otherwise, whatsoever, including, but not limited to: (i) warranties of merchantability, fitness for a particular purpose, suitability, usage, title or noninfringement; (ii) that the contents of this white paper are free from error; and (iii) that such contents will not infringe third-party rights. block.one and its affiliates shall have no liability for damages of any kind arising out of the use, reference to, or reliance on this white paper or any of the content contained herein, even if advised of the possibility of such damages. In no event will block.one or its affiliates be liable to any person or entity for any damages, losses, liabilities, costs or expenses of any kind, whether direct or indirect, consequential, compensatory, incidental, actual, exemplary, punitive or special for the use of, reference to, or reliance on this white paper or any of the content contained herein, including, without limitation, any loss of business, revenues, profits, data, use, goodwill or other intangible losses. + +**免责声明：** 本EOS.IO技术白皮书v2仅供参考。 block.one不保证本白皮书的准确性或达到相应的结论，并且本白皮书按“原样”提供。 block.one没有明确表示承担任何明示，暗示，法定或其他任何陈述和保证，包括但不限于：（i）对适销性，适用于特定用途，适用性，使用，标题或不侵权; （ii）本白皮书的内容没有错误; （iii）此类内容不会侵犯第三方权利。对于因使用，参考或依赖此白皮书或此处包含的任何内容而引起的任何形式的损失，即使已被告知可能发生此类损害，block.one及其附属公司也不承担任何责任。在任何情况下，一个附属公司将不会对任何人或实体承担任何形式的直接或间接，间接，补偿，偶然，实际，惩罚性或惩罚性的任何损害，损失，责任，成本或开支的责任使用，引用或依赖本白皮书或此处包含的任何内容，包括但不限于业务，收入，利润，数据，使用，商誉或其他无形损失的任何损失。 + + + +- [Background 背景](#background) +- [Requirements for Blockchain Applications 区块链应用程序的要求](#requirements-for-blockchain-applications) + * [Support Millions of Users 支持百万级用户](#support-millions-of-users) + * [Free Usage 免费使用](#free-usage) + * [Easy Upgrades and Bug Recovery 轻松升级和故障修复](#easy-upgrades-and-bug-recovery) + * [Low Latency 低延迟](#low-latency) + * [Sequential Performance 串行性能](#sequential-performance) + * [Parallel Performance 并行性能](#parallel-performance) +- [Consensus Algorithm 共识算法 \(BFT-DPOS\)](#consensus-algorithm-bft-dpos) + * [Transaction Confirmation 交易确认](#transaction-confirmation) + * [Transaction as Proof of Stake 交易作为权益证明 \(TaPoS\)](#transaction-as-proof-of-stake-tapos) +- [Accounts 账户](#accounts) + * [Actions & Handlers Actions & 处理器](#actions--handlers) + * [Role Based Permission Management 基于角色的权限管理](#role-based-permission-management) + + [Named Permission Levels 命名权限级别](#named-permission-levels) + + [Permission Mapping 权限映射](#permission-mapping) + + [Evaluating Permissions 权限评估](#evaluating-permissions) + - [Default Permission Groups 默认权限组](#default-permission-groups) + - [Parallel Evaluation of Permissions 权限的并行评估](#parallel-evaluation-of-permissions) + * [Actions with Mandatory Delay 强制延迟的动作](#actions-with-mandatory-delay) + * [Recovery from Stolen Keys 丢失密钥的恢复](#recovery-from-stolen-keys) +- [Deterministic Parallel Execution of Applications 应用程序的确定性并行执行](#deterministic-parallel-execution-of-applications) + * [Minimizing Communication Latency 通讯延迟优化](#minimizing-communication-latency) + * [Read-Only Action Handlers 只读的动作处理器](#read-only-action-handlers) + * [Atomic Transactions with Multiple Accounts 多账户事务的原子化](#atomic-transactions-with-multiple-accounts) + * [Partial Evaluation of Blockchain State 区块链状态的部分评估](#partial-evaluation-of-blockchain-state) + * [Subjective Best Effort Scheduling 排程的主观最优化](#subjective-best-effort-scheduling) + * [Deferred Transactions 延迟事务](#deferred-transactions) + * [Context Free Actions 上下文无关的动作](#context-free-actions) +- [Token Model and Resource Usage 代币模型和资源使用](#token-model-and-resource-usage) + * [Objective and Subjective Measurements 主观度量和客观度量](#objective-and-subjective-measurements) + * [Receiver Pays 收款方付费](#receiver-pays) + * [Delegating Capacity 代理容量](#delegating-capacity) + * [Separating Transaction costs from Token Value 将交易成本与代币价值区分](#separating-transaction-costs-from-token-value) + * [State Storage Costs 状态存储的成本](#state-storage-costs) + * [Block Rewards 出块奖励](#block-rewards) + * [Worker Proposal System 工作提案系统](#worker-proposal-system) +- [Governance 治理](#governance) + * [Freezing Accounts 冻结账户](#freezing-accounts) + * [Changing Account Code 更改账户代码](#changing-account-code) + * [Constitution 宪法](#constitution) + * [Upgrading the Protocol & Constitution 升级协议和宪法](#upgrading-the-protocol--constitution) + + [Emergency Changes 紧急情形下的修改](#emergency-changes) +- [Scripts & Virtual Machines 脚本与虚拟机](#scripts--virtual-machines) + * [Schema Defined Actions 由模式定义的动作](#schema-defined-actions) + * [Schema Defined Database 由模式定义的数据库](#schema-defined-database) + * [Generic Multi Index Database API 通用的多重索引数据库API](#generic-multi-index-database-api) + * [Separating Authentication from Application 将验证与应用区分](#separating-authentication-from-application) +- [Inter Blockchain Communication 跨链通讯](#inter-blockchain-communication) + * [Merkle Proofs for Light Client Validation 用于轻客户端验证的 Merkle 证明\(LCV\)](#merkle-proofs-for-light-client-validation-lcv) + * [Latency of Interchain Communication 跨链通讯延迟](#latency-of-interchain-communication) + * [Proof of Completeness 完成性证明](#proof-of-completeness) + * [Segregated Witness 隔离见证](#segregated-witness) +- [Conclusion 结论](#conclusion) + + + +# Background 背景 + + +Blockchain technology was introduced in 2008 with the launch of the Bitcoin currency, and since then entrepreneurs and developers have attempted to generalize the technology to support a wider range of applications on a single blockchain platform. + +区块链技术源于2008年推出的比特币，自那时以来，企业家和开发人员一直在努力使该技术通用化，以便在单个区块链平台上支持更广泛的应用。 + +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. + + +虽然一些通用区块链平台还在努力实现第一个能正常运行的区块链应用，针对特定场景的区块链应用诸如BitShares去中心化交易所（2014）和Steem社交媒体平台（2016）已经成为日活跃用户上万的成功应用。这两个应用成功的把性能提高到每秒数千笔交易，延迟降低到1.5秒，降低交易费用，并实现了与当前中心化服务器的方案相似的用户体验。 + +Existing blockchain platforms are burdened by large fees and limited computational capacity that prevent widespread blockchain adoption. + +由于现有的区块链平台使用费用高昂，计算性能有限，阻碍了区块链的广泛应用。 + +# Requirements for Blockchain Applications 区块链应用的需求 + +In order to gain widespread use, applications on the blockchain require a platform that is flexible enough to meet the following requirements: + +为了得到广泛使用，区块链上的应用程序要求区块链平台足够灵活，能够满足如下要求： + +## Support Millions of Users 支持百万级别的用户 + +Competing with businesses such as eBay, Uber, AirBnB, and Facebook, require blockchain technology capable of handling tens of millions of active daily users. In certain cases, an application may not work unless a critical mass of users is reached and therefore a platform that can handle very large numbers of users is paramount. + +想要同Ebay，Uber，AirBnB和Facebook这些企业竞争，需要能够处理数千万日活跃用户的区块链技术。 在某些情况下，除非用户数足够庞大，否则应用程序可能无法正常运作，因此，能够应对大量用户的平台至关重要。 + +## Free Usage 免费使用 + +Application developers need the flexibility to offer users free services; users should not have to pay in order to use the platform or benefit from its services. A blockchain platform that is free to use for users will likely gain more widespread adoption. Developers and businesses can then create effective monetization strategies. + +应用开发人员需要具备灵活性，能够为用户提供免费服务; 用户不必为了使用平台或从平台的服务中受益而付费。用户可以免费使用的区块链平台，自然会得到更多人的青睐。有了足够的用户规模，开发者和企业可以创建对应的盈利模式。 + +## Easy Upgrades and Bug Recovery 轻松升级和故障修复 + +Businesses building blockchain based applications need the flexibility to enhance their applications with new features. The platform must support software and smart contract upgrades. + +All non-trivial software is subject to bugs, even with the most rigorous of formal verification. The platform must be robust enough to fix bugs when they inevitably occur. + +基于区块链构建应用程序的企业，需要区块链平台具备灵活性，可以为其应用添加新特性来增强完善。区块链平台必须对软件和智能合约的升级提供支持。 + +所有的非小型的软件都可能会有缺陷，即使是用了最严格的形式验证也是如此。当bug不可避免出现时，区块链平台必须足够健壮，能够修复这些bug。 + +## Low Latency 延迟低 + +A good user experience demands reliable feedback with a delay of no more than a few seconds. Longer delays frustrate users and make applications built on a blockchain less competitive with existing non-blockchain alternatives. The platform should support low latency of transactions. + +及时的反馈是良好用户体验的基础。延迟时间如果超过了几秒钟，会大大影响用户体验，严重降低基于区块链的应用相对于现有的非区块链应用的竞争力。区块链平台应当支持低延迟的交易。 + +## Sequential Performance 串行性能 + +There are some applications that just cannot be implemented with parallel algorithms due to sequentially dependent steps. Applications such as exchanges need enough sequential performance to handle high volumes. Therefore, the platform should support fast sequential performance. + +有些应用程序由于必须顺序执行命令，从而无法用并行算法进行实现。诸如交易所之类的应用经常需要足够的串行操作处理性能，以应对大量的交易。因此，区块链需要提供强大的串行性能支持。 + +## Parallel Performance 并行性能 + +Large scale applications need to divide the workload across multiple CPUs and computers. + +大型应用程序需要在多个CPU和计算机之间分配工作负载。 + +# Consensus Algorithm (BFT-DPOS) 共识算法（BFT-DPOS） + +EOS.IO software utilizes the only known decentralized consensus algorithm proven capable of meeting the performance requirements of applications on the blockchain, [Delegated Proof of Stake (DPOS)](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. + +EOS.IO软件采用了目前为止唯一能够符合上述性能要求的去中心化共识算法 -- 委托权益证明[Delegated Proof of Stake (DPOS)](https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper).。根据这一算法，在使用EOS.IO软件构建的区块链上持有代币的人，可以通过一个持续进行的投票系统来选择区块生产者。任何人都可以选择参加区块生产，只要能够说服代币持有人为其投票，就会有机会参与区块生产。 + +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. + + +EOS.IO软件可以让区块每0.5秒生成一个。任何时刻，只有一个生产者被授权产生区块。如果在计划的某个时间内没有成功出块，则跳过该块。如果有一个或更多的区块被跳过，则在区块链上会有0.5s或者更久的空白。 + + +Using the EOS.IO software, blocks are produced in rounds of 126 (6 blocks each, times 21 producers). At the start of each round 21 unique block producers are chosen by preference of votes cast by token holders. The selected producers are scheduled in an order agreed upon by 15 or more producers. + +If a producer misses a block and has not produced any block within the last 24 hours they are removed from consideration until they notify the blockchain of their intention to start producing blocks again. This ensures the network operates smoothly by minimizing the number of blocks missed by not scheduling producers who are proven to be unreliable. + +使用EOS.IO软件，区块的产生是以126个区块(每个出块者六个区块，乘以21个出块者)为一个周期。在每个出块周期开始时，会根据代币持有人所投票数选出21个区块生产者。被选中的区块生产者的顺序会根据15个及以上的区块生产者的同意，制定出块顺序的安排。 + +如果出块者错过了一个块，并且在最近24小时内没有产生任何块，则这个出块者将被剔除在考虑范围之外，直到他们通知区块链可以重新开始产生区块。这确保了网络的顺利运行，把被证明为不可靠的区块生产者排除在出块排程之外，通过这一方式使得错过区块的数量最小化。 + +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. + +在正常情况下，DPOS块链不会经历任何分叉，因为区块生产者并非竞争关系，他们合作产生区块。如果有区块分叉，共识将自动切换到最长链。这一方式之所以有效，是因为区块链分叉上增加区块的速度，与具有相同共识的区块生产者的比例直接相关。换句话说，具有更多生产者的区块链长度将比具有较少生产者的区块链增长速度更快，因为，有更多生产者的区块链分叉上，丢块更少。 + +Furthermore, no block producer should be producing blocks on two forks at the same time. A block producer caught doing this will likely be voted out. Cryptographic evidence of such double-production may also be used to automatically remove abusers. + +此外，没有块生产者可以同时在两个区块链分叉上生产块。如果一个块生产者发现这么做了，就可能被投票出局。这类双重生产的密码学证据，也可能会被用来自动移除作恶者。 + + +Byzantine Fault Tolerance is added to traditional DPOS by allowing all producers to sign all blocks so long as no producer signs two blocks with the same timestamp or the same block height. Once 15 producers have signed a block the block is deemed irreversible. Any byzantine producer would have to generate cryptographic evidence of their treason by signing two blocks with the same timestamp or blockheight. Under this model a irreversible consensus should be reachable within 1 second. + +在传统的DPOS算法上增加了拜占庭容错算法(Byzantin Fault Tolerance) ，所有的出块者都要对所有区块签名，以此来确保在同一时间戳或者同一区块高度上，没有区块生产者能够同时在两个区块上签名。一个区块有了15个区块生产者的签名，该区块就被认为是不可逆的。任一拜占庭区块生产者如果想在同一时间戳或者同一区块高度的两个区块上签名，就不得不留下密码学证据。在这一模式下，一秒之内就可以达成不可逆的共识。 + +## Transaction Confirmation 交易确认 + +Typical DPOS blockchains have 100% block producer participation. A transaction can be considered confirmed with 99.9% certainty after an average of 0.25 seconds from time of broadcast. + +使用DPOS算法的区块链，一般出块者都是100%参与的。一笔交易在广播后平均0.25秒，就可以认为具有99.9%的确定性了。 + +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. + +EOS.IO 在DPOS之外，还增加了异步拜占庭容错(aBFT, asynchronous Byzantine Fault Tolerance ), 来实现更快的不可逆性。aBFT算法使得在1秒内就可以对不可逆性得到100%的确认。 + +## Transaction as Proof of Stake (TaPoS) -- 交易证明 + +The EOS.IO software requires every transaction to include part of the hash of a recent block header. This hash serves two purposes: + +1. prevents a replay of a transaction on forks that do not include the referenced block; and +2. signals the network that a particular user and their stake are on a specific fork. + +Over time all users end up directly confirming the blockchain which makes it difficult to forge counterfeit chains as the counterfeit would not be able to migrate transactions from the legitimate chain. + +EOS.IO软件要求每个交易都要将最近区块的区块头哈希的一部分包括在其中。 这一哈希有两个目的： + +1.防止在区块链分叉上的交易重放，这些交易并不包含参考区块; +2.通知区块链网络，某一用户及其资产(stake)处于特定的分叉上 + +随着时间的推移所有用户都能直接对区块链进行确认，这使得伪造链难以作伪，因为伪造的链无法从合法的链上转移交易。 + +# Accounts 账户 + +The EOS.IO software permits all accounts to be referenced by a unique human readable name of up to 12 characters in length. The name is chosen by the creator of the account. The account creator must reserve the RAM required to store the new account until the new account stakes tokens to reserve its own RAM. + +In a decentralized context, application developers will pay the nominal cost of account creation to sign up a new user. Traditional businesses already spend significant sums of money per customer they acquire in the form of advertising, free services, etc. The cost of funding a new blockchain account should be insignificant in comparison. Fortunately, there is no need to create accounts for users already signed up by another application. + + +EOS.IO软件允许使用唯一的可读的名称来实现对帐户的引用，名称最长为12个字符。该名称由帐户的创建者选择。账户创建者必须留出RAM空间用于存储新的账户，直至新建的账户抵押了代币以获得自己的RAM空间。 + +在去中心化的情境下，应用程序开发人员将为创建帐户支付名义成本来注册新的用户。通常企业已经以广告和免费服务等形式，为所获取的每个用户花费了大量资金。相比之下，创建新的区块链帐户所需的资金成本是微不足道的。并且幸运的是，没有必要为已经由另一个应用程序注册的用户创建帐户。 + +## Actions & Handlers Actions和处理器 + +Each account can send structured Actions to other accounts and may define scripts to handle Actions when they are received. The EOS.IO software gives each account its own private database which can only be accessed by its own action handlers. Action handling scripts can also send Actions to other accounts. The combination of Actions and automated action handlers is how EOS.IO defines smart contracts. + +To support parallel execution, each account can also define any number of scopes within their database. The block producers will schedule transaction in such a way that there is no conflict over memory access to scopes and therefore they can be executed in parallel. + +每个帐户可以将结构化的Action发送到其他帐户，并且可以定义Action被接受后的处理脚本。EOS.IO软件为每个帐户提供其自己独有的数据库，只能由自己的action处理程序访问。Action处理脚本还可以向其他帐户发送Action。Action和自动的action处理程序的组合正是EOS.IO定义智能合约的方式。 + + + +为了支持并行执行，每个账户都可以在其数据库中定义任意数量的范围(scope)。区块生产者会对事务进行排程，不会在访问scope的内存时出现冲突，因此事务可以进行并行执行。 -未经允许，在非用于商业和教育用途的前提下 (即，除了收取费用或商业目的)，如果注明原始出处并适用声明的版权，任何人可以使用、复制或发布本白皮书内的任何内容。 -**免责声明：** 本 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. +## Role Based Permission Management 基于角色的权限管理 -- [背景](#background) -- [区块链应用的要求](#requirements-for-blockchain-applications) - - [支持成百上千的用户](#support-millions-of-users) - - [免费的使用](#free-usage) - - [简单升级和 bug 修复](#easy-upgrades-and-bug-recovery) - - [低延时](#low-latency) - - [时序性能](#sequential-performance) - - [并发性能](#parallel-performance) -- [共识算法 (DPOS)](#consensus-algorithm--dpos-) - - [交易确认](#transaction-confirmation) - - [股权证明的交易 (TaPoS)](#transaction-as-proof-of-stake--tapos-) -- [帐户](#accounts) - - [消息 & 处理](#messages---handlers) - - [基于角色的权限管理](#role-based-permission-management) - - [命名的权限级别](#named-permission-levels) - - [命名的消息处理群组](#named-message-handler-groups) - - [权限映射](#permission-mapping) - - [评估权限](#evaluating-permissions) - - [默认权限群组](#default-permission-groups) - - [权限并行评估](#parallel-evaluation-of-permissions) - - [带强制性延时的消息](#messages-with-mandatory-delay) - - [恢复被盗窃的密钥](#recovery-from-stolen-keys) -- [应用程序的确定性并行执行](#deterministic-parallel-execution-of-applications) - - [最小化通信延迟](#minimizing-communication-latency) - - [只读信息的处理](#read-only-message-handlers) - - [多帐户的原子化交易](#atomic-transactions-with-multiple-accounts) - - [区块链状态的部分评估](#partial-evaluation-of-blockchain-state) - - [自主最优调度](#subjective-best-effort-scheduling) -- [Token 模型与资源使用](#token-model-and-resource-usage) - - [客观与主观的度量](#objective-and-subjective-measurements) - - [接收方付费](#receiver-pays) - - [委托能力](#delegating-capacity) - - [分离交易成本与 Token 价值](#separating-transaction-costs-from-token-value) - - [状态存储成本](#state-storage-costs) - - [区块奖励](#block-rewards) - - [社区效益应用](#community-benefit-applications) -- [治理](#governance) - - [冻结帐户](#freezing-accounts) - - [更改帐户代码](#changing-account-code) - - [宪法](#constitution) - - [升级协议 & 宪法](#upgrading-the-protocol---constitution) - - [紧急变更](#emergency-changes) -- [脚本 & 虚拟机](#scripts---virtual-machines) - - [模式定义的消息](#schema-defined-messages) - - [模式定义的数据库](#schema-defined-database) - - [分离授权与应用](#separating-authentication-from-application) - - [虚拟机独立架构](#virtual-machine-independent-architecture) - - [Web 组建 (WASM)](#web-assembly) - - [以太访虚拟机 (EVM)](#ethereum-virtual-machine--evm-) -- [跨链通信](#inter-blockchain-communication) - - [用于轻客户端的 Merkle 证明 (LCV)](#merkle-proofs-for-light-client-validation--lcv-) - - [跨链通信的延时](#latency-of-interchain-communication) - - [完备性证明](#proof-of-completeness) -- [结论](#conclusion) +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. -# 背景 +权限管理主要涉及对某一特定Action是否得到正确授权进行确定。权限管理的最简单形式是检查事务是否具有所需的签名，但这意味着已经知晓了所需的签名。通常，授权是与个人或由个人组成的团队绑定在一起的，并且通常会进行划分。EOS.IO软件提供了一个断言式的权限管理系统，可以让帐户就何人在何时能够做何事上，进行细粒度和高级别的控制。 -区块链技术是通过 2008 年诞生的比特币货币得以被认知，自从那之后企业家和开发者就不断的尝试推广这一技术，以便在单一的区块链平台上支持更为广泛的应用程序。 +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. -而一些区块链平台努力的支持可运作的去中心化应用，具体的应用比如 BitShares 去中心化交易所 (2014) 和 Steem 社交媒体平台 (2016) 已经成为每天被成千上万活跃用户重度使用的区块链。 他们能做到这些，是通过性能的提升达到每秒处理上千交易，消除手续费和提供堪比已经存在的中心化服务的用户体验。 +至关重要的是，身份认证和权限管理被标准化实现，并与应用程序的业务逻辑分离。这使得开发某种工具以通用方式管理权限成为可能，并为性能优化提供了巨大的空间。 -已存在的区块链平台承担着大量的交易费和有限的可计算能力，这都阻碍了区块链技术的大面积应用。 +Every account may be controlled by any weighted combination of other accounts and private keys. This creates a hierarchical authority structure that reflects how permissions are organized in reality and makes multi-user control over accounts easier than ever. Multi-user control is the single biggest contributor to security, and, when used properly, it can greatly reduce the risk of theft due to hacking. -# 区块链应用的要求 +每个帐户都可以通过其他帐户和私钥的任何加权组合来控制。这种机制创建了一个能够真实反映权限在现实中的组织情况的层次化权限结构，并使得多用户对账户的控制比以往任何时候都更容易。多用户控制是提升安全性的最重要因素，如果能正确地使用，可以极大地消除黑客盗窃的风险。 -为了赢得广泛的应用，构建在区块链之上的应用需要一个灵活性足以满足以下要求的平台： +EOS.IO software allows accounts to define what combination of keys and/or accounts can send a particular Action type to another account. For example, it is possible to have one key for a user's social media account and another for access to the exchange. It is even possible to give other accounts permission to act on behalf of a user's account without assigning them keys. -## 支持成百上千的用户 +EOS.IO软件允许帐户可以定义何种密钥和/或账户3的组合，可以向另一账户发送特定类型的Action。例如，可以为用户的社交媒体帐号提供一个密钥，并提供另一密钥用于访问交易所。甚至用户可以给予其他帐户许可让其代表自己的帐户行事，而无需向其他帐户分配密钥。 -像 Ebay、Uber、AirBnB 和 Facebook 这样企业，他们需要区块链技术能处理每日数以千万的活跃用户。 在某些情况下，除非用户群体达到一个极庞大的量级否则应用并无用武之地，因此一个可以处理极其庞大用户的平台是至关重要的。 +### Named Permission Levels 命名权限级别 -## 免费的使用 -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. 一个可以免费供用户使用的区块链平台或许将赢得更为广泛的使用。 开发者和企业可以制订有效的货币化战略。 +![](https://camo.githubusercontent.com/6fc705d33e56868cb03f5e307299837f5b91f20d/687474703a2f2f656f732e696f2f7770696d672f6469616772616d332e706e67) -## 简单升级和 bug 修复 -企业构建区块链基础的应用需要能够为应用增加新特性的灵活性。 +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. -所有非同凡响的软件都会受到 bug 的影响，即便是经过了最严格意义上的验证。这个平台必须具有足够的鲁棒性以便应对不可避免出现的 bug。 +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. -## 低延时 +使用EOS.IO软件，帐户可以定义命名权限级别，每个权限级别可以从更高级别的命名权限派生。每个命名权限级别定义一项授权；这一授权是密钥和(/或)其他账户的命名权限级别所组成的多签名检查的阈值。例如，帐户的“朋友”权限级别可以设置为帐户中的某项Action能被该账户的任何朋友的帐户平等地控制。 -一个好的用户体验需要延时时间在数秒内就能收到可靠的反馈。 高延时会阻碍用户，并且会让构建在区块链上的应用比已有的非区块链应用缺乏竞争力。 -## 时序性能 +另一个例子是Steem区块链，其具有三个硬编码命名的权限级别：owner，active和posting。Posting权限只能执行诸如投票和发布等社交行为，而active权限除了更改所有者之外，可以做其他任何事情。owner权限用作冷存储，它能够做所有事情。EOS.IO对这一概念进行了通用化，允许每个帐户持有者定义自己的权限层次结构以及动作的分组。 -一些应用因为顺序依赖关系的执行步骤而不能使用并发算法实现。 比如交易所就需要足够的时序性能来处理很高的交易量，因此高时序性能处理的平台是必须的。 +### Permission Mapping 权限映射 -## 并发性能 +EOS.IO software allows each account to define a mapping between a contract/action or contract of any other account and their own Named Permission Level. For example, an account holder could map the account holder's social media application to the account holder's "Friend" permission group. With this mapping, any friend could post as the account holder on the account holder's social media. Even though they would post as the account holder, they would still use their own keys to sign the Action. This means it is always possible to identify which friends used the account and in what way. -大型可扩展应用需要将工作量分配到多 CPU 和计算机之上。 +EOS.IO软件允许每个帐户定义在合约/动作或任何其他帐户的合约，以及账户自己的命名权限级别之间进行映射。例如，账户持有人可以将账户持有人的社交媒体应用程序映射到帐户持有者的“朋友”权限组。通过此映射，帐户的任何朋友都可以和帐户持有者一样，在帐户的社交媒体上发布内容。即使他们会作为帐户持有者来发帖，他们仍然使用自己的密钥来为Action签名。这意味着总是可以辨别出来哪些朋友以何种方式使用了其帐户。 -# 共识算法 (DPOS) +### Evaluating Permissions 权限评估 -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. +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**. -EOS.IO 软件使得区块准确的每 3 秒生成一个并且在任何时间点都只有一个被授权的生产者来生成区块。 如果一个区块在规定时间之内未被生产出来则这一区块将被跳过。 当一个或多个区块被跳过发生时，在区块链中会有一个 6 秒及以上的间隔。 +当从@Alice向@bob发送类型为“Action”的动作(Action)时，EOS.IO软件将首先检查@alice是否为@bob.groupa.subgroup.Action定义了权限映射。如果没有找到任何结果，那么将会检查@bob.groupa.subgroup，然后是@bob.groupa，最后是@bob的映射。如果此时仍然没有找到匹配的结果，那么假定的映射将是命名权限组 **@alice.active**。 -在 EOS.IO 软件中，区块通过 21 名生产者轮流产生。 在每一轮的开始时，21 个唯一的区块生产者被选出。 获票最高的前 20 名自动在没轮被选中，剩余的一个生产者通过得票比例选出。 被选中的生产者通过从区块取到的时间作为伪随机数来打乱其顺序。 打乱顺序是为确保这些生产者与其他生产者保持均衡的连通性。 +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**. -如果一个生产者错过了一个区块并且在过去的 24 小时内没有生产任何的区块，那么它将被从候选中移除，直到它在区块链中通知它要开始再次生产区块的意图。 这样通过最小化区块丢失数量（因被证实不可靠的节点不作为导致）来确保网络操作的稳定性。 +一旦识别出权限映射，则启动多签名阈值校验过程对签名授权进行校验，把该授权与命名权限相关联。如果失败，那么它会遍历父权限，最终遍历到其所有者的权限， **@alice.owner**。 -在一般情况下，一个 DPOS 区块链不会经历任何的分叉，因为区块生产者是通过合作而非竞争的方式来生产区块。 即便真的出现了分叉，共识也将自动的切换到最长的链上。 之所以会这样运作，是因为区块添加到一个区块链分叉的速率与公用同一共识的区块生产者比例是相关的。 换句话说，具有更多生产者的区块链分叉会比拥有较少生产的那一个条增长的速度更快。 而且，没有一个生产者会同时在两个分叉上同时生产区块。 如果一个区块生产者被抓到做这样的事儿，那么这个生产者将很可能被投票投出。 这些双重生产行为对应密码学凭证可以用来自动的删除这些滥用者。 -## 交易确认 +![](https://camo.githubusercontent.com/8cd91b490fed0c94369251791eb25d74bcf54460/687474703a2f2f656f732e696f2f7770696d672f6469616772616d32677261797363616c65322e6a7067) -通常 DPOS 区块链 100% 会有区块生产者参与。一个交易从广播开始后平均 1.5 秒就可以 99.9% 被认为是确认了。 +#### Default Permission Groups 默认权限组 -在一些特殊情况下例外，软件出现 bug，网络拥塞，或一个恶意的区块生产者制造了两个或更多的分叉。 为了确保一个交易绝对是不可逆的，一个节点可以选择等待 21 个区块生产者中的 15 个给出确认。 基于通常的 EOS.IO 软件配置，在一般情况下这需要平均 45 秒的时间。 默认情况下，所有的节点将认为当 21 个生产者中有 15 个给出确认后这一区块就是不可逆的了，并且不管长度如何都不会切换到没有这一区块的分叉。 -在分叉开始的 9 秒内，一个节点就可以警告用户他们极可能正处于分叉中。 在连续丢失 2 个区块后，有 95% 的概率可以确认一个节点处于分叉中。 在连续丢失 3 个区块后就有 99% 的概率确认。 可以通过节点丢失、近期参与比率和其他参数来构建鲁棒性预测模型，从而快速的警告操作者出现了问题。 +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". -对于这种警告的反应完全取决于商业交易的性质，但最简单的做法就是等待 15/21 的确认直到警告消失。 +EOS.IO 的技术还允许所有帐户都有一个可以做所有事情的“owner”权限组，和一个除了更改所有者组之外可以执行所有操作的“active”权限组。所有其他权限组均派生自“active”权限组。 -## 股权证明的交易 (TaPoS) -EOS.IO 软件需要每一个交易包含最近一个区块头的哈希值。这个哈希值有两个目的： +#### Parallel Evaluation of Permissions 并行权限评估 - 1. 防止不包含区块引用的交易在分叉时重放发生；和 - 2. 通知网络对应的用户和他们的股份当前在某个具体的分叉上。 +The permission evaluation process is "read-only" and changes to permissions made by transactions do not take effect until the end of a block. This means that all keys and permission evaluation for all transactions can be executed in parallel. Furthermore, this means that a rapid validation of permission is possible without starting costly application logic that would have to be rolled back. Lastly, it means that transaction permissions can be evaluated as pending transactions are received and do not need to be re-evaluated as they are applied. -随着时间的推移，所有的用户直接确认区块链，在这一链条上难以伪造假的链条，因为假的链条根本无法从合法链条上迁移交易。 +权限评估是个“只读”的过程，通过事务对权限进行的修改，在一个区块结束时才会生效。首先，这意味着所有事务的所有密钥和权限评估可以并行执行。其次，这种机制意味着可以快速验证权限，而不需要启动可能会回滚的代价高昂的应用程序逻辑。最后，这意味着当接收到挂起的事务时， 可以执行事务权限验证；而在取消挂起、事务生效时，无需重新执行验证。 -# 帐户 +All things considered, permission verification represents a significant percentage of the computation required to validate transactions. Making this a read-only and trivially parallelizable process enables a dramatic increase in performance. -EOS.IO 软件允许所有的帐户使用一个唯一的人类可读的名称来索引，长度在 2 到 32 个字符之间。 这个名称由帐户创建者自己选择。 所有的帐户必须在创建时用极少的帐户余额来注资，从而覆盖存储帐户信息的成本。 帐户名称也支持命名空间，比如 @domain 这个帐户的拥有者是唯一可以创建 @user.domain 帐户的人。 +考虑到所有因素，权限验证占据了交易验证中很大比例的计算量。使之成为只读和并行的过程，可以显著提高性能。 -在一个去中心化的场景中，应用开发者将会为新用户注册成本买单。 Traditional businesses already spend significant sums of money per customer they acquire in the form of advertising, free services, etc. 比起来，资助一个新的区块链帐户的花费简直微不足道。 值得庆幸的是，对一个已经在另一个应用注册过的用户并不需要再创建新的帐户。 +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. -## 消息 & 处理 +在对区块链重放，以便从Action的日志中重新生成确定性的状态时，并不需要再次评估权限。事务被包含在一个已知的状态良好的区块中这一事实，使其可以跳过评估的步骤。这极大地减少了在对日益增长的区块链重放时的计算工作量。 -每个帐户可以发送结构化的消息给其他的帐户，并且可以定义脚本来处理他们接收到的消息。 EOS.IO 软件给每个帐户提供了只有自己的消息处理脚本能访问的私有数据库。 消息处理脚本同样可以给其他帐户发送消息。 消息和自动化的消息处理的结合决定了 EOS.IO 如何定义智能合约的。 +## Actions with Mandatory Delay 强制延迟的动作(Actions) -## 基于角色的权限管理 +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. -权限管理涉及判定一条消息是否被正确的授权。 权限管理最简单的形式就是检查一个交易包含必须的签名，但这意味着必须的签名是已知的。 一般情况下，权威必然是独立的个体或者个体组成的群体，并且是被划分开的。 EOS.IO 软件提供了声明式的权限管理系统，通过管理谁可以在什么时间做什么来给用户细力度和高维度的控制。 +时间是安全的关键组成部分。在大多数情况下，在私钥被使用前不可能知道其是否已经被盗用。基于时间的安全机制在人们使用一些特殊的应用程序时更为关键，这些应用程序需要在连网的电脑上保存密钥，便于人们日常使用。EOS.IO软件允许应用程序的开发者指定某些Action在包含在区块后、实际应用之前，必须等待的最短时间段。在此期间，这些动作可以被取消。 -授权和权限管理被标准化和脱离应用的商业逻辑是不可取的。 这使得管理权限的工具得以被开发，既满足常规的需求又为性能优化提供了重要的可能性。 +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. -每一个帐户可以被任何权重组合的其他帐户和私钥管控。 这创建了分层级的权利结构，这反映了现实中的权限分配方式，并且让多用户共同管理资产变得从未如此简单。 多用户控制是安全最大的贡献者，并且，当用户使用得当，它可以极大的消除因被黑而导致被盗窃的风险。 +当这类Action被广播时，用户可以通过电子邮件或短信收到相应通知。如果他们未曾授权，那么他们可以登录其帐户来还原帐户数据并撤回Action。 -EOS.IO software allows accounts to define what combination of keys and/or accounts can send a particular message type to another account. 举个例子，可以指定一个密钥给一个用户的社交媒体账号，同时另一个密钥访问交易所。 甚至可以给其他帐户权限来代表自己而无需分配给他们密钥。 +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. -### 命名的权限级别 +所需的延迟取决于操作的重要程度。支付一杯咖啡可以在几秒钟内确认，不需延迟，而买房子可能需要72小时清算周期。将整个帐户转移到新的控制者手上可能最多需要30天。具体延迟的选择取决于应用程序开发者和用户。 - +## Recovery from Stolen Keys 密钥被盗后的恢复 -在 EOS.IO 软件中，帐户可以定义命名的权限级别，每一个是由更高级别的命名权限派生而来。 每一个命名的权限级别定义了一个权威；一个权威是多重签名阈值校验，它包含密钥和／或其他帐户的命名权限级别。 打个比方，一个帐户的“朋友”权限级别可以被设置为由该帐户的任何一个朋友无差别的控制。 +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. -另一个例子在 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. -### 命名的消息处理群组 +EOS.IO软件为用户提供了一种在密钥被盗时恢复其帐户控制权的方法。 帐户所有者可以使用在过去30天内活动的所有者(owner)权限的密钥，以及账户所有者所指派的帐户恢复合作伙伴的许可，来重置其帐户上的所有者密钥。不经过帐户所有者的配合，帐户恢复合作伙伴无法重置其帐户的控制权。 -EOS.IO 软件允许每个帐户将他们自己的消息组织到一个命名和嵌套的群组中。 这个命名的消息处理群组可以在其他帐户配置他们权限级别时被引用。 +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. -最高级别的消息处理群组是帐户名称，最低级别的是一个帐户接收到的单独的消息类型。 这些群组可以被这样的方式引用： **@accountname.groupa.subgroupb.MessageType**. +对于攻击帐户的黑客而言，由于其已经“控制”该帐户，因此尝试执行恢复过程没有任何收获。此外，如果他们的确进行恢复的过程，那么恢复合作伙伴可能需要身份认证和多因素认证（如电话和电子邮件）。这或者会暴露黑客的身份，或者黑客在恢复过程中毫无所得。 -在这样的模型之下，交易所合约可以通过将挂单的创建和取消分组，从而与充值提现分离开。 交易所合约的这样分组对用户而言带来了方便。 +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. -### 权限映射 +这个过程与简单的多重签名机制有极大的不同。通过多重签名的交易，有一个对象会执行并参与每一笔交易。然而，通过恢复过程，恢复过程的合作伙伴仅参与了恢复的过程，并没有权力参与日常的交易。这极大降低了相关参与者的成本和法律责任。 -EOS.IO 软件允许每个帐户定义从任意帐户的一个命名的消息处理群组与自己的命名的权限级别之间建立映射。 举个例子，一个帐户所有者可以将自己社交媒体应用与自己的“朋友”权限群组建立映射。 有了这个映射，任何朋友可以以这一帐户的身份在这一帐户的社交媒体上发帖。 尽管他们将以帐户所有者的身份发帖，他们仍然使用自己的密钥来签名消息。 这意味着总是可以辨识出是哪一个朋友在以何种方式使用帐户。 +# Deterministic Parallel Execution of Applications 应用程序的确定性并行执行 -### 评估权限 +Blockchain consensus depends upon deterministic (reproducible) behavior. This means all parallel execution must be free from the use of mutexes or other locking primitives. Without locks there must be some way to guarantee that transactions that may be executed in parallel do not create non-deterministic results. -当 **@alice** 以 "**Action**" 类型发送一条消息给 **@bob** 时，EOS.IO 软件首先会检查 **@alice** 是否为 **@bob.groupa.subgroup.Action** 定义过权限映射。 如果什么都没有找到，紧接着检查 **@bob.groupa.subgroup** 映射，然后是 **@bob.groupa**，最后 **@bob** 将被检查。 如果都没有找到，那么假定映射为命名的权限群组 **@alice.active**。 -一旦一个映射被识别，则通过阈值多签名流程验证签名权威，并且关联权威与命名的权限。 如果失败了，则跃迁至父权限，直至拥有者权限，**@alice.owner**。 +区块链共识取决于确定性（可重现）行为。这意味着所有并行执行都能在不使用互斥体或其他锁的原语的情况下正常运行。没有锁，必须有方法来确保可能需要进行并行操作的事务，不会产生非确定性的结果。 - +The June 2018 release of EOS.IO software will run single threaded, yet it contains the data structures necessary for future multithreaded, parallel execution. -#### 默认权限群组 +2018年6月份发布的EOS.IO软件版本会是单线程运行的，但是包含了未来需要进行多线程和并行执行所用到的数据结构。 -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. 所有其他的全新群组派生自“活动”群组。 +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. -#### 权限并行评估 +基于EOS.IO软件构建的区块链，一旦并行执行的功能开启，区块生产者的工作是将Action传递到单独的碎片(shard)中，以便它们可以并行地评估。每个帐户的状态只取决于传递给它的消息。区块生产者的输出会产生排程表，并且将被确定性地执行，但是生成排程的过程不必是确定性的。这意味着区块生产者可以利用并行算法来对事务进行排程。 -权限评估过程是“只读”的，并且通过交易对权限的变更在一个区块结束之前不会起作用。 这意味着对所有的交易对应的密钥和权限评估可以被并行执行。 此外，这意味着一个快速的权限验证是可行的，它无需启动会引起回滚需求的高成本的应用逻辑。 最后，这意味着交易权限可以被评估即便接收到等待的交易，并且之后无需再重新评估。 -从各方面考虑，权限验证占据了验证交易计算量的很大比例。 让其只读和普遍的并发处理将会使得性能有一个质的飞跃。 +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. -当从消息日志中重新生成确定性状态时不再需要重复的权限验证。 事实是一个交易如果被包含近了一个被认为不存在问题的区块时它就有足够的理由跳过这 步这将极大减少因为区块链增长拉去过去记录时的计算量。 -## 带强制性延时的消息 +并行执行的部分还意味着当脚本生成新的Action时，它不会立即发送，而是在下一个周期中发送它。无法立即发送的原因是因为接收方可能会在另一个碎片(shard)中主动修改自己的状态。 -时间是安全中的一个关键组成部分。 在大多数情况下，一个私钥在没有被使用前都无从知晓它是否被偷窃。 当人们有需要密钥的应用在每天联网使用的电脑上运行时，基于时间的安全会更为重要。 EOS.IO 软件让应用开发者可以指明消息必须在被加到一个区块之前等待最小的时间间隙。 During this time they can be cancelled. +## Minimizing Communication Latency 通信延迟优化 -用户可以在消息广播出去后通过邮件或者文字消息的形式收到通知。 如果他们没有授权，那么他们可以使用帐户恢复流程来恢复帐户，并收回消息。 +Latency is the time it takes for one account to send an Action to another account and then receive a response. The goal is to enable two accounts to exchange Actions back and forth within a single block without having to wait 0.5 seconds between each Action. To enable this, the EOS.IO software divides each block into cycles. Each cycle is divided into shards and each shard contains a list of transactions. Each transaction contains a set of Actions to be delivered. This structure can be visualized as a tree where alternating layers are processed sequentially and in parallel. -这个必须的延时由操作敏感性决定。 为一杯咖啡付款可以没有任何的延时，几秒之内就不可逆了，而购买一个房子也许需要 72 消失的结算期。 转移整个帐户到一个新的控制可能需要长达 30 天。 具体的延时选择由开发者和用户自己来做选择。 +延迟时间是一个帐户将动作(Action)发送到另一个帐户并收到响应所需的时间。EOS.IO软件的目标是使两个帐户能够在单个区块内来回交换Action，而不必在每个Action之间等待0.5秒。为了实现这一点，EOS.IO软件将每个区块分为周期（cycle）。每个周期分为多个碎片（shard），每个碎片(shard)包含一组事务列表。每个事务包含一组要传递的动作(Action)。该结构可以被可视化为树，其中各层依据其特性被顺序处理或者并行处理。 -## 恢复被盗窃的密钥 +``` + Block 区块 -EOS.IO 软件提供给用户一种找回自己失窃密钥控制权的方式。 一个帐户的所有者可以使用过去 30 天任何活跃的拥有者密钥与事先指定的合作者帐户给出的批准来重置自己帐户的密钥。 帐户的恢复合作者在没有所有人帮助的情况下无法重置帐户的控制权。 + Region 区 -黑客尝试进行恢复流程是无意义的，因为他们已经“控制”了帐户。 此外，就算他们真的进行这一流程，恢复合作者也会询问身份证明和多因素认证 (手机和邮件)。 这会让黑客脱作出让步或者无功而返。 + Cycles (sequential) 周期(顺序) -这一流程与简单的多重签名有很大差异。 在多重签名中，另一个公司要参与所有转账的执行，但在恢复流程中，它却只在恢复时才起作用对每天的转账无从干预。 这大大的降低了参与者的成本和法律责任。 + Shards (parallel) 碎片(并行) -# 应用程序的确定性并行执行 + Transactions (sequential) 事务(顺序) -区块链共识取决于确定性 (可重现的) 的行为。 这意味着所有的并行计算必须是不能互斥或者具有其他锁特性的。 没有了锁就必须有一些方式可以确保所有的帐户只可以读取和写入他们自己的私有数据库。 这也意味着每个帐户处理消息是顺序的，而并发只能在帐户层面进行。 + Actions (sequential) 动作(顺序) -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. 每个帐户的状态由且只由发送给它的消息决定。 进度表由区块生产者输出并且会被确定性的执行，但是生成进度表的过程却不一定是确定性的。 这意味着区块生产者可以使用并发算法来调度交易。 + Receiver and Notified Accounts (parallel) 接收者和通知的账户(并行) +``` -并行执行的一方面意味着当一个脚本生成了一个新的消息，它不会立即被发送，而被安排在下一个轮训中发送。 不能立马发出的原因是接受者可能在另一个线程中活跃的变更自己的状态。 +Transactions generated in one cycle can be delivered in any subsequent cycle or block. Block producers will keep adding cycles to a block until the maximum wall clock time has passed or there are no new generated transactions to deliver. -## 最小化通信延迟 +在一个周期中生成的事务可以在任何后续的周期或区块中传送。区块生产者不断地向一个区块中添加cycle，直至达到了最大的时钟时间，或者没有新生成的需要传送的事务为止。 -延迟是一个帐户从发出一条消息给另一个帐户，直到收到回应的这段时间。 我们的目标是在一个单独的区块中包含两个帐户交换消息的来去信息，而不用在每条消息间等待 3 秒钟。 为了做到这一点，EOS.IO 软件将每个区块划分为循环。 每个循环划分为线程，每个线程包含了交易的一个列表。 每一个交易包含了待发送的消息集合。 这个结构可以被可视化为一个树，其中交互层彼此并行，各自被顺序的执行。 +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. - 区块 - - 循环 (顺序) - - 线程 (并行) - - 交易 (顺序) - - 消息 (顺序) - - 接受者和被通知帐户 (并行) - +可以使用区块的静态分析来验证在给定周期(cycle)内是否存在两个碎片(shards)包含了修改同一个帐户的事务。只要这种静态分析机制一直起作用，就可以通过并行运行所有线程来处理区块。 -在一个循环中生成的交易可以在后续的任何一个循环或者区块中被发送。 区块生产者会持续不断的向区块中添加循环直到最大的墙上时间到了或者没有更多的新交易要发送。 +## Read-Only Action Handlers 只读Action处理器 -可以对一个区块使用静态分析来验证同一个循环内不存在两个线程包含同一帐户下对交易的变更。 只要保持不变一个区块就可以并行的运行所有的线程。 +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. -## 只读消息的处理 +部分账户可能会处理一些只需要决定通过与否的动作(Action)，而不会改变自己内在状态。这种情形下，只需要在一个特殊的周期内的一个或多个碎片(shards)中只有某一特定账号的只读Action处理器被包含在其中，这些处理器就能并行进行。 -有些帐户可以在传递/失败的基础上处理消息而不修改内部状态。 如果是这样的话，那么这些处理程序可以并行执行，只要只有一个特定的帐户的只读消息处理程序包含在一个或多个线程在一个特定的周期。 +## Atomic Transactions with Multiple Accounts 多账户的原子事务 -## 多帐户的原子化交易 +Sometimes it is desirable to ensure that Actions are delivered to and accepted by multiple accounts atomically. In this case both Actions are placed in one transaction and both accounts will be assigned the same shard and the Actions applied sequentially. -有时我们需要确保消息自动的被多个账户传递和接收。 在这种情况下，消息会被放在同一个交易内，账户会被分配到同一个线程，并且消息被顺序的添加。 这种情况对性能是不理想的，当用户使用涉及到“账单”时，他们将在交易内以账户唯一索引被列入其中。 +有时，我们希望确保 Action 可以被多个帐户以原子化地方式传递和接收。在这种情况下，两个Action会被放置在同一笔事务中，两个帐户将被指派相同的碎片(shard)，Actions会按顺序执行。 -基于性能和成本原因最好减少涉及两个或多个重度帐户的原子性操作。 +## Partial Evaluation of Blockchain State 对区块链状态的部分评估 -## 区块链状态的部分评估 +Scaling blockchain technology necessitates that components are modular. Everyone should not have to run everything, especially if they only need to use a small subset of the applications. -扩展区块链技术使得组件化成为必要。每个人不应该执行所有的事务，尤其是当其只需要运行应用的一个小的子集。 +大规模区块链技术组件应该是模块化的。不需要每个人都运行所有东西，特别是如果他们只需要使用应用的一小部分时，更是这样。 -一个交易所应用开发者运行一个完整节点位的是为其用户展现所有的状态。 这个交易所应用没有与社交网络建立关联的必要性。 EOS.IO 软件允许任何的完整节点选择应用的任何子集来执行。 传递给其他应用的消息可以被安全的忽略掉，因为应用程序的状态完全由传递给它的消息派生。 +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. -这与其他帐户的沟通有一些重要的影响。 最重要的是，不能假定其他帐户的状态可以在同一台机器上访问。 这也意味着，虽然很容易启用“锁”来允许一个帐户同步调用另一个帐户，如果其他帐户不驻留在内存中，这种设计模式就会出现问题。 +出于将交易状态显示给用户的目的，交易所应用程序的开发者将维护一个完整的节点。这款交易应用不需要其他社交媒体应用的相关状态。EOS.IO系统允许任何完整节点可以选择性地运行任意的应用子集。如果你的应用程序不需要依赖其他程序的状态， 那么传递给其他应用的Action将被安全地忽略。 -所有账户帐户间的状态通信必须通过包含在区块链中的消息进行。 +## Subjective Best Effort Scheduling 自主最优任务安排 -## 自主最优调度 +The EOS.IO software cannot obligate block producers to deliver any Action to any other account. Each block producer makes their own subjective measurement of the computational complexity and time required to process a transaction. This applies whether a transaction is generated by a user or automatically by a smart contract. -EOS.IO 软件并不能为区块生产生者为任何其他帐户送达的任何信息负责。 每个区块生产者要对计算的发杂读和处理一个消息的时间自己进行主观上的预测。 这同时适用于用户生成的和脚本自动生成的交易。 -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. 然而，每个单独的区块生产者要通过自己的算法来计算资源的消耗。 当一个区块生产者断定一个交易或者帐户消耗了不相称的大量的计算资源时，他们可以在生成自己的区块时拒绝该交易；但是，如果其他区块生产者认为交易是有效的，他们就仍需要处理交易。 +EOS.IO系统不能强制阻止区块生产者向其他帐户发送的任何Action。每个区块的生成者对处理一笔事务的计算复杂度和时间都有自己的主观度量，无论这一事务是由用户生成的还是由智能合约自动生成的。 -一般而言，只要一个区块生产者认为交易在资源使用限度内是有效的，那么其他区块生产者就也要接受，但可能交易传递给生产者就要花费 1 分钟。 +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. -在某些情况下，生产者可以创建包含可接受范围之外的数量级的块。 在这种情况下，下一个区块生产者可能会选择拒绝区块和束缚将被第三个生产者打破。 这和因为区块过大导致的网络延时没什么打不同。 社区会注意到模式的异常并最终会将票从流氓生产者哪里删掉。 +在使用EOS.IO软件来构建而启动的一条区块链中，在网络层上所有交易的带宽成本，都会基于所执行的wasm命令的数量来计费。但是，使用该软件的每个单独的区块生产者会使用它们自己的算法和测量方式来计算资源的使用情况。当一个区块生产者发现一笔事务或帐户已经消耗了大量的计算能力时，他们会在生成自己的块时拒绝该交易；但是，如果其他区块生产者认为该事务有效，他们仍然会处理。 -这种对计算成本的主观评估将区块链从必须精确和确定的预测一些东西要花多长时间来运行这一问题中解放出来。 有了这一设计就不需要精确的数指令，将极大的增加优化的可能性又不必打破共识。 +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. -# Token 模型与资源使用 +一般来说，只要有一个区块生产者认为一笔事务是有效的，并且所消耗的资源是在限制范围内的，那么其他所有的区块生产者也会接受，但可能要花费多达1分钟才能使该笔事务传播到这一区块生产者处。 + +In some cases, a producer may create a block that includes transactions that are an order of magnitude outside of acceptable ranges. In this case the next block producer may opt to reject the block and the tie will be broken by the third producer. This is no different than what would happen if a large block caused network propagation delays. The community would notice a pattern of abuse and eventually remove votes from the rogue producer. + +在某些情况下，区块生产者可以创建一个区块，其中包括在可接受范围之外的事务。在这种情况下，下一个区块生产者可能会选择拒绝这个区块，而这一僵局将会被第三个区块生产者终结。这与一个大区块导致网络传播延迟所引发的情况没有什么不同。社区会注意到这种滥用权力的模式，并最终撤销对该恶意区块生产者的投票。 + +This subjective evaluation of computational cost frees the blockchain from having to precisely and deterministically measure how long something takes to run. With this design there is no need to precisely count instructions which dramatically increases opportunities for optimization without breaking consensus. + +对计算成本的主观评估，可以让区块链不必去精确地度量运行某些任务所需要的时长。有了这个设计，就不需要精确地对指令计数，这将极大地增加优化的可能，而不会打破共识。 + +## Deferred Transactions 延迟交易 + +EOS.IO Software supports deferred transactions that are scheduled to execute in the future. This enables computation to move to different shards and/or the creation of long-running processes that continuously schedule a continuance transaction. + +EOS.IO 软件支持延迟事务，事务可以安排在未来执行。这可以让计算转移到不同的碎片(shard)和/或创建长期运行的持续的流程，可以为持续的事务排程。 + +## Context Free Actions 上下文无关的Actions + +A Context Free Action involves computations that depend only on transaction data, but not upon the blockchain state. Signature verification, for example, is a computation that requires only the transaction data and a signature to determine the public key that signed the transaction. This is one of the most expensive individual computations a blockchain must perform, but because this computation is context free it can be performed in parallel. + +上下文无关的动作(Action)涉及到这样的计算: 只依赖事务的数据，而不依赖区块链的状态。例如，签名验证的计算，只需要事务数据和签名来确定签署该事务的公钥。这是区块链上必须执行的最昂贵的计算之一，但是因为这一计算是上下文无关的，所以可以并行执行。 + +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. + +上下文无关的操作就像其他的用户Action一样，只是它们无法访问区块链状态来执行验证。这不仅能使 EOS.IO 可以并行处理所有上下文无关的动作(Copntext Free Actions)，例如签名验证，更重要的是，这为通用的签名验证提供了支持。 + +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. + +在支持上下文无关动作(Context Free Actions)的情况下，可伸缩性技术如Sharding、Raiden、Plasma、State Channels等，变得更加可并行化，实用性更强。这一发展可以实现高效的跨区块链通信和潜在的无限可扩展性。 + +# Token Model and Resource Usage 代币模型和资源使用 **PLEASE NOTE: CRYPTOGRAPHIC TOKENS REFERRED TO IN THIS WHITE PAPER REFER TO CRYPTOGRAPHIC TOKENS ON A LAUNCHED BLOCKCHAIN THAT ADOPTS THE EOS.IO SOFTWARE. THEY DO NOT REFER TO THE ERC-20 COMPATIBLE TOKENS BEING DISTRIBUTED ON THE ETHEREUM BLOCKCHAIN IN CONNECTION WITH THE EOS TOKEN DISTRIBUTION.** +**请注意: 在本篇白皮书中，所指的加密代币是使用EOS.IO软件所构建区块链中的加密代币。 并不是在 EOS 代币发行过程中所用的基于以太坊的ERC-20兼容代币.** + All blockchains are resource constrained and require a system to prevent abuse. With a blockchain that uses EOS.IO software, there are three broad classes of resources that are consumed by applications: - 1. 带宽和日志存储 (磁盘)； - 2. 计算与计算储备 (中央处理器)； - 3. 状态存储 (内存)。 +所有的区块链都是资源受限的，需要系统防止其滥用。在使用 EOS.IO 软件的区块链中，应用程序会消耗三大类资源: + + +1. Bandwidth and Log Storage (Disk); +2. Computation and Computational Backlog (CPU); and +3. State Storage (RAM). + +1. 带宽和日志存储 (磁盘); +2. 计算和计算积压 (CPU); +3. 状态存储 (RAM). + +Bandwidth and computation have two components, instantaneous usage and long-term usage. A blockchain maintains a log of all Actions and this log is ultimately stored and downloaded by all full nodes. With the log of Actions, it is possible to reconstruct the state of all applications. + +瞬时使用和长期使用的这两类组件都会消耗带宽和计算。区块链系统将维护所有Action的日志，这些日志将会被所有的完整节点下载和存储。通过日志，可以重构所有应用程序的状态。 + +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. -带宽和计算有两部分，瞬时使用和长期使用。 一个区块链维持着所有消息的日志，这些日志最终由完全节点存储和下载。 通过消息日志可以重现所有应用的状态。 +计算债务( computational debt)是指通过对 Action 的日志重新生成状态的计算消耗。如果计算债务的增长太大，就有必要对区块链的当前状态进行快照，并抛弃区块链的历史状态。如果计算债务增长过快，区块链将会耗用6个月的时间来重放1年的交易。因此，对计算债务进行谨慎管理是至关重要的。 -可计算债务是一个必须通过消息日志重新构建状态的计算结果。 如果可计算债务增长变得臃肿则有必要通过快照方式记录区块链状态，并丢弃区块链历史。 如果可计算债务增长过快，则它需要花费 6 个月时间来重放等值与 1 年的交易。 这很不可取，因此，可计算债务需要被细心的管理。 +Blockchain state storage is information that is accessible from application logic. It includes information such as order books and account balances. If the state is never read by the application, then it should not be stored. For example, blog post content and comments are not read by application logic, so they should not be stored in the blockchain's state. Meanwhile the existence of a post/comment, the number of votes, and other properties do get stored as part of the blockchain's state. -区块链状态存储是通过访问应用逻辑获取的信息。 它包括诸如挂单和账户余额等信息。 如果状态从未被应用读取则它不会被存储。 比如，博客发布的内容和评论如未被应用逻辑读取则他们就不应该存储在区块链状态中。 同时，发布的内容／评论的存在、投票的数量和其他属性要作为区块链状态的部分被存储下来。 +区块链存储的状态指那些可从应用程序逻辑访问的信息。它包括诸如订单和帐户余额等信息。如果应用程序不读取该状态，则不应该存储它。例如，博客文章的内容和注释不被应用程序逻辑读取，因此它们不应该存储在区块链的状态中。与此同时，博文或评论是否存在这一状态信息、投票数和其他属性将作为区块链状态的一部分被存储起来。 + +Block producers publish their available capacity for bandwidth, computation, and state. The EOS.IO software allows each account to consume a percentage of the available capacity proportional to the amount of tokens held in a 3-day staking contract. For example, if a blockchain based on the EOS.IO software is launched and if an account holds 1% of the total tokens distributable pursuant to that blockchain, then that account has the potential to utilize 1% of the state storage capacity. + +区块生成者可以公布它们可用的带宽、计算资源和状态的容量。EOS.IO系统根据账户在期限为三天的抵押合约中所抵押的代币数量，允许每个帐户可以消耗一定比例的可用容量。例如，假设一个基于EOS.IO系统的区块链应用启动，如果一个帐户持有该区块链提供的总代币的1%，那么这个帐户就有可能利用该区块链1%的状态存储容量。 -区块生产者对外发布她们可用的带宽，计算能力和状态。 EOS.IO 允许帐户按比例消耗一个 3 天对赌合约中的可用资源。 举个例子，如果一个基于 EOS.IO 的区块链启动了，一个帐户持有所有 token 发行总量的 1%，那么帐号就具有使用 1% 状态存储空间的能力。 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. -## 客观与主观的度量 +使用EOS.IO系统的区块链上，带宽和计算能力的分配是基于部分储备机制的，因为它们是短暂的(未使用的容量不能存储下来为将来使用)。EOS. IO系统将使用类似于Steem的算法来限制带宽使用速率。 + +## Objective and Subjective Measurements 客观和主观度量 + +As discussed earlier, instrumenting computational usage has a significant impact on performance and optimization; therefore, all resource usage constraints are ultimately subjective, and enforcement is done by block producers according to their individual algorithms and estimates. These would typically be implemented by a block producer via the writing of a custom plugin. + + +正如前面所讨论的，可度量计算的使用对性能和优化有很大的影响；因此，所有资源的使用限制最终都是主观的，并且根据各自的算法和估计来执行。通常由区块生产者创建自定义的插件来实现。 -如前所述，检测计算使用的性能和优化的影响很大；因此，所有资源的使用限制，最终都是主观的，执行依靠个人的算法和区块生产者进行估计。 +That said, there are certain things that are trivial to measure objectively. The number of Actions delivered, and the size of the data stored in the internal database are cheap to measure objectively. The EOS.IO software enables block producers to apply the same algorithm over these objective measures but may choose to apply stricter subjective algorithms over subjective measurements. -也就是说，有一些事情是微不足道的客观衡量。 发送的消息数和存储在内部数据库中的数据的大小是便宜的客观衡量。 的 EOS.IO 软件让区块生产者采用相同的算法应对客观的量，但可以在主观量上选择采用更严格的主观测量算法。 +除此之外，有些无足轻重的东西，可以进行客观衡量。所传递动作(Actions)的数量和存储在内部数据库中的数据大小，这些都很容易进行客观测量。EOS.IO软件允许区块生产者在这些客观的度量上应用相同的算法，但是也可以在主观度量上选择更严格的主观算法。 -## 接收方付费 +## Receiver Pays 接收方支付 -传统上来说，企业为办公场地、计算力和其他为了运行企业而需要的成本买单。 客户从企业购买具体的产品，产品销售产生的利润来盖过企业运作的成本。 类似的，没有哪个网站要求来访者为盖过运作成本而支付。 因此，去中心化应用也不应该强制用户因为使用了区块链而直接为区块链支付。 +Traditionally, it is the business that pays for office space, computational power, and other costs required to run the business. The customer buys specific products from the business and the revenue from those product sales is used to cover the business costs of operation. Similarly, no website obligates its visitors to make micropayments for visiting its website to cover hosting costs. Therefore, decentralized applications should not force its customers to pay the blockchain directly for the use of the blockchain. + +历来是由企业为办公空间、计算电力以及运营业务所需的其他费用买单。客户从企业购买特定产品，而这些产品的销售收入将用于支付企业的运营成本。同样，没有任何网站要求访问者为维护服务器而支付小额费用。因此，去中心化应用程序不应该强迫它的客户为使用区块链而向区块链支付直接费用。 A launched blockchain that uses the EOS.IO software does not require its users to pay the blockchain directly for its use and therefore does not constrain or prevent a business from determining its own monetization strategy for its products. -## 委托能力 +使用EOS.IO软件的区块链不要求用户直接向区块链支付使用费用，因此不限制或阻止企业制定其产品的货币化策略。 + +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. + +虽然接收方可以付费，EOS.IO 软件允许发送方为带宽，计算和存储付费。这样的话，应用开发者可以选择最适合他们应用程序的方式。在很多情况下，对于不想要自己实现定量配给系统(rationing system)的开发者而言，发送方付费这一方式显著降低了复杂性。应用开发者可以将带宽和计算能力代理给他们的用户，然后采用“发送方付费”的模式来使用应用。从终端用户的角度来看仍然是免费的，但是从区块链的视角看，这是属于发送方付费的模式。 + +## Delegating Capacity 授权能力 + +A holder of tokens on a blockchain launched adopting the EOS.IO software who may not have an immediate need to consume all or part of the available bandwidth, can delegate or rent such unconsumed bandwidth to others; the block producers running EOS.IO software on such blockchain will recognize this delegation of capacity and allocate bandwidth accordingly. + +在一条使用EOS.IO系统开发的区块链上，代币的持有人可能不需要立即消耗可用带宽的全部或部分资源，他们可以选择将未消耗的带宽委托或租赁给他人；在这一区块链上运行EOS.IO 软件的区块生产者将识别这一授权并分配相应的带宽。 + +## Separating Transaction costs from Token Value 将交易成本与代币价值区分开 + +One of the major benefits of the EOS.IO software is that the amount of bandwidth available to an application is entirely independent of any token price. If an application owner holds a relevant number of tokens on a blockchain adopting EOS.IO software, then the application can run indefinitely within a fixed state and bandwidth usage. In such case, developers and users are unaffected from any price volatility in the token market and therefore not reliant on a price feed. In other words, a blockchain that adopts the EOS.IO software enables block producers to naturally increase bandwidth, computation, and storage available per token independent of the token's value. + +EOS.IO软件的主要优点之一是，应用程序可用的带宽数完全独立于代币的价格之外。如果应用程序所有者持有相应数量的代币，那么应用程序可以在固定的状态下，使用固定的带宽资源持续运行。开发人员和用户不会受到代币的市场价格波动的影响，因此不会依赖于喂价。换句话说，使用EOS.IO程序运行的区块链，可以让区块生产者能够自然地增加每单位代币可用的带宽、计算资源和存储资源，这与代币的价值无关。 + +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. + + +使用EOS.IO软件的区块链，区块生产者每次产生区块，都会得到一定的代币奖励。代币的值将影响一个区块生成者能够有钱购买的带宽、存储和计算量；这个模型自然会利用代币价值的上涨来提高网络性能。 + +## State Storage Costs 状态存储成本 + +While bandwidth and computation can be delegated, storage of application state will require an application developer to hold tokens until that state is deleted. If state is never deleted, then the tokens are effectively removed from circulation. + +带宽和计算可以可以代理给他人，但是应用程序状态的存储需要开发者持有代币，直至状态删除为止。如果程序的状态永不删除，那么实际上这部分代币就退出了流通。 + +## Block Rewards 出块奖励 -A 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. +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%. -## 分离交易成本与 Token 价值 +在使用EOS.IO软件构建的区块链上，每生成一个区块，出块者都会得到一些新的代币作为奖励。在这一状况下，新创建的代币数量是由所有区块生产者公布的期望报酬的中位数而决定的。可以配置EOS.IO软件，限制区块生成者所得奖励上限，使得代币供应的年总增长率不超过5%。 -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. +## Worker Proposal System 工作提案系统 -A blockchain using EOS.IO software also awards block producers tokens every time they produce a block. Token 的值将影响其能购买的带宽、存储和计算资源；这一模型会自然的利用 token 值的上涨来增加网络的性能。 +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. -## 状态存储成本 +在基于EOS.IO 软件的区块链上，代币持有人除了选举区块生产者，还可以选出一些旨在造福社区的工作提案。获胜的提案能够得到代币奖励，所配置的每年代币的膨胀率减去已支付给区块生成者的部分，就是这部分奖励的最大值。这些提案将按照所得到的选票比例来获得代币的分配，上限是他们进行工作所要求的代币数量。所选出的提案可以由代币持有人新选出的提案所替代。 -由于带宽和计算资源可以被委托，因此应用的状态存储需要应用程序的开发者持有 token 直到状态被删除。 如果状态永远不会被删除那么 token 实质上从流通中被抹除。 +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. -每一个用户帐户需要一个确定数量的存储；因此每一个帐户必须保持一个最小的余额。随着网络存储能力的不断提升，余额的最小余额需求将会下降。 +实现工作提案的系统合约，可能不会在2018年6月份首网启动时就绪，但是资金机制会上线。区块生产者开始获得奖励时，就会开始为提案系统累积基金。由于工作提案系统会以WASM实现，所以日后可以无需分叉就能够将其加上。 -## 块奖励 +# Governance 治理 -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%。 +Governance is the process by which people in a community: -## 社区效益应用 +治理是社区之中成员的如下过程： -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 持有者选出的新的应用或智能合约所替代。 -# 治理 +1. Reach consensus on subjective matters of collective action that cannot be captured entirely by software algorithms; +2. Carry out the decisions they reach; and +3. Alter the governance rules themselves via Constitutional amendments. -治理是人们在主观问题上达成共识的过程，而这无法完全用软件算法来捕获。 An EOS.IO software-based blockchain implements a governance process that efficiently directs the existing influence of block producers. 没有了定义好的治理流程，之前的区块链依赖临时的、非正式和常常充满争议的方式治理，直接导致不可预知的结果。 -A blockchain based on the EOS.IO software recognizes that power originates with the token holders who delegate that power to the block producers. 区块生产者被授予有限的检查权威来冻结帐户，升级有缺陷的应用程序，对底层协议提出硬分叉的改进建议。 +1. 有些事实无法通过软件代码来收集，而人们通过搜集这些事实，就主观问题达成共识; +2. 执行他们达成的决策; +3. 通过宪法修正案，来变更治理规则。 -Embedded into the EOS.IO software is the election of block producers. 在对区块链没有做任何变更之前他们必须认可它。 如果区块生产者拒绝 token 持有者所预期的变更他们就会被投出。 如果区块生产者未经 token 持有者的授权作出变更，其他的非生产、完整验证 (交易所等) 会拒绝这些变更。 +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. -## 冻结帐户 +基于EOS.IO 软件的区块链实现的治理过程，有效地引导了区块生产者的现有作用。以前的区块链缺乏定义好的治理过程，依赖于临时、非正式和经常存在争议的治理过程，从而导致不可预知的结果。 -有时一个智能合约的行为处于一种一场或不可预测的状态并且无法按照预期执行；另一些时候一个应用或帐户也许发现了一个可以销毁不可想像数量资源的漏洞。 当这些问题不可避免的发生时，区块生产者有能力来扭转这一局面。 +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. -所有区块链上的区块生产者都有能力来决定哪些交易被加到区块中，这给了他们冻结帐户的能力。 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. 如果生产者滥用权利他们会被投出，而对应冻结帐户就将解冻。 +基于 EOS.IO 软件的区块链认为，权力来自于代币持有人，他们将权力代理给区块生产者。区块生产者被赋予了有限和经审查的授权，可以冻结账户，更新有缺陷的应用，并提出对基础协议进行硬分叉的变更。 -## 更改帐户代码 +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. -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 这样的生产者票形。 +EOS.IO 软件内嵌了区块生产者的选举机制。在对区块链进行任何更改之前，这些区块生产者必须批准它。如果区块生产者拒绝按代币持有人的期望做出变更，那么可以投票将其替换。如果未经代币持有者的允许区块生产者就擅作更改，那么所有其他非出块的全节点验证者(交易所等)将拒绝该更改。 -## 宪法 +## Freezing Accounts 冻结账户 -EOS.IO 应用使得区块链创建了一个点对点的服务条款协议或者绑定用户到一个合约，这都需要用户对其签名，简称“宪法”。 宪法的内容定义了仅仅依靠代码无法在用户间履行的义务，同时通过建立管辖权和可选的法律来解决相互间的争端。 每个在网络广播的交易都必须将宪法的哈希值作为签名的一部分，从而显性的将签名者绑定在合约中。 +Sometimes a smart contact behaves in an aberrant or unpredictable manner and fails to perform as intended; other times an application or account may discover an exploit that enables it to consume an unreasonable amount of resources. When such issues inevitably occur, the block producers have the power to rectify such situations. -宪法还定义了人类可读意图的源代码协议。 这个意图是用来识别错误和功能之间的差异，当错误发生时，引导社区对什么是适当或不当修复。 +The block producers on all blockchains have the power to select which transactions are included in blocks which gives them the ability to freeze accounts. A blockchain using EOS.IO software formalizes this authority by subjecting the process of freezing an account to a 15/21 vote of active producers. If the producers abuse the power they can be voted out and an account will be unfrozen. -## 升级协议 & 宪法 +有时，智能合约会发生异常或不可预知的状况，无法按预期执行；有时，应用程序或帐户可能会利用漏洞，使其消耗不合理的巨量资源。当此类问题不可避免地发生时，区块生产者应当有权力纠正。 -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: +所有区块链上的区块生产者都有权选择将哪些事务包含在区块之中，这给予了他们冻结账户的能力。使用 EOS.IO 软件的区块链将这一权力正式化了，对一个账户冻结的决策会提交给21个节点进行投票，如果得到15个节点及以上的通过，则会冻结账户。如果出块者滥用权力，他们可以被投票换掉，而冻结的账号也会解冻。 - 1. 区块生产者对宪法提出改建意见并获得 17/21 批准。 - 2. 区块生产者持续 17/21 品准连续 30 天。 - 3. 所有用户需要使用新的宪法来做签名。 - 4. 区块生产通过变更代码的方式来影响宪法并且提交一个 git 记录的哈希值。 - 5. 区块生产者持续 17/21 品准连续 30 天。 - 6. 7 天后改为会起影响的代码，给所有完整节点 1 周时间在确认源码后进行升级。 - 7. 所有未升级到最新代码的节点被自动关掉。 +## Changing Account Code 更改账户代码 -按照 EOS.IO 的默认配置，添加新特性升级区块链的流程需要 2 到 3 个月，而修复一般的 bug 不需要更改宪法需要 1 到 2 个月时间。 +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. -### 紧急变更 +当其他一切都失败了，而“无法停止的应用程序”以一种不可预知的方式运行时，使用 EOS.IO 软件的区块链，允许区块生产者在不需要硬分叉整个区块链的情况下就能替换掉帐户的代码。与冻结帐户的过程类似，替换账户的代码需要得到被选中出块节点中17 / 21个节点的投票同意。 -区块生产者可以推荐软件的变更当 bug 是伤害性 bug 或安全溢出影响用户使用的。 一般来说，这可能是对宪法的加速更新，引进新的功能或修复无害的错误。 +## Constitution 宪法 -# 脚本 & 虚拟机 +The EOS.IO software enables blockchains to establish a peer-to-peer terms of service agreement or a binding contract among those users who sign it, referred to as a "constitution". The content of this constitution defines obligations among the users which cannot be entirely enforced by code and facilitates dispute resolution by establishing jurisdiction and choice of law along with other mutually accepted rules. Every transaction broadcast on the network must incorporate the hash of the constitution as part of the signature and thereby explicitly binds the signer to the contract. -EOS.IO 首先会是一个平台用于协同用户间认证消息的传递。 脚本语言和虚拟机的具体实现与 EOS.IO 技术的设计是分离的。 任何语言或者虚拟主机，只要确定并适合沙盒，带有足够的运行效率均可以和 EOS.IO 软件 API 对接。 +EOS.IO 软件使得区块链可以在签名用户之间建立P2P的服务协议或约束性合约，即所谓“宪法”。宪法内容定义了无法通过代码来强制履行的用户义务；通过确立司法权和适用法律以及其他公认的规则，促进争议的解决。每一笔在网络中广播的事务，其签名信息中必须包含宪法的哈希值，因此明确的将签名者绑定至合约。 -## 模式定义的消息 +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. -所以用户间发送的消息都是通过模式定义定义出来的，它是区块链共识状态的一部分。 这个模式允许消息在二进制与 JSON 格式之间无缝的转换。 +宪法还定义了源代码协议的人类可读的意图(intent)。在错误发生时，这一意图用于分辨bug和特性的区别，帮助社区确定什么样的修复措施才是合理的。 -## 模式定义的数据库 +## Upgrading the Protocol & Constitution 协议和宪法的升级 -数据库状态也是通过类似的模式来定义。 这是为了确保所有应用存储的数据是可以转化为人类可读的 JSON 但存储和控制时使用高效的二进制。 +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: -## 分离授权与应用 +EOS.IO 软件定义了如下过程，借助于此，可以对由源代码和宪法所定义的协议，进行变更： + +1. Block producers propose a change to the constitution and obtains 15/21 approval. +2. Block producers maintain 15/21 approval of the new **constitution** for 30 consecutive days. +3. All users are required to indicate acceptance of the new constitution as a condition of future transactions being processed. +4. Block producers adopt changes to the source code to reflect the change in the constitution and propose it to the blockchain using the hash of the new constitution. +5. Block producers maintain 15/21 approval of the new **code** for 30 consecutive days. +6. Changes to the code take effect 7 days later, giving all non-producing full nodes 1 week to upgrade after ratification of the source code. +7. All nodes that do not upgrade to the new code shut down automatically. + + +1. 区块生产者提出变更宪法的动议，获得出块者中 15/21 的投票通过。 +2. 区块生产者对新 **宪法**的赞成态度，需要维持持续30天。 +3. 所有的用户都需要表示接受新的宪法，作为未来的交易能够处理的条件。 +4. 区块生产者采纳对源代码的变更以反应宪法的变化，并用新宪法的哈希值将变更提交到区块链上. +5. 区块生产者对新**代码**的赞成态度，需要维持持续30天. +6. 代码的修改7天之后生效, 源代码通过后，给非出块的全节点一周的时间进行更新。 +7. 所有未升级代码的全节点，会自动关闭。 + +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. + +根据EOS.IO 软件的默认配置，更新区块链增加新特性的过程往往耗时2～3个月，而只需要进行非关键问题的修复却不需要修改宪法的更新，需要1到2个月时间。 + +### Emergency Changes 紧急情况下的变更 + +The block producers may accelerate the process if a software change is required to fix a harmful bug or security exploit that is actively harming users. Generally speaking it could be against the constitution for accelerated updates to introduce new features or fix harmless bugs. + +如果需要进行软件变更，以便修复正在损害用户利益的有害漏洞或安全漏洞，区块生产者可以加速这一变更过程。通常而言加速新特性更新过程或修复无害的bug，都是违反宪法的行为。 + + +# Scripts & Virtual Machines 脚本 & 虚拟机 + +The EOS.IO software will be first and foremost a platform for coordinating the delivery of authenticated messages (called Actions) to accounts. The details of scripting language and virtual machine are implementation specific details that are mostly independent from the design of the EOS.IO technology. Any language or virtual machine that is deterministic and properly sandboxed with sufficient performance can be integrated with the EOS.IO software API. + +EOS.IO 软件首先是一个平台，协调已认证信息(称为Action，动作)在账户间的传递。脚本语言和虚拟机的实现细节将独立于 EOS.IO 技术。任何开发语言或虚拟机，只要具有确定性，经过了恰当的沙盒化并具有足够的性能，，都可以与 EOS.IO 软件的 API集成。 + +## Schema Defined Actions 模式(schema)定义的动作(Action) + +All Actions sent between accounts are defined by a schema which is part of the blockchain consensus state. This schema allows seamless conversion between binary and JSON representation of the Actions. + +在账户之间发送的所有动作都是通过模式(schema)来定义的，这是区块链共识状态的一部分。这一模式(schema)使得 Action 可以在二进制和JSON格式之间无缝转换。 + +## Schema Defined Database 模式定义的数据库 + +Database state is also defined using a similar schema. This ensures that all data stored by all applications is in a format that can be interpreted as human readable JSON but stored and manipulated with the efficiency of binary. + +数据库状态也是由类似的模式所定义的。这确保了所有应用程序所存储的所有的数据，都能够以人类可读的 JSON 格式解析，又利用了二进制文件的高效性进行操作和存储。 + +## Generic Multi Index Database API 通用的多重索引数据库 API + +Developing smart contracts requires a defined database schema to track, store, and find data. Developers commonly need the same data sorted or indexed by multiple fields and to maintain consistency among all the indices. + +开发智能合约需要定义好的数据库模式，用于追踪，存储和寻找数据。开发者通常需要按照多个字段对相同的数据排序或索引，并维持所有索引的一致性。 + +## Separating Authentication from Application 验证与应用程序相分离 To maximize parallelization opportunities and minimize the computational debt associated with regenerating application state from the transaction log, EOS.IO software separates validation logic into three sections: - 1. 验证消息是否内部一致； - 2. 验证所有前提条件是否有效； - 3. 修改应用程序状态。 +为了尽可能优化并行运算，并把从程序日志中重新生成应用程序状态时相关的计算债务( computational debt )降至最低，EOS.IO 软件将验证逻辑分为三个部分: + +1. Validating that an Action is internally consistent; +2. Validating that all preconditions are valid; and +3. Modifying the application state. + + +1. 验证动作( Action) 的内在一致性; +2. 验证所有前置条件的有效性; 以及 +3. 修改应用程序的状态 + +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. + +对Action 内部一致性的验证是只读的，不需要访问区块链状态，这意味着它执行时，可以将并行运算最大化。对前置条件（如所需的账户余额）的验证也是只读的，因此也可以受益于并行运算。只有对应用程序状态的修改才需要写的权限，必须对每个程序顺序处理。 + +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. + +验证(Authentication)是一个只读过程，用于检验一个动作(Action)是否可以生效。应用(Application)是实际起作用的过程。这两种计算都需要实时进行，不过，一旦一笔事务包含在了区块链之中，就不需要再进行验证操作了。 + +# Inter Blockchain Communication 区块链跨链通讯 + +EOS.IO software is designed to facilitate inter-blockchain communication. This is achieved by making it easy to generate proof of Action existence and proof of Action sequence. These proofs combined with an application architecture designed around Action passing enables the details of inter-blockchain communication and proof validation to be hidden from application developers, enabling high level abstractions to be presented to developers. + +EOS.IO 软件旨在促进区块链间的跨链交互，这通过简化Action存在证明(proof of Action existence)和Action顺序证明(proof of Action sequence)的生成过程来实现。这些证明与围绕Action 传递而设计的应用架构结合起来，将跨链通讯以及验证证明的细节对应用的发者隐藏，展现给开发者的是高层次的抽象。 + + +## Merkle Proofs for Light Client Validation (LCV) - 用于轻客户端验证的Merkle证明(LCV) + +![](https://camo.githubusercontent.com/d1247e97697c62a84ed549bb9b00f601beb013a0/687474703a2f2f656f732e696f2f7770696d672f4469616772616d312e6a7067) + +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. + +如果客户端不需要处理所有的事务(transaction), 那么，与其他区块链交互将变得非常容易。毕竟，一个交易所只会关注交易所的出账和入账信息，而不会关心其它。更理想的情况是，对于交易所自身所维持的链来说，如果可以将轻量级的默克尔存款证明应用其中，那么就不必完全依赖自己的区块生产者。至少，某个区块链的生产者在同步另一条区块链时，会希望尽可能减小开销。 + + +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. + +LCV的目标是能产生相对轻量级的交易存在证明，其他人只需要追踪一个相对轻量级的数据集，就可以对此进行验证。既然如此，目标就是证明一笔特定的事务被一个特定的区块所包含，并且 某一条特定的区块链的验证历史中，已经包含了该区块了。 + +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. + + +比特币的轻量级验证方式是，假设所有节点都可以读取区块头数据的完整记录，区块头数据每年增长4MB。 假设每秒产生10笔交易，一个有效的证明需要512 bytes，这对于一个出块时间为10分钟的区块链来说是可行的。但对于一个出块时间为 0.5 秒的区块链来说，这就远远谈不上“轻量”了。 + +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. + +EOS.IO 软件的轻量级证明中，在某笔交易被包含到区块链之后，只需要对任意一个不可逆的区块头进行验证即可。使用下图中的哈希链表架构，可能只需要不到1024个字节大小的证明，就可以验证任意一笔交易的存在。 -验证消息的内部一致性是只读的并且无需访问区块链状态。 这意味着它可以以最大并发来执行。 验证前提条件，比如需要的余额数，是只读的因此也可以受益与并行计算。 只有更改应用状态时需要写入权限并且必须顺序的执行每个应用。 +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. -身份认证是一个验证消息可被使用的只读过程。 应用程序实际上在发挥作用。 同一时间两者都需要被计算，然而一旦消息被包含进区块它就不再需要进行消息验证的操作了。 +给定区块链上任意一个区块的区块id，以及一个不可逆的可信区块的区块头。可以证明某个区块是包含在区块链上的。这一证明的算法复杂度是（log2(N)），其中 N 是区块链上的区块数量。给定 SHA256 加密算法的类型，只用 864 个字节，你就能够证明在一条包含了 1亿个区块的链上，一个任意的区块是否存在。 -## 虚拟机独立架构 -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. +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. -### Web 组建 (WASM) +生成区块的时候如果使用合适的哈希链表来产生这些证明，只会带来很小的增量开销，这意味着没有理由不以这种方式去生成区块。 -网络组建是一种为了构建高性能的 web 应用而新兴的 web 标准。 只需要进行少量的更改 Web 组建就可以被制作为确定性的和沙盒化的。 Web 组建的好处是它有着广泛的产业支持并且它可以让智能合约使用熟知的语言进行开发，比如 C 或 C++。 +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. -以太访开发者已经开始更改 Web 组建来提供合适的沙盒与确定性在他们的[以太访式 Web 组建 (WASM)](https://github.com/ewasm/design)。 这种方式让 EOS.IO 很容易的与之适配和对接。 +对其他链上的证明进行验证时，在时间、空间和带宽方面都有很大的优化空间。跟踪所有区块头数据(420 MB/年)可以让证明的尺寸最小。只跟踪最近的区块头，可以在长期存储文件的最小化和证明尺寸的最小化之间，得到均衡。或者，一个区块链可以采用惰性评估的方式，只记录过去证明的中间哈希值。新的证明只需要包含指向已知的sparse tree（稀疏树）结构的链接。实际使用的方式，需要根据在merkle 证明中所引用的交易位于外链上所占的比例来决定。 -### 以太访虚拟机 (EVM) +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. -这个虚拟机已经被众多已有的智能合约所采用并且可以通过适配应用与 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. +在一条区块链上，可以将另外一条区块链的所有区块历史都包含其中，不需要再进行跨链的证明。在跨链关联密度达到一定程度之后，这会是更高效的做法。出于性能考虑，理想情况是尽可能降低将跨链证明的频率。 -# 跨链通信 +## Latency of Interchain Communication 跨链通讯延迟 -EOS.IO 软件被设计为跨区块链通信友好的。 这是通过生成消息存在证明与消息时序证明变的简单而实现的。 这些证明与应用架构设计相结合，即围绕消息细节的跨链传输和有效性验证时隐藏应用程序开发者的架构设计。 +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. - +与外部区块链通讯时，区块生产者必须等到一笔事务(transaction)经过外部区块链的确认，达到了100%的不可篡改的确定性之后，才能够接受该笔事务，认可为有效的输入。在一条基于 EOS.IO 软件的区块链上，借助于DPOS 0.5秒的出块速度，并使用了额外的拜占庭容错的不可篡改性，这一过程大约耗时为0.5秒。如果某个链上的区块生产者不等到交易不可篡改，就像一个交易所接受了一笔存款而后这笔操作又撤销了的情况一样，这会影响这条链共识的有效性。EOS.IO 软件使用了 DPOS 和 aBFT(异步拜占庭容错)算法，提供快速的不可篡改性。 -## 用于轻客户端的 Merkle 证明 (LCV) +## Proof of Completeness 完成性证明 -如果客户端不需要处理所有的交易会让多区块链间的整合更为轻松。 毕竟，一个交易所只需要关心交易所的入账和出账，别无他求。 如果交易所链条可以使用资金的轻量 merkle 证明，而不必非要完全依赖对它区块生产者的信任会是一个不错的主意。 至少一个链的区块生产者在与其他区块链同步时更乐意保持尽可能小的开销。 +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. -LCV 的目标能产生相对轻量存在性证明，使得任何追踪相对轻量数据集的人可以验证其有效性。 在这种情况下，目的是为了证明一个特定的交易是包含在一个特定的区块中，区块包含在一个特定的区块链的已验证历史中。 +使用外部区块链的merkle 证明，知道所有处理过的事务都是有效的，和知道没有事务被跳过或忽略，这两者之间有明显差别。虽然无法证明最近的所有事务都是已知的，但是，要证明在事务的历史中不存在遗漏，还是可能的。EOS.IO 软件为传递给每个账户的每个Action都指定了一个序列号，使得这一点成为可能。用户可以用这些序列号来证明，与某个账户相关的所有的 Action 都得到了处理，并且是按顺序处理的。 -比特币支持通过全节点的完整记录获取每年 4MB 大小的区块头信息来验证交易。 每秒 10 个交易，一个有效的证明需要 512 个字节。 这对于有 10 分钟间隔的区块链没有问题，但是对于 3 秒间隔区块链就显得不那么“轻量”了。 +## Segregated Witness 隔离见证 -EOS.IO 软件使得任何一个人只要他拥有包含交易所对应区块之后的随意一个不可逆的区块头，他就可以进行轻量证明。 使用下面展示的哈希链结构就可以使用少于 1024 字节的大小来完成任意交易的存在性证明。 如果假设校验节点在过去几天内所有的区块头一直增长 (2MB 的数据)，那么验证这些交易将只需要 200 字节就够了。 +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. -将生产的区块与恰当的哈希链做关联使得开销增幅很小，这意味着没有理由不使用这种方式来生成区块。 +隔离见证(SegWit) 是指，在不可逆地将一笔事务包含到区块链中之后，事务的签名不再具有相关性了。一旦事务具有不可篡改性了，签名数据可以被剪掉，其他所有人都能够达成当前的状态。由于在大多数的事务之中签名数据占据了很大一部分，SegWit 能够明显地降低磁盘使用量，减少同步时间。 -当需要验证其他链时，有譬如 时间/ 空间/ 带宽 的多样化优化可以做。 追踪全部区块头 (420 MB/年) 将保持证明体积的轻巧。 只追踪最近的头可以提供最小长期存储和证明大小来获得。 另外，一个区块链可以使用懒惰的评估方法，即它记住过去证明的中间值哈希。 新证明只需要包含指向已知稀疏树的链接。 确切的方法将取决于那些包含对 Merkle 证明引用的交易所在的外部区块的比例。 +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. -一定密度的联系后，将变得更为高效，一个链会包含另一个链整个区块的历史和消除证据一起，这样就不需要通信便可以验证了。 出于性能原因，应最小化的跨链证明的频率。 +同样的概念可以用在跨链通讯的merkle证明中。一旦一笔证明被接受，并不可逆的记录到区块链之后，想达成正确的区块链状态，用作证明的sha256 哈希的2kb文件就不再需要了。同样使用隔离见证，给跨链通讯所带来的节省程度，是给普通签名带来节省程度的32倍。 -## 跨链通信的延时 +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. -当与外部区块链进行通信时，区块生产者必须等待直到 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. +隔离见证的另外一个例子是Steem的文章。在这一模式下，(在区块链中)一篇帖子只包含博客内容的sha256哈希函数值，博客正文会被放在隔离见证数据中。区块生产者只需要验证内容是存在的，并且具有给定的哈希值，而不需要在链上存储博文的内容，就能够从区块链的日志中恢复到当前的状态。这样做可以在不必永久保存博文内容的情况下，就能够证明所说的内容曾经存在过。 -## 完备性证明 +# Conclusion 结论 -当使用来自外部区块链的 Merkle 证明时，在已知所有交易均已验证和已知没有交易被跳过或遗忘之间有一个重要的差异。 虽然不可能证明所有最近的交易是已知的，但有没有间隙的交易历史是可以被证明的。 EOS.IO 软件在每个用户的每个传递的消息上分配了一个序列号。 一个用于可以使用这些序列号来证明所有的消息由某个特定帐户处理，只需要看它是否是按序执行的。 +The EOS.IO software is designed from experience with proven concepts and best practices, and represents fundamental advancements in blockchain technology. The software is part of a holistic blueprint for a globally scalable blockchain society in which decentralized applications can be easily deployed and governed. -# 总结 +EOS.IO 软件是基于已为实践所证实的概念和最优实践的经验来设计的，代表着区块链技术的根本性进步。它是全球性可扩展的区块链社会宏伟蓝图的一部分 ，在其中，可以轻松部署和管理去中心化的应用程序。 -EOS.IO 软件是从证明概念的经验和最佳实践设计而来，它代表了区块链技术的重要进步。 该软件是全球可扩展区块链社会伟大蓝图中的一部分，它将应用去中心化并得以轻松的发布和治理。 \ No newline at end of file