EOS轻节点方案–EOS 弧光

EOS 原力开发团队于近日发布了首个高性能区块链轻节点方案–EOS 弧光。该方案基于 Golang 开发,为 EOSIO 这类高性能区块链协议引入轻量级节点解决方案。与基于 nodeos 启动的 EOSIO 全节点不同 ,「EOS 弧光 」轻节点仅需验证区块头 , 无需执行区块中 Action。

高性能区块链的新瓶颈:

1、运维费用高
EOSIO 的区块头结构支持轻量级的节点,但是当前 EOSIO 社区中并没有一个可靠的轻量级节点实现。
在比特币白皮书中,中本聪提出不运行一个完整的网络节点也是可以进行支付验证。对于区块链数据可以采取剪枝的方式进行进行压缩, 老的区块可以只保留区块头和节点关注的交易数据,即使在白皮书发布的 2008 年,也可以在当时常见的微型计算机的内存中存储全部区块头数据。
随后的讨论中, 中本聪认为比特币网络最终可能只存在 10 万左右的全节点,这些全节点具备生产区块的能力,而同时存在着数百万的轻量级客户端,这些客户端可以收发交易,虽然不能生产区块,但仍能自己验证支付,而不需要依赖别的节点进行验证。
EOSIO 的区块链结构同样支持轻量级节点,在其网络与应用中,同样需要大量的轻量级节点,特别的, 区别于比特币的设计,EOSIO 全节点对机器性能的要求十分苛刻,并且由于其本身的 Token 增发与 RAM 扩容机制,这一要求不会随着机器物理性能的提升而得到缓解。
在 EOSIO 网络中,一个全节点对于机器性能、网络和运维的要求是非常高的,目前 EOSIO 网络中可用的全节点很少 , 这意味着当前 EOSIO 网络结构不够去中心化 , 对整个网络的稳定性产生了很大影响 , 同时这也提高了链上应用的开发和部署难度。
以 EOS 网络(chainID:aca376f206b8fc25a6ed44dbdc66547c36c6c33e3a119ffbeaef943642f0e906)为例(2020 年 1 月中旬),RAM 总量为 174G,已分配的内存为 74G 左右,虽然实际使用的数据很少,但作为一个全节点至少要配置超过 64G 的内存,否则会出现因为内存读写未命中而导致事务执行失败,即使是重放区块,也可能导致区块重放速度无法跟上新区块生产速度,这也意味着目前的大多数计算设备无法满足 EOSIO 节点的需求。
另一方面,目前 EOSIO 区块数据十分庞大,这给节点的维护和存储带来很大挑战,同时重放区块消耗时间过长,在一些主流性能服务器上,完整的重放区块需要近一个月时间。即便使用快照功能可以在几个小时时间之内恢复 RAM 状态但依然不能解决节点消耗过大的问题。有的开发者甚至感叹高 TPS 是「伪命题」,认为今后节点部署甚至会花费一年时间,以至于没有新的全节点出现。

2、开发难度及成本高
虽然 EOSIO 的插件式架构可以允许节点拓展功能 , 但是节点对机器性能的要求较高 , 同时 EOSIO 基于 C++开发插件有较高的开发门槛 , 因此 EOSIO 的拓展工具很少 , 这也间接提高了 DAPP 的开发难度。
早期的很多 DAPP 的查询与索引服务依赖于 EOSIO 的 history 插件和 mongoDB 插件,但随着节点区块数据的增多,这样的 history 节点或 mongoDB 数据库产生了很大的性能问题,虽然社区也提出了一些解决方案,但是由于其往往依赖于全节点,故而成本颇高,使得很多此类服务的价格比较高昂,这给 DAPP 的开发和运营带来了很多额外成本。
中本聪对于比特币网络结构的预测同样适用于其他的区块链网络,除了全节点外,EOSIO 的网络也同样需要大量符合成本博弈的轻量级节点。

3、跨链需求无法满足
目前公有链发展的一个重要方向是跨链功能的支持 , EOSIO 将支持基于 IBC 来添加侧链 , 目前启动 IBC 需要基于全节点以使用户可以获取基于 Merkle Tree 的证明数据 , 但是由于搭建一个全节点的成本过高 , 即使要求少数验证者和钓鱼者启动全节点也是一件非常难以实现的事,这会使得某些理论上的支持方案从经济成本上不成立,如果跨链的运行仅仅依赖于少数的全节点提供的服务 , 那么整个系统将会十分脆弱。
综合以上问题 , 我们需要一个足够轻量级的 EOSIO 节点实现 , 轻节点在保证对区块的验证同时 , 应当易于拓展和二次开发。

「EOS 弧光」技术原理:

「EOS 弧光」轻节点不会处理每一个事务,仅仅验证区块与区块头的有效性,同时确认其区块不可逆。
EOSIO 对节点高需求的一个主要原因是其内存(RAM)状态,这些状态十分庞大且没有在区块中验证,所以任何一个想要获取任意状态的节点都需要完整的重放一遍 EOSIO 的区块,虽然可以通过快照功能复原节点,但即使对于保持同步的节点,一旦出现故障其复原时间也比较漫长。同时由于 EOSIO 链上的事务比较繁忙,峰值时可达 4000 TPS 左右,同步实时的 EOSIO 区块也会对机器的要求较高。
不处理每一个事务意味轻节点的大部分工作可以并行完成,而且也可以从任意区块高度开始同步,在目前的原型实现中,轻节点只需占用很少的计算资源即可完成验证。
不处理每一个事务虽然允许轻节点占用很少的资源,但是也使得轻节点无法提供内存(RAM)状态,而在 EOSIO 中几乎所有的状态都在内存中,一些操作(EOSIO 称之为 Action)也需要通过执行事务来触发,为了解决这个问题,这就需要一些断言机制来保证节点仅仅基于区块数据就可以获得 EOSIO 的状态,这可以通过 EOSIO 状态断言合约和状态静态断言合约来实现。
根据 EOSIO 轻节点所负担的角色的不同,我们将 EOSIO 轻节点分为区块节点和区块头节点,前者包含全部或部分 EOSIO 区块,后者只包括 EOSIO 区块头数据。
考虑到 EOSIO 还在不断的发展中 , 轻节点也需要跟随其进行迭代 , 所以轻节点的设计应该尽可能的和 EOSIO 保持同构 , 其 API 与操作也应该尽可能与 nodeos 保持统一 , 当然 , 轻节点不含内存状态 , 所以一些 API。如:get table 等。

「EOS 弧光」使用场景:

1 真正的去中心化钱包:
目前的 EOSIO 钱包往往基于中心化的第三方提供的数据,这些数据并没有被验证,这与比特币的钱包有很大区别,这些钱包如果脱离了第三方提供的服务就无法正常使用,同时在这些钱包中,用户无法得到准确的交易执行回馈,如果要确认交易是否完成,只能依赖于其他服务,例如区块浏览器来确认交易完成,这实际上存在的很大安全风险。
基于「EOS 弧光」我们可以将轻节点嵌入进钱包中,这样每一个钱包都是一个轻节点,这时钱包可以独立去验证交易是否成功,即使在不安全的网络环境中也可以安全的使用。

2 可信实时的区块数据服务:
很多 DAPP 需要实时的链上数据,尤其是去中心化交易所等响应短且重视安全性的应用,需要可以安全、确定的获取链上实时的状态,特别是 EOSIO 的不可逆区块判定,由于目前的共识算法尚处于初步完成的阶段,区块进入不可逆状态的时间间隔较长,这也就意味着很多应用需要先乐观的接受未进不可逆的区块,以事后验证的方式避免状态不一致,这样的逻辑需要编写节点插件,并部署全节点,这会增加很大的 DAPP 开发与运营成本。
基于「EOS 弧光」,可以把轻节点以库的形式纳入到已有的数据服务中,轻节点基于 Golang 开发,对于后端开发比较友好且不存在门槛,同时因为轻节点完整的实现了共识算法,所以实现可信实时的区块数据服务十分方便。

3 高性能跨链服务:
如果需要实现 EOSIO 链与其他链的跨链交互,往往需要同时实现两条链的轻节点,「EOS 弧光」可以很简单的嵌入其他服务或节点中,并且能够独立的验证节点,可以很好的支撑此类应用。
事实上,「EOS 弧光」最初的开发动机即是作为跨链服务中的一环,比如,目前很多链基于 Cosmos SDK 开发,一个很常见的架构就是把基于 Cosmos SDK 的链作为结算链,把基于 EOSIO 的链作为计算链,通过实现 Cosmos 的 IBC 协议来完成跨链计算结果结算。在这个系统中,我们只需在结算链节点节点中集成「EOS 弧光」,使每个结算链的节点都是计算链的轻节点,通过原有结算链的共识机制使各个结算链节点持有的计算链区块数据(只需考虑不可逆块的 ID)达成共识,这样就实现了计算链的数据回溯到结算链的过程。

「EOS 弧光」技术路线图

「EOS 弧光」由 EOSC 社区开发团队 EOS 原力开发,目前开发工作主要分为三个方向:节点实现、兼容全节点 API 和计算性能优化,EOS 原力团队已经实现了初步的版本,可以完成区块数据的同步和验证,同时发布了技术路线图:
2020 Q1 : 实现区块不可逆块判定算法,完善区块存储实现 , 兼容 nodeos 的 block db
2020 Q2 : 支持其他节点从轻节点同步区块与事务,完善 API 接口以尽可能兼容 nodeos
2020 Q3 :优化并发计算能力 , 加速同步过程,支持 EOS-VM 以实现部分 Action 的执行

「EOS 弧光」已全部开源,Github 地址:https://github.com/eosforce/eos-light-node

EOS 新的资源 — “硬盘”

EOS正在开发新的网络资源系统—“硬盘”。

“硬盘”DISK将为DAPP的开发者提供更为便宜的资源。

很快EOS将推出一个新的在线数据存贮解决方案。这个新的网络资源叫做“硬盘”,它可以为开发者提供一个存储各种数据、智能合约以及DAPP数据更好的选项。

根据项目的Github网页显示,EOSIO系统将包含一个叫“eosio.kvdisk”的数据库,它将消耗一种叫“硬盘”的网络资源。这个数据库相比于RAM(内存)系统拥有较高的容量以及较高的CPU消耗量,可显著降低DAPP开发者的开发费用。

区块链解决方案公司的CTO Corvin Meyer今天公布这一特征。他解释说:“在我看来,它不仅仅是文件存储系统。它便宜,但是链上速度较慢。它作为存储合约计算数据使用,而不是用来存储大型文件。相较于RAM内存,DISK硬盘更易负担。这使得哈希值上链变的更有意义和可能”。

他指出,尽管“硬盘”几个月前已经被添加了,但是直到现在仍未被关注。早在去年十一月份最初的信息已经被披露。

同时他也建议这个特征应先添加到EOSIO,然后再延伸到EOS链上。

EOS的效率

EOS的批评者一直呼吁提高链的效率和可扩展性。

EOS使用资源模型来约束链上处理,因此基于EOS的DAPP必须为各种资源付费,例如CPU、RAM、NET。它允许DAPP为交易提前储备带宽。

不幸的是,EOS资源偶尔会超载,同时资源价格也会偶尔剧烈波动。为避免这个问题,在去年十一月份,数个DAPP迁移到其他链上了。即便是EOS的母公司,Block.one也只能在另一条备用链上发布它的社交网络Voice。

针对EOS的可扩展性的抱怨已经消失,但是EOS依然和以前一样承受着同样的问题。将一部分数据放到一个单独的资源中可以降低DAPP开发者的负担。

其他的特征一样可以减轻负担,EOS的REX,将来的其他类似的工具,以及第三方LiquidApps开发的 VRAM都可以帮助开发者负担的起他们需要的资源。

更多的区块链存储

就像其他评论员指出的,EOS上还存在另外的通用文件存储系统。

Cryptolions加密狮最近介绍了一个叫普罗米修斯的系统,任何人都可以上传文件到EOSFileStore。这是一个老的,不再使用的系统。EOS的副链Telos正在开发一个叫DSTOR的基于IPFS的存储平台。

同样,也有一些分布式存储系统被整合到其他链上。比如:TRON的BitTorrent File
System (BTFS) ,Protocol Labs的 IPFS, 以及 Sia最近发布的 Skynet 。

相比于EOS尚未开启的DISK硬盘,这些平台拥有更大的影响力。但是事实上,在一个解决开发者痛点的长期竞赛中,后入局者往往更加重要。

BM 说

WechatIMG26

EOS 新增的 disk功能,接下来几周内会发布。
一开始,使用RAM来存储,作为alpha测试版;后面,节点可以升级,改用 rocks db 作为数据存储层,而不影响智能合约。本年度会发布更多的改进,兼容 rocks db

EOSIO 官方 testnet

EOS 官方发布了一个测试网
https://testnet.eos.io

特点是把账号创建、资源申请、区块链浏览器、部署代码和Action调用都界面化的放在一起了,方便开发者上手。

使用步骤

1 注册开发者账号,需要验证邮件

2 完成注册后,在右上角【Account Settings】里面可以查看已经自动创建好的测试账号

点击后,可以在里面申请多个账号、申请测试币、购买内存和抵押资源等

3 点击 Deploy 菜单,进入合约部署操作

4 点击 Push Action,可以发起合约交互,这里的界面目前不算友好,还不如bloks.io浏览器做得好

EOSIO 2 简介:提高性能,提高安全性和新的开发人员工具

原文链接:https://eos.io/news/introducing-eosio-2/

EOSIO 2 的构建考虑了开发人员。我们的重点:使其在EOSIO上构建更快,更简单,更安全。

我们认为,区块链开发的最大瓶颈是他们执行智能合约的速度。

EOSIO是第一个使用WebAssembly(WASM)引擎提高性能的区块链软件,但是随着时间的推移,我们超越了现有的通用WASM引擎,你知道的我们可以做得更多。

我们的解决方案是:构建我们自己的解决方案,并从头开始考虑区块链。EOS VM是我们专门构建的区块链WASM引擎,与EOSIO 1.0一起发布的Binaryen相比,运行EOS Mechanics WASM CPU基准的速度最高可快16倍。

接下来,我们想解决新开发人员的入门障碍–那些首次前往#eosio的hackathon或首次在EOSIO上进行开发的开发人员。通常,设置区块链开发环境是一个多步骤的过程,可能需要数小时甚至数天才能完成。这就是为什么我们要构建EOSIO Quickstart Web IDE,这是一个开发工具,它使新开发人员可以在几分钟之内从入门到准备就绪。

最后,对于任何开发人员而言,将新用户加入区块链应用程序的主要痛点之一就是保护私钥和公钥,如果操作不当,则会带来安全风险。通过此版本的WebAuthn对EOSIO的支持,开发人员可以开始在其EOSIO应用程序中使用WebAuthn测试事务签名,从而为当今区块链中不存在的私钥提供一定程度的安全性。

继续阅读以进一步解释EOSIO 2.0 Release Candidate中包含的四个主要组件:

EOS VM

专门用于区块链应用程序的高性能WebAssembly(WASM)引擎,可在处理智能合约和显着提高性能时促进更有效地使用系统资源。
EOSIO快速入门Web IDE:一个功能强大的,新的,自包含的,基于Web的集成开发环境,用于构建EOSIO智能合约和关联的Web应用程序。它可以在几分钟内完成设置,可以在任何浏览器中运行,并有助于降低新的EOSIO区块链开发人员的进入门槛。
WebAuthn支持:一种广泛接受的安全身份验证标准,无需进行浏览器扩展或其他软件即可进行交易签名。
加权阈值多签名块生产支持:块生产者使用不同的密钥在主块和备用块生产硬件上对块进行签名的安全方法。

我们已经开发了一种新的专用WebAssembly(WASM)引擎,称为EOS VM,可以满足EOSIO区块链上安全的确定性执行的不断增长的需求。尽管非常适合它们的目的,但是Binaryen和WABT解释器在内存分配不受限制,加载时间延长和堆栈溢出方面存在问题,并且它们在运行时缺少沙箱。这些问题加在一起,限制了整体性能和可靠性。

作为最初的WASM解决方案,Binaryen解释器于2018年6月发布,带有EOSIO 1.0,同年9月被EOSIO 1.3支持WABT所取代,性能提高了2倍。借助EOSIO 2,我们将发布一个名为EOS VM的新WASM引擎,该引擎由三个组件组成,每个组件都有自己的功能并提供特定的性能增强。

区块链WebAssembly执行的强大组件三重奏

EOS VM解释器是一个WebAssembly解释器,提供了极快的解析/加载,确定性和高效的时限执行。从头开始设计解释器,使我们能够为将来对智能合约的调试支持腾出空间。

EOS VM即时(JIT)编译器是WebAssembly编译器,它采用WASM并即时生成本机代码。与WABT,Binaryen和EOS VM解释器之类的解释器相比,该体系结构能够非常快速地执行WASM智能合约,并提供显着的性能优势。这种JIT解决方案的绝对速度使我们能够在区块链上使用它,而无需其他解决方案进行较长的块编译时间。

EOS VM优化编译器是EOS VM的第三个组件,它使用了利用多遍编译架构的专用编译器框架(LLVM)。通过优化编译器生成的本机代码通常比在WABT,Binaryen,EOS VM解释器和EOS VM JIT中执行的相同代码快一个数量级。最重要的是,它甚至比现有的WAVM引擎还要快,但是与WAVM不同,它可以利用我们的分层设计在区块链上安全使用。

极快的执行性能

我们针对不同组件的基准测试在我们的测试环境中产生了以下性能增强:

以上性能基准显示了各种EOS VM组件的相对优势。EOSIO 2将EOS VM JIT作为大多数智能合约执行的一线编译器,而EOS VM Optimized Compiler尝试在后台编译相同的智能合约,并将其部署以在链上以极快的速度随后执行。这种分层架构使EOSIO 2能够利用快速启动和优化的智能合约代码编译功能。

EOS VM及其组件也可以高度自定义,因此开发人员可以以适合其所需功能的特定方式实现其各个方面。通过参考GitHub上的EOS VM存储库了解更多信息。

网络代码的重大改进

我们向net_plugin添加了多线程支持。现在,net_plugin中的几乎所有处理,包括块传播,事务处理,块/事务打包/解压缩以及其他进程,都由与主应用程序线程不同的单独线程来处理。通过隔离这些过程,我们发现多生产者EOSIO网络上的事务处理和块处理性能有了显着改善。更多详细信息,请参见EOSIO 2.0.0-rc1发行说明。

EOSIO快速入门Web IDE
EOSIO 2的增强功能是针对开发人员的,此新工具将使在EOSIO项目上开始,共享和协作变得更加容易。

为EOSIO 设置开发环境目前需要在开发人员的计算机上本地运行的多步骤过程,这对于刚入职的人来说可能相当复杂。现在处于Alpha支持阶段,EOSIO Quickstart Web IDE打算消除开发人员的入门障碍。它在云中运行,使新开发人员能够建立智能合约和Web应用程序开发环境以及完全集成的单节点个人测试网,因此他们可以在几分钟之内从入门到构建。

EOSIO快速入门Web IDE使新的区块链开发人员可以更轻松地访问EOSIO,从而简化了流程,并使快速而轻松地开始学习EOSIO开发。开发人员可以从演示应用程序开始,无缝地进行更改,并实时查看更新,以及直接从浏览器将代码提交到git存储库。

随着新的开发人员开始使用EOSIO Quickstart Web IDE进行构建,我们期待收到社区的反馈。

对WebAuthn支持

WebAuthn是强大的用户身份验证的标准,由万维网联盟(W3C),在线快速身份验证(FIDO)联盟在Google,Mozilla,Microsoft,Yubico等公司的帮助下进行了协作。WebAuthn允许您使用硬件设备在浏览器中对交易进行身份验证和签名,而无需在设备上安装扩展程序或其他软件。

WebAuthn在诸如YubiKey之类的设备上创建加密密钥对,并通过安全且经过身份验证的通道仅与远程服务器共享公共密钥。通过完全在硬件设备中管理身份验证凭据,WebAuthn已显示出从本质上缓解了整个网络钓鱼等攻击类型。由于硬件设备是必不可少的,并且密码没有存储在中央服务器上,因此实现基于WebAuthn的身份验证甚至可以帮助防止密码被盗的高规格数据泄露。

通过此版本的WebAuthn对EOSIO的支持,开发人员可以开始在其EOSIO应用程序中使用WebAuthn测试事务签名。EOSIO对WebAuthn的支持是迈向安全和无缝事务签名的一步,而无需跟踪私钥或其他帐户信息。我们将继续研究各种机制,以支持希望针对WebAuthn集成调整其应用程序的面向社区的参与者和企业级参与者,并且我们鼓励应用程序开发人员加入第一批尝试采用该技术的私人应用程序的第一批采用者。

加权门限多签名块生产

区块生产者必须能够为其运行区块链的核心服务提供高可用性。实现此目的的常用方法是冗余基础结构,在发生硬件故障或网络问题时,该基础结构可有效地保持块生产。加权阈值多签名块生产是许多功能中的第一个,旨在为块生产者提供完整的高可用性解决方案。

当前的共识规则要求每个块生产者仅需要一个加密块签名密钥。该密钥,无论是存储在磁盘上并通过软件加载还是由硬件钱包保护,都代表了块生产者操作的单点故障。如果该密钥丢失或暂时无法访问包含它的硬件模块,则块生产者别无选择,只能丢弃块,从而影响整个网络的吞吐量。

为了提高块生产的安全性和可伸缩性,加权阈值多签名块支持提供了一个允许层,该许可层允许以灵活方案使用多个块签名密钥,这将使冗余块签名基础结构能够存在而无需共享任何敏感数据。在GitHub上了解有关加权阈值多签名块生产的更多信息。

EOSIO 历史工具 (Alpha 版本)

随着区块链网络数据的不断增长,链上历史状态数据的查询读取越发困难。为了解决这一难题,Block.one 一直在开发一系列历史工具,以让 EOSIO 区块链上的访问数据操作更加简单快捷。

Block.one 之前发布了“状态历史插件”来优化数据访问,“状态历史插件”将区块链状态数据保存为新的平面文件格式,并且暴露一个 websocket 接口来读取区块/状态数据。

在现在的 Alpha 版本历史工具解决方案中,Block.one 通过引入 database fillers 来读取状态数据并且填充 PostgreSQL 和 LMDB 数据库,可以使用特定客户端和服务器wasm进行查询。

更多技术细节文档请阅读 Github 仓库:

https://github.com/EOSIO/history-tools

相关文档说明链接:

https://eosio.github.io/history-tools/

一文读懂 EOSIO 史上最复杂硬分叉升级及未来影响

作者:孤矢,EOS 原力创始人

2019 年年初,一些媒体开始报道 EOS.IO 代码提交次数下降的问题,我们 EOS 原力团队曾经公开回应过:EOS.IO 每天都有多个开发者在提交代码,这些开发内容在不同的分支里提交,并且需要经过测试以后再合并到主线。今天我们要提到的 1.8.0-rc2 就是此类情况,从 2019 年年初甚至更早就开始进行了开发,直到 2019 年 5 月 15 日 1.8.0-rc2 发布。

接下来我们将详细解释此次更新何以如此重要。

一、1.8.0-rc2 有哪些重要的改进

1 扩展性提升与代码重构

在这个版本中我们看到了大量的提交 , 主要集中在代码重构和线程安全化两个方面 :

首先的代码重构 , 很多人往往不关心这些既没有增加功能也没有提升性能的代码修改 , 但是从开发的角度看 , 这些其实构成后续开发的重要基础 , 我们可以看到 , 自年初以来 , Block.one 的核心开发者一直在改善 EOS.IO 的代码结构 , 并且从设计层面上逐步在建立一个抽象层 , 最明显的是 EOS.IO.cdt 的完善 , 这些构成了 EOS.IO 的框架 , 不同于很多在一开始就给出了庞大架构的团队 ,Block.one 的开发团队一贯以务实且自低向上的思路开发 EOS.IO。

在 1.8.0 版本中 , Block.one 的开发者拆分了很多之前的巨无霸类型 , 剥离了散落在各处的一些复杂逻辑 , 比如 `pending_block_state` 相关的状态管理 , 就从 `block_header_state` 中剥离出来 . 还有之前略带“坏味”的 transaction traces, 也在这次重新整理。

另一个方面是关于多线程 , 在最近一段时间有很多关于线程安全性的提交,为下一步实现多线程相关开发做准备,Block.One 团队在 2019 年的开发中对多线程非常重视,此次重构后将很更好的实现 EOS.IO 白皮书里描述的多线程,届时 TPS 会上升到一个新的台阶。

众所周知 , 中大规模 C++软件的多线程开发一直是一个“深坑”, 为了在引入并行计算的同时保证 EOS.IO 的稳定性 , Block.One 团队并没有急于进行多线程相关新特性的开发 , 而是耐心的排查代码中的线程安全问题 , 完善基础架构支持 , 同时在特定的适合并发的独立模块 , 如 chain api 以及 p2p 模块引入对应的多线程实现。

2 提升链安全性

在这个版本中 , Block.One 团队修正了之前遗留的一些资源计算问题 , EOS.IO 中资源相关的逻辑很多 , 并且极为分散 , 为了提升链性能并避免节点进行不必要的计算 , EOS.IO 中添加了很多资源相关的特化逻辑 , 这也造成了很多特定场景下用户资源计算的不明确 , 对于 EOS.IO 链来说 , 这带来了很多起潜在的安全性问题 , 前一阶段暴露的由延迟交易所触发的阻塞交易问题 , 很大程度上就是资源检查不完备的问题。

另外 , 某些场景下资源计算的问题也会导致用户权益上的损失 , 所以这方面的修改势在必行。

3 智能合约安全

智能合约安全困扰了 EOS.IO 社区很久,DAPP 开发者在过去一年的实践中发现了大量的问题,Block.One 团队吸收了这些问题并且做出了极大的改进,此次更新对智能合约开发者更友好。

举例来说 , 对于 DAPP 开发者来说 , 一个好消息就是千呼万唤的 `GET_SENDER` API 终于要引入 EOS.IO 中了 , DAPP 开发者可以通过这个 API 判定当前 Action 是否是通过 inline action 机制触发的 , 据此可以回避大量的基于合约触发 inline action 的攻击手段 . 这个更新,可以一定程度上部分解决了困扰社区已久的随机数问题,需要注意的是 , 即使通过这个 api 可以屏蔽当前的很多攻击手段 , 固然攻击者的攻击成本会大幅提高 , 但是不意味着 DAPP 开发者可以高枕无忧 , 对于开发者来说安全问题永远需要注意 , 没有什么一劳永逸的银弹。

4 硬分叉升级机制

这方面的更新可以使得未来的硬分叉升级更加高效的同时使得硬分叉升级过程中不影响用户使用体验。

近一段时间 , Block.One 其实开发了非常多的新功能,包括上面提到的几个功能 , 但都没有在过往的更新中出现,一个很大的原因就是开发者必须保证 EOS.IO 的兼容性 , 节点可以选择不升级节点版本 , 显然这会极大的阻挠 EOS.IO 的发展 , 这次 1.8.0 的版本与以往的一个最大区别是这个版本不兼容前面的版本 , 也就是所谓的“硬分叉”, 在这个版本之前 EOS.IO 并没有应对硬分叉的机制 , 硬分叉的过程会对用户的使用带来很大影响 , 为了使以后的更新不会像这一次一样造成很大影响 , 这次更新中添加了一系列硬分叉升级机制 , 为的是以后的硬分叉更新可以更加平滑和安全。

在 EOS 原力过往的更新中 , 原力团队也遇到了同样的问题 , 所以引入了链配置功能 , 通过这个机制向链添加特性的开启区块高度和链维护状态 , 以此解决硬分叉中的过渡问题 , Block.One 的对策与此类似 , 通过引入 protocol feature 来解决这个问题 , 与原力强调简单通用的解决方案不同 , Block.One 的 feature 设计希望更加完备的解决特性的兼容问题 , 具体的设计可以参见 #6831。

这里可以判断 Block.One 以后的开发过程中会有比之以往更多的硬分叉 , 未来 EOS.IO 的进展会明显快于以往 .

二 EOS.IO 硬分叉影响

EOS.IO 第一次使用硬分叉方式来升级,因此带来的影响也是非常巨大的。

1 节点

大部分节点应该没有经历过硬分叉升级 , 如果严格按照硬分叉的要求来,所有节点需要重放一遍区块,按现在的节点配置,大多数节点最少需要数天才能完成区块重放,当然,还有一种比较偷懒的方法,就是直接使用其他机构提供的快照,但是这样的坏处是如果太多核心节点尤其是 BP 如果这样更新 , 则会影响整个链的安全性。

2 用户

交易所,钱包,区块浏览器,DAPP 等所有的 P2P 节点都会暂停一段时间,其他所有的外部访问数据都会中断,用户感知非常明显。
当然,区块链本身并没有停止,只是为了安全着想,暂停外部和链的交互。

3 DAPP 开发者

理论上链的硬分叉不会影响合约的运行 , 但是考虑到很多 DAPP 采取了半中心化的架构 , 有大量的逻辑在链外运行并与链交互 , 这样一次硬分叉势必带来一定的风险。

三 硬分叉好处和风险

1 好处

在互联网时代,产品迭代是家常便饭,几乎每周开发者都会发布新的版本,用户也习惯第一时间更新升级享受更多的功能和服务。
而此前硬分叉升级在区块链行业几乎非常少见,原因是大部分区块链由去中心化的自由开发者组成,因此开发进度缓慢,节点极其分散,导致硬分叉升级更加麻烦,以比特币为例,2010 年的溢出漏洞导致了导致了 1840 亿的 BTC 凭空创建出来,中本聪第一时间发布了新的版本硬分叉升级,避免了比特币的危机,后来中本聪离开社区后,比特币由社区接管,硬分叉升级很难达成共识,因此很少使用硬分叉升级的方式。

而 Block.One 团队是一个专业开发组织,开发进度比以往的区块链项目得到了指数级的提升,因此快速迭代适应用户需求成为了主流。以目前大多数公有链的技术架构来看,如果要实现大规模的功能升级,硬分叉升级的方式不可避免。

2 风险

如果分叉的过程中超级节点作恶,分叉过程会变得十分危险,如果一部分节点联合起来拒绝升级,那么大概率会出现两个 EOS。

Blockone 做了一定的防范措施:尽管 Block.One 在 2019 年上半年进行了大量的开发,有很多的新功能,但是此次更新只包括一些必要的功能和安全性问题修复 , 等到 feature 上线后硬分叉会变得更加顺利。

四、本次硬分叉注意事项

这是 EOS.IO 面临的第一次硬分叉更新,而且是没有在一个有效的升级机制下进行的硬分叉更新,需要节点和社区付出更多的努力。EOS 原力团队从主网启动开始进行过多次大规模的硬分叉升级以迭代新的功能,这里我们分享一下硬分叉升级中的一些经验:

首先 , 准备越多则更新越顺利 , 在更新之前 , 节点必须做好备份工作 , 当前 EOS.IO 节点数据很大 , 节点备份时也一定要考虑恢复备份数据时的效率 , 备份数据与节点一定要在同一内网中 , 不要依赖于他人的备份 , 否则出现问题时传输备份数据的时间会很漫长 , 最好的方式是直接建立节点的备份节点。

其次 , 需要注意控制节点的交互 , 在更新的过程中 , 整个 EOS.IO 网络会处于一个节点半兼容状态 , 此时如果有人提交触发不兼容逻辑的交易到已经更新过的 BP, 则会导致未更新的 BP 立即分叉 , 虽然这次硬分叉的功能本身就是基于 feature 来管理是否生效的 , 同时执行逻辑出错的交易一般不会在 p2p 网络中传递 , 但是很难排出完全不会出现整个网络分裂的可能性 , 所以在更新过程中节点尤其是超级节点要注意控制交互 , 首先是要控制 http api 的开放 , 可以适当的开启几个 rpc 节点 , 但 rpc 节点与出块几点间不能有直接的 p2p 链接 , 同时重要的节点与其他外部节点间也不要有直接的 p2p 链接 , 这样可以在出现硬分叉时保证关键节点运行。

最后 , 需要控制好更新次序 , 如果基于一个有序的更新次序 , 即使有硬分叉可能 , 多数节点也不会受到影响 , EOS.IO 中的节点往往分为数据节点、出块节点、RPC 节点和同步节点 , 通过控制节点的交互可以很容易的为出块节点门建立一个“绿区”, 屏蔽外部对核心的出块节点的影响 , 此时出块节点可以进行升级 , 在此之后 , 逐步更新出块节点与外部的同步节点 , 同时应该为社区中的数据节点和其他只读节点预留一个更新窗口期 , 社区和开发者的节点可以一次类推 , 先通过建立屏蔽的同步节点建立一个安全区 , 再更新内部节点 , 最后更新同步节点 , 最终当大部分节点以及全部的核心节点更新完毕之后 , 再更新 RPC 节点 , 进而完成整个网络的更新。

其实以上谈到的手段和部署规范早已是老生常谈 , 只不过很多节点的维护者并没有严格的按照规范规划节点的部署 , 可以预见 , 如果节点的维护者还不完善节点部署 , 那么在这次更新中将会是很多问题的一个集中爆发点。

总之 , 越多准备则越加顺利 , 很多问题无法预测 , 所以节点在正式更新之前应当进行一次或者多次演练 , 这样会让 EOS.IO 的这次升级更加稳定。

五、硬分叉的意义是什么

硬分叉本应该是一个再普通不过的技术词汇,然而不同目的的硬分叉会产生不同的结果,因此社区对于硬分叉概念有着非常不同的理解。

从技术角度来讲:硬分叉会导致新的规则不兼容以前的规则,如果获得社区所有人的支持,那么大概率不会有什么影响。

从社区角度来讲:硬分叉时如果出现不同的共识和技术路线,那么大概率社区会分叉成两个公有链,各自支持不同的路线。

2016 年,以太坊(ETH)出现了 DAO 危机,创始人 Vitalik 决定回滚交易,社区有一部分人不同意回滚交易,认为区块链账本不可篡改,拒绝回滚,因此诞生 ETC (以太坊经典)。

2017 年,比特币(BTC)的拥堵使得大区块的支持者迫不及待要改进比特币,但是社区里有不同意见,因此诞生了比特币现金(BCH)。

2018 年,EOS 主网启动时,EOS 原力团队提出了不同的治理路线,随后诞生了 EOS 原力(EOSC)。我们可以看到,Block.one 团队做了大量的准备。

六、本次硬分叉的重要性

本次硬分叉是 EOS.IO 诞生以来最重要的版本,所有基于 EOS.IO 开发的公有链如 EOS,EOSC,ENU,Telos, BOS,Worbli 等均需要采用硬分叉升级。

Block.One 作为业内水平最高的开发组织之一,开发思路都非常大胆,此次添加了硬分叉机制,意味着后半年还会至少有两三次硬分叉。

以往的区块链都非常害怕硬分叉,只有 BCH 社区维持着半年一次的硬分叉升级, EOS 原力也进行过多次硬分叉升级,随着节点和社区认知的发展,硬分叉将不再是一个令人恐慌的词汇,反而会成为区块链进步的方式,即使出现新的分支也是有意义的探索。

此次硬分叉升级将会给 EOS.IO 带来更多的功能和易用性,可以预计,如果想要使得公有链适应时代的发展,未来硬分叉的升级方式将会成为主流。

七、关于近期社区关于 BM 跑路的传言。

近期又有传言称 BM 开发了新的项目,引发了 EOS.IO 社区的恐慌。

从 EOS.IO 的角度来讲,主网启动后 Block.One 在 EOS.IO 上付出了极大的努力,持续高效的开发将 EOS.IO 打造成了最强大的去中心化应用软件平台。同时,社区也有 EOS 原力,EOS Canada BOS Core 这样一直在公链开发一线深耕的团队,即使 BM 离开社区也不会影响 EOS.IO 的发展。

EOS 原力团队追踪着世界上大部分主流公有链的实际开发进展,无论是开发速度还是代码质量,BlockOne 在 EOS.IO 开发上的表现远超其他主流公有链开发团队,和 1.8.0-rc2 一样重要的分支还有多个都在开发中,让我们拭目以待。


EOS原力团队专注 EOSIO 的开发,最近在招聘 C++ 区块链工程师,有意进入EOS区块链开发的小伙伴可以关注下

推荐一个好工具 EOS Studio Web 版

EOS Studio Web 的使命是建立一个简单的、完整的、功能强大的在线合约开发和分享平台,为从新手开发者到大型开发团队提供基础设施和技术服务。这个平台由三个部分组成,它们将共同作用,创造一个更加便捷地合约开发资源网络:
1、即开即用的 Web 端集成开发环境;
2、在线的智能合约分享平台;
3、丰富的在线开发教程和相关资源。
即开即用的 Web 端集成开发环境
我们移植了桌面版所具有的全部核心功能,降低了配置和部署本地环境的门槛,即使是新手小白也能轻松地在线开始学习区块链开发。

主要功能和特点:
  • 在线代码编辑器:支持语法高亮,自动补全,代码错误提醒等常用功能;
  • 云端的合约编译器:为方便您运行早期版本的智能合约,我们支持随时切换 v1.3 – v1.6 版本的 EOSIO.CDT;
  • 云端的 EOSIO 节点托管服务:无需搭建本地开发环境,省去大量初始化时间和硬盘存储空间(感谢 dfuse 团队提供服务);
  • 在开发不同阶段随时切换不同网络:随时切换使用 EOS Studio 专属云托管网络,Jungle / Kylin 测试网,和 EOSIO 主网;
  • 合约调试器和账户查看器:提供和 EOS Studio 桌面版同样强大的合约调试及账户查看功能;
  • 交易签名工具:支持使用 Scatter 和其他移动端钱包进行交易签名。

Web IDE 直达链接:https://app.eosstudio.io/

EOSIO Authenticator APP 测试

基于 B1 钱包的开源代码,已经有团队完成了应用商店的上架

EOS Authenticator – iOS App by EOSLaomao
https://itunes.apple.com/app/eos-authenticator-app/id1466212988?mt=8

EOSIO Authenticator – Chrome 插件 by 麦子钱包
https://chrome.google.com/webstore/detail/eosio-authenticator/nnpajjdpjdjjchhlkndibblhelbdjaio?hl=en-US

目前 EOS 主网尚无 DAPP 支持 EOS Authenticator 协议,可以通过下面的这个 Demo 来进行测试
https://tropical.eoslaomao.com

EOS应用开发视频教程

麦子钱包 CTO 讲的一个 EOS 应用开发视频教程
https://www.youtube.com/playlist?list=PLyM_BB-jMJPrj79ykPNQPgJ5kinwLi8W_

还有一本配套实体书
https://search.jd.com/Search?keyword=EOS%E5%8C%BA%E5%9D%97%E9%93%BE%E5%BA%94%E7%94%A8%E5%BC%80%E5%8F%91%E6%8C%87%E5%8D%97&enc=utf-8&wq=EOS%E5%8C%BA%E5%9D%97%E9%93%BE%E5%BA%94%E7%94%A8%E5%BC%80%E5%8F%91%E6%8C%87%E5%8D%97

和一套开源代码
https://github.com/ericfish/EOS-Dev-Book/

感兴趣的可以看看