腾讯十年老兵：区块链本质上是一个异地多活的分布式数据库

区块链前哨导读：本文整理自 9 月 8 日“腾讯技术工程—区块链技术沙龙”上的演讲。

讲师介绍：潘安群，腾讯 TEG 计费平台部账户中心总监，专家工程师；中国计算机学会 CCF 区块链专业委员会委员；有近 10 年分布式存储研发经验，目前负责分布式 Cache 系统厚德（Hold）、分布式数据库 TDSQL，以及腾讯云区块链 TBaaS 平台的技术研发工作。

本文主要有四个部分的内容：

• 从分布式数据库角度看区块链
• 腾讯云区块链服务 TBaaS 技术介绍
• 智能合约开发及示例
• 快速部署及运营配套

1. 从分布式数据库角度看区块链

区块链是源于比特币中的底层技术，用于实现一个无中心的点对点现金系统，因为没有权威中心机构的参与，比特币以区块链的形式来组织交易数据，防止“双花”，达成交易共识。

传统意义上的数字资产，比如游戏币，是以集中式的方式管理的，仅能在单个系统中流转，由某个中心化机构负责协调，通常以数据库的方式来存储。宏观上看，区块链和数据库一样，都是用来保存数据，只是数据存取的形式有所不同。

区块链本质上是一个异地多活的分布式数据库。异地多活的提出，原本是为了在解决系统的容灾问题，多年来也一直是分布式数据库领域在探索的方向，但鲜有成效，因为异地多活需要解决数据冲突的问题，这个问题其实不好解决。然而诞生于比特币的区块链以一种全新的方式实现了全球最大的异地多活数据库，它完全开放，没有边界，支持上万节点并可随机的加入和退出。

在区块链中数据冲突问题就更加突出了，区块链里每个节点是完全对等的多活架构，上万个节点要达成一致，数据以谁为准呢？比特币采用的方式是 POW，大家来算一个谜题，谁先算出来，就拥有记账权，在这个周期，就以他所记的账为准，下一个周期大家重新计算。争夺记账权的节点决定将哪些交易打包进区块，并将区块同步给其他节点，其他节点仍然需要基于本地数据对区块中的交易做验证，并不像数据库的主从节点间那样无条件接受，这就是区块链里的共识算法。POW 虽然消耗大量算力，好处是在争夺记账权的过程中 POW 只要在自身节点中计算 hash，不需要经过网络投票来选举，网络通信的代价小，适合大规模节点之间共识。POW 是目前公有链里最完备最简单最粗暴做法，最经得起考验，但问题是效率太低。

所以后面发展出了 PoS、DPoS，谁拥有资产最多，谁就拥有记账权，或者大家投票，但这样又引入了经济学方面的问题，比如所谓的贿选的问题，这就不太好控制了。在传统分布式数据库里，不叫共识算法，而叫一致性算法，本质上也是一回事。但分布式数据库里一般节点数都很少，而且网络是可信的，通常节点都是安全可靠的，我们基本上可以相信每一个节点，即使它出现故障，不给应答，但绝对不会给出假应答。所以在传统公司分布式数据里，都用 Raft 或 Paxos 协议去做这种一致性算法。

后来产生了联盟链，若干企业组成一个联盟，加入联盟的组织或机构需要进行身份认证，基本上能够确认它们的身份是可信的。所以联盟链跟公有链的共识算法是不太一样的，联盟链主要采用 PBFT 或更简单的 Raft。

以太坊提出了智能合约的概念，可以实现各种逻辑, 而在分布式数据库中可以利用存储过程来实现类似功能。

区块链在解决横向扩展问题上，可以采取分片 / 跨链等方式，和分布式数据库里中的 Auto-Sharding 技术类似, 在处理过程中，都需要保证事务的完整性。

整体从纯技术角度来看，本质上区块链跟分布式数据库没什么太大的区别。但他们的路线，或者要解决的问题是不一样的，区块链侧重于抵御审查和安全性，而分布式数据库侧重于用户体验和性能效率。

产品上来看二者的侧重点有着显著的不同。抵御审查是以比特币为代表的区块链最重要的特性，也是比特币赖以生存的基础，因为比特币不属于任何人或组织，没有谁能代表比特币，比特币没有主体，所以各国政府或权威部门都无法关停比特币。然后是安全性，区块链账本有成千上万份副本分散在全球各地，数据几乎永不丢失，同时利用所有节点的相互制约，没人能够恶意篡改数据。这两者是区块链的重心，表现出来就是大家常说的去中心化。

用户体验和性能相对于前两个核心目标来说，不是区块链最侧重的，比特币动用巨大的算力来运行秒只有几个 TPS 的系统，数据冗余了上万份副本，一笔交易可能需要数十分钟才能提交，提交后的交易还可能因为被判定为“双花”而取消，而这些问题在数据库上都是不能接受的。二者产品上的侧重点不同，从而导致技术实现上的差异.

2. 腾讯云区块链服务 TBaaS 技术介绍

该架构有以下几个主要模块：

• 成员管理，要对成员有准入的控制，提供身份保证、内容保密、交易审计等功能
• 区块的服务，要有一些底层基础的服务、共识算法和 P2P 的通讯协议，用于维护分布式账本
• 页面封装，提供 RESTFul API 来访问各种服务，提供 CLI 客户端工具，使开发人员能够快速测试账链代码
• 账链代码，用于构成智能合同，它嵌在交易中，所有确认节点确认交易前都必须执行它

在 Fabric 架构中拆分了几个模块，最重要的是 Peer 和 Orderer， Order 主要处理共识过程，而其他所有业务逻辑是在 peer 执行。

在部署方面的话，是按照不同的组织部署自己的环境，然后通过共识网络组合成联盟链。Fabric 支持共识算法、身份认证和加密算法的插件化，背书和验证程序的插件化，以及可配置 state 数据库。

不同场景不同行业对区块链的需求不同，侧重点不同，如共识算法、安全级别、加密算法、账户模型等，作为一个 BaaS 平台，需要支持模块插件式的架构设计以应对行业的不同需求，TBaaS 基于 fabric 开发。

共识算法: 基于 kafka-zookeeper, raft，pbft。

身份认证 是联盟链重要的部分，用来区分不同的联盟成员，实现不同类型的权限控制（channel 的创建，修改，chaincode 的读写权限等）。

通用的 编程语言 可以方便区块链与链外系统的交互（有限制，链外数据经常变化，会导致不同 peer 读到不同的结果）。智能合约语言方面，我们支持通用的 golang、JS、Java。私有数据隔离保护：私有数据不公开在链上账本中，仅公开私有数据的 hash，私有数据通过 gossip 协议点对点传递到指定节点。安全隐私方面，支持硬件加密机，支持国密算法，在多链设计上做了数据的物理隔离，私有数据也做了隔离保护。

TBaaS 逻辑上分成三个组件：背书节点，共识节点，验证节点，其中背书节点是验证节点的一个子集。

交易依次在三个组件上执行，采用三阶段的交易流程：执行合约—打包区块—交易验证。

Execute：背书节点模拟合约执行，执行成功后对结果签名背书， 背书策略就是定义什么样背书节点的组合是有效的背书。

Order：共识节点对背书后的交易打包成区块，生成全局交易序列。

Validate: 验证节点验证区块生成者的签名，验证交易发起者的签名，验证背书策略是否符合，验证数据版本号等，验证通过后最终提交到账本。

把背书节点从验证节点中分离，方便设置灵活的背书策略，不需要每个节点都参与背书，联盟中有权威的机构可参与背书，只有背书节点才需要查看合约，便于保护合约的隐私。

把共识节点从验证节点中分离，是为了更好的可扩展性，不需要全部节点都参与共识，否则联盟中节点数过多，会导致共识代价过大（pbft 需要大量的节点间通信来达成共识）。

如果全节点参与智能合约的执行，全节点参与共识，就类似以太坊等公有链行为，采用三阶段方式是出于灵活性、可扩展性、隐私等方面考虑。

在最后的验证阶段, 有大量的加解密计算和 IO 操作，容易形成性能瓶颈。区块的计算是有顺序的，是串行的过程。所以我们把验证与提交阶段拆成了五个阶段，像流水线的方式去执行。

Pipeline 方案保证交易顺序全局一致的情况下，可以将区块提交分成 N 个阶段，每阶段可并行执行，区块间的处理顺序不变，但同一时刻最多有 N 个区块并行，交易吞吐量最高可提升 N 倍并发必然引入数据竞争，比如某一数据在相邻两个区块中执行先读后写，在不同节点的执行环境中，多线程的执行时序存在差异，有可能部分节点读到新版本，部分读到旧版本（mvcc 冲突），同时还有幻读等一系列数据库常见问题。

通过预处理方式，可以让每个节点在执行到 pipeline 的同一阶段时能看到同样的数据视图

3. 智能合约开发及示例

这是我们跟合作伙伴做的一个通兑积分的产品。现在很多机构都有自己的积分，但数量少的话没什么用，我们想把这些积分能够整合起来，做到通兑积分，解决积分的出口问题。

1. 银行 1 与银行 n 分别对用户 a 和 b 记录初始积分。
2. 调用智能合约，a 给 b 转账 10；
3. 调用查询合约查询积分。

4. 快速部署及运营配套

做联盟链，配套设施很重要。因为面对的是银行客户，或者是企业级客户，需要给他们提供完整的配套设施, 比如说 IDE、监控, 这些技术难度虽然不是特别大，但是必须要做到配套完善。

5. 答疑：

问：我看到一组数据，比特币弱中心化趋势越来越明显。比如，全球有 77% 的算力都掌握在中国，从某种意义上来说的话，看上去好像比 dpos 更集中化了。您是怎么看的？

答：就目前来看，整体虽然越来越集中，但还算可控，因为 POW 是一个纯粹的计算问题。它的设计初衷假定人是独立的。如果你控制整个计算，损害了其他人的利益的，别人就会逃离这个平台，你也不会获得收益。