简介
分析
共享数据库存在的问题：
- 单个节点的存储和计算能力有限
- 节点中存在恶意节点
因此需要建立一个不需要节点之间达成信任就可以运行的共享数据库
- 可以建立中心节点负责各种事务处理（中心节点可能欺骗用户节点，用户节点可能会提出利于自己的update请求）
- 需要建立一个系统：不需要依赖一个中心化节点，不信任的环境下也可以正常运行
可以将共享数据库结合区块链
需要解决什么问题：
- 单个用户很难作为节点参与到区块链系统中（很少能够做到，因为作为节点的开销比较大）（轻量级客户端的概念）
- 用户将操作发给智能合约，智能合约会让所有的全节点针对操作结果进行一次（BFT）共识，通过后操作上链，并将结果返回给用户（存在吞吐量小，延迟高 ，高gas，隐私泄露）
三个目标：安全 兼容 高效 难以兼得
需要做到：
- 效率高
- 用户开销小
- 数据可溯源，防篡改
总的来说就是一些存储有限的用户节点如何能够高效且安全的参与到数据库的维护中
贡献
FalconDB实现了：
- 用户开销小
- 单个用户作为节点参与到共识中（单个用户只保存区块头，区块头中有当前数据库的最新摘要）
- 中心化数据库相当的查询效率
区块链相当的安全性，1/3容错
激励机制：鼓励server存储更多数据，对用户的查询给出正确的结果
系统设计
总览
DB Digest由ADS生成，用户可以用来验证
两种角色：
- servers
- clients：其中一部分会加入区块链系统中进行区块的验证，其他不会参与到共识中
用户提出update请求
提出请求并与服务端完成交互之后，发布一个包含这个update的新块，然后所有节点进行一次共识，通过后把块上链，用户节点更新本地保存的数据
保证操作之间的独立性
用户指出需要在哪个块的基础上进行修改，只有在指定块和当前块之间没有冲突时，包含此事务的块才会被接受。
区块链结构
共识
可以使用任何许可链的BFT共识 permissioned BFT consensus
所有服务节点和部分用户节点参与到共识中
部署
用户节点数量少时，可以全部加入到共识中，以将系统安全性最大化（使用tendermint实验，检测许可链环境下的拜占庭容错能力）
用户节点较多时
- 规定共识过程中总的节点数量（防止节点数量过多共识进程缓慢），再随机选出部分用户节点参与到共识中
- 使用algorand作为共识协议，来减少通信开销
激励模型
两个部分组成：
- 服务费合约：当客户端向服务器发送查询，或者请求对返回的结果进行证明时，客户端向其连接的服务器支付一定的服务费。此外，服务器和客户端因参与区块链共识协议和验证新区块而获得奖励。
- 验证合约：查询认证过程与区块链本身分离，在服务器提交有效证明之前，其在智能合约中的账户(包括存款和之前的收益)将被暂时冻结。服务器在那段时间内仍然可以从智能合约中收到钱，但不能提取。因此，恶意服务器将失去智能合约账户中的所有资金。
用户和服务端都在合约中抵押一笔资金
用户提出proof request时需要付出额外的钱给服务端
服务端无法提供正确的proof会失去抵押的钱和这一次查询挣到的钱
针对恶意客户节点
可能会提出恶意的update请求
设置一个权限函数，可以规定某个用户节点的相应权限（query、update等等），如果一个用户节点出现恶意行为，其他节点可以共同取消该结点的权限（由智能合约来实现，文中没有详细说明）
数据模型
数据具有VF和VT两个属性
块高为h时，只有$VF\le h$以及$VT\ge h$的数据是有效数据
数据操作包括：
- insert：VF=h，VT为无穷
- delete：VT=h
- update(=delete+insert)
数据库中的查询操作
FalconDB支持的查询类型受到所使用的ADS的约束。
客户端最多用两个谓词包装每个查询。
数据库中的写入操作
验证过程
- 用户提交操作请求后，服务端检查用户是否具有该权限，然后使用UpdC和UpdS函数对本地数据进行更新，用户会得到一个新的digest值
- 服务端根据更新后的数据提出一个新块，将新块和操作记录以及digest中间值一起发送给其他节点进行共识
- 其他节点收到后，首先检查用户是否有该权利，然后通过操作记录进行复现并与digest中间值进行比对
- 该块通过共识被接受后上链，其他节点更新本地数据
数据库中的事务
ACID(atomicity, consistency, isolation and durability)
- 原子性和持久性由区块链保证
- 独立性：OCC
- 提出更新操作时，需要给出基于哪个块进行修改（块高h），h作为read timestamp i
- 提交操作时，当前块高作为commit timestamp j
- 验证时需要检查块i+1到块j-1之间是否存在跟该操作矛盾的操作，如果存在则中止该操作
- 为了让用户节点也能够检查冲突情况，服务端在发送新块的同时也发送新块中数据相关的块中的读写操作集合，用户收到后在本地也进行OCC验证
- 一致性由ADS保证
