区块链和数据库：致虚极，守静笃

新闻 2018年10月31日
1.59W 0
从数据一致性的角度来说，数据库也是区块链在特殊场景下的一个特例。

如果说牛顿的经典物理是爱因斯坦相对论在低速环境下的一种体现的话，我们所熟知的数据库技术，可以认为是区块链技术在弱分布式环境下的一个特例。

区块链和数据库：致虚极，守静笃

「弱分布式」环境是我胡扯的一个词，你可以将其理解为节点数量极其有限，运行环境高度可控的一种分布式环境。一个数据库集群运行在同一数据中心，或者不同数据中心，只要是同一个管理者，那么这就是可控的运行环境。在可控的运行环境下，默认不存在「作恶」的节点，也就无所谓 BFT（Byzantine Fault Tolerance），因此我们不需要复杂的共识算法（consensus algorithm），一般两阶段提交（two phase commit）或者 paxos / raft 就能收敛共识，满足需要。所以，数据库的共识算法是区块链共识算法的特例。

在区块链的世界里，交易（transaction）和交易产生的状态（state）是严格分离的。若干交易由被共识算法选择出来的矿工验证并打包成为区块（block）并广播出去，然后网络里其他参与者验证区块中每个交易的合法性，并写入自己的 state db。在 bitcoin 里，state db 是 UTXO，在 ethereum 里，则是其 world state。

数据库的世界里仿佛没有类似于区块链的交易记录（数据库中的 transaction 是另一个概念），但仔细想想，它的交易历史其实就是 WAL（Write-Ahead Logging）。从外界接收到的请求，数据库会先将其写入 WAL，确保其进入持久化存储，才会往它自己的 “states” 里面写入。从这个角度，我们可以认为 WAL 里的每一个记录，就对应区块链里的一个交易，它是区块链交易的特例（当然你也可以 argue 两个 checkpoint 之间可以算作一个区块）。

如果你再认真思考一下，WAL，blockchain，以及 Martin Fowler 很早就提倡的 CQRS（Command Query Responsibility Segregation）在这个层面上其实都是「一中各表」：大家都强调「事件」和「状态」的分离，通过前一个状态 + 当前事件，可以推演出当前状态。这样，我们只要有一个初始的「状态」，然后记录系统发生过的所有的「事件」，就可以复原任意一个时刻的「状态」（如果你对 CQRS 感兴趣，不要错过我们明早的 arcblock tech learning series: CQRS & Commanded - hack.arcblock.io/learning）。

我们回到交易和容纳交易的「区块」。你会发现，「区块」是一个怪怪的存在，为什么数据库不需要「区块」这样的概念作为容器装载「交易」，而区块链却需要呢？我们知道，在区块链的世界里，不确定性和确定性仿佛一对孪生兄弟，确定的是规则，不确定的是规则的执行者。所谓矿工轮流做，下回到我家，那怎么定义一个「回合」呢？为了回答这个问题，我们需要某种机制明确一个回合矿工地位的起止 —— 这个起止就是一个「区块」。不仅如此，在一个物理时钟并不一致的分布式环境下，「区块」还承载着全局时钟的功能，滴答滴答将整个网络往前推进。「区块」的概念是如此重要，以至于它当仁不让地成为共识算法的基础 —— 大家先得对下一个要出的区块序号达成共识，否则这个游戏无法进行。反观数据库系统，在一个数据库集群中，master（等价于矿工）是固定的，master 令旗一挥，slave 就迅速跟进，指哪打哪，不存在轮流坐庄，也就无所谓回合，所以其实每个「交易」就是一个「区块」。所以在数据库的世界里，逻辑上每个交易，或者说 WAL 的每个记录，自成一个隐性的「区块」。

我们从另一个角度来探讨这个结论。「区块」的另一个重要的作用是 crash recovery。在一个区块链网路中，某个节点无论是断网还是崩溃，其状态和网络中达成共识的状态必不一致，那么，如何从这种不一致的状态恢复同步的状态呢？答案是「区块」，因为它是唯一明确的共识的产物。节点总是能够找到最近的 commit 的和网络中一致的区块高度，然后从这个高度往后一个区块一个区块同步，依次运行区块中包含的所有交易并更新本地的状态，最终可以保证和网络中的状态达成一致。在这里，「区块」就是检测和达成状态一致的最小单元。而在数据库系统中，在崩溃发生后，系统会从其他节点同步最新的 WAL，并从上次 commit 的 WAL 的位置往后一个记录一个记录执行命令，直到所有记录运行完毕，这时数据库状态恢复到集群的当前状态。在这里，WAL 的记录是检测和达成一致的最小单元，所以我们称其为隐性的「区块」，没毛病。

在区块链的世界里，一笔交易需要被验证。这里的验证有两重含义：1) 身份验证 —— 交易是由其发起人正确签名的；2) 完整性验证 —— 交易对状态的变更是合法的。身份验证好理解，你用自己钱包的私钥签名给我转 1 个 ABT 的交易，系统会验证你的确是你；完整性验证则是指在 states db 里，你的账号下的确有超过 1 个 ABT 的 token，才能发起这个交易。在数据库的世界里，身份验证直接赤果果用诸如 RBAC（Role Based Access Control）的访问控制系统解决了，而完整性验证和区块链类似。

接下来我们看看确定性（deterministic）。所谓确定性，就是在同一个状态 Sn-1 下，大家拿着同样一笔交易，不依赖任何第三方信息独立执行，执行的结果完全一致。这一点仅就纯粹的从交易到 states db 的处理来说，区块链和数据库是完全一致的，大家都能保证确定性。然而，如果某个区块链要支持交易中携带额外信息，这些信息触发某些链上部署好的代码的执行（比如说，smart contract），那么，我们就得注意代码本身需要具备确定性。所谓确定性，无非是：

  • 代码中不要使用不确定的随机数生成器 —— 比如使用计算机的时钟作为种子生成随机数，这就是不确定的。因为交易在被执行的那一刻，我们无法保证所有参与者的时钟是精确同步的。

  • 代码避免使用多线程。多线程引发的 race condition 具有不确定性。

  • 不要使用系统时钟。不解释。

  • 不要使用未初始化的内存。鬼知道上面是陈冠希还是诸子百家。

  • 不要使用浮点数 —— 这个很奇葩，因为不同的 CPU arch，编译器，甚至不同 CPU 型号间，由于支持的浮点数指令集不同，会导致结果不同。

  • 不要使用编程语言的可能有随机行为的数据结构。比如遍历一个 map

基本上避免了这些，代码就具备了确定性，可以在区块链上执行。那么，为什么数据库中的存储过程可以允许没有确定性的代码的执行？比如，一个存储过程里可以使用当前时间插入一条记录？我们如果再回归本源，从「交易」的角度看待问题，可以发现，存储过程类似于 “off-chain” 执行的代码，它虽然植根于数据库之中，但其实是「交易」的源头，存储过程的执行产生真正的交易，也就是 WAL 记录，然后同步给其它节点。所以存储过程可以 non-deterministic，因为其产生的 WAL 记录已经是 deterministic 的 —— 添加一条带当前时间的记录这件事情，在 master 执行时，已经将取「当前时间」这个动作完成并得到一个确定的值，携带于 WAL 之中。这跟区块链的 smart contract 的概念有本质的区别，这也是为什么存储过程可以不必具备确定性，而 “on-chain” 执行的 smart contract 需要确定性。从这个角度来讲，数据库系统也是一个弱化的区块链系统。

既然区块链和数据库存储的对象都是数据，那么，提过了数据的完整性和确定性，接下来就是数据的一致性。区块链显然是最终一致性的典范 —— 网络越大，参与的节点越多，区块的扩散就越慢，任何时刻在不同的节点上读取状态就很大几率出现不一致的情况。然而，只要节点能同步到最新的区块，整个网络的状态是收敛的，最终大家能够得到一个一致的状态数据。其实，按照这个道理，所有使用 WAL，CQRS 思想的分布式系统，其数据的状态都是最终一致的 —— 这似乎和我们对经典数据库强一致性的印象不匹配。然而，如果我们把视角拉到数据库内部，可以发现，强一致性只不过是最终一致性之上添加了一些条件，是个特例。如果我们假定一个区块链满足下面的条件：

  1. 任何节点收到新的区块，必须在交易执行完成，写入 states db 中之后，给矿工节点（其实就是当前的 master）发送确认

  2. 矿工节点在收到所有确认之后广播给网络中所有节点这个区块大家已经 commit 成功

  3. 在一个区块没有收到矿工节点的上述广播之前（写入完成之前），客户端发送来的查询进入队列排队（其实就是 read-write lock）

那么在外界看来，它也是强一致性。当然，第三点有些过于苛刻，一般的数据库实现都会采用 MVCC（Multiversion concurrency control），让每个 client 看到当前状态的一个 snapshot，因而存在一个很小的窗口，大家看到的数据是不一致的。如果较真，MVCC 不算强一致性，当然没人会这么认为。

通过上面的规则，数据库可以通过牺牲一些性能来打造对外而言的强一致性。但有时候，为了一些崇(wo)高(chuo)的理想，数据库系统也可以打破这些规则来号称更高的性能。mongdb 可以在 cluster 的环境下，写操作不需要节点确认即可返回，于是有了美其名曰的，如薛定谔的猫一般的「弱一致性」。

一个区块链网络理论上可以通过上述规则把自己营造成对外强一致性的感觉，但这实际上没有可操作性。能力越大，责任越大网络越大，延迟越大，所以，实际可操作的强一致性只能发生在节点数量很少，且节点都在同一个 data center 的环境下。从数据一致性的角度来说，数据库也是区块链在特殊场景下的一个特例。

最后说说性能。性能这事，和网络规模成反比。两个主要原因：1) 节点越多，达成共识的难度就越大。2) 节点越多，「交易」在网络中传播所需的时间就越长。那想要达到宇宙无敌的 TPS（Transactions Per Second） 怎么办？其实不难 —— 既然数据库是一个弱分布式环境下的特例，那么，咱就把区块链往数据库的方向退化就好。PoW 说「王侯将相，宁有种乎」，让全网参与铁王座的竞争，PoS 就让「一小部分人先富起来」，DPoS 再进一步，「让领导先走」，也许不久的将来，有人会则憋出终极大招，全网就一个九五之尊，把数据库里能用的招数，replicaSet（总还得 HA 一下嘛），Sharding 等等统统用上，再使用兵法中不战而屈人之兵之术：「今治水军八十万众，方与将军会猎于吴」…于是，可以名正言顺地抢下性能的桂冠。

只不过…就像非诚勿扰里车晓问葛优：那事儿，就那么有意思吗？

作者： 陈小天

生成图片
♥赞4
数据库(2)

相关文章

发表评论

区块链和数据库：致虚极，守静笃

星期三 2018-10-31 14:04:02


如果说牛顿的经典物理是爱因斯坦相对论在低速环境下的一种体现的话，我们所熟知的数据库技术，可以认为是区块链技术在弱分布式环境下的一个特例。

区块链和数据库：致虚极，守静笃

「弱分布式」环境是我胡扯的一个词，你可以将其理解为节点数量极其有限，运行环境高度可控的一种分布式环境。一个数据库集群运行在同一数据中心，或者不同数据中心，只要是同一个管理者，那么这就是可控的运行环境。在可控的运行环境下，默认不存在「作恶」的节点，也就无所谓 BFT（Byzantine Fault Tolerance），因此我们不需要复杂的共识算法（consensus algorithm），一般两阶段提交（two phase commit）或者 paxos / raft 就能收敛共识，满足需要。所以，数据库的共识算法是区块链共识算法的特例。

在区块链的世界里，交易（transaction）和交易产生的状态（state）是严格分离的。若干交易由被共识算法选择出来的矿工验证并打包成为区块（block）并广播出去，然后网络里其他参与者验证区块中每个交易的合法性，并写入自己的 state db。在 bitcoin 里，state db 是 UTXO，在 ethereum 里，则是其 world state。

数据库的世界里仿佛没有类似于区块链的交易记录（数据库中的 transaction 是另一个概念），但仔细想想，它的交易历史其实就是 WAL（Write-Ahead Logging）。从外界接收到的请求，数据库会先将其写入 WAL，确保其进入持久化存储，才会往它自己的 “states” 里面写入。从这个角度，我们可以认为 WAL 里的每一个记录，就对应区块链里的一个交易，它是区块链交易的特例（当然你也可以 argue 两个 checkpoint 之间可以算作一个区块）。

如果你再认真思考一下，WAL，blockchain，以及 Martin Fowler 很早就提倡的 CQRS（Command Query Responsibility Segregation）在这个层面上其实都是「一中各表」：大家都强调「事件」和「状态」的分离，通过前一个状态 + 当前事件，可以推演出当前状态。这样，我们只要有一个初始的「状态」，然后记录系统发生过的所有的「事件」，就可以复原任意一个时刻的「状态」（如果你对 CQRS 感兴趣，不要错过我们明早的 arcblock tech learning series: CQRS & Commanded - hack.arcblock.io/learning）。

我们回到交易和容纳交易的「区块」。你会发现，「区块」是一个怪怪的存在，为什么数据库不需要「区块」这样的概念作为容器装载「交易」，而区块链却需要呢？我们知道，在区块链的世界里，不确定性和确定性仿佛一对孪生兄弟，确定的是规则，不确定的是规则的执行者。所谓矿工轮流做，下回到我家，那怎么定义一个「回合」呢？为了回答这个问题，我们需要某种机制明确一个回合矿工地位的起止 —— 这个起止就是一个「区块」。不仅如此，在一个物理时钟并不一致的分布式环境下，「区块」还承载着全局时钟的功能，滴答滴答将整个网络往前推进。「区块」的概念是如此重要，以至于它当仁不让地成为共识算法的基础 —— 大家先得对下一个要出的区块序号达成共识，否则这个游戏无法进行。反观数据库系统，在一个数据库集群中，master（等价于矿工）是固定的，master 令旗一挥，slave 就迅速跟进，指哪打哪，不存在轮流坐庄，也就无所谓回合，所以其实每个「交易」就是一个「区块」。所以在数据库的世界里，逻辑上每个交易，或者说 WAL 的每个记录，自成一个隐性的「区块」。

我们从另一个角度来探讨这个结论。「区块」的另一个重要的作用是 crash recovery。在一个区块链网路中，某个节点无论是断网还是崩溃，其状态和网络中达成共识的状态必不一致，那么，如何从这种不一致的状态恢复同步的状态呢？答案是「区块」，因为它是唯一明确的共识的产物。节点总是能够找到最近的 commit 的和网络中一致的区块高度，然后从这个高度往后一个区块一个区块同步，依次运行区块中包含的所有交易并更新本地的状态，最终可以保证和网络中的状态达成一致。在这里，「区块」就是检测和达成状态一致的最小单元。而在数据库系统中，在崩溃发生后，系统会从其他节点同步最新的 WAL，并从上次 commit 的 WAL 的位置往后一个记录一个记录执行命令，直到所有记录运行完毕，这时数据库状态恢复到集群的当前状态。在这里，WAL 的记录是检测和达成一致的最小单元，所以我们称其为隐性的「区块」，没毛病。

在区块链的世界里，一笔交易需要被验证。这里的验证有两重含义：1) 身份验证 —— 交易是由其发起人正确签名的；2) 完整性验证 —— 交易对状态的变更是合法的。身份验证好理解，你用自己钱包的私钥签名给我转 1 个 ABT 的交易，系统会验证你的确是你；完整性验证则是指在 states db 里，你的账号下的确有超过 1 个 ABT 的 token，才能发起这个交易。在数据库的世界里，身份验证直接赤果果用诸如 RBAC（Role Based Access Control）的访问控制系统解决了，而完整性验证和区块链类似。

接下来我们看看确定性（deterministic）。所谓确定性，就是在同一个状态 Sn-1 下，大家拿着同样一笔交易，不依赖任何第三方信息独立执行，执行的结果完全一致。这一点仅就纯粹的从交易到 states db 的处理来说，区块链和数据库是完全一致的，大家都能保证确定性。然而，如果某个区块链要支持交易中携带额外信息，这些信息触发某些链上部署好的代码的执行（比如说，smart contract），那么，我们就得注意代码本身需要具备确定性。所谓确定性，无非是：

  • 代码中不要使用不确定的随机数生成器 —— 比如使用计算机的时钟作为种子生成随机数，这就是不确定的。因为交易在被执行的那一刻，我们无法保证所有参与者的时钟是精确同步的。

  • 代码避免使用多线程。多线程引发的 race condition 具有不确定性。

  • 不要使用系统时钟。不解释。

  • 不要使用未初始化的内存。鬼知道上面是陈冠希还是诸子百家。

  • 不要使用浮点数 —— 这个很奇葩，因为不同的 CPU arch，编译器，甚至不同 CPU 型号间，由于支持的浮点数指令集不同，会导致结果不同。

  • 不要使用编程语言的可能有随机行为的数据结构。比如遍历一个 map

基本上避免了这些，代码就具备了确定性，可以在区块链上执行。那么，为什么数据库中的存储过程可以允许没有确定性的代码的执行？比如，一个存储过程里可以使用当前时间插入一条记录？我们如果再回归本源，从「交易」的角度看待问题，可以发现，存储过程类似于 “off-chain” 执行的代码，它虽然植根于数据库之中，但其实是「交易」的源头，存储过程的执行产生真正的交易，也就是 WAL 记录，然后同步给其它节点。所以存储过程可以 non-deterministic，因为其产生的 WAL 记录已经是 deterministic 的 —— 添加一条带当前时间的记录这件事情，在 master 执行时，已经将取「当前时间」这个动作完成并得到一个确定的值，携带于 WAL 之中。这跟区块链的 smart contract 的概念有本质的区别，这也是为什么存储过程可以不必具备确定性，而 “on-chain” 执行的 smart contract 需要确定性。从这个角度来讲，数据库系统也是一个弱化的区块链系统。

既然区块链和数据库存储的对象都是数据，那么，提过了数据的完整性和确定性，接下来就是数据的一致性。区块链显然是最终一致性的典范 —— 网络越大，参与的节点越多，区块的扩散就越慢，任何时刻在不同的节点上读取状态就很大几率出现不一致的情况。然而，只要节点能同步到最新的区块，整个网络的状态是收敛的，最终大家能够得到一个一致的状态数据。其实，按照这个道理，所有使用 WAL，CQRS 思想的分布式系统，其数据的状态都是最终一致的 —— 这似乎和我们对经典数据库强一致性的印象不匹配。然而，如果我们把视角拉到数据库内部，可以发现，强一致性只不过是最终一致性之上添加了一些条件，是个特例。如果我们假定一个区块链满足下面的条件：

  1. 任何节点收到新的区块，必须在交易执行完成，写入 states db 中之后，给矿工节点（其实就是当前的 master）发送确认

  2. 矿工节点在收到所有确认之后广播给网络中所有节点这个区块大家已经 commit 成功

  3. 在一个区块没有收到矿工节点的上述广播之前（写入完成之前），客户端发送来的查询进入队列排队（其实就是 read-write lock）

那么在外界看来，它也是强一致性。当然，第三点有些过于苛刻，一般的数据库实现都会采用 MVCC（Multiversion concurrency control），让每个 client 看到当前状态的一个 snapshot，因而存在一个很小的窗口，大家看到的数据是不一致的。如果较真，MVCC 不算强一致性，当然没人会这么认为。

通过上面的规则，数据库可以通过牺牲一些性能来打造对外而言的强一致性。但有时候，为了一些崇(wo)高(chuo)的理想，数据库系统也可以打破这些规则来号称更高的性能。mongdb 可以在 cluster 的环境下，写操作不需要节点确认即可返回，于是有了美其名曰的，如薛定谔的猫一般的「弱一致性」。

一个区块链网络理论上可以通过上述规则把自己营造成对外强一致性的感觉，但这实际上没有可操作性。能力越大，责任越大网络越大，延迟越大，所以，实际可操作的强一致性只能发生在节点数量很少，且节点都在同一个 data center 的环境下。从数据一致性的角度来说，数据库也是区块链在特殊场景下的一个特例。

最后说说性能。性能这事，和网络规模成反比。两个主要原因：1) 节点越多，达成共识的难度就越大。2) 节点越多，「交易」在网络中传播所需的时间就越长。那想要达到宇宙无敌的 TPS（Transactions Per Second） 怎么办？其实不难 —— 既然数据库是一个弱分布式环境下的特例，那么，咱就把区块链往数据库的方向退化就好。PoW 说「王侯将相，宁有种乎」，让全网参与铁王座的竞争，PoS 就让「一小部分人先富起来」，DPoS 再进一步，「让领导先走」，也许不久的将来，有人会则憋出终极大招，全网就一个九五之尊，把数据库里能用的招数，replicaSet（总还得 HA 一下嘛），Sharding 等等统统用上，再使用兵法中不战而屈人之兵之术：「今治水军八十万众，方与将军会猎于吴」…于是，可以名正言顺地抢下性能的桂冠。

只不过…就像非诚勿扰里车晓问葛优：那事儿，就那么有意思吗？

作者： 陈小天