基于BCOS的历史数据查询方案

目标

完成类fabric里gethistoryfromkey的功能，即可以根据key查询key对应数据的表更记录。

方案探究

智能合约新增逻辑

在智能合约里编写逻辑：

//在数据上链时1.创建一个交易hash数组2.查询该key最新的交易hash //新增3.将该hash写入数组 //新增4，执行写入数据操作

较原先的合约逻辑，新增了第2第3步。

通过这个文档（查看英文文档）我们可以查询到有关区块可交易属性的 接口有：

不包含我们期望的获取交易hash(交易地址)的接口。

借用fabric源码逻辑

查看fabric源码逻辑可知。fabric并不是在计算阶段记录历史数据。

而是在提交阶段，即生成区块的时候记录的。在系统流程中将所有的key及历史数据相关信息计入了历史数据库。

图源

解决方案

由前两个方案可知，在智能合约内部记录的方案一是没有现成的接口来实现，第二则是将复杂的流程放到了智能合约上执行，不符合节约链上资源的设计准则。所以我们可以实现的

方案1：

每次交易完成后，实时将本次交易的交易hash(甚至交易数据)和对应的key一起，记录到专门的history数据库(链上或链下皆可)里。

方案2：

而参考这个回答，我们除了从交易返回里获取交易数据外，还可以使用事件监控来获取交易数据及其变更。

但是，这个方式依旧无法获得交易hash，只能直接存储交易的数据。

总结

​ 研究这个问题我们发现，区块链系统本身并未提供“记录历史”的功能，乍一看好像违背了其【可溯源】的特性。使用者并不能直接去根据一个key值去做历史数据追溯，但是细想才发现未必。

​ 在讨论【不可篡改】【可溯源】时，我们常常忽略这里谈论的是特性而非功能。功能是用来使用的，而特性则更多的体现在生成过程中。

​ 而在区块链系统里，生成过程中的对象就是数据。所以我们在说系统的特性的时候，其实说的是数据特性，即区块链系统的数据是【不可篡改】【可溯源】的。

一个猜想

​ 因为区块链的特殊机制，存储一直都是各区块链系统的一个重点指标。而默认对历史数据进行链上存储，无异会增加存储压力。所以这个功能也变成了一个可选项。不过对于一个长期运行的项目来说，可能根据自己需求去做部分的历史存储，会是一个比较好的折中方案。

可能这也是为什么有的区块链不直接带历史数据查询的原因吧

 注：文中出现的【区块链】专指联盟链，公链不在讨论范围。