基于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值去做历史数据追溯，但是细想才发现未必。
在讨论【不可篡改】【可溯源】时，我们常常忽略这里谈论的是特性而非功能。功能是用来使用的，而特性则更多的体现在生成过程中。
而在区块链系统里，生成过程中的对象就是数据。所以我们在说系统的特性的时候，其实说的是数据特性，即区块链系统的数据是【不可篡改】【可溯源】的。
一个猜想
因为区块链的特殊机制，存储一直都是各区块链系统的一个重点指标。而默认对历史数据进行链上存储，无异会增加存储压力。所以这个功能也变成了一个可选项。不过对于一个长期运行的项目来说，可能根据自己需求去做部分的历史存储，会是一个比较好的折中方案。文章来源：https://www.toymoban.com/news/detail-786278.html
可能这也是为什么有的区块链不直接带历史数据查询的原因吧文章来源地址https://www.toymoban.com/news/detail-786278.html
注：文中出现的【区块链】专指联盟链，公链不在讨论范围。
到了这里，关于基于BCOS的历史数据查询方案的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
