FISCO BCOS分布式存储

一丶Merkle Tree 与MPT

1.数据存储两大要素

• 数据组织方式：MPTState StorageState
• 存储引擎选择: NoSQL SQL

2.从Merkle树说起

• Merkle tree是一种树，大多数是二叉树，也可以多叉树，无论几叉树，他都具有树结构的所有特点
• Merkle tree 叶子结点的value是数据项的内容，或者是数据项的哈希值
• 非叶子节点的value根据其子节点的信息，然后按照Hash算法计算而得出的

若两颗树的根哈希一致，则这两颗树的结构，节点的内容必然相同（数据指纹）

Merkle Tree 的优势：
快速重哈希（验证）
Merkle tree 的特点之一就是当树节点内容发生变化时，能够在前一次哈希计算的基础上，仅仅将被修改的树节点进行哈希重计算，便能得到一个新的根哈希用来代表整棵树的状态
轻节点扩展（计算）
采用Merkle tree ，可以在公链环境下扩展一种“轻节点”，轻节点的特点是对于每个区块，仅仅需要存储约80个字节大小的区块头数据，而不存储交易列表，回执列表等数据，然而通过轻节点，可以实现在非信任的公链环境中验证某一笔交易是否被收录在区块链账本的功能。这使得像比特币，以太坊这样的区块链能够运行在个人PC，智能手机等拥有小存储量的终端上

劣势：
存储开销太大

3.压缩前缀树 Patricia Tree

字谜游戏
在压缩前缀树（基数数）中，健值是通过树达到相应值的实际路径值

4.以太坊 vs 比特币，Merkle Tree => Merkle Patricia Tree

比特币使用的是UTXO模型，存储开销更小
以太坊使用的是账户模型，在账户模型中，账户存在多个属性（余额，代码，存储信息），属性（状态）需要经常更新，在账户量剧增的情况下，存储开销剧增
因此，导致了以太坊需要这样一种结构：

1. 在执行插入，修改或者删除操作后能快速计算新的树根，而无需重新计算整个树（Merkle Tree）
2. 即使攻击者故意构造非常深的树，他的深度也是有限的，否则，攻击者可以通过特易构造足够深的树使得每次树的更新变得极慢，从而执行拒绝服务攻击
3. 树的根值仅取决于数据，而不取决于更新的顺序，以不同的顺序更新，甚至是从头重新计算树都不会改变树的根值（Tries树）

5.MPT = Merkle Tree + Patricia tree

以太坊的全局状态数据，保存在MPT树中，状态数据由账号组成，账号在MPT中是一个叶子结点，数据账号包括Nonce,Balance,CodeHash和StorageRoot，任意一个账号字段发生变化时，会导致该账号所在的叶子的HASH发生变化，从该叶子直到顶部的所有叶子的HASH都会变化，最后导致顶部的StateRoot变化
由此可见，任何账户的任意字段变化，都会导致StateRoot的变化，StateRoot能唯一标识以太坊的全局状态
在性能方面，MPT State 存在着天然的劣势，可以说，MPT State追求极致的可证明性和可追溯性，对性能可扩展性做了一定的妥协

6.数据组织方式

MPTState & StorageState
对区块链世界状态（world state）的描述，记录了链及所有账户的信息
MPTState

• 以太坊经典的数据组织方式，FISCO BCOS1.0使用

• 记录历史状态，实现数据溯源

• StorageState FISCO BCOS2.0提出并实现

• 抛弃账户数据的历史状态，只记录最新状态

• 基于“主Key+块高”记录，任可具备溯源条件

7.StorageState vs MPTState

StorageState

• 支持多种数据库
• 性能更优（RocksDB）
• 无限扩容（MySQL）
• 数据可视化更好
  MPTState
• 存储历史数据
• 天然具备可追溯性

二丶分布式存储

1.分布式存储的优点

• 支持多种存储引擎，选用高可用的分布式存储系统，可以支持数据简便快速的扩容
• 将计算和数据隔离，节点故障不会导致数据异常
• 数据在远端存储，数据可以在更安全的隔离区存储，这在很多场景中非常有意义
• 分布式存储不仅支持Key-Value形式，还支持SQL方法，使得业务开发更为简便
• 世界状态的存储从原来的MPT存储结构转为分布式存储，避免了世界状态急剧膨胀导致性能下降的问题
• 优化了数据存储的结构，更节约存储空间

2.存储引擎选择

NOSQL vs SQL
SQL优点
采用二维表格的关系模型来组织数据的数据库，其以行和列的形式，存储数据

• 数据可视化程度高
• 可实现复杂查询
• 提供事务支持

NoSQL
非关系的，强调Key-Value的数据库

• 性能高，健值对数据不需经过解析
• 可扩展性强，健值对数据不存在耦合，容易水平扩展
• 支持存储多种数据格式

3.概述

分布式存储 AMDB（Advanced Mass Database）
特性

• 实现对区块链底层存储模型的抽象## 标题
• 实现对不同数据库的存储驱动，理论上可以支持SQL和NoSQL的数据库
• 既可以对应到关系型数据库的表，也可以拆分使用KV数据库进行存储
  存储内容
• 存储所有的区块数据及CRUD数据
• 存储StorageState下的合约数据

4.架构

5.存储模型性能对比

• 分布式存储的数据请求不经过MPT，直接访问存储，提高读写速度
• 引入缓存机制CachedStorage，提升读写速度
• MySQL存储下性能衰弱缓慢，支持集群，分库分表等平行扩展方式
  理论上存储容量无限

6.名字解释：

Key

• AMDB的主Key和MySQL的主Key不同
• 用于标示Entry归属
• 可重复，非联合主Key

Table

• 存储MySQL表中的所有数据
• Table中存储主Key到对应Entriles的映射
• 基于主Key进行增删改查，支持条件查询
• AMDB的Table与MySQL的表不同

Entries

• 存放主Key相同的Entry

Entry

• 对应于MySQL表中的每一行
• 每行以列作为Key，列值作为Value，KV结构列表，具备可扩展性
• 每个Entry拥有AMDB主Key

Condition

• AMDB删改查接口条件，如条件为空，不做筛选
• Condition与AMDB的主Key共同起作用，相当于MySQL的联合主Key

7.分布式实操

通过控制台console部署调用Table合约