Reducing transaction aborts in an execution-ordered-validated blockchain model

Abstract

The processor can store the write set of the transaction in a cache. The cache can include state information, and the cache can not be committed to the blockchain. The processor can identify a subsequent transaction. The subsequent transaction can read from the cache when the requested key exists in the cache. The processor can order the transaction and the subsequent transaction based on what is read from the cache. Ordering the transaction and the subsequent transaction can avoid stalling of the subsequent transaction.

Description

Background Technology

[0001] This disclosure generally relates to the field of transaction processing, and more specifically to reducing transaction aborts in the execute-order-validate (EOV) blockchain transaction model.

[0002] Blockchain platforms (such as Hyperledger Fabric) follow the EOV protocol / model. This protocol consists of three phases. In the first phase, blockchain transactions are executed / simulated to collect a set of reads and writes. In the second phase, the executed blockchain transactions are ordered. In the third and final phase, the set of reads from the blockchain transactions is verified to check for any violations of serializability. Summary of the Invention

[0003] Embodiments of this disclosure include methods, systems, and computer programs for reducing transaction aborts in a blockchain model that performs order verification. A processor may store a set of writes of transactions in a cache. The cache may include state information, and the cache may not be committed to the blockchain. The processor can identify subsequent transactions. When the requested key exists in the cache, subsequent transactions can be read from the cache. The processor may order the transactions and subsequent transactions based on what is read from the cache. Ordering the transactions and subsequent transactions can prevent the abort of subsequent transactions.

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

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

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

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

[0008] Figure 2A An example of a distributed system for reducing transaction aborts in a blockchain model that performs order verification, according to embodiments of the present disclosure, is shown.

[0009] Figure 2B An example of a Hyperledger Fabric system for reducing transaction aborts, according to embodiments of the present disclosure, is shown.

[0010] Figure 2CAn example of an improved method for performing sorting verification according to embodiments of the present disclosure is shown.

[0011] Figure 3 A flowchart is shown as an example method for reducing transaction aborts in a blockchain model that performs order verification, according to embodiments of the present disclosure.

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

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

[0014] 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.

[0015] While the embodiments described herein may have various modifications and alternatives, their details have been shown 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 to be construed as limiting. Rather, it is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of this disclosure. Detailed Implementation

[0016] This disclosure generally relates to the field of transaction processing, and more specifically to reducing transaction aborts in the EOV blockchain transaction model. Blockchain platforms (such as Hyperledger Fabric) follow the EOV protocol / model. In this protocol, there are three phases. In the first phase, blockchain transactions are executed / simulated to collect a set of reads and writes. In the second phase, the executed blockchain transactions are ordered. In the third and final phase, the read set of the blockchain transactions is verified to check for any violations of serializability.

[0017] However, a common problem with the EOV protocol is that, due to the time gap between the execution and verification phases, serializability violations are highly likely to occur if multiple conflicting transactions are committed within a short time span. This reduces the effective throughput of the entire blockchain platform. For example, if two transactions are committed to increase an account's balance, only one transaction will be committed, while the other will be aborted due to a serializability violation (e.g., the read version existing in the read set will not match the currently committed version).

[0018] Therefore, this section discusses solutions for avoiding / mitigating serializability violations in detail. As a general overview, the described solution maintains an uncommitted state cache at each node in the blockchain network and caches the write set at the end of the execution phase. When a subsequent dependent transaction executes, it reads from the uncommitted state cache, rather than from the currently committed version, which will soon be modified by previously executed transactions.

[0019] The advantage of this publicly available solution is that, because the execution phase is already deterministic in the EOV model, there is no need to worry about the determinism required in subsequent executions. Therefore, the publicly available solution can support arbitrary data rather than just numbers / integers, which in turn leads to higher effective throughput compared to subsequent executions (because there is no sequential execution).

[0020] Before turning to the accompanying drawings, it will be readily understood that, as generally described and illustrated in the drawings herein, this component can be arranged and designed in a wide 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 is merely representative of selected embodiments.

[0021] In one or more embodiments, the features, structures, or characteristics described herein may be combined or removed in any suitable manner. For example, throughout the specification, the use of the phrases “example embodiment,” “some embodiments,” or other similar language refers to the fact that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment. Therefore, the phrases “example embodiment,” “in some embodiments,” “in other embodiments,” or other similar language appearing throughout the 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 described 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 information.

[0022] Furthermore, although the term "message" may have been used in the description of the embodiments, this application can be applied to many types of networks and data. Additionally, while certain 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.

[0023] Additionally, although the terms transaction, transaction proposal, or proposal may be used throughout this specification, it should be noted that they are interchangeable and synonymous with blockchain transaction / transaction proposal, and should not be construed as a commercial or financial transaction. This is because a blockchain transaction proposal is a proposal to submit data to the blockchain, and a blockchain transaction is either the submission of said data or the execution of smart contract code that can be executed in response to the fulfillment of conditions associated with the smart contract.

[0024] This article details the methods, systems, and computer program products for reducing transaction aborts in the EOV blockchain model.

[0025] In some embodiments, the methods, systems, and / or computer program products utilize a decentralized database (such as a blockchain) as a distributed storage system, comprising multiple nodes communicating with each other. The decentralized database may include only appended immutable data structures, similar to a distributed ledger capable of maintaining records between mutually distrusting parties. These distrustful parties are referred to herein as peers, nodes, and / or peer nodes. Each peer maintains a copy of the database records, and no single peer can modify a database record without consensus among the distributed peers. For example, peers may execute consensus protocols to verify blockchain storage transactions, group storage transactions into blocks, and build a hash chain on the blocks. This process forms a ledger by ordering storage transactions as needed to maintain consistency.

[0026] In various embodiments, permissioned and / or permissionless blockchains can be used. In public or permissionless blockchains, anyone can participate without a specific identity (e.g., remaining anonymous). Public blockchains may involve native cryptocurrencies and use consensus based on various protocols such as Proof of Work. On the other hand, permissioned blockchain databases provide secure interaction between a group of entities that share common goals but do not fully trust each other (such as enterprises exchanging funds, goods, (privacy) information, etc.).

[0027] Furthermore, in some embodiments, the methods, systems, and / or computer program products may utilize a blockchain that operates arbitrary programmable logic adapted to decentralized storage schemes and is referred to as a "smart contract" or "chaincode." In some cases, dedicated chaincode may exist for management functions and parameters referred to as system chaincode (such as managing the ordering / serialization of transactions to be submitted to the blockchain network). In some embodiments, the methods, systems, and / or computer program products may also utilize smart contracts as trusted distributed applications that leverage the tamper-proof nature of the blockchain database and the underlying protocols between nodes; this is referred to as endorsement or endorsement strategy.

[0028] Endorsement policies allow chaincode to specify the endorsers of a transaction in the form of a set of peer nodes required for endorsement. When a client sends a transaction to the peers (e.g., endorsers) specified in the endorsement policy, the transaction is executed to verify it. After verification, the transaction enters an ordering phase, where a consensus protocol is used to produce an ordered sequence of endorsed transactions that are divided into blocks.

[0029] In some embodiments, the method, system, and / or computer program product may utilize nodes as communication entities within a blockchain system. A “node” can perform logical functions, meaning 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 various ways. Nodes may include different types, such as client or submitting client nodes that submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to a sorting service (e.g., sorting nodes).

[0030] Another type of node is the peer node, which receives transactions submitted by clients, submits those transactions, and maintains the state and copies of the ledger for blockchain transactions. Peers can also act as endorsers, although this is not mandatory. Ordering service nodes, or orderers, are nodes that run communication services for all nodes and implement delivery guarantees, such as broadcasting to all peers in the system when a transaction is submitted / confirmed and when the world state of the blockchain is modified. The world state is another name for the initial blockchain transaction, which typically includes control and setting information.

[0031] In some embodiments, the method, system, and / or computer program product may utilize a ledger, which is an ordered, tamper-proof record of all state transitions of a blockchain. State transitions may be generated 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) may maintain a copy of the ledger. A transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as create, update, delete, etc. The ledger comprises 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.

[0032] In some embodiments, the methods, systems, and / or computer program products described herein can utilize a chain as a transaction log, constructed as hashed linked blocks, with each block containing a sequence of N transactions, where N is equal to or greater than one. The block header includes the hash of the block's transactions and the hash of the header of the previous block. 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 arrived on the chain before it, ensuring that all peer nodes are in a consistent and trusted state. This chain can be stored on a peer node file system (e.g., local, attached storage, cloud, etc.), thus efficiently supporting the append-only nature of blockchain workloads.

[0033] The current state of an immutable ledger represents the latest value of all keys included in the chained transaction log. Because the current state represents the latest known key-value pair, it is sometimes referred to as the world state. Chaincode calls execute transactions against the ledger's current state data. To make these chaincode interactions 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 chained transaction log, and therefore can be regenerated from the chain at any time. The state database can be automatically restored (or generated) when peer nodes start up and before transactions are accepted.

[0034] Some of the benefits of this solution described and depicted herein include methods, systems, and computer program products for reducing transaction aborts in the EOV blockchain model. Exemplary embodiments address the problem of transactions that are committed at relatively similar times and may involve the same endpoints (e.g., accounts, databases requiring up-to-date information, etc.).

[0035] Note that blockchain differs from traditional databases in that it is not a central store, but rather a decentralized, immutable, and secure store where nodes can share changes to records within the store. Some properties inherent to blockchain and that contribute to its realization include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, and accessibility, which are further described herein. The system described herein is achieved, in various respects, through immutable accountability, security, privacy, permissive decentralization, the availability of smart contracts, and the inherent and unique accessibility and endorsement of the blockchain.

[0036] Specifically, the immutability of blockchain ledger data provides an efficient way to reduce transaction interruptions in the EOV blockchain model. Furthermore, the use of cryptography in the 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 hosted on the blockchain network. Key organizations can act as endorsers for peers to verify smart contract execution results, read sets, and write sets. In other words, the inherent characteristics of blockchain provide an efficient way to reduce transaction interruptions in the EOV blockchain model and ensure that up-to-date / correct information is submitted to the blockchain, which in turn saves processing power and time associated with handling transactions and reduces pressure on the blockchain network (e.g., peers, nodes, components, etc.). Therefore, it's important to note that blockchain is more than just a database; it has the ability to create user networks and to host / unhost organizations / entities / users that collaborate and execute service processes in the form of smart contracts. Smart contracts can be associated with serialized transactions and can reduce pressure on the blockchain network itself.

[0037] The example implementations offer numerous advantages over traditional databases. For instance, through blockchain, the implementations provide exclusive and unique immutable responsibility, security, privacy, permissioned decentralization, availability, endorsement, and accessibility of smart contracts. Without such benefits, unnecessary processing time and computational power would be wasted on transaction processing / committing.

[0038] Furthermore, traditional databases cannot be used to implement the example embodiments because they do not bring all parties onto the network, do not create trusted collaboration, and do not provide efficient transaction serialization. Traditional databases do not provide tamper-proof storage and do not offer means to avoid transaction interruptions. Therefore, the proposed embodiments utilizing blockchain networks described herein cannot be implemented with traditional databases because without the benefits provided by blockchain, there would again be unnecessary processing time and computational power wasted on transaction processing.

[0039] Furthermore, if traditional databases are used to implement the example embodiments, the examples will suffer from unnecessary drawbacks, such as lack of security and slow data processing. Therefore, the example embodiments provide specific solutions to problems in the field of blockchain transaction processing.

[0040] Turn now Figure 1AThis illustration shows a blockchain architecture 100 according to embodiments of the present 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 only as examples). These nodes participate in multiple activities, such as blockchain transaction increment and verification processes (consensus). One or more of peers 104-110 may endorse and / or recommend transactions based on an endorsement policy and may provide ordering services to all blockchain nodes 102 in the blockchain architecture 100. Blockchain nodes may initiate blockchain authentication and seek to write to the blockchain immutable ledger stored in blockchain layer 116, a copy of which may also be stored on the underlying physical infrastructure 114. Blockchain configurations may include one or more applications 124 linked to an application programming interface (API) 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 by attaching it to the distributed ledger.

[0041] The blockchain foundation or platform 112 may include various layers of blockchain data and services (e.g., cryptographic trust services, virtual execution environments, etc.), as well as the underlying physical computer infrastructure that can be used to receive and store new transactions and provide access to auditors seeking access to data entries. The blockchain layer 116 may expose interfaces that provide access to the processor code and the virtual execution environment required to interface with the physical infrastructure 114. The cryptographic trust service 118 can be used to verify transactions (such as encryption and key generation) and maintain the privacy of information.

[0042] Figure 1AThe blockchain architecture 100 can process and execute program / application code 120 via one or more interfaces exposed by the blockchain platform 112 and the services provided. Application code 120 can control blockchain assets. For example, application code 120 can store and transfer data and can be executed by peers 104-110 in the form of smart contracts and associated chaincode with conditions or other code elements subject to execution. As a non-limiting example, smart contracts can be generated to perform asset / resource transfers, asset / resource generation, etc. Smart contracts themselves can be used to identify rules associated with authorization (e.g., asset transfer rules, restrictions, encryption / key generation, etc.), access requirements (e.g., access requirements for data storage, access requirements for off-chain data storage, access requirements for those who can participate in transactions, etc.), and / or ledger usage. For example, transaction 126 (e.g., serialized using a cached write set to avoid commit interruption) 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 how / will process transaction 126). In some embodiments, physical infrastructure 114 can be used to retrieve any of the data / information / assets described herein.

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

[0044] 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 output of various logical operations to the blockchain. This 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 kept private. Temporary data used / generated by smart contracts is maintained in memory by the supplied execution environment and then deleted once the data required by the blockchain is identified.

[0045] 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 chain validators during the consensus process. The chaincode receives hashes and retrieves from the blockchain a hash associated with a data template created using a previously stored feature extractor. If the hash of the hash identifier matches a hash created from the stored identifier template data, the chaincode sends an authorization key to the requested service. The chaincode can write data associated with cryptographic details to the blockchain (e.g., thus committing transaction 126 or transactions within transaction 126, etc.).

[0046] Figure 1B An example of a blockchain transaction flow 150 between nodes of 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. Endorsing peer 181 verifies the client signature and executes a chaincode function to initiate the transaction. The output may include the chaincode result, a set of key / value versions read from the chaincode (read set), and a set of key / value versions written to the chaincode (write set). If approved, a proposal response 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 on the channel to all peers 181-183. Each peer 181-183 can verify the transaction before it is committed to the blockchain. For example, a peer can check the endorsement policy to ensure that the correct allocation for the designated peer has been signed and that the signature has been verified against the transaction payload 193.

[0047] Refer again Figure 1B Client node 160 initiates transaction 191 by constructing a request and sending it to peer node 181, in this example, where peer node 181 is the endorser. Client 160 may include an application utilizing a supported software development kit (SDK) that leverages available APIs to generate transaction proposal 191. This proposal is a request to invoke a chaincode function so that data can be read and / or written to the ledger. The SDK can reconstruct the package of transaction proposal 191 into an appropriately structured format (e.g., a protocol buffer over a remote procedure call (RPC)) and obtain the client's cryptographic credentials to generate a unique signature for transaction proposal 191.

[0048] In response, the endorsing peer 181 can verify that (a) the transaction proposal 191 is well-formed, (b) the transaction has not been committed before (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 181 can input the transaction proposal 191 as arguments to a invoked chaincode function. The chaincode is then executed against the current state database to produce a transaction result including response values, a set of reads, and a set of writes. However, the ledger is not updated at this time. In some embodiments, this set of values, along with the signature of the endorsing peer 181, is passed back to client 160's SDK as a proposal response 192, which parses the payload for application consumption.

[0049] In response, client 160's application checks / verifies the endorser peer's signature and compares the proposal 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 commit the transaction to the ordering node service 184. If the client application wants to commit the transaction to the ordering node service 184 to update the ledger, the application determines whether the specified endorsement policy has been satisfied before committing. Here, the client may include only one of the many parties in 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 peer and maintained during the commit verification phase.

[0050] After a successful check, in transaction payload step 193, client 160 assembles the endorsement into the transaction and broadcasts the transaction proposal 191 and response to ordering node 184 within the transaction message. The transaction may contain a read set / write set, endorser peer signatures, and channel IDs (e.g., if utilizing a specific [off-chain] data store). Ordering 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, order them by channel in chronological order, and create blocks of transactions by channel.

[0051] The transaction block is delivered on the channel from sorting node 184 to all peer nodes 181-183. Transaction 194 within the block is verified to ensure that any endorsement policy is met and that the ledger state of the read set variable has not changed since the read set was generated by the transaction execution. The transaction in the block is marked as valid or invalid. Furthermore, in step 195, each peer node 181-183 appends the block to the chain of the channel, and for each valid transaction, the write set is committed to the current state database. An event is emitted to notify the client that the transaction (call) has been immutably appended to the chain, and to indicate whether the transaction is valid or invalid.

[0052] Now for reference Figure 2A An example of a distributed system 200 for reducing transaction aborts in an execution order verification blockchain model, according to embodiments of the present disclosure, is shown. As shown, the distributed system 200 includes a client 202, an ordering service 204, a peer 208, a bootstrapping peer 210 including a gossip protocol 212, a cache update propagator 214, a cache update validator 216, a first state cache 218, a first smart contract 220, a second state cache 222, a second smart contract 224, a state database 226, a history database 228, a block store 230, an endorser 232, a block queue 234, an endorsement policy validator 236, and a submitter 240.

[0053] In some embodiments, the bootstrapping peer 210 transmits and receives rumors / information via the rumor protocol 212. The bootstrapping peer may communicate with client 202, ordering service 204, peer 208, endorser 232, cache update propagator 214, and any of the others listed. In some embodiments, communication with the listed components may be via remote procedure calls (e.g., gRPC).

[0054] In some embodiments, distributed system 200 describes a peer-to-peer process used when one or more transactions are sent to distributed system 200 to be added to a blockchain (e.g., block store 230). As described herein, bootstrapping peer 210 first communicates with cache update propagator 214, which sends cache updates to other endorsers (or endorsers 232) of first smart contract 220 or second smart contract 224. As will be discussed more fully below, cache updates can be identified from, or can be a set of writes from one or more transactions, which allows for reduced aborts associated with multiple transactions. In some embodiments, cache update verifier 216 communicates through distributed system 200 and collects cache updates from peer 208, verifying whether all endorsers (e.g., including endorser 232) have provided one or more matching updates.

[0055] In some embodiments, the cache update verifier 216 and the cache update propagator 214 receive their cache updates from either or both of the first state cache 218 and / or the second state cache 222. In any instance, both the first state cache 218 and the second state cache 222 are controlled by their respective smart contracts 220, 224; and reside on any peer 208 authorized by smart contracts 220, 224. The first state cache 218 and the second state cache 222 may also be additionally associated with the first and second transactions (not shown), respectively, and are uncommitted caches of information related to the write sets of the first and second transactions.

[0056] In some embodiments, one or more transactions are submitted to the sorting service 204 by / through the bootstrapping peer 210 in a serial / sequential order, which has been defined by the bootstrapping peer 210 and / or confirmed by the endorser 232 to avoid any abort of the transactions. In some embodiments, to avoid reordering at the sorting service 204, the bootstrapping peer 210 may batch all transactions in a single transaction.

[0057] In some embodiments, the peering process proceeds normally. For example, endorser 232 simulates a transaction directly submitted by a user to bootstrapping peer 210 (or peer 208). In some embodiments, block 235 of block queue 232 is then processed by the remaining components of distributed system 200, as depicted. In some embodiments, endorser 232 provides deterministic transactions to block queue 234. Regardless of the embodiment, endorsement policy validator 236 then verifies that the correct endorser 232 was used and / or the correct endorsement protocol / process was used. Serializability validator 238 then checks whether any read versions have been altered in the committed state. If no alteration is made, the transaction is marked as valid. Otherwise, the transaction is marked as invalid. That is, transactions are ordered based on what is identified in the first state cache 218 and the second state cache 222, such that if a transaction uses information from another, the transaction is not aborted if that other transaction is received by distributed system 200 first.

[0058] In some embodiments, the committer 240 updates the blockchain state (e.g., 226, 228, and 230) and also removes entries from caches 218 and 222. The entries removed from caches 218 and 222 are those present in the write set of the committed transaction. In some embodiments, the state database 226 is stored in the history database 228 and then subsequently stored in the block store 230. Note that the states presented in this disclosure and in… Figure 2AThe novel components depicted are cache update propagator 214, cache update verifier 216, and state caches 218 and 222. Furthermore, the rumor protocol 221 and serializability verifier 238 are novelly modified. Using these novel components and modifications, the existing version management in the architecture remains unchanged.

[0059] It should also be noted that, although described in the process, information propagation in the distributed system 200 can be performed in any manner. For example, information about one or more transactions may be analyzed first, and the information may be sent to either of the caches 218 or 224 before communicating / interacting with the cache update propagator 214 and / or the cache update verifier 216.

[0060] Now go to Figure 2B An example of a hyperledger construction system 250 for reducing transaction interruptions according to embodiments of the present disclosure is shown. As depicted, peer 252A is controlled by organization 258A, and smart contracts 254A, 254B specify which transactions peer 252A handles. In such an embodiment, each smart contract 254A, 254B controls a cache 256A or 256B that holds the write set / information of transactions before submission to the blockchain. Peer 252B, controlled by organization 256B, is also described; and peer 252C, controlled by organization 258C. Each of the other peers 252B and 252C may be controlled by the same smart contracts 254A, 254B. Note that in the drawings, the same reference numerals are used to denote the same parts.

[0061] In some embodiments, smart contract 254A has an "AND(orgA, orgB, orgC)" endorsement policy, while smart contract 254B has an "AND(orgA, orgC)" endorsement policy. In this embodiment, the endorsement policy specifies that all peers 252A-C that host smart contracts 254A and / or 254B execute requests, thus eliminating the need to propagate (uncommitted state) cache updates of 256A and 256B, i.e., simulating the set of write requests.

[0062] In some embodiments, the hyperledger construction system 250 may receive a first transaction proposal and a second transaction proposal simultaneously or substantially simultaneously, and each proposal may be associated with a smart contract 254B. As described, the proposal may not be sent to all peers 252A-C, since smart contract 254B only includes peers 252A and 252C. Traditionally, peer 252A needs to propagate the write set after simulating proposals from other endorsers of smart contract 256B (e.g., peer 252C), and according to the endorsement policy, if peer 252A sends a signed write set to peer 252C, it will trust the received write set (because the signature satisfies the endorsement policy).

[0063] However, in the embodiments disclosed herein, the first transaction proposal and the second transaction proposal modify the same key, or the key / value may be inconsistent. In this case, there is a propagation of cache updates (e.g., such as via...). Figure 2A The cache update propagator 214 will be used, and if the first and second transaction proposals modify the same key, the uncommitted state cache 256A at peers 252A and 252B (because each transaction is associated with smart contract 254A) will be different. Cache 256A at peer 252A will have the update from peer 252B, and cache 256A at peer 252B will have the update from peer 252A. However, note that due to the novel use of the state cache at each peer 252A, 252B, the serializable isolation property will not be affected, as optimistic concurrency control (OCC) verification is always performed only for committed states. It will only result in transaction invalidation (not transaction abort). The cache divergence will be temporary, and it will synchronize once the clients stop committing conflicting transactions simultaneously.

[0064] In some embodiments, for efficiency, conflicting transactions must be submitted one after another by the client. It is proposed that each smart contract have 254A, 254B (e.g., Figure 2A The leader peers of 220 / 224 (e.g., Figure 2A The guiding peer 210 issues a sequence number for each cache update to the smart contract 254A or 254B. Using this sequence, the hyperledger construction system 250 is able to sort the updates and always keep cache 256A / 256B in order across all peers 252A-C (or...). Figure 2A Consistent at 208). In some embodiments, consensus is run among the endorsers of smart contracts 254A-B (e.g., peers 252A-C) to order cache updates.

[0065] In some embodiments, prior to sorting, the endorsement policy identifies a set of constructed peers (e.g., 252A-C) whose signatures are necessary and sufficient to approve any changes to a given chaincode namespace. In this sense, this set of peers 252A-C (or any combination thereof) forms a logical entity collectively referred to as guardians or protectors. Furthermore, if the private data set is in place among these peers 252A-C (or any combination thereof), they are also the only nodes in the network that know the state values ​​in the namespace they protect.

[0066] In this embodiment, the guardian is responsible for coordinating all transactions targeting the namespace being protected by the guardian. Specifically, the guardian collects transactions, analyzes the dependency graph, reorders transactions / proposals as necessary, and submits the transactions to the ordering service. In some embodiments, to avoid reordering at the ordering service, the guardian can batch all transactions within a single transaction. Note that in this embodiment, the commit phase is unaffected, and therefore, it can proceed at full speed. It should also be noted that this embodiment requires coordination among the constructive peers 252A-C (or any combination thereof) forming the guardian, and requires the selection of a leader responsible for submitting transactions to the ordering service.

[0067] As an example, consider a traditional banking scenario where a bank customer wants to make two (or more) different transfers (using some kind of automated software). If each transaction is committed in parallel, only one transaction will pass. The automated software needs to commit each transaction serially after verifying the previous transaction's commit, which significantly reduces the overall throughput. The proposed solution described in this paper alleviates the need for serial verification by caching the set of writes for transactions, ensuring they do not modify information available to previous transactions that is only received or ordered after subsequent transactions.

[0068] To further illustrate, suppose the first transaction received by the banking system is actually transaction two (T2), and T2 has a read set [k1, 1], where the read set contains keys and read versions; and a write set [k1, v3], where the write set contains keys and new values. Furthermore, the banking system has a state database with [k1, v1, 1]. The proposed solution will simulate T2, and during this simulation, at the end of the execution phase of T2, the write set [k1, v3] and the indicator associated with T2 will be stored in an uncommitted state cache (e.g., [k1, v3|T2]).

[0069] Next, after the execution phase of T2, a subsequent transaction T1 (which is actually the first transaction) with a read set [k1, T2] and a write set [k1, v2] can be simulated; and during the execution phase of T1, because the requested key (k1) exists in T1, T1 will read from the uncommitted state cache before execution. In some embodiments, after the execution phase of T1, the uncommitted state cache is now [k1, v2|T1] (e.g., the write set of T1 with an indicator).

[0070] Then, during the sorting phase, it will be identified that T2 needs to be processed before T1 because T1's read set includes T2. Therefore, an edge from transaction T2 to T1 will be added because transaction T1 has version T2 in its read set, and will then be sorted for processing after T1. To perform transaction sorting, we can perform a topological sorting algorithm on the dependency graph. Thus, during the verification phase, transaction T2 will be committed before T1, and the abort of either T1 or T2 is avoided because T1 reads the version written by T2 instead of the stale state. In some embodiments, after the verification of T1 and / or T2, the state database is updated to reflect the correct commit of transactions T1 and / or T2, for example, the state database is transformed from [k1, v1, 1] to [k1, v3, 2] (e.g., with the correct key from the correct version of T2). Simultaneously, entries associated with these transactions present in the uncommitted cache are also removed because they are now available in the state database itself.

[0071] This again highlights the difference between the new method proposed above and the traditional EOV. The validator only notices that T2 is a read version of T1 with the read set [k1, T2] during the validation of T1. Therefore, if T2 has not yet been committed, T1 will be aborted; or if T2 is aborted, T1 will be aborted; or if T2 is committed and the following condition is met, T1 will be committed, otherwise T1 will be aborted. That is, T1 will only be committed if the current committed version of k1 in the database has the same commit key as T2, and the committed version of k1 is the same according to the read set.

[0072] Now for reference Figure 2C An example of an improved Execution Order Verification (EOV) method 270B according to an embodiment of the present disclosure is shown. As shown, the original EOV method 270A processes transaction 272A only after EOV 274A completes, followed by transaction 272B only after EOV 274B completes, and finally transaction 272C only after EOV 274B completes. Therefore, using the original EOV method 270A, the total throughput for processing transactions 272A-C is significantly increased, and the computational power and load on the system (e.g., 200, 250, etc.) that actually processes transactions 272A-C are significantly increased.

[0073] This contrasts with the improved (EOV) method 270B, which caches the write set at the end of each execution phase in EOV 274A-C and can provide transaction balancing (balancing) 276, which identifies whether a transaction is deterministic and whether it should be processed before any other transactions 272A-C. In such an embodiment, the disclosed improved (EOV) method 270B substantially increases performance growth / reduces the total throughput of processing transactions 272A-C.

[0074] Now for reference Figure 3 The diagram illustrates a flowchart of an example method 300 for reducing transaction aborts in a blockchain model that performs order verification, according to embodiments of the present disclosure. In some embodiments, method 300 may be provided by a blockchain network / system (such as...) Figure 2A Distributed systems 200 and / or Figure 2B This is executed by processors, nodes, and / or peer nodes in a hyperledger construction system (250). In some embodiments, method 300 begins with operation 302, where the processor stores a set of writes of transactions in a cache. The cache may include state information, and the cache may not be committed to the blockchain.

[0075] In some embodiments, method 300 proceeds to operation 304, where the processor identifies a subsequent transaction (which may actually be the first transaction received after a technically second transaction). In some embodiments, the subsequent transaction can be read from the cache if the requested key exists in the cache.

[0076] In some embodiments, method 300 proceeds to operation 306, where the processor sorts the transaction and subsequent transactions based on content read from the cache. Sorting the transaction and subsequent transactions can prevent the abort of subsequent transactions. In some embodiments, method 300 may terminate.

[0077] In some embodiments discussed below, one or more operations of method 300 are not depicted for the sake of brevity. Therefore, in some embodiments, storing the write set in a cache allows the read set to include a version number used in the state store and an identifier associated with the transaction. In some embodiments, this identifier represents uncommitted state in the cache (e.g., key, value, version number, iteration, etc.).

[0078] In some embodiments, ordering the transaction and subsequent transactions may include verifying the subsequent transactions. In some embodiments, verifying the subsequent transactions may include the processor identifying a first version number used in the state store as associated with the transaction. The processor may identify a second version number used in the state store as associated with the subsequent transaction, and the processor may determine which of the first or second version numbers is the dependent version number.

[0079] In some embodiments, the processor may recognize that a first version number depends on a second version number. The processor may commit subsequent transactions before this transaction. In some embodiments, the processor may recognize that a second version number depends on a first version number. The processor may commit this transaction before subsequent transactions.

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

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

[0082] The characteristics are as follows:

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

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

[0085] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated based on demand. Partial independence exists because consumers typically cannot control or know the exact portion of the resources provided, but may be able to specify portions at a higher level of abstraction (e.g., country, state, or data center).

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

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

[0088] The service model is as follows:

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

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

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

[0092] The deployment model is as follows:

[0093] Private cloud: Cloud infrastructure operated solely by an organization. It can be managed by the organization or a third party and can exist inside or outside a building.

[0094] Community cloud: 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.

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

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

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

[0098] Figure 4A A cloud computing environment 410 is illustrated. As shown, the cloud computing environment 410 includes one or more cloud computing nodes 400 to which local computing devices used by cloud consumers can communicate, such as 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.

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

[0100] 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 that... Figure 4B The components, layers, and functions shown are for illustrative purposes only, and embodiments of this disclosure are not limited thereto. The following layers and corresponding functions are provided.

[0101] The hardware and software layer 415 includes hardware and software components. Examples of hardware components include: a host 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 networking component 412. In some embodiments, software components include network application server software 414 and database software 416.

[0102] 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.

[0103] In one example, management layer 440 may provide the functionality described below. Resource provisioning 442 provides dynamic procurement of computing resources and other resources utilized to perform tasks within the cloud computing environment. Metering and pricing 444 provides cost tracking when utilizing resources in the cloud computing environment, as well as accounting or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, and 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 the required service level is met. Service level agreement (SLA) planning and fulfillment 450 provides pre-scheduling and procurement of cloud resources, where future needs are anticipated according to the SLA.

[0104] The workload layer 460 provides examples of functionalities that can be leveraged in 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 reducing transaction aborts 472.

[0105] Figure 5 A high-level block diagram of an example computer system 501 according to an embodiment of the present disclosure is shown. This computer system can be used to implement one or more of the methods, tools, and modules described herein, as well as any associated functions (e.g., using one or more processor circuits 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 these components may be directly or indirectly communicatively coupled to enable inter-component communication via a memory bus 503, an I / O bus 508, and an I / O bus interface unit 510.

[0106] Computer system 501 may include one or more general-purpose programmable central processing units (CPUs) 502A, 502B, 502C, and 502D, generally 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 levels of onboard cache.

[0107] System memory 504 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 522 or cache 524. Computer system 501 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 526 may be provided for reading from and writing 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 and 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. Additionally, memory 504 may include flash memory, such as a flash stick drive or flash drive. The memory device 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 functions of various embodiments.

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

[0109] Although the memory bus 503 is Figure 5 While shown as a single bus structure providing a direct communication path between CPU 502, memory subsystem 504, and I / O bus interface 510, 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 hierarchical point-to-point links, star or mesh configurations, multi-layer 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. Additionally, although multiple I / O interface units are shown separating I / O bus 508 from various communication paths to various I / O devices, in other embodiments, some or all I / O devices may be directly connected to one or more system I / O buses.

[0110] 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). Furthermore, 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.

[0111] Notice, Figure 5 The description aims to depict representative main components of an exemplary computer system 501. However, in some embodiments, the various components may have more... Figure 5 The greater or lesser complexity represented therein can exist differently from... Figure 5 The components shown, or other components, and the number, type, and configuration of these components may vary.

[0112] As discussed in more detail herein, it is conceivable 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 internal parts of a larger process.

[0113] This disclosure can be a system, method, and / or computer program product at any possible level of technical detail integration. The computer program product may include a computer-readable storage medium having computer-readable program instructions thereon for causing a processor to execute aspects of this disclosure.

[0114] 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 the following: 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 optical disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or recessed structures with 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 through fiber optic cables), or electrical signals transmitted through wires.

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

[0116] Computer-readable program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) 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 be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the 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.

[0117] 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 will 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.

[0118] 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 can direct a computer, programmable data processing apparatus, and / or other device to operate in a particular manner, such that the computer-readable storage medium in which the instructions are stored includes an article of writing comprising instructions for implementing aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

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

[0120] 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 the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions indicated in the blocks may occur in a non-linear order as shown in the figures. For example, two blocks shown consecutively may actually be implemented as a single step, executed simultaneously, substantially simultaneously, with partial or complete time overlap, or these blocks may sometimes be executed in reverse order, depending on the functions involved. It will also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0121] 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 improvements to existing technologies in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0122] Although this disclosure has been described with reference to specific embodiments, changes and modifications thereto will be apparent to those skilled in the art. Therefore, the appended claims are intended to be construed as covering all such alterations and modifications that fall within the true spirit and scope of this disclosure.

Claims

1. A system for reducing transaction aborts in a blockchain model that performs order verification, the system comprising: Memory; as well as A processor communicating with the memory, the processor being configured to perform operations including: The first peer performs the initial transactions related to the smart contract; The write set of the initial transaction is stored in a first cache instance of the first peer node file system, wherein the first cache instance includes state information of the proposed transaction simulated by the first peer, and wherein the first cache instance is not committed to the blockchain, and the first cache instance is maintained by the cache update propagator as a first cache instance of uncommitted state cache shared among the endorsers of the smart contract, the endorsers including the first peer and the second peer. Identify subsequent transactions, wherein the subsequent transaction is read from the cache of the corresponding peer node when the key of the requested subsequent transaction exists in the uncommitted state cache; The subsequent transactions are performed by the second peer; The write set of the subsequent transactions is stored in a second cache instance of the second peer node file system, wherein the second cache instance includes the state information of the proposed transaction simulated by the second peer, and wherein the second cache instance is not committed to the blockchain, and the second cache instance is maintained by the cache update propagator as the second cache instance of the uncommitted state cache. The cache update propagator propagates the update to the uncommitted state cache to the first cache instance and the second cache instance; as well as The initial transaction and the subsequent transactions are sorted based on the content read from the uncommitted state cache, wherein sorting the initial transaction and the subsequent transactions avoids the abort of the subsequent transactions.

2. The system of claim 1, wherein ordering the initial transaction and the subsequent transactions includes verifying the subsequent transactions by: Identify the first version number used in the status information that is associated with the initial transaction; Identify the second version number used in the status information that is associated with the subsequent transaction; as well as Determine which of the first or second version numbers is the dependency version number.

3. A method for reducing transaction aborts in a blockchain model that performs order verification, the method comprising: The first peer performs the initial transactions related to the smart contract; The write set of the initial transaction is stored in a first cache instance of the first peer node file system, wherein the first cache instance includes state information of the proposed transaction simulated by the first peer, and wherein the first cache instance is not committed to the blockchain, and the first cache instance is maintained by the cache update propagator as a first cache instance of uncommitted state cache shared among the endorsers of the smart contract, the endorsers including the first peer and the second peer. Identify subsequent transactions, wherein the subsequent transaction is read from the cache of the corresponding peer node when the key of the requested subsequent transaction exists in the uncommitted state cache; The subsequent transactions are performed by the second peer; The write set of the subsequent transactions is stored in a second cache instance of the second peer node file system, wherein the second cache instance includes the state information of the proposed transaction simulated by the second peer, and wherein the second cache instance is not committed to the blockchain, and the second cache instance is maintained by the cache update propagator as the second cache instance of the uncommitted state cache. The cache update propagator propagates the update to the uncommitted state cache to the first cache instance and the second cache instance; as well as The initial transaction and the subsequent transactions are sorted based on the content read from the uncommitted state cache, wherein sorting the initial transaction and the subsequent transactions avoids the abort of the subsequent transactions.

4. The method of claim 3, wherein ordering the initial transaction and the subsequent transactions includes verifying the subsequent transactions by: Identify the first version number used in the status information that is associated with the initial transaction; Identify the second version number used in the status information that is associated with the subsequent transaction; as well as Determine which of the first or second version numbers is the dependency version number.

5. A computer program product for reducing transaction aborts in an execution order verification blockchain model, the computer program product comprising a computer-readable storage medium having program instructions implemented therewith, the program instructions being executable by a processor to cause the processor to perform processing, the processing including: The first peer performs the initial transactions related to the smart contract; The write set of the initial transaction is stored in a first cache instance of the first peer node file system, wherein the first cache instance includes state information of the proposed transaction simulated by the first peer, and wherein the first cache instance is not committed to the blockchain, and the first cache instance is maintained by the cache update propagator as a first cache instance of uncommitted state cache shared among the endorsers of the smart contract, the endorsers including the first peer and the second peer. Identify subsequent transactions, wherein the subsequent transaction is read from the cache of the corresponding peer node when the key of the requested subsequent transaction exists in the uncommitted state cache; The subsequent transactions are performed by the second peer; The write set of the subsequent transactions is stored in a second cache instance of the second peer node file system, wherein the second cache instance includes the state information of the proposed transaction simulated by the second peer, and wherein the second cache instance is not committed to the blockchain, and the second cache instance is maintained by the cache update propagator as the second cache instance of the uncommitted state cache. The cache update propagator propagates the update to the uncommitted state cache to the first cache instance and the second cache instance; as well as The initial transaction and the subsequent transactions are sorted based on the content read from the uncommitted state cache, wherein sorting the initial transaction and the subsequent transactions avoids the abort of the subsequent transactions.

6. The computer program product of claim 5, wherein ordering the initial transaction and the subsequent transactions includes verifying the subsequent transactions by: Identify the first version number used in the status information that is associated with the initial transaction; Identify the second version number used in the status information that is associated with the subsequent transaction; as well as Determine which of the first or second version numbers is the dependency version number.

Images