有许可区块链中的优先级的制作方法

本申请总体上涉及有许可的区块链，并且更具体地涉及有许可的区块链中的优先级。

背景技术：

区块链可以用作公共分布式账本(ledger)来存储信息。虽然主要用于金融事务，但区块链可以存储与商品和服务(即产品、包装、状态等)相关的各种信息。去中心化的方案为去中心化的网络提供权限和信任，并使其节点能够连续并顺序地将其事务记录在公共“块”上，从而创建了称为区块链的独特“链”。密码通过散列码用于确保事务源的身份验证并去除中央中介。区块链是一个分布式数据库，维护着区块链的块中记录的不断增长的列表，由于其不可变的属性，可以防止篡改和修订记录。每个块都包含一个时间戳和一个到前一个块的链接。区块链可用于保存、跟踪、转移和验证信息。由于区块链是分布式系统，因此在将事务添加到区块链分布式账本之前，所有对等方都需要达成共识状态。

传统上，优先级被用于许多类型的网络中，因为并非所有的“要处理的请求”和“要存储的数据”都具有同等的重要性。需要以去中心化的方式确定和实施优先级。直接应用现有技术会将区块链网络退化为中央控制系统。有许可的区块链网络是复杂的分布式系统，具有多个交互的异构流程/组件，例如事务执行、共识、分布式账本验证和提交阶段。实施工作需要在事务处理的多个阶段实施优先级，因为在一个组件中实施优先级可能无法转化为差异化服务。当前，所有与区块链事务相关的请求都具有同等重要性，更具体地说，以固定顺序的顺序方式进行。但是，在某些情况下，快速跟踪或减慢区块链中的事务会很有用。关键事务可能需要优先于正常事务(例如，金融、医疗保健等)。系统事务可能需要优先于客户端事务。更改系统状态的写入事务可能需要优先于查询(读取)事务。

无许可的区块链系统具有使用事务费用/加密货币来实现优先级划分的自然方法。例如，为事务支付的更高费用使区块链矿工有更大的动机将该事务添加到区块中，并且该事务将比其他事务执行得更快。当事务超过更高奖励的事务时，事务可能会无限期推迟。这种方法在旨在保证一旦提交事务就执行的有许可的区块链网络中是不切实际的。

因此，在本领域中需要解决前述问题。

技术实现要素：

从第一方面来看，本发明提供了一种在区块链中确定优先级的方法，该方法包括：识别需要对等方背书的区块链事务；向分配给区块链的一个或多个对等方发送背书请求；从一个或多个对等方接收背书响应消息，其中背书响应消息包括分配给区块链事务的多个优先级；将接收到的多个优先级和区块链事务转发至订购节点以分配给对等方。

从另一方面来看，本发明提供一种用于在区块链中确定优先级的设备，该设备包括：处理器，被配置为识别需要对等方背书的区块链事务；发送器，被配置为向分配给区块链的一个或多个对等方发送背书请求；接收器，被配置为从一个或多个对等方接收背书响应消息，其中背书响应消息包括分配给区块链事务的多个优先级；其中发送器还被配置为将接收到的多个优先级和区块链事务转发至订购节点以分配给对等方。

从另一方面来看，本发明提供了一种用于在区块链中确定优先级的计算机程序产品，该计算机程序产品包括可由处理电路读取的计算机可读存储介质并存储用于由处理电路执行的指令以执行用于执行本发明步骤的方法。

从另一方面来看，本发明提供了一种存储在计算机可读介质上并且可加载到数字计算机的内部存储器中的计算机程序，包括软件代码部分，当该程序在计算机上运行时的，用于执行本发明的步骤。

一个示例实施例可以提供一种方法，包括以下一个或多个：识别需要对等方背书的区块链事务，向分配给区块链的一个或多个对等方发送背书请求，从一个或多个对等方接收背书响应消息，其中背书响应消息包括分配给区块链事务的多个优先级，并将接收到的多个优先级和区块链事务转发至订购节点以分配给所述对等方。

另一示例实施例可以包括一种装置，包括：处理器，被配置为执以下一个或多个：识别需要对等方背书的区块链事务；向分配给区块链的一个或多个对等方发送背书请求；从一个或多个对等方接收背书响应消息，其中背书响应消息包括分配给区块链事务的多个优先级；将接收到的多个优先级和区块链事务转发至订购节点以分配给对等方。

另一示例实施例可以包括一种非暂时性计算机可读存储介质，被配置为存储指令，指令在被执行时使处理器执行以下一项或多项操作：识别需要对等方背书的区块链事务；向分配给区块链的一个或多个对等方发送背书请求；从一个或多个对等方接收背书响应消息，其中背书响应消息包括分配给区块链事务的多个优先级；将接收到的多个优先级和区块链事务转发至订购节点以分配给对等方。

附图说明

现在将参考附图仅以示例的方式描述本发明的实施例，其中：

图1a示出了根据示例实施例的区块链事务优先级分配的逻辑网络图。

图1b示出了根据示例实施例的在区块链事务优先级分配期间执行的一组操作的系统配置图。

图2a示出了根据示例实施例的用于事务优先级分配场景的示例对等节点区块链架构配置。

图2b示出了根据示例实施例的示例对等节点区块链配置。

图3是示出根据示例实施例的有许可的区块链网络的图。

图4示出了根据示例实施例的用于执行事务优先级分配的系统消息图。

图5a示出了根据示例实施例的在区块链中的区块链事务优先级分配的示例方法的流程图。

图5b示出了根据示例实施例的在区块链中的区块链事务优先级分配的另一示例方法的流程图。

图6a示出了根据示例实施例，被配置为根据本文描述的一个或多个操作在区块链上执行各种操作的示例物理基础设施。

图6b示出了根据示例实施例的，在缔约方和被配置为在区块链上执行智能合约条款的中介服务器之间的示例智能合约配置。

图7示出了被配置为支持一个或多个示例实施例的示例计算机系统。

具体实施方式

将容易理解的是，如本文的附图中总体上描述和示出的即时组件可以以多种不同的配置来布置和设计。因此，如在相关联的附图和说明书中所表示的方法、装置、非暂时性计算机可读介质和系统的实施例的详细描述并非旨在限制本申请的范围，而仅代表所选实施例。

在整个说明书中描述的即时特征、结构或特性可以在一个或多个实施例中以任何合适的方式组合。例如，在整个说明书中，短语“示例实施例”、“一些实施例”或其他类似语言的使用是指以下事实：结合该实施例描述的特定特征、结构或特性可以包括在至少一个实施例中。因此，在整个说明书中，短语“示例实施例”、“在一些实施例中”、“在其他实施例中”或其他类似语言的出现不一定都指同一组实施例，并且可以在一个或多个实施例中以任何合适的方式组合所描述的特征、结构或特性。

另外，尽管在实施例的描述中可能已经使用术语“消息”，但是本申请可以应用于多种类型的消息或网络数据，例如分组、帧、数据报等。在示例性实施例中可以描绘某些类型的消息、信令和协议，它们不限于特定类型的消息、信令或协议。

示例实施例提供了支持具有选择性对等方管理程序的区块链分布式系统的方法、设备、网络和/或系统。区块链是一个分布式系统，包含多个相互通信的节点。区块链操作称为链码的程序(例如，智能合约等)、保存状态和分布式账本数据并执行事务。一些事务是在链码上调用的操作。一般而言，区块链事务通常必须由某些区块链成员“背书”，并且只有背书的事务才能提交给区块链并影响区块链的状态。其他未被背书的事务将被忽略。可能存在一个或多个用于管理功能和参数的特殊链码，统称为系统链码。

节点是区块链系统的通信实体。在不同类型的多个节点可以在同一物理服务器上运行的意义上，“节点”可以执行逻辑功能。节点在信任域中分组，并与以各种方式控制它们的逻辑实体相关联。节点可以包括不同类型，例如客户端或提交客户端节点，向背书方(例如，对等方)提交事务-调用，并且将事务-建议广播到订购服务(例如，订购节点)。另一类节点是对等节点，可以接收客户提交的事务，提交事务并维护状态和区块链事务分布式账本的副本。尽管不是必需的，但对等方也可以充当背书方的角色。订购服务节点或订购者是为所有节点运行通信服务的节点，并实现交付保证，例如在提交事务和修改区块链的世界状态时向系统中的每个对等节点广播。

分布式账本是区块链的所有状态转换的有序、防篡改记录。状态转换可以由参与方(例如，客户端节点、订购节点、背书方节点，对等节点等)提交的链码调用(即，事务)引起。事务可能导致一组资产键值对作为一个或多个操作数(例如创建、更新、删除等)被提交到分布式账本。分布式账本包括一个区块链(也称为链)，用于将不可变、顺序的记录存储在块中。分布式账本还包括一个状态数据库，用于维护区块链的当前状态。每个通道通常有一个分布式账本。每个对等节点都为其所属的每个通道维护一个分布式账本的副本。

链作为事务日志被构造为哈希链接的块，并且每个块包含n个事务的序列，其中n等于或大于1。块头部包括块事务的哈希值，以及前一个块头部的哈希值。以这种方式，账本上的所有事务都可以被排序并加密地链接在一起。因此，在不破坏哈希链接的情况下不可能篡改帐本数据。最近添加的区块链块的哈希表示链上之前发生的每笔事务，从而可以确保所有对等节点处于一致且受信任的状态。链可以存储在对等节点文件系统(即本地、附加存储、云等)上，从而有效地支持区块链工作负载的仅附加性质。

不可变账本的当前状态表示链事务日志中包括的所有键的最新值。由于当前状态表示通道已知的最新键值，因此有时将其称为世界状态。链码调用针对账本的当前状态数据执行事务。为了使这些链码交互有效率，可以将键的最新值存储在状态数据库中。状态数据库可能只是链中事务日志的索引视图，因此可以随时从链中重新生成。可以在对等节点启动时以及在接受事务之前自动恢复(或根据需要生成)状态数据库。

示例实施例提供了一种方法、设备、系统和计算机平台，用于区块链对等方以去中心化的方式向未决的区块链事务分配优先级，并在区块链网络内的事务处理的不同阶段实施优先级。每个对等方提供的已分配优先级可以基于其他网络单元上的静态规则和/或动态系统规则。这样分配的优先级将合并为一个“最终”优先级，以便根据优先级合并策略进行分配并用于管理事务。在事务的订购/共识期间以及在区块链事务提交之前进行事务验证期间，将此类合并策略。在订购过程中的实施使订购/订购者节点的订购服务可以基于优先级感知块形成策略从各种可用优先级中选择事务。这种优先级感知块形成策略可确保不同的对等方在形成一个块时从多个不同的优先级队列中读取同一组事务。优先级的分配还可以在以后的某个时间点进行审核，因为它们作为区块链上事务的一部分得以保留。

在一个实施例中的即时应用涉及有许可的区块链，并且在另一实施例中涉及在有许可的区块链中的优先化。

图1a示出了根据示例实施例的区块链事务优先级分配的逻辑网络图。参考图1a，配置100包括管理向对等方的事务委托的客户端110，对等方包括但不限于订购者、提交者和背书方。在操作中，客户端节点110向作为优先级实施模块112的一部分而不是一个或多个背书对等方的订购者节点(111、113、115)发送背书请求105。背书请求和响应被存储在由多队列块生成器116创建的块中，并且对等方在从订购者节点接收到块之后执行背书而不是从客户端直接请求，然后将响应发送到订购者/订购节点。每个客户端可以通过监控对等方的相对处理速度来执行监控和重新平衡，包括比较每个事务的背书请求和响应的块高。结果，可以通过以对那些对等方识别出的处理速度降序的顺序向那些识别出的对等方发送背书请求来执行对等方的选择。

当客户端节点或实体提议/发送新的区块链事务请求101到一组“背书方”对等方时。每个对等方可以使用优先级计算器124，并且那些背书方对等方(121、123、125)为事务分配优先级，并在事务中嵌入背书响应消息103。背书方可以基于已实施的策略静态地确定优先级，或者背书方可以根据本地知识(例如，当前事务负载大小)动态地确定优先级。每个背书方可以在其响应背书消息中为事务分配相同或不同的优先级。在一个示例中，如果有四个背书方可以访问事务，则每个都可以为事务分配不同的优先级，或者三个可以为事务分配相同的优先级，或者所有背书方可以分配相同的优先级，等等。背书方对策略的初始分配可以被每个对等方在决定何时执行事务120时认为是软优先级的实施。

背书方可以用来确定优先级的标准的一些示例可以包括链码id、调用的特定功能、优先于读取事务的写入事务(例如，出于审计目的将具有空写集的查询写入事务日志)和/或当前遇到的待处理事务的网络负载。对等背书方可以利用本地计算的优先级来首先执行具有更高优先级的事务，例如优先级的软实施。客户端收到所有背书和优先级分配，并检查结果的完整性。客户端可以捆绑优先级，并将所有信息与事务一起转发至“订购者”对等方/共识提供方。

订购者和背书方实体处的优先级合并器114使用优先级合并策略140决定最终优先级。最终优先级由背书方使用第二轮背书确定。定购者在块形成期间实施优先级排序，并为每个优先级维护单独的队列118，并根据最终优先级分配过程将事务发送到相应的队列118。订购者对等方根据优先级感知块形成策略从不同的优先级队列中读取事务，该策略描述要包含在块中的每个优先级中的事务数。多队列块生成器116形成一个或多个块。所有订购者应从不同优先级队列中选择同一组事务以形成一个块。为了支持此过程，在此多队列配置中使用了截止时间(ttc)同步消息。事务可以包括写入事务107和读取事务109。将块传送111到验证器134以用于优先级实施130。验证器/提交器节点(131、133、135)利用分配给每个事务的策略，在经由优先级化验证器134的验证排序和执行过程中实施优先级，当块中存在冲突时将选择优先级较高的事务而不是优先级较低的事务，这是事务并行验证的一种形式。最终，一旦由背书方分配了初始优先级并且由订购者选择了最终优先级，就将事务提交给分布式账本136。

当决定分配给特定事务的优先级时，第一种方法可以是基于各种参数来确定优先级的静态方法，诸如链码-id，确定是否是读取/写入集和/或客户端-id。可以通过配置文件指定决定优先级的策略，配置文件被检索并用于证明该策略决定的合理性。优先级也可以动态确定，其中每个对等方根据每个客户端id的事务数、给定对等方的系统负载、从无法识别/首选客户端收到的事务来确定优先级。背书方可以决定分配给事务的优先级，并将其作为对客户的背书请求的建议响应的一部分发送，然后将事务转发到订购服务以进行最终的优先级和提交操作。背书方可以在建立优先级时提供签名。

静态优先级分配的一个示例可以提供将某些事务标识为：事务“a”：#读取10，#写入2，事务b：#读取2，#写入10。结果是，根据每个事务中的读写次数，将事务a的优先级设置为“3”，将事务b的优先级设置为“1”。对优先级方案策略来说写入比读取更为重要。接下来，订购者为事务接收不同和/或相同的背书优先级，并且必须确定最终优先级。在另一个示例实施例中，还可以在背书方处使用第二轮背书进行优先级合并以最终确定优先级，其中，客户将从背书方收到的优先级打包并发送回每个背书方，以进行最终优先级计算。在一个特定的优先级示例中，假设背书方集为：e＝{a,b,c,d}，则某些示例策略可以占'n'的多数(n/2+)。优先级将按顺序进行考虑，例如a>b>c>d，如果a被背书，则将考虑其优先级，否则，将考虑b的优先级，依此类推。对于某些权重(a＝40,b＝30,c＝20,d＝10)，平均sum(all)/n。

根据示例实施例，存在与n个优先级相对应的n个队列。当发布到队列中时，订购者会从接收到的事务中读取优先级值，并根据分配的大多数优先级、中位优先级或其他优先级隔离操作将事务发布到适当的优先级队列中。订购者读取队列并形成块。可以在策略中定义要包括在块中的每个优先级的事务数量。订购者根据百分比、批次大小和/或超时来形成块。订购者首先尝试通过包含每个优先级的预期事务数来形成该块。如果在达到预期的事务数之前存在超时，则会向所有队列发送截止时间块号“n”(ttc-n*)消息。该块首先包括预期的事务数量，以及每个主题在ttc之前可用的事务。其余事务取自在ttc-n之前的剩余事务中具有最高优先级的主题。

当实施优先级时，一个示例可以提供例如，如果三个优先级<高，中，低>的百分比为<100、0、0>，并且形成一个块的批次大小为100，则当订购者从高优先级队列中观察到100个事务时，订购者应立即形成该块。如果在看到100个高优先级事务之前存在超时，则订购者将向所有队列发送ttc-n消息。在ttc-n消息之前，高优先级队列中有60个事务，中优先级队列中有20个事务，低优先级队列中有50个事务。现在，该块包括来自高优先级队列的60个事务，来自中优先级队列的20个事务和来自低优先级队列的20个事务。在此示例中，所有高优先级队列事务以及相等数量的中优先级和低优先级事务都与该块一起使用。

在块管理的另一示例中，元组百分比可以是<50、30、20>。如果订购者在高优先级队列中观察到至少50个事务，在中优先级队列中观察到30个事务，在低优先级队列中观察到20个事务，它将立即形成该块。如果任何存储桶在超时时未满，则将ttc-n消息发送到所有队列。假设在ttc-n之前，高优先级队列中有55个事务，中优先级队列中有50个事务，低优先级队列中有10个事务，现在形成的块将包括来自高优先级队列的55个事务，来自中优先级队列的35个事务和来自低优先级队列的10个事务。

可替代地，可以由客户端或在事务的最后阶段(提交者)来确定优先级。客户端还可以为它认为是次重要或更重要的事务提出优先级。假设订购者可能是恶意的，并且有一种方法可以从分布式账本中恢复，则还可以在订购者中执行优先级验证，其中可以在每个订购者中独立验证最终优先级计算，并可以执行检查以确定事务的最终优先级是否与最初从队列中读取的队列匹配。在确定任何违规问题时，可以删除该事务。有关此配置的一些基本假设包括多对等方分布式区块链系统，其中一个对等方可以具有一个或多个角色(例如，背书方、提交者、订购者)，提供“总订购”的分布式队列，并且所有消费者都使用同一消息集合。

背书方在决定初始优先级时可以使用的可能标准可以基于各种不同的标准。例如，关于链码、与特定链码(智能合约)有关的事务可能比与某些其他链码有关的事务具有更高的优先级。例如，由系统链码执行的系统配置更新事务，与与任何其他链码相关的事务相比，背书方可以为其分配更高的优先级。在关于链码中的功能的另一示例中，存在多个功能，并且与调用同一链码中的其他功能的事务相比，调用特定功能的事务可能被分配更高的优先级。例如，如果有一个用于医院管理的链码，并且在该链码内有两个函数admitpatienttoemergency”和“dischargepatient”。结果，与“admitpatienttoemergency”功能有关的事务可以被赋予比与“dischargepatient”功能有关的事务更高的优先级。

对于具有空写集的读取/查询事务，在这种情况下，可以将背书方配置为提供必须对某些变量执行系统更新“写入”的事务，这比必须简单地“读取”变量的事务具有更高的优先级。当读取事务的优先级高于写入事务的优先级时，也可以使用反向策略。对于当前的经验负载示例，此处的背书方可能以这样的方式配置：如果它知道在一段时间内没有看到任何优先级为1(即最高优先级)的事务，甚至没有在这种情况下，第二优先级#2(优先级低于优先级#1)可以移至优先级#1。同样，可以将背书方配置为通过使用这些策略中多个策略的组合来决定优先级。

通常，根据示例实施例，考虑两种主要类型的策略，包括优先级策略和优先级合并策略。优先级策略是示例策略注意事项中概述的策略类型。例如，如果优先级策略仅基于链码id决定优先级，则策略文档将声明：“chaincode1”->priority1；“chaincode2”->priority1；“chaincode3”->priority2，依此类推。另一个策略是优先级合并策略。

订购者使用优先级合并策略确定最终优先级。优先级策略和优先级合并策略都存储在两个单独的文件中。这些文件是策略文件。背书方使用第一个策略文件来确定初始优先级分配，订购者使用第二个策略文件来确定最终优先级。背书方集合为：e＝{a,b,c,d}，某些示例策略可以是'n'中的多数(n/2+)。优先级将按顺序进行考虑，例如a>b>c>d，如果a被背书，则考虑其优先级，否则，将考虑b的优先级，依此类推。对于某些权重(a＝40,b＝30,c＝20,d＝10)，平均值为sum(all)/n。在上述示例中，有四个背书方a,b,c和d。因此，以“e”表示的背书方集合包含4个元素。因此，e＝{a,b,c,d}。现在，样本优先级合并策略可以是：样本策略1：'n'中占多数(n/2+)，有四个背书方，在此示例中n＝4，并且如果2(n/2)或大于2个背书方同意某些优先级，则是最终优先级。对于样本策略2，将按优先级考虑优先级，例如a>b>c>d。请注意，客户端可以选择不接受集合e中一个或多个背书方的背书。在这种情况下，如果指定了这种优先级合并策略，并且客户端从背书方“a”获得背书，则“a”分配的任何优先级都被视为最终优先级。同样，如果缺少来自背书方“a”的背书，并且采用了来自“b”的背书，则背书方“b”分配的优先级将被视为最终优先级，依此类推。在另一个具有特定权重(a＝40,b＝30,c＝20,d＝10)的示例策略3中，在这种策略中，每个背书方都被分配了一些权重，因此，如果背书方“a”表示优先级应该是#1，但是b，c和d投票认为优先级应该是#2，因此，如果背书方“a”表示优先级应为#1，但b，c和d投票赞成优先级应为#2，因为相对于优先级#1而言，有40个权重(来自背书方a)但相对于优先级#2而言，有60个权重(来自背书人b，c和d)。在另一个示例中，样本策略4的平均总和sum(all)/n。这是一个基于平均的简单策略，因此，如果“a”表示优先级#2，“b”表示优先级#2，c表示优先级#3，d表示优先级#1，则最终优先级为平均值(2+2+3+1)/4＝2。

策略管理的系统配置可以配置为在块中包括一定数量的每个优先级的事务。因此，例如，如果块大小为100个事务，并且有三个优先级，那么我们将在一个块中包括50个优先级为#1的事务，30个优先级为#2的事务和20个优先级为#3的事务。现在，该比例为50:30:20，可以将其定义为配置。理想情况下，每个队列中至少要有一个事务包含在一个块中，以免忽略任何区块链成员。如果在某个时间段内希望停止某个特定优先级的事务，则可以相应地指定事务操作比率。例如，如果在上述示例中比率为50:50:0，则优先级为3的事务将不包含在任何块中。因此，直到并且除非在一段时间后更新该比率，假设每个优先级为#1和#2的事务有50个可用于填充每个块，则将完全不处理优先级为#3的事务。换句话说，根据容纳优先级#1和#2的事务后的任何剩余容量，优先级#3严格来说将是尽力而为方案。

图1b示出了根据示例实施例的在区块链事务优先级分配期间执行的一组操作的系统配置图。参考图1b，系统配置150包括客户端152，背书对等方154，订购者156和提交对等方158。最初，客户端152将用于优先级分配的事务提交给背书的对等方154。事务请求可以包括客户id、链码id、事务有效载荷、时间戳和客户签名162。背书对等方154可以基于已知数据模拟事务并计算优先级，并签署优先级分配163。背书164被发送回客户端152，客户端152收集事务和优先级信息165，并将背书166发送给订购者156。优先级分配基于策略进行合并，并分配给相应的队列167。从队列中读取事务，并在生成事务块169之前验证每个事务的优先级。将该块与写入事务168一起分配给背书对等方。对等方验证背书和读取集，如果可以接受，则将写入集应用于状态171。然后将事务提交给提交对等方172，提交对等方172验证优先级并验证要提交给区块链173的事务。

图2a示出了根据示例实施例的区块链系统架构配置200。参考图2a，区块链架构200可以包括某些区块链单元，例如，参与区块链事务添加和验证过程(共识)的区块链节点281-284的组280。一个或多个区块链节点281-284可以背书事务，并且一个或多个区块链节点281-284可以为架构200中的所有区块链节点提供订购服务。区块链节点可以发起区块链身份验证并尝试写入存储在区块链层220中的区块链不可变账本，其副本也可以存储在基础物理基础设施210上。区块链配置可以包括一个或多个应用270，链接到应用编程接口(api)260以访问和执行存储的可以根据参与者寻求的定制配置创建并且可以维持自己状态、控制自己的资产、并接收外部信息的程序/应用程序代码250(例如，链码、智能合约等)。

区块链基础或平台205可以包括区块链数据、服务(例如，密码信任服务、虚拟执行环境等)的各个层，以及可用于接收和存储新事务并向正在寻求访问数据条目的审核方提供访问的基础物理基础设施。区块链层220可以暴露接口，提供对处理程序代码和使用物理基础设施210所必需的虚拟执行环境的访问。密码信任服务230可以用于验证诸如资产交换事务类的事务并保持信息私有。

图2a的区块链架构配置可以经由区块链平台205暴露的一个或多个接口以及提供的服务来处理和执行程序/应用代码240。代码240可以控制区块链资产。例如，代码240可以存储和传输数据，并且可以由节点281-284以智能合约和相关链码的形式由具有其执行条件或其他代码单元执行。作为非限制性示例，可以创建智能合约以执行提醒、更新和/或其他更改、更新等的通知。智能合约本身可以用于标识与授权和访问要求及账本使用相关的规则。在一个示例中，对等事务优先级数据222可以由包括在区块链层220中的一个或多个处理实体(例如，虚拟机)来识别和处理。结果可以包括根据优先级分配224将块分配给对等方，以用于处理区块链任务/事件。

利用链码，可以通过高级应用和编程语言创建智能合约，然后将其写入区块链中的块。智能合约可以包括可执行代码，被区块链(例如，区块链对等方的分布式网络)注册、存储和/或复制。事务是可以响应于与智能合约相关联的条件得到满足而执行的智能合约代码的执行。智能合约的执行可以触发对数字区块链账本状态的可信修改。由智能合约执行引起的对区块链账本的修改可以通过一个或多个共识协议在整个区块链对等方的分布式网络中自动复制。

智能合约可以以键值对的格式将数据写入区块链。此外，智能合约代码可以读取存储在区块链中的值，并将其用于应用操作中。智能合约代码可以将各种逻辑操作的输出写入区块链。代码可用于在虚拟机或其他计算平台中创建临时数据结构。写入区块链的数据可以是公开的和/或可以加密并保持为私有。智能合约使用/生成的临时数据由提供的执行环境保存在内存中，一旦识别出区块链所需的数据便将其删除。

链码可以包括具有附加特征的智能合约的代码解释。如本文所述，链码可以是部署在计算网络上的程序代码，共识过程中与链验证器一起在链上执行并验证链码。操作中，链码接收哈希，并从区块链中检索与使用先前存储的特征提取器创建的数据模板关联的哈希。如果哈希标识符的哈希值与从存储的标识符模板数据创建的哈希值匹配，则链码将授权密钥发送到请求的服务。链码可以将与密码详细信息关联的数据写入区块链。在图2a的例子中，对等方优先级分配可用于将事务作为事务块排序、分配和写入事务。

图2b示出了根据示例实施例的在区块链的节点之间的区块链事务流250的示例。参考图2b，事务流可以包括由应用客户端节点201发送到背书对等节点281的事务提议291。背书对等节点281可以验证客户端签名并执行链码功能以发起事务。输出可能包括链码结果、在链码中读取的一组键/值版本(读取集)以及以链码写入的一组键/值(写入集)。如果得到批准，则将提议响应292与背书签名一起发送回客户端201。客户端201将背书组装成事务有效载荷293，并将其广播到订购服务节点284。订购服务节点284然后将订购的事务作为块传递给信道上的所有对等方281-283。在提交到区块链之前，每个对等方281-283可以验证事务。例如，对等方可以检查背书策略，以确保指定对等方的正确分配已经对结果进行了签名并针对事务有效负载293验证了签名。

再次参考图2b，客户端节点201通过构造请求并将其发送给作为背书方的对等节点281来发起事务291。客户端201可以包括利用支持的软件开发工具包(sdk)的应用，诸如node、java、python等，利用可用的api来生成事务提议。java和所有基于java的商标和徽标是oracle和/或其分支机构的商标或注册商标。

提议是调用链码功能的请求，以便可以读取数据和/或将数据写入帐本(即，为资产写入新的键值对)。sdk可以充当填充程序，将事务提议打包为适当的架构格式(例如，远程过程调用(rpc)上的协议缓冲区)，并采用客户的加密凭据为事务提议生成唯一的签名。

作为响应，背书对等节点281可以验证(a)事务提议的格式正确，(b)过去尚未提交过事务(重放攻击保护)，(c)签名是有效，(d)提交者(在此示例中为客户端201)已被适当授权在该信道上执行提议的操作。背书对等节点281可以将事务提议输入作为所调用的链码功能的参数。然后针对当前状态数据库执行链码以产生包括响应值、读取集和写入集的事务结果。然而，此时尚未对账本进行任何更新。在292中，将值的集合与背书对等节点281的签名一起作为提议响应292传递回客户端201的sdk，客户端201的sdk解析应用消费的有效载荷。

作为响应，客户端201的应用检查/验证背书对等方的签名，并比较提议响应以确定提议响应是否相同。如果链码仅查询帐本，则应用将检查查询响应并通常不将事务提交至订购节点服务284。如果客户端应用打算将事务提交至订购节点服务284以更新帐本，则应用在提交之前确定指定的背书策略是否已实现(即，事务所需的所有对等节点是否都对事务进行背书)。在此，客户端可以仅包括事务的多方之一。这种情况下，每个客户端可能有自己的背书节点，并且每个背书节点都需要对事务背书。该体系结构使得即使应用选择不检查响应或以其他方式转发未背书的事务，背书策略仍将由对等方强制执行并在提交验证阶段得到维护。

在成功检查之后，在步骤293中，客户端201将背书组装成事务，并在事务消息内向订购节点284广播事务提议和响应。事务可以包含读/写集、背书对等方的签名和信道id。排序节点284不需要为了执行其操作而检查事务的全部内容，而是排序节点284可以简单地从网络中的所有信道接收事务，将信道按时间顺序对它们进行排序并创建每个信道的事务块。

事务的块从排序节点284传递到信道上的所有对等节点281-283。验证块内的事务294以确保满足任何背书策略并确保自事务执行生成读取集以来，读取集变量的账本状态没有变化。块中的事务被标记为有效或无效。此外，在步骤295中，每个对等节点281-283将块附加到信道的链上，并且对于每个有效事务，将写入集提交给当前状态数据库。发出一个事件以通知客户端应用事务(调用)已被不可变地附加到链上，并通知事务是通过验证还是无效。

图3a示出了有许可的区块链网络300的示例，其特征在于分布式、去中心化的对等架构以及管理用户角色和权限的证书颁发机构318。在这个例子中，区块链用户302可以提交到有许可的区块链310的事务。在这个例子中，事务可以是部署、调用或查询，并且可以通过利用sdk的客户端应用，例如直接通过restapi等，直接发布。可信的商业网络可以提供对诸如审计方(例如，美国股票市场中的证券交易委员会)之类的监管方系统314的访问。同时，区块链网络运营商308管理包括管理成员许可，例如将监管方310注册为“审计方”，并且将区块链用户302注册为“客户端”的节点系统。审计方可能只限于查询帐本，而客户端可以被授权部署、调用和查询某些类型的链码。

区块链开发方系统316可以编写链码和客户端应用。区块链开发方系统316可以通过rest接口将链码直接部署到网络。为了将来自传统数据源330的凭证包括在链码中，开发方系统316可以使用带外连接来访问数据。在该示例中，区块链用户302通过对等节点312连接到网络。在进行任何事务之前，对等节点312从证书颁发机构318检索用户的注册和事务证书。在某些情况下，区块链用户必须拥有这些数字证书以便在有许可的区块链网络310上进行事务。同时，可能要求尝试使用链码的用户在传统数据源330上验证其凭据。为了确认用户的授权，链码可以通过传统处理平台320使用对此数据的带外连接。

图4示出了根据示例实施例的用于执行事务优先级分配的系统消息图。参考图4，系统400提供客户端410、对等方420和订购方430。该过程可以包括识别一个或多个需要背书412的区块链事务。可以创建对应的请求并将其发送414给背书对等方，背书对等方向区块链事务416分配初始或第一优先级。背书响应包括背书方对等签名和分配给一个或多个事务的优先级。响应418被发送回客户端410，客户端410将背书422转发给订购者430。根据分配给订购者430确定的每个事务的最终优先级，在队列424中对事务进行排序。创建426用于事务提交的块，并将其分配428到提交对等方。基于事务的最终优先级432和优先级选择过程来提交事务，该优先级选择过程用于选择具有较高优先级的事务，同时根据该策略考虑优先级较低的事务。

图5a示出了根据示例实施例的在区块链中的区块链事务优先级分配的示例方法的流程图。参照图5a，方法500可以包括：识别需要对等方背书的(一个或多个)区块链事务512；向分配给区块链的一个或多个对等方传送一个或多个背书请求514；从一个或多个对等方接收背书响应消息，并且背书响应消息包括分配给区块链事务的多个优先级516。

该方法还包括将接收到的多个优先级和区块链事务转发至订购节点以分配给对等方518。

分配给区块链事务的多个优先级包括与多个优先级中的至少另一个不同的至少一个不同的优先级。分配给区块链事务的多个优先级可以全部是相同的优先级。用于确定分配给区块链事务的多个优先级的标准包括以下一项或多项：链码标识符(id)、调用的功能、事务类型和区块链事务的当前负载。该方法还提供基于所接收的多个优先级确定在订购节点处的区块链事务的最终订购优先级，并基于那些最终优先级将区块链事务分配给多个优先级队列之一。该方法还可以包括：当识别到一个或多个事务冲突时，从多个优先级队列中选择比其他区块链事务分配了更高优先级的多个区块链事务；以及验证分配了较高优先级的多个区块链事务以形成区块链块。通常，首先根据背书策略对分配了较高优先级的多个区块链事务进行验证。

图5b示出了根据示例实施例的在区块链中的区块链事务优先级分配的另一示例方法的流程图。参照图5b，方法550包括识别需要对等方背书的区块链事务552，向分配给区块链的一个或多个对等方传输背书请求554，标识背书请求是从受信源发送的556，由一个或多个对等方基于信任源为区块链事务分配预定优先级558，并从一个或多个对等方接收包括分配的预定优先级的背书响应消息562。

除了由对等方根据策略和背书请求的已知属性执行的优先级确定过程之外，受信源还可以仅转发已知具有特定优先级的背书请求。这使得对等方可以覆盖任何确定过程并直接分配特定优先级，而无需任何其他优先级计算或确定过程。

图6a示出了根据示例实施例的，被配置为根据本文描述的一个或多个操作在区块链上执行各种操作的示例物理基础设施。参照图6a，示例性配置600包括具有区块链620和智能合约640的物理基础设施610，可以执行任何示例性实施例中包括的任何操作步骤612。步骤/操作612可以包括在一个或多个流程图和/或逻辑图中描述或描绘的一个或多个步骤。这些步骤可以表示从驻留在计算机系统配置的物理基础结构610上的一个或多个智能合约640和/或区块链620写入或读取的输出或写入信息。可以从执行的智能合约640和/或区块链620输出数据。物理基础设施610可以包括一个或多个计算机、服务器、处理器、存储器和/或无线通信设备。

图6b示出了根据示例实施例的，在缔约方和被配置为在区块链上执行智能合约条款的中介服务器之间的示例智能合约配置。参考图6b，配置650可以表示由智能合约640驱动的通信会话、资产转移会话或流程或过程，智能合约640明确标识一个或多个用户设备652和/或656。智能合约的运行、执行、操作和结果可以由服务器654管理。智能合约640的内容可能需要由作为智能合约事务的当事方的实体652和656中的一个或多个进行数字签名。智能合约执行的结果可以作为区块链事务写入到区块链中。

以上实施例可以以硬件、以处理器执行的计算机程序、以固件或以上述的组合来实现。计算机程序可以体现在诸如存储介质的计算机可读介质上。例如，计算机程序可以驻留在随机存取存储器(ram)、闪存、只读存储器(rom)、可擦可编程只读存储器(eprom)、电可擦可编程只读存储器(eeprom)、寄存器、硬盘、可移动磁盘、光盘只读存储器(cd-rom)或本领域已知的任何其他形式的存储介质中。

示例性存储介质可以被耦合到处理器，使得处理器可以从该存储介质读取信息，并且可以向该存储介质写入信息。或者，存储介质可以与处理器集成在一起。处理器和存储介质可以驻留在专用集成电路(“asic”)中。在替代方案中，处理器和存储介质可作为分立组件驻留。

图7并非旨在暗示对本文所述应用的实施例的使用范围或功能的任何限制。无论如何，计算节点700能够被实现和/或执行以上阐述的任何功能。

在计算节点700中，存在计算机系统/服务器702，可与许多其他通用或专用计算系统环境或配置一起操作。可能适合与计算机系统/服务器702一起使用的众所周知的计算系统、环境和/或配置的示例包括但不限于个人计算机系统、服务器计算机系统、瘦客户端、胖客户端、手工手持式或膝上型设备、多处理器系统、基于微处理器的系统、机顶盒、可编程消费电子产品、网络pc、小型计算机系统、大型计算机系统以及包括上述任何系统或设备的分布式云计算环境等等。

可在由计算机系统执行的计算机系统可执行指令(例如程序模块)的一般上下文中描述计算机系统/服务器702。通常，程序模块可以包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、逻辑、数据结构等。可以在分布式云计算环境中实践计算机系统/服务器702，在分布式云计算环境中，任务由通过通信网络链接的远程处理设备执行。在分布式云计算环境中，程序模块可以位于包括内存存储设备的本地和远程计算机系统存储介质中。

如图7所示，以通用计算设备的形式示出了云计算节点700中的计算机系统/服务器702。计算机系统/服务器702的组件可以包括但不限于一个或多个处理器或处理单元704、系统存储器706以及将包括系统存储器706的各种系统组件耦合到处理器704的总线。

总线表示几种类型的总线结构中的任何一种或多种，包括使用各种总线体系结构中的任何一种的存储器总线或存储器控制器、外围总线、加速图形端口以及处理器或本地总线。作为示例而非限制，此类体系结构包括行业标准体系结构(isa)总线、微通道体系结构(mca)总线、增强型isa(eisa)总线、视频电子标准协会(vesa)本地总线和外围组件互连(pci)总线。

计算机系统/服务器702通常包括各种计算机系统可读介质。这样的介质可以是计算机系统/服务器702可访问的任何可用介质，并且包括易失性和非易失性介质、可移动和不可移动介质。在一个实施例中，系统存储器706实现其他附图的流程图。系统存储器706可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(ram)710和/或高速缓冲存储器712。

计算机系统/服务器702可以进一步包括其他可移动/不可移动、易失性/非易失性计算机系统存储介质。仅作为示例，可以提供存储系统714以用于读取和写入不可移动的非易失性磁性介质(未示出并且通常称为“硬盘驱动器”)。尽管未示出，但是用于读取和写入可移动非易失性磁盘(例如“软盘”)的磁盘驱动器以及用于读取或写入可移动非易失性光盘的光盘驱动器可以提供cd-rom、dvd-rom或其他光学介质之类的磁盘。在这种情况下，每一个都可以通过一个或多个数据媒体接口连接到总线。如将在下面进一步描绘和描述的，存储器706可以包括具有一组(例如，至少一个)程序模块的至少一个程序产品，该程序模块被配置为执行本申请的各种实施例的功能。

具有一组(至少一个)程序模块718的程序/实用程序716以及操作系统、一个或多个应用程序、其他程序模块和程序数据可以通过示例而非限制的方式存储在存储器706中。操作系统、一个或多个应用程序、其他程序模块以及程序数据或它们的某种组合中的每一个可以包括联网环境的实现。程序模块718通常执行本文所述的本申请的各种实施例的功能和/或方法。

如本领域技术人员将理解的，本申请的各方面可以体现为系统、方法或计算机程序产品。因此，本申请的各方面可以采取以下形式：完全硬件实施例、完全软件实施例(包括固件、驻留软件、微代码等)或结合了通常可以全部提及的软件和硬件方面的实施例。本文中称为“电路”、“模块”或“系统”。此外，本申请的各方面可以采取体现在其上体现有计算机可读程序代码的一个或多个计算机可读介质中体现的计算机程序产品的形式。

计算机系统/服务器702还可以与一个或多个外部设备720通信，诸如键盘、指示设备、显示器722等、使用户能够与计算机系统/服务器702交互的一个或多个设备和/或使计算机系统/服务器702与一个或多个其他计算设备通信的任何设备(例如，网卡、调制解调器等)。这样的通信可以经由i/o接口724发生。然而，计算机系统/服务器702仍然可以通过网络适配器726与一个或多个网络通信，诸如局域网(lan)、通用广域网(wan)和/或公共网络(例如，internet)。如图所示，网络适配器726通过总线与计算机系统/服务器702的其他组件进行通信。应当理解，尽管未示出，但是其他硬件和/或软件组件可以与计算机系统/服务器702结合使用。示例包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动器、阵列、raid系统、磁带驱动器和数据档案存储系统等。

尽管在附图中示出了系统、方法和非暂时性计算机可读介质中的至少一个的示例性实施例，并且在前面的详细描述中进行了描述，但是应当理解，本申请不限于公开的实施例，而是能够进行如所附权利要求所阐述和定义的许多重新布置、修改和替换。例如，各个附图的系统的能力可以由本文描述的模块或组件中的一个或多个或以分布式架构来执行，并且可以包括发射机、接收机或两者。例如，由各个模块执行的全部或部分功能可以由这些模块中的一个或多个来执行。此外，本文描述的功能可以在模块或模块或组件内部或外部的各种时间并且与各种事件相关地执行。而且，可以经由以下各项中的至少一项在各个模块之间和/或通过多种协议发送各种模块之间发送的信息：数据网络、互联网、语音网络、互联网协议网络、无线设备、有线设备。而且，可以直接和/或经由一个或多个其他模块来发送或接收由任何模块发送或接收的消息。

本领域的技术人员将意识到，“系统”可以体现为个人计算机、服务器、控制台、个人数字助理(pda)、手机、平板计算设备、智能手机或任何其他形式合适的计算设备或设备组合。将上述功能呈现为由“系统”执行并不旨在以任何方式限制本申请的范围，而是旨在提供许多实施例的一个示例。实际上，本文公开的方法、系统和装置可以以与计算技术一致的局部和分布式形式来实现。

应该注意的是，在本说明书中描述的一些系统特征已经作为模块呈现以便更具体地强调它们的实现独立性。例如，模块可以被实现为硬件电路，包括定制的超大规模集成电路(vlsi)电路或门阵列，诸如逻辑芯片、晶体管或其他分立组件的现成半导体。模块也可以在诸如现场可编程门阵列、可编程阵列逻辑、可编程逻辑设备、图形处理单元等的可编程硬件设备中实现。

模块也可以至少部分地以软件实现以由各种类型的处理器执行。所标识的可执行代码单元可以例如包括计算机指令的一个或多个物理或逻辑块，计算机指令可以例如被组织为对象、过程或功能。然而，所标识的模块的可执行文件不需要在物理上位于一起，而是可以包括存储在不同位置的不同指令，当这些指令在逻辑上结合在一起时，包括模块并实现模块的所述目的。此外，模块可以存储在计算机可读介质上，该计算机可读介质可以是例如硬盘驱动器、闪存设备、随机存取存储器(ram)、磁带或用于存储数据的任何其他此类介质。

实际上，可执行代码的模块可以是单个或多个指令，并且甚至可以分布在多个不同的代码段上、不同的程序之间以及多个存储设备上。类似地，操作数据可以在这里在模块内被识别和示出，并且可以以任何合适的形式体现并且可以在任何合适的类型的数据结构内组织。操作数据可以作为单个数据集收集，或者可以分布在包括不同存储设备的不同位置上并且可以至少部分地仅作为系统或网络上的电子信号存在。

将容易地理解，如本文的附图中总体上描述和示出的，本申请的组件可以以多种不同的配置来布置和设计。因此，实施例的详细描述不旨在限制所要求保护的本申请的范围，而仅代表本申请的所选实施例。

本领域普通技术人员将容易地理解，可以以不同顺序的步骤和/或以与所公开的配置不同的配置的硬件元件来实践以上内容。因此，尽管已经基于这些优选实施例描述了本申请，但是对于本领域技术人员显而易见的是，某些修改、变型和替代构造将是显而易见的。

尽管已经描述了本申请的优选实施例，但是应当理解，所描述的实施例仅是示例性的，并且当考虑全部等价物和修改(例如，协议、硬件设备、软件平台等)的范围时，本申请的范围仅由所附权利要求书限定。