区块链网络中加入节点的方法和区块链系统
阅读：943发布：2024-01-27
专利汇可以提供区块链网络中加入节点的方法和区块链系统专利检索，专利查询，专利分析的服务。并且本 申请 实施例 公开了一种 区 块 链 网络中加入 节点 的方法和区块链系统。区块链网络中加入节点的方法包括：区块链网络中的第一已有共识节点接收添加节点的交易 请求 ，并针对该添加节点的交易请求发起共识；达成共识后，已有共识节点执行所述添加节点的交易，在本地节点列表中已有共识节点的编号的 基础 上为所述待添加节点编号；所述待添加节点同步区块链上的区块数据；所述已有共识节点发起视图切换；所述视图切换完成后，所述待添加节点参与所述区块链的共识过程。，下面是区块链网络中加入节点的方法和区块链系统专利的具体信息内容。
1.区块链网络中加入节点的方法，包括：
区块链网络中的第一已有共识节点接收添加节点的交易请求，并针对该添加节点的交易请求发起共识；达成共识后，已有共识节点执行所述添加节点的交易，在本地节点列表中已有共识节点的编号的基础上为所述待添加节点编号；
所述待添加节点同步区块链上的区块数据；
所述已有共识节点发起视图切换；
所述视图切换完成后，所述待添加节点参与所述区块链的共识过程。
2.如权利要求1所述的方法，其中，所述添加节点的交易请求包括调用合约的交易请求。
3.如权利要求2所述的方法，其中，所述调用的合约包括创世合约或系统合约。
4.如权利要求1所述的方法，其中，所述第一已有共识节点接收添加节点的交易请求，包括：
第一已有共识节点接收客户端发起的添加节点的交易请求；或，
第一已有共识节点接收控制台指令端发起的添加节点的交易请求。
5.如权利要求1所述的方法，其中，已有共识节点在本地维护有节点列表，所述节点列表中包括共识节点的标识、IP地址、端口号中的一个或多个；其中，共识节点在本地节点列表中顺序编号。
6.如权利要求5所述的方法，其中，所述共识节点在本地维护的节点列表位于世界状态中。
7.如权利要求1所述的方法，其中，已有共识节点执行所述添加节点的交易，在本地节点列表中已有共识节点的编号的基础上为所述待添加节点编号，包括：
已有共识节点执行所述添加节点的交易，在本地节点列表中已有共识节点的基础上将所述待添加节点的标识添加至列表尾部并顺序编号；
或，
已有共识节点执行所述添加节点的交易，在本地节点列表中将包括所述待添加节点在内的所有共识节点重新按照指定属性排序。
8.如权利要求1所述的方法，其中，所述待添加节点同步区块链上的区块数据包括：
所述待添加节点向连接的一个已有节点发出同步请求，从该已有节点上获取全部区块数据；或，
所述待添加节点向不同的已有节点发出获取不同区块的同步请求。
9.如权利要求1所述的方法，其中，待添加节点通过checkpoint消息判断是否完成了区块数据的同步，或向其它节点发出查询当前最大区块号的请求，通过大多数节点反馈的相同的最大区块号与本地最大区块号一致来判断完成了区块的同步。
10.如权利要求1所述的方法，其中，所述已有共识节点检测到下面任一情形时发起视图切换：
本地共识节点列表中的共识节点数量与当前视图中的共识节点数量存在不一致；或，本地共识节点列表中的共识节点标识与当前视图中的共识节点标识存在不一致。
11.如权利要求1所述的方法，其中，所述已有共识节点接收到所述待添加节点广播的“发起视图切换”的消息后发起视图切换。
12.如权利要求1所述的方法，其中，所述待添加节点同步完成区块链上的区块数据后发送激活节点的交易请求至区块链网络，所述已有共识节点对所述激活节点的交易请求完成共识后并执行。
13.如权利要求12所述的方法，其中，所述已有共识节点检测到下面任一情形时发起视图切换：
本地共识节点列表中的激活的共识节点数量与当前视图中的激活的共识节点数量存在不一致；或，
本地共识节点列表中激活的的共识节点标识与当前视图中激活的共识节点标识存在不一致。
14.如权利要求1所述的方法，其中，视图切换过程中的副本集合个数为包括待添加节点的共识节点总数。
15.一种区块链系统，包括：
第一已有共识节点，用于接收添加节点的交易请求，并针对该添加节点的交易请求发起共识；达成共识后，已有共识节点执行所述添加节点的交易，在本地节点列表中已有共识节点的编号的基础上为所述待添加节点编号；
所述待添加节点，用于同步区块链上的区块数据；
所述已有共识节点，用于发起视图切换；
所述视图切换完成后，所述待添加节点参与所述区块链的共识过程。
16.如权利要求15所述的区块链系统，其中，所述添加节点的交易请求包括调用合约的交易请求。
17.如权利要求16所述的区块链系统，其中，所述调用的合约包括创世合约或系统合约。
18.如权利要求15所述的区块链系统，其中，所述第一已有共识节点接收添加节点的交易请求，包括：
第一已有共识节点接收客户端发起的添加节点的交易请求；或，
第一已有共识节点接收控制台指令端发起的添加节点的交易请求。
19.如权利要求15所述的区块链系统，其中，已有共识节点在本地维护有节点列表，所述节点列表中包括共识节点的标识、IP地址、端口号中的一个或多个；其中，共识节点在本地节点列表中顺序编号。
20.如权利要求19所述的区块链系统，其中，所述共识节点在本地维护的节点列表位于世界状态中。
21.如权利要求15所述的区块链系统，其中，已有共识节点执行所述添加节点的交易，在本地节点列表中已有共识节点的编号的基础上为所述待添加节点编号，包括：
已有共识节点执行所述添加节点的交易，在本地节点列表中已有共识节点的基础上将所述待添加节点的标识添加至列表尾部并顺序编号；
或，
已有共识节点执行所述添加节点的交易，在本地节点列表中将包括所述待添加节点在内的所有共识节点重新按照指定属性排序。
22.如权利要求15所述的区块链系统，其中，所述待添加节点同步区块链上的区块数据包括：
所述待添加节点向连接的一个已有节点发出同步请求，从该已有节点上获取全部区块数据；或，
所述待添加节点向不同的已有节点发出获取不同区块的同步请求。
23.如权利要求15所述的区块链系统，其中，待添加节点通过checkpoint消息判断是否完成了区块数据的同步，或向其它节点发出查询当前最大区块号的请求，通过大多数节点反馈的相同的最大区块号与本地最大区块号一致来判断完成了区块的同步。
24.如权利要求15所述的区块链系统，其中，所述已有共识节点检测到下面任一情形时发起视图切换：
本地共识节点列表中的共识节点数量与当前视图中的共识节点数量存在不一致；或，本地共识节点列表中的共识节点标识与当前视图中的共识节点标识存在不一致。
25.如权利要求15所述的区块链系统，其中，所述已有共识节点接收到所述待添加节点广播的“发起视图切换”的消息后发起视图切换。
26.如权利要求15所述的区块链系统，其中，所述待添加节点同步完成区块链上的区块数据后发送激活节点的交易请求至区块链网络，所述已有共识节点对所述激活节点的交易请求完成共识后并执行。
27.如权利要求26所述的区块链系统，其中，所述已有共识节点检测到下面任一情形时发起视图切换：
本地共识节点列表中的激活的共识节点数量与当前视图中的激活的共识节点数量存在不一致；或，
本地共识节点列表中激活的的共识节点标识与当前视图中激活的共识节点标识存在不一致。
28.如权利要求15所述的区块链系统，其中，视图切换过程中的副本集合个数为包括待添加节点的共识节点总数。
区块链网络中加入节点的方法和区块链系统
技术领域
[0001] 本申请涉及计算机技术领域，尤其涉及一种区块链网络中加入节点的方法和区块链系统。
背景技术
[0003] 针对此，需要提供一种区块链网络中加入节点的方法。发明内容
[0004] 本申请实施例的目的是提供一种区块链网络中加入节点的方法和区块链系统。
[0005] 为解决上述技术问题，本申请实施例是这样实现的：
[0006] 区块链网络中加入节点的方法，包括：
[0007] 区块链网络中的第一已有共识节点接收添加节点的交易请求，并针对该添加节点的交易请求发起共识；达成共识后，已有共识节点执行所述添加节点的交易，在本地节点列表中已有共识节点的编号的基础上为所述待添加节点编号；
[0008] 所述待添加节点同步区块链上的区块数据；
[0009] 所述已有共识节点发起视图切换；
[0010] 所述视图切换完成后，所述待添加节点参与所述区块链的共识过程。
[0011] 一种区块链系统，包括：
[0012] 第一已有共识节点，用于接收添加节点的交易请求，并针对该添加节点的交易请求发起共识；达成共识后，已有共识节点执行所述添加节点的交易，在本地节点列表中已有共识节点的编号的基础上为所述待添加节点编号；
[0013] 所述待添加节点，用于同步区块链上的区块数据；
[0014] 所述已有共识节点，用于发起视图切换；
[0015] 所述视图切换完成后，所述待添加节点参与所述区块链的共识过程。
[0016] 由以上本申请实施例提供的技术方案可见，本申请实施例视图切换完成之后，包括待添加节点在内的各共识节点本地各自存有相同的节点编号列表，且具有相同的区块数据，从而待添加节点可以参与共识，即与已有共识节点共同进行共识。这样，就完成了添加节点的过程。附图说明
[0017] 为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
[0018] 图1为本申请一个实施例的创建智能合约的图示过程；
[0019] 图2为本申请一个实施例的调用智能合约的图示过程；
[0020] 图3为本申请一个实施例中创建智能合约和调用智能合约的示意图；
[0021] 图4为PBFT算法的流程图；
[0022] 图5为PBFT算法中需要在视图切换后进行恢复的原理图；
[0023] 图6为PBFT算法中视图切换过程的原理图；
[0024] 图7为本申请联盟链中添加节点的一个实施例的流程图；
[0025] 图8为本申请一区块链系统实施例的架构图。
具体实施方式
[0026] 本申请实施例提供一种区块链网络中加入节点的方法和区块链系统。
[0027] 为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
[0028] 区块链一般被划分为三种类型：公有链(Public Blockchain)，私有链(Private Blockchain)和联盟链(Consortium Blockchain)。此外，还有多种类型的结合，比如私有链+联盟链、联盟链+公有链等不同组合形式。其中去中心化程度最高的是公有链。公有链以比特币、以太坊为代表，加入公有链的参与者可以读取链上的数据记录、参与交易以及竞争新区块的记账权等。而且，各参与者(即节点)可自由加入以及退出网络，并进行相关操作。私有链则相反，该网络的写入权限由某个组织或者机构控制，数据读取权限受组织/机构规定。简单来说，私有链可以为一个弱中心化系统，参与节点具有严格限制且数量少。联盟链则是介于公有链以及私有链之间的区块链，可实现“部分去中心化”。链上各个节点通常有与之相对应的实体机构或者组织；参与者通过授权加入网络并组成利益相关联盟，共同维护区块链运行。上述不同类型的区块链中，都有节点动态加入区块链网络的需求。
[0029] 不论是公有链、私有链还是联盟链，都可能提供智能合约(Smart contract)的功能。区块链上的智能合约是在区块链系统上可以被交易触发执行的合约。以以太坊为例，支持用户在以太坊网络中创建并调用一些复杂的逻辑，这是以太坊区别于比特币区块链技术的最大挑战。以太坊作为一个可编程区块链的核心是以太坊虚拟机(EVM)，每个以太坊节点都可以运行EVM。EVM是一个图灵完备的虚拟机，这意味着可以通过它实现各种复杂的逻辑。用户在以太坊中发布和调用智能合约可以在EVM上运行的。
[0030] 例如图1所示，Bob将一个包含创建智能合约的交易发送到以太坊网络后，节点1的EVM可以执行这个交易并生成对应的合约实例。图中1中的“0x6f8ae93…”代表了这个合约的地址，交易的data字段保存的可以是字节码，交易的to字段为一个空的账户。节点间通过共识机制达成一致后，这个合约成功创建，后续用户可以调用这个合约。
[0031] 合约创建后，区块链上出现一个与该智能合约对应的合约账户，并拥有一个特定的地址，合约代码和账户存储将保存在该合约账户中。智能合约的行为由合约代码控制，而智能合约的账户存储则保存了合约的状态。换句话说，智能合约使得区块链上产生包含合约代码和账户存储(Storage)的虚拟账户。
[0032] 如图2所示，仍以以太坊为例，Bob将一个包含调用智能合约信息的交易发送到以太坊网络后，节点1的EVM可以执行这个交易并生成对应的合约实例。图中2中交易的from字段是发起调用智能合约的账户的地址，to字段中的“0x6f8ae93…”代表了被调用的智能合约的地址，value字段在以太坊中是以太币的值，交易的data字段保存的调用智能合约的方法和参数。调用智能合约后，balance的值可能改变。后续，某个客户端可以通过某一区块链节点(例如图2中的节点6)查看balance的当前值。
[0033] 智能合约可以以规定的方式在区块链网络中每个节点独立的执行，所有执行记录和数据都保存在区块链上，所以当这样的交易完成后后，区块链上就保存了无法篡改、不会丢失的交易凭证。
[0034] 创建智能合约和调用智能合约的示意图如图3所示。以太坊中要创建一个智能合约，需要经过编写智能合约、变成字节码、部署到区块链等过程。以太坊中调用智能合约，是发起一笔指向智能合约地址的交易，智能合约代码分布式的运行在以太坊网络中每个节点的虚拟机中。
[0035] 需要说明的是，除了可以由用户创建智能合约，也可以在创世块中由系统设置智能合约。这类合约一般称为创世合约。一般的，创世合约中可以设置一些区块链网络的数据结构、参数、属性和方法。此外，具有系统管理员权限的账户可以创建系统级的合约，或者修改系统级的合约(简称为系统合约)。另外除了以太坊中的EVM外，不同的区块链网络还可能采用各种的虚拟机，这里并不限定。
[0036] 区块链技术区别于传统技术的去中心化特点之一，就是在各个节点上进行记账，或者称为分布式记账，而不是传统的集中式记账。区块链系统要成为一个难以攻破的、公开的、不可篡改数据记录的去中心化诚实可信系统，需要在尽可能短的时间内做到分布式数据记录的安全、明确及不可逆。不同类型的区块链网络中，为了在各个记录账本的节点中保持账本的一致，通常采用共识算法来保证，即前述提到的共识机制。在节点(例如某个独特的节点)产生一个区块后，如果产生的这个区块得到其它节点的认可，其它节点记录相同的区块。上述产生的区块得到其它节点的认可的过程，就是共识机制。共识机制是区块链节点就区块信息达成全网一致共识的机制，可以保证最新区块被准确添加至区块链。当前主流的共识机制包括：工作量证明(Proof of Work，POW)、股权证明(Proof of Stake，POS)、委任权益证明(Delegated Proof of Stake，DPOS)、实用拜占庭容错(Practical Byzantine Fault Tolerance，PBFT)算法，HoneyBadgerBFT算法等。
[0037] 以PBFT算法为例，有一些已知的结合PBFT实现动态加入节点的尝试。例如《Dynamic Practical Byzantine Fault Tolerance》
[0038] (https://ieeexplore.ieee.org/stamp/stamp.jsp？arnumber＝8433150)，论述了在基于PBFT算法情况下如何让节点能够动态的加入区块链网络，需要一个证书授权(Certificate Authority，CA)中心节点作为安全服务提供方来参与新增节点的加入，CA节点本身不参与共识。再例如《Solida:A Blockchain Protocol Based on Reconfigurable Byzantine Consensus》
[0039] (https://eprint.iacr.org/2017/1118.pdf)，提出了一种基于比特币POW和PBFT算法的节点加入和删除算法，运用POW算法来选出主节点。众所周知，POW算法比较消耗CPU资源。以下以PBFT算法为例介绍共识机制的过程。
[0040] 图4示出了传统的PBFT算法的流程图。该算法是Miguel Castro(卡斯特罗)和Barbara Liskov(利斯科夫)在1999年提出来的，解决了原始拜占庭容错算法效率不高的问题，将算法复杂度由指数级降低到多项式级，使得拜占庭容错算法在实际系统应用中变得可行。该论文发表在1999年的操作系统设计与实现国际会议上(OSDI99)。该算法中假设，当最多存在f个副本(即节点)失效时，如果存在总数为至少3f+1个副本，就能保证在异步系统中提供安全性和活性。为了能够确保所有副本的数据一致性要求和容错要求，需要的一定数量副本的集合，一般是分布式系统中的大多数节点构成的集合，构成大多数(Quorum)。例如在总节点数n为3f+1的情况下，Quorum为2f+1。这样，对于包含四个节点的分布式系统，任意三个节点可以构成一个Quorum。
[0041] 而且，所有的副本(replica)在一个被称为视图(View)的轮换过程(succession of configuration)中运行。在某个视图中，一个副本作为主节点(primary)，其他的副本作为备份节点(backups)。视图是连续编号的整数。主节点由公式p＝v mod|R|计算得到，这里v是视图编号，p是副本编号，|R|是副本集合的个数。当主节点失效的时候就需要启动视图更换(view change)过程，从而在在系统存在故障进行状态调整，更换新的主节点。
[0042] PBFT算法的过程如下：
[0043] 1.客户端c向主节点0(即replica 0)发送请求；
[0044] 2.主节点0通过广播将请求发送给各备份节点；
[0045] 3.所有副本(replica)都执行请求并将结果发回客户端；
[0046] 4.客户端需要等待f+1个不同副本节点发回相同的结果，作为整个操作的最终结果。
[0047] 下面以一个PBFT的例子(例如结合著名的拜占庭将军问题)来进行说明。这里首先假设N＝4，F＝1，即总共有4个节点，其中坏节点的数量是1。这里假设四个节点的编号分别是0、1、2、3，其中坏节点是节点3，则过程如下：
[0048] 1.(REQUEST请求阶段)客户端c发送请求request到0号主节点；
[0049] 2.(PRE-PREPARE预准备阶段)主节点0收到客户端请求(或一组客户端的请求requests)后，对requests排序(对于一组客户端请求而言)并打包为消息m后，发送pre-prepare请求至节点1、2、3(即备份节点1，2，3，也是replica1，2，3，以下简称节点)，pre-prepare请求中包括消息m；
[0050] 3.(PREPARE准备阶段)节点1、2、3收到请求后，如果检查消息m合法，则分别再次广播。具体的，节点1将prepare消息扩散至节点0、2、3，节点2将prepare消息扩散至节点0、1、3，节点3例如是因为宕机而无法广播的坏节点。而且，每一节点还接收其他节点广播的prepare消息。每一节点将自己发送的prepare消息(代表自己的认可)和收到的prepare消息(代表其它节点的认可)都添加到本地Log中。如果某一节点接收到来自不同节点的Quorum-1个数量的针对同一消息的确认后(包括pre-prepare和prepare消息，这样本地Log中共有Quorum个)，转变成prepared状态。
[0051] 4.(COMMIT提交阶段)参与共识节点中的每一个在进入prepared状态后，发送commit消息给其他的共识节点，并将自己发送的commit消息添加到本地Log中(代表自己的认可)，而且，每一节点还接收其他节点广播的commit消息。某一节点如果接收到来自不同节点的Quorum-1数量的合法的commit消息后，添加到本地Log中(这时加上自己添加到本地Log中的共有Quorum个)，转变成commited状态。
[0052] 5.(REPLY响应阶段)所有参与共识的节点中的每一个在本地状态机中顺序执行pre-prepare消息m中的一个request或一组有序requests，并返回应答消息reply至Client，即对客户端c进行反馈。
[0053] 客户端如果收到f+1个相同的REPLY消息，说明客户端发起的请求已经达成全网共识，否则客户端c可能需要判断是否重新发送请求给主节点0。
[0054] 上述图4所示的过程和对应的文字内容，是传统的PBFT的算法过程。这个过程往往由客户端发起，进而针对客户端发起的REQUEST消息中的交易(单个交易或者多个交易)进行共识，并在共识的结束环节中将共识结果反馈给该客户端。
[0055] 在联盟链场景中，共识过程可以由某个节点发起，即主要包括上述图4中的PRE-PREPARE、PREPARE和COMMIT过程。联盟链场景中，可以包括客户端或者不包括客户端。如果不包括客户端，可以不必具有图4中的REQUEST、REPLY的环节，而是在主节点收集一定量的交易后发起PBFT共识。如果包括客户端，共识过程可以不是由客户端发起，而是主节点收集一定量的交易后发起PBFT共识，即图4过程中的REQUEST并不直接导致PRE-PREPARE阶段的启动。
[0056] 如果主节点掉线或者作恶而不广播客户端的请求，客户端可以设置超时机制。如果超时的话，客户端可以向所有副本节点广播请求消息。副本节点检测出主节点作恶或者下线后，也可以发起View Change协议阶段，以更换主节点。
[0057] 此外，也可能由于主节点发起错误的提议导致PRE-PREPARE、PREPARE和COMMIT三阶段共识过程失败，或者，PREPARE、COMMIT阶段可能达不成Quorum数量的一致，也都无法完成共识。这些情况下也可能发起View Change协议阶段，以更换主节点。
[0058] View Change协议阶段，还需要考虑之前某个节点和其它节点处理不同步的问题，需要在View Change(也简称为VC)后恢复，如图5所示。例如，主节点Replica 0在VC前的视图V下对对应的propose m5已经进入committed状态，并已经执行了propose m5，而Replica 1可能由于网络延迟还没有对propose m5进入committed状态，而是prepared状态。Replica 2(以及3)可能对propose m5也是prepared状态。此后，Replica0宕机。这样，在不同节点上具有不完全相同的状态。更换主节点后，Replica 0可能重启恢复，主节点例如更换为Replica 1，则Replica 1-3需要跟上Replica 0的步伐，所以新的主节点Replica 1需要把处于prepared状态的propose m5重发一遍，让Replica 1-3执行完毕，才能与Replica 0的状态一致。否则，可能Replica 1-3在新视图V+1中对新的消息m6完成三阶段共识，而仅有replica 0之前对m5完成了执行，实际上replica 1-3并未完成对m5的执行，即Replica 1-3在新视图V+1中对新的消息m6的执行是在与replica 0不同的状态上开始的，这样就会出现不同节点上状态机的不一致，形成分叉。另外，上述过程中，如果Replica 0对m5只是prepared状态，即并没有在状态机上执行，其它Replicas比Replica 0处理的还慢，则Replica 0达成的prepared状态可以删除，而不影响全局的状态一致。
[0059] View Change协议阶段一般至少包括View-Change和New-View两个协议过程。这两个协议过程执行完毕后，完成更换主节点。更换主节点完成之后，视图编号加1，即更改为v+1，根据p＝(v+1)％N，主节点可以由如图4中的replica 0更换为replica 1。
[0060] 具体的，如图6所示，检测出主节点作恶或者下线的副本节点可以向其他副本节点广播消息。如图6中所示，replica 1检测到原主节点replica 0作恶或者下线，则replica 1向replica 0，replica 2和replica 3发送1,n,C,P,i>消息；类似的，replica 2向replica 0，replica 1和replica 3发送消息，replica 3向replica 0，replica 1和replica 3发送消息。
[0061] 其中，VIEW-CHANGE是协议标识，标识该协议是VIEW-CHANGE协议；v+1是下一视图的编号；n是最新的stable checkpoint(稳定检查点)的编号；C是2f+1验证过的CheckPoint消息的集合；P是可选项，如果有则表示当前发出VIEW-CHANGE消息的副本节点已经达到prepared状态的若干个消息的集合(对应每个prepared状态的，包括pre-prepare消息和2f个不同节点的签名)。
[0062] 当新的主节点p＝(v+1)mod|R|，例如此时为如图6中的replica 1，收到2f个有效的VIEW-CHANGE消息后，向其他节点广播消息。NEW-VIEW是协议标识，标识该协议是NEW-VIEW协议；v+1是下一视图的编号；V是新的主节点接收到的2f个不同节点发出的带签名的view-change消息，以及新的主节点自己要发出或已发出的对于v+1的view-change消息。O是主节点重新发起的未经完成的PRE-PREPARE消息的集合。p是当前节点的签名。PRE-PREPARE消息集合的选取规则包括：
[0063] 1.选取V中最小的stable checkpoint编号min-s，选取V中prepare消息的最大编号max-s。
[0064] 2.在min-s和max-s之间，如果存在P消息集合，则创建<,m>消息。否则创建一个空的PRE-PREPARE消息，即：<,m(null)>,m(null)是空消息，d(null)是空消息的摘要。
[0065] 副本节点收到主节点的NEW-VIEW消息，验证签名合法并且V中的view-change消息合法，O合法。如果合法的话，进入v+1状态，并且开始O中的PRE-PREPARE消息处理流程。
[0066] 以联盟链为例，联盟链场景中，一个节点可以对应一个或多个账号，当然，一个节点也可以不对应任何账号，而只是作为共识节点。此外，联盟链中可以存在创世合约或系统合约。创世合约和系统合约可以如前述所述产生。一般地，创世合约/系统合约中可以设置联盟链的共识节点列表，例如，设置共识节点的公钥的集合，并且该集合中的公钥按照某一特定顺序排列。联盟链中的各个共识节点，按照创世合约中设置的共识节点列表，可以在本地存储本地节点列表。每个共识节点在其本地的节点列表中，可以根据创世合约/系统合约中给定的特定顺序将各共识节点按照对应的公钥排列，从而，各共识节点各自本地节点列表中具有相同的共识节点并且这些共识节点按照相同顺序排列。而且，创世合约/系统合约中可以设置添加共识节点的方法和参数，从而，根据创世合约/系统合约，节点可以更改本地节点列表中的节点，从而完成添加节点的操作。
[0067] 当某一账号发起一个添加共识节点的请求，该请求例如是一个交易请求，第一已有共识节点可以接收该请求。所述请求例如可以是一个客户端发起的添加节点的交易请求，从而触发添加该待添加节点的过程，也可以是第一已有共识节点接收的控制台指令端发起的添加节点的交易请求，从而触发添加该待添加节点的过程。控制台一般可以由控制该节点的管理员操作，例如通过图形化或代码化的指令发起操作。需要说明的是，对于PBFT这类有主共识算法来说，第一已有共识节点一般为主节点。而第一已有共识节点可能是直接从客户端或控制台发来的交易请求，也可能是通过其它已有共识节点中转而接收的交易请求。对于HoneyBadgerBFT等无主的共识算法来说，不存在主节点，则第一已有共识节点为多个平等的共识节点中的一个。
[0068] 则如图7所示，联盟链中添加节点的过程包括如下：
[0069] S701：区块链网络中的第一已有共识节点接收添加节点的交易请求，并针对该添加节点的交易请求发起共识；达成共识后，已有共识节点执行所述添加节点的交易，在本地节点列表中已有共识节点的编号的基础上为所述待添加节点编号。
[0070] 所述交易请求，可以是调用合约的交易请求。该交易请求中，可以指明被调用的智能合约的地址，调用的方法和传入的参数。例如调用的合约为前述提到的创世合约/系统合约，调用的方法为添加节点的方法，传入的参数例如包括待添加节点的标识，IP地址,端口号等一个或多个。
[0071] 第一已有共识节点，可以通过接收添加节点的交易请求而触发添加节点的过程。例如，如前所述，第一已有共识节点可以通过接收客户端发起的添加节点的交易请求而触发添加该待添加节点的过程，也可以是第一已有共识节点通过接收控制台指令端发起的添加节点交易请求而触发添加该待添加节点的过程。控制台一般可以由控制该节点的管理员操作，例如通过图形化或代码化的指令发起操作。此外，第一已有共识节点也可以是收到待添加节点发来的所述待添加节点的相关信息，从而发起添加该待添加节点的过程。
[0072] 添加节点的交易请求一般会在区块链网络中基于底层的对等(peer-to-peer，P2P)网络传播至各共识节点。第一已有共识节点接收添加节点的交易请求后，作为有主共识算法的主节点或者无主共识算法的共识节点，可以发起共识过程。以PBFT这类有主共识算法为例，第一已有共识节点可以是主节点，可以针对包括该添加节点的交易请求发起共识过程，即主要包括上述图4中的PRE-PREPARE、PREPARE和COMMIT过程。
[0073] 完成共识后，区块链网络中的至少Quorum数量的共识节点都在本地具有了所述添加节点的交易请求中的消息内容，并达成了共识。并且，如果该添加节点的交易请求中的消息内容与其它消息一同构成共识的结果，则该添加节点的交易请求中的消息内容在不同节点上具有相同的消息顺序，即至少Quorum数量的共识节点对该添加节点请求中的消息内容和顺序都达成了共识。对添加节点请求中的消息内容和顺序都达成共识的意义在于，如果一个PRE-PREPARE消息中包含的消息包括至少两条添加节点的消息，例如分别添加节点m和节点n，通过主节点固定共识的消息的内容和顺序，节点m和节点n后续在不同共识节点的本地节点列表中具有相同的编号，既不会出现在一个共识节点的本地节点列表中节点m编号为4、节点n编号为5，而在另一个共识节点的本地节点列表中节点n的编号为4、节点m的编号为5的情形。
[0074] 在S701之后，如前所述，至少Quorum数量的共识节点对包括所述添加节点的交易请求中的消息内容达成了共识。进而，已有共识节点可以在本地执行相应的合约。例如，已有共识节点调用前述提到的创世合约/系统合约，在EVM之类的虚拟机中执行调用的创世合约/系统合约中指明的方法，并传入相应的参数。具体的，传入的参数例如包括待添加节点的标识，IP地址,端口号等。执行合约过程中，已有共识节点可以是在本地节点列表中已有共识节点的基础上将所述待添加节点的标识添加至列表尾部，并顺序编号。这样，至少Quorum数量的已有共识节点本地维护的共识节点列表中也已具有了相同顺序的待添加节点的相关信息。
[0075] 如前所述，已有共识节点可以在本地维护一个共识节点列表，即前述的本地节点列表，其中记载了当前区块链网络中所有共识节点的基础信息。具体的，这些基础信息例如可以包括共识节点的标识、IP地址、端口号等中的一个或多个。其中，共识节点在本地节点列表中可以是顺序编号的。一个共识节点一般具有一个标识(ID)，这个ID可以是能够唯一标识该节点的标识，例如可以是该节点的公钥、IP地址+端口号之类，当然也可以是其它内容。所述共识节点列表，在一些区块链项目中，可以从逻辑上存在于世界状态(world state)中。以以太坊、Fabric和一些联盟链的商业项目为例，每个节点在本地维护世界状态，在该世界状态中有最新的全部账户的状态。例如在以太坊中，节点可以根据区块中状态树、交易树和收据树的内容维护最新的全部账户的状态。
[0076] 由于此前已有共识节点已经进行过若干次共识，理论上各已有共识节点之间已经保持了共识节点列表的一致。例如，已有共识节点a、b、c、d，各自的世界状态中存储有本地节点列表，并且，已有共识节点a、b、c、d各自的本地节点列表中存储的已有共识节点均是a、b、c、d四个节点，并且都是a-b-c-d的顺序。那么，a、b、c、d的编号分别是0、1、2、3。这样，对于添加的节点m，各已有共识节点在本地维护的共识节点列表基础上，执行本申请实施例的S701和S702的过程，则各已有共识节点在本地节点列表中的节点均包括0、1、2、3、m共5个节点，且为所述待添加节点m的顺序设置的编号的顺序是相同的，例如都是4。
[0077] 执行合约过程中，除了上述提到的已有共识节点在本地节点列表中已有共识节点的基础上将所述待添加节点的标识添加至列表尾部并顺序编号的方式，还可以是将包括待添加节点在内的所有共识节点重新按照指定属性排序。例如，已有共识节点在EVM之类的虚拟机中执行指明的创世合约/系统合约中的方法，该方法定义了按照某一属性对本地节点列表中的所有节点重新进行排序。例如，已有共识节点a、b、c、d，各自的世界状态中存储有本地节点列表，并且，已有共识节点a、b、c、d各自的本地节点列表中存储的已有共识节点均是a、b、c、d四个节点，并且都是a-b-c-d的顺序。那么，a、b、c、d的编号分别是0、1、2、3。这样，对于添加的节点m，各已有共识节点在本地维护的共识节点列表基础上，执行本申请实施例的S701和S702的过程，则各已有共识节点在本地节点列表中的节点均包括a、b、c、d、m共5个节点。例如，创世合约/系统合约中的方法是将包括待添加节点在内的所有共识节点重新按照指定属性-公钥排序，即将公钥当成字符串来排序，从最高位开始比较，一直到最低位。例如，重新排序后的结果为a-b-m-c-d。这样，a、b、m、c、d的编号分别是0、1、2、3，4。可见，其中新加入节点m的编号为2，已有节点c、d的编号发生了改变，分别由2改为了3和由3改为了4。
[0078] S703：所述待添加节点同步区块链上的区块数据。
[0079] 经过本申请实施例的过程，待添加节点会加入区块链网络并成为其中的一个节点。如果该待添加节点加入区块链网络中并成为共识节点，即后续参与共识过程，则该待添加节点一般需要获得区块链网络的全部区块数据，并且获得该区块链网络中包括所有共识节点的列表。待添加节点获得区块链网络的全部区块数据，才能在本地的状态机中按照从创世区块到最新区块的顺序执行每笔交易，进而更新本地的世界状态。由于待添加节点执行的从创世区块到最新区块链的交易与其它共识节点从创世区块到最新区块中的交易相同，因此，待添加节点的世界状态能够保持与其它共识节点的世界状态相同。这样，该待添加节点后续成为共识节点后才能与其它已有共识节点保持相同的初始状态来执行后续的交易，并保持世界状态与其它已有共识节点的世界状态相同。
[0080] 待添加节点为了获得区块链网络的全部区块数据，可以向部分或全部相连接的已有节点发出同步请求，从而从已有节点上获取区块。一种简单的实现方式，所述待添加节点可以向某一相连接的已有节点发出同步请求，从而从该已有节点上获取全部的区块数据。
[0081] 此外，为了高效，可以类似于P2P传播原理，所述待添加节点向不同的已有节点发出获取不同区块的同步请求，同步请求的总和是获取全部区块。例如，一共有从0到9共10个区块，所述待添加节点可以向已有节点1请求获取0-3号区块，向已有节点2请求获取4-6号区块，向已有节点3请求获取7-10号区块。这样，所述待添加节点从不同已有节点上获取不同区块后，可以组成全部的区块。
[0082] 全部的区块一般包括从创世区块开始到最新产生的区块的所有区块。待添加节点可以通过checkpoint消息来判断是否完成了区块的同步。
[0083] 在前述的PBFT三阶段过程中，每个Replica在发出一个消息或者接收到其它节点发来的消息(包括pre-prepare、prepare、commit消息)时，都会在Replica本地内存的Message Log中做记录。随着PBFT的进行，Log会占用较大内存空间。所以为了节省内存空间，需要做垃圾回收，即在Replica执行完propose时，清空Log。一种方式是，某个Replica每执行完1条propose，向其它节点发出广播，就是否可以清除Log在全网达成一致。每个Replica收到广播后也向其它Replicas广播。如果收到Quorum数量不同节点的确认，这些节点就删除本地Log中的K条propose对应的消息记录。另一种方式是，某个Replica每执行完K条propose，向其它节点发出广播，就是否可以清除Log在全网达成一致。每个Replica收到广播后也向其它Replicas广播。如果收到Quorum数量不同节点的确认，这些节点就删除本地Log中的K条propose对应的消息记录。上面的清除Log的消息即checkpoint消息，格式为。其中，n是当前节点期望保留的最小的一个Sequence number，d是期望保留的消息摘要，i是发出checkpoint消息的Replica编号。Replica发出的checkPoint消息和接收到checkPoint消息的都记录到Message Log中。如果Replica i收到不同节点发来的Quorum-1个合法的checkPoint消息，加上自己发出的checkPoint消息，Log中针对的checkpoint消息达到Quorum数量，则清除日志中n之前的所有消息(包括pre-prepare、prepare、commit消息，还可以包括checkpoint消息)。
[0084] 前述提到的待添加节点可以通过checkpoint消息来判断是否完成了区块数据的同步，具体的，待添加节点可以在接收到不同节点发来的Quorum-1个合法的checkPoint消息，其中的n与待添加节点自身同步到的区块中的最大n值一致时，可以确定完成了区块的同步。
[0085] 此外，checkpoint消息中也可以直接指明当前最新的区块号。待添加节点可以在接收到不同节点发来的Quorum-1个合法的checkPoint消息，其中的指明的当前最新区块号与待添加节点自身同步到的区块中的最大区块号一致时，可以确定完成了所有区块的同步。
[0086] 当然，待添加节点也可以向其它节点发出查询当前最大区块号的请求，通过大多数节点反馈的相同的最大区块号与本地最大区块号一致来判断完成了区块的同步。
[0087] 需要说明的是，S701和S703并没有严格的先后顺序，可以异步/并行执行。
[0088] S705：所述已有共识节点发起视图切换。
[0089] S701中，已有共识节点执行所述添加节点的交易后，会更新本地节点列表。当前视图中，仍然是原有的参与共识的节点及顺序。这样，已有共识节点执行所述添加节点的交易后，会检测到本地共识节点列表中的共识节点数量与当前视图中的共识节点数量存在不一致，或检测到本地共识节点列表中的共识节点标识与当前视图中的共识节点标识存在不一致。这样，已有共识节点可以发起视图切换。
[0090] 当然，也可以是待添加节点同步完成区块链上的区块数据后，广播一条“发起视图切换”的消息至区块链网络，表明待添加节点已完成同步，具备了加入区块链网络并作为共识节点的能力，请求发起视图切换，从而，已有共识节点在收到该消息后可以发起视图切换过程。
[0091] 其中，视图切换过程中的R(即视图切换过程中的副本集合个数)为包括待添加节点的共识节点总数，也即本地节点列表中包括待加入节点的节点数量。
[0092] 类似前面所述，已有共识节点可以向其他副本节点广播消息。n是最新的stable checkpoint(稳定检查点)的编号，C是2f+1个验证过的CheckPoint消息集合，P是当前副本节点未完成的请求的PRE-PREPARE和PREPARE消息集合。
[0093] 假设已有共识节点包括节点0、1、2、3，待添加节点为节点4。节点0例如是PBFT中的主节点(Primary)，节点1、2、3例如是PBFT中的备份节点。可以通过p＝(v)mod|R|计算得到新的主节点的编号。这里的R为本地节点列表中包括待加入节点的节点数量。例如，之前一共有4个已有共识节点，编号分别为0、1、2、3。每个已有共识节点在本地的节点列表中都记录了0、1、2、3共四个节点的编号。该情况下，R＝4。执行本实施例的S701～S705后的一个例子中，每一已有共识节点在本地节点列表中已有共识节点的编号的基础上可以为待添加节点顺序编号，即可以将所述待添加节点顺序编号为4。该情况下，R变为了5。发起视图切换过程中的视图编号递增，即如前所述，由v变为v+1。
[0094] 在S701中调用创世合约/系统合约时，调用的方法为添加节点的方法，共识完成之后，已有共识节点执行所述添加节点的交易，在本地节点列表中已有共识节点的编号的基础上为所述待添加节点编号，添加的节点在本地节点列表中可以初始化为默认的未激活状态。进而，待添加节点可以通过发起交易请求的方式尝试激活待添加节点，已有共识节点也可以在达成共识后通过执行相应交易来将新添加的节点由未激活状态更改为已激活状态。
[0095] 这样，S703和S705之间，还可以包括：所述待添加节点同步完成区块链上的区块数据后发送激活节点的交易请求至区块链网络，所述已有共识节点对所述激活节点的交易请求完成共识后并执行。
[0096] 待添加节点完成了所有区块数据的同步之后，可以发送激活节点的交易请求至区块链网络。具体的，待添加节点可以通过自身节点的账号发送激活节点的交易请求至区块链网络。与前述添加节点的交易请求类似的，激活节点的交易请求中也可以是调用合约的交易。相应的，创世合约/系统合约中已存在激活节点的方法。所述激活节点的交易请求可以指明调用的创世合约/系统合约中的方法，并可以包括节点标识,节点IP地址,节点端口号等参数。
[0097] 类似的，激活节点的交易请求一般会在区块链网络中基于底层的对等(peer-to-peer，P2P)网络传播至各共识节点。已有共识节点可以对所述激活节点的交易请求发起共识。以PBFT这类有主共识算法为例，第一已有共识节点可以是主节点，可以针对包括该激活节点的交易请求发起共识过程，即主要包括上述图4中的PRE-PREPARE、PREPARE和COMMIT过程。
[0098] 完成共识后，区块链网络中的至少Quorum数量的共识节点都在本地具有了所述添加节点的交易请求中的消息内容，并达成了共识。进而，已有共识节点可以在本地调用相应的合约并执行。例如，已有共识节点调用前述提到的创世合约/系统合约，在EVM之类的虚拟机中执行调用的创世合约/系统合约中指明的方法，并传入相应的参数。具体的，传入的参数例如包括前述提到的节点标识，节点IP地址,节点端口号等。执行合约的过程中，已有共识节点在本地节点列表中将指明的处于未激活状态的节点的状态设置为已激活。进而，已有共识节点会检测到本地共识节点列表中的激活的共识节点数量与当前视图中的激活的共识节点数量存在不一致，或检测到本地共识节点列表中激活的的共识节点标识与当前视图中激活的共识节点标识存在不一致。这样，已有共识节点可以发起视图切换。
[0099] 需要说明的是，激活节点的交易请求通过共识后会形成一个新的区块(该区块中还可能包括除所述激活节点的交易以外的其它交易)。该新生成的区块经过共识后存在于至少Quorum个已有共识节点上，而并不存在于所述刚激活的节点(即之前的待添加节点)。这是因为，刚激活的节点在激活之前并没有参与共识。于是，待添加节点可以在S702之后继续向部分或全部相连接的已有节点发出同步请求，从而从已有节点上获取区块。这样，待添加节点可以获取到包含所述激活节点交易请求的区块。
[0100] S707：所述视图切换完成后，所述待添加节点参与共识。
[0101] 视图切换完成之后，包括待添加节点在内的各共识节点本地各自存有相同的节点编号列表，且具有相同的区块数据，从而待添加节点可以参与共识，即与已有共识节点共同进行共识。这样，就完成了添加节点的过程。
[0102] 根据上述本发明实施例，本申请实施例视图切换完成之后，包括待添加节点在内的各共识节点本地各自存有相同的节点编号列表，且具有相同的区块数据，从而待添加节点可以参与共识，即与已有共识节点共同进行共识。这样，就完成了添加节点的过程。
[0103] 图8示出了本申请一种区块链系统实施例的架构图，包括：
[0104] 一种区块链系统，包括：
[0105] 第一已有共识节点801，用于接收添加节点的交易请求，并针对该添加节点的交易请求发起共识；达成共识后，已有共识节点执行所述添加节点的交易，在本地节点列表中已有共识节点的编号的基础上为所述待添加节点编号；
[0106] 所述待添加节点802，用于同步区块链上的区块数据；
[0107] 所述已有共识节点803，用于发起视图切换；
[0108] 所述视图切换完成后，所述待添加节点802参与所述区块链的共识过程。
[0109] 其中，所述添加节点的交易请求包括调用合约的交易请求。
[0110] 其中，所述调用的合约包括创世合约或系统合约。
[0111] 其中，所述第一已有共识节点801接收添加节点的交易请求，包括：
[0112] 第一已有共识节点801接收客户端发起的添加节点的交易请求；或，
[0113] 第一已有共识节点801接收控制台指令端发起的添加节点的交易请求。
[0114] 其中，已有共识节点803在本地维护有节点列表，所述节点列表中包括共识节点的标识、IP地址、端口号中的一个或多个；其中，共识节点在本地节点列表中顺序编号。
[0115] 所述共识节点在本地维护的节点列表位于世界状态中。
[0116] 其中，已有共识节点801执行所述添加节点的交易，在本地节点列表中已有共识节点的编号的基础上为所述待添加节点编号，包括：
[0117] 已有共识节点执行所述添加节点的交易，在本地节点列表中已有共识节点的基础上将所述待添加节点的标识添加至列表尾部并顺序编号；
[0118] 或，
[0119] 已有共识节点执行所述添加节点的交易，在本地节点列表中将包括所述待添加节点在内的所有共识节点重新按照指定属性排序。
[0120] 所述待添加节点802同步区块链上的区块数据包括：
[0121] 所述待添加节点802向连接的一个已有节点发出同步请求，从该已有节点上获取全部区块数据；或，
[0122] 所述待添加节点向不同的已有节点发出获取不同区块的同步请求。
[0123] 其中，待添加节点802通过checkpoint消息判断是否完成了区块数据的同步，或向其它节点发出查询当前最大区块号的请求，通过大多数节点反馈的相同的最大区块号与本地最大区块号一致来判断完成了区块的同步。
[0124] 其中，所述已有共识节点803检测到下面任一情形时发起视图切换：
[0125] 本地共识节点列表中的共识节点数量与当前视图中的共识节点数量存在不一致；或，
[0126] 本地共识节点列表中的共识节点标识与当前视图中的共识节点标识存在不一致。
[0127] 其中，所述已有共识节点803接收到所述待添加节点广播的“发起视图切换”的消息后发起视图切换。
[0128] 其中，所述待添加节点802同步完成区块链上的区块数据后发送激活节点的交易请求至区块链网络，所述已有共识节点对所述激活节点的交易请求完成共识后并执行。
[0129] 其中，所述已有共识节点801检测到下面任一情形时发起视图切换：
[0130] 本地共识节点列表中的激活的共识节点数量与当前视图中的激活的共识节点数量存在不一致；或，
[0131] 本地共识节点列表中激活的的共识节点标识与当前视图中激活的共识节点标识存在不一致。
[0132] 其中，视图切换过程中的副本集合个数为包括待添加节点的共识节点总数。
[0133] 上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
[0136] 计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
[0137] 还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
[0138] 上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
[0139] 在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
[0140] 应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
[0142] 本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
[0143] 以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 硫酸钙尿素颗粒及其制备和使用方法 | 2020-05-08 | 165 |
| 一种扬声器 | 2020-05-08 | 11 |
| 带宽压缩中的预测方法 | 2020-05-08 | 240 |
| 一种智能路由方法 | 2020-05-08 | 701 |
| 一种降低稳态误差的定时同步方法 | 2020-05-08 | 322 |
| 带宽压缩中的后选择预测方法 | 2020-05-08 | 5 |
| 一种基于CML的智能变电站设备网络结点连锁失效风险分析方法 | 2020-05-08 | 383 |
| 用于固定冷却元件的系统 | 2020-05-08 | 845 |
| 采用碳材料的高充电接受能力铅酸蓄电池 | 2020-05-11 | 535 |
| 一种自产供电电源相电压跌落计算方法 | 2020-05-11 | 979 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
QQ群二维码
意见反馈
意见反馈