Supporting two-stage communication protocol

Abstract

The blockchain system is capable of participating in distributed transactions using a two-stage commit protocol ("2PC"). In a 2PC, a computer system, such as a DBMS or blockchain system, submits transactions that change data (e.g., database, world state) using two stages. To participate in a distributed transaction using a 2PC, a blockchain system performs a "staged transaction". The staged transaction passes through a 2PC stage. In the preparation stage, the new value of the world state record is temporarily stored in the stage record as a stage value. In a second stage, if a distributed transaction is to be submitted, a world stage record is set to a stage value.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to distributed transactions with respect to blockchain systems. BACKGROUND

[0002] In a blockchain system, blockchain clients submit transaction requests to change a database called the world state. These changes are recorded in the blockchain as blockchain transactions (“BC transactions”). The blockchain system is decentralized and distributed, meaning that the blockchain system has multiple copies of both the blockchain and the world state. Copies of the blockchain can be collectively referred to herein as the blockchain.

[0003] The world state includes world state records, each containing one or more values. For example, a world state record can be a key-value pair representing a currency token spent and generated for a transaction.

[0004] The blockchain system includes multiple peer nodes, some or all of which are responsible for participating in forming and approving BC transactions and / or recording BC transactions in their respective copies of the blockchain.

[0005] In a blockchain system, multiple peer nodes can receive transaction requests. The blockchain transaction of each transaction request must be approved by multiple peer nodes in the blockchain system. Multiple BC transactions can be grouped into a “transaction block” that is appended to each copy of the blockchain in the blockchain system. The appending of a block containing one or more blockchain transactions and any changes to the world state specified by the BC transactions are committed together.

[0006] The blockchain system can support multiple blockchains and corresponding world states. Each blockchain and its corresponding world state can be managed by a different set of peer nodes in the blockchain system. In a blockchain system that supports multiple blockchains and corresponding world states, the blockchain, the corresponding world state, the corresponding peer nodes participating in managing the blockchain and the world state, and / or the computing nodes are referred to as a blockchain channel.

[0007] Cross-blockchain transactions: Heterogeneous distributed transactions.

[0008] A scenario increasingly common in blockchain systems involves cross-BC transactions. A cross-BC transaction changes multiple world states of corresponding multiple blockchains. Each change to each world state is recorded in the corresponding separate blockchain. For example, a cross-BC transaction can involve selling a property owned by participant A in exchange for tokens paid by participant B. The payment of tokens and the transfer of property are handled in two different blockchain systems, a bank blockchain system and a property record blockchain system. The payment of tokens is recorded in a BC transaction of the bank blockchain system, and the exchange of property is recorded in a BC transaction of the property record blockchain system.

[0009] It is desirable to execute cross-BC transactions atomically across multiple respective blockchains. For example, to execute a cross-blockchain for a property sale, it is desirable to commit both BC transactions together successfully, i.e., atomically, or not at all.

[0010] One way to execute cross-BC transactions atomically is finality atomicity. In finality atomicity, a cross-BC transaction performed for a client is executed as separate BC transactions. The client issues the separate BC transactions to the respective blockchain systems. If one BC transaction succeeds and the other BC transaction fails, the client issues a compensating BC transaction for the successful BC transaction to effectively undo the changes to the successful BC transaction.

[0011] Another scenario that can become prevalent in blockchain systems involves heterogeneous distributed transactions. A heterogeneous distributed transaction is a distributed transaction that is executed atomically and includes one or more transactions executed on a blockchain system and one or more transactions executed on a non-blockchain data processing system, such as a database management system (DBMS). Heterogeneous distributed transactions can also be executed atomically using finality atomicity.

[0012] Finality atomicity has at least some drawbacks. This approach requires client implementation code to handle compensating transaction processing, which can be very complex. Moreover, the state of the respective world state can remain inconsistent for an unacceptably long period of time before the compensating transaction is executed. BRIEF DESCRIPTION OF DRAWINGS

[0013] In the drawings:

[0014] Figure 1 is a schematic diagram depicting a blockchain system in accordance with an embodiment of the present application.

[0015] Figure 2 is a schematic diagram depicting operations performed for a preparation phase of a staged transaction in accordance with an embodiment of the present application.

[0016] Figure 3 is a schematic diagram depicting operations performed for a commit phase of a staged transaction in accordance with an embodiment of the present application.

[0017] Figure 4 is a schematic diagram depicting operations performed for a rollback phase of a staged transaction in accordance with an embodiment of the present application.

[0018] Figure 5 is a schematic diagram depicting a heterogeneous distributed transaction performed in accordance with an embodiment of the present application.

[0019] Figure 6 is a schematic diagram depicting a computer system that can be used to implement an embodiment of the present application.

[0020] Figure 7 A software system usable to control operations is described. DETAILED DESCRIPTION

[0021] In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present application. It will be apparent, however, that the present application can be practiced without

[0022] SUMMARY

[0023] Described herein are methods that enable a blockchain system to participate in distributed transactions that use a two-phase commit protocol ("2PC"). In 2PC, a computer system such as a DBMS or a blockchain system uses a two-phase commit to change data (e.g., a database, a world state) in a transaction. The first phase is a prepare phase. In the prepare phase, the computer system reaches a "prepared state." When in the prepared state, if the computer system is requested or otherwise decides to commit the transaction or roll back the transaction, the computer system is already in a state where the computer system can commit the transaction or roll back the transaction. In the second phase, the computer system commits or rolls back the transaction. The second phase can be referred to herein as a commit phase or a rollback phase, depending on whether the transaction is committed or rolled back in the second phase. A computer system that supports 2PC can participate in distributed transactions that use 2PC as a single transaction commit or rollback.

[0024] To participate in distributed transactions that use 2PC, a blockchain system performs a "staged transaction." A staged transaction goes through the 2PC phases. In the prepare phase, a new value of a world state record is temporarily stored in a phase record as a phase value. In the second phase, if the distributed transaction is to be committed, the world state record is set to the phase value.

[0025] A staged transaction includes two separate BC transactions, each of which commits a world state change. In the prepare phase, the world state is changed to store a phase value in a phase record; a "prepare BC transaction" is committed to change the world state to store the phase value in the phase record. In the second phase, a "commit BC transaction" can be committed to set the world state record to the phase value.

[0026] Exemplary Blockchain System

[0027] Figure 1 A blockchain system 101 is described, an illustrative blockchain system used in embodiments of the present application. The blockchain system 101 manages a blockchain and corresponding world state using a manner referred to herein as the execute-order-validate manner, the phases and steps of which are described in Figure 1 As the name of the manner suggests, the phases include an execute phase, an order phase, and a validate phase. Each of the phases, and the steps performed therein, will be explained in more detail.

[0028] The blockchain system 101 includes peer computing nodes that participate in the stages of the execution phase and / or the validation phase. The peer computing nodes can be referred to herein as BC peers or simply peers. The blockchain system 101 includes BC peers 102-1, 102-2, and 102-3, which can be collectively referred to herein as BC peers 102.

[0029] The ordering phase is performed by an ordering service, which can or can not be a peer. The computing nodes that perform the ordering phase are not described in Figure 1

[0030] As will be explained in further detail, each BC peer 102 maintains a world state replica of a distributed world state of the blockchain system 101 and a blockchain replica of a distributed blockchain of the blockchain system 101. The BC peers 102-1, 102-2, and 102-3 maintain world state replicas 104-1, 104-2, and 104-3 and blockchain replicas 105-1, 105-2, and 105-3, respectively. The world state replicas 104-1, 104-2, and 104-3 can be collectively referred to as the distributed world state 104. The blockchain replicas 105-1, 105-2, and 105-3 can be collectively referred to as the distributed blockchain 105.

[0031] Each peer in the blockchain system 101 includes blockchain metadata that defines configurations and other aspects of the blockchain system 101. The blockchain metadata defines, among other things, the peers of the blockchain system 101, the endorsement policy, and the blockchain code.

[0032] As previously mentioned, a blockchain system can include multiple blockchain channels. Figure 1 Only one blockchain channel is described, which is the blockchain channel that includes the distributed blockchain 105 and the BC peers 102. However, the blockchain system 101 can include one or more other blockchain channels, each channel including a respective distributed blockchain and world state. Each blockchain channel can include a different set of BC peers that service the execution phase, the validation phase, or the ordering phase.

[0033] Execution-order-validation approach

[0034] Endorsers are BC peers in a blockchain channel that participate in the execution phase. Not all BC peers must participate in the execution phase. Peers that do not participate in the execution phase are referred to herein as non-endorsing peers.

[0035] ​The blockchain client sends a BC transaction proposal to each endorser. Each endorser simulates the proposed BC transaction to generate a read-write set. The proposed BC transaction, including the read-write set generated by the endorser, is sent to the ordering service as an endorsed BC transaction.

[0036] In the ordering phase, the ordering service groups the endorsed BC transactions into ordered blocks. In the validation phase, the ordered blocks are sent to peer nodes for processing. In this phase, the peer nodes perform validation checks on the BC transactions in each block and commit valid transactions to the distributed world state and commit blocks to the distributed blockchain.

[0037] The steps performed in each phase are explained below and illustrated using the elements of the blockchain system 101 described in Figure 1

[0038] Endorsement phase

[0039] Step 1 : The blockchain client 120 (see Figure 1 ) sends a BC transaction proposal to BC peer node 102-1 and BC peer node 102-2. The proposed BC transaction can require multiple world state record changes.

[0040] In embodiments of the invention, the BC transaction proposal is sent by a remote call to a smart contract on each of BC peer node 102-1 and BC peer node 102-2. The smart contract is recorded in the distributed blockchain 105 as an approved function that can be called by any blockchain client on an endorser to request a BC transaction from the blockchain system 101.

[0041] Step 2: BC peer node 102-1 and BC peer node 102-2 simulate the execution of the proposed BC transaction on their respective copies of the distributed world state 104, which are world state copy 104-1 and world state copy 104-2. The simulation generates a read-write set. BC peer node 102-1 and BC peer node 102-2 each send an endorsement response that includes the read-write set and a digital signature generated based on the specific contents of the respective endorsement response. The endorsement response also includes data indicating whether the endorser endorses (i.e., approves) the proposed BC transaction. An endorsement response that approves the proposed BC transaction is referred to herein as an endorsement. Each of BC peer node 102-1 and BC peer node 102-2 sends the endorsement to the blockchain client 120.

[0042] If the BC transaction request is sent by calling a smart contract, the endorsement response includes the identity of the smart contract assigned by the blockchain system 101 and the input parameters of the smart contract call.

[0043] ​Step 3: The blockchain client 120 collects the endorsement responses sent by the BC peers 102-1 and 102-2 and packages the endorsement responses into an endorsed BC transaction. The endorsed BC transaction is sent to the ordering service 103. In an embodiment, the blockchain client 120 sends the endorsed BC transaction to the BC peers 102, which then forward the endorsed BC transaction to the ordering service 103.

[0044] Ordering phase

[0045] Step 4: The ordering service 103 receives the endorsed BC transactions sent from blockchain clients including the blockchain client 120 and organizes the BC transactions into an ordered transaction block.

[0046] Step 5: The ordered transaction block is sent to all the peers of the blockchain system 101. These are the BC peers 102-1, 102-2, and 102-3.

[0047] Validation phase

[0048] Step 6: Upon receiving the transaction block, each of the BC peers 102 independently validates each BC transaction in the transaction block by performing various validation checks. Each peer determines whether the block transaction has a sufficient number of endorsements according to the endorsement policy. The digital signatures from each endorser in the BC transaction are checked.

[0049] Step 7: Each of the BC peers 102 modifies the world state records for valid BC transactions in its respective world state copy. No world state changes are made for invalid BC transactions. Each peer appends the respective transaction block to its respective blockchain copy. Each peer commits the changes to their world state copies and appends the transaction block to their blockchain copies together. The transaction block includes BC transactions that are valid or invalid.

[0050] The execute-order-validate approach is described in Jeet Ann Chacko et al., Why Do My Blockchain Transactions Fail?, ACM SIGMOD 2021, March 8, 2021, the entirety of which is incorporated by reference herein. A blockchain system is also described in U.S. Patent Application No. 16 / 261,363, filed January 29, 2019, by Carlo Innocenti, the entirety of which is incorporated by reference herein (the computing nodes are referred to as nodes).

[0051] Preparation phase of the phased transaction

[0052] Figure 2 Operations performed by a blockchain channel for the prepare phase of a staged transaction are described. In particular, Figure 2 Operations performed by a transaction manager of a blockchain channel, a peer node, and an ordering service are described. The transaction manager operates as a blockchain client of the blockchain channel. As previously described, a staged transaction includes a prepare BC transaction followed by a commit BC transaction or a rollback BC transaction. Figure 2 The operations described in the involve committing the prepare BC transaction to add a stage value to the world state.

[0053] Reference is made to Figure 2 The transaction manager receives a request to execute a distributed blockchain transaction. The request specifies that multiple BC transactions are to be executed as a distributed transaction on respective blockchain channels. For example, the request can request that two smart contracts are to be executed together as a distributed transaction on separate blockchain channels.

[0054] In addition, the request specifies an isolation level. The isolation level determines the kind of locks that are to be performed for the staged transaction in the distributed blockchain transaction, which will be explained in more detail.

[0055] In response to receiving the request for the distributed blockchain transaction, the transaction manager generates a distributed transaction identifier ("DTXID") and sends a prepare BC transaction proposal to each of the separate blockchain channels. The prepare BC transaction proposal includes the DTXID. For example, the transaction manager sends a prepare blockchain transaction proposal to each peer node of each of the separate blockchain channels to execute one of the two smart contracts.

[0056] Figure 2 The operations described in the are performed by the transaction manager of a blockchain channel, each peer node, or the ordering service. The operations performed by a peer node are further described herein with respect to one of the peer nodes of one of the blockchain channels.

[0057] In response to the peer node receiving the prepare blockchain transaction proposal, the peer node generates a read-write state referred to as a stage write set. (220) The stage read-write state includes read versions of the world state records that are to be changed.

[0058] However, rather than containing new values of the world state records that are to be changed, the write set contains new values that are stage values of "stage records." The write set is referred to herein as a stage write set. The stage records are staged versions of the world state records that are to be changed. At commit stage, as will be explained in more detail, the world state records that are to be changed are set to the stage values stored in their respective stage records.

[0059] The stage write set also includes transaction metadata records that hold transaction metadata that describes the stage transaction. The stage records and the transaction metadata records are collectively referred to herein as stage state.

[0060] For example, the following world state record stores the balance of user Kerry as a key-value pair. Distributed blockchain transaction DTX53 (DTX53 is a DTXID) changes the balance from 20 to 30. The read-write set of the prepare BC transaction includes the following read-write set.

[0061]

[0062] The world state record with key "2PC.Staged.DTX53.Kerry" is a staging record. The world state record with key "2PC.Status.DTX53" is a transaction metadata record that specifies that the status of the staged transaction of distributed transaction DTX53 is prepared and the isolation level is read-committed.

[0063] Next, the peers create and send endorsements to the transaction manager based on the staging status.(222) Then, the transaction manager collects the endorsements from the peers in the blockchain channel.(214)

[0064] The transaction manager packages the endorsements into an endorsed prepared BC transaction. Then, the transaction manager sends the endorsed prepared BC transaction to the peers to forward to the ordering service.(216) Then, the peers forward the endorsed prepared BC transaction to the ordering service.(224)

[0065] The ordering service forms a transaction block that includes the prepared BC transaction.(230) Then, the ordering service sends the transaction block to the peers.(232)

[0066] In response to receiving the transaction block, if the isolation level requires locking, the peers lock the changed world state records, which will be explained later.(226)

[0067] Next, the peers commit the transaction block to their respective blockchain replicas and commit the staging status to their respective world state replicas.(228) Committing the staging status requires committing the staging record and the transaction metadata record. At this stage, the staged transaction is ready for commitment.

[0068] The peers send a prepared notification to the transaction manager. The prepared notification can simply include confirmation that the endorsed prepare BC transaction is committed, i.e., the transaction block holding the prepare BC transaction is committed and the corresponding write set of the prepare BC transaction is committed to the world state.(229) The transaction manager receives the prepared notification.(218)

[0069] Commitment phase of the staged transaction

[0070] Figure 3 Operations performed by a transaction manager, peer node, or ordering service of a blockchain channel during a commit phase are described. The operations can be initiated by the transaction manager in response to receiving a ready notification from a peer node.

[0071] Reference is made to Figure 3 The transaction manager sends a commit BC transaction proposal to each individual blockchain channel. (312) For example, the transaction manager sends a commit BC transaction proposal to each peer node of each individual channel.

[0072] (320) In response to a peer node receiving the commit BC transaction proposal, the peer node generates a read-write state referred to herein as a commit read-write set. The commit write set specifies changes to the corresponding transaction metadata record that indicate that the corresponding distributed blockchain transaction is committed. For example, the write set of the commit BC transaction for distributed blockchain transaction DTX53 includes the following:

[0073] “2PC.Status.DTX53” = “state = committed,

[0074] isolevel = read-commit”

[0075] Next, the peer node creates an endorsement based on the committed BC transaction and sends the endorsement to the transaction manager. (322) The transaction manager then collects the endorsements sent from the peer nodes. (314)

[0076] The transaction manager packages the endorsements into an endorsed commit BC transaction. The transaction manager sends the endorsed commit BC transaction to the peer nodes. (316) The peer nodes forward the endorsed commit BC transaction to the ordering service. (324)

[0077] The ordering service forms a transaction block that includes the endorsed commit BC transaction. (330) The ordering service sends the transaction block to the peer nodes. (332)

[0078] (325, 326) In response to receiving the transaction block, the peer nodes change the value of the world state record to the corresponding stage value stored in the corresponding stage record. If the isolation level requires, the world state record is locked before changing the world state record. In the current example, the world state record (set to the stage value) and the corresponding stage record are shown below.

[0079] World State Record Corresponding Stage Record

[0080] “Kerry” = 30 “2PC.Staged.DTX53.Kerry” = 30

[0081] Next, the peer submits the change to the phase value of the world state record and the set of transaction metadata records that specify the status of the phased transaction. The transaction block is also submitted to the peer's respective copy of the blockchain. At this stage, the distributed transaction is committed. The committed world state record and transaction metadata records are referred to herein as the committed state.

[0082] Next, the peer unlocks the world state record that was locked for the distributed blockchain transaction, if any. (328) The peer sends a committed notification to the transaction manager. The committed notification can simply include confirmation that the endorsed committed BC transaction is committed, i.e., that the transaction block holding the committed BC transaction is committed and the respective write set of the committed BC transaction is committed to the world state. (329) The transaction manager receives the prepared notification. (318)

[0083] Rollback phase of a phased transaction

[0084] Figure 4 Operations performed by the transaction manager of a blockchain channel, a peer, or an ordering service during the rollback phase are described. The operations can be initiated by the transaction manager in response to receiving a prepared notification from a peer.

[0085] Reference Figure 4 The transaction manager sends a rollback BC transaction proposal to each individual blockchain channel. (412)

[0086] (420) In response to the peer receiving the rollback BC transaction proposal, the peer generates a read-write state referred to herein as a rollback read-write set. The rollback read-write set specifies changes to the respective transaction metadata records to indicate that the respective distributed blockchain transaction is rolled back. For example, the write set of distributed blockchain transaction DTX53 includes the following:

[0087] "2PC.Status.DTX53" = "state = rollback,

[0088] isolevel = read-commit"

[0089] Next, the peer creates an endorsement based on the proposed rollback BC transaction and sends the endorsement to the transaction manager. (422) The transaction manager collects the endorsements from the peers. (414)

[0090] The transaction manager packages the endorsements into an endorsed rollback BC transaction. The transaction manager sends the endorsed rollback BC transaction to the peers. (416) The peers forward the endorsed rollback BC transaction to the ordering service. (424)

[0091] The ordering service forms a transaction block that includes the endorsed rollback BC transaction. (430). The ordering service sends the transaction block to the peer. (432)

[0092] In response to receiving the transaction block, the peer abandons changing the value of the world state record to the corresponding phase value stored in the corresponding phase record. The peer commits the changes to the transaction metadata record and the transaction block. (426) At this stage, the distributed transaction is rolled back.

[0093] Next, the peer unlocks the world state record, if any, that was locked for the distributed blockchain transaction. (428) The peer sends a rollback notification to the transaction manager. The rollback notification can simply include confirmation that the endorsed rollback BC transaction was committed, i.e., the transaction block holding the rollback BC transaction was committed, and the corresponding write set of the rollback BC transaction was committed to the world state. (429) The transaction manager receives the prepared notification. (418)

[0094] XA Transaction

[0095] According to embodiments, a distributed transaction involving phased transactions can be a heterogeneous distributed transaction. The blockchain system and other participants can participate in a distributed transaction using a distributed transaction protocol specified in the X / Open XA specification. A distributed transaction using the protocol specified in the X / Open XA specification is referred to herein as an XA transaction. An XA transaction includes branch transactions that are committed or rolled back together using 2PC. An XA transaction is managed by a global transaction manager. Each branch transaction is managed by either a distributed transaction participant or the global transaction manager. In embodiments, an XA transaction includes one or more phase transactions that are branch transactions.

[0096] Figure 5 An illustrative execution of an XA transaction is described in which the transaction manager of the phased transaction also operates as the global transaction manager of the heterogeneous distributed transaction, which includes branch database transactions executed on participant DBMSs. In the illustrated example, the global transaction manager is the blockchain transaction manager that represents the retailer. Figure 5 In the illustrated example, the blockchain transaction manager that represents the retailer also is the global transaction manager that manages the XA transaction.

[0097] The XA transaction represents a consumer purchasing a product from the retailer that is shipped from a warehouse. The XA transaction includes three branch transactions as follows.

[0098] (1) (a) a phased transaction that records income to the retailer 100 on a blockchain channel R, and (b) a phased transaction that records an expense to the consumer 100 on a blockchain channel C.

[0099] (2) a database transaction that records the order in a DBMS used by the warehouse.

[0100] The global transaction manager manages the XA transaction as a branch transaction of the respective staged transactions on blockchain channel R and blockchain channel C, and manages the database transaction on the warehouse DBMS using the XA protocol.

[0101] To execute the XA transaction, the transaction manager adds the prepare BC transaction to the blockchain channel R and the blockchain channel C by performing the prepare phase operation shown in Figure 2 The blocks 510 and 512 show the phase state committed by the prepare phase on the blockchain channel R and C, respectively. The transaction manager initiates a database transaction to add the order to the warehouse DBMS using the XA protocol. In the database transaction of the warehouse DBMS, the transaction manager sends a prepare request.

[0102] Upon receiving the prepared notification from the warehouse DBMS and the blockchain channels, the global transaction manager coordinates the commit of the XA transaction. The global transaction manager performs the commit phase operation to commit the distributed blockchain transaction on the blockchain channel R and the blockchain channel C. The blocks 520 and 522 show the committed state. The global transaction manager also sends a commit request to the warehouse DBMS. Finally, the transaction manager receives the committed notification from the warehouse DBMS and the blockchain channel R and the blockchain channel C.

[0103] In general, the XA transaction and the distributed transaction can include any number of branch transactions executed as staged transactions and any number of branch transactions executed on a computer system that supports 2PC of changing data on the computer system.

[0104] Isolation Levels

[0105] As previously described, a request to execute a distributed transaction on a blockchain system or channel can specify an isolation level. The isolation level of the request determines the locking of the world state records of the staged transactions executed as part of the distributed transaction. According to embodiments, the isolation levels are serializable, read-committed, and read-uncommitted.

[0106] For the serializable isolation level, as block 226 (see Figure 2 ), a lock is issued to lock the world state records changed during the prepare phase before the phase records of the staged transaction are changed. The locking of the world state records at this time in the staged transaction ensures that the records can be changed in the commit phase. For the read-committed isolation level, the world state records changed are locked before the phase values of the phase records are applied. The locking of the world state records at this time in the staged transaction can be desirable when changes to the world state records can be tolerated between the prepare phase and the commit phase.

[0107] At the read-uncommitted isolation level, records are not locked; however, the types of changes that can be made are limited. Changes to the world state record are limited to changing a numeric value by applying a difference or increment to the numeric value. For example, the world state record can store a balance. Changes made by the blockchain system to the world state record apply an increment to the balance. An example of handling changes to the world state in this manner is described in U.S. Patent Application No. 17 / 895,240, Minimizing Read and Update Conflict Errors In Blockchains, by Carlo Innocenti, filed August 25, 2022, the entirety of which is incorporated by reference herein.

[0108] Blockchain peer / participant is a computing node

[0109] Each peer or participant in the blockchain system can include one or more computing nodes. A computing node is a combination of one or more hardware processors that each share access to byte-addressable memory. Each hardware processor is electrically coupled to registers on the same chip as the hardware processor and is capable of executing an instruction that references a memory address in the addressable memory and causing the hardware processor to load data at that memory address into any register. In addition, the hardware processor can access its own private memory that other processors cannot access. The one or more hardware processors can run under the control of the same operating system.

[0110] A hardware processor can include multiple core processors on the same chip, each core processor (“core”) capable of executing machine code instructions separately from another one of the multiple cores in the same clock cycle. Each core processor can be electrically coupled to connect to a scratchpad memory that cannot be accessed by any other core processor of the multiple core processors.

[0111] A cluster includes computing nodes that each communicate with each other over a network. Each node in the cluster can be coupled to a network card or network integrated circuit on the same board as the computing node. Network communication between any two nodes occurs through the network card or network integrated circuit on one node and the network card or network integrated circuit on the other node. The network can be configured to support remote direct memory access.

[0112] DBMS overview

[0113] A database management system (DBMS) manages a database. The DBMS can include one or more database servers. A database includes database data and a database dictionary, which are stored on persistent storage mechanisms such as a set of hard disks. The database data can be stored in one or more collections of records. The data in each record is organized into one or more attributes. In a relational DBMS, the collections are called tables (or data frames), the records are called records, and the attributes are called attributes. In a document DBMS (“DOCS”), the collection of records is a collection of documents, each of which can be a data object marked up in a hierarchical markup language, such as a JSON object or an XML document. These attributes are called JSON fields or XML elements. A relational DBMS can also store hierarchical markup data objects; however, the hierarchical markup data objects are contained in attributes of records, such as JSON-type attributes.

[0114] A user interacts with a database server of a DBMS by submitting commands to the database server, which cause the database server to perform operations on data stored in the database. The user can be one or more applications running on a client computer that is interacting with the database server. Multiple users can also be collectively referred to as users herein.

[0115] A database command can be in the form of a database statement that conforms to a database language. The database language used to express database commands is Structured Query Language (SQL). There are many different versions of SQL; some versions are standard, some versions are proprietary, and there are multiple extensions. Data Definition Language (“DDL”) commands are issued to the database server to create or configure data objects, such as tables, views, or complex data types, referred to herein as database objects. SQL / XML is a common extension of SQL used when manipulating XML data in an object-relational database. Another database language to express database commands is Spark TM SQL, which uses a syntax based on function or method calls.

[0116] In DOCS, a database command can be in the form of a function or object method call that invokes a CRUD (create read update delete) operation. An example of an API for such functions and method calls is MQL (MondoDB TM Query Language). In DOCS, a database object includes a collection of documents, a document, a view, or a field defined by a JSON schema for a collection. A view can be created by invoking a function provided by the DBMS for creating a view in the database.

[0117] Changes to a database in a DBMS are accomplished using transaction processing. A database transaction is a set of operations that change the data of a database. In a DBMS, a database transaction is initiated in response to a database command requesting a change, such as a DML command requesting an update, insertion of a record, or deletion of a record, or a CRUD object method call requesting creation, update, or deletion of a document. DML commands and DDL specify changes to data, such as insert (INSERT) and update (UPDATE) statements. DML statements or commands do not refer to statements or commands that merely query database data. Committing a transaction refers to making the changes to the transaction permanent.

[0118] Under transaction processing, all changes of a transaction are performed atomically. When a transaction is committed, either all changes are committed or the transaction is rolled back. The changes are recorded in change records, which can include redo records and undo records. Redo records can be used to reapply changes made to data blocks. Undo records are used to reverse or undo changes made to data blocks by a transaction.

[0119] Examples of such transaction metadata include change records that record changes made to database data by a transaction. Another example of transaction metadata is embedded transaction metadata stored in database data, which describes transactions that changed the database data.

[0120] Undo records are used to provide transactional consistency by performing operations referred to herein as consistency operations. Each undo record is associated with a logical time. An example of a logical time is a system change number (SCN). For example, a Lamporting mechanism can be used to maintain SCNs. For a data block read for a computation of a database command, the DBMS applies the required undo records to a copy of the data block to bring the copy to a state consistent with the snapshot time of the query. The DBMS determines which undo records to apply to a data block based on the respective logical times associated with the undo records.

[0121] In a distributed transaction, multiple DBMSs commit a distributed transaction using a two-phase commit approach. Each DBMS performs a local transaction in a branch transaction of the distributed transaction. One DBMS, referred to herein as a coordinator DBMS, is responsible for coordinating the commit of the transaction on one or more other database systems. The other DBMSs are referred to herein as participant DBMSs.

[0122] Two-phase commit includes two phases, a prepare phase and a commit phase. In the prepare phase, a branch transaction is prepared in each participating database system. When the branch transaction is prepared on a DBMS, the database is in a "prepared state" such that it can guarantee that modifications to the database data performed as part of the branch transaction can be committed. This guarantee can entail persistently storing change records for the branch transaction. When the participating DBMSs have completed the prepare phase and have entered the prepared state for the respective branch transactions of the participating DBMSs, the participating DBMSs perform a confirmation.

[0123] In the commit phase, the coordinator database system commits the transaction on the coordinator database system and the participating database systems. Specifically, the coordinator database system sends a message to the participants requesting that the participants commit the modifications specified by the transaction to the data on the participating database systems. The participating database systems and the coordinator database system then commit the transaction.

[0124] On the other hand, if the participating database systems cannot prepare or the coordinator database system cannot commit, then at least one database system cannot make the changes specified by the transaction. In this case, all modifications at each participant and the coordinator database system are undone, restoring each database system to its state prior to the changes.

[0125] A client can issue a series of requests to a DBMS by establishing a database session, such as requests to execute queries. A database session includes a particular connection to a database server established for a client, through which the client can issue a series of requests. A database session process executes in a database session and processes requests issued by a client through the database session. A database session can generate an execution plan for a query issued by a database session client and schedule slave processes for executing the execution plan.

[0126] A database server can maintain session state data about a database session. The session state data reflects the current state of the session and can include the identity of the user for which the session was established, the services used by the user, instances of object types, language and character set data, statistics about resource usage for the session, temporary variable values generated by processes executing software within the session, storage of cursors, variables, and other information.

[0127] A database server includes a plurality of database processes. Database processes run under the control of the database server (i.e., can be created or terminated by the database server) and perform various database server functions. Database processes include processes that run in a database session established for a client.

[0128] A database process is an execution unit. A database process can be a computer system process or thread, or a user-defined execution context such as a user thread or fiber. A database process can also include a "database server system" process that provides services and / or performs functions on behalf of the entire database server. Such database server system processes include listeners, garbage collectors, log writers, and recovery processes.

[0129] A multi-node database management system is composed of interconnected computing nodes ("nodes"), each of which runs a database server that shares access to a common database. Typically, the nodes are interconnected by a network and share access, to varying degrees, to shared memory, such as shared access to a set of disk drives and data blocks stored thereon. The nodes in a multi-node database system can be in the form of a set of computers (e.g., workstations, personal computers) interconnected by a network. Alternatively, the nodes can be nodes of a grid composed of nodes in the form of server blades interconnected with other server blades on a rack.

[0130] Each node in a multi-node database system hosts a database server. A server such as a database server is a combination of integrated software components and allocation of computing resources, such as memory, nodes, and processes on the nodes for executing the integrated software components on processors, the combination of software and allocation of computing resources being dedicated to performing a particular function on behalf of one or more clients.

[0131] Resources from multiple nodes in a multi-node database system can be allocated to run particular database server software. Each combination of software and allocation of resources from a node is a server, referred to herein as a "server instance" or "instance." A database server can include multiple database instances, some or all of which run on separate computers, including separate server blades.

[0132] A database dictionary can include multiple data structures that store database metadata. For example, a database dictionary can include multiple files and tables. Portions of the data structures can be cached in the main memory of a database server.

[0133] When a database object is said to be defined by a database dictionary, the database dictionary contains metadata that defines characteristics of the database object. For example, metadata in a database dictionary that defines a database table can specify attribute names and data types of the attributes, as well as one or more files or portions thereof that store the table data. Metadata in a database dictionary that defines a procedure can specify the name of the procedure, the parameter and return data types of the procedure, and can include source code and compiled versions thereof.

[0134] A database object can be defined by a database dictionary, but the metadata in the database dictionary itself can only partially specify the characteristics of the database object. Other characteristics can be defined by data structures that can not be considered part of the database dictionary. For example, a user-defined function implemented in a Java class can be partially defined by the database dictionary by specifying the name of the user-defined function and by specifying a reference to a file containing the source code of the JAVA class (i.e., a.java file) and a compiled version of the class (i.e., a.class file).

[0135] Native data types are data types that are supported by a DBMS "out-of-the-box." On the other hand, non-native data types can not be supported by a DBMS out-of-the-box. Non-native data types include user-defined abstract types or object classes. Once a non-native data type is defined in the database dictionary of a DBMS, the DBMS only recognizes and processes the non-native data type in database commands, such as by issuing a DDL statement to the DBMS that defines the non-native data type. Native data types are recognized as valid data types without having to be defined by the database dictionary and are processed by the DBMS in database statements. Generally, the database software of a DBMS is programmed to recognize and process native data types without having to configure the DBMS by defining the data types, such as by issuing DDL statements to the DBMS.

[0136] Hardware Overview

[0137] According to one embodiment, the technology described herein is implemented by one or more special-purpose computing devices. The special-purpose computing devices can be hard-wired to perform the technology, or can include digital electronic devices such as one or more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are persistently programmed to perform the technology, or can include one or more general purpose hardware processors programmed to perform the technology pursuant to program instructions in firmware, memory, other storage, or a combination. Such special-purpose computing devices can also combine custom hard-wired logic with custom programming to accomplish the technology. The special-purpose computing devices can be a desktop computer system, a portable computer system, a handheld device, a network device, or any other device combined with hard-wired custom logic and / or program logic that implements the technology.

[0138] For example, Figure 6 FIG. 6 is a block diagram that illustrates a computer system 600 upon which an embodiment of the application can be implemented. Computer system 600 includes a bus 602 or other communication mechanism for communicating information, and a hardware processor 604 coupled with bus 602 for processing information. Hardware processor 604 can be, for example, a general purpose microprocessor.

[0139] The computer system 600 also includes a main memory 606, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 602 for storing information and instructions to be executed by processor 604. Main memory 606 also can be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 604. Such instructions can be stored and executed by computer system 600 in cooperation with such a processor 604, the

[0140] The computer system 600 further includes a read only memory (ROM) 608 or other static storage device coupled to bus 602 for storing static information and instructions for processor 604. A storage device 610, such as a magnetic disk, optical disk, or solid-state drive is provided and coupled to bus 602 for storing information and instructions.

[0141] Computer system 600 can be coupled via bus 602 to a display 612, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 614, including alphanumeric and other keys, is coupled to bus 602 for communicating information and command selections to processor 604. Another type of user input device is cursor control 616, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 604 and for

[0142] Computer system 600 can implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and / or program logic which in combination with the computer system causes or programs computer system 600 to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system 600 in response to processor 604 executing one or more sequences of instructions contained in main memory 606. Such instructions can be read into main memory 606 from another storage medium, such as storage device 610. Execution of the sequences of instructions contained in main memory 606 causes processor 604 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry can be used in place of or in combination with software instructions.

[0143] The term "storage media" as used herein refers to any non-transitory media that store data and / or instructions that cause a machine to operate in a specific fashion. Such storage media can comprise non-volatile media and / or volatile media. Non-volatile media includes, for example, optical disks, magnetic disks, or solid-state drives, such as storage device 610. Volatile media includes dynamic memory, such as main memory 606. Common forms of storage media include, for example, a floppy disk, a flexible disk, a hard disk, a solid- state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge.

[0144] Storage media are distinct from, but can be used in combination with, transmission media. Transmission media participate in transferring information between storage media. For example, transmission media includes coaxial cables, copper wire, and optical fibers, including the wires that comprise bus 602. Transmission media can also take the form of acoustic or light waves, such as those generated during radio frequency and infrared data communications.

[0145] Various forms of media can be involved in carrying one or more sequences of one or more instructions to processor 604 for execution. For example, the instructions can initially be carried on a magnetic disk or solid-state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 600 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 602. Bus 602 carries the data to main memory 606, from which processor 604 retrieves and executes the instructions. The instructions received by main memory 606 can optionally be stored on storage device 610 either before or after execution by processor 604.

[0146] Computer system 600 also includes a communication interface 618 coupled to bus 602. Communication interface 618 provides a two-way data communication coupling to a network link 620 that is connected to a local network 622. For example, communication interface 618 can be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 618 can be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links can also be implemented. In any such implementation, communication interface 618 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

[0147] Network link 620 typically provides data communication through one or more networks to other data devices. For example, network link 620 can provide a connection through local network 622 to a host computer 624 or to data equipment operated by an Internet Service Provider (ISP) 626. ISP 626 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the "Internet" 628. Local network 622 and Internet 628 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 620 and through communication interface 618, which carry the digital data to and from computer system 600, are example forms of transmission media for digital data.

[0148] Computer system 600 can send messages and receive data, including program code, through the network(s), network link 620 and communication interface 618. In the Internet example, server 630 might transmit a requested code for an application program through Internet 628, ISP 626, local network 622 and communication interface 618.

[0149] The received code can be executed by processor 604 as it is received, and / or stored in storage device 610, or other non-volatile storage for later execution.

[0150] Software Overview

[0151] Figure 7 is a block diagram of a basic software system 700 that can be employed for controlling the operation of the computer system 600. The software system 700 and its components, including their connections, relationships and functions, are meant to be exemplary only and not meant to limit implementations of the example embodiments. Other software systems suitable for implementing the example embodiments can have different components, including components with different connections, relationships and functions.

[0152] The software system 700 is provided for directing the operation of the computer system 600. The software system 700, which can be stored in the system memory (RAM) 1106 and on the fixed storage (e.g., hard disk or flash memory) 1110, includes the kernel or operating system (OS) 710.

[0153] OS 710 manages low-level aspects of computer operation, including managing execution of processes, memory allocation, file input and output (I / O), and device I / O. One or more applications, represented as 702A, 702B, 702C... 702N, can be "loaded" (e.g., transferred from fixed storage 1110 to memory 1106) for execution by system 700. An application or other software intended for use on computer system 600 can also be stored as a set of download-able computer-executable instructions, for example, for downloading and installation from a web location (e.g., a Web server, an application store, or other online service).

[0154] Software system 700 includes graphical user interface (GUI) 715, for receiving user commands and data in a graphical (e.g., "point and click" or "touch gesture") fashion. These inputs, in turn, can be acted upon by system 700 in conjunction with results of receiving certain data that is received by system 700, and under control of operating system 710 and application program(s) 702. GUI 715 also serves to display results of operation. User commands can be given to control, for example, the loading of a computer program into memory, the execution of the computer program, the transmission of data to or from system 700, and the like.

[0155] OS 710 can execute directly on the bare hardware 720 (e.g., processor 1104) of computer system 600. Alternatively, a hypervisor or virtual machine monitor (VMM) 730 can be interposed between OS 710 and bare hardware 720. In this configuration, VMM 730 acts as a software "cushion" or virtualization layer between OS 710 and bare hardware 720 of computer system 600.

[0156] VMM 730 instantiates and runs one or more virtual machine instances ("guest machines"). Each guest machine includes a "guest" operating system, like OS 710, and one or more applications, like application 702, designed to execute on the guest operating system. VMM 730 presents a virtual operating platform to the guest operating system, and manages execution of the guest operating system.

[0157] In some instances, VMM 730 can allow a guest operating system to run as if it were running directly on the bare hardware 720 of computer system 600. In these instances, the same version of the guest operating system that is configured to execute directly on bare hardware 720 can also execute on VMM 730 without modification or reconfiguration. In other words, VMM 730 can provide full hardware and CPU virtualization to the guest operating system in some instances.

[0158] In other instances, for efficiency, a guest operating system can be specially designed or configured to execute on the VMM 730. In these instances, the guest operating system "knows" that it is executing on a virtual machine monitor. In other words, the VMM 730 can provide para-virtualization to the guest operating system in some instances.

[0159] A computer system process includes an allocation of hardware processor time and an allocation of memory (physical and / or virtual) for storing instructions for execution by the hardware processor, for storing data generated by the hardware processor executing the instructions, and / or for storing the state of the hardware processor (e.g., contents of registers) between allocations of hardware processor time when the computer system process is not running. Computer system processes run under the control of an operating system and can run under the control of other programs executing on the computer system.

[0160] Cloud computing

[0161] The term "cloud computing" is generally used herein to describe a model of computing in which shared pools of computing resources, such as computer networks, servers, software applications, and services, are provided and made accessible over the Internet on a pay-per-use basis.

[0162] Cloud computing environments (sometimes referred to as cloud environments or clouds) can be implemented in a variety of different ways to best suit different needs. For example, in a public cloud environment, the underlying computing infrastructure is owned by an organization that makes its cloud services available to other organizations or the general public. Conversely, a private cloud environment is typically intended solely for use by a single organization. A community cloud is intended to be shared by multiple organizations within a community; and a hybrid cloud includes two or more types of cloud (e.g., private, community, or public) that are bound together by data and application portability.

[0163] Generally speaking, cloud computing models enable some of the responsibilities that previously might have been provided by an organization's own information technology department to be delivered as a service layer in a cloud environment for use by consumers (either within the organization or externally, or according to the public / private nature of the cloud). Depending on the particular implementation, the precise definition of the components or features within or provided by each cloud service layer can vary, but common examples include: Software as a Service (SaaS), in which consumers use software applications running on cloud infrastructure, while the SaaS provider manages or controls the underlying cloud infrastructure and applications. Platform as a Service (PaaS), in which consumers can use software programming languages and development tools supported by the PaaS provider to develop, deploy, and otherwise control their own applications, while the PaaS provider manages or controls other aspects of the cloud environment (i.e., everything below the runtime execution environment). Infrastructure as a Service (IaaS), in which consumers can deploy and run arbitrary software applications, and / or provision processing, storage, networks, and other foundational computing resources, while the IaaS provider manages or controls the underlying physical cloud infrastructure (i.e., everything below the operating system layer). Database as a Service (DBaaS), in which consumers use database servers or database management systems running on cloud infrastructure, while the DBaaS provider manages or controls the underlying cloud infrastructure, applications, and servers, including one or more database servers.

[0164] In the foregoing specification, embodiments of the application have been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes can be made thereto without departing from the broader spirit and scope of the application. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the application, and what is intended by the applicants to be the scope of the application, is the literal and equivalent scope of the language in which the claim terms are used in the following claims and the specifications, including any subsequent correction and / or amendments to such claims or the specification.

Claims

1. A method comprising: receiving a request to perform a particular distributed transaction, the request requiring a particular world state record in a particular blockchain channel to be changed to a particular value; within a prepare phase of a particular staged transaction of the particular distributed transaction, submitting a first blockchain transaction, wherein submitting the first blockchain transaction comprises submitting: a particular phase record set to the particular value; a particular transaction metadata record indicating that the particular staged transaction has been prepared; within a commit phase of the particular staged transaction, submitting a second blockchain transaction, wherein submitting the second blockchain transaction comprises submitting: the particular world state record to the particular value; and the particular transaction metadata record to a value indicating that the particular staged transaction has been committed.

2. The method of claim 1, wherein: the particular distributed transaction requires a further world state record in a further blockchain channel to be changed to a further value; within a prepare phase of a further staged transaction of the particular distributed transaction, submitting a third blockchain transaction, wherein submitting the third blockchain transaction comprises submitting: a further phase record set to the further value; a further transaction metadata record indicating that the further staged transaction has been prepared; within a commit phase of the further staged transaction, submitting a fourth blockchain transaction, wherein submitting the fourth blockchain transaction comprises submitting: the further world state record to the further value; and the further transaction metadata record to a value indicating that the particular staged transaction has been committed.

3. The method of claim 1, further comprising: a blockchain client of the particular blockchain channel proposing the first blockchain transaction to at least one peer node of the particular blockchain channel; and the blockchain client receiving a prepared notification from the at least one peer node of the particular blockchain channel.

4. The method of claim 1, further comprising: a blockchain client of the particular blockchain channel proposing the second blockchain transaction to at least one peer node of the particular blockchain channel; and the blockchain client receiving a commit notification from the at least one peer node of the particular blockchain channel.

5. The method of claim 1, wherein the particular distributed transaction requires a particular change to particular data in a computer system, the computer system committing the particular change to the particular data using a two-phase protocol, wherein the method further comprises: receiving a prepared notification from the computer system, the notification indicating that the computer system has prepared to commit the particular change to the particular data; after receiving the prepared notification from the computer system, sending a request to commit the particular change.

6. The method of claim 5, wherein the computer system is a database management system.

7. The method of claim 1, further comprising: receiving a request to perform a further distributed transaction, the request requiring a further world state record in the particular blockchain channel to be changed to a further value; ​ ​ ​ In a prepare phase of the other sub-phase transaction of the other distributed transaction, a third blockchain transaction is committed, wherein committing the third blockchain transaction includes committing: another phase record set to the particular value; another transaction metadata record indicating that the other sub-phase transaction is prepared; in a rollback phase of the other sub-phase transaction, a fourth blockchain transaction is committed, wherein committing the second blockchain transaction includes committing the other transaction metadata record to a value indicating that the particular sub-phase transaction is rolled back.

8. The method of claim 1, further comprising locking the particular world state record during the prepare phase.

9. The method of claim 1, further comprising locking the particular world state record during the commit phase.

10. The method of claim 1, wherein a blockchain system includes the particular blockchain channel, wherein the blockchain system is configured to modify a blockchain and a corresponding world state using an endorsement phase, an ordering phase, and a validation phase.

Images