逐字逐句解读BM最新发布的EOSIO Dawn 4.0版本介绍
BM在5月5日于Medium上发布了关于EOSIO Dawn4.0的版本介绍。在过去的一个月里，block.one团队一直在为EOSIO的精简性和稳定性付出着努力，本文将从十余个方面介绍EOSIO Dawn4.0
It has been about 1 month since block.one released EOSIO Dawn 3.0. This past month our team has been focused on cleanup and stability of the EOSIO software. A big part of this work was moving toward a proof of concept for inter-blockchain communication.
距离 block.one 发布 EOSIO Dawn 3.0已经一个月了。 在过去的一个月里，我们的团队一直专注在EOSIO软件的优化和稳定性，这其中很大一部分工作是在证明链间通信的可行性。
Excluding merges, 43 authors have pushed 818 commits to github. This puts EOSIO in the top 8 most active c++ projects on github in the past month. As you can see a lot is happening
不将merge操作计算在内，共有43位开发者提交818个commit到项目的github仓库。 这让EOSIO成为过去一个月中github中最活跃的8个C++项目之一。 正如你所看到的，许多事情正在发生。
１．Now is now Now
２．New Market-Based RAM Allocation Model
３．Rise of Inter-Blockchain-Communication
４．Upgrade DPOS Last Irreversible Block ．Algorithm
７．Light Weight Producer Schedule Change Proofs
８．Refined Producer Pay Model
9． Producer Vote Decay
１０．Exchange Integration Support
One of the biggest changes in EOSIO Dawn 4.0 is that we have changed the definition of the current time from “time of head block” to “time of current block”. This change resolves a lot of corner-cases with time-based operations in the presence of missed blocks and enables much more accurate measuring of elapsed-time within smart contracts.
EOSIO Dawn 4.0最大的变化之一是我们已将当前时间的定义从“头块的时间”改为“当前区块的时间”。 这种变化使得大量包含时间操作的案例可以在存在缺失区块的情况下执行，并且更精确地计算智能合约的运行时间。
In our testing we determined that how the EOSIO System Contract was allocating RAM (database space) to those who staked tokens would lead to shortages down the road. We switched to a market-based allocation approach using the Bancor algorithm.
Our math indicates that if 1TB of RAM was allocated on a pro-rata basis to token holders then the cost-per-byte would be $0.018 (assuming $20/token). The reality is that most token-holders don’t actually have an active need to use the RAM they might be entitled to; therefore, we are initially pricing RAM at $0.000018 per byte (assuming $20/token). New accounts require about 4KB of RAM which means they will cost about $0.10. As RAM is reserved the price will automatically increase so that the price approaches infinity before the system runs out of RAM.
Under the Dawn 3.0 system contract, you could only sell RAM for the price you paid. The goal was to disincentivize hoarding and speculation. The downside to this approach is that those who buy RAM cheaply have no financial incentive to free RAM for other users after it gets more congested. Under Dawn 4.0 the system contract now buys and sells RAM allocations at prevailing market prices. This may result in traders buying RAM today in anticipation of potential shortages tomorrow. Overall this will result in the market balancing the supply and demand for RAM over time.
Over time Moore’s law will allow block producers to upgrade to 4TB or even 16TB of RAM and this increase in supply will trickle into the the EOSIO RAM market lowering prices.
在Dawn 3.0系统合约中，您只能以您支付的价格出售RAM。 目的是抑制囤积和投机。 这种方法的缺点那些廉价购买RAM的人在RAM变得更紧缺后，没有为其他用户腾出RAM的经济激励。在Dawn 4.0之下，系统合约现在以当前市场价格购买和销售RAM分配。 这可能会导致交易商在预计明天可能出现短缺的情况下购买RAM。 总的来说，这将导致市场随着时间的推移平衡RAM的供需。
As a smart contract developer, RAM is a precious resource which is consumed by the database records you store. Due to the cost of RAM it will be important to minimize the amount of data that you store in the in-memory database and design your applications with the ability to free RAM after your users are done. For example, Steem only stores 1 weeks worth of content in RAM so that the total size doesn’t grow much over time.
Now that there is a RAM market, speculators may want to trade RAM price-volatility for profit. The EOSIO system contract makes RAM non-transferrable and charges a 1% fee on trades. The result of this fee is to offset the natural inflation of tokens by taking them out of the market. If annual trading volume of RAM equals the token supply then 100% of all block producer rewards will be covered by the RAM market fees.
那么现在形成了一个RAM市场，投机者或许想要利用RAM价格的波动性获取盈利。而 EOSIO 系统合约设定RAM不可转让，并收取1％的交易费用。这笔费用的结果是通过将其退出市场来抵消Token 的自然通货膨胀。如果RAM的年度交易量等于 Token 供应量，则所有块生产者奖励的100％将由 RAM 市场费用支付。
High performance blockchains need all data in RAM because the time to access disk will quickly drop transaction throughput to just a couple hundred transactions per second. In order to scale RAM usage we need multiple chains with independent memory regions running on independent hardware.
EOSIO block producers can operate many different chains that all use the same token for buying RAM and staking bandwidth. The producer elections will happen on the main chain and all related side-chains will be operated by the same set of producers. Each chain can have its own 1 TB+ of RAM and decentralized applications can send messages between chains with just a couple seconds of latency.
The price of RAM will be different on all chains which will inform DAPP developers where it is cheapest to operate.
EOSIO区块生产者可以运行许多不同的链，它们都使用相同的token来购买RAM和持有带宽。超级节点选举将在主链上进行，所有相关的侧链将由同一组超级节点维护。 每个链可以拥有1 TB以上的RAM，DAPP可以在链间发送消息，仅需几秒钟的延迟。
Inter Blockchain Communication (IBC) involves both chains validating merkle proofs that are 1KB+ in size and involve dozens of cryptographic hash functions and/or 15+ signature verifications. In other words, the cost of validating a message from another chain is about 15x to 30x higher than the cost of validating normal transactions.
Fortunately, validating these proofs is trivial to parallelize as they do not depend upon blockchain state. A blockchain that only processed messages from other chains could easily consume 30 CPU cores while only sustaining a couple thousand transactions per second.
It is our belief that scaling via Inter Blockchain Communication will give almost unlimited scaling potential. This approach scales RAM, network, and CPU at the same time. Considering that signature verification, context-free-action validation and IBC proofs will already saturate most CPUs with high-single-threaded throughput, optimizing for multi-threaded WASM execution will likely be bottlenecked by other resource constraints.
Under EOSIO Dawn 3.0 we made a lot of design decisions around the potential for future multi-threaded WASM execution. Unfortunately, until you actually implement a full multi-threaded implementation it is impossible to know whether we have all the corner cases covered. This means that EOSIO Dawn 3.0 had a lot of architecture complexity that was not giving any immediate benefit.
We now believe that the path of upgrading from single-threaded to multi-threaded execution is to launch a new chain with multi-threaded support run by the same block producers and staking the same native tokens. This gives the new chain complete freedom to make design tweaks as necessary to support multi-threaded operation without risking an in-place upgrade to a live chain.
With this roadmap to parallelism we can simplify EOSIO 1.0 and optimize it for maximum single-threaded performance and ease-of-development. We anticipate that the single-threaded version of EOSIO may one day achieve 5,000–10,000 TPS. We also anticipate that many applications will prefer the many-chain approach to scaling as it will lower overall costs and scale faster.
通过这个并行性路线图，我们可以简化EOSIO 1.0并优化它以实现最高的单线程性能和易于开发。 我们预计EOSIO的单线程版本有一天可能达到5,000-10,000 TPS。 我们也预计，许多应用程序将更倾向于多链方法来扩展，因为它会降低总体成本并加快扩展。
Those of you who have followed consensus algorithm debates may have heard that DPOS with the last irreversible block (LIB) algorithm (as it exists in Steem & BitShares) has the potential to fall out of consensus in certain extreme network connectivity disruptions. In the past I have dismissed this potential failure mode due to its purely theoretical nature and the relatively minimal costs and downtime. The LIB algorithm was just a metric, like the 6-block rule for Bitcoin. Pure DPOS always relied on longest-chain rule which will always reach eventual consensus. The LIB algorithm was a short-cut designed to optimize undo-history and give a confidence measure to exchanges.
EOSIO’s IBC algorithm depends upon the DPOS LIB in order to be certain of finality. The costs associated with a LIB failure and the difficulty in fixing it are much higher once you introduce IBC. Our team, specifically Bart and Arhag, have come up with an elegant improvement to the LIB algorithm which guarantees that it is impossible for two nodes to reach a different LIB without more than ⅓ of them being byzantine. Furthermore, it is possible to detect byzantine behavior of a single peer. Read more about it here.
It is the lack of finality of Bitcoin and Ethereum blocks that make inter blockchain communication with legacy chains difficult and/or very high latency. The new tweak to DPOS brings it up to a new level of byzantine fault-tolerant finality and robust in all network environments.
参与过共识算法讨论的人可能听说过，使用最后一个不可逆块（LIB）算法（如 Steem＆BitShares 中存在的算法）的DPOS在某些极端网络连接中断时有可能失去共识。在过去，由于其纯粹的理论性质以及相对最低的成本和停机时间，我已经驳回了这种潜在的失败模式。LIB算法只是一个度量标准，就像比特币的6区块规则。纯粹的DPOS总是依赖最长链规则，这将永远达到最终的一致。LIB算法是一种捷径，旨在优化还原历史并为交易提供可信度度量。
EOSIO的IBC算法依赖于DPOS LIB以确定最终结果。一旦你引入IBC，与LIB失败相关的成本和修复它的难度都会变高。我们的团队，特别是 Bart 和 Arhag，对LIB算法进行了优化改进，以保证不超过其中的1/3是拜占庭式的时，两个节点不可能达到不同的LIB。此外，有可能检测单个对等体的拜占庭行为。关于此的更多信息见：https://github.com/EOSIO/eos/issues/2718
Some users have expressed concern over the 12 character name limit imposed on EOSIO accounts. These 12 character names are derived from base-32 encoding of a 64 bit integer. The 64 bit integer is the native machine word size and is therefore very efficient. Within a transaction we refer to account names many times, (code, scope, permissions, etc), and our database indexes are also based around these 64 bit integers. Increasing the length of an account name would have far-reaching impact on performance and architecture.
That said, our vision for blockchains is to separate the concept of accounts from identity and to establish a dynamic on-chain mapping between account names and more readable display names.
It is best to view account names as license plates where users can pick vanity plates that are easier to remember. That said, the vast majority of people should be able to find an attractive 12-character (or less) name.
Due to the potential high-value of certain names, we believe that the EOSIO system should offer a dynamic pricing model for account names. Furthermore, the ability to namespace accounts such as *.com can provide an extra layer of security for users and/or groups.
Due to the limited development time between now and the release of version 1.0 of the EOSIO software, we are going to recommend that all account names be forced to 12 characters and not contain any ‘.’ characters. The community can then upgrade the system contract (without hard fork) once a viable pricing and anti-name-squatting policy is identified. We will likely provide a model similar to BitShares where account names are priced by length and character content.
一些用户对EOSIO帐户上的12个字符名称限制表示担忧。 这12个字符名称是从64位整数的base-32编码派生的。 64位整数是本地机器字大小，因此非常有效。 在一个事务中，我们多次引用帐户名（代码，范围，权限等），而我们的数据库索引也是以这些64位整数为基础的。 增加帐户名称的长度将对性能和架构产生深远影响。
由于某些名称潜在的高价值，我们认为EOSIO系统应为帐户名称提供动态定价模式。 此外，诸如* .com之类的命名空间帐户的能力可以为用户或者群体提供额外的安全保护。
On Steem, BitShares, and EOS Dawn 3.0 and earlier it was not possible to validate a block-header without applying the full block. With EOS Dawn 4.0 we now support header-only validation. This feature is the basis of light clients and IBC and also prevents a range of attack vectors while allowing blocks to propagate across the network without waiting for each node to do full verification.
The simplest form of IBC for high-frequency communication involves light clients processing all headers and then users providing simple merkle-proofs of actions relative to a known block.
在Steem, BitShares和 EOS Dawn 3.0以及更早的版本中，如果不使用整个区块是不能验证区块头的。在EOS Dawn 4.0中，我们支持了只需要对区块头进行验证。这个功能是轻客户端和链间通信的基础，同时还可以阻止一系列攻击媒介，同时无需等待每个节点进行全节点验证的情况下，区块数据也可以在网络中传播。
We spent significant time cleaning up the process by which blocks are built and applied. Under the new model a block is created with the same sequence of API calls that are used to apply the block. This ensures the same code-paths are followed and minimizes the potential for inconsistencies between what a producer thinks is valid and what a validator thinks is valid. This cleanup makes the process of applying the block as little more than a script that replays what the producer did.
As we were implementing the IBC proof-of-concept we realized that Dawn 3.0 had a few edge cases where simple signature proofs were impossible. We wanted to make light-weight sparse-header validation as simple as possible which necessitated a refactor of how blocks are signed.
１．Producer Schedule Chain can be Validated Independently of Headers
２．Each Block Header References Schedule Version
３．It is impossible to produce blocks without signing schedule change proofs
４．Light clients and IBC Contracts can process only Producer Schedule Changes
With EOSIO Dawn 4.0 it is now possible to validate changes to the producer schedules without having to validate any block headers. When a producer signs a block they also sign the new schedule such that it is impossible for there to be two-competing and validly signed Producer Schedules without ⅔+ of producers colluding or ⅓+ colluding with a very bad network split.
使用EOSIO Dawn 4.0 现在可以验证生产者调度的更改，而无需验证任何区块头。当一个生产者签署一个区块时，他们也签署新的调度，这样就不可能出现两者相互竞争和有效签署的生产者调度，而没有⅔以上生产者的共同勾结或者⅓以上在非常差的网络分离中勾结
There has been a lot of community discussion around producer pay and how to allocate the maximum of 5% inflation. The reference system contract that block.one will provide with EOSIO 1.0 will allocate inflation like so:
There are 21 active block producers and any number of standby producers. The top 21 divide up the 0.25% per-block rewards proportional to the number of blocks each one producers. All block producer candidates (including the top 21) also divide up the .75% per-vote rewards budget proportional to the total number of votes they receive. They can claim their share of the per-vote rewards at most once-per-day. In order to claim their share they must qualify for at least 100 tokens/day. Producers candidates who do not qualify for at least 100 tokens/day on a per-vote basis will receive nothing.
The idea behind this algorithm is to ensure all candidate producers have sufficient pay to provide full-node services to the community and to ensure no one is in the position of receiving money that is insufficient to cover their costs. Assuming the top 200 producer candidates all received the same number of votes this would support 21 active producers and 179 stand-by producers. In reality some producers will have significantly more votes than others which may reduce the number of paid-standby producers.
It is critical to have a minimum per-day payment so that wealthy individuals who have no intention of producing blocks don’t attempt to earn interest on their producer candidate by voting on themselves.
Much of the work we are doing since Dawn 3.0 involves tweaking the system contract. One of those tweaks is the implementation of vote decay. In order to maintain maximum voting influence each voter will have to re-assert their vote every week. Voting influence decays with a half-life of 1 year for those who do not keep their votes up to date.
We recommend that the constitution contain language forbidding the use of automated voting bots as the purpose of vote-decay was to ensure that voters re-evaluate their decisions rather than “set-it and forget it”. While it is not possible to prove the use of bots, it will be possible to prove that people do not use smart contracts to auto-vote.
自Dawn 3.0以来，我们所做的大部分工作都涉及调整系统合约。 其中一项调整是实施投票衰减。 为了保持最大的投票影响力，每个选民必须每周重新投票。 对于那些不更新其选票的人来说，其投票影响力会衰退，而且半衰期为1年。
As we approach the EOSIO 1.0 release, many people are asking us for information about how exchanges will monitor an EOSIO blockchain for incoming deposits and/or validate that their out-going withdraws are accepted and irreversibly confirmed. We have created a tutorial on using cleos (our command line eosio interface) to monitor the chain for incoming deposits. We have also created a demonstration python script that monitors deposits and withdraws. With this tutorial and example script exchanges should have everything they need to begin integration with EOSIO based blockchains.
随着EOSIO 1.0版本的临近发布，很多人都在要求我们提供有关交易所如何监控EOSIO区块链接收存款，以及确认其外部撤回被接受并不可逆转地确认的信息。 我们已经创建了一个使用cleos（我们的命令行eosio界面）来监视链上交易的教程。 我们还创建了一个python脚本的验证来监视存款和提款。 通过本教程和示例脚本，交易所就可以让一切所需的基于EOSIO的区块链集成开始工作了。
EOSIO Dawn 4.0的可用性
Development of EOSIO Dawn 4.0 code is ongoing in the ‘slim’ branch on github. We will be polishing it up and officially releasing it May 11, 2018. At that time we will move slim to master and tag a release. Developers who want to remain on the cutting edge can follow our progress on the slim branch.
EOSIO Dawn 4.0代码的开发工作正在Github上进行。 我们将在2018年5月11日正式将其发布。届时，我们会将slim移到master分支上，掌握并打一个版本标签。 希望继续使用最新版本的开发人员可以继续关注slim分支。
EOSIO software is making massive strides toward a robust 1.0 release this June. With Dawn 4.0 the code has been cleaned up significantly and we are more confident than ever.
今年6月，EOSIO软件正朝着强劲的1.0版本迈进。 使用Dawn 4.0后，代码已经被显著优化，我们比以往更加自信。