论文阅读《CAPER: A Cross-Application Permissioned Blockchain》报告

摘要

尽管最近进行了深入研究，但现有的区块链系统无法充分满足分布式应用程序的所有特征。特别是，分布式应用程序根据服务级别协议（SLA）相互交易以提供不同的服务。虽然应用程序之间的协作（例如，跨应用程序事务）应对所有应用程序可见，但每个应用程序的内部数据（例如，内部事务）可能是机密的。在本文中，我们介绍了CAPER，这是一种受许可的区块链系统，可支持协作分布式应用程序的内部和跨应用程序事务。在CAPER中，区块链分类账形成为有向无环图，其中每个应用程序都访问并仅维护其自己的分类账视图，包括其内部和所有跨应用程序交易。 CAPER还引入了三种共识协议，以使用不同的内部共识协议对应用程序之间的跨应用程序事务进行全局排序。实验结果展示了CAPER在性能和可伸缩性方面的效率。

基本信息

该论文于2019年7月在数据库的定会VLDB（VLDB基金会论文集）上发表。一作是来自宾夕法尼亚大学的Mohammad Javad Amiri，二作是来自加州大学圣塔芭芭拉分校的Divyakant Agrawal，三作为Amr El Abbadi。论文主要针对区块链在隐私性、算力和跨链操作方面的不足，设计实现了CAPER机制，主要解决了跨链交易中的隐私性。

背景

许多系统使用区块链的独特功能（例如透明性，出处，容错性和真实性）在许可的环境中部署广泛的分布式应用程序。可以将区块链分为许可链和非许可链，许可链是指参与到区块链系统中的每个节点都是经过许可的，未经许可的节点是不可以接入到系统中，因此私有链和联盟连都属于许可链，相对应的公有链一般属于非许可链。

将区块链技术运用到分布式应用中，需要分布式应用提供高性能、低延迟、高算力、低开销，这些要求目前的主流区块链（Bitcoin和Ethereum）都达不到。同时，分布式应用需要相互协作来完成，因此跨应用的交易是必不可少的；跨应用的交易会涉及到隐私数据，为此需要对隐私数据进行保护，但一般的加密方法计算都会带来巨大的算力开销。

现有的许可链在带宽和延迟上都表现不佳，且每个节点都存储账本的一个副本，存在隐私性问题。Fabric并行地执行交易，提升了性能；通过通道机制限制其他应用的访问，但最终经过排序后每个节点都存储账本信息。

为此CAPER设计了新的许可链，支持分布式应用内部的交易和跨应用的交易行文，同时满足以下特性：

1. 分布式应用内部的交易在本地完成排序和交易；跨应用交易在整个系统中公开，所有应用可见；
2. 区块链账本被实现为一个有向无环图，包含每个分布式应用的内部交易和跨应用交易；
3. 任一分布式应用本地只保存其内部交易的账本和所有跨应用的交易账本；
4. 为了保持一致性，跨应用交易需要完成全局共识（论文介绍了三种共识机制，可以完成跨应用交易的全局排序）

主要的贡献如下：

• 介绍区块链视图，其中每个应用程序仅维护其自己的分类账视图，包括其内部和所有跨应用程序交易。
• CAPER，一种受许可的区块链，支持协作分布式应用程序。 CAPER支持内部和跨应用程序事务。
• 三种不同的共识协议，用于使用不同的本地共识协议对应用程序之间的跨应用程序事务进行全局排序。

背景动机

供应链场景设置如下：

涉及五个参与方：供应商、制造商、买家、中间商和货运，整个过程需要上述五个参与者共同协商完成，每个参与者也有自己单独的任务。比如，制造商生产过程涉及金融、市场、采购等，同时还要在内部完成集合、绘画、烘干、测试和包装的全过程。整个过程的描述如下：
买家与制造商交流提交订单，制造商通过中间商提交原材料的订单，中间商材料的订单提交给供应商并安排货运；获得材料后，供应商通知货运，货运将其转送给制造商，制造商完成制造并将产品交付给买家。

整个过程需要多方协同完成，且过程容易出错引发纠纷。比如，制造商收到原材料的时间晚与约定的时间，此时会发生中间商、供应商和货运相互推卸责任的现象；如果此时制造商拒绝接受原材料，情况就会更加恶化，那一方来承担这个责任。

为了解决这个问题，可以在所有不同的参与者之间使用许可的区块链系统，以确保在不信任中央机构或任何特定参与者的情况下就合作方的共享状态达成协议。区块链基本上监视协作流程的执行，并检查流程执行与SLA之间的一致性。任何基于区块链的解决方案都必须解决以下问题。

为此，需要区块链满足以下三个特性：

1. 分布式应用支持本地和跨链交易；
2. 分布式应用对其他应用本地完成的交易不可见；
3. 计算性能高。

CAPER 模型

分布式应用

CAPER是一种区块链系统，旨在支持一组可能彼此不信任的分布式应用程序相互协作。每个应用程序维护私有和公共记录，私有记录仅可由该分布式应用程序访问，而公共记录则在所有应用程序上复制，被所有节点访问。

CAPER支持内部和跨应用程序事务。内部交易是根据应用程序的逻辑在应用程序内执行的，例如，在供应链方案中，制造商在内部计算原料需求。应用程序的内部事务可以读取和写入其私有记录，但是它们只能读取（不能写入）公共记录。另一方面，涉及多个应用程序跨应用程序（公共）的交易对所有应用程序都是可见的，例如，制造商通过中间人下达物料订单。跨应用程序事务遵循相关应用程序之间的服务级别协议（SLA）。SLA表示应用程序之间的通信流，并指示服务的不同方面，例如，质量，可用性和职责，应由不同的应用程序提供。例如，在供应链方案中，承运人负责在供应商通知之日起的两个工作日内将请求的物料交付给制造商。公开记录只能通过跨应用程序事务进行更新。

区块链账本

区块链账本是一个append-only数据结构，以哈希链的形式记录交易，其中每个块都包含一批交易。在许可的区块链中，将交易批处理成块会降低性能。 因此，在CAPER中**，每个块都包含一个事务**。 CAPER中的区块链分类帐由系统中所有应用程序的内部事务和所有跨应用程序事务组成。为了支持这两种类型的交易，我们将区块链分类帐的概念从线性链推广到有向无环图（DAG），其中图的节点是交易，边是执行交易的顺序。

在应用程序内，由于事务可以访问同一数据存储，因此将强制执行由应用程序启动的事务之间的总顺序以确保一致性。 为了在区块链分类账中显示交易的总顺序，交易被链接在一起，即每个交易都包含前一个交易的加密哈希。 另外，由于跨应用程序事务会更新在所有应用程序上复制的数据，因此为了确保一致性，跨应用程序事务也将全部排序。此外，应用程序的内部交易可能会使用跨应用程序交易提供的数据。 为了显示这种数据依赖性，内部事务包括分类账中跨应用程序事务的加密哈希。

区块链分类账具有以下三个性质：

1. 所有交易之间有一个全序；
2. 跨应用交易之间有一个全序；
3. 内部交易可能包含一个跨应用交易的哈希值；

如图所示，CAPER中四个分布式应用程序${\alpha }_1,{\alpha }_2,{\alpha }_3,{\alpha }_4$的账本为一个有向无环图(a)。图中，$\lambda$表示创世区块，内部交易和跨应用交易也标注了出来。比如，$t_{11},t_{13},t_{14}$和$t_{15}$是应用程序${\alpha }_1$的内部交易，$t_{12,1},t_{23,2}$和$t_{34,3}$是跨应用交易，分别由分布式应用程序${\alpha }_1,{\alpha }_2,{\alpha }_3$发起。不难看出，所有交易由其中一个应用程序初始化并链接在一起（满足性质1），跨应用交易也被链接在一起（满足性质2），内部交易包含了跨应用交易的哈希值（满足性质3），比如内部交易$t_{22}$跟跨应用交易$t_{12,1}$有变相连，$t_{22}$包含了$t_{12,1}$的哈希值。
备注：因为交易$t$到交易$t^{\prime }$的边表示t发生在$t^{\prime }$之后，$t$区块包含$t^{\prime }$的哈希，很容易证明账本是有向无环图。

跨应用交易对所有分布式应用可见，但应用程序的内部交易对其他应用程序是不可见的。总体上，整个区块链的账本不会被任何应用程序独自保存，每个应用程序只能看到自己的内部交易和所有的跨链交易，区块链账本是所有应用账本的并集。如上图所示，(b)-(e)展示了每个分布式应用程序本地保存的账本信息。

部署应用程序

CAPER中的每个应用程序，除了数据存储及其对区块链分类账的视图之外，还维护着一个“私有智能合约”来实现应用程序逻辑，以及一个“公共智能合约”来实现跨应用程序交易的逻辑。

CAPER中的每个应用程序都有其自己的私有智能合约，其中包括内部交易的逻辑。另外，编写了一个公共智能合约以包括跨应用程序交易的逻辑，该逻辑由应用程序之间的服务级别协议确定。为了执行协作过程，参与者同意SLA，然后将SLA写入公共智能合约中。公共智能合约在每个应用程序上运行，以检查跨应用程序交易是否符合SLA，并执行跨应用程序交易中定义的条件。与大多数现有的区块链不同，在每个区块中每个智能合约都在所有节点上运行，这与机密性不符，而在CAPER中，每个私有智能合约仅在其应用程序上运行。但是，为了支持跨应用程序交易，公共智能合约在每个应用程序上运行。

CAPER机制

CAPER由异步分布式系统中的一组节点组成，其中每个应用程序在称为应用程序代理的（非空）不相交的节点子集上运行。我们使用N和A表示节点和应用程序的集合。此外，$N_{\alpha }$表示应用程序$\alpha \in A$的代理的集合，并且对于每对应用程序${\alpha }_i$和${\alpha }_j$的节点不相交，即$N_{{\alpha }_i}\cap N_{{\alpha }_j}=\varnothing$

节点通过点对点双向通信通道连接，且能防止恶意节点伪造正确节点的信息。节点间传输的信息包含签名者的公钥和信息摘要。CAPER中节点可能出现恶意节点，为此将系统中的行为分为两层，节点层和应用层，两个层的恶意行为相互独立，没有直接关系。

在每个应用程序中对事务进行排序需要在应用程序的代理之间达成共识。为了建立共识，可以使用异步容错协议。该算法必须满足两个主要属性：

• 安全性：所有正确的节点以相同的顺序接收相同的请求
• 活动性：所有正确的客户端请求最终都被排序

崩溃容错协议可确保使用2f + 1个节点的异步网络的安全性，以克服任何f个节点的同时故障，而在拜占庭容错协议中，在存在f个恶意节点的情况下，至少需要3f + 1个节点提供安全性。

下面简单介绍下以Paxos和PBFT为代表的两个冲突和拜占庭容错算法：

• Paxos：它在使用2f + 1节点的异步网络中保证了安全性，收到来自客户端的请求后，主服务器（假设它已经被选举）通过广播一个accept消息在应用程序的agent之间启动共识协议；agent接收到accept消息后，返回accepted消息给主代理；主服务器等待接受不同agent的f条accepted消息（加上本身变为f +1）后，将commit消息广播到所有agent，然后将reply消息发送给客户端；收到来自主数据库的commit消息后，每agent程序都会执行事务。
• PBFT：在存在恶意节点的情况下，需要使用PBFT，使用3f + 1节点保证异步网络中的安全性。在正常情况下执行期间，客户端将请求发送到主节点，而主节点将pre-prepare消息广播到所有agent；然后，在prepare和commit阶段，所有agent相互通信以达成协议并将响应发送回客户端。
• 注意注意的是，在Paxos中，只有主服务器将答复消息发送到客户端，而在PBFT中，每个代理都发送答复消息，并且客户端在接受结果之前先等待f +1个匹配的答复消息。

共识协议

接下来最主要的就是在如何达成交易账本的一致性，即对需要处理的交易顺序达成一致，也就是下面要说的共识协议。

本地共识

CAPER中的本地共识协议是可插拔的。根据节点的故障模型，应用程序可以使用崩溃容错协议（例如Paxos ）或拜占庭容错协议（例如PBFT）作为本地共识协议。部分应用程序甚至可能不使用共识协议，而是依赖于一个无故障的可靠节点来对交易进行排序。

本地共识协议由主代理发起。CAPER执行内部事务的常规情况操作如下。 客户端c向主要应用程序的agent p发送消息$<REQUEST,tx,{\tau }_c,c{>}_{{\sigma }_c}$来请求应用程序的内部交易tx。${\tau }_c$是客户的时间戳，整个消息都用签名${\sigma }_c$签名。客户端的时间戳${\tau }_c$用于完全排序每个客户端的请求，并确保恰好执行一次客户端请求。

当主服务器p收到来自客户端的请求时，它首先检查签名以确保它的有效性，然后通过广播消息（例如Paxos中的accept消息或PBFT中的pre-prepare消息）来启动本地共识算法，向其他agent请求交易。为了提供事务之间的总顺序，主消息在消息中还包括$H(t)$，其中$H(.)$表示加密哈希函数，t是应用程序所排序的先前事务。如果事务对跨应用程序事务具有数据依赖性，则主数据库也将包含跨应用程序事务的加密哈希（前面说过，性质3）。

接下来，代理使用所使用的共识协议对交易进行全局排序，执行交易并将其附加到区块链分类账中。最后，主agent或每个agent节点（取决于本地共识协议）向客户端c发送回复消息$<REPLY,{\tau }_c,u{>}_{{\sigma }_o}$,其中${\tau }_c$是相应请求的时间戳，而u是执行结果。

全局共识协议

前面说了本地交易如何排序、运行，涉及到跨应用交易的排序执行，情况就会更加复杂。论文中设计了三种全局共识协议。

使用独立的Orderers节点排序

仿照Fabric中的Orderer机制，引入了不相交的节点集对交易进行排序，以增强系统的可伸缩性并增加实现共识协议的灵活性，即，可以使用不同的协议来建立共识。

如上图，可以看到在由四个应用程序${\alpha }_1,{\alpha }_2,{\alpha }_3$和${\alpha }_4$组成的区块链中使用一组订购者$o_1,o_2,o_3$进行跨应用程序交易的流程。此处，应用程序${\alpha }_1$启动了跨应用程序交易,在从客户端接收到跨应用程序事务后，${\alpha }_1$的主节点$n_1$验证该事务，并且类似于内部事务，启动本地共识算法以在应用程序内对事务进行排序；在内部对交易进行排序后，会将排序消息发送到主排序节点，图中是$o_1$；Orderers使用全局共识协议（例如，图3中f = 1的崩溃容错协议）就全局排序达成一致，然后广播包括事务的消息，将全局排序的结果同步到每个应用程序的每个代理；然后，由每个代理验证交易。
具体算法如下图：

分层全局共识协议

使用独立的Orderers节点进行全局排序会让协议变得简单，但增加Orderers的同时，也增加了额外的开销，需要付出额外的成本。在没有这样的订购者节点的情况下，就跨应用程序交易的顺序达成共识需要所有应用程序的参与。为了区分节点级别的信任和应用程序级别的信任，CAPER为全局共识使用异步拜占庭容错协议，对于每个跨应用程序事务和全局共识的每个阶段，每个应用程序都运行其本地共识协议，在该阶段内部决定应用程序的投票。

另外，由于发起方应用程序的代理参与了全局共识，因此与第一种方法相反，本地和全局排序被合并在一起。但是全局排序的每个步骤，协议都要确保发起方应用程序同意该排序。以此来保证由发起方应用程序发起的交易被正确地排序。

此外，在全局排序的每个步骤中以及在每个应用程序中，一旦达成协议，则取决于所使用的本地共识协议，要么是主要的(在Paxos中)，要么是每个代理(在PBFT中)，将投票发送给其他分布式应用程序。

上图了四个应用程序的分层共识，其中应用程序${\alpha }_1$和${\alpha }_3$使用崩溃容错(CFT)协议，应用程序${\alpha }_2$使用拜占庭容错(BFT)协议作为本地协议。应用的主要节点${\alpha }_1$启动共识。

作为一种优化，对于跨应用程序事务百分比很高的系统，并为了防止并发跨应用程序事务的启动，可以将其中一个应用程序的主节点指定为超级主节点，每个应用程序都将其跨节点发送给它，超级主节点启动该协议。
协议的具体算法如下：

One-level共识协议

虽然分层共识消除了对额外的订购者节点集的需求，并且区分了节点级别的信任和应用程序级别的信任，但它需要昂贵的两级共识协议，其中全局共识的每一步都需要整个本地协议。在每个应用程序中运行的共识协议，接下来介绍 One-level共识协议，其中对于每个跨应用程序事务，所有应用程序的agent都参与以达成对事务顺序的共识。

由于每个应用程序的agent数量取决于应用程序中所使用的共识协议，因此，确保应用程序的大多数代理程序同意交易顺序的匹配答复数量因应用程序而异。为此，将本地多数定义为来自应用程序代理的所需匹配消息数。如果应用程序的agen仅是崩溃的节点，则该应用程序的本地多数等于f +1(来自2f +1个代理的总数)；如果应用程序的代理可能表现出恶意行为，则该应用程序的本地多数申请等于2f +1(总共3f +1个代理)。对于只有一个可靠代理的应用程序，本地多数就是其中之一。

上图描述了四个具有不同失败模式的one-level共识协议。具体算法如下：

结论

论文提出了CAPER机制，解决了区块链在隐私性、性能和跨应用中的不足，通过将原先的链式区块链转换成一个有向无环图，每个分布式应用程序只保存自己内部的交易和所有的跨链操作，而后设计三个共识协议完成对所有交易的排序，保证了交易的一致性。论文的思路较好，设计理念创新，值得学习。

本人水平有限，对论文的解读不深，可能有出错的地方，欢迎大家批评指正，也欢迎大家一起讨论！谢谢观看！