EOS大神BM最新发布 EOSIO Dawn 3.0(中文翻译版)

EOSIO Dawn3.0 发布!

阅读字数: 5923
阅读所需时间:10分钟左右

英文发布-原文地址:https://medium.com/eosio/eosio-dawn-3-0-now-available-49a3b99242d7(需要梯子,翻了墙才能看)

Block.one 宣布第一个功能完善的EOS.IO,Dawn 3.0正式发布。

(Github 查看地址为:https://github.com/EOSIO/eos/releases/tag/dawn-v3.0.0

EOSIO Github 截图

这个预先版是今年2018年6月 EOSIO 1.0 正式上线的重要里程碑。我们遍布全球的开发者正在争分夺秒地工作,已确保EOSIO能够成为Dapp应用所依赖的最强区块链平台。距离上一次发布EOS Dawn 2.0已经过去4个月了,针对这4个月的工作成果,我们将有许许多多的内容要告诉大家。

艺术般的区块链架构建造过程,其实就是一个我们不断学习不断改变,优化设计的过程。我们发布的EOSIO,Dawn 3.0预先版中,绝大多数特性事实上并没有出现在我们最初的 EOSIO 白皮书中,但是,这些特性依然是创建高性能,可拓展以及易开发的区块链平台过程中的一部分。

可拓展性

可拓展性意味着规模化满足市场需求的能力。我们团队每一步都已经将未来规模化需求考虑到设计里了。也就是说,Dawn 3.0 仅仅实现了未来EOSIO自身规模化时,潜在优化内容的一小部分。我们已经将EOSIO设计成为可利用并行计算的方式来加速处理吞吐量,并且没有硬分叉的变化。

跨链通讯

跨链通讯是一个终极的可拓展特性-类似“圣杯”的感觉-整个行业都一直在寻找这样的协议解决方案,如侧链,Plasma方案和分片方案等等。跨链通讯支持链与链之间以一种可证明的安全方式进行区块事件的真实性验证。我们最终目标就是跨链通讯会和链内基于智能合约的通讯一样安全,并且我们已经达成了这个目标。

以我们的角度来看,跨链通讯无非是作为一个智能合约,并且拥有了执行轻客户端的能力。轻客户端是可以不同步整个区块链而进行区块交易验证的。这样反过来就是使用高效的,安全的轻客户端验证方式来构建了一种权益证明机制的区块链。因此轻客户端必须考虑到协议层的设计中,尽管依据之前的事实,很难去落实。

极简区块头验证

传统的轻客户端是期望通过获取每个区块头以及验证和这个区块头相关的区块头来验证的。如今,EOSIO 可以实现每秒生成2个区块,并且一个区块链获取每个区块头需要至少每秒2笔交易的速度。但是,这个不适用于相对较少的跨链通讯场景。为了解决这个问题,我们创造了创世块容错机制的极简区块头验证。具体来说,就是系统需要超过三分之二的区块生产者都变坏了,然后他们统一意见去尝试欺骗一个轻客户端,才有可能造成系统交易被篡改。(举例,当前EOSIO 是 21个节点,然后超过15个就可能发生以上描述情况)。更近一步地说,轻客户端只需要活跃区块生产者变化带来的区块头就可以,并且也包含了相关的跨链信息。这样就大大地减少了维护一个拜占庭容错轻客户端的开支,以及大大增加了跨链通讯的效率。

语境自由 Action

语境自由Action是保障跨链通讯高效运行的关键特性之一。他们是一种特殊的Action,主要是因为他们可以被包含到一个交易里,但不依赖区块链的状态,因此,他们是“自由语境”的。举个例子,就是默克尔树根或签名的验证。因为这些计算是自由语境的,他们可以被平行地验证,并且这个计算是可以通过回滚修改的。

每个自由语境Action也都与交易中特殊的可修改数据区域相关联。这就意味着大量默克尔树根可以被修改,并且他们昂贵的计算在区块回滚中跳过了。

语境自由Action使得我们可以并行与跨链通讯相关的大多数开支。也使得我们能够并行和修改一些计算上比较昂贵隐私技术的经常性费用,如保密交易,“防弹技术”,零知识证明等

为了激发语境自由Action的使用,区块生产者只会向用户收取一小部分CPU使用的费用,收取费用的情况: 当且仅当一次计算是作为一次语境自由Action执行了,而不是一次传统的交易过程。

自由语境一致性Action事件(Events)

EOS柚子-黎明2.0(EOSIO Dawn 2.0)开发团队一直在寻找的一种方式,就是借助外部资源来推进Events事件的生成。在以太坊中这些Events事件是用来表明一个合约内部操作的结构化信息。由于自由语境actions的加入,我们也有潜力完成自由语境一致性actions. 一个一致性action是由合约代码产生,并作为当前交易的一部分被执行。一个一致性action 可以被廉价,以及平行的方式进行。因为所有的actions 都被包含默克尔树根,所以是有可能来使用这些actions作为验证的通知来传递给其他区块链和外界服务的。

交易压缩

有许多交易是有很多可压缩的数据的。其中一个不可避免的例子是,合约的WebAssembly码。其他的,例如ABI标准规格以及和一个账户或合约相关联的Ricardian 合约。有些应用,如社交媒体,也同样期望在区块链上压缩用户产生的内容数据。

利用交易压缩,区块链可以更高效地储存以及发送大量交易,最后还可以让压缩数据的用户为发送交易支付更少的费用。

InterpreterJIT编译

来自Dawn 2.0的最大的变化是WebAssembly运行环境的抽象化。Dawn 3.0现在默认使用Binaryen WebAssemblyhttps://github.com/WebAssembly/binaryen)而不是更快的JIT编译器(https://github.co)。这个决定事实上减弱了性能但却增加了稳定性和标准一致性,当然还是支持在必要的时候切换到性能更高的JIT编译器。Interpreter也解决了我们在Dawn2.0 时面对的一个重大挑战:由于编译合约造成的延迟。未来,我们在编译和最优化合约的场景下,用起Interpreter会变慢,但可以缩短等待时间,和立刻执行部署合约。这样的双重执行下意味着,我们所有的单元测试都可以运用到编译和解码过程中。所以我们发现了,在我们能部署混合方法前,是有潜在的非确定性或者非标准化规则行为存在的。

资源测量率限制

这个发布的Dawn 3.0 已经拥有一个完整的新资源率限制系统。最大的变化可能是客观的指令计数算法。当我们着手去打造EOSIO时,我们有一个目标就是使用完全主观的资源速度限制和压力。后来,我们发现,主观压力的限制几乎和一个更客观的方式是相同的效果。当用户要求为客观的使用而付费时,我们现在使用一个混合的解决方式来处理。但区块生产者也会在合约中布置主观的“挂钟”时间限制。

我们采纳这种方式的原因之一是允许个人交易,相比以前,可以执行更多的计算。现在是,理论上包含单个交易的一个区块,需要100ms去运行,然而在旧模式下,每个交易必须在1ms以下去运行。

速度限制的另一个改变是,定义一种代币的需求从原先的限制中拿走。这就允许EOSIO可以被应用于私有,联盟链(不需要代币的场景下)。公有链则可以接受一个系统合约,这个系统合约可通过股权的形式来执行限制。并且社区可以动态地升级,自己考虑如何根据强加的分配任务来单独地分配资源。

每0.5秒出一次块 & BFT DPOS 共识机制

在Dawn 3.0 中,我们把出块时间从3s改到了0.5s。这个大大减少了区块确认前的延迟。通过混合的BFT DPOS 共识机制,交易可以不可逆转地在1s被确认。不可逆转前的延迟对于跨链通讯有比较严重的负作用,原因是另一个区块链必须在与另一条陌生的链结合前 等待这个不可逆转的结果。两个基于EOSIO的区块链可以在3s内完成一次往返的通讯。这样一个类似的通过过程在以太坊上要花费9分钟,在比特币上要话费3小时。

BFT DPOS 共识机制还没有被实践,因为它是一个非硬分叉的优化。我们会在发布EOSIO 1.0 之前将 BFT DPOS 共识嵌入。

BIOS 架构

BIOS架构是EOSIO Dawn 2.0 到 Dawn 3.0 最大的变化之一。在 EOSIO Dawn3.0 下,大多数的区块链商业逻辑可以转移到智能合约中,最终社区可以在没有硬分叉的前提下,进行动态地升级。一个“裸露骨头(最初形态的)” EOSIO 区块链是一个单生产者,并且没有任何代币,投票以及DPOS共识机制的区块链。唯一嵌入到核心区块链代码层的是许可系统,这个许可系统具备了创建账户,部署合约和强制执行资源配置的能力。关于区块链DPOS,以及 代币,投票,股权和资源配置的 所有一切都是基于系统合约,由Web Assembly 来定义的。

借助新的架构,我们已经可以聚焦在静态的,非Web Assembly的区块链开发了。这些部分对于区块链的稳定性十分重要,也是最难去升级的。在Dawn 3.0 至 EOSIO 1.0之间,我们会制定出系统合约,股权,投票的最终细节。

安全特性

对于任何计算机系统而言,安全始终是至关重要的。我们已将EOSIO 设计成为市场上最安全的区块链。安全是个多维的,综合的考虑,包括黑客攻击,硬件损坏,硬件丢失以及忘记密码。硬件钱包擅长保护不被黑客攻击,但如果他们自己坏了,你的资产将永久被锁住。还有,硬件钱包的纸质备份可能被偷或丢失。

安全延迟交易

EOSIO Dawn 3.0 最重要的功能之一就是添加了 用户自定义的延迟功能。有了这个延迟,一个交易可以被设置成数小时,或数天才能执行。在这个延迟阶段,用户可以采取措施,利用高级权限来重置他们的账户,然后取消这个交易。这是一个区别于其他区块链的重要提升,这样的也就让你在不知不觉被黑客攻击的情况下,免得什么挽救措施都做不了。

丢失密码的恢复

任何账户都有至少2个权限等级:“所有者”和“激活”。所有者授权级别应该是一个N/M 的多方签名机制,当没有达到N的时候,是没有所有者钥匙的。当激活钥匙被偷或丢失时,所有者权限级别可以在任何时候 重置 激活权限。

如果你丢失了所有者钥匙或者你的多方签名伙伴不合作了,这个账户的激活权限可以在所有者权限不活跃30天后,请求一次所有者权限的重置。然后,所有者有7天时间可以通过升级活跃权限来挑战这个请求。

在这个模型下,一个账户所有者的权限被一个或多个硬件钱包控制,会使它对于黑客攻击和设备损坏是安全可靠的。如果此时设备是台iphone, 并且有硬件,指纹,人脸识别来确保私钥安全,那这个黑客需要说通你的多方签名伙伴,盗取你的手机,偷走你的指纹或人脸。理想状况下,你的多方签名伙伴也正在使用生物识别地方式来确保硬件设备安全。

交易提案系统

在用户可以自由地添加或删除他们的多方签名权限的情况下,多方签名就变得容易多了,而不是像以前传统交易那样,要在有限的到期时间窗口收集到所有签名。利用提案系统,任何人都可以提出一个交易,然后和交易相关的成员可以简单地同意通过。任何时候,在添加你的同意和获取阈值之间,你的同意是可以被删除的。

为了执行这个系统, 我们添加了新的api,这些api是允许合同来评估一套账户的权限是否足够充分来授权一个交易。这就可以让我们通过部署新的WebAssembly这样的方式来升级多方签名进程,而不是硬分叉。

简化的合约开发

EOSIO的目标之一就是将合约开发过程尽量简化和轻松。如果一个开发者知道怎么用C++,那他们也能够参考略微有点复杂样板来写智能合约。

我们很高兴能够将“hello world”的智能合约实现代码演示出来。我们的工具链已经可以自动化生成合约ABI,并且根据你的class将用户的actions发送到methods。正在开发中的合约从未如此简单。


智能合约

浮点支持

简化智能合约开发部分目的是,使得开发者需要的数学算法更容易实现。区块链开发最难之处在于缺少服点算法和相关的power,root 以及 三角函数。很多算法, 如Bancor, 就浮点而言,是更容易去实践的,而不是投入所有的计算到内存密集固定点和容易出错的地方。

我们通过在WebAssembly 合约中集成一个软件浮点,解决了硬件浮点的非确定性。利用软件浮点支持,我们可以获得确定性的好处,并且相比于处理复杂情况下的固定点,开发成本下降了好多。在很多情况下,相比于确定性的浮点支持,固定点不是容易出错,就是以更加内存固定点形式出现。

C++ 标准模版库支持

对于EOSIO Dawn 3.0, 我们花了很大精力来支持C++标准模版库。这就意味着,开发者可以使用他们熟悉的工具,库和算法来开发。同时,也避免了由于非标准化执行算法所带来的潜在bug。

计划交易

通过计划交易开发者模式,现在可以提供合约永久运行-主要是提供了合同足够多的宽带。其他平台要求链下的解决方案在一个恰当的时间触发合同。通过计划交易,我们可以让开发者无需自己的服务器即可充分,自由地使用合同,并保持合约的运行。

自动化范围检测

在EOSIO Dawn 2.0这个版本下,每笔交易都必须说明它用到的数据范围。这对于开发者而言,是个容易出错的,冗长的地方。而在EOSIO Dawn 3.0 下,区块生产者是需要对使用数据范围负责的,并且需要排解他们。这样就使得交易更小,并且把计划性的开支转移到了区块生产者,而不是用户,开发者或所有节点。

多线程数据库API

EOSIO Dawn 3.0 引入了一个新的数据库api来监控增长::multi_index_container。使用这个api就很容易支持数据库表了,一般这个复杂的数据库表包含了多重钥匙,查找项目,使用性能的更低,或更高上限,以及在数据库上来回进程。这个新的api使用了迭代器接口,可以通过扫描表的方式,大幅提升性能。

性能表现

我们团队密切关注着实际测试中的性能表现,事实上,我们此刻对实际性能表现很满意。我们将EOSIO Dawn 3.0 这个版本放到不同配置中,来检测性能的最低和上限表现。所有的测试都是基于苹果设备和苹果设备之间的代币交易转账,并可与 比特币或 以太坊ERC20代币的复杂性计算相对比。

最差情况-1000 TPS(TPS:每秒交易笔数)

这是我们没有任何优化的最低表现。我们可以使用多节点网络来解释单线程签名验证,并维持超过1000 TPS 的性能。

平均情况-3000 TPS(TPS:每秒交易笔数)

只要我们打开了JIT编译器,我们可以使用多节点网络来解释单线程签名验证,并维持超过3000 TPS 的性能。

最好情况-6000 TPS(TPS:每秒交易笔数)

一旦我们实践了并行签名验证,我们可以假设随着并行和签名数的增加,每个签名的“挂钟时间”将为0。我们可以通过禁用签名验证的方式,来模拟这个环境。在这样的模型下,我们可以使用JIT编译器在多节点网络上,达到6000 TPS 的情况

理论情况-8000 TPS(TPS:每秒交易笔数)

如果我们从equation中去除网络节点,只关注于关闭签名验证的CPU性能,并且使用JIT编译器,我么可以达到每秒单线程的8000 TPS。如果在单链上,还想达到更高的TPS,则需要WebAssembly 的多线程执行,即一个更高级的Scheduler调度。在这样的场景下,使用Interpreter,而不是JIT,我们可以看到2700 TPS的效。这就暗示着,仅仅是使用JIT编译器这样的简单变化,就可以造成交易性能3倍的变化。这些测试的执行环境是 MacBook 2.8Ghz i7。

每秒无限交易量

“每秒交易笔数”经常被定义为 苹果和橘子的对比。基于链内通讯,我们可以将工作量拆分许多区块链,只要我们愿意。代币可以安全地,可信任地在不同链之间流转。在同一或不同区块生产者产生的1000条链并行情况下,我们可以看到,百万级别的TPS是可以实现的。这就代表着之前理论范围的目标已在真实环境中实现。

我们强烈建议EOSIO的区块生产者可以运行越来越多的链,最终以达到满足用户需求的目的。所有的链都是可以使用同一个代币作为股权和资源配置的基础。这就会基于单个代币产生网络最大化效应,并且赋予了高级市场中的资本化代币 信任和安全的经济刺激。

类似于交易所,货币以及社交类的应用可以在多个平行的链中平衡他们的发展路径。

前方的路

EOSIO Dawn 3.0是专注于核心平台的稳定性。下个月,我们将会对最终系统合约的股权,投票以及治理机制做实践准备。我们也会最终确定我们的代币标准。

一旦系统合约达到我们满意的程度,我们会发布一个新的公有测试网络。到那时,我们已经大大简化了开发者启动他们自己测试网络,以及开发自己应用的流程。接下来几周, 我们将会关闭当前公有测试网络,主要原因是我们将开始准备新的测试网络来尽量减少开发者疑惑。

总结

EOSIO Dawn 3.0 是一个 拥有稳定APIs 服务,“功能完善”的 开发者版本。我们相信这个平台目前已经足够稳定,已经可以满足一些真正的Dapp应用开发者开始在EOS上构建他们自己的应用了。相比于一年前,EOSIO已经成为了一个更加强大和更易上手的开发平台!

我们的团队在成长开发工作也在以创纪录地速度进行。在过去的一个月中,我们EOSIO的repository在所有Github活跃的C++ repository 中是居于前10。一切的工作都在为今年6月份 EOSIO 1.0 高质量地公开发布而进行着!

小丁翻译
2018.4.7

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,456评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,370评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,337评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,583评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,596评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,572评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,936评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,595评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,850评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,601评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,685评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,371评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,951评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,934评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,167评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,636评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,411评论 2 342

推荐阅读更多精彩内容