Privacy protection architecture for permissioned blockchain

Abstract

A processor can generate a request associated with a transaction. The processor can collect an anchor associated with the request. The processor can convert the transaction into a set of two or more hashes. The processor can submit the transaction to an ordering service. The processor can receive a request associated with the transaction. The processor can identify that a first image associated with a first hash is known to a first shard. The processor can generate a first identification marker associated with the transaction. The processor can receive a request associated with the transaction. The processor can assign a first task to the first shard. The processor can identify that a first image associated with a first hash is known to a first shard. The processor can perform the task.

Description

Background Technology

[0001] This disclosure generally relates to the field of blockchain transaction commitments, and more specifically to protecting the privacy of transactions in permissioned blockchains.

[0002] Blockchain provides data immutability by replicating data across all nodes in the network. In order to verify a blockchain, a node must have access to the complete history of transactions; any data on the chain is visible to all participants. Summary of the Invention

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

[0004] Further embodiments of this disclosure include a method for processing private transactions in a blockchain network. A processor may receive a request associated with a transaction. The processor may identify that a first preimage associated with a first hash is known for a first shard. The processor may generate a first identifier token associated with the transaction.

[0005] Further embodiments of this disclosure include a method for processing private transactions in a blockchain network. A processor may receive a request associated with a transaction. The processor may assign a first task to a first shard. The processor may identify that a first preimage associated with a first hash is known to the first shard. The processor may execute the task.

[0006] The above description of the invention is not intended to depict every illustrated embodiment or implementation of this disclosure. Attached Figure Description

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

[0008] Figure 1A An example blockchain architecture according to an embodiment of this disclosure is shown.

[0009] Figure 1B A blockchain transaction process according to an embodiment of this disclosure is illustrated.

[0010] Figure 2A A block diagram of an example system for atomically submitting transactions to a blockchain network, according to embodiments of the present disclosure, is shown.

[0011] Figure 2B A block diagram of an example system for atomically submitting horizontally sliced ​​transactions to a blockchain network, according to embodiments of the present disclosure, is shown.

[0012] Figure 2C A block diagram of an example system for atomically submitting vertically slicing transactions to a blockchain network, according to embodiments of the present disclosure, is shown.

[0013] Figure 3A A flowchart illustrating an example method for processing private transactions in a blockchain network according to embodiments of the present disclosure is shown.

[0014] Figure 3B A flowchart is shown as another example method for processing private transactions in a blockchain network according to embodiments of this disclosure.

[0015] Figure 3C A flowchart is shown as another example method for processing private transactions in a blockchain network according to embodiments of this disclosure.

[0016] Figure 4A A cloud computing environment according to an embodiment of this disclosure is shown.

[0017] Figure 4B An abstract model layer according to an embodiment of this disclosure is shown.

[0018] Figure 5 A high-level block diagram of an example computer system, according to embodiments of the present disclosure, is shown that can be used to implement one or more of the methods, tools, and modules described herein, as well as any related functions.

[0019] While the embodiments described herein are subject to various modifications and alternatives, their details have been illustrated by way of example in the accompanying drawings and will be described in detail. However, it should be understood that the specific embodiments described are not intended to be limiting. Rather, the invention is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of this disclosure. Detailed Implementation

[0020] This disclosure generally relates to the field of blockchain transaction commitments, and more specifically to protecting transaction privacy in permissioned blockchains. The described embodiments address blockchain privacy issues by redesigning the blockchain framework around a privacy-first approach that does not rely on expensive cryptographic primitives (e.g., computational costs, resource costs, etc.). What is disclosed herein are methods, systems, and computer program products that allow for modular transaction execution environments, subscription services, and internal data storage. Key contributions to the blockchain technology / field discussed 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 commit protocol.

[0021] It will be readily understood that, as generally described and illustrated in the accompanying drawings, the components of the present invention can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of at least one embodiment of the methods, apparatus, non-transitory computer-readable media, and systems illustrated in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments.

[0022] In one or more embodiments, the immediate features, structures, or characteristics described throughout this specification may be combined or removed in any suitable manner. For example, the use of the phrases “example embodiment,” “some embodiments,” or other similar language throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with that embodiment may be included in at least one embodiment. Therefore, the phrases “example embodiment,” “some embodiments,” “other embodiments,” or other similar language appearing throughout this specification do not necessarily refer to the same set of embodiments, and the described features, structures, or characteristics may be combined or removed in any suitable manner in one or more embodiments. Furthermore, in the drawings, any connection between elements may allow unidirectional and / or bidirectional communication, even if the depicted connection is a unidirectional or bidirectional arrow. Moreover, any device depicted in the drawings may be a different device. For example, if a mobile device is shown as transmitting information, a wired device may also be used to transmit that information.

[0023] Furthermore, although the term "message" may be used in the description of the embodiments, this application can be applied to various types of networks and data. Moreover, although specific types of connections, messages, and signaling may be described in the exemplary embodiments, this application is not limited to specific types of connections, messages, and signaling.

[0024] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that provide document sharing based on privacy-preserving attributes within a blockchain network.

[0025] In one embodiment, this application utilizes a decentralized database (such as a blockchain) as a distributed storage system comprising multiple nodes communicating with each other. The decentralized database comprises an append-only immutable data structure similar to a distributed ledger capable of maintaining records among mutually untrusted parties. Untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records, and no single peer can modify a database record without consensus among distributed peers. For example, peers can execute consensus protocols to verify blockchain storage transactions, group storage transactions into blocks, and build a hash chain on the blocks. For consistency, the process forms a ledger by ordering storage transactions as needed. In various embodiments, permissioned and / or permissionless blockchains can be used. In public or permissionless blockchains, anyone can participate without a specific identity. Public blockchains can involve local cryptography and use consensus based on different protocols (such as proof-of-work). On the other hand, permissioned blockchain databases provide secure interaction between groups of entities sharing common goals but not fully trusting each other, such as businesses exchanging funds, goods, information, etc.

[0026] This application can utilize blockchains that operate on arbitrary, programmable logic, customized as decentralized storage schemes and referred to as "smart contracts" or "chaincode." In some cases, dedicated chaincode, known as system chaincode, can exist to manage functions and parameters. This application can also utilize smart contracts, which are trusted distributed applications that leverage the tamper-proof nature of blockchain databases and underlying protocols between nodes, referred to as endorsement or endorsement policies. Blockchain transactions associated with this application can be "endorsed" before being submitted to the blockchain, while unendorsed transactions are ignored. Endorsement policies allow chaincodes to specify endorsers for a transaction in the form of a set of peer nodes required for endorsement. When a client sends a transaction to the peers specified in the endorsement policy, the transaction is executed to verify it. After verification, the transactions enter a sorting phase, where a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks.

[0027] This application can utilize nodes as communication entities in a blockchain system. A "node" can perform logical functions in the sense that multiple nodes of different types can run on the same physical server. Nodes are grouped in trust domains and associated with logical entities that control them in different ways. Nodes can include different types, such as client or submitting client nodes that 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 transactions submitted by clients, submit transactions, and maintain the state and copy of the ledger of blockchain transactions. Peers can also have the role of endorsers, although it is not required. Ordering service nodes or orderers are nodes that run communication services for all nodes and implement delivery guarantees, such as broadcasting to every peer node in the system when a transaction is submitted and the world state of the blockchain is modified. The world state is another name for the initial blockchain transaction and typically includes control and setup information.

[0028] This application can utilize a ledger, which is an ordered, tamper-proof record of all state transitions in a blockchain. State transitions can be triggered by chaincode calls (e.g., transactions) submitted by participants (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participant (such as a peer node) can maintain a copy of the ledger. Transactions can result in a set of asset key-value pairs being submitted to the ledger as one or more operands, such as creation, update, deletion, etc. The ledger includes a blockchain (also called a chain) for storing immutable, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0029] This application utilizes a chain as a transaction log, constructed as hash-linked blocks, with each block comprising a sequence of N transactions, where N is equal to or greater than 1. The block header includes the hashes of the block's transactions and the hashes of the headers of previous blocks. In this way, all transactions on the ledger can be ordered and cryptographically linked together. Therefore, it is impossible to tamper with the ledger data without breaking the hash link. The hash of the most recently added blockchain block represents every transaction that has appeared before on the chain, thus ensuring that all peer nodes are in a consistent and trustworthy state. The chain can be stored on a peer node file system (e.g., local, attached storage, cloud, etc.), effectively supporting the append-only nature of blockchain workloads.

[0030] The current state of an immutable ledger represents the latest value of all keys included in the chain's transaction log. Because the current state represents the latest key-value pair known to the channel, it is sometimes referred to as the world state. Chaincode calls execute transactions targeting the ledger's current state data. To make these chaincode interactions efficient, the latest value of each key can be stored in a state database. The state database can simply be an indexed view of the chain's transaction log, and therefore can be regenerated from the chain at any time. The state database can be automatically restored (or generated if needed) when peer nodes start up and before accepting transactions.

[0031] Some benefits of the immediate solutions described and depicted herein include methods and systems for document sharing based on privacy-preserving attributes within blockchain networks. Exemplary embodiments address the issues of time and trust by extending database characteristics such as immutability, digital signatures, and acting as a single source of truth. Exemplary embodiments provide solutions for document sharing based on privacy-preserving attributes within blockchain networks. Blockchain networks can be homogeneous based on asset type and rules governing asset management through smart contracts.

[0032] The difference between blockchain and traditional databases lies in the fact that blockchain is not a central storage, but a decentralized, immutable, and secure storage where nodes can share changes to records within the storage. Some inherent properties of blockchain that contribute to its realization include, but are not limited to, the immutable ledger, smart contracts, security, privacy, decentralization, consensus, endorsement, and accessibility described further herein. Depending on the aspect, blockchain enables systems for document sharing based on privacy-preserving properties within blockchain networks due to its inherent and unique immutability, security, privacy, permissioned decentralization, availability of smart contracts, endorsement, and accessibility. Specifically, blockchain ledger data is immutable, and it provides an efficient method for document sharing based on privacy-preserving properties within blockchain networks. Furthermore, the use of encryption in blockchain provides security and establishes trust. Smart contracts manage the state of assets to complete their lifecycle. Example blockchains are permissioned and decentralized. Therefore, each end-user can have their own copy of the ledger for access. Multiple organizations (and peers) can be bound together on the blockchain network. Key organizations can act as endorsing peers to verify the execution results, read-set, and write-set of smart contracts. In other words, the inherent characteristics of blockchain provide an efficient way to process private transactions within a blockchain network.

[0033] One benefit of the example embodiment is that it improves the functionality of a computing system by implementing methods for processing private transactions within a blockchain network. Through the blockchain system described herein, a computing system (or a processor within a computing system) can perform functions utilizing a blockchain network for private transaction processing by providing access to capabilities such as distributed ledgers, peer-to-peer mechanisms, cryptography, MSPs, and event processing. Furthermore, the blockchain enables the creation of business networks and allows any user or organization board to participate. Thus, the blockchain is more than just a database. It has the capability to create business networks of users and on-board / off-board organizations to collaborate and execute service processes in the form of smart contracts.

[0034] The example implementations offer several advantages over traditional databases. For instance, through blockchain, the implementations provide the inherent and unique immutability, security, privacy, permissioned decentralization, availability, endorsement, and accessibility of blockchain.

[0035] Furthermore, traditional databases cannot be used to implement the example embodiments because they do not bring together all parties on a commercial network, do not create trusted collaboration, and do not provide effective storage of digital assets. Traditional databases do not provide tamper-proof storage and do not provide preservation of the stored digital assets. Therefore, the proposed embodiments utilizing blockchain networks described herein cannot be implemented in traditional databases.

[0036] Furthermore, if a traditional database were used to implement the example embodiment, it would suffer from unnecessary drawbacks, such as poor search capabilities, lack of security, and slow transaction speeds. Therefore, the example embodiment provides a specific solution to problems in privacy-preserving processing technologies / fields.

[0037] Example embodiments also change how data can be stored within the block structure of a blockchain. For example, digital asset data can be securely stored within a portion of a data block (e.g., within a header, data segment, or metadata). By storing digital asset data within data blocks of a blockchain, the digital asset data can be appended to the immutable blockchain ledger via a hash-linked chain of blocks. In some embodiments, data blocks can differ from traditional data blocks by ensuring that personal data associated with digital assets is not stored alongside assets within the blockchain's traditional block structure. By removing personal data associated with digital assets, the blockchain can provide the benefits of anonymity based on immutability, accountability, and security.

[0038] Continuing, a blockchain document processor can have two components: a private off-chain processor that manages the secure processing of private information related to participants; and a ledger processor that manages the processing of public information shared with all participants in the blockchain network using the network's consensus algorithm.

[0039] According to an exemplary embodiment, each organization intending to share documents with other organizations uses a blockchain document processor connected to a blockchain network. Using the document processor, an organization can build on the ledger the following: a list of document templates (such as cloud storage proposals for archiving); attributes of each document template to be shared on the ledger in hash form; combinations of key attributes from different templates for matching and sharing documents; and a partnership Merkle tree: each partnership Merkle tree can be built based on the identifier (ID) of the partner organization (e.g., the proposing entity).

[0040] In some embodiments, all documents (e.g., files, etc.) are stored on off-chain data storage (e.g., cloud servers, data centers, etc.). Only the preimage, attribute hash, and / or document identifier (ID) are submitted as part of the blockchain transaction. For example, as suggested in this disclosure, the hashed preimage is stored in a specific shard within the blockchain, which privately verifies the transaction and prevents other shards from viewing the information.

[0041] Figure 1A The illustration depicts a blockchain architecture 100 according to an embodiment of this disclosure. In some embodiments, the blockchain architecture 100 may include certain blockchain elements, such as a set of blockchain nodes 102. Blockchain nodes 102 may include one or more blockchain nodes, such as peers 104-110 (these four nodes are depicted by way of example only). These nodes participate in multiple activities, such as the blockchain transaction addition and confirmation process (consensus). One or more of peers 104-110 may endorse and / or recommend transactions based on an endorsement policy and may provide ordering services for all blockchain nodes 102 in the blockchain architecture 100. Blockchain nodes may initiate blockchain authentication and attempt to write to the blockchain immutable ledger stored in blockchain layer 116, a copy of which may also be stored on supporting physical infrastructure 114. Blockchain configuration may include one or more applications 124 that are linked to application programming interfaces (APIs) 122 to access and execute stored program / application code 120 (e.g., chaincode, smart contracts, etc.), which may be created according to customized configurations sought by participants and may maintain their own state, control their own assets, and receive external information. This can be deployed as a transaction and installed on all blockchain nodes 104-110 via attachment to the distributed ledger.

[0042] The blockchain base or platform 112 may include different layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and supporting physical computer infrastructure that can be used to receive and store new transactions and provide access to auditors attempting to access data entries. The blockchain layer 116 may expose an interface that provides access to the processor code and the virtual execution environment necessary to participate in the physical infrastructure 114. The cryptographic trust service 118 can be used to verify transactions (such as asset exchange transactions) and maintain information privacy.

[0043] Figure 1A The blockchain architecture 100 can process and execute program / application code 120 via one or more interfaces and services exposed by the blockchain platform 112. Code 120 can control blockchain assets. For example, code 120 can store and transfer data and can be executed by peers 104-110 in the form of smart contracts and associated chained code, where conditions or other code elements are subject to their execution. As a non-limiting example, smart contracts can be created to perform the generation of storage space, the reservation of storage space, updates to current proposals, etc. The smart contract itself can be used to identify rules associated with authorization and access requirements and use of the ledger. For example, document attribute information 126 can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 116. Result 128 can include multiple linked shared documents (e.g., each linked shared document records the publication of smart contracts, etc.). Physical infrastructure 114 can be used to retrieve any data or information described herein.

[0044] Smart contracts can be created using high-level applications and programming languages ​​and then written to blocks in a blockchain. Smart contracts can include executable code that is registered, stored, and / or replicated using a blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code, which can be performed in response to the fulfillment of conditions associated with the smart contract. Execution of a smart contract can trigger trusted modifications to the state of the digital blockchain ledger. Multiple modifications to the blockchain ledger caused by the execution of a smart contract can be automatically replicated across a distributed network of blockchain peers using one or more consensus protocols.

[0045] Smart contracts can write data to the blockchain in key-value pair format. Furthermore, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the outputs of different logical operations to the blockchain. The code can be used to create temporary data structures in virtual machines or other computing platforms. Data written to the blockchain can be public and / or can be encrypted and maintained as private. Temporary data used / generated by smart contracts is stored in memory by the supplied execution environment and then deleted once the data needed by the blockchain is identified.

[0046] Chaincode can include a code interpretation of a smart contract with additional features. As described herein, chaincode can be program code deployed on a computing network, where it is executed and verified together by a chain verifier during the consensus process. Chaincode receives hashes and retrieves hashes from the blockchain associated with a data template created using a previously stored feature extractor. If the hash of the hash identifier matches the hash created from the stored identifier template data, the chaincode sends an authorization key to the requested service. Chaincode can write data associated with cryptographic details to the blockchain (e.g., thus atomically submitting transactions to the blockchain).

[0047] Figure 1B An example of a blockchain transaction flow 150 between nodes in a blockchain, according to an example embodiment, is shown. (Reference) Figure 1B The transaction flow may include a transaction proposal 191 sent by application client node 160 to endorsing peer node 181 (e.g., in some embodiments, transaction proposal 191 may be sent for endorsement when the preimage of the hash associated with transaction proposal 191 matches the preimage stored within a specific shard). Endorsing peer 181 may verify the client signature and execute chaincode functions to initiate the transaction. Output may include chaincode results, a set of key / value versions read in the chaincode (read set), and a set of key / value versions written in the chaincode (write set). If approved, a proposal response 192 is sent back to client 160 along with the endorsement signature. Client 160 assembles the endorsement into a transaction payload 193 and broadcasts it to ordering service node 184. Ordering service node 184 then delivers the ordered transactions as blocks to all peers 181-183 on the channel. Each peer 181-183 may verify the transaction before it is committed to the blockchain. For example, peers can check the endorsement policy to ensure that the correct allocation of the specified peer has been signed for the result and that the signature has been verified for the transaction payload 193.

[0048] Refer again Figure 1BClient node 160 initiates transaction 191 by constructing a request and sending it to peer node 181, which acts as the endorser. Client 160 may include an application utilizing a supported software development kit (SDK) that leverages available APIs to generate transaction proposal 191. A proposal is a request to call a chaincode function to allow data to be read and / or written to the ledger (e.g., writing new key-value pairs for assets). The SDK may act as a shim to encapsulate transaction proposal 191 into an appropriate architectural format (e.g., a protocol buffer over a remote procedure call (RPC)) and use the client's cryptographic certificate to generate a unique signature for transaction proposal 191.

[0049] In response, the endorsing peer node 181 verifies that (a) transaction proposal 191 is well-formed, (b) the transaction has not been submitted in the past (replay attack protection), (c) the signature is valid, and (d) the submitter (client 160 in this example) is properly authorized to perform the proposed operation on the channel. The endorsing peer node 181 can take the transaction proposal 191 as input as arguments to the invoked chaincode function. The chaincode is then executed against the current state database to produce a transaction result including response values, a read set, and a write set. However, no ledger is updated at this point. In 192, this set of values, along with the signature of the endorsing peer node 181, is passed back to client 160's SDK as proposal response 192, which parses the payload consumed by the application.

[0050] In response, client 160's application checks / verifies the endorsed peer signature and compares the proposed response to determine if they are identical. If the chaincode only queries the ledger, the application will check the query response and typically will not submit the transaction to the ordering node service 184. If the client application intends to submit a transaction to the ordering node service 184 to update the ledger, the application determines whether the specified endorsement policy has been satisfied before submission (e.g., whether all peer nodes with the specific shard required for the transaction have endorsed the transaction). Here, the client may only include one of the multiple parties to the transaction. In this case, each client may have its own endorser node, and each endorser node will be required to endorse the transaction. This architecture ensures that even if the application chooses not to check the response or otherwise forwards unendorsed transactions, the endorsement policy will still be enforced by the peers and maintained during the submission verification phase.

[0051] After a successful check, in step 193, client 160 assembles the endorsement into the transaction and broadcasts the transaction proposal 191 and the response within the transaction message to sorting node 184. The transaction may contain a read / write set, endorsement peer signatures, and a channel ID. Sorting node 184 does not need to examine the entire contents of the transaction to execute its operation; instead, it can simply receive transactions from all channels in the network, sort them chronologically by channel, and create transaction blocks by channel.

[0052] The block of transactions is delivered from sorting node 184 to all peer nodes 181-183 on the channel. Transactions 194 within the block are verified to ensure any endorsement policies are satisfied and that the ledger state for the read set variables remains unchanged, as the read set is generated by transaction execution. Transactions in the block are marked as valid or invalid. Furthermore, in step 195, each peer node 181-183 appends the block to the channel's chain, and for each valid transaction, the write set is committed to the current state database. Events are emitted to notify clients that the application transaction (call) has been immutably appended to the chain, and to notify whether the transaction has been verified or invalidated.

[0053] See now Figure 2A The diagram illustrates a block diagram of an example system 200 for atomically submitting transactions to a blockchain network according to embodiments of the present disclosure. In some embodiments, system 200 includes a transaction 202, which includes a first hash 204 and a second hash 206. System 200 further includes a first shard 208, a second shard 210, and a third shard 212. The system continues to include a first verification 214, a second verification 216, an unknown preimage 218, an atomic commit (e.g., a command, operation, module, node, etc.) 220, and an ignore (e.g., a command, operation, module, node, etc.) 222. In some embodiments, transaction 202 is sent to system 200 for verification by the blockchain network and submission to / through the blockchain network. Transaction 202 is split into a first hash 204 and a second hash 206, which have preimages associated with them (e.g., not depicted). The original images of hashes 204 and 206 are then sent to all, one, or any combination of fragments 208-210, which have copies of the original version associated with the first hash 204 or the second hash 206.

[0054] As depicted, the first shard 208 includes a copy of the preimage associated with the first hash 204, the second shard 210 includes a copy of the preimage associated with the second hash 206, and the third shard 212 does not include a copy of either preimage. In some embodiments, the first shard 208 allows nodes / peers accommodating / utilizing the first shard 208 to perform a first verification 214; the second shard 210 allows nodes / peers accommodating / utilizing the second shard 210 to perform a second verification 216. In some embodiments, after verifications 214 and 216, an atomic commit 220 is performed and the transaction is committed to the blockchain network.

[0055] In some embodiments, the node / peer identifier of the third shard 212 that the unknown preimage 218 has been sent to the node / peer of the third shard 212 and the unknown preimage 218 is ignored by ignore 222. In some embodiments, atomic commit 220 and ignore 222 are performed simultaneously. Note that what is depicted in system 200 allows transactions (e.g., transaction 202) to be committed to the blockchain network without indiscriminately exposing information to the entire blockchain network.

[0056] Further attention should be paid to system 200 (and separately regarding...) Figures 2B to 2C Systems 230 and 260 use certain assumptions, which are detailed below:

[0057] All processes running by network participants and communication between network nodes are partially synchronous. More specifically, for each communication round, there is an upper limit to the waiting time for each message sent between two correct nodes. It is measured by the number of rounds;

[0058] Hash functions and Public Key Infrastructure (PKI) cannot be intentionally compromised. Note that the network setup presented in this paper is permissive; for example, all participants are known and have roles assigned to them in a manner similar to current implementations of (hyperledger) structures. Thus, it is further assumed that communication is peer-to-peer authenticated, for example, using Transport Layer Security (TLS).

[0059] Each node in the network (loosely corresponding to a peer in the structure) belongs to at least one privacy shard. While each node replicates the same ledger, it shares its view of the world state only with other nodes in the same privacy shard. The union of all local shard states creates the complete world view. Therefore, it is further assumed that all other nodes in the network are aware of all nodes and their shard memberships. However, nodes do not reveal their local state or any information not specified in the protocol described herein. Furthermore, while nodes may exhibit failures, we assume that shards as a whole are honest, but curious, and do not fail.

[0060] Clients are entities that interact with the ledger. They are responsible for initiating transactions. Multiple clients can collaborate to create transactions together. Each of these clients is susceptible to Byzantine faulty. In particular, some or even all of the clients involved may collude with the rest of the network;

[0061] Assets are collections of data representing physical objects or virtual concepts on a ledger. As disclosed herein, assets are first-class citizens and become the primary points of interaction with the blockchain. By modeling them like objects in object-oriented programming, such smart assets manage their own data. They track their own internal state and only make public APIs available for interaction. This breaks down traditional smart contracts into two parts based on interactions between one or more smart assets: asset qualifiers and business logic. Each can be handled by different domain experts, making application development, interoperability, and asset composition easier. Asset qualifiers (e.g., their internal workings and public APIs) are mounted on privacy shards. Thus, different shards can provide different smart asset qualifiers, similar to a bank offering different choices of financial instruments. Further, it is assumed that all API calls accept Data Transfer Objects (DTOs) containing all the necessary data for the requested state transition. All DTOs and the assets themselves implement the interfaces GetID() and GetStakeholder(). The first ensures that the ledger can find previously created assets, and the latter is needed to verify stakeholder policies, as discussed below. Note that the methods, systems, and computer program products disclosed herein are not limited to assets but are instead agnostic to the content of transactions;

[0062] Further assuming that each asset requires a defined set of stakeholders. For example, an IOU asset would require borrowers and lenders as stakeholders. When asset definitions are installed, each API can register a stakeholder policy. Whenever a client calls an API, it can provide one or more stakeholder signatures that satisfy the policy used for the function call. For example, a policy for a withdrawal request from a joint bank account might require one of two stakeholder signatures. Stakeholders are part of the asset's internal state and can change over time.

[0063] From a conceptual standpoint, the existence of stakeholders prevents double-spending on the ledger without forking, as presented in this paper. Whenever a staker transfers ownership of an asset to a new staker, that asset will no longer accept the signature of the old staker. If a malicious staker attempts to create two transfers for the same asset, they will eventually appear in full sequence on the global ledger. The first transaction then changes the staker, so when the second transaction is verified, it violates the staker policy for the asset and is discarded.

[0064] A transaction is a semantic unit of simultaneous state transitions and is submitted to the ledger by a client. It can involve complex dependencies between multiple privacy shards and their different parts. For example, a transaction might include three state transitions. The first transition in shard A and the second transition in shard B are interdependent for submission, ensuring atomic interaction. The third transition involves shard C but is independent of the other two. This could lead to a situation where A and B discard the transaction while C submits it. This is allowed because the correctness of the local state of each shard is preserved and the atomic parts of the transaction are also consensus-based. If the parts of shard C are truly independent of A and B, then whether those shards are discarded is irrelevant. Otherwise, the third part needs to receive the dependencies and be overridden by atomicity guarantees.

[0065] The ordering service is responsible for creating the global order of transactions. Like privacy shards, the ordering service is treated as a "black box" in the described scenario. Thus, the ordering service is honest but curious. Furthermore, it creates the overall order of transactions submitted by clients, cuts this order into blocks, and distributes the blocks to all privacy shards in the network. As described in this paper and discussed in more detail below, this is achieved by constructing a system that doesn't know which shards are involved in a single transaction. Therefore, it's impossible for the global ordering service to propagate transactions only to the shards involved.

[0066] Return to reference Figure 2A The text describes a simplified example, such as: a client named Bob wants to borrow $100 from another client named Alice. For this purpose, they would create an IOU smart asset, which represents a privacy shard S. iou The total amount borrowed from the asset already secured is the sum of the assets. In exchange, Alice will transfer $100 worth of existing assets stored in a privacy shard to Bob. These two operations belong to the same transaction and can be executed atomically.

[0067] In another example, Alice and Bob negotiate the contents of the DTO against the CreateIOU call. As mentioned earlier, GetID() and GetStakeholders() are already implemented, so they only need to ensure they add their public keys to mark them as stakeholders and agree on the correct values. This negotiation occurs entirely between the clients involved and does not involve any sharding or ordering services.

[0068] Once Bob and Alice are both satisfied with the DTO used for IOU creation, they are ready to work on the shard S. iouThe request consists of a uniquely specified name of the function call (CreateIOU in this case), the corresponding DTO, an arbitrary request ID, and the set of shards that this request depends on. The request ID ensures that the shards receiving this request can distinguish between a malicious / accidental replay of the same request and a genuine second request with only the same parameters. This is achieved by adding a dependency set {S} to the request. token Alice and Bob can tell S iou S token Another part of the transaction must be verified. In this case, S iou If and only if S token Also submit changes if you change them (this will be described in more detail below).

[0069] The set of clients satisfying the stakeholder policy for function calls in the request needs to sign the Merkle root hash of the four parts of the request using the same private key belonging to their stakeholder public key. The received fragments later check whether these signatures comply with the stakeholder policy. For CreateIOU, in S... iou The registration strategy requires both borrowers and lenders to sign the request, so Alice and Bob both add their signatures. Because of these signatures, no client can create a valid request that isn't seen by the required number of stakeholders.

[0070] Finally, Bob, who sends the request to the shard, adds a signature associated with his role in the network to the message to verify that he is authorized to make the request to the shard. An example of such a role is a WRITER, someone authorized to create requests and transactions. This final signature is not considered part of the message and is discarded by the shard after verification, ensuring that no information about the sender of the request is leaked to the rest of the network. Each client signature is bound to a specific request due to the request ID; it cannot be reused by a malicious client without attempting to replay the entire request, which can be addressed through deduplication prevention on the shard.

[0071] When fragment S iou Upon receiving a request from Bob, it first examines the request for replication. Then, it unpacks the payload and uses the GetStakeholders() interface of the DTO to receive the necessary public key to verify the signature against the stakeholder policy of the CreateIOU. If the verification fails, the shard simply responds with an error message. Otherwise, the next step depends on the shard's configuration.

[0072] In some embodiments, the blockchain's execution engine is completely decoupled from the transaction flow, so shards can be configured to perform pre-order or post-order execution, or some combination of both. If a shard performs pre-order execution, it now simulates CreateIOU and stores the result in a local transient repository. If a shard is configured to perform post-order execution, the resulting payload is empty. In either case, the shard then hashes the request using a Merkle root hash (without...). The shard is then signed with the resulting payload. This acts as a partial preimage of the future transaction, allowing the shard to store it locally before returning the response to the client. The shard then simply returns the hash of the preimage 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 an anchor for the preimage to the transaction.

[0073] In some embodiments, the steps provided above may be repeated for all parts of the complete transaction. Therefore, Alice and Bob must also agree on which asset Alice will transfer to Bob. They create a {S} iou} as a request for a transfer token of the dependency set. Thus, if S iou Only if the other part of the transaction is submitted will the token transfer be successful. Alice then sends the request to S. token , which holds that specific asset. Then, with the help of the GetID interface of the DTO requesting the transfer token, S token The asset is loaded from the asset database. This allows both the requesting stakeholder and the existing asset to be verified together. In this case, the asset owner must also be a stakeholder in the transfer. This translates to the following policy: "One signature must match a single stakeholder of the existing asset and a stakeholder in the transfer, and another signature must match only a separate stakeholder in the transfer."

[0074] Generally, multiple requests to different shards can be processed simultaneously because the only link between them is their set of dependencies, which is only used during validation after the transaction is committed. Note that no shard involved knows what requests are being made by other shards.

[0075] In some embodiments, Alice and Bob are from fragment S iou and S token Upon receiving the response, Alice and Bob collect and hash the response before both signing it with the same private key used for the individual request. As with previous individual requests, Alice appends a signature associated with her network role and sends the entire transaction to the ordering service.

[0076] The transaction consists of the hash of all sharded responses involved in the transaction and the Merkle root signatures of all involved stakeholders. Here, we distinguish between stakeholders and clients because a single client might use a different key pair for each request for a shard. In this case, the client would need to sign the transaction with all involved private keys. It is important to note that the client signs the Merkle root without needing to know exactly any response preimages. This allows for partially opaque transactions.

[0077] In another example, consider a scenario where three clients, Alice, Bob, and Cerise, periodically owe each other $10 in net settlement. Alice is willing to cancel her IOU with Bob if Cerise's IOU with her is canceled simultaneously. Similarly, Bob and Cerise do the same. However, none of the clients need to know the agreement between the other two clients to ensure the net settlement works for them. Therefore, they create a three-part transaction, where each client only knows two of the hashed sharded responses. The three parts of the net settlement transfer must be combined into a single transaction to guarantee atomicity. The clients are still able to sign the Merkle root of the transaction because they are confident that the opaque part of the transaction cannot involve any of their assets. Otherwise, they would have to sign the request, resulting in an opaque hash being created in the transaction. It should be noted that the transaction can implicitly involve 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, then discards the signature and adds the transaction to a new block, which is then propagated throughout the network. Since the ordering service only sees the hash and signature associated with an unknown public key, it cannot know anything about the client's identity (other than the sender) or even which privacy shards are involved. However, it can know the number of shards involved and the number of clients. If this disclosure is a problem, the client could add any number of fake (e.g., fake, forged, etc.) hashes and forged signatures to the transaction in previous steps to obscure the real number of participants. Furthermore, if the identity of the real sender should be kept confidential, a proxy client could be used to broadcast the transaction to the ordering service.

[0079] In some embodiments, in the case of IOU, fragment S iou and S token Both scan every transaction in each new block they receive. They compare each Merkle leaf of a transaction with the hash of its previously created but unverified preimage. Therefore, at some point, S iou This will identify the hash of the response to the CreateIOU request. To check if a known hash is part of a valid transaction, S...iou All stakeholders who verified the preimage have also signed the complete transaction. If this is not the case, a transaction can be created without the knowledge of one of the requesting stakeholders.

[0080] Assume S iou Configured for pre-order execution, it has already stored the simulated request results. Since these results may now be outdated, it needs to verify that they are still valid. If replacing S... iou Configured to execute sequentially, it will simulate the result and check its validity, as previously discussed. In either case, if the result is invalid, it discards the transaction and continues moving. If the result is valid, it queries S. token Is its transaction portion also valid? To do this, it sends the relevant transaction's Merkel root data to S. token .

[0081] At the same time, S token The same process has been completed, so each shard will respond to queries from other shards with a success or failure message. If a shard receives a failure message, it discards its local result, even if it is valid. Otherwise, the result is committed to the local ledger state. This ensures that an IOU is created and a token is delivered, or neither is created nor delivered.

[0082] As another example, the commit protocol becomes more complex in scenarios with more than two shards. Imagine a scenario with four shards S0, S1, S2, and S3. Each shard S... i Depends on the two shards and The result is as follows: If S1 is valid, and the responses from S0 and S2 are also valid, then it proceeds and commits. However, it's possible that S1 queries before any of the other shards has a chance to get a response from S3. If S3 is invalid, then both S0 and S2 also invalidate their results. Therefore, S1 should not commit its portion of the transaction. This means that atomic commits (ACs) should be implemented across all involved shards.

[0083] Furthermore, in handling the extreme case of fuzziness, a transaction may include multiple requests for the same shard. In this case, verification of the computation results is performed in the same order as the order in which their associated hashes appear in the transaction. This order is fixed by the Merkle root of the transaction's signing, thus ensuring determinism as long as the result of each individual confirmation is deterministic. Next, the condition of having multiple requests S is defined. multi The response of the sharded data is given to any dependent shard. dep In some instances, it is not possible to use S. depDistinguish requests because it cannot join hashes in a transaction to a specific shard. In another instance, because a set of dependencies does not necessarily create bidirectional dependencies, S... multi I don't know S dep Which request S do you want to make? dep To respond. Therefore, S multi Only for S dep A single response is provided. The only way a single response will not compromise the atomicity of any dependency validation is by aggregating the results of all requests in an all-or-none manner. Therefore, regardless of the number of validation requests, the response of any shard is hashed by the transactions of the other shards and the single successful or failed query.

[0084] It's important to note that transactions are typically verified sequentially to ensure determinism. However, shards can infer transaction dependencies. Especially if shards use pre-order execution, they can discover transactions that only have access to different states. In this case, shards awaiting verification can verify 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 impossible, it ensures that all shards eventually progress, assuming no permanent network partitions. By the time a transaction is submitted to the ordering service, all involved shards have seen their own associated preimages. Otherwise, shards would not be able to sign responses to client requests. If a shard does not identify a hash in a transaction, that hash belongs to a different shard or it is an invalid hash, and therefore can be ignored in either case. Therefore, when a shard begins the atomic commit protocol for a particular transaction, each involved shard can explicitly determine its own starting value. The commit latency is determined by the latest shard receiving the block and the waiting time of the atomic commit protocol. By assuming all shards behave well, all shards will eventually decide.

[0085] It is important to emphasize that this disclosure does not guarantee the complete commit or discard of a transaction, but only the atomicity of dependent parts. Suppose a transaction consists of two independent parts. Each corresponding shard will verify that the stakeholders of its part are a subset of the complete set of transaction signatures. In this case, the first shard cannot and should not be able to determine whether the second shard can verify the signature. Therefore, it is possible for the first shard to commit a change while the second shard ignores it. However, by constraint, the two parts are semantically independent, so this will not lead to any inconsistencies or potential attacks on the global state of the ledger.

[0086] See now Figure 2B This illustrates a block diagram of an example system 230 for atomically submitting horizontally sliced ​​transactions to a blockchain network according to embodiments of the present disclosure. It should be noted that various descriptions of system 230 can be derived from the above descriptions. Figure 2A The system 200 describes the scenario or description.

[0087] In some embodiments, system 230 may include transaction 232, which is divided into a first hash 234 and a second hash 236. In some embodiments, the preimage (not shown) of each of hashes 234, 236 may be sent to a first shard 238, a second shard 240, or both shards 238, 240. As depicted, but not limited to, the first shard 238 indicates that it has retained a matching (identical) preimage of the first hash 234 as sent. Further, the second shard 240 indicates that it has retained a matching preimage of the second hash 236.

[0088] In some embodiments, when shards 238 and 240 identify that they have corresponding preimages of hashes 234 and 236, the first shard 238 generates a first identifier (ID) token 242 and the second shard 240 generates a second ID token 244. In some embodiments, tokens 242 and 244 are submitted to the blockchain via atomic commit 252. In some embodiments, the first ID token 242 is presented to a first user 246 and a second user 248 before, after, or simultaneously with atomic commit 252. Further, the second ID token 244 is presented to the first user 246 and a third user 250.

[0089] For example, a transaction in which a farmer delivers crops to a distributor can be split into two hashes. One hash may relate to the transport operator delivering the crops to the distributor, and the other hash may relate to the crops to be delivered to the distributor. Before initiating the transaction, the first shard of the blockchain is sent to the preimage of the hash associated with the transport operator, and the second shard of the blockchain is sent to the preimage of the hash associated with the crops.

[0090] When a farmer initiates a transaction with a distributor, two hashed preimages are sent to each shard, and the corresponding shard with the matching preimage generates an identifier transparent to both the farmer and the transport operator or distributor. That is, the farmer knows both the transport operator being used and the crop being delivered, but the distributor only knows the crop being delivered (because the distributor does not need to know the transporter being used).

[0091] refer to Figure 2C This illustrates a block diagram of an example system 260 for atomically submitting vertically slicing transactions to a blockchain network according to embodiments of the present disclosure. It should be noted that various descriptions of system 260 can be derived from the above descriptions. Figure 2A The system 200 describes the scenario or description.

[0092] In some embodiments, system 260 may include transaction 262, which is divided into a first hash 264 and a second hash 266. In some embodiments, the preimage (not shown) of each of hashes 264, 266 may be sent to a first fragment 268, a second fragment 270, or both fragments 268, 270. As described but not limited to, the first fragment 268 indicates that it has retained a matching (identical) preimage of the first hash 264 as sent. Further, the second fragment 270 indicates that it has retained a matching preimage of the second hash 266.

[0093] In some embodiments, when the first fragment 268 identifies that it has a matching preimage associated with the first hash 264, the first fragment 268 performs a first task 272. Further, when the second fragment 270 identifies that it has a matching preimage associated with the second hash 266, the second fragment 270 performs a second task 274. In some embodiments, after performing the first task 272 and the second task 274, an atomic commit 276 may be performed.

[0094] For example, a transaction in which Bob buys a $100,000 house from Alice can be submitted to a blockchain network. The transaction can be split into two hashes: a first hash associated with the transfer of ownership of the house from Alice to Bob; and a second hash associated with the transfer of the $100,000 house from Bob to Alice. In some embodiments, before initiating the transaction, the corresponding preimage for each hash can be sent to a first shard and a second shard accordingly. Upon initiating the conversion, both preimages are sent to both the first shard and the second shard, and each shard is identified by a matching corresponding preimage. In some embodiments, the first shard includes the preimage associated with the first hash and performs the task of transferring the house ownership from Alice to Bob; similarly, the second shard includes the preimage associated with the second hash and performs the task of transferring the $100,000 house from Bob to Alice.

[0095] See now Figure 3A The diagram shows a flowchart of an example method 300 for processing private transactions in a blockchain network according to embodiments of the present disclosure. In some embodiments, method 300 may be executed by a processor (e.g., a node, computer system, etc.) in the blockchain network.

[0096] In some embodiments, method 300 begins at operation 302, where the processor generates a request associated with the 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 transforms the transaction into a set of two or more hashes. Method 300 continues to operation 308, where the processor submits the transaction to a sorting service. In some embodiments, method 300...

[0097] The following discussion will cover in more detail how this can be achieved through method 300, but... Figure 3A Further operations are not shown. Therefore, in some embodiments, the request may be a processable action that modifies the blockchain ledger. In some embodiments, method 300 further proceeds to the operation of the processor verifying a transaction through two or more shards in the blockchain network (which may be housed in / on the processor). The transaction may be verified locally by two or more shards (e.g., where it is not visible to other shards in the blockchain).

[0098] In some embodiments, two or more shards verify a transaction via method 300, further proceeding to the point where the processor receives a corresponding known preimage associated with two or more hashes through each of the two or more shards. The processor matches the corresponding known preimage with the two or more hashes through each of the two or more shards.

[0099] In some embodiments, method 300 further proceeds to the operation of the processor performing the requested atomic commit via two or more slices (in / on the processor). In some embodiments, the atomic commit may be performed without sharing any corresponding known preimage with any of the other two or more slices.

[0100] See now Figure 3B The diagram shows a flowchart of another example method 330 for processing private transactions in a blockchain network according to embodiments of the present disclosure. In some embodiments, method 330 may be executed by a processor (e.g., a node, computer system, etc.) in the blockchain network.

[0101] In some embodiments, method 330 begins at operation 332, where the processor receives a request associated with a transaction. Method 330 continues to operation 334, where the processor identifies that a first preimage associated with a first hash is known for a first shard. Method 330 proceeds to operation 336, where the processor generates a first identifier token associated with the transaction. In some embodiments, method 330 ends.

[0102] The following discussion elaborates on how this can be achieved through method 330, but... Figure 3BFurther operations are not shown in the diagram. Therefore, in some embodiments, method 330 further continues to the operation whereby the processor identifies that the second preimage associated with the second hash is known to the second slice. The processor generates a second identifier tag associated with the transaction.

[0103] In some embodiments, the first identifier is displayed to a first user and a second user, and the second identifier is displayed to both a first user and a third user. In some embodiments, method 330 further proceeds to the processor verifying the transaction. The processor then atomically submits the transaction to the blockchain network.

[0104] See now Figure 3C The diagram illustrates a flowchart of an example method for processing private transactions in a blockchain network according to embodiments of the present disclosure. In some embodiments, method 350 may be executed by a processor (e.g., a node, computer system, etc.) in the blockchain network.

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

[0106] The following is a more comprehensive discussion of how this can be achieved through method 350, but... Figure 3C Further operations are not shown. Therefore, in some embodiments, method 350 further proceeds to the operation of the processor assigning a second task to the second shard. The processor identifies that the second preimage pair associated with the second hash is known to the second shard. The processor executes the second task. In some embodiments, the execution of the first and second tasks is part of an atomic commit of the transaction.

[0107] It should be understood that while this disclosure includes a detailed description of cloud computing, the implementation of the teachings cited herein is not limited to cloud computing environments. Rather, embodiments of this disclosure can be implemented in conjunction with any other type of computing environment now known or developed hereafter.

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

[0109] The features are as follows:

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

[0111] Extensive network access: Capabilities are available through networks and accessed via standard mechanisms that facilitate the use of heterogeneous thin client platforms or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0112] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated as needed. There is a sense of partial independence because consumers typically do not have control or knowledge of the exact portions of the resources provided, but may be able to specify portions at a higher level of abstraction (e.g., country, state, or data center).

[0113] Rapid flexibility: The ability to provide capacity quickly and flexibly, automatically scaling down and up rapidly in some situations to scale up rapidly. For consumers, the available supply capacity often appears unlimited and can be purchased in any quantity at any time.

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

[0115] The service model is as follows:

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

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

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

[0119] The deployment model is as follows:

[0120] Private cloud: A cloud infrastructure that operates solely for an organization. It can be managed by the organization or a third party and can exist on-site or off-site.

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

[0122] Public cloud: Makes cloud infrastructure available to the public or large industry groups and is owned by an organization that sells cloud services.

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

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

[0125] Figure 4A A cloud computing environment 410 is illustrated. As shown, the cloud computing environment 410 includes one or more cloud computing nodes 400 that can communicate with local computing devices used by cloud consumers, such as, for example, personal digital assistants (PDAs) or cellular phones 400A, desktop computers 400B, laptop computers 400C, and / or automotive computer systems 400N. The nodes 400 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as private clouds, community clouds, public clouds, or hybrid clouds, or combinations thereof, as described above.

[0126] This allows cloud computing environments 410 to provide infrastructure, platforms, and / or software services to cloud consumers without requiring them to maintain resources on their local computing devices. It should be understood that... Figure 4AThe types of computing devices 400A-N shown are intended to be illustrative only, and computing node 400 and cloud computing environment 410 can communicate with any type of computerized device via any type of network and / or network-addressable connection (e.g., using a web browser).

[0127] Figure 4B This demonstrates the use of a cloud computing environment 410 ( Figure 4A This provides a set of functional abstractions. It should be understood beforehand. Figure 4B The components, layers, and functions shown are intended to be illustrative only, and embodiments of this disclosure are not limited thereto. The following layers and corresponding functions are provided.

[0128] The hardware and software layer 415 includes hardware and software components. Examples of hardware components include: a mainframe 402; a server 404 based on a RISC (Reduced Instruction Set Computer) architecture; a server 406; a blade server 408; a storage device 411; and a network and network components 412. In some embodiments, software components include network application server software 414 and database software 416.

[0129] The virtualization layer 420 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual server 422; virtual storage 424; virtual network 426, including virtual private network; virtual application and operating system 428; and virtual client 430.

[0130] In one example, management layer 440 may provide the functions described below. Resource provisioning 442 provides dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and pricing 444 provides cost tracking as resources are utilized within the cloud computing environment and bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. User portal 446 provides access to the cloud computing environment for consumers and system administrators. Service level management 448 provides cloud resource allocation and management to ensure that required service levels are met. Service level agreement (SLA) planning and fulfillment 450 provides pre-scheduling and procurement of cloud resources based on anticipated future needs according to the SLA.

[0131] The workload layer 460 provides examples of functionalities that can leverage a cloud computing environment. Examples of workloads and functionalities that can be provided from this layer include: mapping and navigation 462; software development and lifecycle management 464; virtual classroom education delivery 466; data analytics and processing 468; transaction processing 470; and atomic commits 472.

[0132] Figure 5A high-level block diagram of an exemplary computer system 501, according to embodiments of the present disclosure, is shown that can be used to implement one or more of the methods, tools, and modules described herein and any related functions (e.g., using one or more processor circuits of a computer or a computer processor). In some embodiments, the main components of the 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 directly or indirectly communicatively coupled 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 CPU 502. In some embodiments, computer system 501 may include a typical multiple processors of a relatively large system; however, in other embodiments, computer system 501 may alternatively be a single CPU system. Each CPU 502 may execute instructions stored in memory subsystem 504 and may include one or more on-board caches.

[0134] 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. Computer system 501 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 526 may be configured to read from and write to non-removable, non-volatile magnetic media (such as a "hard disk drive"). Although not shown, a disk drive may be provided for reading from or writing to a removable non-volatile disk (e.g., a "floppy disk"), or an optical disk drive may be provided for reading from or writing to a removable non-volatile optical disk (such as a CD-ROM, DVD-ROM, or other optical media). Furthermore, memory 504 may include flash memory, such as a flash stick drive or a flash drive. Memory devices may be connected to memory bus 503 via one or more data media interfaces. 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 different embodiments.

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

[0136] Although the memory bus 503 is Figure 5 The diagram illustrates a single bus structure providing a direct communication path between CPU 502, memory subsystem 504, and I / O bus interface 510. However, in some embodiments, memory bus 503 may include multiple different buses or communication paths, which may be arranged in any of a variety of forms, such as point-to-point links in hierarchical, star, or network configurations, multiple hierarchical buses, parallel and redundant paths, or any other suitable type of configuration. Furthermore, although I / O bus interface 510 and I / O bus 508 are shown as a single corresponding unit, in some embodiments, computer system 501 may include multiple I / O bus interface units 510, multiple I / O buses 508, or both. Further, while multiple I / O interface units are shown separating I / O bus 508 from different communication paths running to different 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, a server computer, or a 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, portable computer, laptop or notebook computer, tablet computer, pocket computer, telephone, smartphone, network switch or router, or any other suitable type of electronic device.

[0138] It is important to note that Figure 5 This description aims to depict representative major components of an exemplary computer system 501. However, in some embodiments, a single component may have more than Figure 5 The greater or lesser complexity represented therein can exist differently from... Figure 5 The components shown or excluding Figure 5 Components other than those shown, and the number, type, and configuration of such components can vary.

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

[0140] This disclosure can be a system, method, and / or computer program product with any possible level of technical detail integration. The computer program product may comprise a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to execute aspects of the invention.

[0141] Computer-readable storage media can be tangible devices capable of retaining and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital universal disk (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or protrusions in slots having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted through wires.

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

[0143] Computer-readable program instructions used to perform the operations disclosed herein may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as the "C" programming language or similar programming languages). The computer-readable program instructions may execute entirely on a user's computer, partially on a user's computer, as a standalone software package, partially on a user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network (including a local area network (LAN) or a 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, programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may execute computer-readable program instructions by utilizing the status information of the computer-readable program instructions to personalize the electronic circuitry in order to perform aspects of this disclosure.

[0144] This document describes aspects of the disclosure with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts 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 produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner, such that the computer-readable storage medium storing the instructions includes an article of manufacture containing instructions that implement aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

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

[0147] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. 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 marked in the blocks may occur in a different order than indicated in the figures. For example, two consecutively shown blocks may actually be completed as a single step, executed simultaneously, substantially simultaneously, or with partial or complete temporal overlap, or the blocks may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0148] Various embodiments of this disclosure have been described for illustrative purposes, but are 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 chosen to best explain the principles of the embodiments, their practical application, or technical improvements to technologies found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0149] While this disclosure has been described with reference to specific embodiments, variations and modifications thereof are expected to become apparent to those skilled in the art. Therefore, the following claims are intended to be construed as covering all such changes and modifications that fall within the true spirit and scope of this disclosure.

Claims

1. A method for processing private transactions in a blockchain network, the method comprising: Generate requests associated with the transaction; The transaction is verified privately, wherein the private verification of the transaction prevents other shards from viewing the information by storing the preimage of the hash in a specific shard within the blockchain; Collect the anchors associated with the request; The transaction is converted into a set of two or more hashes; as well as Submit the transaction to the sorting service.

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

3. The method of claim 1, wherein the transaction is locally verified by two or more shards in the blockchain network.

4. The method of claim 3, wherein the two or more shards verifying the transaction comprises: Each of the two or more slices receives a corresponding known preimage associated with the two or more hashes; as well as The corresponding known preimage is matched with the two or more hashes by each of the two or more slices.

5. The method according to claim 4, further comprising: The atomic commit of the request is performed by the two or more fragments.

6. The method of claim 5, wherein the atomic commit is performed without sharing any corresponding known preimage with any of the other two or more slices.

7. A system for processing private transactions in a blockchain network, the system comprising: Memory; as well as A processor communicating with the memory, the processor being configured to perform operations including: Generate requests associated with the transaction; The transaction is verified privately, wherein the private verification of the transaction prevents other shards from viewing the information by storing the preimage of the hash in a specific shard within the blockchain; Collect the anchors associated with the request; Transform the transaction into a set of two or more hashes; and Submit the transaction to the sorting service.

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

9. The system of claim 7, wherein the transaction is locally verified by two or more shards in the blockchain network.

10. The system of claim 9, wherein the two or more shards verify the transaction comprising: Each of the two or more slices receives a corresponding known preimage associated with the two or more hashes; as well as The corresponding known preimage is matched with the two or more hashes by each of the two or more slices.

11. The system of claim 10, wherein the operation further comprises: The request is atomically committed by the two or more fragments.

12. The system of claim 11, wherein the atomic commit is performed without sharing any corresponding known preimage with any of the other two or more slices.

13. A computer program product for processing private transactions in a blockchain network, the computer program product comprising program instructions executable by a processor to cause the processor to perform functions, the functions including: Generate requests associated with the transaction; The transaction is verified privately, wherein the private verification of the transaction prevents other shards from viewing the information by storing the preimage of the hash in a specific shard within the blockchain; Collect the anchors associated with the request; The transaction is converted into a set of two or more hashes; as well as Submit the transaction to the sorting service.

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

15. The computer program product of claim 13, wherein the transaction is locally verified by two or more shards in the blockchain network.

16. The computer program product of claim 15, wherein the two or more shards verifying the transaction comprises: Each of the two or more slices receives a corresponding known preimage associated with the two or more hashes; as well as The corresponding known preimage is matched with the two or more hashes by each of the two or more slices.

17. The computer program product according to claim 16, further comprising: The request is atomically committed by the two or more fragments.

18. The computer program product of claim 17, wherein the atomic commit is executed without sharing any corresponding known preimage with any of the other two or more slices.

19. A method for processing private transactions in a blockchain network, the method comprising: Receive requests associated with a transaction; The first preimage pair associated with the first hash is known in the first piece; The transaction is privately verified using the first shard, wherein private verification prevents other shards from viewing the information by storing the preimage of the hash in a specific shard within the blockchain; and Generate a first identifier associated with the transaction.

20. The method of claim 19, further comprising: The second preimage pair associated with the second hash is known to the second piece; as well as Generate a second identifier associated with the transaction.

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

22. The method of claim 21, further comprising: The transaction is submitted atomically to the blockchain network.

23. A method for processing private transactions in a blockchain network, the method comprising: Receive requests associated with a transaction; Assign the first task to the first segment; The first preimage associated with the first hash is known to the first fragment; The transaction is privately verified using the first shard, wherein private verification prevents other shards from viewing the information by storing the preimage of the hash in a specific shard within the blockchain; and Perform the first task.

24. The method of claim 23, further comprising: Assign the second task to the second partition; The second preimage associated with the second hash is known to the second piece; as well as Perform the second task.

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