论文框架
查询效率
使用智能合约实现查询
以前的实现方法，智能合约直接访问和存储数据：
- 使用合约实现不同的索引和查询功能。不适合数据量大的实时查询，存储代价过大
- 用solidity建立一个基于合约的索引层。但当查询量较大时，gas费相当高
- 使用FastQuery。存储效率和查询速度都很快，但是由于要在合约中存储大量数据，所以很难实现
关于预言机：用于链上链下交互，是区块链链上世界和链外世界的桥梁，用于访问无法确定的、或是从链上数据无法获取的信息
Alice从Bob那里买了一杯$5的咖啡，使用比特币付账。此时需要将美元转化为一定数额的比特币，让Alice将这笔钱转给Bob。需要知道当前代币到美元转换的汇率，但该汇率可能会发生变化，导致各个节点进行验证时得出不一样的结果，无法达成一致性
使用预言机建立索引以及提供检索工具，智能合约辅助检索，不再直接访问数据：
- 使用SMPT数据结构，将链上数据分割为若干个不相交的子集，可以并行处理数据。同样的问题也是查询成本gas过高
总的来说，直接使用智能合约查询数据有很多缺点：
- 智能合约本身存在一定局限性
- gas费用问题
- Solidity语言转化二进制时可能产生问题
- 数据存储量小
将链上数据存储在其他数据库中
仍然面对着数据同步延迟大、无法防止篡改的问题
- EtherQL：第一个支持SQL类查询语句的高效查询层
- 基于EtherQL进行的扩展
使用Map-Reduce模型将区块链数据构建成关系型数据库。但同步时间过长，无法适配以太坊12秒一个新块的速度
- Map-Reduce模型是一种可用于大数据并行处理的计算模型、框架和平台，主要解决海量数据的计算
- 关于该模型还有一个不错的帖子
基于ForkBase的数据存储和查询：使用ForkBase作为外部数据库，添加了外部缓存以提高查询性能
在区块链中建立内部索引
分为块内索引和块间索引
这部分的内容用到了很多有关查找树的知识
- ？
- 使用RBTree作为检索结构。同时证明了当节点状态版本达到某个阈值后，即使删除当前节点，也不会对链上状态有影响，可以由此给检索进行剪枝
- Ether Query Language：使用了BST，用户可以使用SQL类似语句进行查询
- 使用TBST和AVL树来组织链上数据，能够支持时间范围搜索，可以快速找到搜索的起始位置，从该位置开始搜索所有交易记录
- 提出B-树是最合适的多路径自平衡搜索树
- 使用深度学习
