区块链子网概述
什么是子网?
子网是在较大网络上下文中运行的较小网络,因此由对应的“主网”,主网即包含多个子网的较大网络或具有隶属关系的上一级网络。子网允许在主网中进行一些独立的事务或控制网络参数。
对于互联网而言,子网是较大网络的分段,是将网络逻辑划分为多个较小的网段。划分子网的目的:
- 减少网络流量,从而优化网络性能;
- 简化管理,在小网络中更易于找出并隔离网络问题。
在比特币区块链阶段,区块链是不存在子网概念的。而区块链侧链,就是能和比特币区块链交互,并与比特币挂钩的区块链。侧链和比特币区块链机制完全相同,且不存在包含或隶属的关系,一般不认为它是子网。
以太坊把区块链作为一个可编程的分布式信用基础设施,使用以太链虚拟机(EVM)支撑智能合约应用。以EVM兼容链为基础,波卡(Polkabot)引入多链相关的概念。之后雪崩(Avalanche)在多链之上提出了子网的概念。
雪崩链的子网是一个验证小组:
- 子网中有很多个验证节点,验证该子网下的单个或多个区块链。
- 子网会设置成员资格条件,只有满足条件的验证者才能加入该子网。比如:
- 要求验证者必须是某个国家的公民
- 要求验证者完成实名认证
- 要求验证者的电脑满足某种配置要求
- 每个验证者必须参与验证主网
- 雪崩链的子网允许运行私有链和无gas交易,但其中仍然是EVM兼容链。
联盟链子网概述
从雪崩链的子网可以看出,其最主要的作用是隔离成员。而隔离成员的目的是为了保护数据隐私,使得只有授权成员才可以访问隐私数据。因为许可链正是联盟链的特点,所以区块链子网的概念和应用范围在联盟链中更容易被定义和使用。而很多联盟链也都实际上实现了区块链子网的功能。
联盟链子网的功能及应用范围:
- 多个特定网络成员之间通信的专用网络
- 多个特定网络成员之间私有和机密的交易
联盟链子网的主要特点:
- 成员节点仅维护参与的相关子网的交易账本
- 联盟内多个特定节点间需要隔离交易和账本
上面两个特点体现出联盟链对隔离的处理方式:
- 不论一个成员节点是否可以参与多个子网,则与其无关的子网上的交易和账本应与此节点隔离;
- 如果一个成员节点可以参与多个子网,则其内部不同子网的交易和账本也必须相互隔离。
不同的联盟链子网实现
Hyperledge Fabric使用通道(Channel)实现了上述子网的功能和特点。除通道之外,为了保护每个成员组织的数据隐私,Fabric还引入了私有数据机制,其相当于一个轻量级的子网。
Corda的兼容区域(Compatibility Zone)或称Corda网络(Corda Network)本身就具有上述子网的部分功能和特点。但因为不存在更高一级的主网,所以其不是子网。R3也建议使用业务网络(Business Network)在Corda上实现子网的功能。
蚂蚁链允许联盟内多个参与方自由配置不同子链(Subnet)进行组网。
Fisco BCOS使用群组实现子网的部分功能和特点。
- 区块链节点可启动多个群组,群组间交易处理、数据存储、区块共识相互隔离;
- 每个群组独立运行各自的共识算法,不同群组可使用不同的共识算法。
如下图所示,Fisco BCOS使用单链多账本的解决方案,基于群组维度实现一条链上的数据隔离和保密。
HyperLedger Fabric子网
Fabric通道概述
为了在Fabric网络上创建和转移资产,一个组织需要加入一个通道。通道是特定组织间交流的私有层并且对其他网络成员不可见。
每个通道由单独的分隔的账本(区块链和世界状态)组成,该分隔的账本只能被通道成员读取和写入,成员节点被允许加入到该通道并接收来自排序服务的新交易块。
通道由成员(组织)、每个成员的锚点节点、共享账本、链码应用程序和排序服务节点定义。
网络上的每个交易都在一个通道上执行,在这个通道上,每一方都必须经过身份认证和授权才能在该通道上进行交易。
综上所述,Fabric通道实现了联盟链子网的所有定义和功能特点。并且Fabric的Peer节点可以参与多个通道的。
Fabric的通道分为两类:
- 系统通道
保存排序(共识)策略、形成排序服务的成员组织、排序节点保存联盟里的成员组织(这些组织管理员可以创建应用通道)和相关的配置;
是联盟链创建的第一个通道。
- 应用通道
保存与当前通道策略、成员组织和各组织锚点节点相关的配置;
默认使用系统通道中的排序节点和策略作为当前通道的排序节点和策略;
创建时成员组织是包含在对应联盟中的成员组织的一个子集。
系统通道概述
系统通道定义了形成排序服务的Orderer节点集合和充当排序服务管理员的组织集合。
系统通道包括属于区块链联盟的组织。
- 联盟是由一组管理Peer节点的组织组成的,他们的MSP保存于系统通道,但他们不是排序服务的管理员。
- 联盟组织的管理员可以创建新通道,并包括其他联盟组织作为通道初始成员。
这是一个最简单的初始Fabric网络:
- 绿色代表初始的排序服务组织R4:
- 证书颁发机构CA4被用来向组织R4的管理员和网络节点分配身份信息;
- 能访问此网络的用户也是由CA4定义的,他们具有网络配置NC4中包含的规则中所描述的权利;
- 排序服务O4由一个单独的排序节点组成,NC4实际上就保存在O4的账本上。
- 粉色代表另一个排序服务组织R1:
- R1也被记录进网络配置NC4中,因此其和R4在网络配置中具有相同的权限;
- 证书颁发机构CA1用来标识R1组织的用户;
- 尽管排序节点O4是运行在R4的基础设施上的,如果R1能够访问到的话就可以共享管理的权限。
- 褐色代表一个初始的联盟组织R2:
- 这里在NC4上定义了一个联盟X1,其定义了R1和R2是它的联盟组织。
- 证书颁发机构CA2用来标识R2组织的用户,在NC4中只规定了他们具有创建应用通道的权力。
- 这里的NC4就是系统通道账本。O4就是系统通道承载的节点。
应用通道概述
只有属于系统通道的联盟组织的管理员身份才能创建应用通道,具体由系统通道账本上的通道创建策略决定。
应用通道的初始组织是包含在对应联盟中的组织的一个子集。
系统通道中定义的排序节点成为新通道的默认共识者集合。排序服务的管理员成为该通道的排序管理员。
排序管理员可使用通道更新在共识者集合中添加或删除排序节点和排序服务组织。
这是包含一个应用通道的Fabric网络:
- 通道C1为联盟X1提供了一个私有的通信机制;
- 通道C1具有同网络配置NC4完全分开的配置CC1,R4在这个通道中没有权限;
- Peer节点P1和P2存储账本实例L1的副本,智能合约S5被安装在了P1和P2上;
- 组织R1和R2的客户端应用A1或A2都可以通过Peer节点P1和P2使用S5来访问账本L1;
- 这里客户端可以读写哪个Peer节点由读取和写入策略决定;
- 更新账本由背书策略决定;
- 这些策略也会被放置在通道账本上;
- 组织R1和R2都可以在此通道上添加并不属于联盟组织的新组织。此行为由管理员策略决定。
对于含两个应用通道的Fabric网络,可以有两种不同的实现方法:
- 在系统通道设置NC4中定义另一个联盟X2,包含R2和R3:
- 新联盟只能够由网络配置策略NC4中指定的排序服务组织R1和R4来创建;
- 根据联盟X2上的通道创建策略,成员R2和R3可以创建此通道,且必须设置初始通道配置CC2引用联盟X2。
- 也可以不创建新联盟X2:
- 根据联盟X1上的通道创建策略,成员R2可以创建此通道,且必须设置初始通道配置CC2引用联盟X1;
- 初始通道C2上可以只有R2一个成员组织,然后R2和R3加入此通道。
- 通道C2是由组织R2和R3管理的,这两种创建方式创建的通道C2除联盟引用外并无区别。
- 节点P2同时是两个通道的成员,其通过不同的智能合约来处理不同的账本。
- 客户端应用程序A2能够在通道C1和C2上进行交易。其按照在相关通道配置中的策略来进行管理。
- 排序服务O4使用通道C1和C2的通信服务。这里的排序服务是中心化的,但如果组织R1可提供排序节点O1,则其也是去中心化的。
系统通道配置信息
系统通道账本NC4上的网络配置信息,这里的Consortiums和Order属性都是channel_group下groups列表中的对象属性。
联盟属性下的修改策略(mod_policy)指向排序属性下的策略,即上面所述联盟的创建和修改只能由排序组织R1或R4进行。
此图中联盟X1的创建通道策略为ANY Admins,即组织R1或R2的任意一个Admin用户都可以创建应用通道。
排序属性下每个排序组织都要保存排序节点(Endpoints)信息,R1没有排序节点则其中地址列表为空。
应用通道配置信息
应用通道账本CC1上的通道配置信息,这里的Application和Orderer属性都是channel_group下的groups列表中的对象属性。
channel_group下的values中的Consortium标识了当前通道配置引用系统通道中联盟X1的配置。
应用属性下的组织策略和MSP默认拷贝自引用的系统通道上的联盟组织。这里多了锚节点的配置:
- 如果一个Peer节点需要同另一个组织的Peer节点通信的话,它可以使用对方组织通道配置中定义的锚节点。
最终通道的管理员、背书、智能合约生命周期背书等策略由Application下的policies决定。
排序属性下的共识者集合、策略和配置是从系统通道排序属性下拷贝过来的,这里的管理员策略决定了谁可以后续修改此通道的排序服务。
Fabric私有数据概述
应用通道将隐私数据从底层物理上进行了隔离,但其也有下面的问题:
- 创建单独的通道会产生额外的管理开销(维护链码版本、策略、MSP等);
- 不能在保留一部分数据私有的同时,让其他通道参与者看到相关的事务。
为了解决这两个问题,提供轻量级的子网能力,Fabric提供私有数据集合的功能。
私有数据集合是两个元素的组合:
- 实际的私有数据
通过Gossip协议点对点地发送给授权可以看到它的组织。
数据保存在被授权的组织节点上的私有数据库上,它们可以被授权节点的链码访问。
排序节点不能影响也不能看到私有数据。
- 私有数据的哈希值
该哈希值被背书、排序之后写入通道上每个节点的账本副本上。此哈希值作为交易的证明用于状态验证,并可用于审计。
如果集合成员陷入争端,或者想把资产转让给第三方。则第三方可计算私有数据的哈希,并查看它是否与通道账本上的状态匹配,从而证明在某个时间点,集合成员之间存在该状态。
私有数据的应用场景与交易流程
私有数据与通道的使用场景:
- 必须将整个账本在属于通道成员的组织中保密时,使用通道;
- 账本必须共享给一些组织,但是只有其中的部分组织可以在交易中使用这些数据的一部分或者全部时,使用私有数据集合;
- 私有数据是点对点传播的,而不是通过块传播的,所以在交易数据必须对排序服务节点保密时,使用私有数据集合。
当Fabric链码(智能合约)中引用私有数据集合时,为在交易被提案、背书并提交到账本时保持私有数据的机密性,交易流程略有不同:
- 客户端应用程序提交一个提案请求,让授权此集合的背书节点执行链码函数,其中的私有数据需通过瞬态字段传递;
- 背书节点执行链码,并将私有数据存储在瞬态数据存储(节点的本地临时存储)中。它们根据组织集合的策略将私有数据通过gossip分发给授权的Peer节点。
- 背书节点将响应发送回客户端。响应包含公共数据和任何私有数据键和值的哈希。私有数据不会被发送回客户端。
- 客户端应用程序将带有私有哈希的交易提交排序服务。此交易同样被包含在区块中。带有私有数据哈希的区块分发给通道中所有节点。
- 在区块提交的时候,授权节点根据私有数据集合策略决定是否有权访问私有数据。
- 如果有权访问,节点先检查本地瞬态数据存储,以确定是否在背书的时候已经接收到了私有数据。
- 如果瞬态数据存储中没有,节点从其他已授权节点拉取私有数据,并对照公共区块上的哈希验证私有数据后提交交易和区块。
- 验证或提交结束后,私有数据被移动到这些节点私有数据库和私有读写存储副本中。
- 授权节点删除瞬态数据存储中存储的私有数据。
私有数据的集合定义
私有数据的集合定义如下,其需要与相关的智能合约一起部署:
- name:集合名称。即调用putPrivateData,getPrivateData等函数的第一个参数;
- policy:私有数据集合分发策略。定义了允许哪些组织的Peer节点持久化集合数据。
- requirePeerCount:在节点背书并将提案响应返回给客户端前,每个背书节点必须将私有数据分发到的节点的最小数量。0代表不必分发。
- maxPeerCount:为了数据的冗余存储,每个背书节点尝试将私有数据分发到的其他节点的最大数量。0代表不会分发,则提交时强制拉取。
- blockToLive:私有数据应该以区块的形式在私有数据库中存在多久。
- memberOnlyRead:true表示节点强制只有属于此集合成员组织的客户端才可以读取私有数据。
- memberOnlyWrite:true表示节点强制只有属于此集合成员组织的客户端才可以写入私有数据。
- endorsementPolicy:可供选择的背书策略,用来覆盖链码级别的背书策略。
组织Org2MSP只可以访问collectionMarble隐私数据集合。而collectionMarblePrivateDetails只有Org1MSP的Peer节点可以访问和背书写入。
Corda子网
Corda网络权限结构
Corda账本特点
在Corda中没有唯一的中心化存储的数据。
每个节点维护一个独立的数据库,其中包含了所知道的事实。
每个节点只能够看到账本中的事实中的一部分,没有节点能够知道所有的内容。
对于账本上的共享事实,共享的两方(或多方)总是能够保证存在他们自己的账本中的事实是完全一致的。
Corda核心概念
- “状态”(State)代表的是存在账本上的事实。每个节点都有一个“保险库”(Vault)存储该节点所有相关的“状态”。
- “交易”(Transaction)是关于更新账本的提议。
- 一个有效的“交易”必须要被它的所有输入和输出“状态”所引用的“合约”(Contract)接受。如下图。
- “流程”(Flow)使同意更新账本变得自动化。内置的“流程”提供了常用的一些任务。
- CorDapps(Corda分布式应用Corda Distributed Applications)是在Corda平台上运行的分布式应用程序。包含下边的元素:
- 流程:定义了节点的日常工作,通常是更新账本;
- 状态:定义了要达成协议的事实;
- 合约:定义了构成有效账本更新的内容;
- 服务:在节点中提供了长期的工具类;
- 序列化白名单:限制了你的节点会接收什么样的信息。
Corda业务网络
Corda“业务网络”是一个成员列表或区域中已同意相互交易的节点子集。允许节点操作员可以基于一组CorDapp以及共享的业务上下文,定义和创建逻辑网络。
业务网络之外的Corda节点不知道其成员。网络可以分为子组或成员列表,从而允许进一步的隐私(组的成员只知道他们组中的成员)。
通过此扩展的CorDapps,您可以使用一组流程来:
- 开始一个商业网络;
- 添加成员;
- 将成员分配到成员列表或组;
- 更新有关成员的信息 - 例如他们的商业网络身份;
- 修改成员在网络中的角色;
- 暂停或撤销会员资格。
在业务网络中,您可以为网络成员分配不同的角色:
- 商业网络运营商 - 拥有商业网络中的所有管理权限。
- 授权成员 - 至少具有执行特定任务所需的管理权限。
- 成员 - 可能没有管理权限,但仍然是组的成员。
综上所述,业务网络可视为Corda网络中的一种轻量级的子网的实现。
蚂蚁链子网
蚂蚁链子网概述
允许联盟内,多个参与方自由配置不同子链(Subnet)进行组网。
在一个参与方的角度,将可以参与多个业务建立多条子链(Subnet)。
蚂蚁链子网特点
蚂蚁链允许联盟内多个参与方自由配置不同子网(Subnet)。在一个参与方角度,将可以参与多个业务建立多条子网(Subnet)。
Subnet管理能力包括:
- 创建Subnet:通过特定消息,SDK可以从接收节点不停机的情况下动态创建Subnet。
- 加入Subnet:动态加入Subnet复用现有蚂蚁链动态增删节点能力。
- 退出Subnet:复用现有蚂蚁链动态增删节点功能,主链Subnet0无操作。
Subnet内独立共识,根据SubnetID,交易将被分发至不同Subnet。每个Subnet内的所有Transaction复用现有共识引擎独立分区共识。
不同Subnet内的分区共识互不影响。Subnet内独立交易,根据SubnetID,交易将被分发至不同Subnet进行分区共识。
分区共识后的交易批次(Batch),将由Controller按照SubnetID分发至不同的区块链实例进行计算和存储。
Subnet机制实现了一个动态、立体的区块链节点互联网络。
蚂蚁链动态子网
在区块链应用中,存在联盟内部不同节点灵活组网的需求。
蚂蚁链动态子网(Subnet)功能支持:
- 在区块链运行过程中创建新的共识子网。
- 新的子网包含主网上全部或部分节点,运行独立的共识。
- 能够实现在不部署新节点的情况下快速建立独立的业务链,支持业务数据隔离。
- 子网统一节点身份机制也为不同子网间的业务互操作提供了安全保障。
综上所述,蚂蚁链子网具有以下特点:
- 动态创建
- 独立共识
- 业务数据隔离
- 子网间互操作