Privacy-Preserving Architecture for Permissioned Blockchains

Abstract

The processor may generate a request associated with the transaction. The processor may collect an anchor associated with the request. The processor may transition the transaction to a set of two or more hashes. The processor may submit the transaction to an ordering service. The processor may receive a request associated with the transaction. The processor may identify that a first preimage associated with the first hash is known to the first shard. The processor may generate a first identification tag associated with the transaction. The processor may receive the request associated with the transaction. The processor may assign a first task to the first shard. The processor may identify that a first preimage associated with the first hash is known to the first shard. The processor may execute the task.

Description

[Technical Field]

[0001] The present disclosure relates generally to the field of blockchain transaction commitments, and more specifically to preserving transaction privacy in permissioned blockchains. [Background technology]

[0002] Blockchains provide immutability of data by replicating it across all nodes in the network. To be able to validate a blockchain, nodes must have access to the complete history of transactions, making any data on the chain visible to all participants. Summary of the Invention

[0003] Embodiments of the present disclosure include methods, systems, and computer program products for processing private transactions in a blockchain network. A processor may generate a request associated with the transaction. The processor may collect anchors associated with the request. The processor may transition the transaction into a set of two or more hashes. The processor may submit the transaction to an ordering service.

[0004]

[0010] A further embodiment of the present disclosure includes a method for processing a private transaction in a blockchain network. A processor may receive a request related to the transaction. The processor may identify that a first pre-image associated with a first hash is known to a first shard. The processor may generate a first identification tag associated with the transaction.

[0005] A further embodiment of the present disclosure includes a method for processing private transactions in a blockchain network. A processor may receive a request related to the transaction. The processor may assign a first task to a first shard. The processor may identify that a first pre-image associated with the first hash is known to the first shard. The processor may execute the task.

[0006] The above summary is not intended to describe each illustrated embodiment or every implementation of the present disclosure. [Brief explanation of the drawings]

[0007] The drawings included in this disclosure are incorporated in and form a part of this specification. They illustrate embodiments of the disclosure and, together with the description, serve to explain the principles of the disclosure. The drawings are merely illustrative of particular embodiments and are not intended to limit the disclosure.

[0008] [Figure 1A] 1 illustrates an exemplary blockchain architecture according to an embodiment of the present disclosure.

[0009] [Figure 1B] 1 illustrates a blockchain transaction flow according to an embodiment of the present disclosure.

[0010] [Figure 2A] FIG. 1 illustrates a block diagram of an exemplary system for atomically committing a transaction to a blockchain network, according to an embodiment of the present disclosure.

[0011] [Figure 2B] FIG. 1 illustrates a block diagram of an exemplary system for atomically committing horizontal cut transactions to a blockchain network, according to an embodiment of the present disclosure.

[0012] [Figure 2C]FIG. 1 illustrates a block diagram of an exemplary system for atomically committing a vertical cut transaction to a blockchain network, according to an embodiment of the present disclosure.

[0013] [Figure 3A] 1 illustrates a flowchart of an exemplary method for processing private transactions in a blockchain network, according to an embodiment of the present disclosure.

[0014] [Figure 3B] 10 illustrates a flowchart of a further exemplary method for processing private transactions in a blockchain network, according to an embodiment of the present disclosure.

[0015] [Figure 3C] 1 illustrates a flowchart of another exemplary method for processing private transactions in a blockchain network, according to an embodiment of the present disclosure.

[0016] [Figure 4A] 1 illustrates a cloud computing environment according to an embodiment of the present disclosure.

[0017] [Figure 4B] 1 illustrates an abstraction model layer according to an embodiment of the present disclosure.

[0018] [Figure 5] FIG. 1 illustrates a high-level block diagram of an exemplary computer system that may be used to implement one or more of the methods, tools, and modules, and any associated functionality described herein, according to embodiments of the present disclosure.

[0019] While the embodiments described herein are susceptible to various modifications and alternative forms, specific features thereof have been shown by way of example in the drawings and will be described in detail. It is to be understood, however, that the particular embodiments described are not to be construed in a limiting sense. On the contrary, it is intended to cover all modifications, equivalents, and alternatives within the spirit and scope of the disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0020] Aspects of the present disclosure relate generally to the field of blockchain transaction commitment, and more specifically to protecting transaction privacy in permissioned blockchains. The described embodiments address blockchain privacy concerns by redesigning the blockchain framework around a privacy-first approach that does not rely on expensive (e.g., computational costs, resource costs, etc.) cryptographic primitives. Disclosed herein are methods, systems, and computer program products that enable a modular transaction execution environment, ordering service, and internal data storage. Key contributions to the described blockchain technology / field are a novel shard-based blockchain framework with fast atomic inter-shard transactions, domain-driven transaction creation independent of the underlying data management system, and a privacy-preserving non-blocking atomic commitment protocol.

[0021] It will be readily understood that the components, as generally described and illustrated herein, could be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of at least one embodiment of a method, apparatus, non-transitory computer-readable medium, and system, as illustrated in the accompanying drawings, is not intended to limit the scope of the present application as claimed, but rather represents selected embodiments.

[0022] The features, structures, or characteristics described throughout this specification may be combined or eliminated in any suitable manner in one or more embodiments. For example, the use of the phrase "exemplary embodiment," "some embodiments," or other similar language throughout this specification indicates that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment. Thus, the appearance of the phrase "exemplary embodiment," "some embodiments," "other embodiments," or other similar language throughout this specification does not necessarily refer to the same group of embodiments, and the described features, structures, or characteristics may be combined or eliminated in any suitable manner in one or more embodiments. Furthermore, in the figures, any connection between elements can allow for one-way or two-way communication, or a combination thereof, even if the illustrated connection is a one-way or two-way arrow. Also, any device shown in the figures may be another device. For example, when a mobile device is shown transmitting information, a wired device may be used to transmit the information.

[0023] Also, while the term "message" may be used in describing the embodiments, the present application may apply to many types of networks and data. Furthermore, while example embodiments may show particular types of connections, messages, and signaling, the present application is not limited to the particular types of connections, messages, and signaling.

[0024] Exemplary embodiments provide a method, system, component, non-transitory computer-readable medium, device, or network, or combination thereof, that provides privacy-preserving, attribute-based document sharing in a blockchain network.

[0025] In one embodiment, the present application utilizes a decentralized database (e.g., a blockchain), which is a distributed storage system that includes multiple nodes that communicate with each other. The decentralized database includes an append-only immutable data structure, similar to a distributed ledger, that can maintain records among mutually untrusted parties. The untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database record, and no single peer can modify the database record unless consensus is reached among the distributed peers. For example, peers may run a consensus protocol to validate blockchain storage transactions, group the storage transactions into blocks, and build a hash chain over the blocks. In this process, a ledger is formed by ordering the storage transactions as necessary to ensure consistency. In various embodiments, a permissioned or permissionless blockchain, or a combination thereof, may be used. A public or permissionless blockchain allows anyone to participate without specific identification. A public blockchain may involve a native cryptocurrency and may use consensus based on various protocols, such as proof of work. A permissioned blockchain database, on the other hand, provides secure interactions among a group of entities that share a common purpose but do not fully trust each other, such as businesses exchanging funds, goods, information, etc.

[0026] This application is tailored to decentralized storage methods and can utilize blockchains that run arbitrary programmable logic, called "smart contracts" or "chaincodes." In some cases, there may be specialized chaincodes for managing functions and parameters, called system chaincodes. This application also utilizes smart contracts, which are trusted distributed applications that leverage the tamper-resistant properties of blockchain databases and underlying agreements between nodes, called endorsements or endorsement policies. Blockchain transactions associated with this application can be "endorsed" before being committed to the blockchain, and unendorsed transactions are ignored. The endorsement policy allows the chaincode to specify endorsers for the transaction in the form of a set of peer nodes required for endorsement. When a client submits a transaction to the peers specified in the endorsement policy, the transaction is executed and validated. After validation, the transaction enters the ordering phase, where a consensus protocol is used to generate an ordered sequence of endorsed transactions grouped into blocks.

[0027] This application may utilize nodes, which are communicating entities in a blockchain system. A "node" may perform a logical function, in the sense that multiple nodes of different types may operate on the same physical server. Nodes are grouped into trust domains and associated with logical entities that control them in various ways. Nodes may include various types, such as client or submitting client nodes, which submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to ordering services (e.g., ordering nodes). Another type of node is a peer node, which can receive client-submitted transactions, commit the transactions, and maintain a ledger state and copy of the blockchain transactions. Peers can also, but need not, have the role of endorser. An ordering service node, or orderer, is a node that performs communication services for all nodes and enforces delivery guarantees, such as broadcasting to each of the peer nodes in the system, when committing transactions and modifying the blockchain world state, also known as the initial blockchain transaction, which typically contains control and setup information.

[0028] This application utilizes a ledger, which is a sequenced, tamper-resistant record of all state transitions of a blockchain. State transitions can result from chaincode invocations (e.g., transactions) submitted by participants (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participant (e.g., peer node) can maintain a copy of the ledger. Transactions can result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as create, update, or delete. The ledger includes a blockchain (also called a chain) that is used to store immutable, sequenced records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0029] The present application may utilize a chain, which is a transaction log organized as hash-linked blocks, where each block contains a sequence of N transactions, where N is greater than or equal to 1. The block header contains the hash of the block's transactions as well as the hash of the previous block's header. In this way, all transactions on the ledger may be sequenced and cryptographically linked. Therefore, it is impossible to tamper with the ledger data without breaking the hash links. The hash of the most recently added blockchain block represents all transactions on the chain that occurred before it, allowing all peer nodes to ensure a consistent and reliable state. The chain is stored on the peer node file system (e.g., locally, on attached storage, on the cloud, etc.), efficiently supporting the append-only nature of blockchain workloads.

[0030] The current state of the immutable ledger represents the most recent values of all keys contained in the chain transaction log. The current state is sometimes called the world state because it represents the most recent key values known to the channel. Chaincode invocations perform transactions against the ledger's current state data. To make these chaincode interactions efficient, the most recent values of keys may be stored in a state database. The state database may simply be an indexed view into the chain's transaction log and therefore can be regenerated from the chain at any time. The state database may be automatically recovered (or generated on demand) upon peer node startup and before transactions are accepted.

[0031] Some advantages of the solution described and illustrated herein include a method and system for privacy-preserving, attribute-based document sharing in a blockchain network. Exemplary embodiments solve the problems of time and trust by extending database features such as immutability, digital signatures, and single source of truth. Exemplary embodiments provide a solution for privacy-preserving, attribute-based document sharing in a blockchain network. Blockchain networks can be homogeneous based on asset types and rules governing assets based on smart contracts.

[0032] Blockchains differ from traditional databases in that they do not have a central storage, but rather are decentralized, immutable, and secure storage where nodes may share changes to records in the storage. Some properties inherent to blockchains that aid in their implementation include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, and accessibility, which are further described herein. According to various aspects, a system for privacy-preserving, attribute-based document sharing in a blockchain network is implemented thanks to immutable accountability, security, privacy, permissioned decentralization, the availability of smart contracts, and the endorsement and accessibility inherent and unique to blockchains. In particular, blockchain ledger data is immutable, providing an efficient method for privacy-preserving, attribute-based document sharing in a blockchain network. Additionally, blockchain's use of cryptography provides security and builds trust. Smart contracts manage the state of assets and complete their lifecycles. An exemplary blockchain is permissioned and decentralized. Therefore, each end user may have their own copy of the ledger for access. Multiple organizations (and peers) may be onboarded onto the blockchain network. A central organization may act as an endorsing peer to verify the results, read sets, and write sets of smart contract execution. In other words, the inherent characteristics of blockchains allow for efficient processing of private transactions in a blockchain network.

[0033] One advantage of the exemplary embodiments is that they enhance the functionality of a computing system by implementing a method for processing private transactions in a blockchain network. Through the blockchain system described herein, a computing system (or a processor within a computing system) can perform functions for processing private transactions using a blockchain network by providing access to functions such as distributed ledgers, peers, cryptography, MSPs, event processing, etc. Blockchains also enable the creation of business networks and the onboarding of any user or organization for participation. As such, blockchains are more than just databases. Blockchains provide the ability to create business networks of users and onboard / offboard organizations to collaborate and perform service operations in the form of smart contracts.

[0034] Exemplary embodiments offer many advantages over traditional databases. For example, through blockchain, embodiments provide immutable accountability, security, privacy, permissioned decentralization, the ability to use smart contracts, and endorsement and accessibility inherent and unique to blockchain.

[0035] On the other hand, traditional databases cannot be used to implement the exemplary embodiments because they do not bring all parties together on a business network, do not create trusted alliances, and do not store digital assets efficiently. Traditional databases do not provide tamper-proof storage and do not protect stored digital assets. Therefore, the proposed embodiments described herein that utilize blockchain networks cannot be implemented with traditional databases.

[0036] On the other hand, if a conventional database were used to implement the exemplary embodiments, the exemplary embodiments would suffer from unnecessary drawbacks such as lack of search functionality, security, and slow transaction speeds. Therefore, the exemplary embodiments provide a specific solution to problems in the technology / field of privacy-preserving processing.

[0037] Exemplary embodiments also modify how data may be stored within a blockchain's block structure. For example, digital asset data may be securely stored within specific portions of a data block (e.g., within a header, data segment, or metadata). By storing digital asset data within a blockchain's data blocks, the digital asset data may be added to an immutable blockchain ledger through a chain linked by the block's hash. In some embodiments, a data block may differ from a traditional data block by having personal data associated with the digital asset that is not stored with the asset within a blockchain's traditional block structure. By eliminating personal data associated with digital assets, blockchain can provide the benefits of immutable accountability and security-based anonymity.

[0038] A blockchain document processor may then have two components: a private off-chain processor that manages the secure processing of private information about participants, and a ledger processor that manages the processing of common information shared with all participants in the blockchain network using the network's consensus algorithm.

[0039] According to an example embodiment, each organization that wishes to share documents with other organizations uses a blockchain document processor connected to the blockchain network. Using the document processor, the organizations can populate the ledger with a list of document templates (e.g., archived cloud storage proposals), attributes of each document template that are shared in hashed form on the ledger, combinations of key attributes from different templates for matching and sharing documents, and partnership Merkle trees (each partnership Merkle tree may be built based on the identifiers (IDs) of partner organizations (e.g., of the proposing entities)).

[0040] In some embodiments, all documents (e.g., files, etc.) are stored in an off-chain data store (e.g., a cloud server, data center, etc.). Only the pre-image, attribute hash, or document identifier (ID), or a combination thereof, is submitted as part of a blockchain transaction. For example, as proposed in this disclosure, the pre-image of the hash is stored on a specific shard in the blockchain, which privately verifies the transaction and prevents other shards from seeing the information.

[0041] FIG. 1A illustrates a blockchain architecture 100 according to an embodiment of the present disclosure. In some embodiments, the blockchain architecture 100 may include a group of specific blockchain elements, such as blockchain nodes 102. The blockchain nodes 102 may include one or more blockchain nodes, such as peers 104-110 (these four nodes are shown by way of example only). These nodes participate in many activities, such as adding and validating blockchain transactions (consensus). One or more of the peers 104-110 may endorse and / or recommend transactions based on an endorsement policy and provide an ordering service for all blockchain nodes 102 in the blockchain architecture 100. A blockchain node may initiate blockchain validation and attempt to write to a blockchain immutable ledger stored in a blockchain layer 116, a copy of which may be stored on the underlying physical infrastructure 114. A blockchain configuration may include one or more applications 124 linked to an application programming interface (API) 122 for accessing and executing stored program / application code 120 (e.g., chaincode, smart contracts, etc.), which can be created according to customized configurations desired by participants, maintain their own state, control their own assets, and receive external information, which can be deployed as transactions and installed on all blockchain nodes 104-110 through additions to the distributed ledger.

[0042] The blockchain base or platform 112 may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and underlying physical computer infrastructure that may be used to receive and store new transactions and provide access to auditors attempting to access data entries. The blockchain layer 116 may expose interfaces that provide access to the virtual execution environments necessary to process program code and interact with the physical infrastructure 114. The cryptographic trust services 118 may be used to verify transactions, such as asset exchange transactions, and keep information private.

[0043] The blockchain architecture 100 of FIG. 1A may process and execute program / application code 120 through one or more interfaces and services exposed by the blockchain platform 112. The code 120 may control blockchain assets. For example, the code 120 may store and transfer data and be executed by peers 104-110 in the form of smart contracts and associated chaincodes with other code elements subject to conditions or execution. As a non-limiting example, smart contracts may be created to perform tasks such as creating storage space, reserving storage space, updating current proposals, etc. The smart contract itself may be used to identify authentication and access requirements and rules associated with ledger use. For example, document attribute information 126 may be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 116. The results 128 may include multiple linked shared documents (e.g., each linked shared document recording a smart contract issuance, etc.). The physical infrastructure 114 may be utilized to obtain any of the data or information described herein.

[0044] Smart contracts may be created via high-level application and programming languages and written into blocks within a blockchain. Smart contracts may include executable code that is registered, stored, or replicated on the blockchain (e.g., a decentralized network of blockchain peers), or a combination thereof. A transaction is the execution of smart contract code that may be executed in response to conditions associated with the smart contract being met. Execution of a smart contract may trigger trusted modifications to the state of the digital blockchain ledger. Modifications to the blockchain ledger caused by smart contract execution may be automatically replicated across the decentralized network of blockchain peers through one or more consensus protocols.

[0045] Smart contracts can write data to the blockchain in the format of key-value pairs. Additionally, smart contract code can read values stored on the blockchain and use them in application operations. Smart contract code can write the output of various logic operations to the blockchain. Code can be used to create temporary data structures in virtual machines or other computing platforms. Data written to the blockchain can be public, or kept private and encrypted, or both. The temporary data used / generated by smart contracts is kept in memory by the provided execution environment and deleted once the data needed for the blockchain is identified.

[0046] Chaincode may include a code interpretation of a smart contract, with additional features. As described herein, chaincode may be program code deployed on a computing network that is executed and verified by chain validators together during the consensus process. The chaincode receives hashes and retrieves hashes from the blockchain associated with data templates created using pre-stored feature extractors. If the hash of the hash identifier and the hash created from the stored identifier template data match, the chaincode sends an authentication key to the requested service. The chaincode may write associated cryptographic details to blockchain data (e.g., thereby atomically committing the transaction to the blockchain).

[0047] FIG. 1B illustrates an example of a blockchain transaction flow 150 between nodes of a blockchain, according to an example embodiment. Referring to FIG. 1B, the transaction flow may include a transaction proposal 191 sent by an application client node 160 to an endorsing peer node 181 (e.g., in some embodiments, the transaction proposal 191 may be sent for endorsement upon determining that a preimage of a hash associated with the transaction proposal 191 matches a stored preimage in a particular shard). The endorsing peer 181 may verify the client signature and execute a chaincode function to initiate the transaction. The output may include the chaincode result, a set of key / value versions read by the chaincode (the read set), and a set of key / values written to the chaincode (the write set). A proposal response 192, if approved, is sent back to the client 160 along with the endorsement signature. The client 160 assembles the endorsement into a transaction payload 193 and broadcasts it to the ordering service node 184. The ordering service node 184 then distributes the ordered transactions as a block to all peers 181-183 on the channel. Before committing it to the blockchain, each peer 181-183 may validate the transaction. For example, a peer may check an endorsement policy to ensure that the correct allocation of a specified peer signed the result and authenticated the signature against the transaction payload 193.

[0048] Referring again to FIG. 1B , a client node 160 initiates a transaction 191 by constructing and sending a request to an endorser peer node 181. The client 160 may include an application that utilizes a supported software development kit (SDK) that utilizes available APIs to generate a transaction proposal 191. The proposal is a request that invokes chaincode functions to read and / or write data to the ledger (e.g., write a new key-value pair for an asset). The SDK may act as a shim that packages the transaction proposal 191 in a suitably designed format (e.g., protocol buffers over remote procedure calls (RPCs)), obtains the client's cryptographic credentials, and generates a unique signature for the transaction proposal 191.

[0049] In response, the endorsing peer node 181 may verify that (a) the transaction proposal 191 is well-formed, (b) the transaction has not already been submitted in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (in this example, client 160) is properly authorized to perform the proposed operation on that channel. The endorsing peer node 181 may receive the transaction proposal 191 input as an argument to a called chaincode function. The chaincode then runs against the current state database and generates a transaction result that includes a response value, a read set, and a write set. However, the ledger is not updated at this point. At 192, the set of values, along with the endorsing peer node 181's signature, is returned as a proposal response 192 to the client 160's SDK, which parses the payload for the application to consume.

[0050] In response, the application on the client 160 inspects / verifies the signature of the endorsing peer and compares the proposal response to determine whether the proposal response is the same. If the chaincode only queried the ledger, the application inspects the query response and typically does not submit the transaction to the ordering node service 184. When a client application attempts to submit a transaction to the ordering node service 184 to update the ledger, the application determines whether the specified endorsement policy is satisfied (e.g., whether all peer nodes with the specific shards required for the transaction have endorsed the transaction) before submitting. Here, the client may include only one of multiple parties to the transaction. In this case, each client may have its own endorsing node, and each endorsing node must endorse the transaction. In the architecture, even if the application chooses not to inspect the response or chooses to forward the unendorsed transaction, the endorsement policy is still enforced by the peers and confirmed in the commit verification phase.

[0051] After successful validation, in step 193, client 160 assembles the endorsements into a transaction and broadcasts the transaction proposal 191 and response in a transaction message to ordering node 184. The transaction may include a read / write set, an endorsing peer signature, and a channel ID. Ordering node 184 does not need to validate the entire contents of the transaction to perform its operation; instead, ordering node 184 may simply receive transactions from all channels in the network, order them chronologically by channel, and create blocks of transactions per channel.

[0052] A block of transactions is distributed from the ordering node 184 to all peer nodes 181-183 on the channel. The transactions 194 in the block are validated to ensure that any endorsement policies are met and to ensure that no changes have occurred to the ledger state with respect to the readset variable since transaction execution generated the readset. Transactions in the block are tagged as valid or invalid. Furthermore, in step 195, each peer node 181-183 adds the block to the channel's chain, and for each valid transaction, the writeset is committed to the current state database. An event is emitted to notify the client application that the transaction (invocation) has been immutably added to the chain, as well as whether the transaction has been validated or invalidated.

[0053] Referring now to FIG. 2A , a block diagram of an exemplary system 200 for atomically committing a transaction to a blockchain network is shown, according to an embodiment of the present disclosure. In some embodiments, the system 200 includes a transaction 202 that includes a first hash 204 and a second hash 206. The system 200 further includes a first shard 208, a second shard 210, and a third shard 212. The system continues with a first validation 214, a second validation 216, an unknown preimage 218, an atomic commit (e.g., command, operation, module, node, etc.) 220, and an ignore (e.g., command, operation, module, node, etc.) 222. In some embodiments, the transaction 202 is submitted to the system 200, validated, and committed by / to the blockchain network. The transaction 202 is split into the first hash 204 and the second hash 206, each having an associated preimage (e.g., not shown). The pre-images of hashes 204, 206 are then sent to all, one, or any combination of shards 208-210 that have a copy of either the pre-image associated with first hash 204 or second hash 206.

[0054] As shown, the first shard 208 includes a copy of the pre-image associated with the first hash 204, the second shard 210 includes a copy of the pre-image associated with the second hash 206, and the third shard 212 does not include a copy of any pre-image. In some embodiments, the first shard 208 enables a node / peer housing / utilizing the first shard 208 to perform a first validation 214, and the second shard 210 enables a node / peer housing / utilizing the second shard 210 to perform a second validation 216. In some embodiments, upon validation 214, 216, an atomic commit 220 is performed and the transaction is committed to the blockchain network.

[0055] In some embodiments, the node / peer housing / utilizing the third shard 212 identifies that the unknown pre-image 218 was sent to the node / peer of the third shard 212, and the unknown pre-image 218 is ignored by ignore 222. In some embodiments, the atomic commit 220 and ignore 222 are performed simultaneously. Note that the system 200 depicted enables committing a transaction (e.g., transaction 202) to a blockchain network without disclosing information to the entire blockchain network.

[0056] Additionally, it should be noted that certain assumptions are made regarding system 200 (and systems 230, 250 of FIGS. 2B-C), which are detailed below.

[0057] All operations running on network participants and communications between network nodes are partially synchronous. More specifically, for each communication round, there is an upper bound on the latency Δε[1, ∞], measured in rounds, for each message sent between two correct nodes.

[0058] The hash function and public key infrastructure (PKI) cannot be broken intentionally. Note that the presented network setup described herein is permissioned, e.g., all participants are known and have assigned roles in a manner similar to current implementations of (Hyperledger) Fabric. As such, it is further assumed that communications are authenticated point-to-point, e.g., using Transport Layer Security (TLS).

[0059] Each node in the network (roughly corresponding to a peer in Fabric) belongs to at least one privacy shard. All nodes replicate the same ledger, but only share their view of the world state with other nodes in the same privacy shard. A complete world view is created by merging all local shard states. Therefore, it is further assumed that all nodes and their shard memberships are known to all other nodes in the network. However, nodes do not leak information not specified in their local state or the protocols described herein. Furthermore, we assume that while nodes may behave poorly, the shard as a whole is honest, inquisitive, and non-failure-prone.

[0060] Clients are entities that interact with the ledger. They are responsible for initiating transactions. Multiple clients can collaborate and create transactions together. Each of these clients can be Byzantine-faulty. In particular, some or all of the clients involved can collude against the rest of the network.

[0061] An asset is a collection of data representing either a physical object or a virtual concept on the ledger. As disclosed herein, assets are first-class citizens and the primary point of interaction with the blockchain. By modeling them like objects in object-oriented programming, such smart assets manage their own data. They track their internal state and only make public APIs available for interaction. This splits traditional smart contracts into two parts: asset definitions and business logic, based on interactions between one or more smart assets. Each can be handled by different subject matter experts, facilitating application development, interoperability, and asset configuration. Asset definitions, such as their internal workings and public APIs, are installed in privacy shards. This allows different shards to offer different smart asset definitions, similar to how a bank offers a variety of financial product options. It is further envisioned that all API calls populate a data transfer object (DTO) containing all the data necessary for the requested state transition. All DTOs and the assets themselves may implement the interfaces GetID() and GetStakeholders(). The former ensures that the ledger can find previously created assets, and the latter is necessary to validate stakeholder policies, as described below. It should be noted that the methods, systems, and computer program products disclosed herein are not asset-specific, but rather transaction-independent.

[0062] Furthermore, it is assumed that every asset must have a defined set of stakeholders. For example, an IOU asset requires a borrower and a lender as stakeholders. When installing an asset definition, each API may register a stakeholder policy. Whenever a client calls an API, they may provide one or more stakeholder signatures that satisfy the policy of the function call. For example, the policy for a withdrawal request from a joint bank account may require the signature of one of two stakeholders. Stakeholders are part of the internal state of the asset and may change over time.

[0063] From a conceptual perspective, the existence of stakeholders prevents double-spending in a forkless ledger like the one presented here. Every time a stakeholder transfers ownership of an asset to a new stakeholder, the asset will no longer accept the old stakeholder's signature. If a malicious stakeholder attempts to create two transfers for the same asset, they will eventually appear perfectly ordered on the global ledger. And when the second transaction is validated, because the first transaction changes stakeholders, it will violate the asset's stakeholder policy and be discarded.

[0064] A transaction is a semantic unit of concurrent state transitions, submitted to the ledger by a client. It may involve multiple privacy shards and complex dependencies between the different parts. For example, a transaction may consist of three state transitions. The first transition on shard A and the second transition on shard B commit dependently, thereby guaranteeing an atomic interaction. The third transition involves shard C, but is independent of the other two parts. This can lead to a situation where A and B abandon the transaction and C commits it. This is permissible behavior because it protects the correctness of each shard's local state and ensures that the atomic parts of the transaction are consistent. If the parts on shard C were truly independent of A and B, it should be fine for them to be abandoned. If this were not the case, the third part would need to receive a dependency, subject to the atomicity guarantee.

[0065] The ordering service is responsible for creating a global order of transactions. Like privacy shards, the ordering service is considered a "black box" in the described scenario. As such, the ordering service operates honestly but inquisitively. Furthermore, it creates a total order of transactions submitted by clients, divides this order into blocks, and distributes the blocks to all privacy shards in the network. As explained herein and described in more detail below, it is architecturally unknown which shards are involved in a single transaction. Therefore, it is not possible for the global ordering service to distribute transactions only to the involved shards.

[0066] Referring again to Figure 2A, a simplified example is illustrated, where say one client, Bob, wants to borrow $100 from another client, Alice. To this end, they borrow $100 from the privacy shard s where their asset definition is installed. iouIn exchange, Alice will receive a privacy shard s token Transfer $100 worth of existing assets stored in to Bob. These two actions belong to the same transaction and can be performed atomically.

[0067] In another example, Alice and Bob negotiate the contents of the DTO for a CreateIOU call. As mentioned before, GetID() and GetStakeholders() are already implemented, so they just need to ensure that they add their public keys to mark them as stakeholders and agree on the correct values. This negotiation is done entirely between the participating clients, without the involvement of shards or ordering services.

[0068] Once both Bob and Alice are happy with the IOU creation DTO, the shards iou Prepare a request to . This request consists of a uniquely specified name of the function call (in this case CreateIOU), the corresponding DTO, an optional request ID, and the set of shards this request depends on. The request ID ensures that a shard receiving this request can distinguish between a malicious / accidental replay of the same request and a real second request that happens to have the same parameters. {s token By adding} as a dependency set to the request, Alice and Bob can token that s needs to validate another part of the transaction iou In this case, s iou is, s token Commit your changes only if you also commit them (more on this below).

[0069] The set of clients that satisfy the stakeholder policy of the function call in the request must sign the Merkle root hash of the four parts of the request using the same private key belonging to the stakeholder public key. The receiving shard later checks whether these signatures comply with the stakeholder policy. In the case of CreateIOU, s iouThe policy registered in requires both the borrower and lender to sign the request, so both Alice and Bob add their signatures. These signatures ensure that no client can create a valid request that has not been confirmed by the required number of stakeholders.

[0070] Finally, Bob, sending a request to a shard, confirms that he is authorized to make requests to the shard by adding a signature related to his role in the network to the message (Table 2). An example of such a role is a writer, someone who is authorized to create requests and transactions. This last signature is not considered part of the message and is discarded by the shard after verification, so no information about the sender of the request is leaked to the rest of the network. The request ID associates each client signature with a specific request, and a malicious client cannot reuse a signature without replaying the entire request. This is addressed by duplication prevention at the shard.

[0071] Shards iou When receives a request from Bob, it first checks for duplicate requests, then unpacks the payload and verifies the signature against the CreateIOU stakeholder policy using the DTO's GetStakeholders() interface to receive the required public keys. If this verification fails, the shard simply responds with an error message. Otherwise, the next steps depend on the shard's configuration.

[0072] In some embodiments, since the blockchain's execution engine is completely decoupled from the transaction flow, a shard may be configured to either perform a pre-ordering execution, a post-ordering execution, or some mix of the two. If the shard performs a pre-ordering execution, it simulates CreateIOU and stores the result in a local temporary store. If the shard is configured to perform a post-ordering execution, the result payload is empty. In either case, the shard then calculates the Merkle root hash (σ roleThe shard then returns only the hash of the pre-image and its signature. Note that the client does not need to know the result of the request; the hash in the response simply serves as a pre-image anchor for the transaction.

[0073] In some embodiments, the above steps may be repeated for all parts of the complete transaction. Therefore, Alice and Bob must also agree on which assets Alice will transfer to Bob. They iou} as a dependency set. In this way, the token transfer is iou It will only be executed if s also commits its part of the transaction. Then Alice can send the request to s token , where the specific asset is held. token loads the asset from the database using the GetID interface of the TransferToken request DTO. This way, both the stakeholder of the request and the existing asset can be validated together. In this case, the asset owner must also be a stakeholder of the transfer. This translates to a policy: "One signature must match both the single stakeholder of the existing asset and one stakeholder of the transfer. The other signature must match only the other stakeholder of the transfer."

[0074] In general, multiple requests to different shards can be processed simultaneously, since the only link between them is the dependency set, which is only used during validation after the transaction has been submitted. Note that none of the shards involved knows what the requests to the other shards are.

[0075] In some embodiments, Alice and Bob access shard s iou and s token After receiving the responses from each, she collects and hashes them, then signs the Merkle root hash with the same private key she used for the individual requests. As with the previous single request, Alice attaches a signature associated with her role in the network and submits the entire transaction to the ordering service.

[0076] A transaction consists of the hash of all shard responses involved in the transaction and the Merkle root signatures of all involved stakeholders. We distinguish between stakeholders and clients here because a single client may use a different key pair for each request to a shard. In that case, this client needs to sign the transaction using all involved private keys. It is important to point out that the client signs the Merkle root without needing to know exactly the preimage of the responses. This allows for partially opaque transactions.

[0077] Another example is a netting scenario in which three clients, Alice, Bob, and Cerise, owe each other $10 in a circular manner. Alice is willing to cancel her IOU with Bob if Cerise also cancels her IOU at the same time. Similarly, Bob and Cerise are willing to do the same. However, no client needs to know the agreement between the other two clients to be confident that the netting will work for them. Therefore, they create a transaction with three parts, and each client will only know two of the hashed shard responses. To guarantee atomicity, the three parts of the netting transfer must be combined into a single transaction. Nevertheless, all clients can sign the transaction's Merkle root because they are confident that the opaque part of the transaction does not involve any of their own assets. Otherwise, they would have had to sign requests that would result in the creation of opaque hashes within the transaction. Note that a transaction can implicitly include multiple hashed responses from the same shard.

[0078] In some embodiments, when the ordering service receives a new transaction, it verifies the client's role, discards its signature, and places the transaction in a new block, which is then distributed across the network. Because the ordering service only sees the hash and signature associated with an unknown public key, it cannot learn anything about the client's (except the sender) identity or even which privacy shards are involved. However, it can learn the number of shards and clients involved. If this leakage is a concern, the client can add any number of false (e.g., false, fake, etc.) hashes and signatures to the transaction from the previous step to obscure the true number of participants. Furthermore, if it is necessary to keep the identity of the true sender secret, a proxy client can be used to broadcast the transaction to the ordering service.

[0079] In some embodiments, in the case of an IOU, shards iou and s token Both s scan all transactions in each new block they receive. They compare each Merkle leaf of a transaction with the hash of a previously created but not yet validated pre-image. Thus, at some point, s iou recognizes the hash of the response to the CreateIOU request. To check that the known hash is part of a valid transaction, s iou verifies that all stakeholders in the pre-image have also signed the complete transaction. If this is not the case, the transaction may have been created without the knowledge of one of the stakeholders in the request.

[0080] s iou If s is configured to perform preordering, it has already stored the results of the simulated requests. The results may now be out of date, so you must ensure that the results are still valid. Instead, s iou If s is configured to perform post-ordering execution, it simulates the result as described above and checks for validity. In either case, if the result is invalid, it discards the transaction and moves on. If the result is valid, it checks whether that part of the transaction was also valid by s token For this purpose, we use the Merkle root of the transaction in question as s token Send to.

[0081] Meanwhile, s token did the same, so each shard responds to the other shard's queries with a success or failure message. If a shard receives a failure message, it discards the local result, even if it was valid. Otherwise, the result is committed to the local ledger state. This ensures that either the IOU creation and token transfer occur, or neither.

[0082] As a further example, in scenarios with more than two shards, the commit protocol becomes more complex. Imagine a scenario with four shards: s0, s1, s2, and s3. Each shard s i There are two shards i-1 mod 4 and s i+1 mod 4 If s1 is valid and the responses from s0 and s2 are also valid, then go ahead and commit. However, it may be the case that s1 queries before any of the other shards get a response from s3. If s3 is invalid, then both s0 and s2 change their results to invalid. Therefore, s1 should not have committed that part of the transaction. This means that we should perform a variant of atomic commit (AC) across all involved shards.

[0083] Furthermore, to handle ambiguous corner cases, a transaction may contain multiple requests to the same shard. In such cases, the computation results are verified in the same order as the associated hashes appear in the transaction. This order is fixed by the transaction's signed Merkle root, so the result is deterministic as long as the results of all verifications are deterministic. Next, a shard with multiple requests, s, multi Any dependent shards dep In some cases, it is not possible to tie hashes in a transaction to a specific shard, so s dep In a further case, s multi Since a dependency set does not necessarily generate bidirectional dependencies, s dep does not know which request s wants a response to. multi is depcan only give a single answer to a single shard. The only way to preserve the atomicity of the validation that a single response depends on is to aggregate all request results in an all-or-nothing manner. Thus, the response from any shard is the transaction hash queried by other shards and a single success or failure, independent of the number of requests it makes to validate.

[0084] Note that, in general, to guarantee determinism, transactions must be validated sequentially. However, shards may be able to infer transaction dependencies. In particular, if a shard uses preordering, it may be able to find transactions that only touch a distinct state. In such cases, a validating shard can validate independent transactions in parallel to avoid being completely blocked by a single transaction waiting for a response from another shard. However, even if transaction dependency analysis is not possible, all shards are guaranteed to eventually progress, assuming there are no permanent network partitions. By the time a transaction is submitted to the ordering service, all participating shards have seen their own associated preimages. Otherwise, the shard would not have been able to sign the response to the client's request. If a shard does not recognize a hash in a transaction, it can ignore it, either because it belongs to another shard or because it is an invalid hash. Thus, when a shard initiates the atomic commit protocol for a particular transaction, each participating shard can reliably determine its own starting value. The commitment delay is determined by the most recent shard to receive a block and the latency of the atomic commit protocol. Everything will be decided in the end, assuming all shards are functioning normally.

[0085] We emphasize that this disclosure does not guarantee the complete commitment or revocation of a transaction, but only the atomicity of dependent parts. Suppose a transaction consists of two independent parts. Each corresponding shard verifies that the stakeholders of that part are a subset of the complete set of transaction signatures. In this case, the first shard cannot and should not determine whether the second shard was able to verify the signatures. Thus, it is possible for the first shard to commit a change and for the second shard to reject it. However, since both parts are semantically independent by definition, this cannot lead to inconsistencies or attacks on the global state of the ledger.

[0086] 2B, a block diagram of an example system 230 for atomically committing horizontal cut transactions to a blockchain network is shown, according to an embodiment of the present disclosure. Note that various descriptions of system 230 may utilize the scenarios or descriptions described above with respect to system 200 of FIG. 2A.

[0087] In some embodiments, system 230 may include transaction 232 that is split into a first hash 234 and a second hash 236. In some embodiments, a pre-image (not shown) of each of hashes 234, 236 may be sent to either a first shard 238, a second shard 240, or both shards 238, 240. As shown, but not limited to, first shard 238 identifies that it already holds a matching (same) pre-image of the submitted first hash 234. Furthermore, second shard 240 identifies that it already holds a matching pre-image of the second hash 236.

[0088] In some embodiments, once shards 238, 240 identify that they have pre-images of hashes 234, 236, respectively, the first shard 238 generates a first identification (ID) tag 242 and the second shard 240 generates a second ID tag 244. In some embodiments, the tags 242, 244 are committed to the blockchain via an atomic commit 252. In some embodiments, before, after, or simultaneously with the atomic commit 252, the first ID tag 242 is presented to a first user 246 and a second user 248. Additionally, the second ID tag 244 is presented to the first user 246 and a third user 250.

[0089] For example, a transaction for a farmer to deliver crops to a dealer may be split into two hashes: one hash for the shipper delivering the crop to the dealer, and another hash for the crop being delivered to the dealer. Before the transaction is initiated, a first shard in the blockchain is sent a pre-image of the hash for the shipper, and a second shard in the blockchain is sent a pre-image of the hash for the crop.

[0090] When a farmer initiates a transaction with a seller, pre-images of both hashes are sent to each shard, and each shard with a matching pre-image generates an identity that is transparent to the farmer and either the carrier or the seller: the farmer knows both the carrier used and the crop being delivered, but the seller only knows the crop being delivered (as the seller does not need to know the carrier being used).

[0091] 2C, a block diagram of an example system 260 for atomically committing vertical cut transactions to a blockchain network is shown, according to an embodiment of the present disclosure. Note that various descriptions of system 260 may utilize the scenarios or descriptions described above with respect to system 200 of FIG. 2A.

[0092] In some embodiments, system 260 may include transaction 262 that is split into a first hash 264 and a second hash 266. In some embodiments, a pre-image (not shown) of each of hashes 264, 266 may be sent to either a first shard 268, a second shard 270, or both shards 268, 270. As shown, first shard 268 identifies that it already holds a matching (same) pre-image of the submitted first hash 264, but is not limited to this. Furthermore, second shard 270 identifies that it already holds a matching pre-image of the second hash 266.

[0093] In some embodiments, when the first shard 268 identifies that it has a matching preimage for the first hash 264, the first shard 268 executes a first task 272. Additionally, when the second shard 270 identifies that it has a matching preimage for the second hash 266, the second shard 270 executes a second task 274. In some embodiments, once the first task 272 and the second task 274 are executed, an atomic commit 276 may be executed.

[0094] For example, a transaction for Bob to purchase a house from Alice for $100,000 may be submitted to a blockchain network. The transaction may be split into two hashes, with a first hash relating to the transfer of ownership of the house from Alice to Bob and a second hash relating to the transfer of $100,000 from Bob to Alice. In some embodiments, before the transaction is initiated, a respective preimage of each hash may be sent to a first shard and a second shard, respectively. When the transition is initiated, both preimages are sent to both the first shard and the second shard, and each shard identifies that it has a matching respective preimage. In some embodiments, the first shard contains the preimage associated with the first hash and performs the task of transferring ownership of the house from Alice to Bob, and the second shard contains the preimage associated with the second hash and performs the task of transferring $100,000 from Bob to Alice.

[0095] 3A, a flowchart of an example method 300 for processing private transactions in a blockchain network is shown, in accordance with an embodiment of the present disclosure. In some embodiments, method 300 may be performed by a processor (e.g., a node, a computer system, etc.) in the blockchain network.

[0096] In some embodiments, method 300 begins at operation 302, where a processor generates a request associated with a transaction. Method 300 proceeds to operation 304, where the processor collects anchors associated with the request. In some embodiments, method 300 proceeds to operation 306, where the processor transitions the transaction into a set of two or more hashes. Method 300 proceeds to operation 308, where the processor submits the transaction to an ordering service. In some embodiments, method 300 ends.

[0097] Further operations that may be performed by method 300 but are not shown in FIG. 3A are described more fully below. Thus, in some embodiments, the request may be a processable action that modifies the blockchain ledger. In some embodiments, method 300 further proceeds with the processor validating the transaction with two or more shards in the blockchain network (which may be housed in / on the processor). The transaction may be validated locally (e.g., without visibility by other shards in the blockchain) by two or more shards.

[0098] In some embodiments, two or more shards verify the transaction by having method 300 further proceed with having the processor receive, by each of the two or more shards, a respective known pre-image associated with the two or more hashes. The processor matches, by each of the two or more shards, the respective known pre-image to the two or more hashes.

[0099] In some embodiments, method 300 further proceeds with the processor performing an atomic commit of the request by two or more shards (within / on the processor). In some embodiments, the atomic commit may be performed without each known pre-image being shared with any of the other two or more shards.

[0100] 3B, a flowchart of a further exemplary method 330 for processing private transactions in a blockchain network is shown, in accordance with an embodiment of the present disclosure. In some embodiments, method 330 may be performed by a processor (e.g., a node, a computer system, etc.) within the blockchain network.

[0101] In some embodiments, method 330 begins at operation 332, where a processor receives a request associated with a transaction. Method 330 proceeds to operation 334, where the processor identifies that a first pre-image associated with the first hash is known to the first shard. Method 330 proceeds to operation 336, where the processor generates a first identification tag associated with the transaction. In some embodiments, method 330 ends.

[0102] Further operations that may be performed by method 330 but are not shown in Figure 3B are described more fully below. Thus, in some embodiments, method 330 further proceeds with the operation of the processor identifying that a second pre-image associated with the second hash is known to the second shard. The processor generates a second identification tag associated with the transaction.

[0103] In some embodiments, the first identification tag is displayed to the first user and the second user, and the second identification tag is displayed to the first user and the third user. In some embodiments, the method 330 further proceeds with the processor verifying the transaction. The processor then atomically commits the transaction to the blockchain network.

[0104] 3C, a flowchart of an exemplary method for processing private transactions in a blockchain network is shown, in some embodiments, the method 350 may be performed by a processor (e.g., a node, a computer system, etc.) in the blockchain network, according to an embodiment of the present disclosure.

[0105] In some embodiments, method 350 begins at operation 352, where a processor receives a request associated with a transaction. Method 350 proceeds to operation 354, where the processor assigns a first task to a first shard. Method 350 proceeds to operation 356, where the processor identifies that a first pre-image associated with the first hash is known to the first shard. Method 350 proceeds to operation 358, where the processor executes the first task. In some embodiments, method 350 ends.

[0106] Further operations that may be performed by method 350 but are not shown in FIG. 3C are described more fully below. Thus, in some embodiments, method 350 further proceeds with an operation in which the processor assigns a second task to a second shard. The processor identifies that a second preimage associated with the second hash is known to the second shard. The processor executes the second task. In some embodiments, the first task and the second task are executed as part of an atomic commit of the transaction.

[0107] Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the teachings described herein is not limited to a cloud computing environment. Rather, embodiments of the present disclosure can be implemented in conjunction with any other type of computing environment now known or later developed.

[0108] Cloud computing is a service delivery model for enabling 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 administrative effort or interaction with the service provider. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0109] The characteristics are as follows:

[0110] On-demand self-service: Cloud consumers can unilaterally provision computing capacity, such as server time or network storage, automatically as needed, without requiring human interaction with the service provider.

[0111] Wide network access: Functionality is available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (eg, cell phones, laptops, and PDAs).

[0112] Resource Pooling: A provider's computing resources are pooled to serve multiple customers using a multi-tenant model, with various physical and virtual resources dynamically allocated and reallocated according to demand. Customers generally do not control or know the exact portion of the resources provided, but there is a sense of portion independence in that they may be able to specify portions at a higher level of abstraction (e.g., country, state, or data center).

[0113] Rapid Elasticity: Capabilities can be provisioned quickly and elastically, and in some cases can be automatically provisioned to quickly scale out and released to quickly scale in. To the consumer, the capabilities available for provisioning often appear unlimited, and any quantity can be purchased at any time.

[0114] Metering Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of utilized services.

[0115] The service model is as follows:

[0116] Software as a Service (SaaS): The consumer is offered the ability to use the provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through a thin-client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or individual application functions, with the possible exception of limited user-specific application configuration settings.

[0117] Platform as a Service (PaaS): The functionality offered to consumers is the deployment of consumer-created or acquired applications on a cloud infrastructure, written using programming languages and tools supported by the provider. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they do control the deployed applications and, in some cases, the application hosting environment configuration.

[0118] Infrastructure as a Service (IaaS): The capability provided to the customer is to provision processing, storage, network, and other basic computing resources on which the customer can deploy and run any software, which may include operating systems and applications. The customer does not manage or control the underlying cloud infrastructure, but does control the operating system, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0119] The deployment model is as follows:

[0120] Private Cloud: Cloud infrastructure is operated solely for one organization. It can be managed by the organization or a third party and can exist on-premise or off-premise.

[0121] Community Cloud: Cloud infrastructure is shared among several organizations to support a specific community with common interests (e.g., mission, security requirements, policies, compliance considerations). It may be managed by the organization or a third party and may exist on-premises or off-premises.

[0122] Public Cloud: Cloud infrastructure is made available to the general public or large industry organizations and is owned by organizations that sell cloud services.

[0123] Hybrid Cloud: Cloud infrastructure is a blend of two or more clouds (private, community, or public) that remain unique entities but are tied together by standardized or proprietary technologies (e.g., cloud bursting for load balancing between clouds) that allow for data and application portability.

[0124] Cloud computing environments are service-oriented, emphasizing statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that comprises a network of interconnected nodes.

[0125] 4A illustrates a cloud computing environment 410. As illustrated, the cloud computing environment 410 includes one or more cloud computing nodes 400 with which local computing devices used by cloud users, such as, for example, a personal digital assistant (PDA) or mobile phone 400A, a desktop computer 400B, a laptop computer 400C, or an automobile computer system 400N, or combinations thereof, may communicate. The nodes 400 may communicate with each other. They may be physically or virtually grouped in one or more networks (not shown), such as a private cloud, a community cloud, a public cloud, or a hybrid cloud, or combinations thereof, as described hereinabove.

[0126] This allows the cloud computing environment 410 to provide infrastructure, platform, and / or software as a service without requiring the cloud consumer to maintain resources on a local computing device. It will be understood that the types of computing devices 400A-N shown in Figure 4A are intended to be exemplary only, and that the computing nodes 400 and the cloud computing environment 410 can communicate with any type of computerized device over any type of network and / or network-addressable connection (e.g., using a web browser).

[0127] 4B illustrates a set of functional abstraction layers provided by the cloud computing environment 410 (FIG. 4A). It should be understood in advance that the components, layers, and functions illustrated in FIG. 4B are merely for illustrative purposes, and embodiments of the present disclosure are not limited thereto. As shown below, the following layers and corresponding functions are provided:

[0128] Hardware and software layer 415 includes hardware and software components. Examples of hardware components include mainframe 402, RISC (reduced instruction set computer) architecture-based servers 404, servers 406, blade servers 408, storage devices 411, networks, and network and networking components 412. In some embodiments, software components include network application server software 414 and database software 416.

[0129] Virtualization layer 420 provides an abstraction layer at which the following examples of virtual entities can be provided: virtual servers 422, virtual storage 424, virtual networks 426, including virtual private networks, virtual applications and operating systems 428, and virtual clients 430.

[0130] In one example, management layer 440 may provide the functions described below. Resource provisioning 442 provides dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 444 provides cost tracking as resources are utilized within the cloud computing environment and vouchers or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification of cloud users and tasks, as well as protection of data and other resources. User portal 446 provides access to the cloud computing environment for users and system administrators. Service level management 448 provides allocation and management of cloud computing resources to ensure required service levels are met. Service level agreement (SLA) planning and fulfillment 450 provides advance provisioning and procurement of cloud computing resources for anticipated future needs in accordance with SLAs.

[0131] Workload tier 460 provides examples of functions for which a cloud computing environment may be utilized. Examples of workloads and functions that may be provided from this tier include mapping and navigation 462, software development and lifecycle management 464, virtual classroom instruction delivery 466, data analytics processing 468, transaction processing 470, and atomic commit 472.

[0132] 5 illustrates a high-level block diagram of an exemplary computer system 501 that may be used to implement (e.g., using one or more processor circuits of a computer or computer processor) one or more of the methods, tools, and modules, and any associated functionality described herein, according to embodiments of the present disclosure. In some embodiments, major components of computer system 501 may include one or more CPUs 502, a memory subsystem 504, a terminal interface 512, a storage interface 516, an I / O (input / output) device interface 514, and a network interface 518, all of which may be communicatively coupled, directly or indirectly, for inter-component communication via a memory bus 503, an I / O bus 508, and an I / O bus interface unit 510.

[0133] Computer system 501 may include one or more general-purpose programmable central processing units (CPUs) 502A, 502B, 502C, and 502D, collectively referred to herein as CPUs 502. In some embodiments, computer system 501 may include multiple processors typical of relatively large systems, while in other embodiments, computer system 501 may instead be a single-CPU system. Each CPU 502 may execute instructions stored in memory subsystem 504 and may include one or more levels of on-board cache.

[0134] The system memory 504 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 522 or cache memory 524. The computer system 501 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 526 may be provided for reading from and writing to non-removable, non-volatile magnetic media, such as a “hard drive.” Although not shown, a magnetic disk drive may be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk”), or an optical disk drive may be provided for reading from and writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media. Additionally, the memory 504 may include flash memory, such as a flash memory stick drive or flash drive. Memory devices may be connected to the memory bus 503 by one or more data media interfaces. The memory 504 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of various embodiments.

[0135] One or more programs / utilities 528, each having at least one set of program modules 530, may be stored in memory 504. The programs / utilities 528 may include a hypervisor (also called a virtual machine monitor), one or more operating systems, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may include implementing a networking environment. The programs 528 and / or program modules 530 generally perform the functions or methods of various embodiments.

[0136] 5 as a single bus structure providing a direct communication path between CPU 502, memory subsystem 504, and I / O bus interface 510, memory bus 503, in some embodiments, may include multiple distinct buses or communication paths that may be configured in any of a variety of forms, such as point-to-point links in a hierarchical, star, or web configuration, multiple hierarchical buses, parallel redundant paths, or any other suitable type of configuration. Additionally, while I / O bus interface 510 and I / O bus 508 are each shown as single units, computer system 501, in some embodiments, may include multiple I / O bus interface units 510, multiple I / O buses 508, or both. Additionally, while multiple I / O interface units are shown isolating I / O bus 508 from the various communication paths extending to the various I / O devices, in other embodiments, some or all of the I / O devices may be directly connected to one or more system I / O buses.

[0137] In some embodiments, computer system 501 may be a multi-user mainframe computer system, a single-user system, or a server computer or similar device that has little or no direct user interface but receives requests from other computer systems (clients). Further, in some embodiments, computer system 501 may be implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a telephone, a smartphone, a network switch or router, or any other suitable type of electronic device.

[0138] It should be noted that Figure 5 is intended to illustrate representative major components of an exemplary computer system 501. However, in some embodiments, the individual components may be more or less complex than depicted in Figure 5, there may be components other than or in addition to those depicted in Figure 5, and the number, type, and configuration of such components may vary.

[0139] As described in more detail herein, it is contemplated that some or all of the operations of some embodiments of the methods described herein may be performed in an alternative order or not at all, and further, multiple operations may occur simultaneously or as part of a larger process.

[0140] The present disclosure may be a system, method, or computer program product, or a combination thereof, at any possible level of integration of technical details. The computer program product may include a computer-readable storage medium having computer-readable program instructions for causing a processor to perform aspects of the present disclosure.

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

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

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

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

[0145] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus to create a machine, whereby the instructions, executed via the processor of the computer or other programmable data processing apparatus, generate means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner, whereby a computer-readable storage medium having instructions stored thereon includes a product comprising instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

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

[0147] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be implemented as a single step, executed concurrently, substantially concurrently, partially, or fully in a time-overlapping manner, or the blocks may possibly be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by special-purpose hardware-based systems that perform the specified functions or that act or execute a specific-purpose combination of hardware and computer instructions.

[0148] The description of various embodiments of the present disclosure has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been selected to best explain the principles of the embodiments, practical applications or technical improvements to technology found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0149] While the present disclosure has been described with reference to specific embodiments, it is anticipated that alterations and modifications thereof will become apparent to those skilled in the art. It is therefore intended that the following claims be interpreted to cover all such alterations and modifications as fall within the true spirit and scope of the present disclosure. According to this specification, the following items are also disclosed. [Item 1] 1. A method for processing private transactions in a blockchain network, comprising: generating a request associated with the transaction; collecting anchors related to the request; transitioning the transaction into a set of two or more hashes; submitting the transaction to an ordering service; A method for providing the above. [Item 2] Item 14. The method of item 1, wherein the request is a processable action that modifies the blockchain ledger. [Item 3] 3. The method of claim 1, further comprising validating the transaction by two or more shards in the blockchain network, wherein the transaction is validated locally by the two or more shards. [Item 4] The step of the two or more shards validating the transaction comprises: receiving, by each of the two or more shards, a respective known pre-image associated with the two or more hashes; matching, by each of the two or more shards, the respective known preimages to the two or more hashes; Item 3. The method according to item 3, comprising: [Item 5] Item 5. The method of item 4, further comprising performing an atomic commit of the request by the two or more shards. [Item 6] Item 6. The method of item 5, wherein the atomic commit is performed without any of the respective known pre-images being shared with any of the other two or more shards. [Item 7] 1. A system for processing private transactions in a blockchain network, comprising: Memory and a processor in communication with the memory, generating a request associated with the transaction; collecting anchors related to the request; Transitioning the transaction into a set of two or more hashes; Submitting the above transaction to the ordering service a processor configured to perform operations including: A system comprising: [Item 8] Item 8. The system of item 7, wherein the request is a processable action that modifies the blockchain ledger. [Item 9] The above operation is 9. The system of claim 7 or 8, further comprising validating the transaction by two or more shards in the blockchain network, wherein the transaction is validated locally by the two or more shards. [Item 10] The two or more shards verifying the transaction receiving, by each of the two or more shards, a respective known pre-image associated with the two or more hashes; By each of said two or more shards, matching said respective known preimage to said two or more hashes; Item 10. The system of item 9, comprising: [Item 11] The above operation is Item 11. The system of item 10, further comprising performing an atomic commit on the request by the two or more shards. [Item 12] Item 12. The system of item 11, wherein the atomic commit is performed without any of the respective known pre-images being shared with any of the other two or more shards. [Item 13] 1. A computer program for processing private transactions in a blockchain network, the computer program comprising: generating a request associated with the transaction; collecting anchors related to the request; A procedure for transitioning the above transaction into a set of two or more hashes; The procedure for submitting the above transaction to the ordering service is as follows: A computer program for executing [Item 14] Item 14. The computer program of item 13, wherein the request is a processable action that modifies a blockchain ledger. [Item 15] The processor includes: 15. The computer program of claim 13, further comprising the step of validating the transaction by two or more shards in the blockchain network, wherein the transaction is locally validated by the two or more shards. [Item 16] The procedure for the two or more shards to validate the transaction is as follows: receiving, by each of the two or more shards, a respective known pre-image associated with the two or more hashes; matching, by each of said two or more shards, each of said known preimages to said two or more hashes; Item 16. The computer program according to item 15, comprising: [Item 17] The processor includes: Item 17. The computer program of item 16, further causing the two or more shards to perform an atomic commit on the request. [Item 18] Item 18. The computer program of item 17, wherein the atomic commit is performed without any of the respective known pre-images being shared with any of the other two or more shards. [Item 19] 1. A method for processing private transactions in a blockchain network, comprising: receiving a request associated with a transaction; Identifying that a first preimage associated with the first hash is known to the first shard; generating a first identification tag associated with the transaction; A method for providing the above. [Item 20] identifying a second preimage associated with the second hash as known to a second shard; generating a second identification tag associated with the transaction; 20. The method of claim 19, further comprising: [Item 21] 21. The method of claim 20, wherein the first identification tag is displayed to a first user and a second user, and the second identification tag is displayed to the first user and a third user. [Item 22] validating said transaction; Atomically committing the transaction to the blockchain network. 22. The method of claim 21, further comprising: [Item 23] 1. A method for processing private transactions in a blockchain network, comprising: receiving a request associated with a transaction; assigning a first task to a first shard; identifying a first preimage associated with a first hash as known to the first shard; performing the first task; A method for providing the above. [Item 24] assigning a second task to a second shard; identifying a second preimage associated with the second hash as known to a second shard; performing the second task; 24. The method of claim 23, further comprising: [Item 25] 25. The method of claim 24, wherein the first task and the second task are executed as part of an atomic commit of the transaction.

Claims

1. 1. A method for processing private transactions in a blockchain network, comprising: a client node generating a request associated with a transaction; the client node sending pre-images of two or more hashes to all, one, or any combination of two or more shards; the client node collecting anchors and signatures associated with the request without knowing the outcome of the request; the client node transitioning the transaction into a set of two or more hashes; the client node submitting the transaction to an ordering service; A method for providing the above.

2. The method of claim 1 , wherein the request is a processable action that modifies a blockchain ledger.

3. 3. The method of claim 1 or 2, further comprising validating the transaction by two or more shards in the blockchain network, wherein the transaction is validated locally by the two or more shards.

4. The step of the two or more shards validating the transaction comprises: receiving, by each of the two or more shards, a respective known pre-image associated with the two or more hashes; matching, by each of the two or more shards, the respective known preimage to the two or more hashes; The method of claim 3, comprising:

5. The method of claim 4 , further comprising performing an atomic commit of the request by the two or more shards.

6. 6. The method of claim 5, wherein the atomic commit is performed without any of the respective known pre-images being shared with any of the other two or more shards.

7. 1. A system for processing private transactions in a blockchain network, comprising: Memory and a processor in communication with the memory, A client node generating a request associated with a transaction; the client node sending pre-images of two or more hashes to all, one, or any combination of two or more shards; the client node collecting anchors and signatures associated with the request without knowing the outcome of the request; the client node transitioning the transaction into two or more sets of hashes; the client node submitting the transaction to an ordering service; a processor configured to perform operations including: A system comprising:

8. The system of claim 7 , wherein the request is a processable action that modifies a blockchain ledger.

9. The above operation is 9. The system of claim 7 or 8, further comprising validating the transaction by two or more shards in the blockchain network, wherein the transaction is validated locally by the two or more shards.

10. The two or more shards validating the transaction receiving, by each of the two or more shards, a respective known pre-image associated with the two or more hashes; matching, by each of the two or more shards, the respective known preimages to the two or more hashes; The system of claim 9 , comprising:

11. The above operation is The system of claim 10 , further comprising performing an atomic commit on the request by the two or more shards.

12. 12. The system of claim 11, wherein the atomic commit is performed without any of the respective known pre-images being shared with any of the other two or more shards.

13. 1. A computer program for processing private transactions in a blockchain network, the computer program comprising: a client node generating a request associated with a transaction; the client node sending pre-images of two or more hashes to all, one, or any combination of two or more shards; the client node collecting anchors and signatures associated with the request without knowing the outcome of the request; the client node transitioning the transaction into two or more sets of hashes; the client node submitting the transaction to an ordering service; A computer program for executing

14. The computer program product of claim 13 , wherein the request is a processable action that modifies a blockchain ledger.

15. the processor, 15. The computer program of claim 13 or 14, further comprising the step of validating the transaction by two or more shards in the blockchain network, wherein the transaction is validated locally by the two or more shards.

16. The procedure for the two or more shards to validate the transaction includes: receiving, by each of the two or more shards, a respective known pre-image associated with the two or more hashes; matching, by each of the two or more shards, the respective known preimages to the two or more hashes; 16. The computer program of claim 15, comprising:

17. the processor, The computer program product of claim 16 , further comprising: performing, by the two or more shards, an atomic commit of the request.

18. 20. The computer program product of claim 17, wherein the atomic commit is performed without any of the respective known pre-images being shared with any of the other two or more shards.

19. 1. A method for processing private transactions in a blockchain network, comprising: a client node generating a request associated with a transaction; the client node sending pre-images of two or more hashes to all, one, or any combination of two or more shards; receiving a request associated with the transaction at a first shard; the first shard identifying that a first preimage associated with a first hash is known to the first shard; the first shard generating a first identification tag associated with the transaction; the client node collecting anchors and signatures associated with the request without knowing the outcome of the request; the client node transitioning the transaction into a set of two or more hashes; the client node submitting the transaction to an ordering service; A method for providing the above.

20. a second shard identifying that a second preimage associated with the second hash is known to the second shard; the second shard generating a second identification tag associated with the transaction; 20. The method of claim 19 further comprising:

21. 21. The method of claim 20, wherein the first identification tag is displayed to a first user and a second user, and the second identification tag is displayed to the first user and a third user.

22. the first shard and the second shard validating the transaction; the first shard and the second shard atomically committing the transaction to the blockchain network; 22. The method of claim 21 further comprising:

23. 1. A method for processing private transactions in a blockchain network, comprising: a client node generating a request associated with a transaction; the client node sending pre-images of two or more hashes to all, one, or any combination of two or more shards; receiving a request associated with the transaction at a first shard; the client node assigning a first task to a first shard; the first shard identifying that a first preimage associated with a first hash is known to the first shard; the first shard executing the first task; the client node collecting anchors and signatures associated with the request without knowing the outcome of the request; the client node transitioning the transaction into a set of two or more hashes; the client node submitting the transaction to an ordering service; A method for providing the above.

24. the client node assigning a second task to a second shard; a second shard identifying that a second preimage associated with the second hash is known to the second shard; the second shard executing the second task; 24. The method of claim 23, further comprising:

25. 25. The method of claim 24, wherein the first task and the second task are executed as part of an atomic commit of the transaction.

Images