分布式分类账中基于DAG的交易处理方法和系统

摘要

本文描述了用于分布式分类账中基于DAG的交易处理系统和方法的系统和方法。根据实施例，可以引入分布式分类账中基于DAG的交易处理系统和方法。该模型可以帮助实现提高的吞吐量性能。借助附加的权重机制，可以基于各种业务需求来调整最终性能。这与使用线性结构的现有工作不同，并且可以实现更好的性能。

说明书

版权声明

本专利文档公开内容的一部分包含受版权保护的素材。版权拥有者不反对任何人对专利文档或专利公开内容按照在专利商标局的专利文件或记录中出现得那样进行的传真复制，但是除此之外在任何情况下都保留所有版权。

优先权要求：

本申请要求于2019年1月29日提交的标题为“DAG BASED METHODS AND SYSTEMSOF TRANSACTION PROCESSING IN A DISTRIBUTED LEDGER”、申请号为16/261,371的美国专利申请的优先权，以及要求于2018年8月24日提交的标题为“DAG BASED METHODS ANDSYSTEMS OF TRANSACTION PROCESSING IN A DISTRIBUTED LEDGER”、申请号为62/722,595的美国临时专利申请的优先权；上述申请中的每个申请通过引用整体并入本文。

技术领域

本公开一般而言涉及用于提供分布式分类账(ledger)的系统和方法。更特别地，本公开描述了用于分布式分类账中基于有向非循环图(DAG)的交易处理方法和系统的系统及其方法和组件。

背景技术

分布式分类账可以被广义地描述为资产所有权的数字记录。分类账既没有中央管理员，也没有中央数据存储库。代替地，分类账跨计算环境中的许多参与节点进行复制，该计算环境可能在地理上跨多个站点、国家或机构分布。共识协议确保每个节点的分类账副本与每个其它节点的副本相同。同样，可以将该组副本视为单个共享分类账。资产所有者可以使用密码签名技术来使用分布式分类账，以例如借记(debit)他们的账户和贷记(credit)他人的账户。

区块链是可以用于实现防篡改分布式分类账的数据结构。多个节点遵循通用协议，其中来自客户端的交易被打包成区块，并且节点使用共识协议来协定下一个区块。区块携带累积的密码散列，从而使得难以篡改分类账。每个区块可以具有对时间上前一个区块的引用[散列值]。此外，每个区块可以包括其自己的散列。区块链可以向后遍历(例如，沿着链向上遍历)。

免许可(permissionless)分散式分类账允许匿名参与者维护分类账，同时避免受任何单个实体的控制。但是，鉴于匿名性，身份、责任性和可审计性很难。作为对照，许可分散式分类账通过允许明确授权的各方维护分类账来允许信任和责任级别。许可分类账支持更灵活的管理和对共识机制的更多选择。两种分散式分类账都可能容易受到参与者的操纵，这些参与者更倾向于一些交易。但是，基于许可分类账的责任性提供了可以对参与者施加约束的机会。

区块链通过线性记录结构来记录交易历史来帮助为分布式分类账问题带来潜在的解决方案。但是，由于分布式系统的基本特性，经常发生交易冲突，其中多方将多个交易发送到同一共享分类账。存在缓解冲突的若干方法，但是，这些方法都不能提供良好的性能。

典型的公共区块链(如与加密货币相关联的那些公共区块链)允许矿工(miner)基于排序(ordering)来决定保留哪些交易和拒绝哪些交易。实际上，这里选择了激励模型，因为这些矿工将始终偏好具有更高费用的那些交易。总是指责公共区块链执行非常缓慢，部分原因是激励模型。

典型的类似于企业区块链的架构(fabric)选取其中每个对等方仅基于来自订购服务的批次中的时序排序来提交交易的时序模型。在这种情况下，将存在由于时序排序而导致许多交易被拒绝的情况。

发明内容

根据实施例，本文描述了用于分布式分类账中基于DAG的交易处理方法和系统的系统及其方法和组件。

根据实施例，本文的公开通过引入DAG结构提供了新的交易处理模型。该新的模型可以帮助实现高吞吐量性能。借助附加的权重机制，可以基于各种业务需求来调整最终性能。这与使用线性结构的现有工作完全不同，并且在一些情况下可以实现更好的性能。

超级分类账项目是作为Linux基金会的项目建立的协同合作，以创建企业级、开源分布式分类账框架和代码库。超级分类账架构是用于运行智能合约的分布式分类账平台的实现。它利用容器技术来托管被称为“链式码”的智能合约，该智能合约包括系统的应用逻辑。

根据实施例，超级分类账中的参与者已经复制了分类账的副本。除了共享分类账信息之外，还共享更新分类账的处理。与使用参与者的私有程序来更新相关联的私有分类账的其它系统不同，区块链系统具有共享程序来更新共享的分类账。具有通过共享分类账协调其业务网络的能力，区块链网络可以减少与分配到私有信息分类账中相关联的时间、成本和风险，并减少处理时间(同时增加信任度)。超级分类账架构是私有的并且是许可的。超级分类账架构网络的成员被注册。超级分类账架构还提供了创建通道的能力。每个通道可以包含对特定参与者组可见的独立交易分类账。这允许交易隐私。

根据实施例，架构的分布式分类账协议由对等体运行。架构区分两种对等体：验证对等体是网络上负责运行共识、验证交易和维护分类账的节点。另一方面，非验证对等体是用作代理以将客户端(发出交易)连接到验证对等体的节点。非验证对等体不执行交易，但它可以核实它们。该架构的一些特征包括具有即时终结性(immediate finality)的许可区块链，其运行被称为链式码的任意智能合约。用户定义的链式码智能合约被封装在容器中，并且系统链式码与对等体在同一进程中运行。在整个网络上保持分类账交易同步(例如，以确保分类账仅在适当参与者批准交易后才更新，并且在分类账确实更新时，它们将以相同的排序更新相同的交易)的处理可以被称为共识(consensus)。该架构通过支持TLS(传输层安全)证书、注册证书和交易证书的证书颁发机构(CA)来实现共识协议和安全性。

附图说明

图1A图示了根据实施例的区块链云服务系统的架构中的交易流。

图1B图示了根据实施例的区块链云服务系统。

图1C图示了根据实施例的BCS系统。

图1D图示了根据实施例的BCS系统。

图2图示了根据实施例的用于区块链云服务系统的网关。

图3图示了根据实施例的区块链云服务系统的持久性。

图4图示了架构在BCS上的示例部署。

图5图示了根据实施例的链式码架构。

图6图示了根据实施例的用于提供管理控制台的系统。

图7A图示了根据实施例的BCS控制台UI中的用户界面的示例。

图7B图示了根据实施例的BCS控制台UI中的用户界面的示例。

图8图示了根据实施例的用于在BCS实例中提供REST代理的系统。

图9A示出了根据实施例的用于单点登录的典型IDCS用例。

图9B示出了根据实施例的用于架构客户端认证的IDCS用例。

图10示出了根据实施例的用于分布式分类账中基于DAG的交易处理方法和系统的系统。

图11示出了根据实施例的可以在本公开的实施例中使用的示例关系图。

图12示出了根据实施例的可以在本公开的实施例中使用的示例关系图。

图13示出了根据实施例的可以在本公开的实施例中使用的示例关系图。

图14是根据实施例的用于分布式分类账中基于有向非循环图(DAG)的交易处理的示例方法的流程图。

具体实施方式

根据实施例，本文描述了用于在区块链架构中支持基于SQL的丰富查询的系统和方法。根据实施例，本文提供的系统和方法提供执行SQL查询以允许以更容易和更可维护的方式创建复杂智能合约的能力。此外，通过将数据过滤推回到存储引擎(而不是在智能合约级别发生)以及通过能够依赖于支持并发读写数据访问的关系引擎，性能得以提高。同样，世界状态数据库还可以提供并发的读/写访问。

根据实施例，可以提供在区块链架构中支持基于SQL的丰富查询的示例区块链架构作为云服务。根据实施例，企业级框架包括可缩放性、管理、配置、持久化以及通过使用云技术与各种客户应用的兼容性。在特定实施例中，提供许可区块链分类账和区块链架构作为区块链云服务(BCS)。

在下面的描述中，将通过示例而非限制的方式在附图的各图中图示本教导。本公开中对各种实施例的引用不一定是同一个实施例，并且这样的引用意味着至少一个。虽然讨论了具体的实施方式，但是应该理解的是，这仅是出于说明的目的而提供。相关领域的技术人员将认识到，在不脱离本公开的范围和精神的情况下，可以使用其它部件和配置。本教导的描述提供了支持和公开所要求保护的方法的示例和实施例。

此外，在某些情况下，将阐述许多具体细节以提供对本教导的透彻描述。但是，对于本领域技术人员而言显而易见的是，可以实现当前教导的方法的结果和优点，并且可以在没有这些具体细节的情况下实践当前教导的概念。在其它实例中，没有尽可能详细地描述众所周知的特征，以免混淆本公开。

借助于说明特定功能及其关系的性能的功能构建区块来描述本教导。为了便于描述，这些功能构建区块的边界通常在本文中被任意定义。因此，在替代实施例中，示出由相同元件执行的功能可以由不同元件执行。示出在单独元件中执行的功能可以替代地被组合到一个元件中。可以定义替代边界，只要适当地执行指定的功能及其关系即可。因此，任何这样的替代边界都在本公开的范围和精神内。

在整个附图和详细描述中，共同的附图标记用于表示相同的元件；因此，如果元件在别处被描述，则图中使用的附图标记可以或可以不在特定于该图的详细描述中被引用。

区块链技术具有通过跨客户的生态系统中实现近实时的分布式交易以及通过实现安全、防篡改数据共享来显著增强企业业务价值的潜力。超级分类账架构区块链包含模块化体系架构、水平/跨行业技术支持以及对企业需求的支持。

介绍

根据实施例，超级分类账架构是用于分布式分类账解决方案的平台，其由模块化体系架构加固，提供高度机密性、弹性、灵活性和可缩放性。它被设计为支持不同部件的可插拔实现方案，并适应跨经济生态系统存在的复杂度和复杂性。

根据实施例，超级分类账架构提供弹性和可扩展的体系架构，从而将其与替代的区块链解决方案区分开。

区块链—分布式分类账

根据实施例，区块链网络可以包括分布式分类账，该分布式分类账记录在网络上发生的所有交易。

区块链分类账通常被描述为去中心化的，因为它被复制到许多网络参与者，每个网络参与者在维护区块链分类账中协作。去中心化和协作是反映企业在现实世界中交换商品和服务的方式的属性。

除了去中心化和协作之外，记录到区块链的信息是仅追加(append-only)的，使用密码技术，该密码技术保证一旦交易已被添加到分类账，它就不能被修改。这种不变性的属性使得确定信息的起源(provenance)变得简单，因为参与者可以确定信息在事后没有被改变。以这种方式，区块链可以被认为是证明系统(systems of proof)。

区块链—智能合约

根据实施例，为了支持信息的一致更新——以及启用某些分类账功能(交易、查询等)——区块链网络使用智能合约来提供对分类账的受控访问。

根据实施例，智能合约不仅是用于封装信息并使其在网络上保持简单的关键机制，它们还可以被编写为允许参与者自动执行交易的某些方面。

智能合约可以例如被编写以规定运送物品的成本，该成本取决于物品到达的时间而变化。根据双方同意并写入分类账的条款，当收到物品时，适当的资金自动转手。

区块链—共识

根据实施例，保持分类账交易在网络上同步以确保以下的处理可以被称为共识——以确保分类账仅在交易被适当的参与者批准时才更新，并且在分类账确实更新时，它们以相同的排序更新相同的交易。

根据实施例，区块链可以被认为是共享的、复制的交易系统，该交易系统经由智能合约进行更新并且通过被称为共识的协作处理保持一致同步。

区块链的优点

根据实施例，当前可用的交易网络是自从保留业务记录以来已经存在的网络的版本。业务网络的成员彼此进行交易，但每个成员都维护他们的交易的单独记录。同样，交易的对象可以在每次被出售时建立这些对象的起源，以确保销售该项目的企业拥有核实这些企业对该项目的所有权的产权链(chain of title)。

虽然当前的业务网络由计算系统进行现代化，但是不存在用于管理网络参与者的身份的统一系统，建立起源是费力的，因为清算证券交易(其全世界的体量以数万亿美元计)需要花费数天、合同必须手动签署和执行、并且系统中的每个数据库都包含唯一的信息并因此代表单点故障。

根据实施例，区块链通过提供用于在网络上建立身份、执行交易和存储数据的标准方法，提供了对由标准交易系统表示的许多低效率方案的替代方案。

根据实施例，在区块链网络中，其中的每个参与者具有其自己的分类账的复制副本。除了共享分类账信息之外，还共享更新分类账的处理。与在其中参与者的私有程序被用于更新参与者的私有分类账的其它系统不同，区块链系统具有用于更新共享分类账的共享程序。

根据实施例，利用通过共享分类账协调业务网络的能力，区块链网络可以减少与私人信息和处理相关联的时间、成本和风险，同时改善信任和可见性。

超级分类账架构

像其它区块链技术一样，超级分类账架构具有分类账、使用智能合约、并且是参与者通过其来管理他们的交易的系统。

超级分类账架构与一些其它区块链系统的不同之处在于它是私有的和许可的。超级分类账架构网络的成员通过成员资格服务提供者来登记(enroll)，而不是一些区块链网络用于核实身份的“工作证明”(允许满足这些准则的任何人加入网络)。

超级分类账架构还提供了几种可插拔选项。分类账数据可以以多种格式存储，共识机制可以被切换进和切换出，并且不同的MSP(成员资格服务提供者)被支持。

超级分类账架构还提供创建通道的能力，从而允许一组参与者创建单独的交易分类账。这允许以下这样的网络选项，其中一些参与者可能是竞争者并且不希望他们做出的每一笔交易——例如他们向一些参与者而不是其它参与者提供的特殊价格——对于每个参与者都已知。如果两个参与者形成通道，那么这些参与者——而不是其它参与者——拥有该通道的分类账副本。

共享分类账

根据实施例，超级分类账架构具有包括两个部件的分类账子系统：世界状态和交易日志。每个参与者具有他们所属的每个超级分类账架构网络的分类账副本。

世界状态部件描述在给定时间点处的分类账的状态。它是分类账的数据库。交易日志部件记录导致了世界状态的当前值的所有交易。它是世界状态的更新历史。然后，分类账是世界状态数据库和交易日志历史的组合。

共享分类账具有世界状态的可替换数据存储库。默认情况下，这是LevelDB键-值存储数据库。交易日志不需要是可插拔的。它仅记录区块链网络使用的分类账数据库的前值和后值。

智能合约

超级分类账架构智能合约以链式码编写，并且当区块链外部的应用需要与分类账进行交互时由该应用调用。在大多数情况下，链式码只与分类账的数据库部件、世界状态进行交互(例如，查询它)，而不与交易日志进行交互。

共识

根据实施例，交易按照它们发生的排序被写入分类账，即使它们可能在网络内的不同参与者集合之间。为此，建立了交易的排序，并且可以实现用于拒绝已被错误(或恶意)插入到分类账中的坏交易的方法。

超级分类账架构允许网络实体(例如，网络用户、对等体(peer)、起始者)选择最能代表参与者之间存在的关系的共识机制。与隐私一样，存在一系列需求；从在他们的关系中高度结构化的网络到更加对等(peer-to-peer)的网络。

链式码

根据实施例，链式码可以包括定义(一个或多个)资产的软件，以及用于修改(一个或多个)资产的交易指令——它是业务逻辑。链式码强制执行读取或更改键值对或其它状态数据库信息的规则。链式码函数针对分类账当前状态数据库执行，并通过交易提议发起。链式码执行导致可以提交给网络并应用于所有对等体上的分类账的一组键值写入(写入集)。

分类账特征

根据实施例，分类账是架构中所有状态转换的有序、防篡改记录。状态转换是参与方提交的链式码调用(“交易”)的结果。每个交易都会产生资产键值对集合，该资产键值对集合被提交到分类账作为创建、更新或删除。

分类账包括用于以区块的形式存储不可变的排序记录的区块链，以及用于维护当前架构状态的状态数据库。每个通道可以有一个分类账，每个通道包含对特定的参与者组可见的单独的交易分类账。每个对等体维护其作为成员的每个通道的分类账的副本。

通过通道的隐私(privacy)

根据实施例，超级分类账架构在每个通道的基础上采用不可变的分类账，以及可以操纵和修改资产的当前状态(即更新键值对)的链式码。分类账存在于通道的范围内——它可以跨整个网络共享(假设每个参与者都在一个公共通道上操作)——或者它可以被私有化为只包括特定的参与者集合。

在后一种场景下，这样的参与者可以创建单独的通道，从而使他们的交易和分类账隔离/分离。为了允许想要弥合总透明度和隐私之间的间隙的场景，可以仅在需要访问资产状态以执行读取和写入的对等体上安装链式码(例如，如果链式码未在对等体上安装，那么它将无法与分类账恰当对接)。为了进一步模糊数据，可以在追加到分类账之前使用常见的密码算法(诸如AES(高级加密标准))对链式码内的值进行加密(部分或全部)。

根据实施例，还可以通过“私有集合”的概念来改善隐私—“私有集合”是比按通道进行隐私保护更精细的概念。

安全性和成员资格服务

根据实施例，超级分类账架构提供了其中所有参与者都具有已知身份的交易网络。公钥基础设施被用于生成与组织、网络部件以及终端用户(end user)或客户端应用绑定的密码证书。因此，可以在更广泛的网络和通道级别上操纵和管理数据访问控制。超级分类账架构的这种“许可”概念，加上通道的存在和能力，有助于解决其中隐私和机密性至关重要的场景。

共识

根据实施例，在分布式分类账中，共识可以包含的不仅仅是简单地同意交易的排序。超级分类账架构通过其在从提议和背书(endorsement)到排序(order)、验证和提交的整个交易流中的基础性角色突出了这种差异化。可以将共识定义为包括区块的交易集合的正确性的全圆核实(full-circle verification)。

当区块的交易的排序和结果已满足显式策略标准检查时，最终实现了共识。这些检查和平衡发生在交易的生命周期期间，并包括使用背书策略来指定哪些特定成员必须背书某个交易类，以及系统链式码以确保这些策略被强制执行和支持。在提交之前，对等体可以采用这些系统链式码来确保存在足够的背书，并且它们是从适当的实体导出的。此外，在包含交易的任何区块被追加到分类账之前，可以进行版本控制(versioning)检查，在版本控制检查期间，对分类账的当前状态达成一致或共识。这种最终检查可以防止可能危及数据完整性的双重花费操作和其它威胁，并允许针对非静态变量执行函数。

除了发生的背书、有效性和版本控制检查之外，还存在在交易流中发生的持续身份核实。访问控制列表在网络的层级上实现(将服务排序到通道)，并且当交易提议通过不同的体系架构部件时，有效载荷被重复签署、核实和认证。共识不限于就一批交易的排序达成一致，而是作为在从提议到提交的交易流程期间发生的持续核实的副产品而实现的处理。

区块链云服务—体系架构

根据实施例，诸如云系统(例如，区块链云服务(BCS))之类的系统可以利用上述超级分类账架构作为起始点。这样的系统提供了高度先进和差异化的企业级分布式分类账云平台，该平台允许构建新的基于区块链的应用和/或扩展现有的SaaS、PaaS、IaaS和本地(on-premises)应用。

根据实施例，该系统可以支持任务关键型企业需求，诸如可缩放性、安全性、鲁棒性(robustness)、集成和性能，以移除生产中采用的障碍并且支持区块链应用。该系统允许用户通过提供BCS作为平台即服务(PaaS)云解决方案来部署、配置、管理和监控区块链并降低在企业中部署区块链的成本。该系统还加速了区块链应用与其它平台的开发和集成。该系统允许SaaS云客户使用区块链云平台实现其采购、支付、贸易金融、会计、HR、CX等企业处理，以与第三方应用和外部分布式分类账技术安全地共享数据和进行分布式交易。

根据实施例，该系统是基于PaaS管理器(例如，Oracle PaaS服务管理器(PSM)平台)的云服务。一般而言，这种系统是在计算空间(例如，外部计算空间)中运行的受管理的云服务。在实施例中，系统利用PSM平台的特征，包括使用Oracle身份云服务(IDCS)、Oracle负载均衡器即服务(LBaaS)、Oracle事件中枢云服务和Oracle云存储(Cloud Storage)进行分层的Oracle应用容器云服务(ACCS)。每个客户区块链可以被供应，并且可以作为租户运行。系统支持多个区块链，每个区块链在多租户环境中作为单独的租户被供应和运行。

因而，该系统允许应用或客户应用根据应用的需要或期望实现具有智能合约的分布式分类账。这种系统的客户端和用户可以在云的内部或外部—区块链信任—一些区块链网络可以包括云环境外部的部件(或者可以被约束到特定的云)。

根据实施例，这种系统对于各种应用功能可以是有用的，特别是在必须解决信任和身份问题的多方交易中。与其它区块链系统不同，所提供的系统服务不是匿名的。实际上，身份和可审计性是基本的和被集成的因素。因而，BCS在例如资本市场、跨境交易、金融服务、资产交易、法律监管应用、医疗记录、出版、物流、可追溯性和防伪找到应用。

如上所述，区块链上的每一方都可以访问整个数据库及其完整历史(除非分类账已经被供应/私有化给某些方)。不存在单方控制数据或信息。每一方也可以直接核实其交易伙伴的记录，而无需中介。通信直接发生在对等体之间而不是通过中心节点。每个节点都存储信息并将信息转发给所有其它节点。一旦交易被输入数据库并且账户被更新，记录就不能被更改，因为它们链接到在它们之前到来的每个交易记录(因此称为“链”)。如果交易出错，那么必须使用新交易来撤消错误，然后这两个交易都对被供应的用户是可见的。为了添加新的有效交易，参与者可以经由共识机制就其有效性达成一致。区块链的参与者可以证明资产来自哪里以及资产的所有权随时间如何改变。数字签名可以用于认证文档并且可以被放置在访问控制[不同级别的权限]和可编程性[可执行业务规则]中。

在许多多方交易中，当一方接收到资产或服务时，货币被交换。通常由于交易时间，一方或另一方必须在另一方之前提交货物或金钱。在一些环境中，通过使用中介来解决信任问题，中介将资金保持在托管中直到合约条件完成为止。这解决了原始方之间的信任问题。但是，这种方法增加了必须受信任的另一个中心化的一方，从而增加了复杂性，并且可能增加交易的成本。使用智能合约作为所提供系统的一部分可以消除对中介的需求——各方可以在区块链上进行受信任的交易而无需中介。

根据实施例，所提供的系统(诸如BCS)的优点包括其中包含的信息是分布式的。虽然可审计性是可用的，但访问受到控制并且可以保持一些隐私。而且，区块链分类账基本上是不可变的并且不能被拒绝。分类账包括区块的列表。每个交易区块包含：区块ID、前一个散列、数据散列、时间戳、交易ID列表、动作(1..n)、链式码ID、链式码提议、响应(r/w集合、事件、成功或失败)、背书者(endorser)。由于每个区块包含前一个散列和它自己的散列，因此这些区块一旦被知晓/分布就固有地有序并且不可变(注意：当前区块的散列是前一个区块的散列和当前区块中的其它数据的散列，因此链接链中的区块)。共识可以解决差异。与中心化数据库或中介相比，不需要向中心化授权机构给予过度授权。分类账的分布式性质也增强了区块链记录技术的基本不变性，因为分布式副本的使用—以及共识使得难以修改它(即使在算法上可能的情况下也是如此)。因此，给定交易的排序的情况下—如果有人具有链中最新区块的副本，对分类账进行攻击也几乎是不可能的。

在特定实施例中，如下所述，所提供的系统可以基于Oracle PaaS服务管理器(PSM)平台，并且利用管理控制台进行扩充，该管理控制台简化/促进/自动化基于架构的区块链的供应、监控和配置。此外，还提供了包括单一REST API的REST代理服务，以简化应用与区块链架构之间的联系。开发人员可以构建智能合约，使用管理控制台部署智能合约，然后让应用异步地(默认情况下)或者同步地(如果请求立即响应)调用区块链上的智能合约。取决于平台的需要，REST代理服务和API提供同步和异步功能两者。

根据实施例，架构-CA服务器可以为架构提供成员资格服务。架构-CA服务器可以包括三个部分：针对用户的认证、访问区块链(一组对等体和排序)的授权，以及可以将证书递送到应用客户端、对等体和排序的CA服务器。架构-CA可以使用证书来实现认证和授权。证书包括两种类型：用于认证的登记证书和用于授权的交易证书。根据实施例，诸如IDCS之类的身份服务也可以提供认证和授权。

超级分类账架构

如上所述，在实施例中，所提供的系统可以实现超级分类账架构，其提供用于运行智能合约的分布式分类账平台。该架构利用容器技术来托管被称为“链式码”的包括系统的应用逻辑的智能合约。在替代实施例中，区块链云服务实现替代的分布式分类账平台，包括例如2016年5月31日提交的标题为“Accountability And Trust in Distributed LedgerSystems”的序列号为15/169,622的美国专利申请中所述的“Tendermint”分类账系统，该专利申请通过引用并入本文。

超级分类账架构的分布式分类账协议由对等体运行。现有区块链技术的一个缺点是要求所有对等体记录所有交易。这产生大量的I/O和处理器开销，并且无法方便地缩放到企业级系统。超级分类账架构区分两种对等体：提交者对等体是网络上可以在将交易提交给区块链之前核实背书并验证交易结果以及维护分类账的节点。另一方面，非验证对等体是用作代理以将客户端(发出交易)连接到验证对等体的的节点。非验证对等体(或背书对等体)不执行交易，但它可以模拟并背书交易。对等体类型/功能的分离提高了系统的可缩放性。排序服务可以接受已背书的交易、将其排序到区块中，并且将这些区块递送给提交对等体。在这样的分布式分类账系统中，共识是将要添加到分类账的下一组交易达成一致的处理。在超级分类账架构中，共识由三个不同的步骤组成：交易背书、排序、以及验证和提交。

根据实施例，超级分类账的特征是具有即时终结性(immediate finality)的许可区块链，其运行被称为链式码的任意智能合约。用户定义的链式码智能合约封装在容器中，并且系统链式码在与对等体相同的进程中运行。链式码执行与交易排序分开，从而限制了跨节点类型所需的信任和核实级别，并减少了网络开销。

根据实施例，超级分类账架构中的通道使得能够以在公共网络上交换资产的竞争企业和受监管行业所需的高度隐私和机密性来进行多边交易。不可变的共享分类账为每个通道对整个交易历史进行编码，并且包括用于高效审计和争议解决的查询能力。分类账在通道范围内被提供——它可以在整个网络中共享(假设每个参与者在一个公共通道上操作)——或者它可以私有化为仅包括一组参与者。

根据实施例，超级分类账架构通过支持用于TLS证书、登记证书和交易证书的证书颁发机构(CA)来实现安全性。公钥基础设施被用于生成与组织、网络部件以及终端用户或客户端应用绑定的密码证书。因此，可以在更广泛的网络和通道级别上操纵和管理数据访问控制。超级分类账架构的这种“许可”特征，加上通道的存在和功能，满足了多方企业系统中的隐私和机密性需求。

根据实施例，超级分类账架构提供使用链式码交易修改资产的能力。如上所述，链式码是定义一个或多个资产的软件，并且是用于修改(一个或多个)资产的交易指令。

所集成的共识机制在超级分类账架构中的从提议和背书、到排序、验证和提交的交易流程中具有基础性角色。如上所述，共识是对包括区块的交易集合的有效性的核实。共识在区块的交易的排序和结果满足显式策略准则检查时最终达成。

图1A图示了提供区块链服务的系统的架构中的交易流程。更具体而言，该图图示了根据实施例的区块链云服务(BCS)系统。在1处，客户端160使用架构SDK 162来访问架构证书颁发机构170、172、174以进行登记。在1.1处，架构-CA向客户端160返回登记证书。在2处，客户端160使用架构SDK 162来访问对等体容器180，以请求来自背书者182的背书。在2.1处，背书者182返回经签署的RWset(读写集)。在3处，客户端160处的架构SDK 162向排序容器190处的排序服务提交包括RWset和背书者签名的经背书的TX(交易)。在4处，排序者192将TX批递送到对等体容器180中的提交者184。排序者是所定义的将交易排序成区块的节点集合。排序服务独立于对等体进程而存在，并在先来先服务的基础上为网络上的所有通道对交易进行排序。提交者184在5和5.1处对分类账186和世界状态188应用改变。架构证书颁发机构170可以用于为对等体容器180、智能合约容器166和168(智能合约)以及排序者192验证签名和授权。此外，智能合约168可以与背书者182进行通信。

在实施例中，系统可以使用Kafka集群作为排序服务。Kafka是支持发布和订阅语义的分布式流传输服务。Kafka集群在多个服务器上运行，并将记录的流存储在被称为话题(topic)的类别中。每个记录包括键值和时间戳。因此，Kafka可以用作排序服务，包括排序服务节点(OSN-n)和Kafka集群。排序服务客户端可以连接到多个OSN。OSN不直接彼此通信。这些排序服务节点(OSN)(1)进行客户端认证，(2)允许客户端使用简单的接口写入链1或从链1中读取，以及(3)它们还对重新配置现有链或创建新链的配置交易执行交易过滤和验证。Kafka中的消息(记录)被写入话题分区。Kafka集群可以具有多个话题，并且每个话题可以具有多个分区。每个分区都是不断附加到其的有序的、不可变的记录序列。一旦OSN执行了客户端认证和交易过滤，它们就可以将属于某个链的传入客户端交易中继到链的相应分区。然后，它们可以消费该分区并返回跨所有排序服务节点通用的有序交易列表。

根据实施例，每个对等体具有作为背书者和提交者的能力。存在可以使对等体成为背书者的配置项(例如，CORE_PEER_ENDORSER_ENABLED)。当对等体加入通道时，该对等体成为这个通道的提交者。当在对等体上安装链式码时，这个对等体成为这个链式码的候选背书者。当客户端提出交易时，客户端可以(从候选背书者中)选择哪些对等体作为背书者。

根据实施例，用于让排序者将区块递送给对等体的排序机制如下。首先，对等体(例如，领导者对等体)通过发送其版本(最后的区块编号)来递送对来自排序者的新区块的请求。接下来，排序者检查对等体的版本：a)如果它大于排序者，那么向对等体返回错误，它指示排序者中的分类账丢失，并且无法从EventHub(事件中枢)恢复(在这种情况下，排序者无法继续正常工作)；b)如果对等体的版本小于排序者，那么排序者从(在RAM中或者本地文件中的)本地分类账中检索区块，然后发送回对等体；或者c)如果它们具有相同的版本，那么排序者将阻塞直到新的区块可用为止。当从EventHub中剪切的新区块数据准备就绪时，排序者将其放入本地区块文件或RAM中，然后递送线程从分类账读取这个区块并将其发送回对等体。对等体获取这个区块，并将其提交到本地分类账，并且然后可以将其最新版本广播给其它对等体。

BCS系统体系架构

图1B图示了提供区块链服务的系统的架构中的交易流程。更具体而言，该图图示了根据实施例的区块链云服务(BCS)系统。如图所示，区块链云服务部件在计算空间120(例如，外部计算空间)中供应，例如在Oracle PaaS服务管理器(PSM)平台上供应。对系统的访问由PSM API 122和区块链REST API 124调解。外部计算120利用负载均衡即服务LBaaS126来跨可用的适当资源分发传入的交易。

根据实施例，BCS是在应用容器云服务128上利用PSM平台构建的应用-容器分层服务。BCS实体中的每一个都在单独的容器上运行。BCS实体中的每一个与应用容器一一对应。区块链云服务实现上述超级分类账架构的特征。除了构建基本架构网络的部件之外，还开发了若干部件来将超级分类账架构用于区块链云服务。这些部件需要分开的部署行为和二进制文件来部署这些部件。云堆栈管理器可以用于使用户能够自动将蓝图(blueprint)定义的所有服务作为被称为堆栈的单元进行供应。

在实施例中，BCS提供超级分类账架构的实现方案，该实现方案是用于运行智能合约的分布式分类账平台的实现方案。BCS利用容器技术来托管被称为“链式码”的包括系统的应用逻辑的智能合约。

根据实施例，架构的分布式分类账协议由对等体运行。架构区分两种对等体：验证对等体是网络上负责运行共识、验证交易和维护分类账的节点。另一方面，非验证对等体是用作将(发出交易的)客户端连接到验证对等体的代理的节点。非验证对等体不执行交易，但它可以核实它们。架构发布的一些关键特征包括具有即时终结性的许可区块链，其运行被称为链式码的任意智能合约。用户定义的链式码智能合约封装在容器中，并且系统链式码在与对等体相同的进程中运行。该架构通过支持对于TLS证书、登记证书和交易证书的证书颁发机构(CA)来实现共识协议和安全性。

根据实施例，BCS实体在具有ACCS 128的分层容器实例中运行。这些容器是通过PSM的供应操作而创建和/或起动的。架构-CA容器130是在其中提供BCS架构CA(证书和颁发机构)部件的容器。BCS对等体(容器)132是维护分类账并运行链式码容器以便对分类账部件执行读/写操作的BCS对等网络实体在其中运行的容器。BCS排序者容器134是提供服务来为所有通道将交易排序到区块链的BCS排序者在其中运行的容器。BCS链式码执行容器139是由对等实体创建和起动的容器。在该容器中，链式码执行单元与父对等实体通信并执行资产和交易指令的编码以修改区块链中的资产。

根据实施例，BCS链式码构建器容器140是由对等实体创建和起动的容器。在该容器中，安装和部署链式码构建环境，并在其中构建链式码执行单元。客户端侧架构SDK 106提供用于访问BCS的功能。区块链云服务还利用事件中枢云服务150、云存储服务152和身份服务154。Oracle存储云服务用作BCS的存储服务。

根据实施例，Docker/Weave(坞/织体)141是容器服务。容器提供了以能够在共享操作系统上隔离运行的格式来打包软件的方式。与VM不同，容器不捆绑整个操作系统——而是需要使用使软件工作所需的库和设置。这实现高效、轻量、自包含的系统，并保证软件始终同样地运行，无论它在何处部署。

根据实施例，每个BCS实例包括不同类型的节点。BCS实例中可以有少数个(例如，0个或更多个)至多个对等体节点。在BCS实例中可以有少数个(例如，0个)至多个排序者节点。BCS实例中有1至多个架构-CA节点，每个VM一个。BCS网关：BCS实例中可以有少数个(例如，0个)至多个BCS网关。BCS控制台也是BCS实例的部件。BCS实例中只有一个BCS控制台。

根据实施例，BCS管理服务器(控制台)136是BCS的部件，其向BCS栈实例提供丰富的监控、管理和视图功能，如下面更详细描述的。BCS网关(REST代理)138是BCS的新部件，并且向客户/客户端提供REST API接口，并且用于访问架构以执行交易，如下面更详细描述的。

根据实施例，在公共访问客户端侧100上，PSM控制台UI 102允许管理平台服务管理器。BCS控制台UI 104允许控制BCS管理服务器。各种不同的客户端类型可以访问BCS服务，包括架构SDK客户端106、BCS REST客户端108和架构成员资格客户端110。

根据实施例，可以为上面列出的每种类型的容器定义蓝图，作为单独的服务类型。Oracle云堆栈管理器使用蓝图自动将所有个体服务类型供应到单个堆栈单元中。为每个BCS实体定义服务类型的益处是易于升级和维护各种运行实体。应用容器分层服务支持四种类型的操作：CREATE_SERVICE(创建服务)，DELETE_SERVICE(删除服务)，SCALE_SERVICE(缩放)和Start/Stop/Restart(起动/停止/重启)。这些操作可以按服务来应用。

根据实施例，在超级分类账架构网络中，排序服务部件使用Apache Kafka以崩溃容错方式提供对多个链的排序服务和支持。因而，在BCS云服务中，排序服务部件将使用OEHCS(Oracle事件中枢云服务，该服务将Kafka的强大功能作为受管理的流传输数据平台提供，并且可以与Oracle云的其余部分集成)。

图1C图示了根据实施例的BCS系统。更具体而言，该图示出了BCS运行时。

根据实施例，诸如基于网关的应用103和/或基于架构的应用105之类的客户端可以经由诸如互联网107之类的网络并且经由可以包括云关(CloudGate，将在下面讨论)的诸如负载均衡器LBaaS 126之类的前端与AACS实例128进行通信。传入的调用可以包括REST通信(在图中示为较粗的虚线)，或者在某些情况下，传入的gRPC通信(在图中示为较浅的虚线)。传入的REST通信可以被引导到网关138(网关138可以包括REST API/REST代理)、控制台136或代理架构-CA 130(如上面所讨论的)。现在变换/转化为内部调用(gRPC)的REST通信可以与区块链架构/超级分类账的实例(包括代理/对等体132、代理/排序者134、链式码142和链式码构建器140)对接。同时，可以将传入的gRPC通信直接传输到例如代理/对等体132和代理/排序者134，以与区块链/超级分类账对接。

根据实施例，一旦ACCS实例内的交易已经发生，ACCS实例就可以例如经由REST通信将分类账持久化在云存储区(Storage)中，或者可以同样经由REST通信与事件中枢进行通信。

根据实施例，虽然图中仅示出了一个ACCS实例，但是本领域技术人员将容易理解的是，可以存在一个或多个ACCS实例，其中客户端(诸如基于网关的应用103和/或基于架构的应用105)可以经由所描述的BCS运行时与该一个或多个ACCS实例进行通信。

图1D图示了根据实施例的BCS系统。更具体而言，该图图示了BCS系统内的部件基数(cardinality)，即，部件相对于每个BCS实例的比率。

根据实施例，对于每个BCS实例100a：可以以1∶N的比率提供排序者101a；可以以1∶N的比率提供架构-CA成员资格102a；可以以1∶N的比率提供BCS REST-代理103a；可以以1∶1的比率提供BCS控制台104a，并且对等体容器105a可以以1∶N的比率呈现。

每个对等体容器可以包括可以模拟交易的背书者和可以对分类账应用改变的提交者，该分类账也在对等体容器处提供。

根据实施例，链式码109a可以相对于对等体容器以1∶N的比率提供。此外，存储区106a可以相对于对等体容器和排序者以N∶1的比率提供。同样，事件中枢107a可以相对于对等体容器和排序者以N∶1的比率提供。IDCS 108a可以相对于架构-CA成员资格以N∶1的比率提供。

区块链云服务(BCS)网关

根据实施例，BCS网关(BCSGW)包括使用架构SDK与架构网络进行通信的网络节点。BCS网关向客户端侧上的客户提供HTTPS RESTful API，该HTTPS RESTful API允许客户端/客户端应用与BCS的架构的元素进行交互。

图2图示了根据实施例的用于区块链云服务系统的网关。如图2所示，终端用户200使用HTTPS与应用适配器202进行交互以进行认证和授权。应用适配器202使用到诸如云关212(即，LBaaS)之类的LBaaS的HTTPS来访问公共云210。对传入的交易执行负载均衡即服务(LBaaS)。云关212使用HTTPS将交易传递到BCS网关222。BCS网关提供到BCS架构220的接口，其中通信利用gRPC远程过程调用协议。

根据实施例，云关212是反向代理“访问强制执行模块”或“策略强制执行点”，其使用例如OAuth2和OpenID连接(OpenID Connect)标准来保护web浏览器和REST API资源。IDCS在内部使用云关来保护自己的管理UI和REST API(称为“IDCS web层”)。对于其它应用，云关：OTD作为附加实例部署在称为Non-IDCS(非IDCS)或Standalone(独立)的半支持/临时设置中。

根据实施例，(对于UI客户端)基于OAuth/OpenID的认证支持用户浏览器流，该用户浏览器流在HTTP请求包含“用户-代理”报头(这意味着该请求来自如浏览器或移动app(应用)的UI)的情况下被触发。云关提示用户输入凭证(用户名/密码)、核实凭证，然后创建并返回OAuth会话cookie，该cookie可以被来自浏览器的后续HTTP请求使用。(对于编程客户端)基于OAuth/OpenID的认证还支持资源服务器流。这个流在HTTP请求包含认证“承载者(bearer)”令牌报头的情况下被触发。云关验证令牌以进行认证。

根据实施例，对于HTTP基本认证，对于每个HTTP请求，凭证(用户名/密码)必须被包括在HTTP授权“基本”报头中。云关为每个HTTP请求验证凭证。此方法适用于UI客户端和编程客户端两者。

根据实施例，多令牌流是覆盖某些HTTP请求的自适应方法。如果HTTP请求包含授权“基本”报头，那么云关将执行HTTP基本行为。如果HTTP请求包含授权“承载者”报头，那么云关的行为与资源服务器流相同。

在实施例中，BCS控制台浏览器客户端利用用户浏览器流。在实施例中，对于BCS控制台和网关编程客户端，系统可以使用云关多令牌认证方法。编程客户端可以经由HTTP基本认证来调用BCS REST API。

根据实施例，BCS网关222与对等体224进行通信，对等体224是维护分类账和运行链式码容器以便对分类账执行读/写操作的网络实体。对等体由成员拥有和维护。BCS网关222和对等体224与(一个或多个)排序者226进行通信。排序者提供排序服务。排序者是将交易排序到区块中的所定义的节点集合。排序服务独立于对等体进程而存在，并且在先来先服务的基础上针对网络上的所有通道对交易进行排序。对等体224和(一个或多个)排序者226与架构证书颁发机构228进行通信。BCS网关222还提供对BCS管理服务器/控制台230的访问。

根据实施例，BCS部署在诸如Oracle云之类的云系统上。网关可以在ACCS容器中运行。网关是无状态的。可以通过去除旧网关并起动新网关来更新网关。BCS网关可以通过RESTful协议允许客户查询或调用架构链式码。BCS网关允许客户端通过HTTPS/RESTful服务来访问Oracle云中的架构网络。BCS网关是使用架构SDK与架构网络通信的网络节点。架构内的通信使用gRPC作为通信协议。在客户端侧，BCS网关向客户提供HTTPS/RESTful API。REST API允许客户端使用架构SDK来调用架构内的功能。

根据实施例，可以与架构用户以一对一的关系提供网关。所有网关用户都属于一个组织，所有网关用户在一个网关中映射到一个架构用户。一个网关仅配置一个架构用户。

根据实施例，IDCS发布网关证书和网关用户(“应用适配器(App adapter)”)证书。这些证书是用组织CA签署的。网关和网关用户可以与组织CA一起部署，因此它们可以使用HTTPS进行相互验证。

根据实施例，每个终端用户通过“应用适配器”访问BCSGW。存在3层认证。终端用户200可以由应用适配器202进行认证。应用适配器202可以由BCS网关222用客户端证书进行认证。BCS网关可以由架构网络220中的对等体224和排序者226进行认证。

根据实施例，一个容器运行一个tomcat服务器、部署一个BCS网关、映射到一个架构用户。多个应用适配器可以连接到一个网关。

根据实施例，不同的网关可以与不同的架构用户相关联。连接到一个网关的应用适配器的终端用户可以映射到一个架构用户。

根据实施例，BCSGW在Oracle云中运行，配置由BCS控制台使用JSON文件设置。admin(管理员)用户可以将部分对等体、通道和链式码发布到网关。管理员用户通过控制台起动网关。网关在启动之后不刷新配置。管理员用户可以为链式码设置背书者。终端用户不知道策略，网关不检查链式码策略。

根据实施例，BCSGW由BCS控制台起动。BCS控制台创建BCSGW配置文件，并且使用BCSGW包来起动新网关。在起动后，起动脚本检查BCSGW配置文件，修改Tomcat的配置文件(例如，Tomcat配置文件)，然后起动Tomcat。Tomcat为每个通道起动用于BCSGW的线程(线程读取配置文件)，它创建通道对象，并创建与排序、对等体、事件中枢的连接。不同的通道将与排序/对等体/事件中枢具有不同的连接。这里的事件中枢是对等体的第二端口。网关连接到这个端口以获取交易的结果。Tomcat servlet(小服务程序)容器可以侦听并等待客户端请求。对于链式码查询方法，BCSGW将请求发送给该通道的所有对等体，并仅使用第一个结果。对于链式码调用方法，BCSGW将请求发送给该通道的所有背书者，如果其中一个返回成功，那么BCSGW将交易发送给该通道的所有排序者。

根据实施例，异步API被支持。对等体可以打开两个端口，一个端口用于事件交换。网关可以连接到对等体的事件端口。对于一个通道，网关只需连接到一个事件端口。普通客户端API是同步的。交易可以花费几秒钟，客户端需要等待响应。向客户端发送异步事件不在V1计划中。除了同步交易API之外，网关还提供异步交易API“asyncinvoke”。

在实施例中，异步API可以以这种方式工作。在检查客户端请求的参数之后，网关将交易ID返回给客户端。客户端可以知道交易已起动但尚未完成。网关将起动后台线程以继续交易中的处理。客户端可以跟踪未完成的交易。网关可以为客户端提供用于使用交易ID查询交易状态的“交易”API。

根据实施例，可以支持客户端登录。BCSGW可以支持HTTPS协议，并且不允许不安全的HTTP访问。BCSGW使用证书来信任应用适配器或SALT。应用适配器可以认证终端用户。Tomcat需要设置为使用HTTPS客户端证书认证。密钥库文件包括BCSGW证书和CA证书以验证客户端由BCS控制台提供。BCS网关为客户端访问提供BCS Rest接口。

持久化–-存储云

根据实施例，超级分类账架构项目代码将分类账的区块存储在本地文件系统中，并且其它运行时数据(如区块索引、世界状态、历史和分类账提供者数据库(保持所有分类账ID和恢复状态)存储在LevelDB中，LevelDB也存储在本地文件系统中。在ACCS中，容器文件系统是临时的，这意味着当由于某些硬件故障容器停止并且在新VM上重新起动新容器时—文件系统内容可能丢失。考虑所有容器丢失的情况，则无法恢复分类账。因此，分类账数据必须存储在ACCS容器之外。因此，以对象存储服务的形式提供持久化解决方案，以供上述超级分类账架构的部件使用。

根据实施例，相应地在BCS中，持久化解决方案利用存储云服务(例如，Oracle存储云服务)。分类账被备份到对象存储库。分类账区块写入容器文件系统，但也备份到对象存储区。索引和世界状态使用容器文件系统记录，但如果重新起动容器，那么可以从存储云服务恢复。Oracle存储云是为文件和非结构化数据提供企业级大规模对象存储解决方案的基础设施即服务(IaaS)产品。

图3图示了根据实施例的区块链云服务系统的持久化。如图3中所示，ACCS实例300包括多个容器。容器包括例如排序容器302、304，其具有分类账/区块链312、314。分类账/区块链312和314通过REST接口备份到对象存储区320。对象存储区320可以是例如云存储服务。

对象存储区用于持久化每个排序者的分类账。排序者向对等体递送区块的当前机制如下。首先，对等体通过发送其版本(最后的区块编号)递送对来自排序者的新区块的请求。接下来，排序者检查对等体的版本，a)如果它大于排序者，那么向对等体返回错误，它指示排序的分类账丢失，并且无法从EventHub(事件中枢)中恢复。在这种情况下，排序者无法继续恰当地工作。b)如果对等体的版本小于排序者，那么排序者从RAM中或者本地文件中的本地分类账中检索区块，然后发送回对等体。c)如果它们具有相同的版本，那么排序者将阻塞直到新的区块可用为止。当从EventHub中剪切的新区块数据准备就绪时，排序者将其放入本地区块文件或RAM中，然后递送线程从分类账读取这个区块并将其发送回对等体。最后，对等体获取这个区块，并将其提交到本地分类账。接下来，分类账的最新版本可以被广播给其它对等体。

根据实施例，根据上述处理，排序者或者EventHub可以持久化整个区块。如上所述，EventHub具有时间受限的保留(retention)。如果EventHub可以这样做，那么排序者可以将分类账类型设置为RAM或文件，一旦排序者重新起动并且分类账丢失，它就可以重放来自EventHub的记录并将批处理消息剪切成区块，然后可以重新构建分类账。如果EventHub仅支持有限的保留期，那么一旦排序者重新起动并且分类账丢失，它就无法正确重新构建分类账，因为EventHub中的第一条记录不是分类账中的真实的记录。在这种情况下，排序者无法起动旧通道，因为带有通道信息的第一个区块丢失，并且版本号(最后的区块编号)也不正确。

然后，根据实施例，每个排序者可以将每个区块持久化到Oracle存储区，同时将所有通道ID也保存到存储区中的对象。在对等体上，只持久化起源(genesis)区块，因为它具有通道信息。对于其它区块数据，对等体可以在其丢失后从排序者中检索它。

根据实施例，ACCS实例300还可以包括对等体容器306、308，对等体容器306、308包括分类账316、318和索引326、328。存在由对等体生成的五种类型的运行时数据：交易日志(区块文件)；区块文件索引(LevelDB)；分类账提供者(LevelDB)；状态数据库(LevelDB或couchdb)；历史(LevelDB)。所有交易数据都作为本地文件中的链接区块存储在交易日志中，它必须被持久化到Oracle存储云服务。分类账提供者DB在LevelDB中保留所有分类账ID和恢复状态。分类账ID是识别对等体所属通道的唯一ID。它必须被持久化到Oracle存储云服务。对于其他方，对等体可以在运行时自动恢复它，因此将它们保持在本地文件系统中。

根据实施例，Oracle存储云服务提供用于向对象上传/从对象下载文件的RESTAPI。当生成新区块时，首先，它将像以前一样写入本地区块文件，区别是每个文件一个区块。接下来，这个区块文件将作为对象被上传到Oracle存储区。如果失败，那么本地文件中的改变将回滚，并且将向调用者返回错误。

根据实施例，对于区块文件索引，当排序者更新最新检查点时，可以首先将该信息持久化到Oracle存储区，然后更新本地LevelDB。如果操作的事件失败，那么可以将错误返回给调用者。这个信息将用于区块文件索引的恢复。在Oracle存储区中，每个对等体和排序者都有唯一的容器名称，该唯一的容器名称是msp id和节点id的组合。对象名称是以通道名称为前缀的区块文件的名称。有关更多详细信息，请参见Oracle存储区中的名称约定部分。

根据实施例，可以提供保存分类账提供者DB到Oracle存储的选项。对于分类账提供者DB，整个LevelDB可以一被更新就被复制到Oracle存储云服务。这个文件非常小，并且更新不频繁，因此可以忽略关于复制的开销。当容器重新起动时，可以从Oracle存储云服务下载它(如果存在)。如果排序者是从新容器重新起动的，那么它将首先从存储对象下载通道ID，然后通过通道ID从存储区获取最新检查点。接下来，从第一个区块到最后一个区块起动恢复区块索引。在此期间，将逐个下载区块文件。之后，排序者开始恢复状态DB和历史DB。如果对等体从新容器重新起动，那么它将首先下载分类账提供者DB，然后它可以获得所有分类账ID。接下来，通过分类账ID从存储区获取相关的起源区块。对等体以起源区块中的配置启动，并且向排序者递送获取其它区块数据的请求。在对等体获取这些区块之后，它开始恢复区块索引、状态和历史DB。

根据实施例，本地区块文件充当读取高速缓存。查询将首先从本地读取数据，如果它不存在，那么从对象存储区下载。除了分类账之外，还需要将链式码的源代码持久化到Oracle存储区。在当前架构中，编码的源代码将在安装链式码之后存储在对等体上。对等体将针对每个调用或实例化检查链式码容器，如果容器不存在，那么对等体将从源代码重建它。因此，可以将其上传到Oracle存储区以进行每个链式码安装，并在对等体从盘故障重新起动时下载它。

BCS：基于SDK的配置文件操作和供应后(post-provision)部署

根据实施例，配置文件和部署函数在部署或更新应用时部署、发起生成、更新和获得关于应用的配置，包括对等体、排序者、CA服务器和链式码。这些函数驻留在BCS控制台(Node.js)和架构容器(对等体/排序者/链式码容器)两者中。这些函数将根据UI的请求获取/更新配置，并在需要时调用SDK API以激活配置更改。作为BCS控制台后端的一部分的部件与BCS控制台UI、IDCS后端SDK和所有BCS应用进行交互，以根据请求为UI操作获取/更新配置提供SDK。该部件还有助于供应BCS应用。BCS供应部件将BCS应用部署到使用PSM创建的VM的Docker容器中。这个特征将实现用于使BCS控制台UI和BCS供应部件在供应后阶段获取或更新BCS应用配置和部署的SDK API。在供应后阶段，供应系统将在Docker/Swarm(群)下部署BCS应用，诸如CA服务器、排序者、对等体。当VM起动时，它将调用启动脚本来执行供应后和VM初始工作。

根据实施例，为包括对等体、排序者、架构CA和BCS网关的架构部件提供配置文件。BCS应用包、配置和链式码存储在客户的存储云服务中。

根据实施例，供应系统应当完成所有资源分配。资源包括VM、网络和存储区。

根据实施例，供应系统应当将所有资源分配信息保存到存储服务。该信息包括VM编号及其网络地址/账户凭证、每个VM中的BCS应用编号及其类型、公共和内部IP。并且还应当存在用于容器的足够的内部IP地址(可在VM之间访问)。

根据实施例，当BCS供应部件已完成供应工作时，VM启动脚本将起动，然后调用swarm部署应用容器，并且在容器内部调用容器startup.sh脚本以执行发起操作。

根据实施例，BCS控制台将在其起动时从存储服务获取配置，并且将用户操作的输入从UI保存回存储服务，然后将重新起动命令发送到swarm。

根据实施例，所需的安全证书可以保存在IDCS中。可替代地，可以从IDCS检索安全证书。

根据实施例，BCS控制台后端可以利用swarm与BCS应用进行通信。

根据实施例，当BCS应用容器启动时，BCS应用可以搜集配置细节以决定其应用类型(对等体或链式码容器或其它)，然后加载所需的配置。

根据实施例，这个部件更新配置并提供BCS应用启动shell代码。BCS获取/更新配置文件操作可以分为几个部分。首先，BCS控制台在起动时将从存储区中获取配置，并在需要更新时将配置从BCS控制台保存到存储区中(shell和Node.js)。当BCS应用容器启动时，启动脚本(在每个Docker容器中)将首先起动，然后获取其应用类型的配置，并从IDCS(shell)获取app cert(应用证书)。当BCS控制台UI重新起动BCS应用时，它向Docker/Swarm发送消息以重新起动容器中的应用。

根据实施例，BCS控制台是无状态的，并且当被起动时，可以搜集所有BCS实例配置并连接到BCS应用并监控它们。配置将经由后端API从存储服务获得。当任何配置改变时，BCS控制台将调用后端API以将配置保存回存储服务并重新起动相关的应用。当客户经由BCS控制台UI更改配置项时，UI将配置编码为键/值数据，后端代码将其变换为文件并保存到存储服务中。BCS控制台可以监控、起动和停止BCS应用。起动和停止命令使用Docker/Swarm API来实现这个功能。

架构网络的部署

根据实施例，架构网络包括以下实体：对等体、客户端、排序服务和促进这些实体之间的通信的协议集合。组织是构成架构网络的利益相关者的逻辑实体或公司。架构网络有多个参与组织。成员：拥有用于网络的唯一根证书的法律上独立的实体。诸如对等体节点和应用客户端之类的网络部件将链接到成员。每个组织可以具有一个或多个成员。一个组织可以同时贡献于排序者和对等体，或仅贡献于排序者，或仅贡献于对等体。

部署架构网络的第一步是定义参与者。这一步在架构网络的带外完成。架构网络的所有参与组织协商并完成网络的组成，包括例如哪些组织贡献于排序者节点，以及哪些组织贡献于对等体节点。贡献于排序者节点的每个组织都会发布其排序者服务器的根证书。贡献于对等体节点的每个组织都会发布其对等体服务器的根证书。具有客户端的每个组织都会发布其客户端的根证书。客户端可以在一个组织中与对等体分离到不同的成员。

作为示例，四个银行(银行1、银行2、银行3和银行4)已经决定使用排序服务来部署区块链网络，该排序服务将包括由银行1和银行2拥有的排序者节点。并且银行1在这个网络中仅贡献于排序者。每个银行都是架构网络的组织：银行1有1个成员：排序者(root_cert_1)；银行2有3个成员：客户端(root_cert_21)、对等体(root_cert22)、排序者(root_cert23)；银行3有2个成员：客户端(root_cert31)、对等体(root_cert32)；银行4有2个成员：客户端(root_cert41)、对等体(root_cert42)。

在定义参与者之后，为排序者和对等体生成证书。每个排序者或对等体需要(私钥，签署的证书)对来标识它自己。每个成员可以利用其根证书来配置和起动其自己的架构CA服务器，并使用CLI或SDK请求CA服务器为这个成员的每个排序者/对等体服务器生成(私钥，签署的证书)。BCS提供可以提供证书的架构CA服务器。但是，架构CA服务器不是生成证书的唯一方法。用户可以使用其它CA系统来执行相同的操作。因此，架构CA服务器不是架构网络中的强制性部件。

在为排序者和对等体生成证书之后，通过创建系统通道来引导(bootstrap)架构网络。对于排序服务只有一个系统通道(对于一个架构网络也是如此)，并且它是要被创建(或更准确地说是要被引导)的第一个通道。系统通道定义架构网络的组成：

●一个排序服务

○一个或多个排序者组织。每个组织的

■MSPID

■证书

○排序服务属性(例如类型-solo或Kafka、排序者地址、批的尺寸/超时)

○策略(其可以创建通道等)

●一个或多个联盟(consortium)。每个联盟包含

○一个或多个对等体组织。任何想要参与这个架构网络的对等体组织必须在其中一个联盟中定义。每个组织的

■MSPID

■证书

■锚对等体

在架构网络系统通道被引导之后，为系统通道创建起源区块(链中的第一个区块)。排序者服务管理员为系统通道生成起源区块。起源区块可以通过工具configtxgen(genesismethod＝file)生成，或者在排序者启动期间(genesismethod＝provisional)生成。当使用configtxgen工具生成起源区块时，你必须编写配置文件configtx.yaml作为输入。这个文件包含以下信息：架构网络中所有排序者组织的根证书；所有对等体组织的根证书；排序服务属性：排序者类型、地址、批超时、批尺寸、kafka；策略；通道读取器：认证和验证通道递送请求；通道写入者：认证和验证通道广播请求；链创建者：评估链创建请求；管理员：认证和验证通道重新配置请求。

排序者服务管理员利用配置文件和起源区块来起动排序者服务器。这使用起源区块创建系统通道。起动排序者服务器需要配置文件orderer.yaml：监听地址/端口、分类账类型等；LocalMSP(私钥，签署的证书)。提供排序服务的每个组织都会起动其排序者服务器(不应当指定起源区块)。

贡献于对等体节点的每个组织为每个对等体准备配置文件(default location/etc/hyperledger/fabric/core.yaml)以指定：LocalMSP(私钥，签署的证书)以标识对等体；以及对等体属性：监听地址/端口、引导对等体、闲聊(gossip)属性等。然后起动对等服务器。

在起动排序者和对等体之后，通道管理员(其具有创建通道的特权)使用架构CLI或SDK来请求排序者创建具有以下输入的通道：一个联盟(必须已在系统通道中定义)；以及联盟中的一个或多个对等体组织。每个参与组织使用架构CLI或SDK将其对等体中的一些连接到新创建的通道。

示例：BCS上的架构网络的部署

图4图示了BCS上的架构的示例部署。

更具体地，该图及描述描述了在BCS上部署架构网络的步骤。在这个示例中，四个实体A、B、C和D想要创建和加入架构网络。四个实体离线讨论并决定各个实体的责任。每个实体在OPC上创建一个或多个BCS实例。

根据实施例，实体A提供排序者和对等体两者。实体A创建两个实例：用于排序者的Orderer_Org1 401和用于对等体的Peer_Org1 421。实体A还负责创建架构网络(注意：只有排序者才能创建架构网络)。排序服务400包括Orderer_Org1 401和Orderer_Org2 402以及Kafka集群410。

根据实施例，实体B提供排序者和对等体两者。实体B创建两个实例：用于排序者的Orderer_Org2 402和用于对等体的Peer_Org2 422。

根据实施例，实体C仅提供对等体。实体C创建实例Peer_Org3 423。

根据实施例，实体D仅提供对等体。实体D创建实例Peer_Org4 424。

根据实施例，每个BCS实例的管理员从BCS控制台收集当前组织的CA证书和admin证书。每个对等体组织的管理员识别当前组织的锚对等体并收集锚对等体的IP/端口。这四个实体离线地互相交换所有收集到的信息。

根据实施例，Orderer_Org1的管理员从BCS控制台通过利用在先前步骤中收集的以下信息创建系统通道来创建架构网络：每个组织的CA证书和admin证书；以及每个对等体组织的锚对等体。后端工作包括调用架构工具来创建起源区块以及配置排序者来使用起源区块创建系统通道。

根据实施例，每个对等体组织的管理员从BCS控制台通过更新所有对等体节点的配置以添加所收集的其它组织的CA/admin证书并重新起动所有对等体节点来加入架构网络。

根据实施例，在系统中，提供了允许新组织加入现有架构网络的方法。此外，可以提供用户友好的方法来促进参与者之间的通信以便创建/加入架构网络以例如覆盖初步形成架构的离线动作。

链式码(智能合约)容器

根据实施例，并且如上面所讨论的，链式码是定义一个或多个资产的软件，以及用于修改(一个或多个)资产的交易指令。链式码强制执行用于读取或更改键值对或其它状态数据库信息的规则。链式码函数针对分类账当前状态数据库执行，并通过交易提议被发起。链式码执行导致键值写入的集合(写入集)，其可以提交给网络并应用于所有对等体上的分类账。

根据实施例，为了支持信息的一致更新——以及启用多个分类账功能(交易、查询等)——区块链网络使用智能合约来提供对分类账的受控访问。智能合约可以封装信息、跨架构自动复制信息，并且它们也被编写为允许参与者自动执行交易的某些方面。

根据实施例，超级分类账架构智能合约以链式码编写，并且当区块链外部的应用需要与分类账进行交互时由该应用调用。在大多数情况下，链式码只与分类账的数据库部件、世界状态进行交互(例如，查询它)，而不与交易日志进行交互。

根据实施例，超级分类账架构利用Docker引擎来构建链式码、部署它并使其保持运行。本节描述架构体系架构以及如何将其集成到BCS的ACCS分层模型中。

根据实施例，架构如下所述部署和管理用户链式码：第一，在临时的CC env容器中构建链式码。第二，将链式码作为源代码传送到构建器容器(builder container)中，使用静态链接的所需库进行编译(“Java构建”)，然后将二进制文件发送回对等体。静态链接允许实际的链式码容器尽可能小。第三，构建链式码映像(image)和容器并起动它。然后，链式码容器保持运行，直到对等体关闭或通道终止为止。如果链式码容器崩溃或被去除，那么在映象存在的情况下在下次调用时重新起动它。设计是每个对等体和通道有一个链式码Docker容器。链式码明确安装在对等体上。即：并非加入通道的所有对等体都必须安装链式码。

根据实施例，用户可以在ACCS分层容器中部署架构网络，该ACCS分层容器具有透明地分发诸如对等体、排序者和链式码之类的部件的能力。链式码运行时环境容器(ccenv)将作为ACLS容器动态起动。链式码二进制文件将保存在云存储区中，因为本地区块存储区不被视为可靠的恢复方式。一旦构建，链式码二进制文件就将被上传到云存储区，以用于在容器崩溃情况下的恢复目的。

根据实施例，每个链式码交互可以与链式码的各种函数对应。唯一的限制是在链式码被实例化之前不能被调用或查询。此外，在任何调用时，如果链式码容器不能被发现为正在运行，那么重新起动该链式码容器。

图5图示了根据实施例的链式码体系架构。更具体而言，该图图示了根据实施例的链式码体系架构，该链式码体系架构允许客户端530在ACCS环境500中安装链式码并运行交易。步骤1，客户端530将链式码源代码安装到对等体1 510。首先在临时的CC env容器中构建链式码。当客户端530执行“安装”时，它将：起动构建器容器(该容器将自动起动构建器代理)、等待构建器容器完成初始化、经由对等体将链式码源代码发送到构建器容器(步骤2)。构建器代理将构建链式码(Java构建)。链式码作为源代码被传送到构建器容器中，使用静态链接的所需库进行编译(“Java构建”)，然后将二进制文件发送回对等体。静态链接允许实际的链式码容器尽可能小。一旦构建，链式码包(tgz文件)就将被上传到云存储区560(步骤3)。构建器代理将云存储位置发送给对等体以供稍后引用(步骤4.2)。

根据实施例，对等体510然后将使用PSM REST API将CC env作为ACLS(访问控制列表)容器520起动。构建链式码映像和容器并起动它。然后，链式码容器保持运行，直到对等体关闭或通道终止为止。对等体510将链式码ID、自身IP(用于链式码注册)和云存储位置传递到ACLS容器起动(步骤4.1)。对等体将等待链式码起动，或者在设定的时间段后超时。ccenv将起动链式码。在启动后，链式码将自身向对等体注册(步骤4.3)。链式码将准备好在交易中调用(步骤5)，该交易将使用在注册时建立的连接来执行。

根据实施例，构建器容器550包括简单的REST型服务器。构建器容器550包括构建器代理553。构建器容器550启动并侦听链式码构建请求。当构建器容器550接收到构建请求(例如：具有base64编码的源代码作为主体的POST调用)时，它对源代码进行base64解码并将链式码源代码保存在本地文件系统中。然后，构建器代理553对源代码执行“Java构建”。如果“Java构建”成功，那么构建器代理553打包二进制文件并上传到云存储区560。构建器代理还将链式码位置返回给对等体。如果“Java构建”失败，那么代理将错误和原因返回给对等体。

BCS管理控制台

如上所述，BCS的每个实例可以包括管理控制台，该管理控制台可以用于管理和监控BCS实例，包括BCS网关、BCS节点和BCS通道。

根据实施例，用于提供管理控制台的系统可以包括在脚本运行时环境中运行的web应用，例如Node.js。该web应用可以构建在图形用户界面框架和web框架上；并且可以包括多个自定义功能或API，以与BCS实例中的各种节点或服务进行通信。该web应用可以将来自BCS实例中的各种节点或服务的信息填充到视图对象中，以便在控制台用户界面中显示。管理控制台还可以为管理员提供起动、停止和更新BCS实例中的一个或多个节点的功能。一组管理REST API可以由脚本运行时环境提供，或者可以由脚本运行时环境访问，以支持与web应用提供的功能相同的功能。

根据实施例，系统可以通过由web应用提供的web界面或通过使用一组管理RESTAPI编写的自定义REST客户端应用来促进对相关联的BCS实例的监控和管理。

根据实施例，管理控制台可以使BCS管理员能够管理BCS实例的多个部件，包括一个或多个对等体节点、一个或多个排序者节点、一个或多个架构-CA节点、一个或更多BCS网关节点、通道和一个或多个链式码。

根据实施例，管理BCS部件可以包括执行以下操作中的一个或多个：起动部件、停止部件、添加部件、移除部件、查看/编辑部件的属性、查看部件的性能度量、以及查看部件的日志。

图6图示了根据实施例的用于提供管理控制台的系统。

如图所示，可以在应用容器云服务128中提供BCS管理控制台136作为BCS实例的部件。BCS管理控制台可以是在脚本运行时环境605中运行的web应用，该脚本运行时环境605可以表示由Node.js提供的运行时环境。

根据实施例，在管理控制台内，可以存在架构节点SDK 611、多个架构自定义函数613、以及多个ACCS API 615。SDK、自定义功能和ACCS API可以用于与架构网络601进行通信，该架构网络601可以包括分布式流传输服务(例如，Kafka)603。管理控制台还可以包括视图对象623，该视图对象623可以包含需要在BCS控制台UI 104或REST客户端604中显示的信息，或者包含需要从BCS控制台UI或REST客户端传递到管理控制台的信息。架构节点SDK611可以操作以映射来自架构网络的信息与BCS控制台UI或REST客户端的信息。

根据实施例，BCS管理控制台还可以包括GUI框架(例如，JET)617和web框架(例如，Express)619。GUI框架可以提供可以在管理控制台web应用中使用的各种用户界面(UI)部件和元素。例如，这些UI部件和元素可以用于创建表单、收集数据和可视化数据。web框架可以用JavaScript编写，并且可以提供web应用框架，该web应用框架包括开发web和移动应用的鲁棒的特征集合。

图7A-图7B图示了根据实施例的BCS控制台UI中的用户界面的示例。

根据实施例，如图7A中所示，BCS概要(summary)711可以显示在仪表板(dashboard)中。该概要可以包括组织的数量、对等体的数量、排序者的数量、通道的数量和链式码的数量。

根据实施例，可以显示BCS实例的健康信息713。可以可视地显示和数字化地显示该健康信息。样本UI还可以显示交易执行714和分类账概要715。

根据实施例，图7B图示了用于BCS实例中的所有节点的信息。例如，样本UI示出了总共5个节点，包括2个对等体、1个排序者、1个架构-CA和1个REST代理(在BCS网关节点内)。对于每个节点，概要UI 717显示节点的名称723、节点的路由信息725、节点的类型729、以及节点的状态信息731。样本UI包括用于使管理员添加节点的按钮721，以及用以过滤节点的一个或多个下拉列表719。

节点管理

根据实施例，可以存在可以使用管理控制台来管理BCS实例的两个实体：BCS管理员和BCS用户。每个BCS实例只有一个BCS管理员账户。该BCS管理员账户可以在创建BCS实例时被创建。BCS管理员可以与架构-CA管理员捆绑在一起(即，BCS管理员从BCS控制台或通过BCS管理REST API执行的所有动作都使用架构-CA管理员身份)。可以存在多于一个的BCS用户账户，该BCS用户账户可以由BCS管理员通过注册架构-CA身份来创建。

根据实施例，BCS实例中的节点可以显示在一个web页面中。管理控制台可以支持两种模式。在第一种模式下，每个节点的名称、类型、访问URL和状态可以被呈现为列表。在第二种模式下，每个对等体参与的通道可以在图中呈现。

另外，根据实施例，管理控制台可以使BCS管理员能够起动和停止对等体节点、排序者节点、架构-CA节点和BCS网关节点；以及添加和移除对等体节点、排序者节点和BCS网关节点。架构CA节点无法被添加或移除。

根据实施例，当添加节点时，BCS管理员可以设置节点的属性。新添加的节点可以作为添加操作的一部分而自动起动。当节点被移除时，该节点将被停止并从BCS实例中被移除。

根据实施例，BCS控制台UI可以列出活动对等体节点参与的所有通道，以及安装在活动对等体节点上的所有链式码。

根据实施例，当管理对等体节点时，BCS管理员可以将活动对等体节点加入现有通道，并查看和编辑活动排序者节点的属性。BCS用户可以查看活动对等体节点的属性中的一些属性。

另外，可以在BCS控制台UI中显示活动对等体节点的快照性能度量，诸如：存储器使用情况、所使用的CPU百分比、网络I/O和盘I/O。

根据实施例，当管理排序者节点时，BCS管理员可以查看活动排序者节点的日志、查看和编辑活动排序者节点的属性。BCS用户可以查看活动对等体节点的属性中的一些属性。与管理对等体节点类似，BCS管理员可以查看活动排序者节点的以下快照性能度量：存储器使用情况、所使用的CPU百分比、网络I/O和盘I/O。

根据实施例，当管理架构CA节点时，BCS管理员可以查看和编辑活动架构CA节点的属性、从活动架构CA节点获取CA证书、以及查看活动架构CA节点的日志。另外，BCS管理员可以查看活动架构节点的以下性能度量：存储器使用情况、所使用的CPU百分比、网络I/O和盘I/O。

如上所述，管理BCS网关节点可以包括添加或更多地移除BCS网关节点。由于所允许的BCS网关节点的最大数量是在实例化特定BCS实例时指定的，所以可以被添加到BCS实例的BCS网关节点的数量受所配置的BCS网关的最大允许数量的限制。

根据实施例，每个BCS网关节点可以具有名称，该名称是该网关节点的全局唯一身份。将来配置BCS网关节点时可以引用该名称。也可以在创建BCS网关节点时确定并显示网络地址。

根据实施例，当配置BCS网关节点时，BCS管理员可以定义BCS网关配置文件，并引导BCS网关节点。在供应BCS实例时，可能没有创建任何通道或部署任何链式码。照此，直到在部署一个或多个链式码并且通过管理控制台定义有效的BCS网关配置时，BCS网关节点才起作用。

对于每个BCS网关节点，可以存在配置页面。在某些实施例中，可以在配置页面中配置以下项：

1).通道：选择通过当前网关节点暴露哪些通道。

2).链式码：从每个通道中所有实例化的链式码的列表中选择暴露哪个实例化的链式码。

3).背书者：对于每个链式码，定义背书对等体。

4).根据如上所述的设置生成BCS网关配置。一旦为BCS网关生成了有效的配置文件，就可以起动该网关。

根据实施例，BCS控制台允许使用列表视图功能来查看BCS网关属性。在列表视图中，为每个BCS网关提供以下信息：

1).名称：当创建网关时指定的全局唯一名称。

2).架构身份名称：每个BCS网关可以与架构客户端身份相关联，该架构客户端身份在创建BCS网关时被注册和登记。BCS网关采取的所有动作(例如，调用、查询)可以被授予此架构客户端的权限。

3).网络地址：具有公共互联网网络地址的接入点。

4).状态：开启或关闭

根据实施例，管理控制台还允许BCS管理员查看活动BCS网关节点的日志，并查看以下BCS网关度量：

1).已连接的客户端：客户端名称、地址、登录时间等。

2).当前交易信息：当前交易信息可以与状态信息(即，这个交易所处的状态)一起可用。当前交易信息可以在调试挂起的交易时有用。

3).交易统计信息：交易统计信息可以通过管理控制台UI可用。例如，交易统计信息可以包括已完成的交易的数量、接收的事件通知的数量、以及递送的事件通知的数量。

4).存储器使用情况。

5).CPU百分比。

6).网络I/O。

7).盘I/O。

通道管理

根据实施例，BCS用户可以列出当前BCS实例参与的所有通道。BCS管理员可以利用作为输入的通道名称、联盟名称和一个或多个组织名称来创建通道。还可以显示输出以指示通道创建的成功或失败。

根据实施例，BCS用户可以查看通道的参与节点和组织。管理控制台可以支持两种视图模式：列表模式和拓扑模式。在列表模式中，参与的本地节点和外部组织(由其锚对等体表示)可以被列出为列表。在拓扑模式中，参与的本地节点和外部组织(由其锚对等体表示)可以在拓扑图中表示。

根据实施例，BCS管理员可以查询通道中的对等体的分类账。分类账可以由交易区块的列表组成，每个区块可以包含区块ID、先前的散列、数据散列、时间戳、交易ID列表、动作(1..n)、链式码ID、链式码提议、响应(r/w集合、事件、成功或失败)、以及一个或多个背书者。还可以显示以下统计信息：区块的数量以及调用的数量。

根据实施例，BCS管理员可以列出在通道中实例化的所有链式码。列出的项可以包括链式码ID和版本。BCS管理员还可以查看实例化的链式码的以下信息：路径(Path)，它是由实例化的交易指定的路径；以及实例化自变量。

根据实施例，BCS管理员可以升级通道中的实例化的链式码。升级操作可以采用以下输入：具有安装的新版本的链式码的目标背书对等体；一个或多个排序者；链式码版本；以及自变量，该自变量可选地可以是特定于链式码的字符串(String)数组自变量。升级操作的输出可以是成功或带有错误消息的失败。

链式码管理

根据实施例，BCS管理员可以列出安装在当前BCS实例的任何对等体上的所有链式码。列出的项包括链式码ID和版本。此外，BCS管理员还可以查看已安装链式码的以下信息：具有安装的链式码的本地对等体节点，以及已经实例化链式码的通道。

根据实施例，通过管理控制台，BCS管理员可以将链式码安装到一个或多个本地对等体节点。安装操作的输入可以包括：目标对等体；链式码类型，例如golang/Java；链式码ID，其可以是链式码的名称；链式码版本；链式码路径，其可以是链式码的源代码的位置；以及链式码包，这是可选的。安装操作的输出可能是成功，或者带有错误消息的失败。

根据实施例，BCS管理员可以将安装的链式码实例化到通道，其中以下信息作为输入：通道名称；其上安装有链式码的目标背书对等体；排序者；自变量，该自变量可以是可选的并且可以是特定于链式码的字符串数组自变量；以及背书策略，该背书策略具有定义的格式或者在没有定义的格式的情况下具有默认格式。

成员资格管理

根据实施例，BCS管理员可以列出当前BCS实例中的所有身份、为当前BCS实例注册新用户/身份、注销身份、以及从当前BCS实例中移除用户。另外，BCS管理员可以查看/编辑身份的以下属性，如表1所示：

表1

根据实施例，管理控制台使BCS用户能够登记或重新登记该用户自身，这可以为用户生成私钥和证书。管理控制台还使BCS管理员能够撤消之前登记的身份，并使得BCS用户能够改变它的密码。

根据实施例，BCS管理控制台可以与相关联的BCS实例的起动或停止一起起动或停止。

根据实施例，可以有两种方式来设置BCS管理控制台的日志级别：从BCS管理控制台本身，以及使用管理REST API来改变运行时的日志级别。

REST API

如上所述，架构网络内的不同部件之间的通信基于gRPC协议。照此，基于架构网络的BCS实例将要求客户端应用使用架构SDK来调用BCS实例中的链式码。

要求客户端应用使用架构SDK与区块链云服务进行通信可能部分地抵消将区块链框架提供作为云服务的益处。例如，益处之一是应当利用互联网连接从任何地方访问云服务。

根据实施例，本文描述的系统和方法可以在BCS实例内提供REST代理。REST代理可以提供多个REST API，供REST客户端使用以通过链式码进行查询、通过链式码同步或异步地调用交易、获取交易状态、以及获取BCS代理版本。REST代理可以认证来自REST调用的REST调用，并将REST调用转化成GRPC调用。REST代理还提供了REST API，该REST API支持与BCS管理控制台提供的功能相同的功能。

根据实施例，REST代理为客户端应用提供消费BCS实例的用户界面。

图8图示了根据实施例的用于在BCS实例中提供REST代理的系统。

如图8中所示，REST代理138可以包括REST认证器827和协议转换器829。当BCSREST API客户端808向REST代理发送REST调用815时，连接到云关811的LBaaS126可以认证该调用，以确定REST调用是否包括有效用户名称和有效密码以允许REST访问BCS实例。

根据实施例，如果REST调用被LBaaS认证，那么LBaaS可以将REST调用引导到REST代理，REST代理可以将REST调用835转发到IDCS 813以确定客户端应用是否已经被授予相对于BCS的适当的授权。

根据实施例，如果客户端应用被适当授权，那么REST代理可以将REST调用转化/转换成gRPC调用825，并且将该GRPC调用发送到架构网络601。REST调用一旦被变换/转化为内部调用(gRPC)，就可以与区块链架构/超级分类账的实例对接。

根据实施例，REST调用可以由协议转换器转化，该协议转换器可以是基于具有GRPC库833的架构Java SDK 831的Java应用。

如图8中进一步所示，REST代理可以使用REST 821如上所述与管理控制台进行通信，以将由REST API 823提供的一个或多个功能暴露给管理控制台。

示例REST API

根据实施例，在为BCS实例调用REST API之前，REST代理需要开启并运行。可以通过管理控制台来检查REST代理的状态。如果REST代理未启动并正在运行，那么需要从管理控制台起动它。

根据实施例，可以调用REST API以与部署在BCS实例中的对等体节点上的智能合约(链式码)进行交互。可以通过管理控制台完成部署处理。

根据实施例，提供了示例REST API，该示例REST API被提供用于说明的目的。本文使用的示例假定以下示例链式码被部署到BCS网络。

根据实施例，进一步地，示例管理控制台。如果REST代理没有开启和正在运行，那么可以从管理控制台起动它。

根据实施例，可以调用REST API以与在BCS实例中的对等体节点上部署的智能合约(链式码)进行交互。可以通过管理控制台完成部署处理。

根据实施例，提供了示例REST API，该示例REST API被提供用于说明的目的。本文使用的示例假定以下示例链式码被部署到BCS网络。

根据实施例，REST API提供以下功能：通过链式码查询；通过链式码调用交易；通过链式码异步调用交易；获取交易状态；以及获取BCS网关版本。客户端使用HTTPS访问BCS网关，并根据API利用消息格式以便执行这些函数。

根据实施例，通过链式码的查询功能调用链式码以执行查询动作，其中用于查询的自变量和链式码是通过REST API指定的。获取交易状态：该REST API查询通道以获取交易状态，其中通道和交易ID是通过REST API指定的。获取网关版本。该REST API返回网关版本信息。

根据实施例，通过链式码调用交易的功能：该REST API调用链式码以执行交易动作，用于调用的自变量和链式码是通过REST API指定的。该REST API以同步模式执行交易，这意味着在以下三种情况中的任何一种情况下发送回响应：该交易成功执行；交易完成失败；或者交易超时。

根据实施例，通过链式码异步调用交易的功能：该REST API调用链式码来执行交易动作，用于调用的自变量和链式码是通过REST API指定的。该REST API以异步模式执行交易，这意味着在提交交易后立即发送回响应/确认，而无需等待其完成或超时。随后可以提供结果。提供了BCS实例管理REST API，以支持与BCS控制台提供的功能相同的功能(如下所述)。

与身份云服务(IDCS)集成的架构证书颁发机构(架构CA)

根据实施例，架构-CA服务器为架构提供成员资格服务。它包括三个部分：针对用户的认证、针对访问区块链(一组对等体和排序)的授权、以及可以向应用客户端、对等体和排序递送证书的CA服务器。架构-CA使用证书来实现认证和授权。证书包括两种类型：用于认证的登记证书和用于授权的交易证书。IDCS也提供认证和授权。但其授权由OAuth实现。这意味着如果对等体想要访问排序，那么对等体应当从IDCS获取用户的访问令牌并使用这个令牌来访问排序。

根据实施例，架构CA使用数据库或LDAP来存储架构CA的注册用户的信息，例如用户的名称/密码、用户的证书和用户的从属关系。公共云(OPC)的终端用户将应用一个中心化IDCS实例来管理其员工以访问其所有应用的公共云(OPC)实例。区块链云服务BCS优选地与用于其它云服务的IDCS集成。因此，终端用户能够应用一个中心化IDCS实例来管理其员工以访问其所有应用的公共云(OPC)实例，包括BCS。

在实施例中，区块链云服务(BCS)使用Oracle身份云服务(IDCS)以中心化方式存储用户信息。BCS将架构CA用户的信息存储到IDCS中，从而允许Oracle BCS使用IDCS来管理跨多个公共云服务实例中心化的BCS用户信息。因此，在实施例中，BCS架构CA用户的信息、证书存储在Oracle IDCS中。架构证书授权框架是架构成员资格提供者(MSP)，它包括PKI私钥、签署的证书、CA证书链，并由架构CA客户端/服务器设置。

根据实施例，BCS充分利用OPC的用户管理。任何BCS用户必须首先是OPC用户(因此是IDCS身份)。当创建BCS实例时，创建若干类型的应用：BCS控制台、CA和REST代理。对于控制台，存在两个应用角色：控制台管理员和控制台用户。对于CA，存在四个应用角色：架构管理员、架构客户端、架构对等体、架构排序者。对于REST代理，存在两个应用角色：网关管理员和网关用户。

根据实施例，为了成为BCS用户，OPC用户需要被授予OPC用户管理控制台中的某些BCS应用角色。

当创建BCS实例时，创建者需要提供现有的OPC用户/密码，并且这个用户将被自动授予BCS控制台管理员和架构管理员角色，以使这个用户成为BCS管理员。

认证：对于BCS控制台/CA/REST代理，认证在云关完成。对于对等体/排序者，认证是基于签名的。对于BCS控制台，在认证之后，控制台(通过调用IDCS)获取当前用户的应用角色。如果用户未被授予控制台管理员或控制台用户角色，那么连接被拒绝。否则，控制台基于预定义的规则(例如，普通用户一般只能读取信息而管理员可以做任何事情)进行访问控制。

根据实施例，对于CA，在认证之后，CA获取当前用户的应用角色。如果用户未被授予任何架构角色，那么登记请求被拒绝。

根据实施例，对于REST代理，在认证之后，REST代理获取当前用户的应用角色。如果用户未被授予网关管理员或网关用户角色，那么请求被拒绝。否则，REST代理基于预定义的规则(例如，普通用户可以调用/查询，管理员可以改变配置、获取度量)进行访问控制。

根据实施例，架构-CA服务器为架构提供成员资格服务。它包括三个部分：针对用户的认证、针对访问区块链(一组对等体和排序)的授权，以及可以向应用客户端、对等体和排序递送证书的CA服务器。

根据实施例，架构-CA使用证书来实现认证和授权。证书包括两种类型：用于认证的登记证书和用于授权的交易证书。

根据实施例，IDCS也提供认证和授权。但其授权由OAuth实现。这意味着如果对等体想要访问排序，那么对等体应当从IDCS获取用户的访问令牌并使用这个令牌来访问排序。

图9A示出了根据实施例的用于单点登录的典型IDCS用例。

根据实施例，可以在初始步骤将web应用901添加到IDCS 902。然后，诸如web浏览器900之类的客户端可以请求来自web应用的认证(例如，用户名和密码)。因为web应用已经被添加到IDCS，所以web应用可以指示web浏览器向IDCS做出认证请求。在从web应用接收到响应之后，web浏览器然后可以请求来自IDCS的认证(例如，用户名和密码)。

IDCS然后可以认证该请求，并且在成功认证后，将令牌发送回web浏览器。然后，已经经过认证并接收到其令牌的web浏览器可以从web应用做出请求。web应用可以核实令牌，并且向web浏览器发出认证成功的信号。

在图9A中描绘的情况下，IDCS充当身份提供者(IdP)来为应用提供身份服务。所有方之间的所有通信都是基于HTTP的。这个用例是配置驱动的，但仅应用于基于HTTP的应用。

图9B示出了根据实施例的用于架构客户端认证的IDCS用例。

根据实施例，与已经注册和登记的架构用户(这个用户的私钥和证书已经存储在客户端侧的状态存储库中)相关联的架构客户端904可以请求新客户端()(new Client())，以及获取客户端(用户名)的用户上下文。架构SDK 905可以从状态存储库加载用户，并将用户对象返回给架构客户端。客户端在接收到用户对象后可以向架构SDK发送交易提议，该架构SDK可以使用相同的私钥对该提议进行签署。然后，经签署的提议可以转到对等体(或多个对等体)906，该对等体(或多个对等体)906将在成员资格服务907处核实签名。成员资格服务可以从IDCS 902获取用户的证书，并且可以使用来自IDCS的证书来核实用户的签名。然后，成员资格服务可以向对等体返回签名已核实的核实。

分布式分类账中基于DAG的交易处理

根据实施例，可以引入分布式分类账中基于DAG的交易处理系统和方法。该模型可以帮助提高吞吐量性能。借助附加的权重机制，可以基于各种业务需求来调整最终性能。这与使用线性结构的现有工作不同，并且可以实现更好的性能。

传统上，区块链通过线性记录结构记录交易历史来帮助为分布式分类账问题带来潜在的解决方案。但是，由于分布式系统的基本特性，当多方将多个交易发送到同一共享分类账时，经常发生交易冲突。存在缓解冲突的若干方法，但是当前的方法都无法提供足够的性能。

典型的公共区块链(诸如与加密货币相关的那些公共区块链)将问题抛给矿工，让他们决定保留哪些交易和拒绝哪些交易。实际上，这里将激励模型选择为这些矿工(例如，一些区块链允许向矿工支付以相对于其它交易提高某些交易的优先级)。在这种情况下，矿工和区块链共识的其它成员几乎总是偏好具有更高费用的那些交易。这可能导致区块链的性能下降。

其它企业区块链架构利用其中每个对等方仅基于来自排序服务的批中的时序排序提交交易的时序模型。在这种情况下，将存在由于时序排序和交易之间的冲突而导致许多交易被拒绝的情况。

根据实施例，本系统和方法通过引入DAG结构来提供新的交易处理模型。该模型有助于实现增强和改进的吞吐量性能。利用权重机制，可以基于各种业务需求来调整最终性能。这与使用线性结构的现有工作完全不同，并且可以实现更好的性能。

图10示出了根据实施例的用于在分布式分类账中提供基于DAG的交易处理系统和方法的系统。

根据实施例，分布式分类账中基于DAG的交易处理系统和方法的设计可以包括碰撞(collision)检测器1005、评级(ranking)生成器1010和交易选取器(picker)1015。

根据实施例，碰撞检测器可以检测多个交易之间的碰撞关系。例如，来自交易列表1001的多个交易。

根据实施例，一般而言，如果交易#1依赖于也将在交易#2中更改的某个密钥，那么#1和#2将被视为冲突。交易#1和#2之间可以画一条边。一批交易可能存在若干DAG。

根据实施例，每个交易可以用1条边标记为图中的底层，并且它在DAG中具有输出顶点。

根据实施例，可以扩展碰撞条件，比如两个交易改变相同的表，或者它们的创建者属于同一部门。

根据实施例，在碰撞检测之后，关系将被示为若干DAG。每个交易都是碰撞图1002中的顶点。

根据实施例，利用生成的图1002，系统和方法的评级生成器可以向每个顶点添加权重。如果所有交易被视为相同权重，那么可以将每个顶点的原始评级设置为相同的值，诸如1。

根据实施例，可以通过系统和方法自动地或者经由用户/管理员输入来设置与多个交易相关联的权重，或者交易本身可以携带其权重的指示。

根据实施例，在为每个交易设置原始评级/权重1003之后，系统和方法可以通过顶点来计算评级。

根据实施例，如果交易#1的原始值为x，并且它指向具有顶点的另一个交易#2，那么交易#1将为交易#2的评级/权重贡献评级-x。

根据实施例，连同该处理，DAG中的每个顶点将具有评级编号，该评级编号利用原始评级和其邻居的贡献评级来计算。

根据实施例，利用评级的DAG，系统和方法可以经由交易选取器基于评级来选取交易。

根据实施例，可以遵循以下处理，首先，离开那些底层顶点，并且遵循以下原则选取具有最高评级的顶点：如果交易#x被选取，那么其所有邻居(即，#x与之冲突的那些交易)将不被选择。

根据实施例，最后，可以选择交易的子集，该子集可以被安全地提交，并且可以证明这种方式为该批次实现了最高总和权重。所选择的交易可以作为结果1004输出。

图11示出了根据实施例的可以在本公开的实施例中使用的示例关系图。

根据实施例，例如，假设分类账系统接收包括8个排序交易的批次，命名为交易#1至#8(1101-1108)。在这个实施例中，可以将由碰撞检测器确定的每个交易的碰撞关系总结在一个图中。

在碰撞检测之后，碰撞关系被确定为：

●C(#1，#2，#3)＝#6

●C(#4，#5)＝#7

●C(#6，#7)＝#8

根据实施例，上述碰撞关系可以被读取为交易#6与交易#1、#2和#3碰撞。同样，交易#7与交易#4和#5碰撞，并且交易#8与交易#6和#7碰撞。

根据实施例，并继续该示例，每个交易的权重相等，即为1。基于该关系，评级生成器可以生成图11中所示的关系图，然后可以将其提供给交易选取器，在交易选取器中可以选择要提交的交易。

如图11中所示，交易#1、#2、#3、#4和#5的权重和交易评级均为1。然后，使用上述方法，从碰撞交易的权重中减去这些权重，以便确定每个交易的交易评级。因此，交易#6的交易评级为负2，因为交易#6的交易评级是通过从其自身权重中减去交易#1、#2和#3的权重来计算的(即，1-3＝-2)。执行类似的过程以确定交易#7的总交易权重。在那里，从交易#7的交易权重中减去交易#4和#5的交易权重，以获得交易评级为负1(即，1-2＝-1)。然后对交易#8重复该过程，从交易#8的交易权重中减去交易#6和#7的负权重，以得到总交易评级为4。

根据实施例，在计算碰撞图并且评级生成器根据其加权交易碰撞对每个交易进行评级之后，交易选取器可以确定将提交哪些交易。这里，交易#8(具有最高评级)和#1-#5将被提交，因为这些值为正数，并且因为这些交易彼此不冲突。交易#6和#7将不被选择提交，因为它们的交易评级较低，并且两个交易都与交易#8冲突。图中显示了这种选择，其中选取要提交的交易具有粗体轮廓，而未被选择进行提交的那些交易以虚线显示。

图12示出了根据实施例的可以在本公开的实施例中使用的示例关系图。

根据实施例，图12示出了比图11中所示的情况更复杂的第二种情况。

根据实施例，例如，假设区块链系统接收到包括8个排序交易的批次，命名为交易#1至#8(1201-1208)。在该实施例中，可以将由碰撞检测器确定的交易的碰撞关系总结在一个图中。

在碰撞检测之后，碰撞关系被确定为：

●C(#1，#2，#3)＝#6

●C(#4，#5)＝#7

●C(#3，#6，#7)＝#8

根据实施例，上述碰撞关系可以被读取为交易#6与交易#1、#2和#3碰撞。同样，交易#7与交易#4和#5碰撞，并且交易#8与交易#3、#6和#7碰撞。

根据实施例，并继续该示例，每个交易的权重相等，即为1。基于该关系，评级生成器可以生成如图12中所示的关系图。然后可以将该图提供给交易选取器，在交易选取器中可以选择要提交的交易。

如图12中所示，交易#1、#2、#3、#4和#5的权重和交易评级均为1。然后，使用上述方法，从碰撞交易的权重中减去这些权重，以便确定每个交易的交易评级。因此，交易#6的交易评级为负2，因为交易#6的交易评级是通过从其自身权重中减去交易#1、#2和#3的权重来计算的(即，1-3＝-2)。执行类似的过程以确定交易#7的总交易权重。在那里，从交易#7的交易权重中减去交易#4和#5的交易权重，以获得交易评级为负1(即，1-2＝-1)。然后对交易#8重复该过程，从交易#8的交易权重中减去交易#3、#6和#7的权重，以得到总交易评级为3。

在图12的关系图中，系统和方法可以提供交易的多个碰撞。例如，在图12中，交易#3具有两个碰撞(与#6和#8)。

根据实施例，在计算碰撞图并且评级生成器根据其加权交易碰撞对每个交易进行评级之后，交易选取器可以确定将提交哪些交易。这里，交易#8(具有最高评级)和交易#1、#2、#4和#5将被提交，因为这些值为正数，并且因为这些交易彼此不冲突。尽管交易#3的交易评级等于交易#1、#2、#4和#5的交易评级，但是交易#3没有被提交，因为它与交易#8冲突，其中交易#8具有比#3更高的评级。交易#6和#7没有被选择进行提交，因为它们的交易评级较低并且两个交易都与交易#8冲突。图中显示了这种选择，其中选取要提交的交易具有粗体轮廓，而未被选择进行提交的那些交易以虚线显示。

图13示出了根据实施例的可以在本公开的实施例中使用的示例关系图。

根据实施例，图13示出了比图12中所示的情况更复杂的第二种情况。在图13的关系图中，14个交易被分组为两个碰撞集群，其中交易#1至#8(1301-1308)位于集群A中，而交易#9-#14(1309-1314)位于集群B中。

根据实施例，例如，假设区块链系统接收到包括14个排序交易的批次，命名为交易#1至#4。并且假设由碰撞检测器确定的所有交易的碰撞关系可以总结在一个图中。

在碰撞检测之后，碰撞关系被确定为：

●C(#1，#2，#3)＝#6

●C(#4，#5)＝#7

●C(#3，#6，#7)＝#8

●C(#9，#10，#11，#13)＝#14

●C(#11，#12)＝#13

根据实施例，并继续该示例，假设每个交易的权重相等，即为1，例外是交易#10的原始权重为2并且交易#13的原始权重为5，它们的权重是自动或通过管理员设置的。

如图13中所示，交易#1-#8被包含在集群A中。交易#1、#2、#3、#4和#5的权重和交易评级均为1。然后，使用上述方法，从碰撞交易的权重中减去这些权重，以便确定每个交易的交易评级。因此，交易#6的交易评级为负2，因为交易#6的交易评级是通过从其自身权重中减去交易#1、#2和#3的权重来计算的(即，1-3＝-2)。执行类似的过程以确定交易#7的总交易权重。在那里，从交易#7的交易权重中减去交易#4和#5的交易权重，以获得交易评级为负1(即，1-2＝-1)。然后对交易#8重复该过程，从交易#8的交易权重中减去交易#3、#6和#7的权重，以得到总交易评级为3。

如图13中所示，交易#9-#14被包含在集群B中。交易#9、$#11、#12和#14的权重和交易评级均为1。交易#10的原始权重为2，并且交易#13的原始权重为5，从中减去2(交易#11和#12)以获得交易评级为3。交易#14的原始权重为1，从中减去7(交易#9、#10、#11和#13的原始权重和修改后的权重)，以生成交易评级为负6。

根据实施例，在计算碰撞图并且评级生成器根据其加权交易评级对每个交易进行评级之后，交易选取器可以确定将提交哪些交易。这里，交易#8和#13(具有最高评级)以及交易#1、#2、#4、#5、#9和#10将被提交，因为这些值为正数，并且因为这些交易彼此不冲突。尽管交易#3的交易评级等于交易#1、#2、#4和#5的交易评级，但是交易#3没有被提交，因为它与交易#8冲突，其中交易#8具有比#3更高的评级。交易#6和#7没有被选择进行提交，因为它们的交易评级较低并且两个交易都与交易#8冲突。交易#11和#12没有被提交，因为它们与交易#13冲突，并且交易#14由于与它与之共享边的那些交易相比具有较低交易评级，因此将不被提交。

图14是根据实施例的用于分布式分类账中基于有向非循环图(DAG)的交易处理的示例方法的流程图。

在步骤1401处，该方法可以在企业级的分布式分类账框架处提供分布式分类账架构，该分布式分类账架构处理多个交易。

在步骤1402处，该方法可以由碰撞检测器检测多个交易之间的多个碰撞。

在步骤1403处，该方法可以由评级生成器将多个初始权重参数中的初始权重参数添加到多个交易中的每个交易，并且其中评级生成器生成DAG，其中DAG的至少一个顶点包括评级编号。

在步骤1404处，该方法可以由交易选取器选择多个交易中的要提交的交易的集合，该集合基于所生成的DAG来确定。

虽然上面已经描述了各种实施例，但是应当理解的是，它们是作为示例而非限制来呈现的。选择和描述实施例是为了解释本教导的特征和原理及其实际应用。实施例图示了通过提供新的和/或改进的功能和/或提供性能优势(包括但不限于减少的资源利用、增加的容量、增加的吞吐量、提高的效率、减少的等待时间、增强的安全性和/或改进的易用性)来利用各种特征改进系统和方法的性能的系统和方法。

本文参考图示体系架构、功能、处理和/或操作的方法、装置(系统)和计算机程序产品的流程图和/或框图来描述一些实施例。流程图或框图中的每个方框表示元素、功能、处理、模块、片段或指令的一部分，其包括用于实现指定功能的一个或多个可执行指令。在一些替代实施例中，框图或流程图中提到的功能不按图中所示的顺序发生。例如，取决于所涉及的功能，连续示出的两个方框可以基本上同时执行，或者以相反的顺序执行。流程图和/或框图的每个方框以及流程图和/或框图中的方框的组合可以由执行指定功能的计算机程序指令和/或专用硬件和/或硬件和计算机程序指令的组合来实现。

在一些实施例中，特征在包括处理器、计算机可读介质和用于与其它计算机通信的网卡/接口的计算机中实现。在一些实施例中，特征在包括计算系统的网络计算环境中实现，该计算系统包括各种类型的计算机配置，包括个人计算机、手持设备、多处理器系统、基于微处理器或可编程的消费电子产品、网络PC、小型计算机、大型计算机、以及通过网络互连的链路。网络可以是局域网(LAN)、交换架构网络(例如InfiniBand)、广域网(WAN)和/或互联网。网络可以包括铜传输线缆、光传输光纤、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。

在一些实施例中，特征在包括后端部件(例如，数据服务器)、或包括中间件部件(例如，应用服务器)、或包括前端部件(例如，具有图形用户界面或web浏览器的客户端计算机，用户可以通过该客户端计算机与本文描述的主题的实现进行交互)、或者包括这种后端、中间件或前端部件的通过网络互连的任何组合的计算系统中实现。计算系统可以包括彼此具有客户端-服务器关系的客户端和服务器。在一些实施例中，特征在包括分布式计算环境的计算系统中实现，其中计算机的一个或多个集群通过网络连接。分布式计算环境可以使所有计算机位于单个位置，或者具有通过网络连接的不同远程地理位置处的计算机的集群。

在一些实施例中，基于使用web技术以自助服务、计量方式递送给用户的共享弹性资源，特征在云中实现作为云计算系统的一部分或作为云计算系统的服务。云的特点可以包括例如：按需自助服务；广泛的网络访问；资源汇集；快速弹性；以及测得的服务。云部署模型包括：公共、私有和混合。云服务模型包括软件即服务(SaaS)、平台即服务(PaaS)、数据库即服务(DBaaS)和基础设施即服务(IaaS)。云一般是指硬件、软件、网络和web技术的组合，其为用户递送共享的弹性资源。如本文所使用的，云可以包括公共云、私有云和/或混合云实施例，并且可以包括云SaaS、云DBaaS、云PaaS和/或云IaaS部署模型。

在一些实施例中，使用或借助于硬件、软件、固件或其组合来实现特征。在一些实施例中，使用被配置或编程为执行本教导方法的一个或多个功能的处理器来实现特征。在一些实施例中，处理器是单芯片或多芯片处理器、数字信号处理器(DSP)、片上系统(SOC)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、状态机、离散门或晶体管逻辑、分立硬件部件、或被设计为执行本文所述的功能的其任何组合。在一些实现中，特征由特定于给定功能的电路系统实现。在其它实现中，特征在计算机、计算系统、处理器和/或网络中实现，被配置为使用例如存储在计算机可读存储介质上的指令来执行特定功能。

在一些实施例中，特征结合在软件和/或固件中，用于控制处理和/或网络系统的硬件，并且用于使处理器和/或网络能够利用本教导的这些特征与其它系统进行交互。这种软件或固件可以包括但不限于应用代码、设备驱动程序、操作系统、虚拟机、管理程序、应用编程接口、编程语言和执行环境/容器。基于本公开的教导，熟练的程序人员可以容易地准备适当的软件编码。

在一些实施例中，本教导方法包括计算机程序产品，该计算机程序产品是机器可读或计算机可读介质，该介质具有包括存储在其上/其中或在其中/由其携带的软件和/或固件的指令，这些指令可以用于编程或以其它方式配置诸如计算机之类的系统以执行本教导方法的任何处理或功能。机器可读或计算机可读介质可以包括存储介质，该存储介质可以包括适用于存储指令和/或数据的任何类型的介质或设备，包括但不限于软盘、硬盘驱动器、固态驱动器、光盘、DVD、CD-ROM、微驱动器，以及磁光盘、ROM、RAM、EPROM、EEPROM、DRAM、VRAM、闪存设备、磁卡或光卡、分子存储器、纳米系统或其变体和组合。在特定实施例中，存储介质或计算机可读介质是非瞬态机器可读存储介质或非瞬态计算机可读存储介质。机器可读或计算机可读介质也可以或替代地包括诸如载体或传输信号之类的瞬态介质。

因此，从一个角度来看，已经描述了用于分布式分类账中基于DAG的交易处理系统和方法的系统和方法。根据实施例，可以引入分布式分类账中基于DAG的交易处理系统和方法。该模型可以帮助实现提高的吞吐量性能。借助附加的权重机制，可以基于各种业务需求来调整最终性能。这与使用线性结构的现有工作不同，并且可以实现更好的性能。

在以下编号的条款中列出了本教导的进一步示例：

条款1：一种用于分布式分类账中基于有向非循环图(DAG)的交易处理的系统，包括：企业级分布式分类账框架；以及分布式分类账架构，所述分布式分类账架构处理多个交易；碰撞检测器，其中所述碰撞检测器检测所述多个交易之间的多个碰撞；评级生成器，其中所述评级生成器将多个初始权重参数中的初始权重参数添加到所述多个交易中的每个交易，并且其中所述评级生成器生成DAG，其中DAG的至少一个顶点包括评级编号；以及交易选取器，其中交易选取器选择所述多个交易中的要提交的交易的集合，所述集合基于所生成的DAG来确定。

条款2：如条款1所述的系统，其中所述多个初始权重参数是经由输入提供的。

条款3：如条款1所述的系统，其中所述多个初始权重参数是自动推导出的。

条款4：如条款3所述的系统，其中所述多个初始权重参数的推导至少基于所述多个交易中的每个交易的相对重要性。

条款5：如任何前述条款所述的系统，其中所生成的DAG计算所述多个交易中的每个交易的评级，其中计算出的所述多个交易中的每个交易的评级是被分配给交易的原始权重参数或修改后的权重参数中的一个。

条款6：如条款5所述的系统，其中每个修改后的权重参数是基于主体交易的初始权重参数和与所述主体交易冲突的交易的至少一个评级来计算的。

条款7：如任何前述条款所述的系统，其中所述多个交易中的要提交的交易的集合中的每个交易不冲突。

条款8：一种用于分布式分类账中基于有向非循环图(DAG)的交易处理的方法，所述方法包括：在企业级分布式分类账框架处提供分布式分类账架构，所述分布式分类账架构处理多个交易；由碰撞检测器检测所述多个交易之间的多个碰撞；由评级生成器将多个初始权重参数中的初始权重参数添加到所述多个交易中的每个交易，并且其中所述评级生成器生成DAG，其中DAG的至少一个顶点包括评级编号；以及由交易选取器选择所述多个交易中的要提交的交易的集合，所述集合基于所生成的DAG来确定。

条款9：如条款8所述的方法，其中所述多个初始权重参数是经由输入提供的。

条款10：如条款8所述的方法，其中所述多个初始权重参数是自动推导出的。

条款11：如条款10所述的方法，其中所述多个初始权重参数的推导至少基于所述多个交易中的每个交易的相对重要性。

条款12：如条款8至11中任一项所述的方法，其中所生成的DAG计算所述多个交易中的每个交易的评级，其中计算出的所述多个交易中的每个交易的评级是被分配给交易的原始权重参数或修改后的权重参数中的一个。

条款13：如条款12所述的方法，其中每个修改后的权重参数是基于主体交易的初始权重参数和与所述主体交易冲突的交易的至少一个评级来计算的。

条款14：如条款8至13中任一项所述的方法，其中所述多个交易中的要提交的交易的集合中的每个交易不冲突。

条款15A：一种计算机可读介质，其上具有用于分布式分类账中基于有向非循环图(DAG)的交易处理的指令，所述指令在被读取和执行时，使得一个或多个计算机执行以下步骤：在企业级分布式分类账框架处提供分布式分类账架构，所述分布式分类账架构处理多个交易；由碰撞检测器检测所述多个交易之间的多个碰撞；由评级生成器将多个初始权重参数中的初始权重参数添加到所述多个交易中的每个交易，并且其中所述评级生成器生成DAG，其中DAG的至少一个顶点包括评级编号；以及由交易选取器选择所述多个交易中的要提交的交易的集合，所述集合基于所生成的DAG来确定。

条款16：如条款15所述的计算机可读介质，其中所述多个初始权重参数是经由输入提供的。

条款17：如条款15所述的计算机可读介质，其中所述多个初始权重参数是自动推导出的。

条款18：如条款17所述的计算机可读介质，其中所述多个初始权重参数的推导至少基于所述多个交易中的每个交易的相对重要性。

条款19：如条款15至18中任一项所述的计算机可读介质，其中所生成的DAG计算所述多个交易中的每个交易的评级，其中计算出的所述多个交易中的每个交易的评级是被分配给交易的原始权重参数或修改后的权重参数中的一个。

条款20：如条款19所述的计算机可读介质，其中每个修改后的权重参数是基于主体交易的初始权重参数和与所述主体交易冲突的交易的至少一个评级来计算的。

前面的描述并非旨在是详尽的或将范围限制于所公开的精确形式。此外，在已经使用特定系列的交易和步骤描述了实施例的情况下，本领域技术人员应当清楚的是，除非另有说明，否则该实施例不排除附加交易和步骤的执行。另外，虽然各种实施例描述了特征的特定组合，但是应当理解的是，在本教导和范围的范围内，特征的不同组合对于相关领域技术人员来说将是显而易见的。具体地，在不脱离教导和范围的情况下，在给定实施例、变体或附图中示出的特征(类似设备或类似方法)可以在另一个实施例、变体或附图中与另一个特征组合或替换另一个特征组合。而且，对于相关领域技术人员显而易见的是，在不脱离本公开的精神和范围的情况下，可以在其中进行形式、细节、实现和应用的各种添加、减少、删除、变化、用等同物的元件的替换，以及其它修改和改变。更广泛的精神和保护范围旨在由以下权利要求及其等同物限定。