Consensus Service for Blockchain Networks

Abstract

A computer-implemented method for establishing consensus within a blockchain network, a total ordering service for a blockchain network, and a computer program product. One embodiment may include providing a first total ordering service (TOS) gateway to an organization within the blockchain network; generating a symmetric key at the first TOS gateway; splitting the symmetric key to generate multiple key assignments; and distributing at least one of the multiple key assignments to a second TOS gateway within the blockchain network. In some embodiments, the TOS gateway may have read / write access to a shared message queue, which makes messages available to each other TOS gateway within the blockchain network. Some embodiments may further include recovering the symmetric key by requesting one of the key assignments from the second gateway within the blockchain network and reconstructing the symmetric key using one of the key assignments.

Description

[Technical Field]

[0001] The present disclosure relates to completing and committing transactions, and more particularly to enabling consensus within a decentralized distributed transaction processing system. [Background technology]

[0002] The development of the EDVAC system in 1948 is often cited as the beginning of the computer age. Since that time, computer systems have evolved into extremely complex devices. Modern computer systems typically include a combination of sophisticated hardware and software components, application programs, operating systems, processors, buses, memory, and input / output devices. As advances in semiconductor processing and computer architectures have enabled ever-increasing performance, ever-more advanced computer software has been developed to take advantage of this increased performance, resulting in today's computer systems being far more powerful than those of just a few years ago.

[0003] One area in which computing systems have been successfully applied is transaction processing. Historically, centralized databases store and maintain transaction data in dedicated database programs running on one physical system in one location. This location is often a central computer, such as a server computer or mainframe computer. Centralized databases are relatively easy to maintain and manage because of the single point of control, especially for security purposes. Summary of the Invention

[0004] A computer-implemented method for establishing consensus within a blockchain network according to an embodiment of the present disclosure may include providing a first total ordering service (TOS) gateway to an organization within the blockchain network; generating a symmetric key at the first TOS gateway; splitting the symmetric key to generate multiple key assignments; and distributing at least one of the multiple key assignments to a second TOS gateway within the blockchain network. In some embodiments, the TOS gateway may have read / write access to a shared message queue, which makes messages available to each other TOS gateway within the blockchain network. Some embodiments may further include recovering the symmetric key by requesting one of the key assignments from the second gateway within the blockchain network and reconstructing the symmetric key using one of the key assignments.

[0005] A computer program product for a confidential ordering service according to an embodiment of the present disclosure, comprising one or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media. The program instructions may include: program instructions for running a total ordering service gateway for each organization in a blockchain network, each total ordering service gateway having read / write access to a shared message queue that distributes messages to each organization; program instructions for identifying a group of organizations within the organization; and program instructions for creating a channel including the group of organizations, where the group of organizations collaborate autonomously. The program instructions may further include program instructions for generating a symmetric key known only to the group of organizations; program instructions for dividing the symmetric key into allocations associated with multiple organizations in the group of organizations; and program instructions for storing the allocations but not storing the symmetric key as a whole.

[0006] A total ordering service for a blockchain network according to an embodiment of the present disclosure may include a plurality of total ordering service (TOS) gateways, each associated with one of a plurality of member organizations in the blockchain network, and a shared message queue adapted to redistribute symmetric keys to the plurality of TOS gateways in the blockchain network. Each of the plurality of TOS gateways may include a processor operatively connected to a memory, and the memory may include program instructions, when executed on the processor, to generate a symmetric key at a first TOS gateway of the plurality of TOS gateways, divide the symmetric key into a plurality of key allocations, and distribute at least one of the plurality of key allocations to a second TOS gateway in the blockchain network.

[0007] The above summary is not intended to describe each example embodiment or every implementation of the present disclosure.

[0008] The drawings included in this application are incorporated into and form a part of this specification. The drawings, together with the description, illustrate embodiments of the present disclosure and serve to explain the principles of the disclosure. The drawings are merely examples of particular embodiments and do not limit the disclosure. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 illustrates a data processing system, consistent with some embodiments. [Figure 2] FIG. 1 illustrates a cloud computing environment, consistent with some embodiments. [Figure 3] FIG. 1 illustrates an abstract model layer, consistent with some embodiments. [Figure 4] FIG. 1 is a high-level diagram of a blockchain system, consistent with some embodiments. [Figure 5A] FIG. 1 illustrates an exemplary blockchain architecture configuration, consistent with some embodiments. [Figure 5B] FIG. 1 illustrates a blockchain transaction flow, consistent with some embodiments. [Figure 6A] FIG. 1 illustrates a flow diagram, consistent with some embodiments. [Figure 6B] FIG. 10 illustrates a further flow diagram, consistent with some embodiments. [Figure 6C] FIG. 1 illustrates an example system configured to perform one or more operations described herein, consistent with some embodiments. [Figure 6D] FIG. 1 illustrates another exemplary system configured to perform one or more operations described herein, consistent with some embodiments. [Figure 6E] FIG. 1 illustrates a further exemplary system configured to utilize smart contracts, consistent with some embodiments. [Figure 6F] FIG. 1 illustrates a system including a blockchain, consistent with some embodiments. [Figure 7A] FIG. 1 illustrates one method for creating a channel, consistent with some embodiments. [Figure 7B] FIG. 1 illustrates one method for creating a channel, consistent with some embodiments. [Figure 8] FIG. 1 illustrates one method of symmetric key recovery by a Total Ordering Service Gateway (TOS Gateway), consistent with some embodiments. [Figure 9] FIG. 9 is a flow chart illustrating one method 900 of expanding membership in a blockchain, consistent with some embodiments. [Figure 10A] FIG. 10 illustrates one method for rotating keys, consistent with some embodiments. [Figure 10B] FIG. 10 illustrates one method for rotating keys, consistent with some embodiments. [Figure 11A] FIG. 10 illustrates a process for a new block being added to a distributed ledger, according to an example embodiment. [Figure 11B] FIG. 10 illustrates the contents of a new data block according to an example embodiment. [Figure 11C] FIG. 1 illustrates a blockchain for digital content, according to an example embodiment. [Figure 11D] FIG. 1 illustrates a block diagram that may represent the structure of a block in a blockchain, according to an example embodiment. [Figure 12A] FIG. 1 illustrates an exemplary blockchain for storing machine learning (artificial intelligence) data, according to an example embodiment. [Figure 12B] FIG. 1 illustrates an exemplary quantum-secure blockchain, according to an example embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0010] While the invention is susceptible to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and may be described in detail. It is to be understood, however, that it is not intended to limit the invention to the particular embodiments described. On the contrary, it is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

[0011] Aspects of the present disclosure relate to completing and committing transactions, and more particularly to enabling consensus within a decentralized distributed transaction processing system. While the present disclosure is not necessarily limited to such application, various aspects of the present disclosure may be understood through the description of various embodiments using this context.

[0012] A decentralized database generally refers to a distributed storage system in which multiple nodes cooperate to store data and / or provide access to data. A blockchain is an example of a decentralized database and generally comprises an append-only, immutable data structure resembling a distributed ledger that can maintain records among mutually untrusted / untrusted parties. These mutually untrusted / untrusted parties are referred to herein as peers or peer nodes.

[0013] In some blockchain embodiments, each peer maintains a copy of the distributed database record, and no single peer can modify the distributed database record without reaching consensus among the peers. In some blockchain embodiments, peers may run a consensus protocol to verify the validity of blockchain transactions, group those blockchain transactions into blocks, and build a hash chain on the blocks. This process may form a distributed ledger by ordering stored transactions for consistency.

[0014] In public or permissionless blockchain embodiments, anyone can participate without specific permission. In contrast, permissioned blockchain embodiments provide a system that can protect the actions of a group of permissioned entities that share a common goal but do not fully trust each other, such as businesses exchanging funds, goods, information, etc.

[0015] Some blockchain embodiments may operate arbitrary programmable logic tailored to a decentralized storage method, such as a "smart contract" or "chaincode." In some of these embodiments, there may be a specialized chaincode for managing functions and parameters, called the system chaincode. Smart contracts are trusted, distributed applications that leverage the tamper-proof properties of the blockchain and the underlying agreements between nodes (often called signatures or signature policies).

[0016] Blockchain transactions, in some embodiments, may be "signed" before being committed to the blockchain, while transactions that are not "signed" may be ignored. A signature policy consistent with some embodiments allows a chaincode to specify the signers of a transaction in the form of a set of peer nodes required for signing. When a client sends a transaction to a peer specified in the signature policy, a transaction may be executed to validate the transaction. After validation, the transaction may move to an ordering phase, where a consensus protocol is used to generate an ordered sequence of signed transactions grouped into blocks.

[0017] In some blockchain embodiments, nodes may function as communicating entities in the blockchain system. A "node," in these embodiments, may perform a logical function, in the sense that multiple nodes of different types may run on the same physical server. Nodes may be grouped within a trust domain and associated with logical entities that control them in various ways. Nodes may include various types, such as client or submit-client nodes that submit transaction calls to signers (e.g., peers) and ordering nodes that broadcast transaction proposals to an ordering service. Yet another type of node is a peer node, which can receive client-submitted transactions, commit transactions, and maintain a ledger state and copy of blockchain transactions. Peer nodes may have the role of signers in some embodiments, but this is not a requirement.

[0018] An ordering service node (or "ordering node"), in some embodiments, may perform communication services for all nodes, such as broadcasting to each of the peer nodes in the system when committing a transaction and changing the blockchain world state, and may enforce delivery guarantees. In some embodiments, this world state may include the initial blockchain transaction, which typically includes control and configuration information.

[0019] However, some users of blockchain technology may be reluctant to host ordering nodes. This may be because exposing endpoints to the public internet carries inherent security risks, and many users lack the technical expertise, focus, and resources required to address those risks. Furthermore, consensus protocols based on non-alternating leaders can lead to uneven network bandwidth distribution. This may further result in some users spending computation, disk I / O, and network bandwidth on transactions that do not involve them. Still other users may be concerned about compliance with regulations, service level agreements, etc., especially if a particular blockchain implementation does not include a bounty for running ordering nodes.

[0020] Conversely, forming a blockchain network in which the consensus service is hosted by a third party (e.g., someone who is not involved in a large percentage of the transactions recorded on the blockchain) can present challenges. For example, if the ordering service is run by a third party, that third party may have access to the contents of the blockchain because the ordering service essentially creates the blocks itself and because newly joining nodes need to parse the blocks to keep up with the blockchain state. However, this can have unwanted side effects, such as: (i) the third party may be able to see all transactions in all channels in the clear (e.g., unencrypted) and therefore may have access to private and / or sensitive information; and (ii) if participants in the blockchain network want to migrate to a new ordering service provider, they may need cooperation from the third-party ordering service, which is not a trivial task and poses the risk of permanent vendor lock-in.

[0021] Thus, some embodiments of the present disclosure may enable the creation of blockchain networks for syndicates of organizations that are unable to host ordering service nodes. These blockchain networks may, in some embodiments, include a confidential total ordering service (TSO) that can receive and retransmit encrypted transaction payloads from multiple total ordering service gateways (TSO gateways).

[0022] Data Processing System FIG. 1 illustrates an embodiment of a data processing system (DPS) 100a consistent with some embodiments. In this embodiment, DPS 100a may be implemented as a personal computer, a server computer, a laptop or notebook computer, a portable computer such as a personal digital assistant (PDA), a tablet computer, or a smartphone, a processor embedded in a larger device such as an automobile, an aircraft, a videoconferencing system, an appliance, a smart device, or any other suitable type of electronic device. Furthermore, components other than or in addition to those illustrated in FIG. 1 may be present, and the number, type, and configuration of such components may vary. Furthermore, FIG. 1 illustrates only representative major components of DPS 100a, and individual components may have greater complexity than depicted in FIG. 1.

[0023] The data processing system 100a of FIG. 1 includes multiple central processing units 110a-110d (collectively referred to herein as processors 110 or CPUs 110) connected by a system bus 122 to memory 112, a mass storage interface 114, a terminal / display interface 116, a network interface 118, and an input / output (I / O) interface 120. In this embodiment, the mass storage interface 114 connects the system bus 122 to one or more mass storage devices, such as a direct access storage device 140, a universal serial bus (USB) storage device 141, or a readable / writable optical disk drive 142. The network interface 118 enables the DPS 100a to communicate with other DPSs 100b via the communications medium 106. The memory 112 also includes an operating system 124, multiple application programs 126, and program data 128.

[0024] The embodiment of data processing system 100a in FIG. 3 is a general-purpose computing device. Accordingly, processor 110 may be any device capable of executing program instructions stored in memory 112, and processor 110 itself may be constructed from one or more microprocessors and / or integrated circuits. In this embodiment, DPS 100a includes multiple processors and / or processing cores, as is typical in larger, more powerful computer systems; however, in other embodiments, computing system 100a may include a single processor system designed to emulate a multiprocessor system, or a single processor or both. Furthermore, processor 110 may be implemented using multiple heterogeneous data processing systems 100a, in which a main processor resides on a single chip along with secondary processors. As another example, processor 110 may be a symmetric multiprocessor system including multiple processors of the same type.

[0025] When data processing system 100a boots, the associated processor 110 initially executes program instructions that make up operating system 124, which manages the physical and logical resources of DPS 100a. These resources include memory 112, mass storage interface 114, terminal / display interface 116, network interface 118, and system bus 122. As with processor 110, some DPS 100a embodiments may utilize multiple system interfaces 114, 116, 118, 120, and bus 122, each of which may include its own separate, fully programmed microprocessor.

[0026] Instructions for the operating system, applications, and / or programs (collectively referred to as "program code," "computer-usable program code," or "computer-readable program code") may initially reside in mass storage devices 140, 141, and 142, which communicate with processor 110 via system bus 122. The program code in various embodiments may be embodied on different physical or tangible computer-readable media, such as system memory 112 or mass storage devices 140, 141, and 142. In the example of FIG. 3, the instructions are stored in a functional form in persistent storage on direct-access storage device 140. These instructions are then loaded into memory 112 for execution by processor 110. However, the program code may also be located in a functional form on selectively removable computer-readable medium 142 and loaded or transferred to DPS 100a for execution by processor 110.

[0027] The system bus 122 may be any device that facilitates communication between the processor 110, the memory 112, and the interfaces 114, 116, 118, 120. Additionally, although the system bus 122 in this embodiment is a relatively simple single bus structure that provides a direct communication path within the system bus 122, other bus structures are consistent with this disclosure, including, but not limited to, point-to-point links in a hierarchical, star, or web configuration, multiple hierarchical buses, redundant parallel paths, etc.

[0028] Memory 112 and mass storage devices 140, 141, and 142 work together to store operating system 124, application programs 126, and program data 128. In this embodiment, memory 112 is a random-access semiconductor device capable of storing data and programs. While FIG. 3 conceptually illustrates this device as a single monolithic entity, in some embodiments, memory 112 may be a more complex configuration, such as a hierarchy of caches and other memory devices. For example, memory 112 may exist in multiple levels of caches, and these caches may be further divided by function, such that some caches hold instructions while other caches hold non-instruction data used by one or more processors. Memory 112 may be further distributed and associated with different processors 110 or sets of processors 110, as known in any of a variety of so-called non-uniform memory access (NUMA) computer architectures. Additionally, some embodiments may utilize a virtual addressing mechanism that allows DPS 100a to act as if it has access to a single large storage entity instead of accessing multiple smaller storage entities, such as memory 112 and mass storage devices 140, 141, 142.

[0029] Although operating system 124, application programs 126, and program data 128 are shown as being contained within memory 112, in some embodiments, some or all of these may be physically located on different computer systems and may be accessed remotely, for example, via communications medium 106. Thus, although operating system 124, application programs 126, and program data 128 are shown as being contained within memory 112, these elements are not necessarily all contained entirely on the same physical device at the same time, but may reside in the virtual memory of another DPS 100b.

[0030] System interfaces 114, 116, 118, 120 support communication with various storage and I / O devices. Mass storage interface 114 supports connection of one or more mass storage devices 140, 141, 142, which are typically rotating magnetic disk drive storage devices, solid-state storage devices (SSDs) that use integrated circuit assemblies as memory (typically using flash memory) to persistently store data, or a combination of the two. However, mass storage devices 140, 141, 142 may also comprise other devices, including arrays of disk drives configured to appear to the host as a single large storage device (commonly referred to as RAID arrays), or hard disk drives, tapes (e.g., miniDV), writable compact disks (e.g., CD-R and CD-RW), digital versatile disks (e.g., DVD, DVD-R, DVD+R, DVD+RW, DVD-RAM), holographic storage systems, blue laser disks, and / or archival storage media such as IBM® Millipede devices.

[0031] Terminal / display interface 116 is used to connect one or more display units, such as monitor 180, directly to data processing system 100a. These display units 180 may be non-intelligent (i.e., non-data processing) terminals, such as LED monitors, or may themselves be fully programmable workstations used to allow IT administrators and customers to communicate with DPS 100a. Note, however, that while display interface 116 is provided to support communication with one or more display units 180, computer system 100a does not necessarily require a display unit 180, as all necessary customer interaction and other processes may occur via network interface 118.

[0032] The communication medium 106 may be any suitable network or combination of networks and may support any suitable protocol for communicating data and / or code between the multiple DPSs 100 a, 100 b. Thus, whether the network connection is made using current analog and / or digital technologies, or through some future network mechanism, the network interface 118 may be any device that facilitates such communication. Suitable communication media 106 include, but are not limited to, networks implemented using one or more of the "InfiniBand" or IEEE (Institute of Electrical and Electronics Engineers) 802.3x "Ethernet®" specifications, cellular transmission networks, wireless networks implemented using one of the IEEE 802.11x, IEEE 802.16, General Packet Radio Service (GPRS), Family Radio Service (FRS), or Bluetooth® specifications, Ultra-Wide Band (UWB) technology as described in FCC 02-48, etc. Those skilled in the art will appreciate that many different network and transport protocols may be used to implement communication medium 106. The Transmission Control Protocol / Internet Protocol (TCP / IP) suite includes suitable network and transport protocols.

[0033] Cloud Computing 2 illustrates a cloud environment including one or more DPSs 100a, consistent with some embodiments. While this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the teachings presented herein is not limited to cloud computing environments. Rather, embodiments of the present invention may be implemented in conjunction with any other type of computing environment now known or later developed.

[0034] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computational resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) and for rapidly provisioning and releasing these resources with minimal administrative effort or interaction with a service provider. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0035] The features are as follows: On-demand self-service: Cloud users can automatically provision server time, network storage, and other computing power as needed, without any unilateral or human interaction with the service provider. Wide network access: Cloud capabilities are available over the network and can be accessed using standard mechanisms, facilitating usage by heterogeneous thin-client or thick-client platforms (e.g., mobile phones, laptops, and PDAs). Resource Pool: The provider's computing resources are pooled and offered to multiple consumers using a multi-tenant model. Various physical and virtual resources are dynamically allocated and reallocated according to demand. There is a sense of location independence; consumers typically have no control or knowledge regarding the exact location of the resources offered, although at a higher level of abstraction they may be able to specify a location (e.g., country, state, or data center). Rapid Elasticity: Cloud capacity is quickly and elastically provisioned, sometimes automatically, and can be quickly scaled out and quickly released to quickly scale in. The capacity available for provisioning often appears unlimited to the consumer, and any amount can be purchased at any time. Metered Services: Cloud systems leverage metering capabilities to automatically control and optimize resource usage at an abstraction level appropriate to the type of service (e.g., storage, processing, bandwidth, and active customer accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services utilized.

[0036] The service model is as follows: SaaS (Software as a Service): The consumer is provided with the ability to use the provider's applications running on a cloud infrastructure. Those applications can be accessed from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or individual application features, except for the possibility of limited customer-specific application configuration settings. PaaS (Platform as a Service): The ability offered to a consumer is to deploy applications they create or acquire, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of the application hosting environment. Infrastructure as a Service (IaaS): The capability provided to a consumer is the provisioning of processing, storage, network, and other basic computing resources, upon which the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating systems, storage, and deployed applications, and in some cases has limited control over selected network components (e.g., host firewalls).

[0037] The deployment model is as follows: Private Cloud: This cloud infrastructure is operated solely for an organization and can be managed by that organization or a third party, and can reside on-premise or off-premise. Community Cloud: This cloud infrastructure is shared by multiple organizations to support a specific community with shared interests (e.g., mission, security requirements, policy, and compliance considerations). It can be managed by these organizations or a third party and can reside on-premises or off-premises. Public Cloud: This cloud infrastructure is available for use by the general public or large industry organizations and is owned by an organization that sells cloud services. Hybrid cloud: This cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain distinct and are joined together by standardized or proprietary technologies that allow for the portability of data and applications (e.g., cloud bursting to balance load between clouds).

[0038] A cloud computing environment is a service-oriented environment that emphasizes statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0039] Referring now to FIG. 2, an exemplary cloud computing environment SO is illustrated. As illustrated, the cloud computing environment SO includes one or more cloud computing nodes 10 with which local computing devices used by cloud consumers (e.g., a personal digital assistant (PDA) or mobile phone S4A, a desktop computer S4B, a laptop computer S4C, and / or an automobile computer system S4N) can communicate. The nodes 10 may communicate with each other. The nodes 10 may be physically or virtually grouped in one or more networks (not shown), such as a private cloud, community cloud, public cloud, or hybrid cloud, or combinations thereof, as previously described herein. This enables the cloud computing environment 50 to provide an infrastructure, platform, and / or SaaS that does not require cloud consumers to maintain resources on their local computing devices. The types of computing devices S4A-N shown in the figures are intended to be illustrative only, and it is understood that computing node 10 and cloud computing environment 50 can communicate with any type of computer-controlled device via any type of network and / or network-addressable connection (e.g., a connection using a web browser).

[0040] Referring now to Figure 3, a set of functional abstraction layers provided by cloud computing environment 50 (Figure 2) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 2 are intended to be illustrative only, and that embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0041] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, RISC (Reduced Instruction Set Computer) architecture-based server 62, server 63, blade server 64, storage device 65, and network and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0042] The virtualization layer 70 comprises an abstraction layer capable of providing virtual entities such as virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0043] By way of example, the management layer 80 may provide the following functions: Resource provisioning 81 dynamically procures computing and other resources used to execute tasks within the cloud computing environment. Metering and pricing 82 tracks costs as resources are utilized within the cloud computing environment and sends bills or invoices for the utilization of those resources. By way of example, those resources may include application software licenses. Security verifies the identity of cloud users and tasks and protects data and other resources. Customer portal 83 provides users and system administrators with access to the cloud computing environment. Service level management 84 allocates and manages cloud computing resources to meet required service levels. Service level agreement (SLA) planning and execution 85 proactively prepares and procures cloud computing resources in accordance with SLAs in anticipation of future demand.

[0044] The workload layer 90 illustrates examples of functionality available in a cloud computing environment. Examples of workloads and functionality that may be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instruction delivery 93, data analytics processing 94, transaction processing 95, and ordering services 96.

[0045] Blockchain System Figure 4 is a high-level diagram of a blockchain system 400, consistent with some embodiments. In the embodiment of Figure 4, each member organization (for example purposes A, B, and C) of a blockchain-using syndicate may run a total ordering service gateway (TOS gateway) GA, Gii, Ge, etc., which may be deployed as a cluster or cloud service within the syndicate's member organizations A, B, C. The TOS gateways GA, Gii, Ge, etc. may each have read / write access to the total ordering service TSO, which may be maintained by a third-party service provider.

[0046] The total ordering service TOS, in some embodiments, may maintain a shared message queue 450, which may be used to publish messages to all participants in a blockchain syndicate. For channels spanning a subset of organizations A, B, etc., TOS gateways GA, Gii, etc. may autonomously collaborate to create a symmetric key K known only to the subset of organizations A, B, etc., then split the shared key (i.e., symbolically (KA, KB, etc.) + -Split(K)), distribute portions of the symmetric key and key assignments to other TOS gateways, and then retain only the key assignments KA, KB, etc. (and not the symmetric key K itself) in non-volatile memory. In contrast, the shared symmetric key K may, in some embodiments and implementations, be maintained only in volatile memory (e.g., RAM).

[0047] TOS Gateways GA, Gii, and Ge may then receive transactions from internal clients CA, CB, and CC within syndicate member organizations A, B, and C, encrypt those transactions using shared symmetric key K, establish a total order for the encrypted transactions, decrypt the totally ordered transactions to form blocks, autonomously sign the blocks using their respective long-term private blockchain keys, and broadcast the blocks within organizations A, B, and C. In some embodiments, TOS Gateways GA, Gii, and Ge may recognize each other's public certificates and use those public certificates for signature verification (in some embodiments, all protocol messages may be signed). Furthermore, as described in more detail with reference to FIGS. 7-10 , in some embodiments and / or implementations, TOS Gateways GA, Gii, and Ge may autonomously rotate these keys in cases such as membership reconfigurations.

[0048] The total ordering service TOS in the embodiment of FIG. 4 does not need, and typically does not have, access to unencrypted transaction information generated by internal clients CA, CB, and Cc. That is, some embodiments of the present disclosure may protect the confidentiality of the syndicate and syndicate organizations A, B, and C because the total ordering service TOS cannot learn any information about the data it processes, even while being run by a third party. In this way, the organization providing the total ordering service TOS need not be a trusted syndicate member but instead may be an unrelated third party, such as a cloud computing service provider. Thus, some embodiments of the present disclosure may include a blockchain that includes a delegated total ordering service that (i) allows the total ordering service to be run by a third party and (ii) does not disclose any transaction information, confidential or otherwise, to that third party.

[0049] A third party running a total ordering service TOS may, in some embodiments, be used as a persistent total order messaging service. Advantageously, this allows for restricted TOS gateways GA, Gs, Ge that only provide the ability to send messages and receive messages in the same order, without dropping those messages.

[0050] Another feature and advantage of some embodiments is that the operation of the blockchain may be fully autonomous, requiring relatively low general and administrative costs, which may further enable a relatively smooth blockchain experience for syndicate members A, B, C, etc.

[0051] The total ordering service TOS, in some embodiments, may further achieve fairness in resource allocation among members of a blockchain syndicate, since processing typically involves uploading transactions to and downloading transactions from a shared message queue 450. However, since downloading is simply an aggregation of uploads, internal clients CA, Cs, CC from each organization A, B, C can simply pay for uploading transactions to the total ordering service TOS, and this payment implicitly accounts for downloads by all organizations A, B, C.

[0052] Additionally, some embodiments may include one or more of the following security features: (i) autonomous operation, where the human element is removed from the equation; (ii) resistance to collusion between the Total Ordering Service TOS and a rogue administrator with access to the local TOS Gateway's file system; (iii) a key establishment protocol that can be modified to use a quantum-resistant scheme in addition to the standard key establishment protocol, thus future-proofing it in the presence of quantum computers; and (iv) different keys for different channels, and therefore not requiring complete trust in all other parties to properly protect those keys.

[0053] Distributed Ledger In some embodiments, a distributed ledger may be an ordered, tamper-proof record of all state transitions of a blockchain. State transitions may result from chaincode invocations (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, signer nodes, peer nodes, etc.). Transactions may then result in a set of asset key-value pairs (such as creation, update, or deletion) being committed to the distributed ledger as one or more operands. A distributed ledger may include a blockchain (also called a chain) used to store immutable, ordered records in blocks. A distributed ledger may also include a state database that maintains the current state of the blockchain. Some embodiments use one distributed ledger per channel, although other embodiments are possible. In these embodiments, each peer node maintains a copy of the distributed ledger for each channel in which they are a member.

[0054] In some embodiments, the chain may include a transaction log, which may be structured as hash-linked blocks, with each block containing a sequence of N transactions, where N is greater than or equal to 1. The block header may contain a hash of the block's transactions and a hash of the previous block's header. In this way, all transactions in the ledger may be ordered and cryptographically linked to each other. Therefore, in these embodiments, it is not reasonably possible to tamper with the ledger data without breaking the hash links. The hash of the most recently added block in the blockchain represents all transactions on the chain that occurred before it, allowing all peer nodes to be assured that they are in a consistent and reliable state. The chain may be stored in the file systems of peer nodes (i.e., locally, on attached storage, in the cloud, etc.), which efficiently supports the append-only nature of blockchain workloads.

[0055] The immutable ledger's current state, in some embodiments, may represent the most recent values ​​of all keys contained in the chain's transaction log. The current state is sometimes referred to as the world state, as it represents the most recent key values ​​known to the channel. Chaincode invocations execute transactions against data in the ledger's current state. To make those chaincode interactions efficient, the most recent key values ​​may be stored in a state database. The state database, in some embodiments, may simply be an indexed view into the chain's transaction log and therefore may be regenerated from the chain at any time. The state database may be automatically recovered (or generated if necessary) upon peer node startup, before any transactions are received.

[0056] Blockchain Architecture FIG. 5A illustrates a blockchain architecture configuration 500 consistent with some embodiments. In these embodiments, the blockchain architecture 500 may include a particular blockchain element (e.g., a group of blockchain nodes 502). The group of blockchain nodes 502 may then include one or more member nodes 504-510 (four nodes are shown merely by way of example). These member nodes 504-510 may participate in multiple activities, such as the addition and validation process (consensus) of blockchain transactions. One or more of the member nodes 504-510 may sign transactions based on a signature policy and provide an ordering service to all blockchain nodes in the architecture 500. The member nodes 504-510 may initiate blockchain validations and attempt to write to the blockchain's immutable ledger stored in the blockchain layer 516, a copy of which may also be stored in the underlying physical infrastructure 514.

[0057] In some embodiments, the blockchain architecture 500 may include one or more applications 524 linked to an application programming interface (API) 522 to access and execute stored program / application code 520 (e.g., chaincode, smart contracts, etc.). The stored program / application code 520 can then be created according to customized configurations required by participants, maintain its own state, control participants' assets, and receive external information. The stored program / application code 520 can be deployed as a transaction and installed on all blockchain nodes 504-510 by adding it to the distributed ledger.

[0058] The blockchain base or platform 512 may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and underlying physical computer infrastructure that may be used to receive and store new transactions and provide access to auditors seeking access to data entries. The blockchain layer 516 may expose interfaces that process program code and provide access to the virtual execution environments necessary to enlist the physical infrastructure 514. The cryptographic trust services 518 may be used to verify transactions, such as asset exchange transactions, and keep information private.

[0059] The blockchain architecture of FIG. 5A may process and execute program / application code 520 through one or more interfaces and services exposed by the blockchain platform 512. The program / application code 520 may control assets on the blockchain. For example, the code 520 may store and transfer data and be executed by the member nodes 504-510 in the form of associated chaincode, including smart contracts and conditions, or other code elements subject to execution. As a non-limiting example, smart contracts may be created to implement reminders, updates, or changes, other notifications subject to updates, or combinations thereof. The smart contract itself may be used to identify permission and access requirements and rules associated with use of the ledger. For example, document attribute information 526 may be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 516. The results 528 may include multiple linked shared documents. The physical infrastructure 514 may be utilized to retrieve any of the data or information described herein.

[0060] In some embodiments, smart contracts may be created using high-level application and programming languages ​​and then written into blocks in a blockchain. Smart contracts may include executable code that is registered, stored, and / or replicated to a blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code that may be executed in response to a condition associated with the smart contract being satisfied. Execution of a smart contract may trigger trusted changes to the state of a digital blockchain ledger. Changes to the blockchain ledger caused by the execution of a smart contract may, in some embodiments, be automatically replicated across a distributed network of blockchain peers via one or more consensus protocols.

[0061] A smart contract may write data to the blockchain in the form of key-value pairs. In some embodiments, smart contract code can also read values ​​stored on the blockchain and use them in the operation of the application. In these embodiments, smart contract code can write the output of various logical operations to the blockchain. In some embodiments, smart contract code may be used to create temporary data structures within a virtual machine or other computing platform. In these embodiments, data written to the blockchain may be public or may be kept private and encrypted. The temporary data used / generated by the smart contract may be kept in memory by the provided execution environment and then deleted after the data needed for the blockchain has been identified.

[0062] In some embodiments, the chaincode may include a code interpretation of the smart contract along with additional functionality. In some embodiments, the chaincode may be implemented as program code deployed on a computing network and executed together and validated by chain validators during the consensus process. The chaincode may receive a hash and retrieve a hash from the blockchain associated with a data template created by use of a previously stored feature extractor. If the hash of the hashed identifier matches the hash created from the stored identifier template data, the chaincode may send an authorization key to the requested service. The chaincode may write data associated with cryptographic details to the blockchain.

[0063] FIG. 5B illustrates an example blockchain transaction flow 550 between nodes of a blockchain, according to some embodiments. The transaction flow in these embodiments may include a transaction proposal 591 sent by an application client node 560 to a signing peer node 581. The signing peer 581 may verify the client's signature and execute a chaincode function to initiate the transaction. The output may include the chaincode result, a set of key / value versions read into the chaincode (the read set), and a set of key / values ​​written into the chaincode (the write set). A proposal response 592 may then be sent back to the client 560, along with a signature if approved.

[0064] In response, the client 560 may package the signatures into a transaction payload 593 and broadcast it to the ordering service node 584. The ordering service node 584 may then distribute the ordered transaction as a block on a channel to all peers 581-583. Before committing it to the blockchain, each peer 581-583 may verify the validity of the transaction. For example, in some embodiments, a peer may check a signature policy to ensure that the correct allocation of the designated peer has signed the result and authenticated the signature on the transaction payload 593.

[0065] Continuing with reference to FIG. 5B , in some embodiments, a client node 560 may initiate a transaction 591 by constructing and sending a request to a peer node 581, which may act as a signer. The client 560 may include an application utilizing a supported software development kit (SDK), which may utilize available APIs to generate a transaction proposal. Furthermore, the transaction proposal may be a request to invoke a chaincode function so that data can be read from and / or written to the distributed ledger (i.e., writing a new key-value pair for an asset). The SDK may act as a shim to package the transaction proposal into a suitably designed format (e.g., protocol buffers via remote procedure call (RPC)), receive the client's cryptographic credentials, and generate a unique signature for the transaction proposal.

[0066] In response, the signing peer node 581 may verify that (a) the transaction proposal is properly formed, (b) the transaction has not already been submitted previously (replay attack protection), (c) the signature is valid, and (d) the submitter (in this example embodiment, client 560) is properly authorized to perform the proposed operation for that channel. The signing peer node 581 may receive the transaction proposal input as an argument to a chaincode function that is invoked. The chaincode may then be executed against the current state database to generate a transaction result that includes a response value, a read set, and a write set. In some embodiments, no updates are made to the ledger at this point. Instead, the set of values, along with the signing peer node's 581 signature, may be returned as a proposal response 592 to the client's 560 SDK, which parses the payload for use by the application.

[0067] In response, the application at the client 560 may inspect / verify the signature of the signing peer and compare the proposal response to determine whether the proposal response is the same. If the chaincode simply queries the ledger, the application may inspect the query response and typically do not submit the transaction to the ordering service 584. If the client application is attempting to submit a transaction to the ordering service 584 to update the ledger, the application may determine whether the specified signature policy is satisfied (i.e., whether all required peer nodes for the transaction have signed the transaction) before submitting. Here, the client may include only one of multiple parties in the transaction. In this case, each client may include its own signing node, and each signing node must sign the transaction. The architecture ensures that the signature policy is still enforced by peers and maintained in the commit validation phase, even if the application chooses not to inspect the response or otherwise forwards an unsigned transaction.

[0068] After successful verification, at operation 594, the client 560 may assemble the signatures into a transaction and broadcast the transaction proposal and transaction response in a transaction message to the ordering service 584. The transaction may include a read / write set, the signing peer's signature, and a channel ID. The ordering service 584 does not need to inspect the entire contents of the transaction to perform its operation; instead, the ordering service 584 may simply receive transactions from all channels in the network, order them chronologically by channel, and create a block of transactions for each channel.

[0069] A block of transactions may be distributed from the ordering service 584 to all peer nodes 581-583 on the channel. The transactions in the block may be validated to ensure that any signature policies are met and to ensure that there have been no changes to the ledger state with respect to the variables in the read set since the read set was generated by the transaction's execution. The transactions in the block may be tagged as valid or invalid. Further, in operation 595, each peer node 581-583 may add the block to the channel's chain, and for each valid transaction, the write set is committed to the current state database. Events may be published to notify client applications that a transaction (invocation) has been immutably added to the chain and whether the transaction has been validated or invalidated.

[0070] Permissioned Blockchain FIG. 6A illustrates an example of a permissioned blockchain network consistent with some embodiments, where the permissioned blockchain network features a distributed, decentralized, peer-to-peer architecture. In this example, a blockchain user 602 may initiate a transaction against a permissioned blockchain 604. In this example, the transaction may be a deployment, invocation, or query and may be issued via a client-side application utilizing an SDK, directly via an API, or the like. The network may provide access to regulators 606, such as auditors. A blockchain network operator 608 manages member permissions, such as registering regulators 606 as “auditors” and blockchain users 602 as “clients.” Auditors may be limited to only querying the ledger, while clients may be allowed to deploy, invoke, and query certain types of chaincode.

[0071] A blockchain developer 610, in some embodiments, can write chaincode and client-side applications. In these embodiments, the blockchain developer 610 may deploy the chaincode directly to the network via an interface. To include authentication information from traditional data sources 612 in the chaincode, the developer 610 may access the data using an out-of-band connection. In this example, a blockchain user 602 may connect to the permissioned blockchain 604 through a peer node 614. Before initiating any transactions, the peer node 614 may obtain user registration and transaction certificates from a certificate authority 616 that manages user roles and permissions. In some embodiments, blockchain users must possess their digital certificates to perform transactions on the permissioned blockchain 604. In other embodiments, blockchain users may be authenticated using other techniques, such as by a distributed chain of trust. Meanwhile, users seeking to utilize chaincode may need to verify their user credentials on traditional data sources 612. To verify the user's authorization, the chaincode may use an out-of-band connection to this data through a traditional processing platform 618.

[0072] FIG. 6B illustrates another example of a permissioned blockchain network consistent with some embodiments, where the permissioned blockchain network features a distributed, decentralized, peer-to-peer architecture. In this example, a blockchain user 622 may submit transactions to a permissioned blockchain 624. In this example, transactions can be deploys, invokes, or queries and can be issued through a client-side application utilizing an SDK, directly through an API, or the like. The network may provide access to regulators 626, such as auditors. A blockchain network operator 628 manages member permissions, such as registering regulators 626 as “auditors” and blockchain users 622 as “clients.” Auditors can be limited to only querying the ledger, while clients can be authorized to deploy, invoke, and query certain types of chaincode.

[0073] A blockchain developer 631 may write the chaincode and client-side applications in these embodiments. The blockchain developer 631 may deploy the chaincode directly to the network through an interface. To include authentication information from traditional data sources 632 in the chaincode, the developer 631 may access the data using an out-of-band connection. In this example, a blockchain user 622 connects to the network through a peer node 634. The peer node 634 obtains the user's registration and transaction certificate from a certificate authority 636 before initiating any transactions. In some embodiments, blockchain users must possess their digital certificates to execute transactions on the permissioned blockchain 624. In other embodiments, blockchain users may be authenticated using other techniques, such as by a distributed chain of trust. Meanwhile, users seeking to utilize chaincode may need to verify their user's authentication information on traditional data sources 632. To verify the user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 638.

[0074] FIG. 6C illustrates an example system including a physical infrastructure 611 configured to perform various operations consistent with some embodiments. Referring to FIG. 6C, the physical infrastructure 611 includes a module 688 and a module 689. The module 619 includes a blockchain 620 and a smart contract 630 (which may reside in the blockchain 620), which may perform any of the operational steps 678 (within the module 688) included in any of the example embodiments. The steps / operations 678 may include one or more of the embodiments described or illustrated in the figures and may represent information written to, read from, output from, or written to one or more smart contracts 630 and / or the blockchain 620. The physical infrastructure 611, the module 688, and the module 689 may include one or more computers, servers, processors, memories, or wireless communication devices, or a combination thereof. Additionally, the module 688 and the module 689 may be the same module.

[0075] FIG. 6D illustrates another exemplary system configured to perform various operations consistent with some embodiments. Referring to FIG. 6D , the system includes modules 692 and 694. Module 694 includes a blockchain 620 and a smart contract 630 (which may reside in the blockchain 620), which may perform any of the operational steps 678 (within module 692) included in any of the example embodiments. Steps / operations 678 may include one or more of the embodiments described or illustrated in the figures and may represent information written to, read from, output from, or written to one or more smart contracts 630 and / or blockchain 620. Physical modules 692 and 694 may include one or more computers, servers, processors, memories, or wireless communication devices, or a combination thereof. Furthermore, modules 692 and 694 may be the same module.

[0076] FIG. 6E illustrates an exemplary system configured to utilize an intermediary server configured to configure a smart contract between contracting parties and enforce the terms of the smart contract on the blockchain 620, consistent with some embodiments. Referring to FIG. 6E, this configuration may represent a communication session, an asset transfer session, or a process or procedure operated by a smart contract 630 that explicitly identifies one or more user devices 652 and / or 656. The execution, operation, and results of the smart contract may be managed by a server 654. The contents of the smart contract 630 may require digital signatures by one or more of the entities 652 and 656 that are participants in the smart contract transaction. The results of the smart contract execution may be written to the blockchain 620 as a blockchain transaction. The smart contract 630 resides on the blockchain 620, which may reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0077] FIG. 6F illustrates a system 660 including a blockchain, consistent with some embodiments. Referring to the example of FIG. 6D , an application programming interface (API) gateway 662 provides a common interface for accessing the blockchain's logic (e.g., smart contracts 630 or other chaincode) and data (e.g., distributed ledgers, etc.). In this example, the API gateway 662 is a common interface for executing transactions (calls, queries, etc.) against the blockchain by connecting one or more entities 652 and 656 to blockchain peers (i.e., servers 654). Here, the servers 654 are peer components of the blockchain network that maintain copies of the world state and the distributed ledger, allowing clients 652 and 656 to query data about the world state and submit transactions to the blockchain network, which executes the smart contracts 630 according to the smart contracts 630 and signing policies.

[0078] Creating a Channel 7A and 7B (collectively FIG. 7) illustrate one method 700 of creating a channel in a blockchain network, consistent with some embodiments. At operation 710, a blockchain administrator sends a channel creation transaction message (tx) to a TOS gateway GA. At operation 720, the TOS gateway GA may respond by publishing a channel initialization message (“CHAN INIT BEGIN”) to the shared message queue 450. At operation 730, the TOS gateways Ga, Ge associated with organizations B and C, respectively, may receive the message from the total ordering service TOS. In response, each receiving TOS gateway Gii, Ge may generate a pair of random temporary private keys and corresponding public keys P B, P C at operation 732 and then publish the public keys P A, P C to the shared message queue 450 at operation 734.

[0079] Next, the TOS Gateway GA of Organization A may generate a random symmetric key K in operation 740 and may split the generated key K into "t" shares (in this example, three shares, one for each TOS Gateway GA, Gs, Ge, etc. in the blockchain) in operation 742. The TOS Gateway GA may then distribute the key shares to the other TOS Gateways, which in operation 744 distributes the split keys of the other Gateways Ps (Ks), Pc (Kc), etc. and publishing the resulting ciphertext at operation 746. Each other TOS Gateway G e, G e, etc. may decrypt its key assignment (Ks, Kc, etc.) at operation 750 and store the decrypted key assignment along with a portion of the symmetric key H(K) in local persistent storage at operation 752. Alternatively, as described in more detail below, each TOS Gateway G a, G s, G e may generate its own key assignment from the symmetric key.

[0080] At operation 760, each other TOS gateway Gs, Ge may publish a CHAN INIT END message and then forget (i.e., delete) their TOS gateway temporary private key. The TOS gateways GA, Gs, Ge may store the key splits KA, Ke, Kc in their own persistent storage at operation 762 and may publish K(tx) at operation 764. In this way, the published transaction (tx) may be the creation of a channel transaction. The above operations may establish an encryption key that encrypts the transaction. Because the key may contain sensitive information, such as the identities of the parties in the channel, this key may, in some embodiments, be encrypted to prevent the TOS from seeing the contents of the key.

[0081] Symmetric Key Derivation In some embodiments, the cryptographic key may be used as a seed in a key derivation algorithm that deterministically changes the key every multiple messages, as follows: {SHA256(K||X||i)}XE{” 0 A”', 00 B 00 "C 00 ) where "i" is a predefined number of messages (e.g., 2 32 Messages, 2 96 The counter is a counter that may be incremented periodically, weekly, monthly, quarterly, etc., after every 100 messages. The assignments may then be distributed uniformly randomly according to the field used. One advantage of using this system is that various TOS gateways GA, Gs, etc. do not have to use the same counter value and do not need to coordinate on how to seed the counter. Another advantage is that the system may automatically rotate the order of key assignments among blockchain members (e.g., TOS gateway Chi may have the first key assignment during the first counter period, the fifth key assignment during the second counter period, etc.).

[0082] Symmetric Key Recovery In some embodiments, the channel's symmetric key K is not written to non-volatile storage (e.g., disk) but instead is stored only in volatile storage (e.g., random access memory). FIG. 8 illustrates one method 800 of symmetric key recovery by a TOS gateway GA, consistent with some embodiments. To decrypt or encrypt a message obtained from the total ordering service, the TOS gateway GA may reconstruct the secret by obtaining a sufficient key allocation from a remote TOS gateway Gn, Ge, etc., or may simply obtain the secret from another TOS gateway Gn, Ge, etc. that has already reconstructed the secret. A TOS gateway, in some embodiments, lacks sufficient information to compute its own allocation without knowing the other gateway's allocations.

[0083] To obtain the symmetric key from another TOS Gateway, in operation 810, the TOS Gateway GA may first contact the TOS Gateways Gn, Ge, etc. in a round-robin manner and request the symmetric key. If the other TOS Gateways Gn, Ge, etc. do not have the symmetric key, the TOS Gateway GA may begin reconstructing the symmetric key using the key assignments Ka, Kc, etc. of “t-1” TOS Gateways Gn, Ge, etc., where “t” may be selected by an administrator of the blockchain network based on the security needs of the network.

[0084] However, TOS Gateways may not share any peer-to-peer IP connections in some embodiments. Instead, TOS Gateways may communicate via the shared messaging queue 450 by first initiating / performing a temporary key pair establishment protocol via the shared messaging queue, in operations 820-836, to establish symmetric encryption keys used to encrypt the exchange of K and / or its assignment. More specifically, in operation 820, TOS Gateway G A may first generate a temporary private key a and its corresponding public key Pa and publish a key exchange message, which may not be encrypted. Generally, key exchange protocols, in some embodiments, are designed to function over an insecure medium to establish symmetric encryption keys. However, some key exchange embodiments may use encryption (encrypted) for the shared messaging queue in operation 822, directed to another TOS Gateway (e.g., TOS Gateway G n ) and including the new temporary public key (symbolically {KEX_G n , Pa}) to the shared messaging queue 450. If the TOS Gateway GA wants to recover the original random symmetric key K, the TOS Gateway GA may also add a key request ("KEY") to the message in operation 822; similarly, if the TOS Gateway GA wants to obtain a key assignment, the TOS Gateway GA may also add a key assignment request ("SHR") in operation 822.

[0085] In response to the key exchange message, the TOS Gateway Gii may generate a temporary private key p and a corresponding public key Pp in operation 830. Then, the TOS Gateway Gii may calculate a temporary symmetric key (KEXAB) from p and PA in operation 832. Thereafter, in operation 834, the TOS Gateway Gii may encrypt (using KEXAB) the symmetric key (i.e., {Pp, KEXAB(K)}) and publish it to the shared messaging queue in response to a "KEY" request from the TOS Gateway GA, or may encrypt and publish the TOS Gateway Gii's key assignment (i.e., {Pp, KEXAB(Ks)}) to the shared messaging queue in response to a "SHR" request from the TOS Gateway GA.

[0086] In operation 840, the TOS Gateway Gii may forget the temporary private key p. That is, the TOS Gateway Gii may delete the temporary private key from volatile memory and does not store the temporary private key in non-volatile memory. In operation 850, the TOS Gateway GA may decrypt the original random symmetric key K or reconstruct K using the key fragments KA, Ks, etc. Then, in operation 855, the TOS Gateway GA may forget the temporary private key a. In this way, even if an entity gains access to the shared messaging queue 450, the original random symmetric key K is still protected.

[0087] Syndicate Membership Expansion FIG. 9 is a flow chart illustrating one method 900 of extending membership in a blockchain, consistent with some embodiments. In this embodiment, each time a new member / organization “D” joins a channel, a TOS gateway Gn may obtain a shared key K and its own key assignment K. At operation 910, the TOS gateway Gn begins by contacting “t” of the existing channel members A, B, C, etc., using the protocol described with reference to FIG. 8 to reconstruct the current symmetric key K and store it in volatile memory (only), where “t” is a number selected by the administrator of the blockchain based on their security profile. The new TOS gateway Gn may then calculate its own unique key assignment K (i.e., a key assignment that is different from all other key assignments K, Ks, Kc, etc.) using the method described above at operation 920 and store K in persistent storage at operation 930. Alternatively, one of the other TOS gateways may calculate the key assignment K and send it along with the shared symmetric key.

[0088] Similarly, when a new member D is detected in the channel configuration, all existing TOS gateways GA, Gs, Ge, etc. may conduct a temporary key pair establishment session with the new TOS gateway Go, after which the new TOS gateway Go obtains K and Ko.

[0089] Removal of Syndicate Membership When a member is removed from a channel by blockchain member A, B, C, or the blockchain's IT administrator, or a combination thereof, the total ordering service TOS may rotate the encryption key K so that the removed member can no longer decrypt messages in the shared message queue 450. Figures 10A and 10B (collectively, Figure 10) illustrate one such method 1000 of rotating keys, consistent with some embodiments. In this example, and for illustrative purposes only, assume that organizations A and B want to remove organization C from the channel. At operation 1010, the blockchain administrator may send a channel configuration transaction (tx) to the TOS gateway GA, and at operation 1020, the TOS gateway GA may respond by publishing a channel reconfiguration ("CHAN RECONF AB BEGIN") message tx to the total ordering service TOS.

[0090] At operation 1030, the TOS gateway Gs may receive the channel reconfiguration message and may respond by generating a random temporary private key β and a corresponding public key P. Then, at operation 1035, the TOS gateway G a may publish the public key P p to the total ordering service TOS.

[0091] The TOS gateway GA generates a new random symmetric key K 1 and in operation 1042 generates a symmetric key K 1 into n allocations, where n is equal to the number of remaining members (2 in this case). The TOS Gateway GA then obtains, in operation 1045, the temporary public keys of the other TOS Gateways Gs (e.g., Pp(K 1 a), Pp(K 1 ), and K 1(tx)) and publishes those key assignments to the total ordering service TOS in operation 1047. That is, some embodiments first change the key and then have all organizations except the removed organization learn the new key. However, since these embodiments may still require the reconfiguration to be applied to the blockchain itself, these embodiments may encrypt and send the reconfiguration transaction using the new key. Alternatively, the TOS gateway Gs may use the methods described above to generate a new symmetric key K 1 It may use it to compute its own key assignment.

[0092] At operation 1050, the TOS gateway Gs receives the key assignment K 1 a, a new symmetric key K 1 , and tx. The TOS gateway Gs may then verify in operation 1052 that organization C has indeed been removed from the channel, and if so, in operation 1054, K 1 a is stored in persistent storage and an operation 1056 publishes a channel reconfiguration end ("CHAN RECONF AB END") message to the total ordering service TOS.

[0093] Restructuring of Syndicate Membership To support re-adding removed organizations and / or reconfiguring channels (e.g., creating a channel), each TOS gateway GA, Gn, etc. may store key assignments KA, KB, etc. according to block ranges that include ongoing membership. In such cases, previous key assignments may be used within a block range if all current and future members of the channel agree to retain the key assignment. Similarly, all new organizations that are brought in must learn the past symmetric keys.

[0094] Non-repudiation and integrity guarantees Some embodiments may support non-repudiation and provide integrity guarantees. These embodiments may be desirable if the total ordering service TOS does not operate correctly or malfunctions, resulting in individual TOS gateways GA, Gn, etc. receiving messages in a different order. Similarly, these embodiments may be desirable if one member organization A, B, etc. wrongly claims that the total ordering service TOS sent messages in a different order than the order in which they were received by those member organizations.

[0095] To enable detection of such events if they do occur or to refute incorrect claims, each TOS Gateway, in some embodiments, may periodically (e.g., every B blocks or every T time periods) publish a message that may include (i) the message's block range [i,j], and (ii) a Merkle root (e.g., a hash of all hashes of all transactions that are part of a block in the blockchain network), where the block indexed [i,j] is a leaf of the Merkle root. If a TOS Gateway GA, Gn, etc., detects that it has diverged from the majority of other network members, the TOS Gateway may cease operation and return a special error when servicing API calls.

[0096] Processing Blocks Figure 11A illustrates a process 1100 of a new data block 1130 being added to a distributed ledger 1120, consistent with some embodiments, and Figure 11B illustrates the contents of the new data block 1130 in the blockchain, consistent with some embodiments. The new data block 1130 may include documents that link data.

[0097] Referring to FIG. 11A , a client (not shown) may submit a transaction to blockchain node 1111, 1112, or 1113, or a combination thereof. A client may be an instruction received from any source to specify an activity on the blockchain 1122. As an example, a client may be an application acting on behalf of a requester, such as a device, person, or entity, that proposes a blockchain transaction. Multiple blockchain peers (e.g., blockchain nodes 1111, 1112, and 1113) may maintain a copy of the blockchain network state and distributed ledger 1120. Various types of blockchain nodes / peers may exist within a blockchain network, including signing peers that simulate and sign transactions proposed by clients, and commit peers that verify signatures, confirm the validity of the transactions, and commit the transactions to the distributed ledger 1120. In some embodiments, blockchain nodes 1111, 1112, and 1113 may perform the role of signer nodes, committer nodes, or both.

[0098] The distributed ledger 1120 may include a blockchain that stores immutable, ordered records in blocks, and a state database 1124 (current world state) that maintains the current state of the blockchain 1122. There may be one distributed ledger 1120 per channel, with each peer maintaining its own copy of the distributed ledger 1120 for each channel in which it is a member. The blockchain 1122 may be a transaction log structured as hash-linked blocks, with each block containing a sequence of N transactions. A block may contain various components, such as those shown in FIG. 11B. Block links (shown by arrows in FIG. 11A) may be generated by adding a hash of the previous block's header into the block header of the current block. In this way, all transactions on the blockchain 1122 may be ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash links. Furthermore, because of these links, the most recent block in the blockchain 1122 represents all transactions that came before it. The blockchain 1122 may be stored in the file system (local or attached storage) of a peer that supports additional dedicated blockchain workloads.

[0099] The current state of the blockchain 1122 and distributed ledger 1120 may be stored in a state database 1124, where the current state data represents the latest values ​​of all keys ever included in the chain transaction log of the blockchain 1122. Chaincode invocations execute transactions against the current state in the state database 1124. To make those chaincode interactions more efficient, the latest values ​​of all keys may be stored in the state database 1124. The state database 1124 may contain an indexed view into the blockchain 1122 transaction log and therefore can be regenerated off-chain at any time. The state database 1124 may be automatically restored (or generated if necessary) upon peer startup, before transactions are received.

[0100] A signing node receives transactions from clients and signs them based on the simulation results. The signing node holds a smart contract that simulates a transaction proposal. When a signing node signs a transaction, it creates a transaction signature, which is a signed response from the signing node to the client application indicating the signature of the simulated transaction. The way in which a transaction is signed is determined by a signature policy, which may be specified in the chaincode. An example of a signature policy is "a majority of the signing peers must sign the transaction." Different channels may have different signature policies. The signed transaction is forwarded by the client application to the ordering service 1110.

[0101] The ordering service 1110 receives signed transactions, orders them into blocks, and distributes the blocks to committing peers. For example, the ordering service 1110 may initiate a new block when a transaction threshold is reached, a timer times out, or another condition occurs. In the example of FIG. 11A, blockchain node 1112 is a committing peer that receives a new data block 1130 of new data for storage in the blockchain 1122. The first block in a blockchain may be called a genesis block, which contains information about the blockchain, its members, the stored data, etc.

[0102] The ordering service 1110 may consist of a cluster of ordering nodes. In some embodiments, the ordering service 1110 may not process transactions, smart contracts, or maintain a shared ledger. Rather, in these embodiments, the ordering service 1110 may receive signed transactions and specify the order in which those transactions are committed to the distributed ledger 1120. The architecture of the blockchain network may be designed so that specific implementations of "ordering" (e.g., Solo, Kafka, BFT, etc.) are pluggable components.

[0103] In some embodiments, transactions may be written to the distributed ledger 1120 in a consistent order. In these embodiments, the order of transactions may be established to ensure that updates to the state database 1124 are valid when transactions are committed to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin) where ordering occurs through solving cryptographic puzzles or mining, in this example, the parties to the distributed ledger 1120 may choose the ordering mechanism that best suits their network.

[0104] In some embodiments, the ordering service 1110 may initialize a new data block 1130, which may be broadcast to the committing peers (e.g., blockchain nodes 1111, 1112, and 1113). In response, each committing peer may confirm the validity of the transactions in the new data block 1130 by checking to ensure that the read set and write set still match the current world state in the state database 1124. In particular, the committing peer may determine whether the read data that existed when the signer simulated the transaction is identical to the current world state in the state database 1124. If the committing peer confirms the validity of the transaction, the transaction may be written to the blockchain 1122 of the distributed ledger 1120, and the state database 1124 may be updated with the write data from the read / write set. In some embodiments, if a transaction fails (e.g., if a commit peer detects that the read / write set does not match the current world state in state database 1124), the transactions ordered within the block may still be included in that block but may be marked as invalid, and state database 1124 is not updated.

[0105] Referring to FIG. 11B , in some embodiments, a new data block 1130 (also referred to as a data block) stored in the blockchain 1122 of the distributed ledger 1120 may include multiple data segments, such as a block header 1140, block data 1150, and block metadata 1160. It should be understood that the various illustrated blocks and their contents, such as the new data block 1130 and its contents illustrated in FIG. 11B , are merely examples and are not intended to limit the scope of example embodiments. The new data block 1130 may store transaction information for N (e.g., 1, 10, 100, 200, 1000, 2000, 3000, etc.) transactions in the block data 1150. The new data block 1130 may include a link to a previous block (e.g., on the blockchain 1122 of FIG. 11A ) in the block header 1140. In particular, the block header 1140 may include a hash of the previous block's header. The block header 1140 may include a unique block number for the new data block 1130, a hash of the block data 1150, etc. The block numbers for the new data block 1130 are unique and may be assigned in various orders, such as a progressive / consecutive order starting from 0.

[0106] The block data 1150 may store transaction information for each transaction recorded in the new data block 1130. For example, the transaction data may include one or more of the following: transaction type, version, timestamp, distributed ledger 1120 channel ID, transaction ID, epoch, payload visibility, chaincode path (deploying the transaction), chaincode name, chaincode version, inputs (chaincode and function), client (creator) identification such as public key and certificate, client signature, signer identification information, signer signature, proposal hash, chaincode event, response status, namespace, read set (e.g., a list of keys and versions read by the transaction), write set (e.g., a list of keys and values), start key, end key, list of keys, Merkle tree query summary, etc. Transaction data may be stored for each of the N transactions.

[0107] In some embodiments, block data 1150 may store new data 1162 that adds additional information to the hash-linked chain of blocks in blockchain 1122. The additional information may include one or more of the steps, features, processes, or operations described or illustrated herein, or any combination thereof. Accordingly, new data 1162 may be stored in an immutable log of blocks on distributed ledger 1120. Some of the advantages of storing such new data 1162 are reflected in various embodiments disclosed and illustrated herein. While FIG. 11B shows new data 1162 within block data 1150, in some embodiments, new data 1162 may also be within block header 1140 or block metadata 1160. New data 1162 may include a document composite key used to link documents within an organization.

[0108] The block metadata 1160 may store multiple fields of metadata (e.g., as a byte array). The metadata fields may include a signature at the time of block creation, a reference to the last constituent block, a transaction filter that identifies valid and invalid transactions in the block, and the last persistent offset of the ordering service that ordered the block. The signature, last constituent block, and ordering node metadata may be added by the ordering service 1110. Meanwhile, the block committer (e.g., blockchain node 1112) may add valid / invalid information based on signature policies, validation of read / write sets, etc. The transaction filter may include a byte array of size equal to the number of transactions in the block data 1150 and a validation code that identifies whether the transaction was valid / invalid.

[0109] FIG. 11C illustrates an embodiment of a blockchain 1170 for digital content, consistent with some embodiments. Digital content may include one or more files and associated information. These files may include transaction data, media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only feature of some blockchain embodiments may be desirable in serving as a safeguard to protect the integrity, validity, and authenticity of the digital content, making it appropriate for use in legal proceedings where admissibility rules apply or in other situations where evidence is considered or the presentation and use of digital information is otherwise subject. In this case, the digital content may be referred to as digital evidence.

[0110] In these embodiments, the blockchain may be formed in a variety of ways. In one embodiment, digital content may be contained within and accessed from the blockchain itself. For example, each block in the blockchain may store a hash value of reference information (e.g., headers, values, etc.) along with the associated digital content. The hash value and associated digital content may then be encrypted together. Thus, the digital content of each block may be accessed by decrypting each block in the blockchain, and the hash value of each block may be used as a basis to reference the previous block. This may be shown as follows: Block 1 Block 2 ······ Block N Hash value 1 Hash value 2 Hash value N Digital Content 1 Digital Content 2 Digital Content N

[0111] In one embodiment, the digital content may not be included in the blockchain. For example, the blockchain may store a cryptographic hash of the contents of each block that does not contain digital content. The digital content may be stored in a separate storage area or memory address relative to the hash value of the original file. The other storage area may be the same storage device used to store the blockchain, or it may be a different storage area or a separate relational database. The digital content of each block may be referenced or accessed by obtaining or querying the hash value of the block in question and then searching the storage area for the stored hash value that corresponds to the actual digital content. This operation may be performed, for example, by a database gatekeeper. This may be illustrated as follows: Blockchain Storage Area Hash value of block 1 Hash value of block 1 Contents · · · · · · Hash value of block N Hash value of block N...Contents

[0112] In the example embodiment of FIG. 7C, the blockchain 1170 includes multiple blocks 11781, 11782, ... 1178N cryptographically linked in an ordered sequence, N::”. 1. The cryptography used to link the blocks 11781, 11782, ... 1178N may be any of multiple keyed or unkeyed hash functions. In one embodiment, the blocks 11781, 11782, ... 1178N are subjected to a hash function (where n is 256 or another number) that produces an n-bit alphanumeric output from input that is based on the information in the block. Examples of such hash functions include SHA-type (SHA stands for Secure Hash Algorithm). Examples of such algorithms include, but are not limited to, the RSA Algorithm (representing a hash function), the Merkle-Dangard algorithm, the HAIFA algorithm, the Merkle tree algorithm, a nonce-based algorithm, and a non-collision-resistant PRF algorithm. In another embodiment, blocks 11781, 11782, ..., 1178N may be cryptographically linked by a function different from a hash function. For illustrative purposes, the following description is provided with reference to a hash function (e.g., SHA-2).

[0113] Each of the blocks 11781, 11782, ..., 1178N in the blockchain may include a header, a file version, and a value. The header and value may vary from block to block as a result of hashing within the blockchain. In one embodiment, the value may be included in the header. As described in more detail below, the file version may be the original file or a different version of the original file.

[0114] The first block 11781 in a blockchain is called the genesis block and may include a header 11721, an original file 11741, and an initial value 11761. The hashing scheme used for the genesis block (and indeed for all subsequent blocks) may vary. For example, all of the information in the first block 11781 may be hashed together simultaneously, or each or portions of the information in the first block 11781 may be hashed separately, followed by subsequent hashing of the separately hashed portions.

[0115] The header 11721 may include one or more initial parameters, such as a version number, a timestamp, a nonce, root information, difficulty, consensus protocol, duration, media format, source, descriptive keywords, or other information associated with the original file 11741 and / or the blockchain. The header 11721 may be generated automatically (e.g., by blockchain network management software) or manually by a blockchain participant. Unlike headers in other blocks 11782-1178N in the blockchain, the header 11721 in the genesis block need not reference a previous block, simply because there is no previous block.

[0116] The original file 11741 in the genesis block may be, for example, data captured by a device, with or without processing before being included in the blockchain. The original file 11741 may be received from a device, media source, or node through a system interface. The original file 11741 may be associated with metadata, which may be generated, for example, by a user, device, or system processor, or a combination thereof, either manually or automatically. The metadata may be included in the first block 11781 associated with the original file 11741.

[0117] The value 11761 in the genesis block may be an initial value generated based on one or more unique attributes of the original file 11741. In one embodiment, the one or more unique attributes may include a hash value of the original file 11741, metadata of the original file 11741, and other information associated with the file. In one implementation, the initial value 11761 may be based on the following unique attributes: (1) The hash value calculated for the original file using SHA-2 (2) Calling device ID (3) The start timestamp of the original file (4) The initial storage location of the original file (5) The blockchain network member ID of the software that currently controls the original file and associated metadata.

[0118] The other blocks 11782-1178N in the blockchain also contain headers, files, and values. However, unlike the first block's header 11721, each of the headers 11722-1172N in the other blocks contains the hash value of the immediately preceding block. The hash value of the immediately preceding block may simply be the hash of the previous block's header, or it may be the hash value of the entire previous block. By including the hash value of the preceding block in each of the remaining blocks, a block-by-block trace can be performed from the Nth block back to the genesis block (and associated original files), as indicated by arrow 1180, establishing an auditable and immutable chain of custody.

[0119] Each of the headers 11722-1172N in the other blocks may generally include other information (e.g., version number, timestamp, nonce, root information, difficulty, consensus protocol), or other parameters or information associated with the corresponding file or blockchain or both, or a combination thereof.

[0120] The files 11742-1174N in other blocks may be the same as the original file in the genesis block or may be modified versions of the original file, depending, for example, on the type of processing performed. The type of processing performed may vary from block to block. Processing may include any modification of the file in the preceding block, such as, for example, editing or otherwise changing the content of information, removing information from the file, or adding information to the file.

[0121] Additionally or alternatively, processing may include simply copying a file from a previous block, changing the storage location of a file, analyzing a file from one or more previous blocks, moving a file from one storage or memory location to another, or performing an operation on a file and / or associated metadata on the blockchain. Processing that includes analyzing a file may include, for example, adding, including, or otherwise associating various analyses, statistics, or other information associated with the file.

[0122] The values ​​contained in each of the other blocks 11762-1176N within the other blocks are unique and different as a result of the operations that were performed. For example, the value in any one block corresponds to an updated version of the value in the previous block. This update is reflected in the hash of the block to which the value was assigned. Thus, the value of a block provides an indication of what operations were performed within the block and also makes it possible to trace the blockchain back to the original file. This tracking confirms the evidential integrity of the file throughout the blockchain.

[0123] For example, consider the case where a portion of a file in a previous block is redacted, blocked, or pixelated to protect the identity of a person indicated in the file. In this case, the block containing the edited file would include metadata associated with the edited file, such as how the edit was performed, who performed the edit, a timestamp of when the edit occurred, etc. This metadata may be hashed to form a value. Because the block's metadata is different from the information hashed to form the value in the previous block, the values ​​are different from each other and may be recovered when decrypted.

[0124] In one embodiment, the value of the previous block may be updated (e.g., a new hash value may be calculated) to form the value of the current block if any one or more of the following occurs: The new hash value, in this example embodiment, may be calculated by hashing all or part of the information set forth below: (a) A new SHA-2 computed hash value when the file is processed in any way (e.g., when the file is edited, copied, modified, accessed, or any other action is performed on it). (b) The new storage location of the file (c) Identified new metadata associated with the file. (d) Transfer of file access or control from one blockchain participant to another blockchain participant.

[0125] 11D illustrates an embodiment of a block that may represent the structure of a block in a blockchain 1190, consistent with some embodiments. A block (Block i) may include a header 1172 i, a file 1174 i, and a value 1176 i.

[0126] Header 1172i may include a hash value of the previous block (block i.1) ​​as described herein, and additional reference information (e.g., header information including references, properties, parameters, etc.), which may be, for example, any of the types of information. In some embodiments, all blocks may reference the hash of the previous block, but in some embodiments, except for the genesis block. The hash value of the previous block may simply be a hash of the header in the previous block, or it may be a hash of all or part of the information in the previous block, including files and metadata.

[0127] File 1174-i may include multiple pieces of data, such as Data 1, Data 2, ..., Data N, in order. The data are tagged with Metadata 1, Metadata 2, ..., Metadata N, which describe the content and / or characteristics associated with the data. For example, the metadata for each piece of data may include information to indicate a timestamp for the data, keywords indicating the process of the data, people or other content depicted in the data, or other characteristics, or combinations thereof, that establish the validity and content of the file as a whole and may be particularly useful for using digital evidence, e.g., as described in connection with the embodiments described below. In addition to the metadata, each piece of data may be tagged with a reference to the previous piece of data (Reference 1, Reference 2, ..., Reference N) to prevent tampering, gaps within the file, and sequential referencing throughout the file.

[0128] In some embodiments, after metadata is assigned to data (e.g., via a smart contract), it cannot be changed without changing the hash, which can be easily identified as invalid. Thus, in these embodiments, the metadata creates a data log of information that may be accessed for use by participants in the blockchain.

[0129] In some embodiments, value 1176i may be a hash value or other value calculated based on any of the types of information previously described. For example, for any particular block (block i), the value of that block may be updated to reflect operations performed on that block (e.g., a new hash value, a new storage location, new metadata for the associated file, control or access transfer, identifiers, or other operations or information added). Although the values ​​in each block are shown as separate from the metadata of the file and header data, in other embodiments, the values ​​may be based in part or in whole on this metadata.

[0130] In some embodiments, at any point after the blockchain 1170 is formed, an immutable archival record of a file may be obtained by querying the blockchain for a transaction history of values ​​across blocks. This query or tracking procedure may begin by decrypting the value of the last included block (e.g., the last (Nth) block), and then continue decrypting values ​​of other blocks until the genesis block is reached and the original file is recovered. Decryption may include decoding the header and file and associated metadata at each block.

[0131] Decryption may be performed based on the type of encryption performed on each block. This decryption may involve the use of a private key, a public key, or a public and private key pair. For example, if asymmetric encryption is used, a blockchain participant or a processor within the network may generate a public and private key pair using a predefined algorithm. The public and private keys may be related to each other by some mathematical relationship. The public key may be publicly distributed to serve as an address (e.g., an IP address or home address) for receiving messages from other users. The private key may be kept secret and may be used to digitally sign messages sent to other blockchain participants. The signature may then be included in the message so that the recipient can verify it using the sender's public key. In this way, the recipient can be confident that only the sender could have sent the message.

[0132] In some embodiments, generating a key pair may be similar to creating an account on the blockchain, but without actually having to register anywhere. In these embodiments, all transactions performed on the blockchain may be digitally signed by the sender using a private key. This signature may help ensure that only the account owner (within the scope of permissions determined by the smart contract) can track and transact on files on the blockchain.

[0133] Figures 12A and 12B illustrate additional use cases for blockchain that may be incorporated and used herein. In particular, Figure 12A illustrates an example 1200 of a blockchain 1210 storing machine learning (artificial intelligence) data. Machine learning typically relies on large amounts of historical data (or training data) to build predictive models for accurate predictions on new data. Machine learning software (e.g., neural networks) can often sift through millions of records to discover non-intuitive patterns.

[0134] In the example of FIG. 12A , a host platform 1220 builds and deploys machine learning models for predictive monitoring of assets 1230. Here, the host platform 1220 may be a cloud platform, an industrial server, a web server, a personal computer, a user device, etc. The assets 1230 may be any type of asset (e.g., machinery or equipment), such as an aircraft, a locomotive, a turbine, medical machinery and equipment, oil and gas equipment, a boat, a ship, a vehicle, etc. As another example, the assets 1230 may be intangible assets, such as stocks, currency, digital coins, insurance, etc.

[0135] The blockchain 1210 may be used to significantly improve both the machine learning model training process 1202 and the prediction process 1204 based on the trained machine learning model. For example, in 1202, historical data may be stored on the blockchain 1210 by the asset 1230 itself (or through an intermediary, not shown) rather than requiring a data scientist / engineer or other user to collect the data. This may significantly reduce the collection time required by the host platform 1220 when performing predictive model training. For example, a smart contract may be used to transfer data directly and reliably from its original location to the blockchain 1210. The smart contract may send data directly from the asset to the individual who uses the data to build the machine learning model, using the blockchain 1210 to ensure the security and ownership of the collected data. This enables the sharing of data between assets 1230.

[0136] The collected data may be stored in the blockchain 1210 based on a consensus mechanism. The consensus mechanism may control (authorized nodes) to ensure that the data being recorded is verified and accurate. The recorded data may be time-stamped, cryptographically signed, and immutable. Thus, the recorded data is auditable, transparent, and secure. Adding IoT devices that write directly to the blockchain can increase the frequency and accuracy of data recording in certain cases (i.e., supply chain, healthcare, logistics, etc.).

[0137] Furthermore, the training of the machine learning model on the collected data may undergo a series of refinements and tests by the host platform 1220. Each series of refinements and tests may be based on additional data or data not previously considered to help expand the knowledge of the machine learning model. In 1202, the host platform 1220 may store the different training and testing steps (and associated data) on the blockchain 1210. Each refinement of the machine learning model (e.g., changes in variables, weights, etc.) may be stored on the blockchain 1210, thereby providing verifiable proof of how the model was trained and what data was used to train the model. Furthermore, when the host platform 1220 achieves a final trained model, the resulting model may be stored on the blockchain 1210.

[0138] After the model is trained, it may be deployed to a live environment, where predictions / decisions can be made based on the execution of the final trained machine learning model. For example, at 1204, the machine learning model may be used for condition-based maintenance (CBM) for assets such as aircraft, wind turbines, and medical machinery. In this example, feedback data from the asset 1230 may be input into the machine learning model and used to make event predictions such as failure events, error codes, and the like. Decisions made by the execution of the machine learning model on the host platform 1220 may be stored on the blockchain 1210 to provide auditable / verifiable proof. As one non-limiting example, the machine learning model may predict a future outage / failure in a part of the asset 1230 and generate an alert or notification to replace the part. The data behind this decision may be stored on the blockchain 1210 by the host platform 1220. In one embodiment, the features and / or operations described and / or illustrated herein may occur on or with respect to the blockchain 1210.

[0139] New transactions on the blockchain may be collected together in a new block and added to an existing hash value. This hash value may then be encrypted to create a new hash for the new block. This new hash may be added to the next list of transactions, such as when the transaction is encrypted. The result is a chain of blocks, each containing the hash values ​​of all preceding blocks. Computers storing these blocks periodically compare the hash values ​​of the blocks to ensure they all agree. Any computers that do not agree discard the offending record. While this method is good at ensuring the blockchain is tamper-proof, it is not perfect.

[0140] One way to game the system is for a malicious user to modify the list of transactions in a way that does not change the hash. This can be done by brute force, i.e., by modifying the record, encrypting the result, and checking if the hash value is the same. If the hash value is not the same, try again and again until you find a matching hash. The security of blockchain is based on the idea that ordinary computers can only perform this type of brute force attack over completely impractical timescales, such as the age of the universe. In contrast, for some types of problems, quantum computers are extremely fast (thousands of times faster) and therefore pose a much greater threat.

[0141] FIG. 12B shows an example 1250 of a quantum-secure blockchain 1252 that implements quantum key distribution (QKD) to protect against quantum computing attacks. In this example, blockchain users can verify each other's identities using QKD. This verification may involve using quantum particles, such as photons, to transmit information that cannot be copied by an eavesdropper without being corrupted. In this way, senders and receivers can confirm each other's identities via the blockchain.

[0142] In the example of Figure 12B, there are four users (1254, 1256, 1258, and 1260). Each pair of users can share a secret key 1262 (i.e., QKD) between themselves. Since there are four nodes in this example, there are six pairs of nodes, and therefore, QKD AB , QKD AC , QKD AD , QKD BC , QKD BD , and QKD CDSix different secret keys 1262 are used, including: Each pair can create QKD by using quantum particles such as photons to transmit information that cannot be copied by an eavesdropper without being corrupted. In this way, pairs of users can verify each other's identities.

[0143] The operation of the blockchain 1252 may be based on two steps: (i) transaction creation and (ii) building blocks that collect new transactions. New transactions may be created in the same way as in a traditional blockchain network. Each transaction may contain information about the sender, recipient, creation time, the amount (or value) being transferred, and a list of reference transactions that justify the sender having funds for the operation. This transaction record is then sent to all other nodes and entered into a pool of unconfirmed transactions. Here, two parties (i.e., a pair of users from 1254 to 1260) may authenticate the transaction by providing a shared secret key 1262 (QKD). This quantum signature is attached to every transaction, making it difficult to tamper with. Each node checks the transaction entry against its local copy of the blockchain 1252 and verifies that each transaction has sufficient funds. However, the transaction is not yet confirmed.

[0144] Rather than performing a traditional mining process on blocks, blocks may be created in a decentralized manner using a broadcast protocol. Over a predetermined period of time (e.g., seconds, minutes, hours, etc.), the network may apply the broadcast protocol to any unconfirmed transactions, thereby achieving Byzantine agreement (consensus) regarding the correct version of the transaction. For example, each node may possess a private value (that particular node's transaction data). First, the nodes send the private value to each other. Thereafter, the nodes communicate information previously received from other nodes. Now, an authentic node can create the complete set of transactions in a new block. This new block can be added to the blockchain 1252. In one embodiment, features and / or operations described and / or illustrated herein may occur in or with respect to the blockchain 1252.

[0145] Computer Program Products The present invention may be a system, method, or computer program product, or any combination thereof, at any possible level of technical detail of integration. The computer program product may include a computer-readable storage medium containing computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0146] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device, such as, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded devices such as punch cards or ridge-in-groove structures on which instructions are recorded, and any suitable combination thereof. As used herein, computer-readable storage media should not itself be construed as being ephemeral signals such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through fiber optic cable), or electrical signals transmitted over wires.

[0147] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or storage device over a network (e.g., a local area network, a wide area network, or a wireless network, or a combination thereof). This network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on a computer-readable storage medium within each computing / processing device.

[0148] Computer-readable program instructions for carrying out the operations of the present invention may be source or object code written in any combination of one or more programming languages, including assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages ​​such as Smalltalk®, C++, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, to carry out aspects of the present invention, electronic circuitry including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions to personalize the electronic circuitry by utilizing state information of the computer-readable program instructions.

[0149] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0150] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus to create a machine, where the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may be stored on a computer-readable storage medium and capable of directing a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions for performing aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0151] The computer-readable program instructions may be loaded into a computer, other programmable data processing apparatus, or other device to generate a computer-implemented process and cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device, such that the instructions, which execute on the computer, other programmable apparatus, or other device, perform the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0152] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, comprising one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may actually be realized as a single step, executed concurrently, substantially concurrently, partially or completely overlapping in time, or even executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart diagrams, and combinations of blocks included in the block diagrams and / or flowchart diagrams, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations or executes a combination of special-purpose hardware and computer instructions.

[0153] general Aspects of the present invention have been described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions. Moreover, the flowcharts and block diagrams within the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, comprising one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or may sometimes be executed in the reverse order, depending on the functionality involved. It is also noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks included in the block diagrams and / or flowchart illustrations, can be implemented by special-purpose hardware-based systems that perform the specified functions or operations or execute a combination of special-purpose hardware and computer instructions.

[0154] The names of specific programs used in this description are merely for convenience, and therefore the present invention should not be limited to use with only the particular application identified and / or implied by such names. Thus, for example, the routines executed to implement embodiments of the present invention could be referred to as a "program," "application," "server," or other meaningful name, whether implemented as part of an operating system or a specific application, component, program, module, object, or sequence of instructions. Indeed, other alternative hardware and / or software environments may be used without departing from the scope of the present invention.

[0155] The presently described embodiments are therefore considered in all respects to be illustrative and not restrictive, and reference should be made to the appended claims to determine the scope of the invention.

Claims

1. 1. A computer-implemented method for establishing consensus in a blockchain network, comprising: Providing a first Total Ordering Service (TOS) gateway to an organization in a blockchain network, the TOS gateway having read / write access to a shared message queue, the shared message queue making messages available to each other TOS gateway in the blockchain network; generating a symmetric key at the first TOS gateway; splitting the symmetric key to generate a plurality of key assignments; distributing at least one of the plurality of key assignments to a second TOS gateway in the blockchain network; 4. A computer-implemented method comprising:

2. 2. The computer-implemented method of claim 1, wherein the symmetric key is known only to a plurality of TOS gateways in the blockchain network.

3. storing at least one of the plurality of key assignments in a persistent memory; storing said symmetric key only in volatile memory; The computer-implemented method of claim 1 , further comprising:

4. receiving a transaction payload at the first TOS gateway; encrypting the transaction using the symmetric key; publishing the encrypted transaction to the shared message queue; The computer-implemented method of claim 1 , further comprising:

5. forming one or more blocks associated with the transaction; and autonomously signing the one or more blocks using a blockchain key; The computer-implemented method of claim 4 , further comprising:

6. 6. The computer-implemented method of claim 5, wherein the transaction payload cannot be read by an entity managing the shared message queue.

7. 6. The computer-implemented method of claim 5, further comprising adding the signed one or more blocks to a blockchain associated with the blockchain network.

8. requesting one of the key assignments from the second gateway in the blockchain network; reconstructing the symmetric key using said one of said key assignments; 2. The computer-implemented method of claim 1, further comprising recovering the symmetric key, the method comprising:

9. requesting the one of the key assignments from the second gateway; generating a temporary key pair at the first TOS gateway, the temporary key pair including a temporary private key and a corresponding temporary public key; publishing the corresponding temporary public key to the shared queue; receiving a temporary symmetric key from the second TOS gateway via the shared queue, the temporary symmetric key being generated in part using the corresponding temporary public key of the first TOS gateway; receiving, via the shared queue, the one of the key assignments from the second TOS gateway, wherein the one of the key assignments is encrypted using the temporary symmetric key; decrypting said one of said key assignments using said temporary symmetric key; Forgetting said temporary key pair; The computer-implemented method of claim 8 , comprising:

10. receiving, at the first TOS gateway, a request for the symmetric key from the second TOS gateway via the shared queue; and in response, receiving a corresponding temporary public key from the second TOS gateway; generating a temporary key pair, the temporary key pair including a temporary private key and a corresponding temporary public key of the first TOS gateway; generating a temporary symmetric key; encrypting the temporary symmetric key using the corresponding temporary public key from the second TOS gateway; encrypting a shared key using the temporary symmetric key; publishing the encrypted shared key to the shared queue; The computer-implemented method of claim 1 , further comprising:

11. 10. The computer-implemented method of claim 9, wherein the second TOS gateway is a new TOS gateway in the blockchain network.

12. receiving a channel reconfiguration message at the first TOS gateway; generating a temporary key pair at the first TOS gateway, the temporary key pair including a temporary private key and a corresponding temporary public key; publishing the corresponding temporary public key to the shared queue; receiving a key split from the second TOS gateway via the shared queue, the key split being encrypted using the corresponding temporary public key; decrypting the key split using the temporary private key; 2. The computer-implemented method of claim 1, further comprising rotating the symmetric key comprising:

13. 13. The computer-implemented method of claim 12, wherein the channel reconfiguration message is in response to a TOS gateway removal action.

14. A computer program product causing a computer to carry out a method according to any one of claims 1 to 13.

15. 15. A computer readable storage medium having recorded thereon the computer program of claim 14.

16. A computer program for a total ordering service in a blockchain network, comprising: A system for managing a blockchain network comprising: a plurality of total ordering service (TOS) gateways each associated with one of a plurality of member organizations in a blockchain network, the plurality of TOS gateways each comprising a processor operatively connected to a memory, the memory, when executed on the processor, generating a symmetric key at a first TOS gateway of the plurality of TOS gateways; Dividing the symmetric key into a plurality of key assignments; distributing at least one of the plurality of key assignments to a second TOS gateway in the blockchain network; comprising program instructions for executing A computer program product, comprising: a shared message queue adapted to redistribute the symmetric key to the plurality of TOS gateways in the blockchain network.

17. The plurality of TOS gateways, program instructions for receiving a transaction payload; program instructions for encrypting the transaction payload using the symmetric key; program instructions for publishing the encrypted transaction payload to the shared message queue; Further comprising:

17. The computer program product of claim 16, wherein the shared message queue is further adapted to redistribute the encrypted transaction payload to the multiple TOS gateways in the blockchain network, and wherein the shared message queue cannot read the transaction payload.

18. The plurality of TOS gateways, program instructions for storing one of the key assignments in persistent memory; program instructions for storing said symmetric key in only volatile memory; 20. The computer program product of claim 17, further comprising:

Images