Consensus service for a blockchain network

Abstract

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

Description

Background Technology

[0001] This disclosure pertains to the finalization and submission of transactions, and more specifically, to achieving consensus in a decentralized, distributed transaction processing system.

[0002] The development of the EDVAC system in 1948 is often considered the beginning of the computer age. Since then, computer systems have evolved into extremely complex devices. Today's computer systems typically consist of a combination of complex hardware and software components, applications, operating systems, processors, buses, memory, input / output devices, and more. Advances in semiconductor processing and computer architecture have pushed performance to ever-increasing levels, and even more advanced computer software has been developed to take advantage of these capabilities, making today's computer systems far more powerful than those of just a few years ago.

[0003] One area where computing systems have been successfully applied is transaction processing. Historically, centralized databases stored and maintained transaction data in special-purpose database programs running on a physical system located in one location. This location was typically a central computer, such as a server computer or mainframe. Centralized databases were relatively easy to maintain and manage, especially for security reasons, because they were a single point of control. Summary of the Invention

[0004] According to embodiments of this disclosure, a computer-implemented method for establishing consensus in a blockchain network is disclosed. One embodiment may include providing a first Total Ordering Service (TOS) gateway to an organization in the blockchain network, generating a symmetric key at the first TOS gateway, splitting the symmetric key to generate multiple key shares, and assigning at least one of the multiple key shares to a second TOS gateway in the blockchain network. In some embodiments, the TOS gateway may have read / write access to a shared message queue that makes messages available to every other TOS gateway in the blockchain network. Some embodiments may also include recovering the symmetric key by requesting one of the key shares from the second gateway in the blockchain network and reconstructing the symmetric key using one of the key shares.

[0005] According to embodiments of this disclosure, a computer program product for a confidential ordering service includes one or more computer-readable storage media and program instructions commonly stored on the one or more computer-readable storage media. The program instructions may include instructions for running a master ordering service gateway for each organization in a blockchain network, wherein each master ordering service gateway has read / write access to a shared message queue that distributes messages to each organization, identifies a group of organizations within an organization, and generates a channel including that group of organizations, wherein the group of organizations cooperates autonomously. The program instructions may also include instructions for generating a symmetric key known only to that group of organizations, dividing the symmetric key into shares associated with multiple organizations within that group, and storing the shares without storing the entire symmetric key.

[0006] According to embodiments of this disclosure, a total ordering service for a blockchain network is provided. One embodiment 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 suitable for redistributing symmetric keys among 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 containing program instructions that, when executed on the processor, generate a symmetric key in a first of the plurality of TOS gateways, divide the symmetric key into a plurality of key shares, and distribute at least one of the plurality of key shares to a second TOS gateway in the blockchain network.

[0007] The above overview is not intended to describe every illustrative embodiment or every implementation of this disclosure. Attached Figure Description

[0008] The accompanying drawings included in this application are incorporated in and form part of this specification. They illustrate embodiments of this disclosure and, together with the detailed description, serve to explain the principles of this disclosure. The drawings are merely illustrative of certain embodiments and do not limit the scope of this disclosure.

[0009] Figure 1 A data processing system consistent with some embodiments is described.

[0010] Figure 2 A cloud computing environment consistent with some implementations is described.

[0011] Figure 3 An abstract model layer consistent with some implementations is described.

[0012] Figure 4 This is a high-level diagram of a blockchain system consistent with some implementation examples.

[0013] Figure 5AAn example of a blockchain architecture configuration consistent with some implementations is depicted.

[0014] Figure 5B This describes a blockchain transaction process consistent with some of the embodiments.

[0015] Figure 6A A flowchart consistent with some embodiments is provided.

[0016] Figure 6B Further flowcharts consistent with some embodiments are illustrated.

[0017] Figure 6C An example system, consistent with some embodiments, is described and configured to perform one or more operations as described herein.

[0018] Figure 6D Another example system is described, which is consistent with some embodiments and configured to perform one or more operations described herein.

[0019] Figure 6E This describes another example system configured to utilize smart contracts, consistent with some embodiments.

[0020] Figure 6F A system including a blockchain, consistent with some embodiments, is described.

[0021] Figure 7A and Figure 7B This describes a method for creating a channel that is consistent with some embodiments.

[0022] Figure 8 This describes a method for recovering a symmetric key from a Total Ordering Service Gateway (TOS Gateway), consistent with some embodiments.

[0023] Figure 9 This is a flowchart illustrating a method 900 for expanding membership in a blockchain, consistent with some embodiments.

[0024] Figure 10A and Figure 10B A method for rotating keys consistent with some embodiments is described.

[0025] Figure 11A This describes the process of adding a new block to the distributed ledger according to the example embodiment.

[0026] Figure 11B The contents of the new data block according to the example embodiment are described.

[0027] Figure 11C This describes a blockchain for digital content based on an example embodiment.

[0028] Figure 11DA box illustrating the structure of a block in a blockchain, according to an example embodiment, is provided.

[0029] Figure 12A An example blockchain for storing machine learning (artificial intelligence) data is described according to an example embodiment.

[0030] Figure 12B An example quantum-safe blockchain is described according to an example embodiment.

[0031] While the invention can be used in various modifications and alternatives, its specific details have been shown by way of example in the accompanying drawings and can be described in detail. However, it should be understood that the invention is not intended to be limited to the specific embodiments described. Rather, the invention is intended to cover all modifications, equivalents, and alternatives. Detailed Implementation

[0032] This disclosure relates to various aspects of finalizing and submitting transactions; more specifically, it relates to achieving consensus in decentralized, distributed transaction processing systems. While this disclosure is not necessarily limited to such applications, its aspects can be understood through discussion of various examples using this context.

[0033] Decentralized databases generally refer to distributed storage systems where multiple nodes collaborate to store and / or provide access to data. A blockchain is an example of a decentralized database; it typically comprises an append-only, immutable data structure similar to a distributed ledger, capable of maintaining records between mutually distrustful / untrusted parties. These mutually distrustful / untrusted parties are referred to herein as peers or peer nodes.

[0034] In some blockchain implementations, each peer maintains a copy of the distributed database records, and no single peer can modify a distributed database record without consensus among them. In other implementations, peers can execute consensus protocols to confirm blockchain transactions, grouping these transactions into blocks and building hash chains on the blocks. This process can create a distributed ledger by ordering stored transactions for consistency.

[0035] In public or permissionless blockchain implementations, anyone can participate without specific authorization. In contrast, permissioned blockchain implementations provide a system that ensures interaction between a group of authorized entities with common goals but who do not fully trust each other, such as in the exchange of funds, goods, information, and other transactions.

[0036] Some blockchain implementations can operate on arbitrary, programmable logic, tailored for decentralized storage solutions such as "smart contracts" and "chaincode." In some of these implementations, specialized chaincode may reside in administrative functions and parameters; this is referred to as system chaincode. Smart contracts are trusted, distributed applications that leverage the tamper-proof nature of blockchains and the underlying protocols between nodes (often referred to as endorsement or endorsement policies).

[0037] In some embodiments, blockchain transactions can be "endorsed" before being submitted to the blockchain, and transactions that are not "endorsed" can be ignored. An endorsement policy consistent with some embodiments allows chaincode to specify endorsers for a transaction in the form of a set of peer nodes required for endorsement. When a client sends a transaction to the peers specified in the endorsement policy, the transaction can be executed to verify it. After confirmation, the transaction can enter a sorting phase, where a consensus protocol is used to generate an ordered sequence of endorsed transactions that are grouped into blocks.

[0038] In some blockchain embodiments, nodes can act as communication entities within the blockchain system. In these embodiments, a "node" can perform a logical function, and in a sense, multiple nodes of different types can run on the same physical server. Nodes can be grouped within trust domains and can be associated with logical entities that control them in various ways. Nodes can also include different types, such as client or submitting client nodes that submit transaction requests to endorsers (e.g., peers) and ordering nodes that broadcast transaction proposals to an ordering service. However, another type of node is the peer node, which can receive transactions submitted by clients, submit transactions, and maintain a copy of the state and ledger of blockchain transactions. In some embodiments, peer nodes may also have an endorser role, although this is not a requirement.

[0039] In some embodiments, the sorting service node (or "sorter") may run communication services and implement delivery guarantees for all nodes, such as broadcasting to every peer in the system when a transaction is submitted and the world state of the blockchain is modified. In some embodiments, the world state may include the initial blockchain transaction, which typically includes control and setup information.

[0040] However, some users of blockchain technology may be reluctant to host ordering nodes. This could be due to the inherent security risks of exposing endpoints to the public internet, and many users lack the technical expertise, attention, and resources required to manage these risks. Furthermore, leader-based consensus protocols without rotation can lead to uneven distribution of network bandwidth. This could cause some users to waste computation, disk I / O, and network bandwidth on transactions that don't involve them. Other users may also be concerned about regulatory compliance, service level agreements, etc., especially if a particular blockchain implementation does not include economic incentives for running ordering nodes.

[0041] Conversely, challenges may also arise when forming a blockchain network with a consensus service hosted by a third party (e.g., not one of the parties recording a large number of transactions on the blockchain). For example, if the ordering service is run by a third party, the third party may have access to the blockchain content because the ordering service essentially creates the blocks itself, and newly brought nodes need to parse the blocks to catch up with the state of the blockchain. However, this can have undesirable side effects such as: (i) the third party may be able to see all transactions across all channels clearly (e.g., unencrypted), and therefore may have access to confidential and / or sensitive information; (ii) if the parties to the blockchain network wish to migrate to a new ordering service provider, cooperation from the third-party ordering service may be required, but since this is a non-difficult task, it raises the risk of perpetual vendor lock-in.

[0042] Therefore, some embodiments of this disclosure enable organizations that cannot host ordering service nodes to create blockchain networks. These blockchain networks may include a confidential total ordering service (TSO), which in some embodiments can receive and forward encrypted transaction payloads from multiple total ordering service gateways (TSO gateways).

[0043] Data processing system

[0044] Figure 1 An embodiment of a data processing system (DPS) 100a consistent with some embodiments is described. The DPS 100a in this embodiment can be implemented as a personal computer; a server computer; a portable computer, such as a laptop or notebook computer, a PDA (personal digital assistant), a tablet computer, or a smartphone; a processor embedded in a larger device (such as a car, airplane, teleconferencing system, or appliance); a smart device; or any other suitable type of electronic device. Furthermore, except... Figure 1 Besides the components shown, there may be other components, and the number, type, and configuration of these components may vary. Furthermore, Figure 1 Only representative major components of the DPS 100a are depicted; the complexity of individual components may be greater than described. Figure 1 It represents something larger.

[0045] Figure 1 The data processing system 100a includes multiple central processing units 110a-110d (generally referred to herein as processor 110 or CPU 110) connected via a system bus 122 to a 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 read / write optical disc drive 142. The network interface 118 allows DPS 100a to communicate with other DPS 100b via a communication medium 106. The memory 112 also contains an operating system 124, multiple application programs 126, and program data 128.

[0046] Figure 3 The data processing system 100a embodiment is a general-purpose computing device. Therefore, the processor 110 can be any device capable of executing program instructions stored in the memory 112, and can itself be composed of one or more microprocessors and / or integrated circuits. In this embodiment, the DPS 100a includes multiple processors and / or processing cores, which is typical of larger, more powerful computer systems; however, in other embodiments, the computing system 100a may include a single-processor system and / or a single processor designed to simulate a multiprocessor system. Furthermore, the processor 110 can be implemented using some heterogeneous data processing system 100a, where the main processor and secondary processors reside on a single chip. As another illustrative example, the processor 110 can be a symmetric multiprocessor system containing multiple processors of the same type.

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

[0048] Instructions for the operating system, applications, and / or programs (generally 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, and communicate with processor 110 via system bus 122. The program code in different 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. Figure 3 In the illustrative example, instructions are stored in a functional form as persistent storage on direct access storage device 140. These instructions are then loaded into memory 112 for execution by processor 110. However, program code may also reside in a functional form on computer-readable medium 142, which may be selectively removed and may be loaded onto or transferred to DPS 100a for execution by processor 110.

[0049] System bus 122 can be any means that facilitates communication between processor 110, memory 112, and interfaces 114, 116, 118, 120. Furthermore, although system bus 122 in this embodiment is a relatively simple single-bus structure providing a direct communication path between system buses 122, other bus structures consistent with this disclosure include, but are not limited to, hierarchical, star, or network-configured point-to-point links, multiple hierarchical buses, parallel and redundant paths, etc.

[0050] Memory 112 and mass storage devices 140, 141, and 142 work together to store operating system 124, application program 126, and program data 128. In this embodiment, memory 112 is a random access semiconductor device capable of storing data and programs. Although Figure 3 Conceptually, the device is depicted as a single, monolithic entity, but in some embodiments, memory 112 may be arranged in a more complex manner, such as a hierarchical structure of caches and other memory devices. For example, memory 112 may contain multiple hierarchical caches, which may also be functionally partitioned so that one cache holds instructions while another holds non-instruction data used by one or more processors. Memory 112 may also be distributed and associated with different processors 110 or sets of processors 110, as is known in various so-called Non-Uniform Memory Access (NUMA) computer architectures. Furthermore, some embodiments may utilize virtual addressing mechanisms that allow DPS 100a to behave as if it could access a large, single storage entity rather than multiple, smaller storage entities such as memory 112 and mass storage devices 140, 141, 142.

[0051] Although the operating system 124, application program 126, and program data 128 are described as being contained within memory 112, in some embodiments, some or all of them may be physically located on different computer systems and may be remotely accessed, for example, via communication medium 106. Therefore, while the operating system 124, application program 126, and program data 128 are described as being contained within memory 112, these elements are not necessarily all contained in the same physical device simultaneously, and may even reside in the virtual memory of other DPS 100b.

[0052] System interfaces 114, 116, 118, and 120 support communication with various storage and I / O devices. Mass storage interface 114 supports connection to one or more mass storage devices 140, 141, and 142, which are typically spinning disk drive storage devices, solid-state storage devices (SSDs) that use integrated circuit assemblies as memory for continuous data storage, typically using flash memory, or a combination of both. However, mass storage devices 140, 141, and 142 may also include other devices, including disk drive arrays (often called RAID arrays) and / or archival storage media configured as a single large storage device to the host, such as hard disk drives, magnetic tapes (e.g., mini-DV), writable compact optical discs (e.g., CD-R and CD-RW), digital versatile optical discs (e.g., DVD, DVD-R, DVD+R, DVD+RW, DVD-RAM), holographic storage systems, Blue LaserDiscs, IBM Millipede devices, etc.

[0053] Terminal / display interface 116 is used to directly connect one or more display units (such as monitor 180) to data processing system 100a. These display units 180 may be non-intelligent (i.e., dumb) terminals, such as LED displays, or fully programmable workstations that allow IT administrators and customers to communicate with DPS 100a. However, note that while display interface 116 is provided to support communication with one or more display units 180, computer system 100a does not necessarily require display units 180, as all interactions with customers and other processes can occur through network interface 118.

[0054] Communication medium 106 can be any suitable network or combination of networks and can support any appropriate protocol suitable for data and / or code communication with multiple DPS 100a, 100b. Therefore, network interface 118 can be any device conducive to such communication, regardless of whether the network connection uses today's analog and / or digital technologies or is made via some future network mechanism. Suitable communication medium 106 includes, but is not limited to, networks implemented using one or more "InfiniBand" or IEEE (Institute of Electrical and Electronics Engineers) 802.3x "Ethernet" specifications; cellular transport networks; wireless networks implemented using one of the IEEE 802.11x, IEEE 802.16, General Packet Radio Service ("GPRS"), FRS (Family Radio Service), or Bluetooth specifications; ultra-wideband ("UWB") technologies such as those described in FCC 02-48, or similar content. Those skilled in the art will understand that many different network and transport protocols can be used to implement communication medium 106. The Transmission Control Protocol / Internet Protocol ("TCP / IP") suite contains suitable network and transport protocols.

[0055] cloud computing

[0056] Figure 2 A cloud environment comprising one or more DPS 100a is illustrated, consistent with some embodiments. It should be understood that although this disclosure includes a detailed description of cloud computing, implementation of the teachings set forth herein is not limited to a cloud computing environment. Rather, embodiments of the invention can be implemented in conjunction with any other type of computing environment now known or developed hereafter.

[0057] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with service providers. This cloud model may include at least five features, at least three service models, and at least four deployment models.

[0058] The characteristics are as follows:

[0059] On-demand self-service: Cloud consumers can unilaterally and automatically provide computing power, such as server time and network storage, as needed, without requiring manual interaction with the service provider.

[0060] Wide Area Network (WAN) Access: Capabilities are available on the network and accessed through standard mechanisms that facilitate the use of heterogeneous thin or thick client platforms, such as mobile phones, laptops, and PDAs.

[0061] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated based on demand. Location independence has significance because consumers typically do not control or know the exact location of the resources provided, but can specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0062] Rapid Flexibility: In some cases, the ability to scale outwards and inwards quickly and flexibly can be provided. For consumers, the available capacity often appears unlimited and can be purchased in any quantity at any time.

[0063] Measurement services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the service type (e.g., storage, processing, bandwidth, and active customer accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the providers and consumers of the services being used.

[0064] The service model is as follows:

[0065] Software as a Service (SaaS): This provides consumers with the ability to use the provider's applications running on cloud infrastructure. Applications can be accessed from various client devices through thin client interfaces such as web browsers (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, storage, or even individual application capabilities, with the possible exception of limited client-specific application configuration settings.

[0066] Platform as a Service (PaaS): This provides consumers with the ability to deploy consumer-created or acquired applications, built using provider-supported programming languages ​​and tools, onto cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they have control over the deployed applications and the configuration of possible application hosting environments.

[0067] Infrastructure as a Service (IaaS): The capabilities provided to consumers are processing, storage, networking, and other basic computing resources that enable consumers to deploy and run arbitrary software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but have control over the operating system, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0068] The deployment model is as follows:

[0069] Private cloud: Cloud infrastructure operated solely by an organization. It can be managed by the organization or a third party and can exist on-site or off-site.

[0070] Community cloud: A cloud infrastructure shared by several organizations and supporting specific community requirements, policies, and compliance considerations with shared concerns (e.g., tasks, security). It can be managed by an organization or a third party and can exist on-site or off-site.

[0071] Public cloud: Cloud infrastructure available to the general public or large industrial groups and owned by organizations that sell cloud services.

[0072] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain a single entity but are bound together by standardized or proprietary technologies that enable data and applications to be ported together (e.g., cloud bursting for load balancing between clouds).

[0073] Cloud computing environments are service-oriented, focusing on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is the infrastructure of a network of interconnected nodes.

[0074] Now for reference Figure 2 The figure depicts an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 that can communicate with local computing devices used by cloud consumers, such as personal digital assistants (PDAs) or cellular phones 54A, desktop computers 54B, laptop computers 54C, and / or automotive computer systems 54N. Nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as the aforementioned private cloud, community cloud, public cloud, or hybrid cloud, or combinations thereof. This allows the cloud computing environment 50 to provide cloud consumers with infrastructure, platform, and / or software as a service that eliminates the need for them to maintain resources on their local computing devices. It is understood that the types of computing devices 54A-54N shown in the figure are merely illustrative, and the computing nodes 10 and the cloud computing environment 50 can communicate with any type of computing device via any network and / or network addressable connection type (e.g., using a web browser).

[0075] Now for reference Figure 3 This demonstrates the 50 (cloud computing environment) Figure 2 This provides a set of functional abstractions. It should be understood beforehand that... Figure 2 The components, layers, and functions shown are for illustrative purposes only, and embodiments of the invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

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

[0077] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual server 71; virtual storage device 72; virtual network 73, including virtual private network; virtual application and operating system 74; and virtual client 75.

[0078] In one example, management layer 80 may provide the following functionalities: Resource Provisioning 81 provides dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and Pricing 82 provides cost tracking as resources are utilized within the cloud computing environment and bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. User Portal 83 provides access to the cloud computing environment for consumers and system administrators. Service Level Management 84 provides cloud resource allocation and management to ensure that required service levels are met. Service Level Agreement (SLA) Planning and Fulfillment 85 provides pre-scheduling and procurement of cloud resources, anticipating future requirements for those resources according to the SLA.

[0079] Workload tier 90 provides examples of functionalities that can leverage a cloud computing environment. Examples of workloads and functionalities that can be provided from this tier include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics and processing 94; transaction processing 95; and sorting services 96.

[0080] Blockchain system

[0081] Figure 4 This is a high-level diagram of a blockchain system 400 consistent with some implementations. Figure 4 In this embodiment, each member organization of the blockchain-using group (A, B, and C for illustrative purposes) can run a Total Ordering Service Gateway (TOS Gateway) G. A G B G C This allows it to be further deployed as a cluster or cloud service within member organizations A, B, and C of a group. TOS Gateway G A G B G C Each of them can have read / write access to the Total Sort Service (TSO), which can be maintained by a third-party service provider.

[0082] In some embodiments, the Total Ordering Service (TOS) can maintain a shared message queue 450, which can be used to publish messages to all participants in the blockchain community. For channels spanning subsets of organizations A, B, etc., the TOS gateway G... A G B They can autonomously collaborate to create a symmetric key K known only to a subset of organizations A, B, etc.; then they split the shared key (i.e., symbolically, (K)). A ,K B (etc.) ←Split(K)); Distribute a portion of the symmetric key and key share to other TOS gateways; then only distribute key share K. A K B The shared symmetric key K (rather than the symmetric key K itself) is stored in non-volatile memory. In contrast, in some embodiments and implementations, the shared symmetric key K may be maintained only in volatile memory (e.g., RAM).

[0083] Then, TOS gateway G A、 G B、 G C It can receive internal clients C from group member organizations A, B, and C. A C B C C The transactions are processed; these transactions are encrypted using a shared symmetric key K; a total ordering of the encrypted transactions is established; the total ordering of transactions is decrypted and blocks are formed; each transaction self-signs the block using its own long-term private blockchain key; and the block is broadcast within its organizations A, B, and C. In some embodiments, the TOS gateway G... A、 G B、 G C They can know each other's public certificates and use them for signature verification (in some embodiments, all protocol messages can be signed). Furthermore, in some embodiments and / or implementations, as will be discussed in more detail with reference to Figures 7-10, the TOS gateway G... A、 G B、 G C These keys can also be rotated autonomously, such as in the event of member reconfiguration.

[0084] Figure 4 In the embodiments, the total sorting service TOS does not require and is typically not accessible to the internal client C. A C BUnencrypted transaction information generated by Cc. That is, some embodiments of this disclosure can protect the confidentiality of groups and group organizations A, B, and C because the total ranking service TOS cannot know anything about the data it is processing, even when executed by a third party. Thus, the organization providing the total ranking service TOS need not be a member of a trusted group, but can be an unrelated third party, such as a cloud computing service provider. Therefore, some embodiments of this disclosure may include a blockchain with a delegated total ranking service that: (i) enables the total ranking service to be run by a third party; and (ii) does not disclose any confidential or other form of transaction information to that third party.

[0085] In some embodiments, a third party running the Total Ordering Service (TOS) can also be used as a persistent total ordering messaging service. Advantageously, this can allow a restricted TOS gateway G A G B G C It only provides the ability to send messages, receive messages in the same order, and not delete messages.

[0086] Another feature and advantage of some embodiments is that they may require relatively low administrative overhead because blockchain operations can be completely autonomous. This, in turn, allows for a relatively smooth blockchain experience for group members A, B, C, etc.

[0087] In some embodiments, the Total Ordering Service (TOS) can additionally provide fairness in resource allocation among members of the blockchain community, as the process typically involves uploading transactions and downloading them to the shared message queue 450. However, since downloading is merely an aggregation of uploads, internal clients C from each organization A, B, and C... A C B Cc can simply pay the fee to upload the transaction to the total sorting service TOS, and it implicitly specifies the downloads for all organizations A, B, and C.

[0088] Additionally, some embodiments may include one or more of the following security features: (i) autonomous operation to remove human elements from the equation; (ii) resistance to collusion between the Total Ordering Service (TOS) and a fraudulent administrator with access to the file system of its local TOS gateway; (iii) a key establishment protocol that can be modified to use quantum-resistant schemes in addition to conventional schemes, thereby achieving forward secrecy in the presence of a quantum computer; and (iv) different keys for different channels, and therefore not requiring complete trust in each other organization to properly protect those keys.

[0089] Distributed ledger

[0090] In some embodiments, the distributed ledger can be an ordered, tamper-proof record of all state transitions of a blockchain. State transitions can be generated by chaincode calls (i.e., transactions) submitted by participants (e.g., client nodes, sorting nodes, endorsing nodes, peer nodes, etc.). Transactions, in turn, result in a set of asset key-value pairs being submitted to the distributed ledger as one or more operands, such as create, update, delete, etc. The distributed ledger can include a blockchain (also called a chain) used to store immutable, ordered records in blocks. The distributed ledger can also include a state database that maintains the current state of the blockchain. Some embodiments use one distributed ledger per channel, but other embodiments are also possible. In these embodiments, each peer node maintains a copy of the distributed ledger for each channel in which they are a member.

[0091] In some embodiments, the chain may include a transaction log, which can be constructed as hash-linked blocks, with each block containing a sequence of N transactions, where N is equal to or greater than one. The block header may include the hashes of the block's transactions and the hashes of the headers of preceding blocks. In this way, all transactions on the ledger can be ordered and cryptographically linked together. Therefore, in these embodiments, it is impossible to tamper with the ledger data without breaking the hash links. The hash of the most recently added blockchain block represents every transaction on the chain that arrived before it, ensuring that all peer nodes are in a consistent and trusted state. The chain can be stored on a peer node file system (i.e., local, attached storage, cloud, etc.), thus efficiently supporting the append-only nature of blockchain workloads.

[0092] In some embodiments, the current state of the immutable ledger can represent the latest value of all keys included in the chain's transaction log. Because the current state represents the most recent key value known to the channel, it is sometimes referred to as the world state. Chaincode calls execute transactions against the ledger's current state data. To make these chaincode interactions effective, the latest value of the key can be stored in a state database. In some embodiments, the state database can simply be an indexed view of the chain's transaction log, and therefore can be regenerated from the chain at any time. The state database can be automatically restored (or generated if needed) when peers start up and before transactions are accepted.

[0093] Blockchain architecture

[0094] Figure 5AA blockchain architecture configuration 500 consistent with some embodiments is shown. The blockchain architecture 500 in these embodiments may include certain blockchain elements, such as a group of blockchain nodes 502. This group of blockchain nodes 502 may in turn include one or more member nodes 504-510 (these four nodes are described by way of example only). These member nodes 504-510 may participate in various activities, such as the blockchain transaction addition and confirmation process (consensus). One or more of the member nodes 504-510 may endorse transactions based on an endorsement policy and may provide ordering services for all blockchain nodes in the architecture 500. Member nodes 504-510 may initiate blockchain authentication and attempt to write to the immutable blockchain ledger stored in blockchain layer 516, a copy of which may also be stored on the underlying physical infrastructure 514.

[0095] 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 sought by participants and can maintain its own state, control its own assets, and receive external information. The stored program / application code 520 can be deployed as transactions and installed on all blockchain nodes 504-510 via attachment to the distributed ledger.

[0096] The blockchain foundation or platform 512 may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and the underlying physical computer infrastructure used to receive and store new transactions and provide access to auditors attempting to access data entries. The blockchain layer 516 may expose interfaces providing access to the processing code and the virtual execution environment required to use the physical infrastructure 514. The cryptographic trust service 518 can be used to verify transactions such as asset exchange transactions and maintain information privacy.

[0097] Figure 5AThe blockchain architecture configuration can process and execute program / application code 520 through one or more interfaces exposed by the blockchain platform 512 and services provided by the blockchain platform 512. Program / application code 520 can control blockchain assets. For example, code 520 can store and transmit data and can be executed by member nodes 504-510 in the form of smart contracts and associated chaincode with conditions or other code elements subject to their execution. As a non-limiting example, smart contracts can be created to execute reminders, updates, and / or comply with other notifications such as changes and updates. The smart contract itself can be used to identify authorization and access requirements related to the ledger and the use of associated rules. For example, document attribute information 526 can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 516. Result 528 can include multiple linked shared documents. Physical infrastructure 514 can be used to retrieve any data or information described herein.

[0098] In some embodiments, smart contracts can be created via high-level applications 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, which can be executed in response to the fulfillment of conditions associated with the smart contract. Execution of a smart contract can trigger trusted modifications to the state of the digital blockchain ledger. In some embodiments, modifications to the blockchain ledger caused by the execution of a smart contract can be automatically replicated throughout the distributed network of blockchain peers via one or more consensus protocols.

[0099] Smart contracts can write data to the blockchain in key-value pair format. In some embodiments, the smart contract code can also read values ​​stored in the blockchain and use them in application operations. In these embodiments, the smart contract code can then write the output of various logical operations to the blockchain. In some embodiments, the smart contract code can be used to create temporary data structures in a virtual machine or other computing platform. In these embodiments, the data written to the blockchain can be public or can be encrypted and maintained as private. Temporary data used / generated by the smart contract can be maintained in memory by the provided execution environment and then deleted once the data required by the blockchain is identified.

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

[0101] Figure 5B An example of a blockchain transaction flow 550 between nodes of a blockchain according to some embodiments is shown. The transaction flow in these embodiments may include a transaction proposal 591 sent by an application client node 560 to an endorsing peer node 581. The endorsing peer 581 may verify the client signature and execute chaincode functions to initiate the transaction. The output may include the chaincode result, a set of key / value versions read from the chaincode (read set), and a set of key / value versions written to the chaincode (write set). If approved, a proposal response 592 is then sent back to the client 560 along with the endorsing signature.

[0102] In response, client 560 can aggregate endorsements into transaction payload 593 and broadcast it to ordering service node 584. Ordering service node 584 can then deliver the ordered transactions as blocks to all peers 581-583 on the channel. Each peer 581-583 can confirm the transaction before it is committed to the blockchain. For example, in some embodiments, peers can check the endorsement policy to ensure that the correct allocation of the designated peer has signed the result and verified the signature against transaction payload 593.

[0103] Continue to refer to Figure 5B In some embodiments, client node 560 can initiate transaction 591 by constructing a request and sending it to peer node 581, which can act as an endorser. Client 560 may include an application utilizing a supporting software development kit (SDK) that can leverage available APIs to generate transaction proposals. In turn, a transaction proposal may be a request to invoke chaincode functions to read and / or write data to the distributed ledger (i.e., write new key-value pairs of assets). The SDK may be used to fill in the transaction proposal into an appropriate architectural format (e.g., a protocol buffer on a remote procedure call (RPC)) and to use the client's cryptographic credentials to generate a unique signature for the transaction proposal.

[0104] In response, the endorsing peer 581 can verify that: (a) the transaction proposal is well-formed; (b) no transaction has been submitted in the past (replay attack protection); (c) the signature is valid; and (d) the submitter (client 560 in this example embodiment) is correctly authorized to perform the proposed operation on the channel. The endorsing peer 581 can input the transaction proposal as arguments to the invoked chaincode function. Chaincode can then be executed on the current state database to produce transaction results, including response values, a read set, and a write set. In some embodiments, the ledger is not updated at this time. Instead, the set of values, along with the signature of the endorsing peer 581, can be passed back to the client 560's SDK as a proposal response 592, which parses the payload the application wants to consume.

[0105] In response, the application on client 560 can check / verify the signature of the endorsing peer and can compare the proposal response to determine if they are identical. If the chaincode only queries the ledger, the application can check the query response and will generally not submit the transaction to the ordering service 584. If the client application intends to submit the transaction to the ordering service 584 to update the ledger, the application can determine whether the specified endorsement policy has been satisfied before submission (i.e., whether all peer nodes necessary for the transaction have endorsed the transaction). Here, the client may include only one of the parties in the transaction. In this case, each client may have its own endorsement node, and each endorsement node will be required to endorse the transaction. This architecture ensures that even if the application chooses not to check the response or otherwise forwards unendorsed transactions, the endorsement policy will still be enforced by the peers and supported during the submission confirmation phase.

[0106] After a successful check, in operation 594, client 560 can aggregate endorsements into a transaction and broadcast the transaction proposal and response to ordering service 584 within the transaction message. A transaction can contain a read / write set, the signatures of the endorsing peers, and the channel ID. Ordering service 584 does not need to examine the entire contents of a transaction to execute its operation; instead, it can simply receive transactions from all channels in the network, order them by channel in chronological order, and create a transaction block for each channel.

[0107] Blocks of transactions can be delivered from the sorting service 584 to all peer nodes 581-583 on the channel. Transactions within a block can be verified to ensure that any endorsement policy is met and to ensure that there have been no changes to the ledger state of the read set variables since the read set was generated by the transaction execution. Transactions in a block can be marked as valid or invalid. Furthermore, in operation 595, each peer node 581-583 can append a block to the channel's chain, and for each valid transaction, the write set is committed to the current state database. Events can be emitted to notify client applications that the transaction (call) has been immutably appended to the chain and to indicate whether the transaction is valid or invalid.

[0108] Permissioned blockchain

[0109] Figure 6A An example of a permissioned blockchain network consistent with some embodiments is shown, characterized by a distributed, decentralized peer-to-peer architecture. In this example, blockchain user 602 can initiate transactions on a permissioned blockchain 604. In this example, transactions can be deployments, invocations, or queries, and can be issued via client-side applications utilizing the SDK, directly through APIs, etc. The network can provide access to regulators 606 (such as auditors). Blockchain network operator 608 manages member permissions, such as registering regulator 606 as an "auditor" and blockchain user 602 as a "client." Auditors can be restricted to querying only the ledger, while clients can be authorized to deploy, invoke, and query certain types of chaincode.

[0110] In some embodiments, blockchain developer 610 can write chaincode and client applications. In these embodiments, blockchain developer 610 can deploy the chaincode directly to the network via an interface. To include credentials from traditional data source 612 in the chaincode, developer 610 can use out-of-band connections to access the data. In this example, blockchain user 602 can connect to an authorized blockchain 604 via peer node 614. Before any transaction is made, peer node 614 can obtain the user's registration and transaction credentials from a certificate authority 616 that manages user roles and permissions. In some embodiments, blockchain users must possess these digital credentials to transact on the authorized blockchain 604. In other embodiments, blockchain users can use other technologies for authentication, such as via a distributed trust chain. Simultaneously, it may be necessary for users attempting to utilize the chaincode to verify their credentials on traditional data source 612. The chaincode can use out-of-band connections to this data via a traditional processing platform 618 to confirm the user's authorization.

[0111] Figure 6BAnother example of a permissioned blockchain network consistent with some embodiments is shown, characterized by a distributed, decentralized peer-to-peer architecture. For example, blockchain user 622 can submit transactions to a permissioned blockchain 614. In this example, transactions can be deployments, invocations, or queries, and can be issued via client-side applications utilizing the SDK, directly through APIs, etc. The network can provide access to regulators 626 (such as auditors). Blockchain network operator 628 manages member permissions, such as registering regulator 626 as an "auditor" and blockchain user 622 as a "client." Auditors can be restricted to querying only the ledger, while clients can be authorized to deploy, invoke, and query certain types of chaincode.

[0112] In these embodiments, blockchain developer 631 can write chaincode and client applications. Blockchain developer 631 can deploy the chaincode directly to the network via an interface. To include credentials from traditional data source 632 in the chaincode, developer 631 can use an out-of-band connection to access the data. In this example, blockchain user 622 connects to the network via peer node 634. Before any transaction is made, peer node 634 obtains the user's registration and transaction certificates from certificate authority 636. In some embodiments, blockchain users must possess these digital certificates to transact on the authorized blockchain 624. In other embodiments, blockchain users can use other technologies for authentication, such as via a distributed trust chain. Meanwhile, users attempting to utilize the chaincode can be required to verify their certificates on traditional data source 632. The chaincode can use an out-of-band connection to the data via traditional processing platform 618 to confirm the user's authorization.

[0113] Figure 6C An example system, consistent with some embodiments, includes physical infrastructure 611 configured to perform various operations. References Figure 6C Physical infrastructure 611 includes modules 688 and 689. Module 619 includes a blockchain 620 and a smart contract 630 (which may reside on the blockchain 620) capable of executing any operational step 678 (in module 688) included in any example embodiment. Step / operation 678 may include one or more embodiments described or depicted and may represent output or write information written or read from one or more smart contracts 630 and / or blockchain 620. Physical infrastructure 611, module 688, and module 689 may include one or more computers, servers, processors, memory, and / or wireless communication devices. Furthermore, module 688 and module 689 may be the same module.

[0114] Figure 6D Another example system, configured to perform various operations consistent with some embodiments, is shown. (Reference) Figure 6D The system includes modules 692 and 694. Module 694 includes a blockchain 620 and a smart contract 630 (which may reside on the blockchain 620) capable of performing any operational step 678 (in module 692) included in any example embodiment. Step / operation 678 may include one or more embodiments described or depicted, and may represent output or write information written or read from one or more smart contracts 630 and / or blockchain 620. Physical modules 692 and 694 may include one or more computers, servers, processors, memory, and / or wireless communication devices. Furthermore, modules 692 and 694 may be the same module.

[0115] Figure 6E An exemplary system, consistent with some embodiments, is shown, configured to utilize smart contract configurations between contracting parties, and an intermediary server configured to enforce smart contract terms on blockchain 620. References Figure 6E This configuration can represent a communication session, an asset transfer session, or a process or routine driven by smart contract 630, which explicitly identifies one or more user devices 652 and / or 656. The execution, operation, and results of smart contract execution can be managed by server 654. The content of smart contract 630 may require digital signatures by one or more entities 652 and 656, which are parties to the smart contract transaction. The results of smart contract execution can be written to blockchain 620 as a blockchain transaction. Smart contract 630 resides on blockchain 620, which can reside on one or more computers, servers, processors, memory, and / or wireless communication devices.

[0116] Figure 6F A system 660 incorporating blockchain, consistent with some embodiments, is shown. (Reference) Figure 6D As an example, Application Programming Interface (API) Gateway 662 provides a public interface for accessing blockchain logic (e.g., smart contract 630 or other chaincode) and data (e.g., distributed ledger, etc.). In this example, API Gateway 662 is a public interface for executing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 652 and 656 to a blockchain peer (i.e., server 654). Here, server 654 is a blockchain network peer component that maintains a copy of the world state and the ledger, allowing clients 652 and 656 to query world state data and submit transactions to the blockchain network, where, according to smart contract 630 and the endorsement policy, the endorsing peer will run smart contract 630.

[0117] Channel creation

[0118] Figure 7A and7B (Collectively referred to as Figure 7) illustrates a method 700 for creating a channel in a blockchain network, consistent with some embodiments. In operation 710, the blockchain administrator sends an instruction to the TOS gateway G. A Send the channel creation transaction message (tx). In operation 720, TOS gateway G A A response can be made by publishing a channel initialization message (“CHAN INIT BEGIN”) to shared message queue 450. In operation 730, TOS gateways G, associated with organizations B and C respectively... B G C This message can be received from the Total Sort Service (TOS). In operation 732, as a response, each receiving TOS gateway G... B G C It can generate a random temporary private key and a corresponding public key P. B P C Then, in operation 734, the public key P can be... B P C Publish to shared message queue 450.

[0119] Next, in operation 740, the TOS gateway G of organization A. A A random symmetric key K can be generated. In operation 742, the generated key K can be divided into "t" shares (three shares in this example, for each TOS gateway G in the blockchain). A G B G C One share). Then, TOS gateway G A Key shares can be allocated to other TOS gateways. This can include splitting the key P into segments when operating 744 encryption on other gateways. B (K) B ), P C (K) C ), and the password text generated during operation 746. During operation 750, each other TOS gateway G B G C It is possible to decrypt its key share (K) B K C (etc.), and in operation 752, the decrypted key share along with a portion of its symmetric key H(K) is stored in its local persistent storage. Alternatively, as will be described in detail below, each TOS gateway G A G B G C You can generate your own key share from a symmetric key.

[0120] In operation 760, each other TOS gateway G B G CA CHAN INIT END message can be published, and then its temporary private key can be forgotten (i.e., deleted). In operation 762, TOS gateway G A G B G C Their keys can be split into K A K B K C They are stored on their own persistent storage, and K(tx) can be published in operation 764. Thus, the published transaction (tx) can be the creation of a channel transaction. The preceding operations can establish an encryption key for encrypting the transaction. In some embodiments, this key can be encrypted to prevent the TOS from seeing its contents, as it may contain sensitive information such as who the parties in the channel are.

[0121] Symmetric key derivation

[0122] In some embodiments, the encryption key can be used as a seed for a key derivation algorithm that deterministically changes the key every certain number of messages:

[0123]

[0124] Where "i" is a counter that can be periodically incremented, such as after a predetermined number of messages (e.g., 2). 32 One message, 2 96 (Single message), weekly, monthly, quarterly, etc. The share can be evenly and randomly distributed depending on the fields used. One advantage of using this system is that various TOS gateways G A G B This allows for different counter values ​​to be used and eliminates the need to coordinate how to initialize the counters. Another advantage is that the system can automatically rotate the order of key shares among blockchain members (e.g., TOS gateway G). N (It is possible to have a first key share during the first counter period and a fifth key share during the second counter period, etc.)

[0125] Symmetric key recovery

[0126] In some embodiments, the symmetric key K of the channel will not be written to non-volatile memory (e.g., disk), but will only be stored in volatile memory (e.g., random access memory). Figure 8 This illustrates a configuration consistent with some embodiments using a TOS gateway G. A One method for symmetric key recovery 800. To decrypt or encrypt messages obtained from the total ordering service, the TOS gateway G... A It can be accessed from the remote TOS gateway G B G CWait until you acquire enough key shares to reconstruct the secret, or simply from another TOS gateway G that previously reconstructed the secret. B G C Waiting to obtain the secret. In some embodiments, the TOS gateway cannot calculate its own share without knowing the shares of other gateways because it lacks sufficient information.

[0127] In order to obtain a symmetric key from another TOS gateway, TOS gateway G A You can first contact the TOS gateway G in a loop. B G C And so on, and in operation 810, request the symmetric key from them. If there are no other TOS gateways G B G C Once a symmetric key is obtained, the TOS gateway G... A We will begin using "t-1" TOS gateways G B G C Key share K B K C The symmetric key is then reconstructed, where "t" can be chosen by the blockchain network administrator based on the network's security needs.

[0128] However, in some embodiments, the TOS gateways may not share any peer-to-peer IP connections. Instead, they can communicate via a shared message queue 450, first initiating / running a temporary key pair establishment protocol via the shared message queue in operations 820-836 to establish a symmetric encryption key that will be used for exchanging encryption K and / or its shares. More specifically, the TOS gateway G A A temporary private key can be generated first at operation 820. and its public counterpart And publish a key exchange message to the shared message queue (which can be unencrypted. Generally, in some embodiments, the key exchange protocol is designed to work over insecure media to establish symmetric encryption keys. However, some key exchange embodiments may also use encrypted ones), and in operation 822, a new temporary public key will be included (symbolically, Another TOS gateway (e.g., TOS gateway G) B Directed to shared message queue 450. If TOS gateway G A To recover the original random symmetric key K, it can also attach a key request (“KEY”) to the message at operation 822; similarly, if the TOS gateway G A To obtain a key share, it can also attach a key sharing request (“SHR”) at operation 822.

[0129] In response to the key exchange message, in operation 830, TOS gateway G B Temporary private keys can be generated and its public counterpart Then, in operation 832, TOS gateway G B Based on β and P A Calculate the temporary symmetric key (KEX) AB Then, TOS gateway G B Yes (using KEX) AB ) Encryption symmetric key (i.e., { KEX AB (K)}) and publish it to the shared message queue in response to the TOS gateway G A The "KEY" request, or the encrypted TOS gateway G at operation 834. B key share (i.e., { KEX AB (K) B )} and publish it to the shared message queue in response to the TOS gateway G A The “SHR” request.

[0130] During operation 840, TOS gateway G B The temporary private key β can be forgotten; that is, it can be deleted from its volatile memory and never stored in its non-volatile memory. TOS Gateway G A The original random symmetric key K can be decrypted, or the key fragment K in operation 850 can be used. A K B Wait until K is rebuilt. Then, operate 855, TOS gateway G. A You can also forget your temporary private key. In this way, even if an entity gains access to the shared message queue 450, the original random symmetric key K remains protected.

[0131] Group Member Expansion

[0132] Figure 9 This is a flowchart illustrating a method 900 for expanding membership in a blockchain, consistent with some embodiments. In this embodiment, whenever a new member / organization "D" joins the channel, its TOS gateway G... D It can obtain the shared key K and its own key share K. D TOS Gateway G D Starting with operation 910, use the reference. Figure 8The described protocol communicates with "t" existing channel members A, B, C, etc., to reconstruct the current symmetric key K and (only) store it in its volatile memory, where "t" is a number chosen by the administrator for the blockchain based on its security profile. Then, in operation 920, the new TOS gateway G... D The above method can be used to calculate its own unique key share K. D That is, with all other key shares K A K B K C Different key shares, and can be used in operation 930 to transfer K D It is stored in its persistent storage. Alternatively, one of the other TOS gateways can calculate the shared key K. D And transmit it along with the shared symmetric key.

[0133] Similarly, when a new member D is detected in the channel configuration, all existing TOS gateways G A G B G C It can be connected to the new TOS gateway G D After establishing a session using a temporary key pair, the new TOS gateway G... D Get K and K D .

[0134] Group member removal

[0135] When a member is removed from the channel by blockchain members A, B, C and / or the blockchain IT administrator, the total ordering service TOS can rotate the encryption key K so that the removed member is no longer able to decrypt message 450 in the shared message queue. Figure 10A and Figure 10B (Collectively referred to as Figure 10) illustrates one such method 1000 for rotating keys, consistent with some embodiments. In this illustrative example, for illustrative purposes only, it is assumed that organizations A and B want to remove organization C from the channel. In operation 1010, the blockchain administrator sends a channel configuration transaction (tx) to the TOS gateway G. A In operation 1020, TOS gateway G A You can respond by publishing a channel reconfiguration (“CHAN RECONFA AB BEGIN”) message tx to the total ordering service TOS.

[0136] During operation 1030, TOS gateway G B It can receive channel reconfiguration messages and can generate random temporary private keys. and corresponding public key To respond. Then, in operation 1035, TOS gateway G BYou can publish your public key to the Total Ordering Service (TOS). .

[0137] TOS Gateway G A A new random symmetric key K can be generated through operation 1040. 1 In operation 1042, it is divided into n parts (where n equals the remaining number of members, which is two in this case) for the response. Then, in operation 1045, the TOS gateway G... A Other TOS gateways can be used. B Temporary public keys (e.g., for) and The key shares are encrypted, and in operation 1047 they are published to the Total Ordering Service (TOS). That is, some embodiments may first change the key and then have all organizations except the removed organization learn the new key. However, these embodiments may still require reconfiguration to be applied to the blockchain itself, so these embodiments could encrypt the reconfiguration transaction with the new key before sending it. Alternatively, the TOS gateway G... B A new symmetric key K can be used 1 Use the above method to calculate your own key share.

[0138] In operation 1050, TOS gateway G B It can be used to determine its key share K 1 B New symmetric key K 1 Decrypt with tx. Then, in operation 1052, TOS gateway G. B It can be confirmed that organization C has indeed been removed from the channel, and if so, then in operation 1054, K will be removed. 1 B It is stored in its persistent storage device, and in operation 1056, a channel reconfiguration end (“CHAN RECONF AB END”) message is published to the Total Ordering Service (TOS).

[0139] Group member reconfiguration

[0140] To support the re-addition of removed organizations and / or the reconfiguration of channels (e.g., channel creation), each TOS gateway G A G B Key copies K can be stored based on the range of blocks with consecutive members. A K B In this scenario, if all current and future members of the channel confirm that they will persistently store their key shares, then previous key shares can be used across blocks. Similarly, any new organization being loaded will need to learn past symmetric keys.

[0141] Non-repudiation and integrity guarantee

[0142] Some implementations can support nonrepudiation and provide integrity guarantees. These implementations may be desirable in cases where the Total Ordering Service (TOS) performs incorrectly or fails, and therefore, various TOS gateways G... A G B Messages may be received in a different order. Similarly, these embodiments may be desirable if a member organization A, B, etc., erroneously asserts that the Total Ordering Service (TOS) sends their messages in an order different from the order in which they were received.

[0143] To detect such events if they do occur, or to refute incorrect claims, in some embodiments, each TOS gateway may periodically (e.g., every B blocks or T time intervals) publish a message that may contain: (i) the block range [i, j] for the message; and (ii) a Merkle root (e.g., a hash of all hashes of all transactions that is part of a block in the blockchain network), where the block indexed [i, j] is its leaf. In TOS gateway G A G B If it is detected that it has forked from most other network members, the TOS gateway may stop operating and return a special error when making service API calls.

[0144] Block processing

[0145] Figure 1 lA illustrates a process 1100 consistent with some embodiments, in which a new data block 1130 is added to the distributed ledger 1120, and Figure 11B The contents of a blockchain for a new data block 1130, consistent with some embodiments, are shown. The new data block 1130 may contain document link data.

[0146] refer to Figure 1In blockchain 1122, a client (not shown) can submit transactions to blockchain nodes 1111, 1112, and / or 1113. The client can be an instruction received from any source to formulate an activity on blockchain 1122. As an example, the client can be an application acting on behalf of a requester (such as a device or person) or an entity proposing a transaction to the blockchain. Multiple blockchain peers (e.g., blockchain nodes 1111, 1112, and 1113) can maintain the state of the blockchain network and a copy of the distributed ledger 1120. Different types of blockchain nodes / peers can exist in the blockchain network, including endorsement peers that simulate and endorse transactions proposed by clients, and submission peers that verify endorsements, confirm transactions, and submit transactions to the distributed ledger 1120. In some embodiments, blockchain nodes 1111, 1112, and 1113 can perform the roles of an endorser node, a submitter node, or both.

[0147] The distributed ledger 1120 may include a blockchain storing immutable, ordered records in blocks, and a state database 1124 (current world state) maintaining the current state of the blockchain 1122. Each channel may have its own distributed ledger 1120, and each peer maintains 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 constructed as hash-linked blocks, where each block contains a sequence of N transactions. Blocks may include, for example... Figure 11B The various components shown. A chain of blocks can be generated by adding the hash value of the header of the previous block to the block header of the current block. Figure 11A (As indicated by the arrow in the diagram). In this way, all transactions on blockchain 1122 can be ordered and cryptographically linked together, thus preventing tampering with the blockchain data without breaking the hash links. Furthermore, due to the links, the latest block in blockchain 1122 represents every transaction that arrived before it. Blockchain 1122 can be stored on a peer-to-peer file system (local or attached storage) that supports only attached blockchain workloads.

[0148] The current state of blockchain 1122 and distributed ledger 1120 can be stored in state database 1124. Here, the current state data represents the latest values ​​of all keys that were once included in the chain transaction log of blockchain 1122. Chaincode calls execute transactions against the current state in state database 1124. To make these chaincode interactions more efficient, the latest values ​​of all keys can be stored in state database 1124. State database 1124 can include an indexed view of the transaction log of blockchain 1122, so it can be regenerated from the chain at any time. State database 1124 can be automatically restored when peers start up, before transactions are accepted (or generated when needed).

[0149] Endorsing nodes receive transactions from clients and endorse them based on the simulation results. The endorsing nodes maintain the smart contract of the simulated transaction proposal. When an endorsing node endorses a transaction, it creates a transaction endorsement, which is a signed response from the endorsing node to the client application indicating the endorsement of the simulated transaction. The method of endorsing a transaction depends on the endorsement policy that can be specified in the chaincode. An example of an endorsement policy is "most endorsing peers must endorse the transaction." Different channels can have different endorsement policies. The endorsed transaction is forwarded by the client application to the ordering service 1110.

[0150] The ordering service 1110 accepts endorsed transactions, orders them into blocks, and delivers the blocks to submitting peers. For example, the ordering service 1110 can initiate a new block when a transaction threshold is reached, a timer expires, or other conditions are met. Figure 11A In the example, blockchain node 1112 is the committing peer that has received new data block 1130 for storage on blockchain 1122. The first block in a blockchain can be called the genesis block, which includes information about the blockchain, its members, the data stored in it, and so on.

[0151] The sorting service 1110 may consist of a cluster of sorting nodes. In some embodiments, the sorting service 1110 may not process transactions, smart contracts, or maintain a shared ledger. Instead, in these embodiments, the sorting service 1110 may accept endorsed transactions and specify the order in which these transactions are submitted to the distributed ledger 1120. The architecture of the blockchain network may be designed such that the specific method of "sorting" (e.g., Solo, Kafka, BFT, etc.) is a pluggable component.

[0152] In some embodiments, transactions can be written to the distributed ledger 1120 in a consistent order. In these embodiments, the order of transactions can be established to ensure that updates to the state database 1124 are valid when submitted to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin, etc.), where ordering is achieved by solving cryptographic puzzles, in this example, the parties to the distributed ledger 1120 can choose the ordering mechanism best suited to the network.

[0153] In some embodiments, when the sorting service 1110 initializes a new data block 1130, the new data block 1130 can be broadcast to commit peers (e.g., blockchain nodes 1111, 1112, and 1113). In response, each commit peer can confirm 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. Specifically, the commit peer can determine whether the read data present when the endorser simulates the transaction is the same as the current world state in the state database 1124. When a commit peer confirms a transaction, the transaction can be written to blockchain 1122 on the distributed ledger 1120, and the state database 1124 can be updated with the write data from the read and write sets. In some embodiments, if a transaction fails (e.g., if a commit peer finds that the read and write sets do not match the current world state in the state database 1124), the transaction sorted into the block may still be included in the block but marked as invalid, and the state database 1124 will not be updated.

[0154] refer to Figure 11B In some embodiments, a new data block 1130 (also referred to as a data block) stored on 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... Figure 11B The various depictions of blocks and their contents shown, such as new data block 1130 and its contents, are merely examples and not intended to limit the scope of the exemplary embodiments. New data block 1130 may store transaction information for N transactions (e.g., 1, 10, 100, 200, 1000, 2000, 3000, etc.) within block data 1150. New data block 1130 may also include links to preceding data blocks within its data header 1140 (e.g., in...). Figure 11A (On data block 1122). In particular, block header 1140 may include the hash of the preceding block header. Block header 1140 may also include a unique block number, the hash of block data 1150 of the new data block 1130, etc. The block number of the new data block 1130 may be unique and assigned in various orders, such as incremental / sequential sorting starting from zero.

[0155] Block data 1150 can store transaction information for each transaction recorded within the new data block 1130. For example, transaction data may include one or more of the following: transaction type, version, timestamp, channel ID of the distributed ledger 1120, transaction ID, epoch, payload visibility, chaincode path (deploy tx), chaincode name, chaincode version, inputs (chaincode and functionality), client (creator) identity such as public keys and certificates, client signature, endorser identity, endorser signature, proposal hash, chaincode events, response status, namespace, read set (a list of keys and versions read by the transaction, etc.), write set (a list of key-value pairs), start key, end key, list of keys, Merkle tree query digest, etc. Transaction data can be stored for each of N transactions.

[0156] In some embodiments, block data 1150 may also store new data 1162, which adds additional information to the chain of hashed linked blocks in blockchain 1122. The additional information may include one or more steps, features, processes, and / or actions described or depicted herein. Therefore, new data 1162 may be stored in an immutable block log on the distributed ledger 1120. Some advantages of storing such new data 1162 are reflected in the various embodiments disclosed and described herein. While in Figure 11B In this context, new data 1162 is depicted in block data 1150, but in some embodiments, it may also be located in block header 1140 or block metadata 1160. New data 1162 may also include document combination keys for linking documents within the organization.

[0157] Block metadata 1160 can store multiple fields of metadata (e.g., as a byte array). Metadata fields may include: a signature at the time of block creation, a reference to the last configured block, transaction filters identifying valid and invalid transactions within the block, and the last offset of the sorting service that sorts the blocks. The signature, last configured block, and sorter metadata can be added by the sorting service 1110. Simultaneously, the block submitter (such as blockchain node 1112) can add validity / invalidity information based on endorsement policies, verification of read / write sets, etc. Transaction filters may include a byte array of size equal to the number of transactions in block data 1150 and a confirmation code identifying whether a transaction is valid / invalid.

[0158] Figure 11CAn embodiment of blockchain 1170 for digital content, consistent with some embodiments, is described. Digital content may include one or more files and associated information. These files may include transaction data, media, images, videos, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. Immutable, additional aspects in some blockchain embodiments may be desirable as safeguards for the integrity, validity, and authenticity of digital content, making it suitable for legal proceedings for the application of acceptability rules, or other settings that are otherwise meaningful in consideration of the presentation and use of evidence or digital information. In this context, the digital content may be referred to as digital evidence.

[0159] In these embodiments, the blockchain can be formed in various ways. In one embodiment, digital content can be included in the blockchain and accessed from the blockchain itself. For example, each block of the blockchain can store a hash value of reference information (e.g., header, value, etc.) along with the associated digital content. The hash value and the associated digital content can then be encrypted together. Thus, the digital content of each block can be accessed by decrypting each block in the blockchain, and the hash value of each block can serve as a basis for referencing previous blocks. This can be illustrated as follows:

[0160] Block 1 Block 2 ... Block N

[0161] Hash value 1 Hash value 2 Hash value N

[0162] Digital content 1 Digital content 2 Digital content N

[0163] In one embodiment, digital content may not be included in the blockchain. For example, the blockchain could store the encrypted hash of the content of each block without any digital content. The digital content could be stored in a separate storage area or memory address associated with the hash value of the original file. This other storage area could be the same storage device used to store the blockchain, a different storage area, or even a separate relational database. The digital content of each block can be referenced or accessed by retrieving or querying the hash value of the block of interest, and then looking up that hash value in the storage area, where it corresponds to the actual digital content. This operation can be performed by, for example, a database gatekeeper. This can be illustrated as follows:

[0164] Blockchain storage area

[0165] Block 1 hash value Block 1 hash value... content

[0166] …… ……

[0167] …… ……

[0168] …… ……

[0169] Block N hash value Block N hash value... content

[0170] In the exemplary embodiment of Figure 7C, the blockchain 1170 includes a number of blocks 11781, 11782, ... 1178 linked in an ordered sequence. N Where N≥1. Used to link blocks 11781, 11782, ...1178. N The encryption can be any of some keyed or keyless hash functions. In one embodiment, blocks 11781, 11782, ... 1178... N The hash function is constrained to produce an n-digit alphanumeric output (where n is 256 or another number) based on the input information in the block. Examples of such hash functions include, but are not limited to: SHA-type (SHA stands for Secure Hash Algorithm), Merkle-Damgard algorithm, HAIFA algorithm, Merkle-tree algorithm, nonce-based algorithms, and non-collision-resistant PRF algorithms. In another embodiment, blocks 11781, 11782, ... 1178... N Encrypted links can be created using functions other than hash functions. For illustrative purposes, the following description refers to hash functions, such as SHA-2.

[0171] Each block in the blockchain is numbered 11781, 11782, ... 1178. N It may include a header, a file version, and a value. As a result of hashing in the blockchain, the header and value may be different for each block. 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.

[0172] The first block in the blockchain, 11781, is called the genesis block and may include a header 11721, the original file 11741, and an initial value 11761. The hashing scheme used for the genesis block and all subsequent blocks may differ. For example, all the information in the first block 11781 may be hashed at once, or each or part of the information in the first block 11781 may be hashed separately, and then the separately hashed parts may be hashed.

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

[0174] The original file 11741 in the genesis block may be, for example, data captured by a device, which may or may not have been processed before being included in the blockchain. The original file 11741 can be received from a device, media source, or node through the system's interface. The original file 11741 may be associated with metadata, which may be generated manually or automatically by a user, device, and / or system processor, for example. The metadata may be included in the first block 11781 in association with the original file 11741.

[0175] The value 11761 in the genesis block can 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 the hash value of the original file 11741, the metadata of the original file 11741, and other information associated with that file. In one embodiment, the initial value 11761 may be based on the following unique attributes:

[0176] 1) The hash value of the original file calculated using SHA-2.

[0177] 2) Initiating device ID

[0178] 3) Start timestamp of the original file

[0179] 4) Initial storage location of the original file

[0180] 5) The blockchain network member ID of the software currently controlling the original file and associated metadata.

[0181] Other blocks 11782 to 1178 in the blockchain N It also has a header, filename, and value. However, unlike the header 11721 in the first block, each header in the other blocks is 11722 to 1172. NEach block includes the hash of the immediately preceding block. The hash of the immediately preceding block can be either the hash of the block's header or the hash of the entire preceding block. By including the hash of the preceding block in each of the remaining blocks, a traceback from block N to the genesis block (and associated original files) can be performed block-by-block, as shown by arrow 1180, to establish an auditable and immutable chain of custody.

[0182] Each header in the other blocks is 11722 to 1172. N It may also include other information, such as version number, timestamp, nonce, root information, difficulty level, consensus protocol and / or other parameters or information related to the relevant file and / or the blockchain as a whole.

[0183] Files 11742 to 1174 in other blocks N It can be equal to the original file or a modified version of the original file in the genesis block, depending on, for example, the type of processing performed. The type of processing performed can vary from block to block. For example, processing might involve any modification to a file in a preceding block, such as editing information or otherwise changing the contents of the file, retrieving information from the file, or adding or appending information to the file.

[0184] Additionally or alternatively, processing may involve 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 actions relative to the file and / or its associated metadata on the blockchain. Processes involving analyzing files may include, for example, appending, including, or otherwise associating various analyses, statistics, or other information associated with the file.

[0185] Blocks 11762 to 1176 in other blocks N Each block in the blockchain has a unique value, and each value is distinct due to the processing performed. For example, the value in any block corresponds to an updated version of the value in a previous block. This update is reflected in the hash of the block to which the value was assigned. Therefore, the value of a block provides an indication of the processing performed within that block and also allows for tracing back to the original file through the blockchain. This tracing confirms the chain of custody of files throughout the blockchain.

[0186] For example, to protect the identity of the person displayed in the file, portions of the file in previous blocks might have been edited, masked, or pixelated. In this case, the block containing the edited file would include metadata associated with the edited file, such as how the editing was performed, who performed the editing, and the timestamp of the editing. This metadata can be hashed to form values. Because the metadata in this block differs from the hashed values ​​in previous blocks, these values ​​are distinct from each other and can be recovered during decryption.

[0187] In one embodiment, the value of a previous block can be updated (e.g., a new hash value is calculated) to form the value of the current block when any one or more of the following occur. In this example implementation, the new hash value can be calculated by hashing all or part of the information mentioned below.

[0188] a) The new hash value calculated using SHA-2 if the file is processed in any way (e.g., if the file is edited, copied, altered, accessed, or some other action is taken).

[0189] b) The new storage location of the file

[0190] c) New metadata associated with this file

[0191] d) Transfer of file access or control from one blockchain participant to another blockchain participant

[0192] Figure 11D This describes an embodiment of a block consistent with some implementation examples, which may represent the structure of a block in Blockchain 1190. This block... i It can include the head 1172 i Document 1174 i Sum of 1176 i .

[0193] Head 1172 i This can include the preceding block. i-1 The hash value and additional reference information, such as any type of information discussed herein (e.g., header information including references, features, parameters, etc.). In some embodiments, all blocks except the genesis block may reference the hash of previous blocks. The hash value of a previous block may be simply the hash of the header in the previous block, or it may be the hash of all or part of the information in the previous block, including files and metadata.

[0194] Document 1174 iThis may include multiple data sets, such as sequential data 1, data 2, ..., data N. These data sets are labeled metadata 1, metadata 2, ..., metadata N, and describe the content and / or characteristics associated with the data. For example, the metadata for each data set may include: information indicating the timestamp of the data, information about the data processing, keywords indicating the people or other content depicted in the data, and / or other characteristics that may help establish the validity and content of the entire document, particularly its use as digital evidence, such as the description related to the embodiments discussed below. In addition to the metadata, each data set may be referred to as REF1, REF2, ..., REF... N This is used to mark previous data to prevent tampering, blank spaces in the file, and to reference the file order.

[0195] Once metadata is assigned to data (e.g., via a smart contract), it cannot be altered without changing its hash value; in some embodiments, this is easily identified as invalid. Therefore, the metadata in these embodiments creates a data log of information that can be accessed and used by participants in the blockchain.

[0196] In some embodiments, the value is 1176 i This can be a hash value or other value calculated based on any type of information discussed earlier. For example, for any given block... i The value of a block can be updated to reflect the processing performed on that block, such as a new hash value, a new storage location, new metadata for the associated file, a transfer of control or access, an identifier, or the addition of other actions or information. Although the value in each block is shown as separate from the metadata of the file and header data, in another embodiment, the value may be based partly or entirely on that metadata.

[0197] In some embodiments, once the blockchain 1170 is formed, at any point in time, the immutable custody chain of the file can be obtained by querying the transaction history of values ​​across blocks in the blockchain. This query or tracing process can begin by decrypting the value of the block currently containing the most values ​​(e.g., the last (Nth) block) and then continue decrypting the values ​​of other blocks until the genesis block is reached and the original file is recovered. Decryption may involve decrypting the header and file associated with each block, as well as the metadata.

[0198] Decryption can be performed based on the type of encryption that occurs within each block. This may involve using a private key, a public key, or a public-private key pair. For example, when using asymmetric encryption, blockchain participants or processors in the network can generate public and private key pairs using a pre-defined algorithm. The public and private keys can be linked together through some mathematical relationship. The public key can be publicly distributed as an address for receiving messages from other users, such as an IP address or home address. The private key can be kept secret and used to digitally sign messages sent to other blockchain participants. The signature can 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 assured that only the sender could have sent the message.

[0199] In some embodiments, generating a key pair can be similar to creating an account on the blockchain, but without actually registering anywhere. In these embodiments, every transaction executed on the blockchain can be digitally signed by the sender using their private key. This signature helps ensure that only the account owner can track and process (if within the permissions defined by the smart contract) the blockchain's files.

[0200] Figure 12A and Figure 12B Other examples of blockchain use cases that can be incorporated into and used in this article are illustrated. In particular, Figure 12A Example 1200 illustrates a blockchain 1210 for storing machine learning (artificial intelligence) data. Machine learning typically relies on large amounts of historical data (or training data) to build predictive models in order to make accurate predictions on new data. Machine learning software (e.g., neural networks, etc.) can often sift through millions of records to uncover non-intuitive patterns.

[0201] exist Figure 12A In the example, host platform 1220 builds and deploys machine learning models for predictive monitoring of asset 1230. Here, host platform 1220 can be a cloud platform, industrial server, web server, personal computer, user equipment, etc. Asset 1230 can be any type of asset (e.g., machinery or equipment), such as aircraft, locomotives, turbines, medical machines and equipment, oil and gas equipment, ships, vessels, vehicles, etc. As another example, asset 1230 can be intangible assets, such as stocks, currency, digital coins, insurance, etc.

[0202] Blockchain 1210 can be used to significantly improve the training process 1202 of machine learning models and the prediction process 1204 of training-based machine learning models. For example, in 1202, historical data can be stored on blockchain 1210 by asset 1230 itself (or through an undisclosed intermediary), instead of requiring data scientists / engineers or other users to collect the data. This can significantly reduce the collection time required by host platform 1220 when performing predictive model training. For example, using smart contracts, data can be transferred directly and reliably from its source to blockchain 1210. By ensuring the security and ownership of the collected data through blockchain 1210, smart contracts can directly send data from assets to individuals using the data to build machine learning models. This allows data to be shared between assets 1230.

[0203] The collected data can be stored on Blockchain 1210 based on a consensus mechanism. This mechanism can pull in authorized nodes to ensure the recorded data is verified and accurate. The recorded data can be timestamped, cryptographically signed, and immutable. Therefore, it is auditable, transparent, and secure. In some cases (such as supply chain, healthcare, logistics, etc.), adding IoT devices that write directly to the blockchain can increase the frequency and accuracy of the recorded data.

[0204] Furthermore, training the machine learning model on the collected data may require multiple rounds of refinement and testing by the host platform 1220. Each round can be based on additional data or data not previously considered to help expand the knowledge of the machine learning model. In 1202, the different training and testing steps (and the associated data) can be stored on blockchain 1210 by the host platform 1220. Each refinement of the machine learning model (e.g., changes to variables, weights, etc.) can be stored on blockchain 1210. This provides verifiable proof about how the model was trained and what data was used to train it. Additionally, when the host platform 1220 implements the final trained model, the resulting model can be stored on blockchain 1210.

[0205] After the model is trained, it can be deployed to a field environment where it can make predictions / decision based on the performance of the finally trained machine learning model. For example, in 1204, the machine learning model can be used for condition-based maintenance (CBM) of assets such as aircraft, wind turbines, and healthcare vehicles. In this example, data fed back from asset 1230 can be fed into the machine learning model and used to make event predictions such as failure events, error codes, etc. The determinations made by the machine learning model at host platform 1220 can be stored on blockchain 1210 to provide auditable / verifiable proof. As a non-limiting example, the machine learning model can predict future failures / failures of a portion of asset 1230 and create alerts or notifications to replace that portion. The data behind this decision can be stored on blockchain 1210 by host platform 1220. In one embodiment, the functions and / or actions described and / or depicted herein can occur or be associated with blockchain 1210.

[0206] New transactions on a blockchain can be aggregated into a new block and added to an existing hash. This may then be encrypted to create a new hash for the new block. As transactions are encrypted, they may be added to the next list of transactions, and so on. The result is a blockchain where each block contains the hashes of all preceding blocks. The computers storing these blocks periodically compare their hashes to ensure they are consistent. Any inconsistent hashes are discarded by the computer that caused the problem. This method helps ensure the blockchain's tamper-resistance, but it is not perfect.

[0207] One way to manipulate the system is for a dishonest user to change the list of transactions that favor them while keeping the hash value unchanged. This can be done through brute force—in other words, altering the record, encrypting the result, and then seeing if the hash values ​​match. If not, try again and again until a matching hash is found. The security of blockchain is based on the belief that ordinary computers can only perform such brute-force attacks on completely impractical timescales (such as the age of the universe). In contrast, quantum computers are much faster (1000 times faster) for certain types of problems, and therefore pose a much greater threat.

[0208] Figure 12B Example 1250 illustrates a quantum-safe blockchain 1252 that implements quantum key distribution (QKD) to prevent quantum computing attacks. In this example, blockchain users can use QKD to verify each other's identity. This might involve sending information using quantum particles such as photons, which cannot be copied by an eavesdropper without being destroyed. In this way, the sender and receiver through the blockchain can verify each other's identity.

[0209] exist Figure 12B In the example, there are four users: 1254, 1256, 1258, and 1260. Each pair of users can share a secret key 1262 (i.e., QKD). Because there are four nodes in this example, there are six pairs of nodes, thus six different secret keys 1262 are used, including QKD. AB QKD AC QKD AD QKD BC QKD BD and QKD CD Each pair of users can create a QKD by sending information using quantum particles such as photons, which cannot be copied by an eavesdropper without being destroyed. In this way, a pair of users can identify each other.

[0210] The operation of blockchain 1252 can be based on two procedures: (i) the creation of transactions, and (ii) the construction of blocks that aggregate new transactions. The creation of new transactions can be similar to that of a traditional blockchain network. Each transaction can contain information about the sender, receiver, creation time, amount (or value) to be transferred, a list of reference transactions proving the sender has funds for the operation, etc. This transaction record is then sent to all other nodes, where it is entered into a pool of unconfirmed transactions. Here, the two parties (i.e., a pair of users in 1254-1260) can verify the transaction by providing their shared key 1262 (QKD). This quantum signature can be attached to each transaction, making it difficult to tamper with. Each node checks its entries relative to a local copy of blockchain 1252 to verify that each transaction has sufficient funds. However, these transactions are not yet confirmed.

[0211] Blocks are created in a decentralized manner using a broadcast protocol. Within a predetermined time period (e.g., seconds, minutes, hours, etc.), the network can apply the broadcast protocol to any unconfirmed transactions, thereby achieving a Byzantine consensus on the correct version of the transactions. For example, each node may possess private value (transaction data specific to that node). In the first round, nodes send their private value to each other. In subsequent rounds, nodes exchange the information they received from other nodes in the previous round. Here, honest nodes are able to create a complete set of transactions within the new block. This new block can be added to blockchain 1252. In one embodiment, the features and / or actions described and / or depicted herein may occur on or related to blockchain 1252.

[0212] Computer program products

[0213] This invention can be an integrated system, method, and / or computer program product at any possible level of technical detail. The computer program product may include a computer-readable storage medium (or multiple storage media) having computer-readable program instructions to cause a processor to execute aspects of the invention.

[0214] A computer-readable storage medium can be a tangible device that holds and stores instructions for use by an instruction execution device. A computer-readable storage medium can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer floppy disks, 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 optical disc read-only memory (CD-ROM), digital versatile optical disc (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or raised structures in recesses, on which instructions are recorded, and any suitable combination of the foregoing. The computer-readable storage medium as used herein should not be construed as a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through optical fibers), or electrical signals transmitted through wires.

[0215] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to their respective computing / processing devices, or downloaded via a network to an external computer or external storage device, such as the Internet, a local area network (LAN), a wide area network (WAN), and / or a wireless network. This network may include copper transmission cables, optical fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the respective computing / processing device for storage.

[0216] Computer-readable program instructions used to perform the operations of this invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or similar languages, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer, partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or connected to an external computer (e.g., using an internet service provider via the internet). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may execute the computer-readable program instructions by utilizing state information from the computer-readable program instructions to personalize the electronic circuitry and thereby perform various aspects of the invention.

[0217] This document describes aspects of the invention 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 in 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.

[0218] These computer-readable program instructions may be provided to a computer processor or other programmable data processing apparatus to create a machine, thereby creating means, via the instructions which execute through the processor of the computer or other programmable data processing apparatus, to implement the functions / behaviors specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, and / or other apparatus to operate in a particular manner, such that a computer-readable storage medium having instructions stored therein includes an article of writing comprising instructions implementing aspects of the functions / behaviors specified in the blocks of a flowchart and / or block diagram.

[0219] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the instructions, which execute on the computer, other programmable apparatus or other device, perform the functions / behaviors specified in the flowchart and / or block diagram.

[0220] The flowcharts and block diagrams in the figures illustrate the structure, function, and operation of possible embodiments 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 a specified logical function. In some alternative embodiments, the functions indicated in the blocks may not appear in the order shown in the figures. For example, two blocks shown consecutively may actually be completed as a single step, executed simultaneously, substantially simultaneously, executed in a manner with partial or complete time overlap, or these blocks may sometimes be executed in reverse order, depending on the functions involved. It will also be noted that each block in the block diagram and / or flowchart illustrations, and combinations of blocks in the block diagram and / or flowchart illustrations, may be implemented by a special-purpose hardware system that performs the specified function or behavior, or a combination of special-purpose hardware and computer instructions.

[0221] Overview

[0222] This document describes aspects of the invention 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 in 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. Furthermore, the flowcharts and block diagrams in the figures illustrate the structure, function, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the 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 a specified logical function. In some alternative embodiments, the functions indicated in the blocks may not appear in the order shown in the figures. For example, two blocks shown consecutively may actually be executed simultaneously, or the blocks may sometimes be executed in reverse order depending on their function. Furthermore, each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented by performing a specified function or operation or by performing a combination of special hardware and computer instructions.

[0223] Any particular program nomenclature used in this description is for convenience only, and therefore the invention should not be limited to use only in any particular application identified and / or implied by such nomenclature. Thus, for example, routines executed to implement embodiments of the invention, whether implemented as part of an operating system or as a particular application, component, program, module, object, or sequence of instructions, may be referred to as "program," "application," "server," or other meaningful nomenclature. In fact, other alternative hardware and / or software environments may be used without departing from the scope of the invention.

[0224] Therefore, it is intended that the embodiments described herein be considered illustrative in all respects and not restrictive, and that reference be made to the appended claims in determining the scope of the invention.

Claims

1. A computer-implemented method for establishing consensus in a blockchain network, comprising: A first total ordering service (TOS) gateway is provided for organizations in a blockchain network, wherein the TOS gateway has read / write access to a shared message queue that makes messages available to every other TOS gateway in the blockchain network; Generate a symmetric key at the first TOS gateway; The symmetric key is split to generate multiple key shares; Distribute at least one of the plurality of key shares to a second TOS gateway in the blockchain network; and At the first TOS gateway, a request for the symmetric key is received from the second TOS gateway via the shared message queue; and in response: Receive a temporary public counterparty from the second TOS gateway; Generate a temporary key pair, wherein the temporary key pair includes a temporary private key and a temporary public counterpart of the first TOS gateway; Generate a temporary symmetric key; The temporary symmetric key is encrypted using the temporary public counterpart from the second TOS gateway; The temporary symmetric key is used to encrypt the shared key; and The encrypted shared key is published to the shared message queue.

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

3. The computer-implemented method according to claim 1, further comprising: Store at least one of the plurality of key shares in persistent memory; as well as The symmetric key is stored only in volatile memory.

4. The computer-implemented method according to claim 1, further comprising: Receive the transaction payload at the first TOS gateway; The transaction is encrypted using the symmetric key; as well as Publish the encrypted transaction to the shared message queue.

5. The computer-implemented method according to claim 4, further comprising: Form one or more blocks associated with the transaction; as well as Use a blockchain key to autonomously sign one or more blocks.

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

7. The computer-implemented method of claim 5 further includes appending one or more signed blocks to a blockchain associated with the blockchain network.

8. The computer-implemented method according to claim 1, further comprising recovering the symmetric key, including: Request one of the key shares from the second TOS gateway in the blockchain network; as well as The symmetric key is reconstructed using one of the key shares.

9. The computer-implemented method according to claim 8, wherein, Requesting one of the key shares from the second TOS gateway includes: A temporary key pair is generated at the first TOS gateway, wherein the temporary key pair includes a temporary private key and a temporary public counterpart; Publish the temporary public counterpart to the shared message queue; A temporary symmetric key is received from the second TOS gateway via the shared message queue, wherein the temporary symmetric key is generated in part using the temporary public counterpart of the first TOS gateway; The key share is received from the second TOS gateway via the shared message queue, wherein the key share is encrypted using the temporary symmetric key. Use the temporary symmetric key to decrypt one of the key shares; and Forget the temporary key pair.

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

11. The computer-implemented method of claim 1, further comprising rotating the symmetric key, including: Receive the channel reconfiguration message at the first TOS gateway; A temporary key pair is generated at the first TOS gateway, wherein the temporary key pair includes a temporary private key and a temporary public counterpart; Publish the temporary public counterpart to the shared message queue; Receive key fragments from the second TOS gateway via the shared message queue, wherein the key fragments are encrypted using the temporary public counterpart; and Use the temporary private key to decrypt the key fragment.

12. The computer-implemented method of claim 11, wherein the channel reconfiguration message responds to a TOS gateway removal action.

13. A computer program product for a confidential sorting service, the computer program product comprising: One or more computer-readable storage media, and program instructions commonly stored on the one or more computer-readable storage media, the program instructions comprising: A total ordering service (TOS) gateway is run for each organization in the blockchain network, wherein each TOS gateway has read / write access to a shared message queue that distributes messages to each organization; Identify a group of organizations within the organization; and Generate channels comprising the set of organizations, wherein the set of organizations collaborates autonomously; Among them, multiple TOS gateways include program instructions for performing the following operations: A symmetric key is generated at the first TOS gateway among the plurality of TOS gateways; The symmetric key is split to generate multiple key shares; Distribute at least one of the plurality of key shares to a second TOS gateway among the plurality of TOS gateways; and At the first TOS gateway, a request for the symmetric key is received from the second TOS gateway via the shared message queue; and in response: Receive a temporary public counterparty from the second TOS gateway; Generate a temporary key pair, wherein the temporary key pair includes a temporary private key and a temporary public counterpart of the first TOS gateway; Generate a temporary symmetric key; The temporary symmetric key is encrypted using the temporary public counterpart from the second TOS gateway; The temporary symmetric key is used to encrypt the shared key; and The encrypted shared key is published to the shared message queue.

14. The computer program product of claim 13, further comprising program instructions for the following operations: Generate a symmetric key known only to the said group of organizations; The symmetric key is divided into corresponding shares associated with multiple organizations within the set of organizations; and The share is stored but the symmetric key is not stored as a whole.

15. The computer program product of claim 14, further comprising program instructions for the following operations: The transaction is received by the TOS gateway of at least one of the organizations in the group; Encrypt transactions using a symmetric key; Form one or more blocks associated with the transaction; Use the corresponding share to independently sign the one or more blocks; as well as Broadcast one or more signed blocks to the group of organizations.

16. The computer program product of claim 15, wherein each TOS gateway of each organization in the group of organizations knows one or more certificates associated with other organizations in the group of organizations.

17. A blockchain network, comprising: Multiple Total Ordering Service (TOS) gateways, each associated with one of multiple member organizations in a blockchain network, wherein each of the multiple TOS gateways includes a processor operatively connected to a memory containing program instructions that, when executed on the processor, perform the following operations: A symmetric key is generated at the first TOS gateway among the plurality of TOS gateways; Divide the symmetric key into multiple key shares; and Distribute at least one of the multiple key shares to the second TOS gateway in the blockchain network; Shared message queues are suitable for redistributing symmetric keys to multiple TOS gateways in a blockchain network; The plurality of TOS gateways also include program instructions for performing the following operations: At the first TOS gateway, a request for the symmetric key is received from the second TOS gateway via the shared message queue; and in response: Receive a temporary public counterparty from the second TOS gateway; Generate a temporary key pair, wherein the temporary key pair includes a temporary private key and a temporary public counterpart of the first TOS gateway; Generate a temporary symmetric key; The temporary symmetric key is encrypted using the temporary public counterpart from the second TOS gateway; The temporary symmetric key is used to encrypt the shared key; and The encrypted shared key is published to the shared message queue.

18. The blockchain network according to claim 17, wherein, The plurality of TOS gateways also include program instructions for performing the following operations: Receive the transaction payload; The transaction payload is encrypted using the symmetric key; and The encrypted transaction payload is published to the shared message queue; and The shared message queue is also adapted to redistribute transaction payloads to the plurality of TOS gateways in the blockchain network without reading message content.

19. The blockchain network of claim 18, wherein the plurality of TOS gateways further comprises program instructions for the following operations: Store one of the key shares in persistent memory; and The symmetric key is stored only in volatile memory.

Images