WO2023274409A1 - Procédé d'exécution de transaction dans un système de chaîne de blocs et nœud de chaîne de blocs - Google Patents

Procédé d'exécution de transaction dans un système de chaîne de blocs et nœud de chaîne de blocs Download PDF

Info

Publication number
WO2023274409A1
WO2023274409A1 PCT/CN2022/103384 CN2022103384W WO2023274409A1 WO 2023274409 A1 WO2023274409 A1 WO 2023274409A1 CN 2022103384 W CN2022103384 W CN 2022103384W WO 2023274409 A1 WO2023274409 A1 WO 2023274409A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
existence
variable
execution
contract
Prior art date
Application number
PCT/CN2022/103384
Other languages
English (en)
Chinese (zh)
Inventor
刘晓建
Original Assignee
支付宝(杭州)信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2023274409A1 publication Critical patent/WO2023274409A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the embodiment of this specification relates to the technical field of blockchain, and more specifically, relates to a method and blockchain nodes for executing transactions in a blockchain system.
  • Blockchain is a new application model of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.
  • Blockchain is a chained data structure that combines data blocks in a sequential manner in chronological order, and is a cryptographically guaranteed non-tamperable and unforgeable distributed ledger. Due to the characteristics of decentralization, non-tamperable information, and autonomy, the blockchain has also received more and more attention and application.
  • smart contracts are allowed to be deployed and invoked in the blockchain system.
  • key in order to prevent repeated creation of the same object or variable (hereafter denoted as key), before creating an object, it will first try to check the existence of the object, and only when the object does not exist will the subsequent operate.
  • the embodiment of this specification aims to provide a more efficient method for executing transactions in the blockchain system, so that while executing the interface for confirming the existence of the key, the transaction is executed in parallel according to the preset existence of the key, reducing The time consumption caused by the key existence check improves the system efficiency.
  • the first aspect of this specification provides a method for executing a transaction in a blockchain system, in which a contract is called in the transaction, and an interface function for confirming the existence of variables is called in the contract, and the method consists of Blockchain node execution, including:
  • the second aspect of this specification provides a block chain node, the block chain node is used to execute the transaction, the contract is called in the transaction, the interface function used to confirm the existence of the variable is called in the contract, the block Chain nodes include:
  • a first execution unit configured to execute the interface function
  • the second execution unit is configured to execute the contract according to the preset existence of the variable before the result of the interface function is returned.
  • a third aspect of the present specification provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed in a computer, the computer is instructed to execute any one of the methods described in the first aspect.
  • the fourth aspect of this specification provides a blockchain node, including a memory and a processor, the memory stores executable code, and when the processor executes the executable code, any item method.
  • the execution body that executes the transaction can use the interface provided by the platform to check the existence of the key when executing the transaction for the first time, and send the key existence key to the execution body that executes the platform code.
  • the contract developer can predict the existence of the key with a high accuracy rate, that is, in the case where the actual existence of the key is the same as the preset existence, there is a high probability that there is no need to re-execute the transaction, which can reduce the execution of transactions In the process of waiting for the result of storage access, the transaction execution speed is improved and the system efficiency is improved.
  • the blockchain platform can reduce the number of generation and sending of system requests by providing interfaces that combine key existence checks and other predetermined operations, and improve system efficiency.
  • FIG. 1 shows a block chain architecture diagram applied in the embodiment of this specification
  • Fig. 2 shows the architecture diagram of the blockchain node provided by the embodiment of this specification
  • Fig. 3 shows a flow chart of a method for executing a transaction in a blockchain provided by an embodiment of this specification
  • Fig. 4 shows a flow chart of a method for executing a transaction in a blockchain provided by an embodiment of this specification
  • Fig. 5 shows an architecture diagram of a blockchain node provided by the embodiment of this specification.
  • Fig. 1 shows a block chain system architecture diagram applied in the embodiment of this specification.
  • the block chain system (hereinafter referred to as block chain) for example includes A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P has a total of 16 full nodes.
  • the connection between nodes schematically represents a P2P (Peer to Peer, point-to-point) connection.
  • P2P Peer to Peer, point-to-point
  • each full-scale node in the blockchain generates the same state in the blockchain system by executing the same transaction, that is, each full-scale node in the blockchain performs the same operation and stores the same state database.
  • the following describes the execution of a transaction in a node in the blockchain as an example.
  • block chain shown in FIG. 1 is only exemplary, and the embodiment of this description is not limited to be applied to the block chain shown in FIG. 1 , for example, it can also be applied to a block chain system including sharding.
  • the blockchain includes 16 full nodes
  • the embodiment of this specification is not limited thereto, but may include other numbers of full nodes.
  • the nodes contained in the blockchain can meet Byzantine Fault Tolerance (BFT) requirements.
  • BFT Byzantine Fault Tolerance
  • the Byzantine fault tolerance requirement can be understood as that there may be Byzantine nodes inside the blockchain, but the blockchain does not reflect Byzantine behavior externally.
  • some Byzantine fault-tolerant algorithms require the number of nodes to be greater than 3f+1, where f is the number of Byzantine nodes, such as the practical Byzantine fault-tolerant algorithm PBFT (Practical Byzantine Fault Tolerance).
  • a block chain node includes a processing unit 21 and a storage unit 22 .
  • the blockchain node is a single server
  • the processing unit 21 can be a plurality of CPUs included in the server
  • the storage unit 22 can be a storage medium (such as storage) included in the server
  • the storage unit 22 For example, a block database and a state database are stored in it.
  • the block database is used to store the block data in the blockchain
  • the state database is used to store the state data in the blockchain.
  • the blockchain node is a server cluster
  • the processing unit 21 can be a CPU included in any server in the blockchain node
  • the storage unit 22 can be a CPU included in any server in the blockchain node. storage medium.
  • the blockchain node includes one or more servers and computing hardware (such as FPGA) connected to the server.
  • the processing unit 21 can also include a CPU connected to the server. FPGA.
  • TEE technology such as SGX of Intel, SEV of AMD, TrustZone (trusted area) of ARM, etc.
  • TEE technology such as SGX of Intel, SEV of AMD, TrustZone (trusted area) of ARM, etc.
  • the processing unit 21 when the processing unit 21 executes the contract called in the transaction, it usually executes the contract in a virtual machine, and the virtual machine is used to provide an execution environment for the contract. context, a cache for storing data during execution, etc.
  • Ethereum Compared with the Bitcoin network, Ethereum has expanded, adopting the account system and world state, and can record the balance and state of the account directly through the account in the state database.
  • Accounts in Ethereum can be divided into two types: Externally owned account: user’s account, such as the account of the owner of Ethereum; contract account: stores the executed smart contract code and the status of the smart contract code value, usually only activated by external account calls.
  • the value of the state in the smart contract code is the value of the variable defined in the smart contract, and the value of the variable is stored in the state storage of the contract in the state database, for example, stored in the data structure of the MPT tree.
  • the processing unit 21 may assign an execution body (for example, thread 1 ) to execute the transaction.
  • the execution body may be implemented by one of the multiple CPUs in the server, or by the aforementioned FPGA.
  • thread 1 can execute transactions in the TEE environment.
  • the TEE may be implemented in the form of a virtual machine.
  • thread 1 can send a storage access request to thread 2, and wait for thread 2 to return the access result to the state database, or thread 1
  • the execution of the transaction can be suspended, and the state database can be accessed, and the execution of the transaction can be resumed after the access result is obtained.
  • the thread 1 that executes the transaction can send the key existence check request to the thread 2, so that the thread 2 can read the value of the key And return the read result to determine the existence of the key.
  • thread 2 sends the read request to the state database in the hard disk, and waits for the hard disk to return the read result. Thread 1 needs to obtain the reading result through thread 2 before continuing to execute the transaction, which takes a lot of time and reduces the execution efficiency of the transaction.
  • the embodiment of this specification provides a solution for executing a transaction.
  • the thread 1 that executes the transaction needs to check the existence of the key, based on the interface provided by the blockchain platform to confirm the existence of the key, it sends a message to the thread 2 to check the existence of the key.
  • the request for a security check executes the transaction based on the preset existence of the key.
  • the preset existence is likely to be the same as the actual existence of the key, there is a high probability that there is no need to re-execute the transaction, and thread 1 can execute the transaction while thread 2 is performing storage access, which reduces the transaction execution time and improves the transaction efficiency. execution efficiency.
  • the module executes the key existence check interface and transaction in parallel through two execution bodies, but any method that can realize parallel execution can be adopted, for example, two execution bodies in one execution body can be used
  • the module executes the key existence check interface and the transaction. After one module executes the key existence check interface, it sends an access request to the storage (such as a hard disk), so that another module can execute the transaction in parallel while waiting for the result of the access.
  • the storage such as a hard disk
  • Fig. 3 shows a flow chart of a method for executing a transaction in a blockchain provided by an embodiment of this specification, the flow is executed by threads 1 and 2 in the blockchain node, wherein thread 1 is used to execute transactions, and thread 2 is used to execute the code provided by the blockchain platform, which is used to support the execution of the transaction.
  • a contract is called in the transaction, and an interface function for confirming the existence of variables is called in the contract.
  • thread 1 executes step S301 to execute a transaction and generate a key existence confirmation request.
  • an interface ie, a function for confirming the existence of variables can be provided in the blockchain platform.
  • a new key will be added to the contract called in the transaction, and the interface used to confirm the existence of the variable is called before the addition to check the existence of the key to confirm whether the key does not exist.
  • the contract includes, for example, the following instructions:
  • the KeyexistCheck() function is an interface provided by the blockchain platform to check whether the key exists, and the contract can directly call this interface to check the existence of the key.
  • the KeyexistHandle() function is a function defined in the contract, which is used to perform predetermined operations when the key existence returned by the KeyexistCheck() function exists, such as returning transaction failure to the user. "Else" indicates that the SetKV() function is executed when the key existence returned by the KeyexistCheck() function does not exist.
  • the SetKV() function is used to create a new key (such as key1), where new_value is the initial value of key1. After thread 1 starts to execute the contract, after executing the above-mentioned KeyexistCheck() function contained in the contract, it can generate a request corresponding to this function for confirming the existence of the key and send it to thread 2.
  • the AddNewKey interface can be provided in the blockchain platform, which is used to check the existence and add the key when it is determined that the key does not exist.
  • the above interface can be called in the contract.
  • the contract can be set to perform predetermined operations when the existence of the key returned by the AddNewKey interface exists, such as returning a transaction failure to the user.
  • thread 1 executes the AddNewKey interface, it can generate a corresponding request for executing the AddNewKey interface to send to thread 2.
  • Thread 2 sends an access request for the key to the storage according to the request, and while waiting for the access result, the operation of adding the key can be performed in parallel.
  • the operation of adding a Key may include, according to the incoming parameters of AddNewKey, recording the key identifier and the initial value of the key in memory for subsequent updates to the storage, for example, updating to the storage after all transactions in the block are executed middle.
  • thread 2 can delete the operation result of the operation of adding the key that has been executed, or can terminate the execution of the contract according to the settings in the AddNewKey interface, end the transaction, and return transaction failed.
  • the existing key will be deleted in the contract called in the transaction, and the interface provided by the blockchain platform for determining the existence of the variable is called before the deletion to check the existence of the key. Check to see if the key exists.
  • the contract includes, for example, the following instructions:
  • the KeynotexistCheck() function is an interface provided by the blockchain platform to check whether the key (such as key1 shown in the code) does not exist, and the interface can be directly called in the contract.
  • the KeynotexistHandle() function is a function defined in the contract, which is used to perform predetermined operations when the existence of the key returned by the KeynotexistCheck() function is non-existent, such as returning a transaction failure to the user. "Else" indicates that the DelKV() function is executed when the key existence returned by the KeynotexistCheck() function exists.
  • the DelKV() function is used to delete the key. After the thread 1 in the processing unit 21 starts to execute the contract in the virtual machine, after executing the above-mentioned KeynotexistCheck() function contained in the contract, it can generate a request for confirming the existence of the key and send it to the thread 2.
  • the DelKey interface can be provided in the blockchain platform, which is used to check the existence of the key and delete the key when it is determined that the key exists.
  • the above interface can be called in the contract.
  • thread 1 in the blockchain node executes the DelKey interface, it can generate a corresponding request to execute the DelKey interface to send to thread 2.
  • Thread 2 sends an access request to the storage according to the request, and waits for the result of the access.
  • the operation of deleting the Key can be performed in parallel. Similar to the above, the operation of deleting the key can be performed in memory.
  • thread 1 may only send a system request to thread 2 when calling the interface.
  • thread 1 is implemented in FPGA
  • the communication between thread 1 and thread 2 is the communication between two hardwares (i.e. server and FPGA), and the communication cost is relatively high, so the above-mentioned AddNewkey interface and DelKey interface can be greatly improved. Reduce the resource overhead of generating and sending system requests and improve system efficiency.
  • step S302 thread 1 sends the generated key existence confirmation request to thread 2.
  • step S303 thread 1 continues to execute the transaction according to the preset existence of the key.
  • the code of the above-mentioned KeyexistCheck interface thread 1 can use the existence of key1 corresponding to the Else branch as the preset existence, thereby executing the Else branch in the contract.
  • thread 1 can similarly execute the transaction according to the preset existence (that is, execute the contract called in the transaction).
  • thread 1 when thread 1 executes step S303, it continues to execute the subsequent code in the contract, that is, the key creation operation in the transaction, assuming that key1 does not exist. For example, as shown in the code in the first case above, thread 1 can continue to execute the code SetKV(key1, new_value) in the contract, that is, create key1 in the storage.
  • thread 2 since thread 2 performs the operation of creating key1 when it is determined that key1 does not exist, and the operation of creating key1 performed by thread 2 will not affect the subsequent operations in thread 1's execution of the transaction, therefore, thread 1 You can follow the thread 2 assumption that key1 does not exist and key1 has been created, and continue to execute subsequent operations in the contract called by the exchange.
  • thread 1 continues to execute the subsequent code in the contract assuming that the key exists, that is, the operation of deleting the key in the contract. For example, as shown in the code in the third case above, thread 1 may execute the code "DelKV(key1)" according to the existence of key1, that is, delete "key1" in the state database.
  • thread 1 can continue to perform subsequent operations in the transaction assuming that the key exists and has been deleted.
  • Thread 2 performs storage access in step S304 to confirm the existence of the key.
  • thread 2 can access the state database in the hard disk to read the value of key1 from the state database to confirm whether key1 exists. If the value of key1 is read, it can be confirmed that key1 already exists. key1 value, it can be confirmed that key1 does not exist. After thread 2 determines the existence of key1 according to the storage access result, it may store the existence of key1 in the memory.
  • step S305 thread 1 sends a system service request to thread 2.
  • Thread 1 may generate a new system service request in the process of continuing to execute the transaction and needs to send it to thread 2 to request system service.
  • the system service requests include, for example, other key existence confirmation requests, transaction completion requests, and other requests. It can be understood that since thread 2 can execute step S306 at any time before the end of the transaction, it is also possible to execute step S306 before thread 1 sends the system service request. Therefore, step S305 is shown with a dotted line in FIG. 3 , indicating that this step is Optional step.
  • step S306 thread 2 determines whether to re-execute the transaction.
  • Thread 2 can execute this step at any time before the end of the transaction, for example, after receiving any system service request, to determine whether to re-execute the transaction. At this time, if thread 2 has not obtained the result of the above storage access, assuming that the system service request is the existence confirmation request of other keys, thread 2 can determine not to re-execute the transaction, so that thread 1 and thread 2 can continue with the above key1. Handle the same process; assume that the system service request is a transaction completion request, that is, thread 1 has executed all the processing in the transaction, and requests to end the execution of the transaction. Thread 2 needs to wait for the result of the storage access, and obtain the result of the storage access Then confirm the existence of key1 to determine whether to re-execute the transaction.
  • thread 2 If thread 2 has obtained the result of the storage access and stored the existence of key1 in memory, it can read the existence of key1 from memory and compare the existence of key1 with the above preset existence to determine whether Re-execute the transaction. If the existence of key1 is the same as the preset existence, there is no need to re-execute the transaction. Specifically, if the system server request is an existence confirmation request for other keys, thread 1 and thread 2 can continue to perform the same processing as the above-mentioned processing for key1; assuming that the system service request is a transaction completion request, thread 2 can complete the transaction. processing, and notify thread 1 to end the execution of the transaction.
  • thread 2 executes step S307, and sends a notification to thread 1 to re-execute the transaction.
  • thread 1 After thread 1 receives the notification of re-executing the transaction, it executes step S308, discards the execution result data generated during the previous execution of the transaction, and re-executes the transaction. In the process of re-executing the transaction, thread 1 may generate a key (namely key1) existence confirmation request again, and then perform step S309 to send the key existence confirmation request to thread 2.
  • a key namely key1 existence confirmation request again
  • thread 1 after thread 1 receives the notification of re-executing the transaction, it can add 1 to the parameter T defined in the contract to indicate that the execution of the transaction is the second execution, that is, not the first time Execution, or in another embodiment, after thread 2 sends the notification of re-execution of the transaction, it may add 1 to the parameter N defined in the platform code to indicate that the execution of the transaction is the second execution. Therefore, after thread 1 sends a key existence request to thread 2, it can determine that the execution of the transaction is not the first execution according to the value of parameter T, so it waits for thread 2 to return the response to the request.
  • thread 2 After thread 2 receives the key existence confirmation request, it can determine that the execution of the transaction is not the first execution according to the value of parameter N. Therefore, thread 2 obtains the existence of key1 from the memory, and executes step S310, according to the existence A request response is returned, and it can be understood that the response here indicates that the existence of key1 is different from the preset existence.
  • thread 1 After thread 1 receives the response returned by thread 2, it executes step S311 to end the execution of the transaction. Since the response returned by thread 2 indicates that the existence of key1 is different from the preset existence, the execution of the transaction fails, thread 1 ends the execution of the transaction, and returns the failure of the execution of the transaction to the user.
  • Figure 4 shows a method for executing a transaction in a blockchain system provided by an embodiment of this specification, in which a contract is called, and an interface function for confirming the existence of a variable is called in the contract, and the method is determined by the block Block chain node execution, including:
  • Step S401 execute the interface function
  • Step S403 before the result of the interface function is returned, execute the contract according to the preset existence of the variable.
  • step S401 and step S403 in FIG. 4 For details of step S401 and step S403 in FIG. 4 , reference may be made to the specific description of step S304 and step S303 above, which will not be repeated here.
  • the executing the interface function includes: sending an access request to storage to confirm the existence of the variable.
  • the executing the interface function further includes: performing predetermined processing on the variable according to the preset existence before waiting for the storage to return a result to the access request.
  • the interface function is used to: add the variable in the storage when it is confirmed that the variable does not exist, or delete the variable in the storage when it is confirmed that the variable exists.
  • the method further includes, before the execution of the transaction is completed, obtaining the access result of the access request, and determining the existence of the variable and the preset existence according to the access result In the case of different properties, it is determined to re-execute the transaction.
  • the contract defines a first parameter indicating the number of transaction execution times
  • executing the contract according to the preset existence of the variable includes determining that the transaction is executed according to the first parameter Executing the contract is executed for the first time, executing the contract according to the preset existence of the variable, and the method further includes updating the first parameter after determining to re-execute the transaction.
  • the method further includes, when starting to execute the interface function in the re-execution of the transaction, if the transaction is determined to be executed not for the first time according to the first parameter, when obtaining the execution After the existence of the variable is returned by the interface function, the contract is executed according to the existence of the variable.
  • the code of the interface function defines a second parameter indicating the number of transaction execution times
  • the execution of the interface function includes determining that the execution of the transaction is the first execution according to the second parameter Afterwards, returning a confirmation response to the preset existence
  • the executing the contract according to the preset existence of the variable includes executing the contract according to the preset existence of the variable according to the confirmation response
  • the method also includes, after determining to re-execute the transaction, updating the second parameter.
  • Fig. 5 shows an architecture diagram of a block chain node provided by the embodiment of this specification, the block chain node is used to execute a transaction, the contract is called in the transaction, and the contract is called in the contract to confirm the existence of the variable Interface function, the blockchain node includes:
  • the first execution unit 51 is configured to execute the interface function
  • the second execution unit 52 is configured to execute the contract according to the preset existence of the variable before the result of the interface function is returned.
  • the first execution unit 51 is further configured to: send an access request to the storage to confirm the existence of the variable.
  • the first execution unit 51 is further configured to: perform predetermined processing on the variable according to the preset existence before waiting for the storage to return a result to the access request.
  • the interface function is used to: add the variable in the storage when it is confirmed that the variable does not exist, or delete the variable in the storage when it is confirmed that the variable exists.
  • the block chain node further includes a determination unit 53, configured to obtain the access result of the access request before the execution of the transaction is completed, and determine the value of the variable according to the access result If the existence is different from the preset existence, it is determined to re-execute the transaction.
  • a determination unit 53 configured to obtain the access result of the access request before the execution of the transaction is completed, and determine the value of the variable according to the access result If the existence is different from the preset existence, it is determined to re-execute the transaction.
  • the contract defines a first parameter indicating the number of transaction execution times
  • the second execution unit 52 is further configured to determine that the execution of the transaction is the first execution according to the first parameter , execute the contract according to the preset existence of the variable
  • the block chain node further includes an updating unit 54, configured to update the first parameter after it is determined to re-execute the transaction.
  • the block chain node further includes a re-execution unit, configured to start executing the interface function in the re-execution of the transaction, when it is determined according to the first parameter that the transaction is not In the case of the first execution, after obtaining the existence of the variable returned by executing the interface function, execute the contract according to the existence of the variable.
  • a re-execution unit configured to start executing the interface function in the re-execution of the transaction, when it is determined according to the first parameter that the transaction is not In the case of the first execution, after obtaining the existence of the variable returned by executing the interface function, execute the contract according to the existence of the variable.
  • the code of the interface function defines a second parameter indicating the number of transaction execution times
  • the first execution unit 51 is further configured to determine that the execution of the transaction is the first according to the second parameter.
  • the second execution unit 52 is also used to execute the contract according to the preset existence of the variable according to the confirmation response
  • the update unit 54 is further configured to update the second parameter after it is determined to re-execute the transaction.
  • the embodiment of this specification also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed in a computer, the computer is instructed to execute the methods shown in FIG. 3 and FIG. 4 .
  • the embodiment of this specification also provides a block chain node, including a memory and a processor, wherein executable code is stored in the memory, and when the processor executes the executable code, the methods shown in Figure 3 and Figure 4 are implemented .
  • the software module can be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or technical field Any other form of storage medium known in the art.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computing Systems (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Des modes de réalisation de la présente invention concernent un procédé d'exécution d'une transaction dans un système de chaîne de blocs et un nœud de chaîne de blocs. Un contrat est appelé dans une transaction, et une fonction d'interface utilisée pour confirmer l'existence d'une variable est appelée dans un contrat. Le procédé est exécuté par un nœud de chaîne de blocs et comprend : l'exécution d'une fonction d'interface ; et avant de renvoyer un résultat de la fonction d'interface, l'exécution d'un contrat selon une existence prédéfinie d'une variable.
PCT/CN2022/103384 2021-07-02 2022-07-01 Procédé d'exécution de transaction dans un système de chaîne de blocs et nœud de chaîne de blocs WO2023274409A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110748977.1 2021-07-02
CN202110748977.1A CN113254467B (zh) 2021-07-02 2021-07-02 在区块链系统中执行交易的方法和区块链节点

Publications (1)

Publication Number Publication Date
WO2023274409A1 true WO2023274409A1 (fr) 2023-01-05

Family

ID=77190491

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/103384 WO2023274409A1 (fr) 2021-07-02 2022-07-01 Procédé d'exécution de transaction dans un système de chaîne de blocs et nœud de chaîne de blocs

Country Status (2)

Country Link
CN (1) CN113254467B (fr)
WO (1) WO2023274409A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113254467B (zh) * 2021-07-02 2022-05-10 支付宝(杭州)信息技术有限公司 在区块链系统中执行交易的方法和区块链节点

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109299335A (zh) * 2018-08-31 2019-02-01 阿里巴巴集团控股有限公司 数据存储的控制方法、装置、服务器及可读存储介质
US20200052884A1 (en) * 2018-08-13 2020-02-13 International Business Machines Corporation Parallel transaction validation and block generation in a blockchain
CN111047449A (zh) * 2020-03-12 2020-04-21 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法及装置
CN111324425A (zh) * 2020-02-28 2020-06-23 百度在线网络技术（北京）有限公司 一种数据访问方法、装置、设备及存储介质
CN113254467A (zh) * 2021-07-02 2021-08-13 支付宝(杭州)信息技术有限公司 在区块链系统中执行交易的方法和区块链节点

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111324396B (zh) * 2020-03-19 2023-09-15 深圳市迅雷网络技术有限公司 一种区块链智能合约执行方法、装置及设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200052884A1 (en) * 2018-08-13 2020-02-13 International Business Machines Corporation Parallel transaction validation and block generation in a blockchain
CN109299335A (zh) * 2018-08-31 2019-02-01 阿里巴巴集团控股有限公司 数据存储的控制方法、装置、服务器及可读存储介质
CN111324425A (zh) * 2020-02-28 2020-06-23 百度在线网络技术（北京）有限公司 一种数据访问方法、装置、设备及存储介质
CN111047449A (zh) * 2020-03-12 2020-04-21 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法及装置
CN113254467A (zh) * 2021-07-02 2021-08-13 支付宝(杭州)信息技术有限公司 在区块链系统中执行交易的方法和区块链节点

Also Published As

Publication number Publication date
CN113254467B (zh) 2022-05-10
CN113254467A (zh) 2021-08-13

Similar Documents

Publication Publication Date Title
CN111338766B (zh) 事务处理方法、装置、计算机设备及存储介质
JP5006348B2 (ja) 応答出力キャッシュに対するマルチキャッシュ協調
JP6353924B2 (ja) ブロックベースストレージに対するデータボリュームの耐久性状態の低減
US8898680B2 (en) System and method for supporting asynchronous message processing in a distributed data grid
US8185499B2 (en) System and method for transactional session management
JP5296615B2 (ja) 分散トランザクション回復システムおよび方法
US6857082B1 (en) Method for providing a transition from one server to another server clustered together
US9378218B2 (en) Apparatus and method for enabling clients to participate in data storage in distributed file system
US10129361B2 (en) System and method for multi-version remote function execution control in a distributed computing environment
CN104793988A (zh) 跨数据库分布式事务的实现方法和装置
CN105493474B (zh) 用于支持用于同步分布式数据网格中的数据的分区级别日志的系统及方法
JP6920513B2 (ja) 分散データグリッドにおける分散データ構造をサポートするためのシステムおよび方法
US20230052935A1 (en) Asynchronous accounting method and apparatus for blockchain, medium and electronic device
CN112162846B (zh) 事务处理方法、设备及计算机可读存储介质
US10133489B2 (en) System and method for supporting a low contention queue in a distributed data grid
WO2023231339A1 (fr) Procédé et nœud d'exécution de transaction dans système de chaîne de blocs, et système de chaîne de blocs
WO2023274409A1 (fr) Procédé d'exécution de transaction dans un système de chaîne de blocs et nœud de chaîne de blocs
US20200202355A1 (en) Storage and execution of smart contracts in blockchains
CN111240806A (zh) 一种分布式容器镜像构建调度系统及方法
US11522966B2 (en) Methods, devices and systems for non-disruptive upgrades to a replicated state machine in a distributed computing environment
US10127270B1 (en) Transaction processing using a key-value store
US10798146B2 (en) System and method for universal timeout in a distributed computing environment
CN106371919A (zh) 一种基于映射‑归约计算模型的洗牌数据缓存方法
WO2023103340A1 (fr) Procédé et appareil de validation de données de bloc
KR20180095004A (ko) 고 쓰루풋, 고 신뢰성의 데이터 처리 시스템

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22832221

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE