动态 EOS 4.0 介绍 (翻译)

loyo · May 05, 2018 · Last by strahe replied at May 05, 2018 · 6305 hits

本文翻译自:https://medium.com/@bytemaster/introducing-eosio-dawn-4-0-f738c552879

自 block.one 发布 EOSIO Dawn 3.0 以来已有大约 1 个月的时间。 上个月,我们的团队一直专注于 EOSIO 软件的清理和稳定性。 这项工作的很大一部分正在向区块链交流的概念验证。

不包括合并,43 位作者已推送 818 次提交到 github。 这使得 EOSIO 在过去一个月里成为 github 上最活跃的 8 个最活跃的 c ++ 项目。 正如你所看到的很多事情正在发生。

  1. 现在就是现在
  2. 新的基于市场的 RAM 分配模型
  3. 区块链间通信的兴起
  4. 升级 DPOS 最后的不可逆块算法
  5. 名字蹲
  6. 仅头部验证
  7. 轻量级生产者计划变更证明
  8. 精制生产者薪酬模型
  9. 制片人投票衰退
  10. Exchange 集成支持

现在就是现在

EOSIO Dawn 4.0 中最大的变化之一是我们已将当前时间的定义从 “开始时间块” 更改为 “当前时间块”。 这种变化解决了很多具有基于时间的操作的角落案例,并且可以在存在错误的块的情况下更精确地测量智能合约中的经过时间。

原文

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.

RAM 分配模型

在我们的测试中,我们确定了 EOSIO 系统合同如何将 RAM(数据库空间)分配给放置令牌的人将导致短缺。我们转向使用 Bancor 算法的基于市场的分配方法。

我们的数学表明,如果 1TB 的 RAM 是按比例分配给令牌持有者的,那么每字节成本将为 0.018 美元(假设为 20 美元/令牌)。现实情况是,大多数代币持有者实际上并不积极需要使用他们可能有权使用的 RAM;因此,我们最初将内存定价为每字节 0.000018 美元(假设为 20 美元/令牌)。新帐户需要大约 4KB 的 RAM,这意味着他们将花费大约 0.10 美元。随着 RAM 被保留,价格将自动增加,以便在系统用完 RAM 之前价格接近无穷大。

根据 Dawn 3.0 系统合同,您只能以您支付的价格出售内存。目标是抑制囤积和猜测。这种方法的缺点是那些廉价购买 RAM 的用户在获得更多拥塞后没有经济激励来为其他用户腾出内存。在 Dawn 4.0 之下,系统合同现在以当前市场价格购买和销售 RAM 分配。这可能会导致交易商在今天预计明天可能出现短缺的情况下购买 RAM。总的来说,这将导致市场随着时间的推移平衡 RAM 的供应和需求。

随着时间的推移,摩尔定律将允许块生产商升级到 4TB 甚至 16TB 的内存,并且这种供应的增加将逐渐渗入 EOSIO RAM 市场,降低价格。

原文

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.

对智能合同开发商的影响

作为一名智能合约开发人员,RAM 是您存储的数据库记录所消耗的宝贵资源。 由于 RAM 的成本,将存储在内存数据库中的数据量减到最小并且在用户完成后可以释放 RAM 来设计您的应用程序将是非常重要的。 例如,Steem 仅在 RAM 中存储了 1 周的内容,因此总体大小不会随着时间增长而增长。

原文

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.

尽量减少猜测

现在有了 RAM 市场,投机者可能想要将 RAM 价格波动性换成利润。 EOSIO 系统合同使 RAM 不可转让,并收取 1%的交易费用。 这笔费用的结果是通过将其退出市场来抵消代币的自然通货膨胀。 如果 RAM 的年度交易量等于令牌供应量,则所有块生产者奖励的 100%将由 RAM 市场费用支付。

原文

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 中的所有数据,因为访问磁盘的时间会将事务吞吐量迅速降至每秒几百个事务。 为了扩展内存使用量,我们需要在独立硬件上运行独立内存区域的多个链。

EOSIO 块生产者可以运行许多不同的链,它们都使用相同的标记来购买 RAM 和放宽带宽。 生产者选举将在主链上进行,所有相关的侧链将由同一组生产者经营。 每个链可以拥有自己的 1 TB + RAM,分散式应用程序可以在链间发送消息,仅需几秒钟的延迟。

RAM 的价格在所有的链上都会有所不同,这会告诉 DAPP 开发者哪里运行起来最便宜。

原文

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.

并行性路线图

区块链间通信(IBC)涉及两条链,验证 Merkle 证据的大小为 1KB +,并涉及数十个密码散列函数和/或 15+ 签名验证。换句话说,验证来自另一个链的消息的成本比验证正常事务的成本高大约 15 倍到 30 倍。

幸运的是,验证这些证明并不重要,因为它们不依赖区块链状态。仅处理来自其他链的消息的区块链可以轻松消耗 30 个 CPU 内核,而每秒只能支持几千个事务。

我们相信通过 Inter Blockchain Communication 扩展可以提供几乎无限的扩展潜力。这种方法可以同时扩展 RAM,网络和 CPU。考虑到签名验证,上下文无关操作验证和 IBC 证明已经使大多数 CPU 具有高单线程吞吐量,因此针对多线程 WASM 执行的优化可能会受到其他资源限制的瓶颈。

在 EOSIO Dawn 3.0 下,我们围绕未来多线程 WASM 执行的潜力做了大量设计决策。不幸的是,除非实际实现完整的多线程实现,否则不可能知道我们是否覆盖了所有的角落案例。这意味着 EOSIO Dawn 3.0 具有很多架构复杂性,并没有带来任何直接的好处。

我们现在认为,从单线程升级到多线程执行的途径是启动一个新的链,其中包含由同一个块生产者运行的多线程支持,并且放置相同的本地令牌。这使得新链完全自由地进行必要的设计调整,以支持多线程操作,而无需对现场链进行就地升级。

通过这个并行性路线图,我们可以简化 EOSIO 1.0 并对其进行优化,以实现最高的单线程性能和易于开发。我们预计 EOSIO 的单线程版本有一天可能达到 5,000-10,000 TPS。我们也预计,许多应用程序将更倾向于多链方法来扩展,因为它会降低总体成本并加快扩展。

原文

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.

升级 DPOS 最后的不可逆块算法

那些遵循共识算法辩论的人可能听说过,使用最后一个不可逆块(LIB)算法(如 Steem&BitShares 中存在的算法)的 DPOS 在某些极端网络连接中断时有可能失去共识。在过去,由于其纯粹的理论性质以及相对较低的成本和停机时间,我已经放弃了这种潜在的失败模式。 LIB 算法只是一个度量标准,就像比特币的 6 块规则。纯粹的 DPOS 总是依赖最长链规则,这将永远达到最终的一致。 LIB 算法是一种捷径,旨在优化撤消历史并为交易提供可信度度量。

EOSIO 的 IBC 算法依赖于 DPOS LIB 以确定最终结果。一旦您引入 IBC,与 LIB 失败相关的成本和解决此问题的难度就会更高。我们的团队,特别是 Bart 和 Arhag,对 LIB 算法进行了优化改进,以保证两个节点不可能达到不同的 LIB,其中不超过其中的 1/3 是拜占庭。此外,有可能检测单个对等体的拜占庭行为。在这里阅读更多。

比特币和以太坊区块的缺乏导致区块链与传统连锁店之间的沟通困难和/或非常高的延迟。对 DPOS 的新调整将其带到全新的拜占庭容错终结水平,并且在所有网络环境中都具有强大的可靠性。

原文

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.

名字蹲

一些用户对 EOSIO 帐户上的 12 个字符名称限制表示担忧。这 12 个字符名称是从 64 位整数的 base-32 编码派生的。 64 位整数是本地机器字大小,因此非常有效。在一个事务中,我们多次引用帐户名(代码,范围,权限等),而我们的数据库索引也是以这些 64 位整数为基础的。增加帐户名称的长度将对性能和体系结构产生深远影响。

也就是说,我们关于区块链的愿景是将帐户的概念与身份分开,并在帐户名称和更具可读性的显示名称之间建立动态链上映射。

最好将帐户名称视为牌照,用户可以选择容易记住的洗手盆板。也就是说,绝大多数人应该能够找到一个有吸引力的 12 个字符(或更少)的名字。

由于某些名称潜在的高价值,我们认为 EOSIO 系统应为帐户名称提供动态定价模式。此外,诸如* .com 之类的命名空间帐户的能力可以为用户和/或组提供额外的安全层。

由于从现在到 EOSIO 软件 1.0 版的发布时间有限,我们将推荐所有帐户名称被强制为 12 个字符,并且不包含任何'。'字符。然后,一旦确定了可行的定价和反名称策略,社区就可以升级系统合同(没有硬分叉)。我们可能会提供类似于 BitShares 的模型,其中帐户名称按长度和字符内容定价。

原文

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.

仅头部验证

在 Steem,BitShares 和 EOS Dawn 3.0 及更早的版本中,如果不应用完整块,则无法验证块标题。 借助 EOS Dawn 4.0,我们现在支持仅标头验证。 此功能是轻客户端和 IBC 的基础,同时还可以阻止一系列攻击媒介,同时允许块在网络中传播,而无需等待每个节点进行全面验证。

用于高频通信的最简单的 IBC 形式涉及轻客户端处理所有报头,然后用户提供相对于已知块的简单行动证明。

原文

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.

重构建筑与应用建筑

我们花费了大量的时间来清理构建和应用块的过程。 在新模型下,将使用用于应用该块的相同 API 调用序列创建块。 这确保遵循相同的代码路径,并最小化生产者认为有效和验证者认为有效之间不一致的可能性。 这种清理使得应用程序块的过程不过是重放制片人所做的脚本而已。

原文

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.

轻量级生产者日程安排变更证明

在我们实施 IBC 概念验证时,我们意识到 Dawn 3.0 有一些边缘情况,在这些情况下简单的签名证明是不可能的。 我们希望尽可能简化轻量级稀疏报头验证,这需要对块的签名方式进行重构。

原文

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.

使用 EOSIO Dawn 4.0,现在可以验证生产者计划的更改,而无需验证任何块头。 当一个生产者签署一个区块时,他们也签署新的时间表,这样就不可能有两个竞争和有效签署的生产者时间表,而没有生产者的共同勾结或者⅓+ 与非常差的网络拆分勾结。

原文

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.

新制造商薪酬范式

关于生产者薪酬的社区讨论以及如何分配最高 5%的通货膨胀问题已经有很多。 block.one 将与 EOSIO 1.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:

有 21 个活动块生产商和任何数量的备用生产商。排名前 21 的每块奖励分成 0.25%,与每个生产者的块数成比例。所有块生产者候选人(包括前 21 名)也将按照他们收到的总票数除以 0.75%的每票奖励预算。他们最多可以每天一次要求获得每票收益的份额。为了要求他们的份额,他们必须有资格获得至少 100 个令牌/天。生产者候选人没有资格获得每票至少 100 令牌/天的基础,将不会收到任何费用。

该算法背后的思想是确保所有候选生产者有足够的薪酬为社区提供全面节点服务,并确保没有人能够接受不足以支付其成本的资金。假设前 200 名生产者候选人都获得相同数量的选票,这将支持 21 名活跃生产者和 179 名备用生产者。实际上,一些生产者会比其他生产者拥有更多的选票,这可能会减少付费待命生产者的数量。

每日付款最低限额是至关重要的,因为那些无意生产积木的富有人士不会试图通过投票自己获得生产者候选人的利益。

原文

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.

制片人投票衰退

自 Dawn 3.0 以来我们所做的大部分工作都涉及调整系统合同。 其中一项调整是实施投票衰减。 为了保持最大的投票影响力,每个选民必须每周重新投票。 投票影响力衰退,对于那些不更新其选票的人来说,其半衰期为 1 年。

我们建议宪法包含禁止使用自动投票机器人的语言,因为投票腐败的目的是确保选民重新评估他们的决定,而不是 “设定并忘记”。 虽然无法证明使用机器人,但可以证明人们不使用智能合约进行自动投票。

原文

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.

Exchange 集成支持

当我们接近 EOSIO 1.0 版本时,很多人都在要求我们提供有关交易所如何监控 EOSIO 区块链接收存款和/或确认其外部撤回被接受并不可逆转地确认的信息。 我们已经创建了一个关于使用 cleos(我们的命令行 eosio 界面)的教程来监视进入存款的链。 我们还创建了一个演示 python 脚本来监视存款和提款。 通过本教程和示例脚本交换应该具备开始与基于 EOSIO 的区块链集成所需的一切。

原文

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 Dawn 4.0 的可用性

EOSIO Dawn 4.0 代码的开发工作正在 Github 的'slim'分支上进行。 我们将在2018年5月11日发布它,并正式发布它。当时我们将移动苗条,掌握并标记发布。 希望继续保持领先优势的开发人员可以在纤细分支上遵循我们的进展。

原文

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.

## 结论 今年 6 月,EOSIO 软件正朝着强劲的 1.0 版本迈进。 使用 Dawn 4.0 后,代码已经被清除,我们比以往更加自信。

原文

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.

标准的 google 翻译..

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up