EOSIO开发更新2018.02.17

EOSIO 开发更新（多索引api，上下文无关action，新解释器）

过去几周，block.one生产力很高，完成了数个重大更新，它们将对开发者，可扩展性以及稳定性产生影响。

通用多索引数据库api

开发智能合约会涉及到定义一个数据库schema，用它来追踪，存储以及寻找数据。对于开发者来说，对数据进行多字段的排序/索引，以及在所有的维度中保持一致性都是很寻常的需求。

对于熟悉steem和bitshares的人来说，他们都知道boost::multi_index_container的强大。

这些容器(container)提供了强大，灵活和安全的api。我一直都想有为我们的webassembly有一个类似的灵活的强大的系统。我激动的向大家宣布，我们对智能合约如何获取数据库进行了调整，由此我们就能给开发者发布一套相似的api。

数据库迭代器

能让这些事变成现实的很大一部分原因是我们开发了一套新的数据库api，它是基于迭代器的。通过这些迭代器，webassembly能快速的找到并对数据库对象进行迭代。通过把寻找数据库中下一个或上一个项目的时间复杂度从O(log(n)) 降到 O(1)，这套新的api极大的提高了性能。

上下文无关action

一个上下文无关的action需要计算，它只依赖于交易的数据。这种计算的主要例子就是签名验证。我们只能通过交易数据和签名来计算签署了那笔交易的公钥。这种计算是一条去看了必须执行的单独计算中成本最昂贵的计算。因为这种计算是上下文无关的(它不依赖于区块链状态），它能并行执行。

上下文无关action与其他的用户action类似，只是它不需要获取区块链状态来执行验证。这让EOSIO能像签名验证一样并行地执行所有的上下文无关的action。更重要的是，这能执行通用的签名验证。

为了理解通用签名验证的重要性，就要考虑一下跨链通信。在跨链通信的时候，用户必须提供一个默克尔证明，它包含了128 sha256操作 与/或 14 签名验证。完成所有这些数据和计算只是证明了一个特定的操作发生在一条外链的一个特定的区块，并且/或者证明了一个特定的区块被至少三分之二的生产者验证了。这种业务逻辑仅仅需要验证区块id是有效的，以及该action在那个区块中就行了。这种业务逻辑不需要证明该action在该区块中的计算，而是需要从签名导出一个公钥的计算。

有了上下文无关action的支持，以太坊的多数拓展技术(分片，raiden，plasma，状态通道）都变得更加高效，并行化，变得实际可操作。这会与eosi的其他特性一起工作，让eosio能高效的进行跨链通信，实现无限制的可扩展。

隔离验证

隔离验证的概念，就是说交易签名在一笔交易被打包进区块链后，并不那么重要了。一旦交易是不可改变的了，那么签名数据就可以去除了，每个人都还能导出当前的状态。因为签名体现了多数交易的大部分，这就能极大的节省硬盘空间和同步时间。

同样的概念也能用于默克尔证明—它在跨链通信时使用。一旦一个证明被接受了，并不可逆地写进了区块链中后，该证明使用的sha256哈希的2kb空间就不再需要了。在跨链通信中这种方法节省的空间是在普通签名中节省的空间的32倍。

隔离验证的另一个例子是，steem的博客。在这种模式下，发表一篇博文，只需要包含sha256(博客内容)，而博客内容就放到隔离见证数据中。区块生产者会验证内容是否存在，是否有给定的哈希，但是博客内容并不需要保存，来从区块链的log中恢复当前状态。这让证明只需要知道内容一次，而不需要永远保存内容。

比特币如何实现隔离验证存在很多争议，但是多数反对比特币隔离见证的观点，都不适用于dpos。比如说，在dpos中，可以：

要求区块生产者保留所有记录。

跨链通信默克尔证明可以从公开数据中重新生成

区块生产者，有责任提供证据，证明他们的区块是有效的，那个签名权限对于交易来说是存在的。

在bft-dpos机制下，需要区块生产者完全串通，才能导致签名丢失，不过我们有21个独立的验证。

webassembly解释器

Eosio限制支持两种不同的web assembly执行引擎。最初的jit实现能在初始的“慢”编译步骤后提供快执行，而新的binaryen解释器提供了一种标准的一致引用实现，而不需要任何慢启动步骤。

区块生产者能使用这个解释器的同时，让编译器优化x86.更重要的是，在输出是“正确输出”的争论事件中，我们能使用标准定义的binaryen解释器，而让jit实现当作一个必须得到相同输出的优化。

在我们的性能测试总，binaryen解释器的速度是jit实现的20%；但是，对于多数交易，wasm执行时间只是所有交易处理时间的一小部分。数据库获取以及其他的区块链计算仍旧占到处理时间的大部分。在我们的评估中，对于简单的合约(比如现金合约）来说，解释器只影响现实性能的5%。对于我们在六月发布的eosi初始版中，我们将继续专注于正确性，稳定性和安全性，而不是性能。也就是说，我们没有忘记可拓展性和优化，我们设计eosio的目的就是进行拓展。

新团队成员

欢迎arhag来到block.one团队。arhag长期为比特股和steem做贡献，现在跟我们一起做数据库api部分的工作。

结论

开发进度很快，我们对此十分高兴。

EOSIO开发更新2018.02.17