[中文首发]EOS Dawn 3.0 版本发布

Dawn 3.0

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

我怀着无比激动的心情,谨代表Block.one公司在此宣布,第一个全功能预发布版本的EOSIO,Dawn 3.0版已经发布。本次的预发布版本是预计2018年6月正式发布的EOSIO 1.0正式版前的一个重要里程碑。我们遍布全球的开发团队夜以继日的努力工作来让EOSIO成为最强大的区块链应用平台。EOSIO Dawn 2.0版本发布已经过去4个月了,我们有太多新进展想要和大家分享。

构建一个世界顶级的区块链架构是一个不断演进发展的过程,随着我们不断学习到新的知识,我们也在修正调整我们的设计。我们在Dawn 3.0版本里实现了许多甚至在原来白皮书未曾预想到的新功能,这些新功能是在设计建设高性能、高灵活、简单易用的开发平台的过程中被逐步发现的。

扩展性功能

可扩展性意味着拥有灵活扩展规模的能力来快速适应市场需求。我们在设计的每个环节都把未来可扩展的需求融入到设计当中。也就是说,Dawn 3.0目前只实现了部分的潜在优化项来支持EOSIO的规模扩展。另外,EOSIO设计充分考虑到,未来在无须硬分叉的前提下,也可以升级系统来利用并行计算技术加大系统吞吐率。

跨链通信

跨链通信是属于终极目标的可扩展性功能——圣杯,业界已经在寻觅各类解决方案,譬如侧链,plasma和分片技术。跨连通信使得一个区块链能够以一种可信安全的机制来验证在另一个区块链上发生的事件。跨连通信的目标是使得链间的通信能够变得和链内智能合约之间通信一样安全,我们认为我们已经实现了这个目标。

在我们看来,实现跨连通信只需要拥有把一个轻量级客户端(译者注:下简称轻客户端)作为智能合约的能力。一个轻客户端能够验证验证区块链上的交易且无需处理全部链上交易。这意味着我们需要使用高效安全的轻客户端验证机制来构筑一个PoS区块链。轻客户端验证机制因此必须作为协议设计的必要因素,而不可能在现成方案后追加进去。

稀疏头部验证

传统轻客户端一般期望需要处理每个区块的头部然后验证对应的证据。由于EOSIO每秒产出两个区块,其他的区块链需要至少具备每秒2笔交易的处理能力来处理EOSIO产出的区块头。这对于低频跨连通信的场景来说是不可扩展的。为了解决这个问题,我们创造了首个使用拜占庭容错(BFT)稀疏头部验证机制的区块链。具体来说,只有多于2/3(譬如21里大于15个)的区块生产者联合腐败才能欺骗轻客户端。进一步地,轻客户端只需要处理区块生产者集合发生变更或者包含跨连消息的区块头部。这样就能极大减小维护BFT轻客户端的开销,从而极大低提高跨连通信的效率。

上下文无关动作

上下文无关动作是实现跨连通信的关键技术之一,这类特殊的动作包含了一个不依赖于区块链状态的交易,因此被称为上下文无关。一个例子的例子是验证merkle proof或者签名。因为这些计算是上下文无关的,所以它们能够很容易的并行验证,并且计算结果能够从replay中被裁剪。

每个上下文无关动作还能引用一个交易中的特殊的可裁剪数据区域,这意味着大的merkle proof能够被删除,而那些昂贵的计算任务能够在区块链replay过程中被跳过。

上下文无关动作使得跨连通信相关的大部分计算可以被并行化,同样地可以并行化和裁剪掉那些计算昂贵的隐私相关技术,譬如机密交易,bullet proof和zkSNARKs。

为了激励上下文无关动作的采用,区块生产者只向用户收取上下文无关动作所花费的部分CPU开销,而不是作为普通的交易。

上下文无关内联动作事件

EOSIO Dawn 2.0的开发者们想要的一种高效的事件生成机制,使得事件能够在源头以外被处理。在以太坊平台事件被用来报告关于智能合约内部操作的结构化信息。在引入上下文无关动作后,我们也可以执行上下文无关内联动作。一个内联动作是指由合约代码产生并且被作为当前交易一部分而被执行。上下文无关内联动作能够被低成本的并行处理。由于所有内联动作都会被包含在merkle root里,因此很有可能可以使用这些动作作为可证明的通告来通知外部服务和其他区块链。

交易压缩

许多交易上有大量可压缩数据,一个最显然的例子是智能合约的WebAssembly代码本身,其他例子包括ABI规范、关联账户和合约的Ricardian合约。有一些应用譬如社交媒体也可能希望能够压缩由用户生成的连上内容。

使用交易压缩技术后,一方面区块链能够更高效地存储和传输更大数量的交易,另一方面也可以降低用户费用。

解析器和Just-In-Time编译

相比Dawn 2.0版的一个最大的变化是,我们对WebAssembly运行环境进行了抽象。Dawn 3.0现在默认使用Binaryen WebAssembly解析器,而非更快的Just-In-Time编译器。这个决定一定程度降低了性能,但增大了稳定性和标准一致性,让我们能够按需更方便的升级替换使用更高性能的JIT环境。同时解析器也解决了我们在Dawn 2.0遇到的一个最大的挑战,那就是编译合约引发的延迟。在未来我们能够使用解析器来获得一个慢一点但更低延迟的合约部署执行体验,与此同时智能合约在后台被编译和优化。这样的双重实现意味着我们所有的单元测试都需要经过编译测试和解释测试的检验,这样我们能够在部署混合机制前发现潜在的非确定或非标准一致的行为。

资源计费和限速

在Dawn 3.0版本我们有了全新的资源限速系统,也许其中最大的变化是引入了一种客观的指令计数算法。我们建立EOSIO之初有一个目标,就是采用完全主观的限速和约束机制。后来我们发现主观约束的付出代价和更客观的机制的代价几乎一样。所以我们现在采用一种混合的解决方案,用户账单按客观使用量计费,但是区块生产者可以在合约上主观设定运行时间限制。这些主观限制可以有效预防对客观计费机制的滥用。

我们采用这种方法的一个主要原因是允许单独的交易可以比以前进行更多计算,现在理论上一个区块可以包含一个跑100ms的交易,而在旧模型下每个交易被限制在只能跑1ms以下。

限速机制还有一处变化是不再必须定义一个token,这样允许EOSIO能够被私人使用,譬如准入机制的区块链中即使没有使用任何token也能实现限速。而公有链可以采用系统合约,通过权益份额来实现限速,社区可以动态升级资源分配方式。

500ms 区块间隔和BPF DPOS

在Dawn 3.0我们从每3秒区块间隔改为0.5秒间隔,这极大地缩短了确认延迟。结合BFT DPOS共识机制,交易在不到1秒的时间内即可达到不可逆确认状态。不可逆确认延迟对于跨连通信有着重要意义,因为区块链在采用确认外链的证明前必须先等待外链交易不可逆。两个基于EOSIO的区块链应该能够在3秒以内完成一次往返通信。而类似的通信模式在以太坊网络上需要9分钟,在比特币网络上需要3+小时。

BFT DPOS目前还没实现因为它属于非硬分叉优化,我们计划在正式发布EOSIO 1.0以前实现这个功能。

BIOS架构

BIOS架构是区别于Dawn 2.0版本架构上最大的改变,在新版本下大部分区块链业务逻辑被移动到一个智能合约内部,这样社区无须硬分叉即可动态升级。一个裸的EOSIO区块链现在只有区块生产者,不带任何token,投票或者委托权益证明。在核心区块链代码上只实现了权限系统,包括创建账户、部署合约、资源份额分配。所有DPOS的特性包括代币、投票、权益以及资源分配,现在都是由基于WebAssembly的系统合约来定义。

在这种新架构下,我们能够专注开发区块链上非WebAssembly的静态部分。这些部分对于稳定性至关重要——也是最难以升级的部分。在本次Dawn 3.0和正式EOSIO 1.0发布之间,我们会完成系统合约、权益、投票等方面的最终细节。

安全特性

对于任何计算系统而言,安全是至关重要的,我们以市场上最安全的区块链作为目标来设计EOSIO。安全是一个多维度的问题,需要同时考虑被黑客入侵的风险、硬件失效、硬件丢失、密码丢失等等。硬件钱包可以很好的保护用户免受黑客攻击,但同时也能在损坏失效的时候将你从账户中拒之门外。进一步地,纸钱包备份和硬件钱包有丢失和被盗的风险。

安全延迟交易

EOSIO Dawn 3.0版本的一个最显著特征是加入了一种用户可配置的动作延迟机制。通过动作延迟,一个交易必须先提前广播到整个区块链,延迟若干小时或者若干天后再被执行。在延迟的过程中用户可以采取措施去提升交易所需的账户权限阈值要求从而取消掉交易。在其他区块链上,往往在已经到了无法挽回的情况下用户才知晓自己被黑客攻击,相比之下,EOS的延迟机制能够有效保护用户,这是一个非常大的进步。

密码恢复

每个账户拥有至少两级权限:“owner”权限和"active"权限。owner权限应该是N-M多签名,如果没有所有者的秘钥,这里就没有N。 当active的私钥丢失或者被盗时,owner权限可以随时重置active权限。

如果你丢失了owner私钥或者你的多签名伙伴不配合,那么账户active权限可以在owner权限沉寂30天候申请重置owner权限。之前的owner权限有7天期限可以更新active权限来取消掉这个重置申请。

在这个模型下,有一个或多个硬件钱包控制的账户的owner权限能够有效抵御黑客攻击和设备失效的风险。如果设备是一个苹果iPhone,使用了硬件和指纹/Face ID来保护私钥,那么攻击者需要同时做到搞定你的多签名伙伴,物理上盗取你的手机和你的指纹或脸部。理想情况下,你的多签名伙伴也同样使用生物统计学安全的硬件设备。

交易提案系统

如果用户能够独立增加和移除权限,不用在交易限定期限内等待收集所有签名的话,多签名会更简单易用。采用提案系统,任何人可以发起一个交易提案,交易权限关联的其他伙伴可以简单地表决同意与否。在同意提案后,只要提案未达到必要阈值,参与方可以随时撤销同意。

为了实现这个提案系统,我们增加了一些新的API来允许智能合约评估账户权限是否足够充分来对交易授权。这使得我们能够通过部署新的WebAssembly合约来升级多签名机制,从而避免执行硬分叉。

简化合约开发

EOSIO的众多目标之一是让智能合约开发尽可能的简单无痛。一个开发者只要会写C++类和方法,他就有能力参照着很简单的模板来编写智能合约。

我们很高兴能够做到让我们的简版"hell world"合约只需几行简单代码,我们的工具链能够把生成合约ABI接口、映射用户动作到类方法这些琐碎过程全自动化起来。开发智能合约从未如此简单。

Hello Wold智能合约样例

#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智能合约透明无感知。通过软件浮点数,我们能够在复杂情况下以不大于定点运算的代价同时获得确定性和开发易用性的好处。在很多情况下,定点运算比确定性浮点表达运算要么更容易出错,要么更耗费内存。

C++ 标准模块库支持

在EOSIO Dawn 3.0版本,我们花了很大功夫来增加支持C++标准模板库大部分功能,这意味着开发者能够使用透明熟悉的工具、库和算法,同时免于引入非标准算法实现导致的bug。

预定交易

有了预定交易功能,开发者现在可以编写自动永续运行的智能合约,只要合同有充足的抵押带宽。相比之下,其他区块链平台需要一定的链外解决方案,以在适当的时候唤醒合同。有了预定交易功能,我们就获得了效率和易用性,而无需开发者自行安装服务器以保持合同的正常运行。

自动范围监测

在EOSIO Dawn 2.0,每一笔交易都需要定义它需要访问的数据范围,这对开发者来说是容易出错和冗余的。在EOSIO Dawn 3.0, 区块的生产者负责决定访问的数据范围,并解决冲突。
这使得所有交易变的更小,将调度开销转移到块生产者,而不是将其推回到用户、开发者或全节点。

多级索引的数据库编程接口

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。

平均性能——3000TPS

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

最好的情况——6000TPS

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

理论值上限——8000TPS

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

无上限每秒交易

通常每个人对“每秒交易次数”的定义有不同的理解。 通过区块链交流,我们可以根据需要在区块链之间分配工作量。 令牌可以可靠和安全地在不同的链之间传输。 由于相同(或不同)块生产者并行运行1000条链,我们可以看到每秒数百万的交易。 这代表了其他区块链提出的理论扩展方案的实际实现。

我们强烈鼓励基于EOSIO的区块生产者 根据公共网络去运行,尽可能多的满足用户需求。 所有的链都可以使用相同的标记作为获取和资源分配的基础。 这将围绕单个令牌创建最大可能的网络效应,并利用高度市场化的代币形成经济激励的信任和安全性。

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

后续

EOSIO Dawn 3.0 主要聚焦在核心平台的稳定性上,接下去几个月我们将准备最后的系统合约,这一部分将实现权益,投票以及管理机制所有功能,另外会完成代币标准的制定.

一旦系统合约如期实现,我们将会启动一个新的公开测试网络.那时启动你自己的测试网络和开发应用将变得非常简单。同时在接下来的两个星期内,为了在准备新的测试网络时减少对开发者的影响,我们会关闭当前的公开测试网络。

总结

EOSIO Dawn 3.0 是一个开发者发布的版本, 这个版本功能相对完备并且有着稳定的API.我们相信目前这个平台对应用开发者来说已经足够稳定.相对于一年前的构想来说,EOSIO已经强大很多并且开发更加容易。

我们的团队日渐壮大并且在开发上也不断有着新的突破.我们代码仓库的活跃程度在过去一个月内成为了github上前10的C++库.为了6月份EOSIO 1.0高质量的发布,一切都在稳步推进!

翻译&校验:一臣(Ansen Yu),Louis Jin,Frank Wu

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

推荐阅读更多精彩内容