动态 EOSIO Dawn 3.0 正式发布

lome · April 06, 2018 · Last by dnbstarz replied at August 21, 2018 · 5701 hits

引言 今天 block.one 第一次宣布:‘预发布 EOSIO Dawn 3.0 完整版’,这个预发布版本是 2018 年 6 月将发布的 EOSIO 1.0 的一个重要里程碑。我们的全球开发者团队一直在全天候工作,使 EOSIO 成为构建区块链应用程序的最强大平台。自我们发布 EOSIO Dawn 2.0 以来已经有四个月了,我们有很多需要展示的东西。随着我们不断学习,设计不断变化,从而构建最先进的区块链架构。我们在 Dawn3.0 中完成的许多功能在最初的 EOSIO 白皮书中都没有设计,但是在构建高性能,灵活且易于开发的平台的过程中发现了这些功能。

可扩展功能

可扩展性意味着可以扩展以满足市场需求。 我们的团队在每一步都将未来扩展需求纳入设计中。 也就是说,Dawn 3.0 只实现了一小部分潜在的优化,这将允许 EOSIO 进行扩展。 我们设计了 EOSIO,以便将来的实现可以利用并行计算来加速吞吐量,而不会造成硬件更改。

跨链通信

区块链间通信是终极的可扩展性功能——圣杯,业界一直在寻找侧链,plasma 和分片等方法。 区块链间通信使一个区块链能够以可证实的安全方式验证另一个区块链上的事件的真实性。 目标是让区块链间的沟通像智能合约之间的内部链式沟通一样安全,我们认为我们已经实现了这一目标。

从我们的角度来看,跨区块链交流只不过是具备将轻客户作为智能合同的能力。 轻客户端可以验证区块链中的交易,而无需处理整个区块链。 这反过来意味着建立一个有效和安全的轻客户端验证的股权证明区块链。 因此,轻客户端验证必须纳入协议设计中,因为在事实之后几乎不可能实施。

稀疏区块头验证

传统的轻客户端需要处理每个区块头,然后验证区块头的证据。 现在 EOSIO 可以每秒生成两个区块,区块链至少需要 2 tps 才能处理每个区块头的数据。 这不适用于存在相对频率不高的跨链通讯上。 为了解决这个问题,我们创建了第一个带拜占庭容错稀疏区块头验证的区块链。 具体而言,为了试图欺骗轻客户端,它需要超过 2/3 的区块生产者(例如,21 个中的 15 个以上)腐败。 此外,轻客户端只需处理两种区块头数据:活跃区块生产者们发生的变化以及那些包含相关跨链通讯的信息 。 这大大减少了维护拜占庭容错轻客户端的开销,并大大提高了跨链通讯的效率。

上下文无关的 Action

“上下文无关” 的 Action 是实现高效的跨链通讯关键功能之一。 它们是特殊的 Action,因为它们可以包含在交易中,但不依赖于区块链状态,因此它们是 “无上下文” 的。 “上下文无关” Action 的一个例子是验证 merkle 证明或签名。 由于这些计算是 “上下文无关” 的,因此可以并行进行简单验证,并且可以剪除那些重复计算。

每个 “上下文无关” 的 Action 也可以参考一个特殊交易的可修剪数据部分。这意味着可以修剪大型 Merkle 证明,并且在区块链重复时跳过复杂的计算。

上下文无关的 Action 使我们能够并行化与跨链通讯相关的绝大部分算力承载。 它们还使我们能够平行处理并修剪昂贵的计算隐私技术,如机密交易,Bullet proofs 和 zkSNARK 等。

为了激励"上下文无关"的 Action,当计算作为 “上下文无关” 的一部分而不是作为传统交易的一部分执行时,区块生产者仅仅只向用户收取部分 CPU 使用费。

上下文无关的内联 Actions 作为事件

EOS Dawn 2.0 版本时开发人员一直在寻找一种有效的方式生成通过外部来源处理的事件。 在以太坊,这些事件用于通知关于合同内部运作的结构化信息。 通过增加上下文无关的 Action,我们也有可能实现上下文无关的内联 Action。 内联 Action 是由合同代码生成并作为当前交易的一部分执行的行为。 一个 “上下文无关” 的内联 Action 可以廉价并且并行地处理。 由于所有内联 Action 都包含在 Merkle 根目录中,因此可以将这些操作用作可证明的通知给外部服务和其他区块链。

交易压缩

有很多交易存在许多的可压缩数据。 其中最不可避免的例子是合约 WebAssembly 代码本身。 其他例子包括 ABI 规范和与账户/合约相关的李嘉图合约。 某些应用程序(如社交媒体)可能还希望可以压缩用户在区块链生成的内容。

通过利用交易压缩,区块链可以更有效地存储和传输大量交易。并且具有可压缩数据的交易记帐的用户数量少于不可压缩数据的交易数量。

解释器 & 即时编译

Dawn 2.0 最大的变化之一就是 WebAssembly 运行时环境的抽象。 Dawn 3.0 现在默认使用 Binaryen WebAssembly 解释器,而不是更快的 Just-in-Time(JIT)编译器。 这个决定会降低性能,但会增加稳定性和标准一致性,同时允许我们在需要时轻松交换更高性能的 JIT 环境。 解释器也解决了我们面对 Dawn 2.0 所面临的最大挑战之一:编制合约所造成的延误。 将来,我们可以使用解释器来实现新部署合约,较慢但更低延迟的执行,同时可以在后台编译和优化合同。这种双重实现意味着我们所有的单元测试都针对编译和解释代码进行了测试,因此我们可以在部署混合方法之前发现潜在的非确定性或非标准符合性行为。

资源测量速率限制

随着 Dawn3.0 的到来,我们现在有一个全新的资源速率限制系统。 也许最大的改变是引入了客观指令计数算法。 当我们着手构建 EOSIO 时,我们的目标是完全采用主观限速和强制执行。我们发现,主观执法的成本几乎与更加客观的方法相同。 我们现在使用混合解决方案,其中用户需要为客观使用而付费,但区块生产商也会在合约中放置主观挂钟时间限制。这些主观限制防止了目标计费方式的滥用。

我们采用这种方法的主要原因之一是允许单个交易执行比以前更多的计算。 从理论上讲,区块可以包含一个需要 100 ms 运行的事务,而在旧模型下,每个事务必须在 1 ms 以内运行。

限速的另一个变化是将限制与定义令牌的需求分开。 这使得 EOSIO 可以在没有使用 Token 的情况下在私人的,经许可的区块链中使用。公链可以采用系统合约,通过放样实现限制,社区可以动态地升级如何分配资源而这跟分配的实施方式无关。

500 ms 出块间隔 & BFT DPOS 混合共识

随着 Dawn 3.0 中我们已经从 3 秒的出块间隔缩短到 0.5 秒的间隔。 这大大缩短了确认之前的等待时间。 与 BFT DPOS 结合使用时,交易可在 1 秒内不可逆转地得到确认。等到不可逆转之前的的待时间对区块链间的沟通有重要影响,因为另一个区块链必须等待不可逆转性才能结合来自外部链的证据。两个基于 EOSIO 的区块链应该能够在 3 秒内执行往返通信。 以太坊的类似的模式需要 9 分钟,比特币需要 3 个多小时。

BFT-DPOS 尚未实施,因为它是非硬分叉优化。 我们将在发布 EOSIO 1.0 之前实施 BFT-DPOS 混合共识算法。

BIOS 结构

BIOS 结构体系是相对于 EOSIO Dawn 2.0 最大的结构体系变化之一。在 EOSIO Dawn 3.0 中,绝大多数区块链业务逻辑已经进入智能合约,可以由社区动态更新,而不需要硬分叉。 一个简单的 EOSIO 区块链现在是一个单一的生产者,没有任何代币,投票或委托证明。 核心区块链代码中唯一实现的是权限系统,它包括创建帐户,部署合约和强制执行资源配额的功能。 一切使得区块链的 DPOS 机制(包括 Token,投票,权益和资源分配)现在由基于 Web Assembly 的系统智能合约定义。

借助这种新架构,我们能够将开发重点放在区块链的静态非 WebAssembly 部分。 这些是稳定性最关键的部分 - 最难升级。 在发布 EOSIO Dawn 3.0 和 EOSIO 1.0 之间,我们将制定系统合约的最终细节,权益和投票。

安全特性

安全对于任何计算系统都至关重要,我们设计 EOSIO 是市场上最安全的区块链。 安全是一个多维问题,必须考虑到黑客攻击,硬件故障,硬件丢失和密码丢失的风险。 硬件钱包擅长防范黑客入侵,但如果失败,可能会将您锁定在帐户外。 此外,硬件钱包的纸张备份可能会丢失或被盗。

安全延迟交易

EOSIO Dawn 3.0 最重要的功能之一是增加了用户可配置的延迟,用于不同的操作。有了这种延迟,交易必须在区块链上广播几个小时或几天,然后才能应用。在这段延迟期间,用户可以采取措施重置权限更高的帐户,然后取消交易。与其它区块链相比,这是一个重大改进。您不知道自己已被黑客入侵,直到为时已晚。

丢失密码可恢复

每个帐户至少有两个权限级别:“owner” 和 “active”。owner 的许可级别应该是多重签名脚本的 N of M 机制,所有的 N 都不包含 owner 的密钥。任何时候活动密钥丢失或被盗,"owner"的权限级别都可以重置 active 权限。

如果你失去了 “owner” 密钥,或者您的多重签名合作伙伴不合作,则账户的 active 权限可以在 owner 权限闲置 30 天后请求重置 owner 权限。 owner 则有 7 天时间通过更新 active 权限来请求。

在此模式下,由一个或多个硬件钱包控制的帐户所有者权限将可以安全地防止黑客攻击和设备故障。如果该设备是带有硬件和指纹/Face ID 安全密钥的 Apple iPhone,则攻击者需要妥协您的多重签名合作伙伴,窃取您的手机并窃取指纹或 Face ID。 理想情况下,您的多重签名合作伙伴也正在使用生物识别安全硬件设备。

交易的提案系统

用户可以在他们自己的时间独立添加和删除他们的权限,而不必传统交易的有限期限范围内收集所有的签名,从而使得多重签名更加容易。通过提案系统,任何人都可以提出交易,交易涉及的各方可以简单的批准。任何时候在添加您的批准和获得必要的门槛期间,批准都可以被删除。

为了实现这个系统,我们增加了新的 API,允许合约评估一组账户权限是否足以授权交易。这使我们通过部署新的 WebAssembly 来升级多重签名,而不是需要使用硬分叉。

简化合约开发

EOSIO 的众多目标之一就是尽可能简化合同开发。如果开发人员知道如何编写一个 C++ 类的方法,那么他们应该能够编写一个复杂度低的智能合约。

我们很高兴已经简化我们的 “hello world” 合约到几行简单的代码。我们的工具链已经自动生成合约 ABI 并且将用户 action 分发到定义于你类目的方法。开发合约从未如此简单。

#include <eosiolib/eosio.hpp>
#include <eosiolib/print.hpp>
using namespace eosio;

struct hello : public contract {
    using contract::contract;

    void hi( name user ) {
        print( Hello, , user );
    }
};

EOSIO_ABI( hello, (hi) )

浮点支持

简化智能合约开发的一部分是使开发人员所需的数学算法的实现变得更加简单。区块链开发最困难的方面之一就是缺乏浮点运算和相关能力、根和三角函数。许多算法,(例如 Bancor)在浮点方面实现起来要容易的多,而不是迫使所有计算进入容易出错和内存密集的固定点。

我们通过集成由 WebAssembly 合约公开使用的软件 sorftware-floating 库来解决硬件服浮点的非确定性性质。有了 sorftware-floating 库,我们就可以在复杂情况下获得确定性和易于开发的好处,其代价不会高于固定点。 在很多情况下,固定点比确定性浮点表示要么更容易出错,要么内存更密集。

C++ 标准模板库支持

对于 EOSIO Dawn 3.0,我们付出了巨大的努力来增加对大多数 C ++ 标准模板库的支持。这意味着开发人员可以使用他们熟悉的工具,库和算法,同时消除由于这些算法的非标准实现而导致的潜在错误。

计划事务

对于计划事务开发者,只要合约具有足够的带宽,就能够永久运行合约。其他平台在链下的解决方案才能在适当时间唤醒合约。通过计划事务,我们可以提高效率和易用性,不用开发人员托管自己的服务器以保持合同运行。

自动示波器检测

在 EOSIO Dawn 2.0 下,每个事务都需要声明它将访问的数据范围。 这对开发人员来说很冗长并且容易出错。 在 Dawn 3.0 下,BP 负责确定访问哪些数据范围并解除冲突。 这使得所有事务更小,并将调度开销移动到 BP,而不是将其推回到用户,开发人员或完整节点上。

多重索引数据库 API

EOSIO Dawn 3.0 引入了一个反映 boost :: multi_index_container 的新数据库 API。 使用此 API,可以支持按多个键排序的数据库表,查找项目,使用下限/上限,以及在数据库上前后反复迭代也变得简单。这个新的 API 使用迭代器接口,可显着提高扫描表的性能。

现在也可以在 64 位,128 位,256 位和 512 位整数以及 64 位浮点(双精度)上使用索引。 在发布 EOSIO 1.0 之前,会添加对字符串索引的支持。 这是灵活性和开发简便性的显着改进,因为现在可以在同一个表上拥有几乎无限数量的索引字段。

性能

真正的性能是我们团队一直密切关注的事情,我们现在对结果非常满意。 我们通过几种不同的配置对我们的软件进行了基准测试,以了解未来优化时性能的上限和下限。 所有这些测试都假设令牌传输在计算复杂度方面与比特币或 Ethereum ERC20 令牌传输相当。

最糟糕的情况---1000 tps

这是我们没有任何优化的基准性能。 我们能够使用运行具有单线程签名验证的解释器的多节点网络来支持超过 1000 TPS。

正常平均情况--3000 TPS

打开 JIT 编译器后,我们可以使用运行具有单线程签名验证的解释器的多节点网络来维持 3000 TPS。

最好的情况----6000 TPS

一旦我们实现了并行签名验证,我们可以假设壁挂时钟每次签名时间将接近 0,因为并行度和签名数量增加。 我们可以通过禁用签名验证来模拟此环境。 在这个模型下,我们可以用 JIT 编译器在多节点网络上达到 6000 TPS。

理想情况---8000 TPS

如果我们从等式中删除网络代码,并只关注 CPU 在关闭签名验证和使用 JIT 时能够执行的操作,那么我们可以达到单线程的每秒 8,000TPS。 要在单一链上走得更高。需要实现 WebAssembly 的并行执行和更高级的调度程序。 在这种情况下,使用解释器而不是 JIT,我们可以达到 2700 TPS。 这表明启用 JIT 的相对简单的改变将使我们的转移性能提高约 3 倍。 这些测量是在 MacBook 2.8Ghz i7 上进行的。

无限制每秒事务数

“每秒交易次数” 的定义就像是橙子对比苹果。跨链通信时,我们可以根据需要在区块链之间分配工作量。Token 可以可靠和安全地在不同的链之间传输。由于相同(或不同)BP 并行运行 1000 条链,我们可以看到每秒数百万级的交易。这代表了其他区块链提出的理论扩展方案的实际实现。

我们强烈鼓励基于 EOSIO 的公共网络的 BP 根据需要运行尽可能多的链以满足用户需求。所有链都可以使用相同的标记作为权益和资源分配的基础。这将使得单个 Token 创造最大可能的网络效应,并利用高市场资本化代币形成的经济激励的信任和安全性。

像交易所,货币和社交媒体这样的应用程序可以在许多并行链上平衡其负载。

未来

EOSIO Dawn 3.0 重点在于核心平台的稳定性。

在接下来的一个月中,我们将准备执行所有权益,投票和治理机制的最终系统合约。 我们也将最终确定我们的 Token 标准。

一旦系统合约成熟到我们满意,我们将启动一个新的公共测试网络。 在此之前,我们大大简化了搭建自己的测试网络和开发自己的应用程序的过程。 在接下来的几周内,我们正在关闭当前的公共测试网络,同时我们准备新的测试网络以最大限度地降低开发人员的门槛。

总结

EOSIO Dawn 3.0 是一个开发者版本,希望通过稳定的 API 来实现 “功能完备”。 我们认为该平台现在已经足够稳定,可供复杂的应用程序开发人员开始构建应用程序。 EOSIO 已经变得比我们一年前想象的更加强大和容易开发。

我们的团队正在成长,正在以创纪录的速度发展。 我们的仓库在过去的一个月里一直是所有 github 中十大最活跃的 C ++ 仓库之一。 一切都在 6 月份 EOSIO 1.0 高质量版本中公开发布!

原文地址: https://medium.com/eosio/eosio-dawn-3-0-now-available-49a3b99242d7

lome EOSIO Dawn 3.0 现已推出 中提及了此贴 06 Apr 05:54
strahe EOS 3.0 增加了那些功能呢? 中提及了此贴 06 Apr 06:39

+1

翻译的挺好,赞一个!

caokun_8341 回复

Thanks

感觉翻译的有点不太通顺,建议有点地方可以按照中文的意思去翻译哈

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