今天BlockOne发布了EOSIO代码的1.5版本更新，本文介绍下其中的几个重点内容。
对于这次更新，媒体都报道过了，不作赘述，我附上了MeetOne的一份简讯，可以查看。
这篇文章，介绍下这些更改的内容的细节，以及可能会带来什么影响。因为个人理解有限，所以难免可能有不当之处，还请指正。
image.png
白名单/黑名单实现机制的变更
PR: https://github.com/EOSIO/eos/pull/6318
这个更改，让白名单/黑名单功能比原来的方式更加完整。由于该特性也被强制用于特权帐户，因此添加了一个额外的配置，以允许对在白名单/黑名单之外执行的合约进行明确的指定。
什么意思呢？
在1.5更新之后，发送内联动作(inline action)和延时交易的时候，也会进行强制的白名单/黑名单检查。
不过与之相关的一个问题是：有时候出块节点也必须要绕过白名单/黑名单的检查，比如，执行仲裁命令的时候。之前的实现中，出块节点们要从黑名单中临时删除某个账号，才能够实现，这并不安全，因为黑名单账户可能会在这个时间点操作转账等；不过现在出块节点可以通过发起指令时候，加上sender-bypass-whiteblacklist的选项，来绕过黑名单的检查。
请注意，这只是我个人的理解，也许会有不当之处，还请指正。
查询表时更加灵活，且可显示RAM的支付者
涉及到了 get_table_rows和get_table_by_scope的RPC调用的更改。主要是对于开发者来说更加方便了，而对于普通用户而言，可以不需要关注这一条更改。
- 允许开发人员/用户反向遍历get_table_rows RPC调用中的行
- 允许开发人员/用户获取每一行的RAM 支付者信息
- 允许开发人员/用户反向迭代get_table_by_scope RPC调用中的行
多线程事务，以及区块KEY的恢复(transaction key recovery )
当应用一个签名的区块时，通过controler中的线程池的方式，可以在不同的线程之中进行一笔事务的key的恢复。现在可以用传递chain-threads - number这一参数的方式，来指定在进行事务KEY恢复( transaction key recovery)时候，所需要的线程数。
在1.5这个版本，引入了对跨多个线程的事务和区块的加密签名(又名签名验证)中恢复密钥的支持。这一特性会减少大多数区块的资源开销，也会降低区块验证所需要的时间。不过，出块的开销仍然是不变。
状态历史插件(State history Plugin, Alpha版)
EOS 的DAPP查询数据，主要是通过访问完整历史节点来进行的。但是随着EOS网络的快速增长，历史插件变得越来越难以维护。
与历史插件相关的问题，未来会出现更多。如果现在不采取行动，最终会对网络造成严重影响。
来自BlockOne的Todd Fleming 开发了名为State history Plugin(状态历史插件)的这一历史解决方案。状态历史插件解决了MongoDB插件遇到的一些问题:
- 自动处理分叉，不会存储任何重复的数据。
- 数据库存储与节点解耦。因此，如果数据库宕机，可以很容易地进行同步，而无需停止节点或需要重播区块链。
- 其他以前无法实现的功能。这些功能包括，在某个智能合约所有相关区块中，获得该智能合约的数据表中的记录。
- 由于采用了解耦设计，未来对任何数据表结构的更改都不需要重放Nodeos(注意：这一功能会包含在未来的更新中)。
Todd还开发了一个实用程序 fill-postgresql，它会用新的历史信息填充Postgresql数据库。未来会开发出许多其他向数据库填充数据的程序，而不只局限于一个数据库。
这次的1.5版本中，加入了状态历史插件。这个插件目前被认为是ALPHA版本，在最终发布之前可能会有很大的变化，但是blockone的开发团队邀请社区对其进行评估并提供反馈，以帮助指导该产品的开发。
另外，EOS42也发布过一篇文章，介绍针对EOS全历史节点，一个可扩展的解决方案，并且，我们也会开源了针对该状态历史插件的一个API，并在不久之后提供首个基于状态历史插件的API服务。
除此之外，为了使状态历史插件更容易使用, EOS42正与(blockmatrix)(https://blockmatrix.network/)一起，提供针对日常历史状态数据的快照数据文件, 这可以让任何人都能够在几分钟内创建起来一个全新的历史节点, 不用花费数周时间等待数据同步。
网友评论