腾讯云高可扩展性区块链平台原理剖析

导语 | 随着产业互联网加速推进，区块链技术越来越受到重视。然而，区块链平台的构建也面临着问题：成千上万的数据中心有各自的数据管理模式，单个区块链应用既承载不了大规模的数据量，也不能满足多样化的数据管理模式。本文是对腾讯云区块链专家工程师刘长辉老师在「腾讯云开发者社区沙龙online」的分享整理，希望与大家一起交流。

一、新基建下的区块链

区块链集成了密码学、分布式数据库的技术，能够有效并且安全的实现跨组织的数据共享的协作，以发挥在新基建中的作用。

而新基建下的区块链，有以下四个特征：

• 范围广，分区治理，跨链互联
• 层级化治理，满足现有治理体系
• 统一的实名身份，按身份授权
• 支持敏感数据的跨链传输

首先是服务范围更加广。不再像之前几年只是少数几个企业联盟搭建了一个信息化的设施，所以就要求能够进行分区的治理，各个区域、业务可以建设相对独立的区块链，同时又支持与其他不同地域、业务的区块链进行跨链协作。

第二个特征是层级化的治理。区块链在新基建场景下，节点并不是完全对等的，是有层级的，以满足政府或者是企业现有的治理体系。

第三是身份实名。最好是有统一的身份系统，类似于全国统一的身份证，即便是在跨地域或者是跨业务的时候，也可以按身份进行授权与验证。

第四个特征是要支持敏感数据的跨链传输。我们在保障数据跨机构共享的同时，还要保护数据的隐私。

下面举个例子说明一下新基建的区块链应用场景到底是怎么样的。

在教育领域中，可以使用区块链来管理学生的学籍、档案，这些是需要长期去管理的重要数据，保证其不可以后续被篡改，保证数据是可以追溯的。通常不同的省市都会有自己的区块链系统来维护其当地的数据，但如果学生升学或者是转学，就会涉及到跨区块链的数据流转。

在政务领域也有很多这样的例子，比如户口的迁移或者社保的转移，都涉及到跨地域的数据流通，也会有很多跨业务的信息协作场景。

总之，会存在很多按区域或者业务划分的分区的链，这就涉及到跨链的协作。

二、如何构建高可扩展的区块链平台

一个区块链的内部数据是可以做到不可篡改，变更过程可追溯的。但在涉及到跨区块链的环节，分区的链之间互相平行，不能够验证对方的数据是否可靠。

在这种情况下为了保障区块链的基本特性，就需要引入一个跨链治理的平台。它的功能包括跨链的身份管理以及跨链的事务管理。

既然区块链被拉入到新基建的场景当中，就会要求区块链能够服务更广的使用户群体、管理更多的数据，这些最终都会归结于区块链能否实现更高的可扩展。

目前区块链在扩展性上所面临的的问题主要有三点：

• 单个区块链承载的数据量有限
• 单个区块链不能满足不同业务的数据管理模式
• 平行业务、地域、部门组建的区块链相对独立，但又有协作要求

区块链为了追求去中心化以及数据的不可篡改、可追溯等特性，付出的成本与代价远比我们通常使用的数据库要高。所以用单个区块链承载整个产业互联网的数据是不现实的。

第二点在产业区块链里面各种各样的业务会有不同的管理模式，比如不同的共识机制以及策略，这种情况下把不同的业务全部落在同一个区块链里面也是不现实的。

第三个问题就是每个区域、业务都会构建自己的区块链。比如各个城市会有自己独立的区块链，但又涉及到跨地域、跨业务的协作，这也是扩展性的一个大问题。

针对这些问题，目前的解决方案是通过跨链去解决区块链的水平扩展问题，再通过分层解决跨链的效率监管。

三、区块链去中心化与效率的权衡

1. 分层治理

因为区块链强调去中心化，所以就要求各个参与方之间要相互进行验证。在产业互联网的场景中，因为数据量规模很大，不同业务、不同地域的链之间是互相平行平等的，没办法去验证其他业务链的数据是否正确，所以就有了分层的概念。

层级化的治理模式可以提升效率，并且可以满足监管的要求。这一点和我们的整个社会机制是相似的，包括政府、企业都是层级化管理。

分层之所以能够提升区块链的效率，是因为分层相当于牺牲了一部分去中心化的特性。如果不进行分层，整个区块链就是一个完全扁平的结构，就像大家熟知的公有链，每个节点都是对等的。做一次共识需要所有人来进行投票或者竞争，共识的节点就会非常多。如果我们把区块链变成层次化，就可以让共识的范围限制在一小部分节点当中，共识的规模就会小很多。

比如在比特币中，为了提升比特币应用的效率，会在比特币上构建第二层的网络，这也是分层的一个思路。

腾讯云区块链的分层方案在系统上主要分为两个大的层面，上面是应用层，下面是治理层。

（1） 应用层

应用层可以构建大量平行的应用子链，应用子链可以实现不同的业务，也可以用不同的治理模式。子链只需要聚焦于自己的区块链应用，并提供相关的 API 就可以，不需要关心复杂的跨链流程如何实现，也不需要关心和其他链互相通信的时候应该如何实现，因为跨链的流程是由治理层负责实现的。

（2）治理层

治理层为应用层的跨链协作或者是数据流通提供了底层的支持，功能主要分成两部分：跨链的事务管理和跨链的身份管理。

跨链的事务管理需要管理一笔交易在多个不同的链之间的执行状态，以保证数据的一致性。也就是说交易在多个区块链上要么全部执行成功，要么全部都失败，从而确保数据的一致性。

和传统的分布式事务不同的一点，跨链事务处理的过程需要保证去中心化，因为是基于区块链来管理事务，所以称为事务链。

这里采用了两阶段的去中心化的跨链互操作是可以实现灵活的，并且可以大规模跨链互联的区块链系统。

最下面是跨链的身份管理，为区块链的上层应用提供一个可信的身份服务，我们称之为身份链，用于管理子链的身份以及用户的身份。

子链的身份就是上层应用子链的身份，应用子链如果需要与其他平行的子链进行跨链操作，必须先在身份链上注册自己的身份。这个身份中包含子链对外公开的一些资源管理 API，以便实现基于身份的服务发现。

所以身份链相当于一个公开的通讯录，管理了各类的身份信息。

身份信息包含两类，第一个是区块链应用的用户身份，身份链为上层的所有子链都颁发了一个统一的身份，从而使子链可以验证其他子链的用户身份。有了身份链，我们就可以打通数据的拥有者、管理者以及访问者不同权限间的验证流程，为安全的跨链互通提供了信任的基础。

在联盟链中，身份是信任的基石，基本上所有的授权验证都是基于身份实现，一个统一的身份系统是跨链的关键。

身份信息主要包含以下几类：

• 身份标识符(ID)：作为该身份的唯一识别码；
• 身份类型(Type)：分为个人、设备、机构、应用子链几大类；
• 身份公钥：该身份对应的非对称加密公钥，用于验签（私钥由身份拥有者私有）；
• 身份颁发签名：由签发机构/联盟对该身份的签名；
• 身份服务：记录该身份的服务地址、API 等信息，按身份类型不同可分为「机构与应用子链」和「个人」。 

这里面最关键的就是身份服务，它记录了身份关联的网络服务地址和 API 等信息。以个人身份为例，比如“我”现在在深圳，那么“我”的个人身份可能就是深圳某个应用链上对外的服务地址，把这些身份用区块链的形式进行管理，就形成了身份链。

身份链相当于提供了一个统一的身份，类似于现实中的身份证，可以为跨链提供身份的注册查询还有验证等功能。

有了身份链之后就可以走出跨链的第一步，基于身份的区块链服务发现。身份链作为公开透明的身份注册中心，提供对身份的信任背书，同时提供区块链服务发现功能。

因为我们的身份里面包括对外服务的 API。比如说我有一个区块链服务，我想提供我的服务就需要在区块链上注册我的身份，服务的调用者就可以在相关的链上查询到我的服务并且发起调用。

以查询某个个人数据为例。某个 APP 要使用某个个人 A 的身份去查询他在身份链上的身份服务，身份链就会返回个人的身份服务，也就是应用子链的身份 ID，APP 拿到应用子链的身份 ID 后再去区块链上查询链的身份服务，找到后就相当于找到了对外的网络服务地址，也就是查询 API 或者更新 API。这样 APP 就可以直接调用 API 访问应用链，发起对个人用户的数据查询或者更新操作。

应用子链也可以审核操作权限并执行，这就是服务发现的功能。有了服务发现后，可以实现跨链的查询。

2. 跨链查询

跨链查询只相当于跨链里面的一小步，那么如何通过身份服务去实现跨链查询？如图所示，图中共有四个角色

最底层是身份链，最上面是申请者 C 以及两条应用链 A 和 B。这个场景表示的是一个用户的数据托管在蓝色的区块链链 A 上，但现在用户要授权区块链 B 去查询其托管在 A 上的数据，这个场景中 A、B、C 都需要去身份链上查询对方的身份信息并验证对方的身份是否合法，以及请求或者授权的数字签名是否正确。查到对方的服务地址之后，身份链就可以直接按照身份链上的服务地址去访问对方。

通常来说身份链是由监管部门管理的，比如发现某个身份有问题后，监管部门可以对其进行冷冻，冻结之后身份信息就相当于失效了。

（1）预言机

这里有一个细节，比如应用链 B 要去查询身份链，他还要查询子链 A，就涉及到区块链的跨链查询功能。对于区块链来说，如果要查询一个链外的数据，目前来说是不太好实现的，对于外部数据来说，它的有效性无法进行验证，所以如果要查询外部数据，就要引入区块链的预言机功能，这也是区块链中比较新的技术方向。

预言机简单来讲就是区块链外的信息写入区块链内的一个机制。我们把区块链分为两类节点，一类是普通的区块链点，另一类是预言机的节点。

预言机节点里面内置了预言机的模块，当我们要访问链外数据时，通常是调用预言机的智能合约，让预言机去代理读取链外的数据写入到区块链，之后同步给其他的区块链节点。其他的节点会把这个数据写入到它的状态数据库中，随后这些普通的智能合约就可以使用这些链外的数据。

区块链不内置预言机的功能，原因是大部分的智能合约并不能直接访问外部的网络资源。有一些智能合约会采用通用的编程语言，比如 Java、GO，是可以调用网络接口访问外部的，但通常不用智能合约直接去调用外部接口，因为并不太规范。所以通常会从预言机来统一管理网络接口的调用，然后把外部的数据最终写入区块链。

用统一的方式管理一是比较规范，二是它能够把链外数据直接写到区块里，写入区块里后这个外部数据才是可以追溯的。

（2）预言机简化

这个流程比较复杂，对于联盟链来说有更简单的方案。因为联盟链的节点规模并不太多，所以可以简化智能合约的开发流程和部署的方式。

如下图所示就是把验证节点和预言机节点融合在一起，不会单独区分哪些是验证节点哪些是预言机节点，都是通用的区块链节点。智能合约也不会去区分预言机的智能合约和普通的智能合约，而是把它当成一份统一的智能合约，这样智能合约既可以像普通的智能合约一样去访问本地的状态数据库，也可以访问预言机模块。

智能合约的调用过程，也需要通过共识。整个数据流程简化，如从外部调用智能合约，然后在智能合约的执行过程中，如果碰到查询外部数据的指令，就会把指令发到预言机的模块上，预言机就会代理合约去外部查询数据，预言机得到外部数据后直接把数据返回给智能合约，智能合约就可以根据外部数据进行下一步的计算，把计算结果写入到状态数据库。最终智能合约的处理结果以及预言机获取的中间结果会被一起写入到区块链中。

（3） 预言机可信机制

这里有一个关键，在使用预言机后，要如何保证可信度？可信主要包含两个方面，一个是去中心化，一个是数据可验证。

去中心化就是可以部署多个不同组织的预言机节点，通过区块链的方式保证去中心化。比如超过 2/3 的预言机节点都返回同样的结果，我们就认为预言机获取的结果是可信的。预言机的合约跟普通的预言机合约已经融为一体，所以也是通过共识的。只是因为它读取的是链外的数据，所以本地没有办法对这个数据进行校验，要依赖于预言机节点做背书，这是和本地数据不一样的地方。

第二个是数据可验证，也就是要如何验证外部的数据是有效的。这个过程是预言机的链外数据也需要有其他节点验证和提交，并且一定要写入到区块文件里面。

链外的数据就需要规范它的数据格式，才能保证它是可验证的，第一就是链外的服务也要有身份，也就是证书，属于哪个机构或者哪个链，数据的路径访问的是哪一个，链外服务可能或提供 URL 之类。除了数据的原始内容还有数据的签名，链外服务的身份私钥对原始数据进行签名，通过这个方式，保证预言机的可信。

3. 跨链互操作

预言机只能解决读取链外数据的问题，但还有一个更复杂的就是跨链互操作。

跨链互操作不是简单的读取，而是意味着一笔交易可能同时要修改多个链上的数据，相对于跨链查询来说更为复杂。跨链互操作有三个挑战：

• 一致性
• 去中心化
• 跨链数据可验证

现有的分布式系统，解决一致性问题有比较成熟的方案，比如通过一个协调者来实现两阶段的提交。但问题在于区块链要求去中心化，就需要有多个协调者做公证人，把公证人集合做成一个联盟链，以联盟链的方式做公证人的协调。

第三就是跨链数据的可验证，对于区块链来说有一个非常重要的一点就是数据可验证，如果数据不可验证，就跟通常使用的数据库没有区别了。

比如说在使用数据库时，用客户端提交了一个请求，数据库返回给我们一个成功的响应。比如返回一个 OK，我们就认为这个数据在数据库里已经提交了，这种方式对于区块链来说是不可验证的，因为对区块链来说，它觉得这个数据是不可信的。

所以采用去中心化的、两阶段的提交方式实现跨链互操作，并且保证事务的一致性。

我们会从事务链里面选取多个节点作为一个公证人集合，公证人去协调不同的子链之间的互操作。为了保证跨链过程的可验证，公证人集合和子链之间需要相互验证。

相互验证包含两个部分，一个是公证人会发起一个提案，就是两边都按我的提案去做，所以这个提案要求可以验证。因为是公证人集合发起的，不是某一个公证人发起的，所以提案可验证是为了防止公证人作恶，需要两边的应用子链对公证人的提案有效性进行验证。

第二个方面就是提交的可验证。提交可验证是防止两边的应用子链作恶。它需要公证人集合去对应用子链交易的执行结果进行验证，要验证交易所在的区块有没有确定提交，有没有通过哈希的方式构成条链。

举个例子，从链 A 有一个用户要将 10 块钱转到链 B 上的某个用户，中间是一个公证人集合。如果要完成交易，首先由公证人集合发起提案，提案就是在左边这个链 A 减掉 10 块钱，右面的链 B 加上 10 块钱。发起的提案也是要在区块链上进行的，区块链 A 和 B 都要验证这个提案是否有效。

假如公证人作恶，给链 A 发起的提案是链 A 减掉 10 块钱，给 B 的提案是减掉 20 块钱，就会出问题。这就是公证人作恶的情况，所以需要公证人也要去中心化，也要通过区块链的方式来表决。另一方面就是公众人集合也要验证 A 和 B 是否真的提交了。

可验证要如何实现，就需要借助事务链。事务链是由公证人组成的联盟链，管理跨链事务状态、公开记录跨链凭证。跨链的凭证分为两部分，一个是应用子链的跨链凭证，另一个是公众人的跨链凭证。

子链的跨链凭证包括子链的元信息以及交易提交凭证，子链的元信息需要预先公开在事务链上。在跨链过程中，公证人要验证子链的区块以及子链的交易凭证是否满足子链的提交条件。公证人及公证人集合的跨链凭证，包括公证人提案的签名策略，以及提案的签名集合。

所以，需要公证人把提案集合事先要把已经约定好的提案写到事务链中。提案策略会规定一个有效的策略应该满足什么样的公证和条件，比如需要哪些公证人一起签名才是一个有效的提案，或者满足多少百分比的签名才有效。

所以说在跨链的过程中，子链也会验证公证人集合提案签名是否满足提案策略，这就是跨链互操作中数据可验证的一些细节。

事务链作为一个去中心化的协调者，通过两阶段的方式去协调多个不同的应用链，来维护数据的一致性。

两阶段提交中的第一阶段，就是预执行。一笔交易肯定是由事务链中的智能合约发起，最终会触发到应用链的智能合约去执行，调用应用链。

应用链智能合约执行的过程中，会调用智能合约的 API 去读写本地区块链的账本。当然，第一阶段还只是预执行，并不是真正的提交。

所以当应用链的合约要调用某个 API 去修改某个 key 的时候，需要对 key 先进行备份。原因是跨链的过程中，有可能提交成功了但另一个链没办法执行成功，这就需要支持后续的回滚操作。

所以要事先进行备份，同时还要锁定这个 key，以防在当前事务的执行过程中，就被其他的事务进行了修改。也就是说当我这个事务还没有提交时，其他的事务也修改了这个 key 的值，如果不锁定的话，当要执行回滚操作的时候就会出现问题。

所以我们会把它转换成 4 个操作。第一个操作就是查询 key 的原始值，第二步是锁定这个 key，第三步是对 key 的原始值进行备份，最后一步是真正对 key 进行修改。

第二阶段会出现两种情况。如果应用链在预执行阶段比较顺利，就会进入第二阶段的确认分支。

确认分支比较简单，会把第一阶段预执行的备份先删掉，然后接解除key 的锁定状态，完成交易。

如果有一条应用链的第一步失败了，那么需要回滚其他链的预执行操作。在回滚的过程中，需要找出 key 的备份。比如说先找回备份，重置key的数据，最后再释放锁。

在这里会涉及到一个 key 的修改机制，会替换成 4 个读写操作。为了降低开销，后面的三个操作都是写操作，也就是可以把后面的三个写操作批量提交。最终相当于是一次读、一次写，两次请求。

加了两阶段后，为了防止跨链事务的逻辑侵入到应用合约的开发过程中，两阶段的执行过程的细节是由系统完成的。比如合约要修改某个 key，它其实是不知道底层做了几步操作。这样做的好处是可以支持不同的异构的区块链。

我们看到跨链的过程是很复杂的，整个跨链的流程也非常繁琐，既要遵循去中心化，又要追求数据的可验证，这就导致一次跨链事务的效率非常低。

事务链作为多个应用链之间的一个通信的中间人，即使在简单的跨链操作中也会涉及到三条链，并且没有任何一个节点能够单独进行决策。就好比三群人来开会，没有一个人能够拍板做决定。所以共识决策的过程非常低效。

为了找到一个在去中心化和效率之间兼顾的一个方案。在某些场景中，我们将跨链变成两个流程。

第一个流程就是在线的流程，我们假设节点是可信的，不会有节点作恶，我们就可以像传统的中心化系统一样进行通信。比如在每个链中找出一个代理，链与链之间的通信变成两个代理间的通信。

在线的流程中，任何的交付都需要附带凭证。不管是做了一个响应或者发起一个请求，都会有自己的数字签名，同时还有数据在提交过程中可验证的数据结构。虽然为了简化流程不会实时进行验证，但会在第二部分的离线流程中，对在线流程中产生的各种凭证进行校验。因为是离线的，所以对效率不会造成影响。

在追求效率的场景下，可以利用联盟链实名的特点，把跨链的流程分成在线和离线两部分，把一些复杂的东西放到离线的对账流程去进行。

四、区块链技术展望

除了上述提到的可扩展性跨链互联，还有一些比较重要的区块链技术。

1. 链上链下协同

第一个就是链上链下协同。区块链为了安全可信，牺牲了一定的效率。这种低效的处理方式如果想把一个业务完全放到区块链上，完全闭环的解决，场景是有限的。区块链只能解决链上数据的可信，但在现实世界肯定需要考虑到链上链下数据的协同。比如要如何保证现实世界的数据映射到链上，并且是可信的。

比如说基于可信硬件的方法，就是先在链下把数据进行预处理，处理完之后再上链。也可以借助一些可信的系统进行背书，这都是链上链下协同相关的一些技术。

2. 隐私保护

第二个就是隐私保护。区块链为跨组织的数据共享协作带来了便利，相对于中心化的互联网业务，区块链在可靠性和隐私性上面会面临更大的挑战。因为原来的数据只要在内部访问就可以了，现在可能要公开给其他联盟链中的成员，就会出现很多数学方法，比如像同台加密和零知识证明相关的技术。

但复杂的计算需要借助可信的硬件来实现。可信硬件的原理是把我们受保护的一些逻辑运行在可信的硬件模块上，这就要求一定要相信 硬件是可信的。对外部来说是无法对运行逻辑和内存中的数据进行窥探或者篡改。

3. 领域特定语言的智能合约

第三就是领域特定语言的智能合约。智能合约其实是一个多方约定的规则或者合同，本质上是越简洁越好。

简洁一方面意味着代码的 bug 少，另一方面对合约进行审计的时候也简单。合约不像普通的程序，它会给更多的人看，并且不同的组织和公司都要共同审计它是否安全。所以在现实的应用中，会碰到几百行、几千行的智能合约，这个逻辑就非常复杂，对审计人员的技术背景要求也较高。

所以以后有可能会出现针对特定场景的智能合约。因为针对特定场景，开发的部分就会比较少，审计难度和 bug 方面都会有比较大的改善。

Q&A

Q：在知识产权保护方面有没有应用的案例？

A：腾讯云区块链在存证方面，和外部的几个厂商，比如中国网安还有北明做了一个名为「至信链」的项目来保护知识产权。

Q：不同底层框架的区块链可以跨链么？

A：可以跨，但需要重新定义跨链的协议。比如基于超级账本或者以太坊的，协议是互不相通的，需要再进行一层封装，就可以进行异构的跨链。不同的区块链要进行协议的适配，增加一个适配层。目前有很多跨链的方案是支持不同底层框架的。但要做到这一步，就需要自己去适配每一个区块链，或者使用已经适配好的方案。 

Q：如何提高链生成的速度？

A：链生成的速度应该是说链上交易的速度。联盟链中区块链的交易性能还不错，如果说主要是共识比较慢、节点比较多，也是有几个解决方案。比如说分层，或者说随机的选出一部分节点来做共识。共识的人少了，共识的速度就快了。

Q：验证越来越复杂，如何保证速度？

A：可以把部分验证放到离线进行，这个在现在的互联网场景中很常见。比如说不同业务系统之间经常会有对账，比如和银行进行对账，通常都是隔天对账，也是离线的对账。因为在线的时候没有办法完全保证数据是一致的。

Q：公钥能够发给任何人么？

A：公钥是公开的，是放在身份中的，任何人都可以在身份链里看到你的公钥。只有能看到你的公钥才能验证你的签名是否正确。

Q：联盟链如何构建，保证确保可信？

A：这个问题比较典型。联盟链最可信的构建方案，就是每个人都部署一个节点，然后自己生成自己的公私钥对，保管好自己的私钥，把公钥分享出来。在区块链还没有的时候，需要通过其他方式先进行分享，比如通过邮件把所有公钥都收集到一起，将共识信息写到区块链中，区块链中的第一笔交易就诞生了。