A method, apparatus, electronic device, and storage medium for on-chain transactions

Abstract

This application provides a method, apparatus, electronic device, and storage medium for on-chain transactions. It is applied in the field of blockchain technology. The method includes: receiving transaction information input from an upper-layer application through a transaction upload interface; processing the transaction information input from the upper-layer application to generate transactions to be uploaded to the blockchain; temporarily storing the transactions to be uploaded to the blockchain in a local transaction pool; polling the local transaction pool according to a first preset time period to obtain multiple transactions to be uploaded to the blockchain from the local transaction pool; simultaneously uploading the multiple transactions to be uploaded to the blockchain through a batch upload interface; and simultaneously querying the transaction results of the multiple transactions already uploaded to the blockchain through a batch query interface. This application's embodiments achieve universal deployment of contracts and can upload multiple transactions to be uploaded to the blockchain in batches through the batch upload interface, and simultaneously query the results of multiple transactions already uploaded to the blockchain in batches through the batch query interface, improving the efficiency of transaction upload and transaction result query.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a method, apparatus, electronic device and storage medium for recording transactions on the blockchain. Background Technology

[0002] A smart contract is a collection of code and data. Smart contract deployment refers to the process of deploying a smart contract to run on the Ethereum blockchain. For a smart contract to run on the Ethereum blockchain, its code needs to be converted into bytecode recognizable by the Ethereum Virtual Machine. Once successfully deployed, a corresponding contract address is generated. Transactions based on the deployed smart contract can be completed by obtaining the contract address, inputting the required parameters, and then calling the contract's methods.

[0003] Currently, when deploying contracts in a Java project, the first step is to use a tool to compile the Solidity smart contract programming language's SOL file into Java code, and then import the Java code into the Java project. Next, when performing contract transactions, the corresponding Java methods need to be called. Specifically, the transaction interface is first called to send the transaction. After sending the transaction, the transaction hash value is obtained, and then the transaction result query interface is called in a polling manner to retrieve the transaction result using the hash value.

[0004] In the process of deploying contracts in the aforementioned Java project, the SQL file needs to be compiled into Java code first, and then the converted Java code needs to be imported into the Java project. Transactions also require calling the corresponding Java methods. Thus, deploying each smart contract requires first compiling the smart contract's SQL file into Java code, and then importing the Java code into the Java project. This approach fails to achieve universal contract deployment, resulting in exceptionally low efficiency in contract deployment and transaction on-chain processing. Furthermore, in existing blockchain systems, transactions are sent to the blockchain one at a time by calling corresponding interfaces, and transaction result queries are also performed on a single transaction basis, leading to low efficiency in transaction on-chain processing and result retrieval. Therefore, improving the efficiency of smart contract deployment, transaction on-chain processing, and transaction result retrieval has become a pressing issue that needs to be addressed. Summary of the Invention

[0005] In view of this, the first aspect of this application provides a method for batch transaction upload to the blockchain, which is applied to a blockchain-based transaction platform. The blockchain-based transaction platform connects to an upper-layer application with a wallet system through a transaction upload interface, and connects to the blockchain through a batch upload interface / batch query interface. The batch transaction upload method includes:

[0006] The transaction upload interface receives transaction information input from the upper-layer application.

[0007] The transaction information input from the upper-layer application is processed to generate transactions to be uploaded to the blockchain.

[0008] Transactions awaiting on-chain processing are temporarily stored in the local transaction pool.

[0009] The local transaction pool is polled according to the first preset time period to obtain multiple transactions that are to be uploaded to the blockchain.

[0010] Multiple transactions awaiting on-chain can be uploaded to the blockchain simultaneously via the batch on-chain interface.

[0011] The batch query interface allows you to query the transaction results of multiple transactions that have been uploaded to the blockchain simultaneously, with multiple transactions awaiting upload to the blockchain corresponding to multiple transactions already uploaded to the blockchain.

[0012] A second aspect of this application provides a processing apparatus for on-chain transactions, comprising an on-chain transaction platform. The on-chain transaction platform is connected to an upper-layer application with a wallet system via a transaction upload interface, and is also connected to the blockchain via a batch upload interface / batch query interface. The processing apparatus includes:

[0013] The receiving unit is used to receive transaction information input from the upper-layer application through the transaction upload interface.

[0014] The processing unit is used to process the transaction information input by the upper-layer application and generate transactions to be uploaded to the blockchain.

[0015] The storage unit is used to temporarily store transactions to be uploaded to the blockchain in the local transaction pool.

[0016] The acquisition unit is used to poll the local transaction pool according to a first preset time period and acquire multiple transactions to be uploaded to the blockchain from the local transaction pool.

[0017] The processing unit is also used to simultaneously upload multiple transactions to be added to the blockchain via a batch upload interface.

[0018] The query unit is used to query the transaction results of multiple transactions that have been uploaded to the blockchain simultaneously through the batch query interface. Multiple transactions to be uploaded to the blockchain correspond to multiple transactions that have been uploaded to the blockchain.

[0019] A third aspect of this application provides an electronic device, including: a memory and a processor, wherein the memory and the processor are coupled.

[0020] Memory is used to store one or more computer instructions.

[0021] The processor is used to execute one or more computer instructions to implement the on-chain transaction method described in the first aspect above.

[0022] A fourth aspect of this application also provides a computer-readable storage medium storing one or more computer instructions, characterized in that the instructions are executed by a processor to implement a transaction on-chain method as described in any of the above technical solutions.

[0023] Compared with the prior art, the embodiments of this application have the following advantages:

[0024] In this embodiment, the on-chain transaction platform provides a transaction upload interface, a batch upload interface, and a batch query interface. The transaction upload interface is connected to the upper-layer application and is used to receive transaction information. This transaction information can be contract deployment information or ordinary transaction information. During the contract deployment phase, the contract deployment interface within the transaction upload interface can directly receive the contract binary file and application binary import file (ABI) corresponding to the compiled original contract code input by the upper-layer application, and then implement contract deployment based on these two. This eliminates the need to convert the original contract code into Java code and then call the corresponding Java method to deploy the contract. Therefore, the process of compiling the original contract code into Java code is eliminated, allowing any contract to directly call the transaction upload interface for contract deployment, achieving universal contract deployment. During the ordinary transaction upload phase, the on-chain transaction platform can generate transactions to be uploaded to the blockchain based on the transaction information input by the upper-layer application, temporarily store these transactions in a local transaction pool, poll the local transaction pool according to a preset time, and finally upload multiple transactions to the blockchain simultaneously through the batch upload interface. Simultaneously, the transaction results of multiple transactions to be uploaded to the blockchain can be queried through the batch query interface. In this way, multiple transactions awaiting on-chain can be simultaneously uploaded to the blockchain and their results queried through the batch upload and batch query interfaces. This not only achieves the generalization of contract transactions and contract queries, but also improves the efficiency of transaction upload and transaction result query. Attached Figure Description

[0025] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a schematic diagram of the on-chain transaction platform provided in the embodiments of this application;

[0027] Figure 2 This is a flowchart illustrating the transaction on-chain method provided in the embodiments of this application;

[0028] Figure 3This is a flowchart illustrating another method for on-chain transactions provided in this application embodiment;

[0029] Figure 4 This is a schematic diagram of the structure of the transaction on-chain processing device provided in the embodiments of this application;

[0030] Figure 5 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0031] This application provides a method, apparatus, electronic device, and storage medium for on-chain transactions. The on-chain transaction platform provides a transaction upload interface, a batch upload interface, and a batch query interface. By calling the contract deployment interface in the transaction upload interface, generalized deployment of smart contracts can be achieved. The batch upload interface allows multiple transactions to be uploaded to the blockchain simultaneously, and the batch query interface allows simultaneous querying of transaction results for multiple transactions, thereby improving the efficiency of on-chain transactions and the efficiency of transaction result querying.

[0032] To enable those skilled in the art to better understand the technical solutions of this application, the application will be clearly and completely described below with reference to the accompanying drawings of the embodiments. However, this application can be implemented in many other ways different from those described above. Therefore, based on the embodiments provided in this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0033] It should be noted that the terms "first," "second," "third," etc., in the claims, specification, and drawings of this application are used to distinguish similar roles and are not intended to describe a specific order or sequence. Such data are interchangeable where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown or described herein. Furthermore, the terms "comprising," "having," and their variations are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0034] Blockchain technology is a new distributed infrastructure and computing paradigm that uses a block-chain data structure to verify and store data, uses distributed node consensus algorithms to generate and update data, uses cryptography to ensure the security of data transmission and access, and uses smart contracts composed of automated script code to program and manipulate data.

[0035] Smart contracts can automatically execute predefined rules and terms; they are computer protocols designed to disseminate, verify, or execute contracts in an informational manner. A smart contract is a collection of code and data that allows for trusted transactions without a third party; these transactions are traceable and irreversible. In Ethereum, smart contracts are implemented using the Solidity language. Contract deployment and trading refer to running smart contracts and transactions on the Ethereum blockchain. Running smart contracts on the Ethereum blockchain requires converting the smart contract code into bytecode recognizable by the Ethereum Virtual Machine. Once a smart contract is successfully deployed to the blockchain, a corresponding contract address is generated. Transactions based on a deployed smart contract can be completed by obtaining the contract address, inputting the required parameters, and then calling the contract's methods.

[0036] Currently, when deploying contracts in a Java project, the first step is to use a tool to compile the Solidity smart contract programming language (SOL) file into Java code, and then import the converted Java code into the Java project. This allows the Java methods of the contract to be called during transactions. For example, the Java methods for contract deployment and transaction can be called to deploy and execute the contract. Specifically, the underlying process involves assembling transaction parameters using ABI methods, then sending the transaction by calling the WEB3J transaction interface "eth_sendTransaction". After sending the transaction, the transaction hash value is obtained, and then the transaction result query interface "eth_getEthTransactionByHash" is called every 500ms to retrieve the transaction result using the hash value.

[0037] In the process of contract deployment and transactions within the aforementioned Java project, deploying smart contract code requires first compiling the Solidity source code (SOL file) into Java code, then importing the converted Java code into the Java project, and finally calling the corresponding Java methods during contract and transaction deployment. This process necessitates compiling each contract's source code (SOL file) into Java code, importing the corresponding Java code into the Java project, and finally calling the corresponding Java methods based on the different contract's Java code. Since each contract must be compiled into Java code, this results in low contract deployment efficiency and fails to meet the requirements for general contract deployment. Furthermore, in existing blockchain systems, transactions are sent individually by calling the "eth_sendTransaction" interface and the result is retrieved individually by calling the "eth_getEthTransactionByHash" interface. Transactions are recorded on the blockchain individually, and transaction results are also retrieved individually, leading to low efficiency in both transaction recording and result retrieval.

[0038] To address the aforementioned issues, this application provides a method, apparatus, electronic device, and storage medium for on-chain transactions. The on-chain transaction platform of this application provides transaction upload interfaces, batch upload interfaces, batch query interfaces, and data query interfaces. It enables the generalized deployment of contracts. Furthermore, while achieving generalized contract transaction and query capabilities, it improves the efficiency of on-chain transactions and transaction result queries. The on-chain transaction platform, method, apparatus, terminal, and computer-readable storage medium described in this application will be further described in detail below with reference to specific embodiments and accompanying drawings.

[0039] Figure 1 This is a schematic diagram of the structure of an on-chain transaction platform provided in an embodiment of this application. Figure 1 As shown, the on-chain transaction platform includes a transaction upload interface 101, a transaction query interface 102, a transaction packaging module 103, a transaction asynchronous processing module 104, a batch upload interface 105, a batch query interface 106, a local transaction pool 107, and a database module 108.

[0040] The transaction upload interface 101 is connected to an upper-layer application with a wallet system, and is used to receive transaction information input by the upper-layer application. Specifically, the transaction upload interface 101 includes a contract deployment interface and a transaction input interface.

[0041] When the transaction information is contract deployment transaction information, the contract deployment interface receives the contract deployment transaction information input by the upper-layer application. This contract deployment transaction information includes the original contract code file and the first application request number. When the transaction information is contract transaction information, the transaction input interface receives the contract transaction information input by the upper-layer application. This contract transaction information includes the second application transaction request number, ABI file call information, and ABI file input parameters.

[0042] The transaction query interface 102 is connected to the upper-layer application. It receives transaction result query requests from the upper-layer application. Specifically, the transaction query interface 102 may receive a first transaction result query request from the upper-layer application, which includes a first transaction order number or a first application transaction request number, corresponding to the contract deployment. When the on-chain trading platform receives the first transaction result query request, it needs to respond and then query the first receipt event information corresponding to the first transaction order number or the first application transaction request number. Specifically, if the smart contract corresponding to the first transaction order number or the first application transaction request number is successfully deployed, it sends the contract address information and the corresponding ABI file to the upper-layer application. If the smart contract corresponding to the first transaction order number or the first application transaction request number fails to deploy, it sends on-chain failure information to the upper-layer application.

[0043] Transaction query interface 102 may receive a second transaction result query request sent by the upper-layer application. This second transaction result query request includes a second transaction business order number or a second application transaction request number, which is related to ordinary transactions. Similarly, when the on-chain transaction platform receives the second transaction result query request, it needs to respond to the request and then query the second receipt event information corresponding to the second transaction business order number or the second application transaction request number. Specifically, if the transaction corresponding to the second transaction business order number or the second application transaction request number is successfully uploaded to the chain, it will send back to the upper-layer application the ABI file corresponding to the smart contract called by the transaction, the transaction result of the transaction, etc. If the transaction corresponding to the second transaction business order number or the second application transaction request number fails to be uploaded to the chain, it will send back to the upper-layer application a chain failure message.

[0044] The transaction packaging module 103 is used to package transactions based on transaction information to obtain transactions to be uploaded to the blockchain. These transactions can be either contract deployment transactions or contract transactions. For example, in the case of contract deployment, the transaction packaging module 103 can compile the original contract code file to obtain a contract binary file and an application binary interface (ABI) file corresponding to the original contract code file. The ABI file includes the constructor file, transaction methods, query methods, and events of the original contract code file. Then, the transaction packaging module 103 packages the contract binary file and the constructor file to generate a contract deployment transaction to be signed. Next, it calls the wallet signing service of the upper-layer application to sign the contract deployment transaction, combining the transaction to be signed with the signature to obtain the contract deployment transaction to be uploaded to the blockchain. Simultaneously, it calculates the first transaction hash value corresponding to the contract deployment transaction to be uploaded to the blockchain.

[0045] For contract transactions, the transaction packaging module 103 determines the ABI file to be called in the database module 108 based on the ABI file call information in the transaction information. Then, it packages the contract address information corresponding to the ABI file, the corresponding number of the ABI file, and the ABI file input parameters to generate a contract transaction to be signed. The transaction packaging module 103 then calls the wallet signing service of the upper-layer application to sign the contract transaction, combining the transaction to be signed and the signature to obtain the contract transaction to be uploaded to the blockchain. Simultaneously, it calculates the second transaction hash value corresponding to the contract transaction to be uploaded to the blockchain.

[0046] Simultaneously, whether in the contract deployment process or the contract transaction on-chain process, the transaction packaging module 103 needs to store the corresponding relationship of the transactions to be on-chain in the database module 108 upon receiving the transactions to be on-chain. For example, during the contract deployment process, the transaction packaging module needs to store the ABI file and contract binary file corresponding to the contract deployment transaction in the database module 108, and after storage, generate the first transaction business order number corresponding to the contract deployment transaction. Then, it establishes the first correspondence between the first application transaction request number, ABI file, contract binary file, first transaction hash value, and first transaction business order number, and stores the first correspondence in the database module 108. Next, the on-chain transaction platform needs to send the first transaction business order number to the upper-layer application through the contract deployment interface to report the successful receipt of the contract deployment transaction to the upper-layer application.

[0047] For example, during the on-chain process of a contract transaction, after the transaction packaging module 103 stores the correspondence between the second application transaction request number and the second transaction hash value in the database module 108, it generates the second transaction business order number corresponding to the contract transaction. Then, the transaction packaging module 103 establishes a second correspondence between the second application transaction request number, the second transaction hash value, and the second transaction business order number, and stores this second correspondence in the database module. Finally, the on-chain transaction platform sends the second transaction business order number to the upper-layer application through the transaction input interface. The second transaction business order number is used to report the successful receipt of the contract transaction to the upper-layer application.

[0048] After receiving the transactions to be uploaded to the blockchain, the transaction packaging module 103 places them into the local transaction pool 107. At this time, the asynchronous transaction processing module 104 polls the local transaction pool 107 according to a first preset time, obtains multiple transactions to be uploaded to the blockchain from the local transaction pool 107, and uploads multiple transactions to the blockchain simultaneously through the batch upload interface 105 to achieve the purpose of batch uploading of transactions to the blockchain.

[0049] Simultaneously, after multiple transactions awaiting on-chain are uploaded to the blockchain via batch on-chain interface 105, the asynchronous transaction processing module 104 needs to periodically query the blockchain in batches, retrieving the transaction results of the multiple on-chain transactions periodically through batch query interface 106. Understandably, these multiple on-chain transactions correspond to the previous multiple transactions awaiting on-chain. After obtaining the transaction results of the multiple on-chain transactions in batches, it is necessary to parse these results and store them in the database module 108 based on the transaction hash value of each on-chain transaction.

[0050] Next, when the upper-layer application needs to obtain the transaction result of a certain transaction, it needs to send a transaction result query request to the transaction on-chain platform through the transaction query interface 102. At this time, the asynchronous transaction processing module 104 can respond to the transaction result query request, determine the first transaction hash value corresponding to the first transaction business order number or the first application transaction request number according to the first correspondence in the database, and then query the transaction result corresponding to the first transaction hash value in the database module 108. The transaction result includes the first receipt event information, contract address information, on-chain failure information, or ABI file number, etc. Then, the asynchronous transaction processing module 104 sends the first receipt event information, contract address information or on-chain failure information, and ABI file number corresponding to the first transaction hash value to the upper-layer application through the transaction query interface 102. Alternatively, the asynchronous transaction processing module 104 can also be used to determine the second transaction hash value corresponding to the second transaction business order number or the second application transaction request number according to the second correspondence, and determine the transaction result corresponding to the second transaction hash value in the database module 108, such as the second receipt event information and on-chain result information, etc. Finally, the transaction query interface 102 sends the second receipt event result and on-chain result information corresponding to the second transaction hash value to the upper layer application.

[0051] Finally, the asynchronous transaction processing module 104 also needs to monitor the transaction result query status of each on-chain transaction. If it is determined that the transaction result of a target transaction to be on-chain that has been sent has not been found within the second preset time period, then the transaction packaging module 103 needs to recalculate the transaction hash value for the target transaction to be on-chain and put the target transaction to be on-chain back into the local transaction pool for on-chain again.

[0052] Among them, the batch upload port 105 is connected to the blockchain and is used to upload multiple transactions to be uploaded to the blockchain at the same time.

[0053] Among them, the batch query interface 106 is connected to the blockchain and is used to query the transaction results of multiple transactions that are about to be uploaded to the blockchain at the same time.

[0054] Among them, the local transaction pool 107 is used to store contract deployment transactions and contract transactions that are to be uploaded to the chain.

[0055] The database module 108 stores the first correspondence between the first application transaction request number, ABI file, contract binary file, first transaction hash value, and first transaction business order number. It also stores the second correspondence between the second application transaction request number, second transaction hash value, and second transaction business order number. Furthermore, after the asynchronous transaction processing module 104 has parsed the transaction results of multiple transactions awaiting on-chain processing, the database module 108 stores, according to the transaction hash value, the first receipt event information and contract address information or on-chain failure information corresponding to the contract deployment transaction, and stores the second receipt event result and on-chain result information of the contract transaction.

[0056] Based on the aforementioned transaction on-chain platforms, the process of transaction on-chain will be described in detail below. Figure 2 This is a flowchart illustrating a method for putting transactions on the blockchain, as provided in an embodiment of this application. It should be noted that the steps shown in this flowchart can be executed in a computer system, such as a set of computer-executable instructions. Furthermore, in some cases, the released steps can be executed in a logical order different from that shown in the flowchart.

[0057] like Figure 2 As shown, the method for recording transactions on the blockchain includes the following steps:

[0058] 201. Receive transaction information input from the upper-layer application through the transaction upload interface.

[0059] The on-chain trading platform receives transaction information from upper-layer applications through a transaction upload interface. This transaction information can be either contract deployment transaction information or regular contract transaction information. The transaction upload interface includes both a contract deployment interface and a transaction input interface. If the transaction information is contract deployment information, the dedicated contract deployment interface is called to send it to the on-chain trading platform. If the transaction information is contract transaction information, the transaction upload interface is called to send it to the on-chain trading platform.

[0060] Among them, contract deployment transaction information corresponds to contract deployment transactions. A contract deployment transaction refers to sending smart contract code to the blockchain to run and determine the rules of the transaction; its deployment process is also a special type of transaction process. Contract transaction information corresponds to contract transactions, which refer to account transactions implemented by calling a deployed contract. Contract deployment transaction information includes the original contract code file and the first application request number, while contract transaction information includes the second application transaction request number, the ABI file call information of the existing contract to be called, and the ABI file input parameters.

[0061] The first application request number and the second application request number are unique identifiers for contract deployment transaction information and contract transaction information. Each contract deployment transaction and each contract transaction corresponds to a unique application request number. The ABI call information indicates the constructor of the pre-deployed ABI file that the contract transaction needs to call. The ABI file input parameters refer to the transaction parameters that need to be entered when calling the target ABI constructor.

[0062] 202. Process the transaction information input by the upper-layer application to generate transactions to be uploaded to the blockchain.

[0063] After receiving transaction information from the upper-layer application, the transaction information needs to be packaged to generate a transaction ready to be uploaded to the blockchain. The packaging process will be described in detail in the following examples, and will not be repeated here.

[0064] 203. Temporarily store the transactions to be uploaded to the blockchain in the local transaction pool.

[0065] After generating a transaction to be uploaded to the blockchain, the on-chain transaction platform does not immediately send the transaction to the blockchain. Instead, it first stores the transaction in a local transaction pool. In this way, the local transaction pool will continuously receive multiple contract deployment transactions or contract transactions that need to be sent to the blockchain. That is, the local transaction pool is used to temporarily store transactions to be uploaded to the blockchain.

[0066] 204. Poll the local transaction pool according to the first preset time period to obtain multiple transactions to be uploaded to the blockchain from the local transaction pool.

[0067] The on-chain trading platform will poll the local transaction pool according to a preset time period to determine the multiple transactions to be uploaded to the blockchain that have been received and stored in the local transaction pool within a first preset time period. The first preset time period can be predetermined based on the number and speed at which the transactions to be uploaded to the blockchain are generated. For example, the first preset time period can be determined as 500ms, meaning the on-chain trading platform needs to poll the local transaction pool every 500ms to obtain the multiple transactions to be uploaded to the blockchain stored in the local transaction pool within that 500ms period.

[0068] 205. Upload multiple transactions to be uploaded to the blockchain simultaneously via the batch upload interface.

[0069] When sending transactions to the blockchain, the on-chain transaction platform does not send them one by one. Instead, it uploads multiple transactions at once through a batch upload interface. Specifically, the platform polls its local transaction pool according to a preset time period, retrieves multiple transactions temporarily stored in the local transaction pool within the first preset time period, and then uploads these multiple transactions to the blockchain simultaneously through the batch upload interface. After successful upload, the local transaction pool is cleared.

[0070] 206. Simultaneously query and store the transaction results corresponding to multiple on-chain transactions through the batch query interface.

[0071] After the blockchain transaction platform completes the upload process for multiple transactions awaiting blockchain upload, it needs to promptly query the transaction results of these transactions to determine whether the upload was successful. In this embodiment, the platform does not query the results for each transaction individually, but rather queries the results of multiple uploaded transactions in batches through a batch query interface. Specifically, the platform uploads multiple transactions awaiting blockchain upload to the blockchain in batches within a first preset time period, completes the upload process, and then promptly queries the transaction results of this batch of uploaded transactions through the batch query interface. It's understood that transactions awaiting blockchain upload correspond to transactions already uploaded. If a transaction result for an uploaded transaction is found, it is stored in the database. If no result is found for an uploaded transaction, it indicates that the blockchain upload failed. In this case, the transaction result is stored in the database as a failure, or the transaction is repackaged and re-attempted for blockchain upload.

[0072] Each transaction is assigned a transaction hash value during the packaging process, which is used to locate the corresponding blockchain block. Therefore, when querying the transaction results of multiple on-chain transactions, it is necessary to query the corresponding blockchain block based on the transaction hash value of each on-chain transaction. Furthermore, after storing the queried transaction results, the correspondence between transactions, transaction hash values, and transaction results needs to be stored in the database.

[0073] 207. Receive transaction result query requests sent by upper-layer applications through the transaction query interface.

[0074] After the blockchain transaction platform uploads multiple transactions in batches, it stores the transaction results of the successfully uploaded transactions. Then, when an upper-layer application needs to query the transaction result of a specific transaction, it needs to send a transaction result query request through the transaction query interface. This query request includes the transaction information of that transaction, such as the application transaction request number or transaction order number. This transaction information uniquely identifies a specific transaction; that is, the transaction hash value of a particular transaction can be uniquely determined through the transaction information in the transaction result query request.

[0075] 208. Respond to the transaction result query request and determine the target transaction hash value corresponding to the transaction query request.

[0076] Upon receiving a transaction result query request, the on-chain transaction platform responds by determining the target transaction hash value corresponding to the query request. It then queries the database for the transaction result corresponding to the target transaction hash value.

[0077] 209. Determine the transaction result corresponding to the target transaction hash value from the multiple transaction results corresponding to the stored transactions to be uploaded to the blockchain.

[0078] 210. Send the transaction result corresponding to the target transaction hash value to the upper layer application through the transaction query interface.

[0079] Finally, the transaction platform sends the retrieved transaction results to the upper-layer application via the transaction query interface, completing the query process. Understandably, the upper-layer application can call the transaction query interface to query the transaction results of any single transaction, achieving the purpose of querying a single transaction.

[0080] In this embodiment, the on-chain transaction platform provides a transaction upload interface, a batch upload interface, and a batch query interface. The transaction upload interface is connected to the upper-layer application and is used to receive transaction information. This transaction information can be contract deployment information or ordinary transaction information. During the contract deployment phase, the contract deployment interface within the transaction upload interface can directly receive the contract binary file and application binary import file (ABI) corresponding to the compiled original contract code input by the upper-layer application, and then implement contract deployment based on these two. This eliminates the need to convert the original contract code into Java code and then call the corresponding Java method to deploy the contract. Therefore, the process of compiling the original contract code into Java code is eliminated, allowing any contract to directly call the transaction upload interface for contract deployment, achieving universal contract deployment. During the ordinary transaction upload phase, the on-chain transaction platform can generate transactions to be uploaded to the blockchain based on the transaction information input by the upper-layer application, temporarily store these transactions in a local transaction pool, poll the local transaction pool according to a preset time, and finally upload multiple transactions to the blockchain simultaneously through the batch upload interface. Simultaneously, the transaction results of multiple transactions to be uploaded to the blockchain can be queried through the batch query interface. In this way, multiple transactions awaiting on-chain can be simultaneously uploaded to the blockchain and their results queried through the batch upload and batch query interfaces. This not only achieves the generalization of contract transactions and contract queries, but also improves the efficiency of transaction upload and transaction result query.

[0081] The following is a detailed explanation of the process of deploying the contract on the blockchain. Figure 3 This is a schematic diagram of the structure of an on-chain method for deploying contract transactions, as provided in an embodiment of this application. Figure 3 As shown, the method includes the following steps.

[0082] 301. Upper-layer applications input contract deployment transaction information to the transaction on-chain platform through the contract deployment interface.

[0083] The contract deployment transaction information may include the original Solidity contract code file, contract name, construction parameters, first application transaction request number, wallet number, etc. The first application transaction request number is used to identify this contract deployment transaction. The upper-layer application refers to the application that needs to be deployed, such as an NFT application or a notarization application. Solidity is a contract-oriented high-level programming language created to implement smart contracts; the Solidity language runs on the Ethereum Virtual Machine. Solidity original contract code files typically have the .sol extension.

[0084] The following is a brief explanation of the various information items in the contract deployment transaction information, using an NFT application (upper-layer application) as an example:

[0085] The NFT contract source file can be the NFT.sol contract source file code. The contract name refers to the name of the contract source file input by the NFT application; users can identify the current contract by customizing the contract name. The first application transaction request number refers to the request number initiated by the NFT application for this contract deployment transaction, used to uniquely identify this contract deployment transaction. The wallet number, also known as the wallet address, refers to the wallet account that sent the transaction. The constructor parameters refer to the parameters required by the contract's constructor method, which can be used for contract initialization.

[0086] 302. The on-chain trading platform compiles the original contract code file to obtain the contract binary file and the application binary interface (ABI) file corresponding to the original contract code file.

[0087] The upper-layer application calls the contract deployment interface of the on-chain trading platform to send the contract deployment transaction information to the platform. The platform then compiles the original contract code file to obtain the corresponding binary contract file and the corresponding application binary interface (ABI) file. For example, the Solidty compiler "solc" can be used to compile the original contract code file to obtain the corresponding binary contract file and the corresponding ABI file.

[0088] The ABI file corresponding to the original contract code file is a bytecode file that can run on the blockchain. For a contract to be deployed on the blockchain, it needs to be compiled into a bytecode file that Ethereum can recognize. The Application Binary Interface (ABI) file corresponding to the original contract code file is the interface for interaction between programs; it's a file that applications need to call. The ABI file includes constructors, transaction methods, query methods, and events required by the application.

[0089] The following explains the constructor, transaction methods, query methods, and events of ABI files.

[0090] 1. The constructor is the method used to build a contract; it's the method called when the contract is deployed. For example, the constructor of an NFT contract could be:

[0091] constructor(string memory name, string memory description) public {

[0092] _name = name;

[0093] _description = description;

[0094] }

[0095] 2. The transaction method refers to the method called during contract transactions. For example, the code for an NFT destruction interface can be `function burnNFT(uint256 tokenId)`. When you need to destroy a certain interface, call this code, enter the tokenId number, and the interface corresponding to that number will be destroyed.

[0096] 3. The query method refers to the method used to query data on the blockchain corresponding to the contract, and typically returns parameters of the query results. For example, the interface for retrieving tokenId metadata:

[0097] queryNftByTokenId(uint256 tokenId) public view returns (string,string, string, address)

[0098] When querying tokenId metadata, you can call this method and enter the tokenId number. The blockchain will then return the tokenId metadata, including its name, image, description, and the holder's blockchain address.

[0099] 4. Events are used to record data as logs and save them to the blockchain. These log events are output on the blockchain during contract transactions. They are typically returned in the transaction receipt data and used to view the results. For example, a transfer event will be generated after the successful destruction of an NFT-tokenId.

[0100] event Transfer(address indexed from, address indexed to, uint256indexed tokenId);

[0101] Transfer(owner, address(0), tokenId);

[0102] The above event describes the transfer of tokenId from the token owner to address 0.

[0103] Through the steps described above, when deploying contracts, the on-chain trading platform directly compiles the original contract code files into contract binary files and application binary interface (ABI) files. The contract deployment process is then achieved by directly inputting these two files. This eliminates the need to first convert each original contract code file into a Java file and then deploy the contract by calling the corresponding Java contract deployment and transaction methods. This simplifies the contract deployment process, eliminating the need to convert the original contract code files into Java files, and allows any contract to be deployed directly using only the contract binary files and ABI files, thus achieving a universal contract deployment process.

[0104] 303. The on-chain transaction platform records the correspondence between the ABI file list and the transaction request number.

[0105] Specifically, the on-chain trading platform records an ABI list, which is a collection of ABI constructors, transaction methods, query methods, events, and times. During contract deployment, the compiled ABI files need to be stored. For example, multiple ABI files corresponding to a single contract deployment transaction can be stored as an ABI list. Simultaneously, the on-chain trading platform records the correspondence between the ABI list of the contract deployment transaction and the first transaction request number, used to mark the contract deployment transaction. This facilitates subsequent transactions and transaction result queries by looking up the contract's ABI list using the first transaction request number. It also facilitates calling the transaction methods and query methods of the contract's ABI list.

[0106] 304. The on-chain transaction platform performs data format conversion based on the construction parameters in the transaction information deployed in the contract.

[0107] During the contract deployment phase, it is necessary to convert the data format of the data in the contract deployment transaction from Java type to Solidity data type, and then convert the Solidity data type to RLP format.

[0108] Recursive Length Prefix (RLP) provides an encoding suitable for arbitrary binary data arrays and is the primary encoding method for object serialization in Ethereum. RLP is the most commonly used serialization format method in Ethereum. Therefore, if a transaction is to run on the Ethereum blockchain, other data formats need to be converted to the Ethereum blockchain's serialization format.

[0109] In this step, firstly, based on the data format of the contract's constructor and constructor parameters, the format of the Java type data in the upper-layer application is converted into the web3j.type type that matches the data format of the contract's constructor and constructor parameters. Then, the web3j.type type is converted into Ethereum's serialization RLP format, so that the contract can run on the Ethereum blockchain.

[0110] 305. The on-chain trading platform packages the contract binary file and the constructor file in the ABI file to generate a contract to be signed and deployed for trading.

[0111] The on-chain transaction platform packages the contract binary file, constructor file, constructor parameters, blockchain-related parameters, and other data to obtain the transaction to be signed. The blockchain-related parameters include data such as the chain's block height and nonce. The chain's block height, or block number, is the number of blocks connected to the main chain and represents the block number. The transaction nonce represents the number of transactions and is used to record the total number of transactions executed by the account.

[0112] 306. The on-chain transaction platform calls the wallet service to obtain the signature corresponding to the contract to be signed for deployment.

[0113] After packaging and deploying the contract, the on-chain trading platform calls the wallet service, inputting the wallet number and wallet blockchain address. It then obtains the signature data corresponding to the contract deployment transaction, which can be used subsequently to sign the contract deployment transaction to be signed.

[0114] 307. Calculate the first transaction hash value corresponding to the transaction to be deployed in the contract to be uploaded to the chain.

[0115] First, when performing digital signatures, the transaction to be signed, which is the packaged RLP-encoded transaction serialization message, needs to be hashed. Hash calculation refers to using a hash function to map a message of arbitrary length into a shorter, fixed-length value, which is called the hash value. The hash value can serve as a unique identifier for a piece of digital content. In this application, after hash calculation, the transaction data to be signed is shortened into a string, which is the transaction hash value. The transaction hash value is used to indicate an address on the blockchain.

[0116] 308. The on-chain transaction platform uses the signature function to sign the contract to be signed for deployment, thus obtaining the contract to be deployed on the chain.

[0117] For example, the on-chain transaction platform obtains the wallet's private key, uses the wallet's private key to sign the contract deployment transaction to obtain the final contract deployment transaction to be on-chain, which is the transaction data to be sent to the blockchain.

[0118] Below is a brief introduction to the digital signature process:

[0119] Digital signatures are primarily used to verify the legitimacy of the sender of a transaction, prevent information from being tampered with during the transaction, confirm user identity, and ensure that information cannot be repudiated. Understandably, the sender uses their private key to encrypt the transaction information of the contract to be signed.

[0120] 309. The on-chain transaction platform generates the first transaction order number, establishes and stores the correspondence between the first application transaction request number, ABI file, contract binary file, first transaction hash value, and first transaction order number.

[0121] After generating a contract to be deployed on the blockchain, the trading platform generates a first transaction business request number for this contract deployment. It then stores the transaction time, the first application transaction request number, the ABI file, the contract binary file, the transaction hash value, and the first transaction business request number in the database. The status of this contract deployment transaction is then marked as "on-chain". The first application transaction request number, the first transaction business request number, and the transaction hash value are uniquely associated with all parameters of this contract deployment transaction. All three can be used to identify the transaction, and any one of them can be used to query the transaction result of the contract deployment transaction in subsequent queries.

[0122] 310. The on-chain trading platform places the contracts to be deployed on the chain into the local trading pool.

[0123] After placing the contract deployment transaction to be deployed on-chain into its local transaction pool, the on-chain transaction platform can report to the upper-layer application that the contract transaction has been successfully received, and then return the first transaction order number to the upper-layer application. The local transaction pool can temporarily store multiple transactions to be deployed on-chain, including multiple contract deployment transactions and multiple contract transactions. The on-chain transaction platform can upload multiple transactions received within a certain period to the blockchain in batches.

[0124] 311. The on-chain transaction platform sends the contracts to be deployed to the blockchain through the batch upload interface.

[0125] The on-chain trading platform's transaction pool can continuously receive contract deployment transactions and contract transactions from upper-layer applications and store these transactions in its local transaction pool. This allows the on-chain trading platform to batch-upload transactions to the blockchain at preset intervals, such as 500ms. For example, the platform can retrieve multiple transactions awaiting on-chain upload from the transaction pool every 500ms and then upload them to the blockchain in batches via a batch upload interface.

[0126] The blockchain transaction platform uses a batch upload interface to upload multiple transactions from the local transaction pool to the blockchain in batches, solving the problem that only one transaction can be uploaded to the blockchain at a time in existing blockchain systems, and greatly improving the efficiency of transaction uploading.

[0127] 312. The on-chain trading platform uses the batch query interface to query the transaction results corresponding to the contract deployment transactions to be on-chain, and parses the transaction results.

[0128] The batch query interface allows the blockchain trading platform to query the transaction results of multiple transactions that are about to be uploaded to the blockchain at one time and return the transaction results.

[0129] In one embodiment of this application, the on-chain transaction platform uses the transaction hash value to continuously poll through a batch query interface and query the transaction results of multiple transactions simultaneously. When the transaction result of a certain transaction is obtained, the transaction result needs to be parsed and stored.

[0130] For example, an on-chain transaction platform can use an exception timer to retrieve transaction data for transactions that have not been successfully uploaded to the blockchain for an extended period. Specifically, the platform can query the blockchain multiple times. If it cannot find the transaction data corresponding to the transaction hash in the blockchain, or if, according to the transaction database update information, the transaction information in the database cannot be updated after more than 10 minutes, it can be determined that the transaction may not have been received by the blockchain due to network issues or other reasons. In this case, the platform repackages the contract transaction parameters to obtain a new transaction to be signed. Through this new transaction to be signed, it obtains a new hash value and a new transaction to be uploaded to the blockchain. Then, it updates the hash value of the transaction in the database according to the transaction request number, and then re-uploads the transaction to the blockchain until the transaction is uploaded and the transaction result is parsed.

[0131] For example, if the contract deployment transaction is successful, the on-chain trading platform can parse the contract address of the successfully deployed contract from the transaction result. If the transaction fails, an error message indicating that the transaction failed will be returned.

[0132] 313. The on-chain trading platform stores the transaction results of contracts to be deployed on the blockchain in the database.

[0133] After parsing the results, the on-chain transaction platform needs to store the contract address, receipt result list, ABI file list, transaction hash value, and transaction result in the database, update the database for that transaction, and then record the transaction status as successful. At this point, the transaction is complete. Ultimately, the first application transaction request number, the first transaction business order number, and the transaction hash value are all uniquely identified, allowing for the identification of this contract deployment transaction.

[0134] 314. Upper-layer applications can query transaction results using the first application transaction request number or the first transaction business order number.

[0135] Upper-layer applications can query the contract deployment result from the database of the on-chain transaction platform using the first transaction request number or the first transaction business order number. If the contract deployment transaction is successful, the application can obtain information such as the contract address, ABI file list, receipt result list, and transaction success result stored in the database using the first transaction request number or the first transaction business order number. If the contract deployment transaction fails, the application can also read the error information of the transaction failure from the database.

[0136] In the technical solution provided in the above-described embodiments of this application, the on-chain trading platform can directly deploy contracts based on the contract binary file and application binary import file (ABI) obtained by compiling the contract source code file input by the upper-layer application. This eliminates the need to convert the contract source code file into Java code and then call the corresponding Java method to deploy the contract, thus eliminating the process of compiling the contract source code file into Java code. This allows any contract to be deployed directly through the transaction upload interface, achieving universal contract deployment. Furthermore, the on-chain trading platform can temporarily store the contracts to be deployed on the blockchain in a local transaction pool. Then, it polls the local transaction pool according to a preset time, simultaneously uploading multiple transactions to the blockchain through a batch upload interface, and simultaneously querying the transaction results of multiple transactions already on the blockchain through a batch query interface. By simultaneously performing on-chain upload and transaction result querying for multiple transactions to be uploaded through the batch upload and batch query interfaces, the efficiency of transaction upload and transaction result querying is improved.

[0137] Based on the above embodiments, the on-chain process of ordinary contract transactions will be described below. It can be understood that the on-chain process of contract transactions is similar to that of contract deployment transactions, with differences only in certain parts, such as the packaging process. The following will focus on the differences between the on-chain process of contract transactions and contract deployment transactions, and similar steps will not be repeated.

[0138] First, the upper-layer application needs to call the transaction input interface to input contract transaction information into the on-chain transaction platform. Since contract transactions are based on deployed contracts, the contract transaction information includes the second application transaction request number, the ABI number of the contract to be called, the contract address, ABI parameters, wallet number, etc. The contract transaction can call the transaction constructor method of a successfully on-chain contract to deploy the transaction. The ABI number in the contract transaction information is the identifier of the ABI file of the contract to be called in this transaction. The ABI number uniquely identifies an on-chain contract, and the on-chain transaction platform can use the ABI number to find the corresponding ABI file and thus the corresponding constructor method. The ABI parameters refer to the parameter values ​​input to the constructor method in the ABI file when the contract transaction calls it.

[0139] Next, after receiving the contract transaction information, the on-chain trading platform packages the contract address, ABI number, ABI parameters, wallet number, etc., to obtain the contract transaction to be signed. Specifically, the on-chain trading platform queries the database for the constructor method and constructor parameters corresponding to the ABI number, and then matches the retrieved constructor method and data type with the input method and parameters. For example, it checks whether the input ABI method is the corresponding transaction method, and whether the number and data format of the corresponding parameters in the ABI are consistent with the number and data format of the input parameters. If the ABI number, parameters, and method match, the contract address, ABI number, contract address, ABI parameters, wallet number, and other data are packaged and assembled into the contract transaction to be signed.

[0140] Next, after packaging the contract transaction, the on-chain trading platform calls the wallet service, inputting the wallet number and wallet blockchain address. It obtains the signature data corresponding to the contract transaction and then uses this data to sign the contract transaction to be signed. During the digital signature process, the contract transaction to be signed is first hashed to obtain its transaction hash value. Then, the on-chain trading platform obtains the wallet's private key and uses it to sign the contract transaction to be signed, resulting in the final contract transaction to be uploaded to the blockchain, which is the contract transaction data to be sent to the blockchain.

[0141] Next, the on-chain trading platform generates a second transaction order number corresponding to the contract transaction, establishing and storing the correspondence between the second application transaction request number, the second transaction hash value, and the first transaction order number. It also marks the status of the contract transaction as "on-chain". The second application transaction request number, the second transaction order number, and the transaction hash value are uniquely matched and used to associate all parameters of the contract transaction. All three—the second application transaction request number, the second transaction order number, and the transaction hash value—can be used to identify the transaction, and any one of them can be used to query the transaction result in subsequent searches.

[0142] Finally, the on-chain trading platform temporarily stores the packaged contract transactions to be on-chain in its local transaction pool, and then simultaneously uploads multiple transactions from the local pool via a batch upload interface. The platform then needs to query the transaction results of multiple transactions simultaneously via a batch query interface. For contract transactions, it polls the contract's ABI event list, parses out matching transaction events, and stores the event results, receipt result list, transaction hash, etc., in the database. The transaction status is then recorded as successful, and the transaction ends. If a transaction fails, an error message is returned, stored in the database, and the transaction status is recorded as failed.

[0143] Figure 4 This is a schematic diagram of a transaction on-chain processing device provided in an embodiment of this application. The following is in conjunction with... Figure 4 The embodiments described below are described in detail. The embodiments described below are used to explain the technical solutions of this application and are not intended to limit actual use. Figure 4 As shown, the processing device includes an on-chain transaction platform, which connects to an upper-layer application with a wallet system via a transaction upload interface, and connects to the blockchain via a batch upload interface / batch query interface. The processing device includes:

[0144] The receiving unit 401 is used to receive transaction information input by the upper-layer application through the transaction upload interface.

[0145] Processing unit 402 is used to process the transaction information input by the upper layer application and generate transactions to be uploaded to the chain.

[0146] Storage unit 403 is used to temporarily store transactions to be uploaded to the blockchain in the local transaction pool.

[0147] The acquisition unit 404 is used to poll the local transaction pool according to a first preset time period and acquire multiple transactions to be uploaded to the blockchain from the local transaction pool.

[0148] Processing unit 402 is also used to simultaneously upload multiple transactions to be uploaded to the blockchain via a batch upload port.

[0149] The query unit 405 is used to query the transaction results of multiple transactions that have been put on the chain at the same time through the batch query interface. The multiple transactions to be put on the chain correspond to the multiple transactions that have been put on the chain.

[0150] In an optional implementation, the on-chain transaction platform connects to the upper-layer application via a transaction query interface. The device also includes a sending unit 406. The query unit 405 is specifically used to determine multiple transaction hash values ​​corresponding to multiple on-chain transactions, and based on these multiple transaction hash values, simultaneously query the transaction result corresponding to each of the multiple on-chain transactions in the blockchain.

[0151] Storage unit 403 is also used to store the transaction result corresponding to each transaction that has been put on the chain.

[0152] The receiving unit 401 is also used to receive transaction result query requests sent by the upper-layer application through the transaction query interface.

[0153] The processing unit 402 is also used to respond to the transaction result query request and determine the target transaction hash value corresponding to the transaction result query request.

[0154] Sending unit 406 is used to send the transaction result corresponding to the target transaction hash value to the upper layer application through the transaction query interface.

[0155] In one optional implementation, the transaction upload interface includes a contract deployment interface, and the transaction information is contract deployment transaction information. The contract deployment transaction information includes the original contract code file and the first application transaction request number, and the transactions to be uploaded to the blockchain include contract deployment transactions to be uploaded to the blockchain.

[0156] Processing unit 402 is specifically used to compile the original contract code file to obtain a contract binary file and an application binary interface (ABI) file corresponding to the original contract code file. The ABI file includes a constructor file. The contract binary file and the constructor file are then packaged to generate a contract to be signed and deployed.

[0157] The retrieval unit 404 is also used to call the wallet signature service of the upper-layer application to obtain the signature corresponding to the upper-layer application.

[0158] Processing unit 402 is specifically used to sign the contract deployment transaction to be signed, thereby obtaining the contract deployment transaction to be uploaded to the chain.

[0159] In an optional implementation, processing unit 402 is further configured to, after storing the ABI file and contract binary file corresponding to the contract deployment transaction to be uploaded to the blockchain in storage unit 403, generate a first transaction business order number corresponding to the contract deployment transaction to be uploaded to the blockchain. It also calculates a first transaction hash value corresponding to the contract deployment transaction to be uploaded to the blockchain. Finally, it establishes a first correspondence between the first application transaction request number, the ABI file, the contract binary file, the first transaction hash value, and the first transaction business order number.

[0160] Storage unit 403 is also used to store the first correspondence.

[0161] The sending unit 406 is also used to send the first transaction order number to the upper-layer application through the contract deployment interface. The first transaction order number is used to report to the upper-layer application that the contract deployment transaction information has been successfully received.

[0162] In an optional implementation, the on-chain transaction platform further includes a database module and a processing unit 402, which is also used to parse the transaction results of multiple on-chain transactions and determine the transaction result information corresponding to each on-chain transaction. Among the transaction result information of the multiple on-chain transactions, the first transaction result information corresponding to the first transaction hash value is determined. The first transaction result information includes the first transaction hash value, the first receipt event information, and the contract address information / on-chain failure information.

[0163] Storage unit 403 is also used to store first receipt event information and contract address information / on-chain failure information in the database module.

[0164] In one optional implementation, the transaction query interface is specifically used to receive a first transaction result query request sent by the upper-layer application. The first transaction result query request includes the first transaction business order number / the first application transaction request number.

[0165] The processing unit 402 is also used to respond to the first transaction result query request and determine the first transaction hash value corresponding to the first transaction business order number / first application transaction request number according to the first correspondence relationship.

[0166] The query unit 405 is also used to query the first receipt event information, contract address information / on-chain failure information and ABI file number corresponding to the first transaction hash value in the database module.

[0167] The sending unit 406 is also used to send the first receipt event information, contract address information / on-chain failure information and ABI file number corresponding to the first transaction hash value to the upper layer application through the transaction query interface.

[0168] In one optional implementation, the transaction upload interface includes a transaction input interface. The transaction information is contract transaction information, which includes the second application transaction request number, ABI file call information, and ABI file input parameters. Transactions to be uploaded to the blockchain include contract transactions to be uploaded to the blockchain.

[0169] Processing unit 402 is specifically used to determine the ABI file to be called in the database module based on the ABI file call information. It packages the contract address information corresponding to the ABI file to be called, the corresponding number of the ABI file to be called, and the ABI file input parameters to generate a contract transaction to be signed.

[0170] The retrieval unit 404 is also used to call the wallet signature service of the upper-layer application to obtain the signature corresponding to the upper-layer application.

[0171] Processing unit 402 is specifically used to obtain the contract transaction to be uploaded to the chain based on the signature and the contract transaction to be signed.

[0172] In an optional implementation, the processing unit 402 is further configured to, after the storage unit 403 has stored the correspondence between the second application transaction request number and the second transaction hash value in the database module, generate the second transaction business order number corresponding to the contract transaction; calculate the second transaction hash value corresponding to the contract transaction to be uploaded to the blockchain; and establish a second correspondence between the second application transaction request number, the second transaction hash value, and the second transaction business order number.

[0173] Storage unit 403 is also used to store the second correspondence in the database module.

[0174] The sending unit 406 is also used to send the second transaction business order number to the upper-layer application through the transaction input interface. The second transaction business order number is used to report the successful receipt of contract transaction information to the upper-layer application.

[0175] In an optional implementation, the processing unit 402 is further configured to determine the second transaction result information corresponding to the second transaction hash value from the transaction result information of multiple on-chain transactions. The second transaction result information includes the second transaction hash value, the second receipt event result, and the on-chain result information.

[0176] Storage unit 403 is also used to store the second receipt event result and on-chain result information corresponding to the second transaction hash value in the database module.

[0177] In one optional implementation, the transaction query interface is specifically used to receive a second transaction result query request sent by the upper-layer application. The second transaction result query request includes the second transaction business order number / second application transaction request number.

[0178] Processing unit 402 is also configured to respond to the second transaction result query request and determine the second transaction hash value corresponding to the second transaction business order number / second application transaction request number based on the second correspondence. The database module then determines the second receipt event information and on-chain result information corresponding to the second transaction hash value.

[0179] The sending unit 406 is also used to send the second receipt event result and on-chain result information corresponding to the second transaction hash value to the upper layer application through the transaction query interface.

[0180] In an optional implementation, processing unit 402 is further configured to identify a target transaction for which no transaction result was found among multiple transactions to be added to the blockchain within a second preset time period. The target transaction is then re-added to the local transaction pool. The transaction hash value is recalculated for the target transaction.

[0181] In this embodiment, the on-chain transaction platform provides a transaction upload interface, a batch upload interface, and a batch query interface. The transaction upload interface is connected to the upper-layer application and is used to receive transaction information. This transaction information can be contract deployment information or ordinary transaction information. During the contract deployment phase, the contract deployment interface within the transaction upload interface can directly receive the contract binary file and application binary import file (ABI) corresponding to the compiled original contract code input by the upper-layer application, and then implement contract deployment based on these two. This eliminates the need to convert the original contract code into Java code and then call the corresponding Java method to deploy the contract. Therefore, the process of compiling the original contract code into Java code is eliminated, allowing any contract to directly call the transaction upload interface for contract deployment, achieving universal contract deployment. During the ordinary transaction upload phase, the on-chain transaction platform can generate transactions to be uploaded to the blockchain based on the transaction information input by the upper-layer application, temporarily store these transactions in a local transaction pool, poll the local transaction pool according to a preset time, and finally upload multiple transactions to the blockchain simultaneously through the batch upload interface. Simultaneously, the transaction results of multiple transactions to be uploaded to the blockchain can be queried through the batch query interface. In this way, multiple transactions awaiting on-chain can be simultaneously uploaded to the blockchain and their results queried through the batch upload and batch query interfaces. This not only achieves the generalization of contract transactions and contract queries, but also improves the efficiency of transaction upload and transaction result query.

[0182] It should be noted that the information interaction and execution process between the various modules / units in the device are different from those in this application. Figures 1 to 3 The various method embodiments are based on the same concept, and the details can be found in the descriptions of the method embodiments shown above in this application, which will not be repeated here.

[0183] The following describes an electronic device provided by an embodiment of this application. Please refer to [link / reference]. Figure 5 , Figure 5 This is a schematic diagram of an electronic device provided in an embodiment of this application. The electronic device 500 may be equipped with... Figure 4 The transaction on-chain processing device described in the corresponding embodiment is used to implement... Figures 1 to 4 The functions correspond to those in the embodiments. Specifically, the electronic device 500 includes: a receiver 501, a transmitter 502, a processor 503, and a memory 504 (wherein the number of processors 503 in the execution device 500 may be one or more). Figure 5 (Taking a processor as an example), processor 503 may include application processor 5031 and communication processor 5032. In some embodiments of this application, receiver 501, transmitter 502, processor 503 and memory 504 may be connected via a bus or other means.

[0184] Memory 504 may include read-only memory and random access memory, and provides instructions and data to processor 503. A portion of memory 504 may also include non-volatile random access memory (NVRAM). Memory 504 stores processor and operation instructions, executable modules, or data structures, or subsets thereof, or extended sets thereof, wherein the operation instructions may include various operation instructions for implementing various operations.

[0185] Processor 503 controls the operation of the execution device. In specific applications, the various components of the execution device are coupled together through a bus system, which may include not only the data bus, but also power buses, control buses, and status signal buses. However, for clarity, all buses are referred to as the bus system in the diagram.

[0186] The methods disclosed in the embodiments of this application can be applied to processor 503, or implemented by processor 503. Processor 503 can be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 503 or by instructions in the form of software. The processor 503 can be a general-purpose processor, a digital signal processor (DSP), a microprocessor or a microcontroller, and may further include an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The processor 503 can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 504, and processor 503 reads the information from memory 504 and, in conjunction with its hardware, completes the steps of the above method.

[0187] Receiver 501 can be used to receive input digital or character information, and to generate signal inputs related to the settings and function control of the execution device. Transmitter 502 can be used to output digital or character information through the first interface; transmitter 502 can also be used to send instructions to the disk group through the first interface to modify the data in the disk group; transmitter 502 may also include a display device such as a display screen.

[0188] In this embodiment of the application, the application processor 5031 in the processor 503 is used to execute... Figures 1 to 4 The specific steps of the transaction on-chain platform and on-chain transaction method in the example are different from those in this application. Figures 1 to 4 The various method embodiments are based on the same concept, and the technical effects they bring are the same as those in this application. Figures 1 to 4 The various method embodiments are the same, and for details, please refer to the description in the method embodiments shown above in this application, which will not be repeated here.

[0189] This application provides a computer-readable storage medium, which includes computer instructions. When executed by a processor, the computer instructions are used to implement the technical solution of any of the transaction on-chain methods in this application.

[0190] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0191] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0192] Computer-readable media, as defined herein, includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include non-transitory computer-readable media, such as modulated data signals and carrier waves.

[0193] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0194] Although this application discloses preferred embodiments as described above, it is not intended to limit this application. Any person skilled in the art can make possible changes and modifications without departing from the spirit and scope of this application. Therefore, the scope of protection of this application should be determined by the scope defined in the claims of this application.

Claims

1. A method for recording transactions on the blockchain, characterized in that, The method for batch on-chain transactions is applied to an on-chain trading platform, which connects to an upper-layer application with a wallet system through a transaction upload interface, and connects to the blockchain through a batch upload interface and a batch query interface; the method for on-chain transactions includes: The transaction information input by the upper-layer application is received through the transaction upload interface; The transaction information input by the upper-layer application is processed to generate transactions to be uploaded to the blockchain; The transactions to be uploaded to the blockchain are temporarily stored in the local transaction pool; The local transaction pool is polled according to a first preset time period to obtain multiple transactions to be uploaded to the blockchain from the local transaction pool. The multiple transactions to be uploaded to the blockchain are simultaneously uploaded through the batch upload interface; The batch query interface allows simultaneous querying of transaction results for multiple transactions that have already been uploaded to the blockchain; the multiple transactions awaiting upload to the blockchain correspond to the multiple transactions that have already been uploaded to the blockchain. The transaction upload interface includes a contract deployment interface; the transaction information is contract deployment transaction information, which includes the original contract code file and the first application transaction request number; the transactions to be uploaded to the blockchain include contract deployment transactions to be uploaded to the blockchain. The process of processing the transaction information input by the upper-layer application to generate transactions to be uploaded to the blockchain includes: The original contract code file is compiled to obtain a contract binary file and an application binary interface (ABI) file corresponding to the original contract code file; wherein, the ABI file includes a constructor file; The contract binary file and the constructor file are packaged together to generate a contract to be signed and deployed for transaction purposes. Call the wallet signing service of the upper-layer application to obtain the signature corresponding to the upper-layer application; The signature is used to sign the contract deployment transaction to be signed, thus obtaining the contract deployment transaction to be uploaded to the blockchain.

2. The transaction on-chain method according to claim 1, characterized in that, The on-chain transaction platform connects to the upper-layer application via a transaction query interface; the process of simultaneously querying the transaction results of multiple on-chain transactions through the batch query interface includes: Determine the multiple transaction hash values ​​corresponding to the multiple transactions that have been uploaded to the blockchain; Based on the multiple transaction hash values ​​corresponding to the multiple on-chain transactions, simultaneously query the transaction result corresponding to each of the multiple on-chain transactions in the blockchain; and store the transaction result corresponding to each on-chain transaction. The method further includes: The transaction query interface receives transaction result query requests sent by the upper-layer application. In response to the transaction result query request, determine the target transaction hash value corresponding to the transaction result query request; The transaction result corresponding to the target transaction hash value is sent to the upper-layer application through the transaction query interface.

3. The transaction on-chain method according to claim 2, characterized in that, The method further includes: After storing the ABI file and the contract binary file corresponding to the contract deployment transaction to be uploaded to the blockchain, a first transaction business order number corresponding to the contract deployment transaction to be uploaded to the blockchain is generated; Calculate the first transaction hash value corresponding to the transaction to be deployed in the contract to be uploaded to the blockchain; Establish a first correspondence between the first application transaction request number, the ABI file, the contract binary file, the first transaction hash value, and the first transaction business number, and store the first correspondence. The first transaction order number is sent to the upper-layer application through the contract deployment interface; the first transaction order number is used to send feedback to the upper-layer application that the contract deployment transaction information has been successfully received.

4. The transaction on-chain method according to claim 3, characterized in that, The on-chain transaction platform also includes a database module, and the method further includes: Analyze the transaction results of the multiple on-chain transactions to determine the transaction result information corresponding to each on-chain transaction among the multiple on-chain transactions; The first transaction result information corresponding to the first transaction hash value is determined from the transaction result information of the multiple on-chain transactions; the first transaction result information includes the first transaction hash value, the first receipt event information, and the contract address information / on-chain failure information; The database module stores the first receipt event information and the contract address information / on-chain failure information.

5. The transaction on-chain method according to claim 4, characterized in that, The transaction query interface is specifically used to receive a first transaction result query request sent by the upper-layer application; the first transaction result query request includes the first transaction business number / the first application transaction request number; The method further includes: In response to the first transaction result query request, determine the first transaction hash value corresponding to the first transaction business order number / first application transaction request number based on the first correspondence relationship; Query the database module for the first receipt event information, contract address information / on-chain failure information, and the ABI file number corresponding to the first transaction hash value; The transaction query interface sends the first receipt event information, contract address information / on-chain failure information, and ABI file number corresponding to the first transaction hash value to the upper-layer application.

6. The transaction on-chain method according to claim 4, characterized in that, The transaction upload interface includes a transaction input interface; the transaction information is contract transaction information, which includes the second application transaction request number, ABI file call information, and ABI file input parameters; the transactions to be uploaded to the blockchain include contract transactions to be uploaded to the blockchain. The process of processing the transaction information input by the upper-layer application to generate transactions to be uploaded to the blockchain includes: The ABI file to be invoked in the database module is determined based on the ABI file invocation information. The contract address information corresponding to the ABI file to be invoked, the number corresponding to the ABI file to be invoked, and the input parameters of the ABI file are packaged to generate a contract transaction to be signed. Call the wallet signing service of the upper-layer application to obtain the signature corresponding to the upper-layer application; The contract transaction to be uploaded to the blockchain is obtained based on the signature and the contract transaction to be signed.

7. The transaction on-chain method according to claim 6, characterized in that, The method further includes: After storing the correspondence between the second application transaction request number and the second transaction hash value in the database module, the second transaction business order number corresponding to the contract transaction is generated; Calculate the second transaction hash value corresponding to the contract transaction to be uploaded to the blockchain; Establish a second correspondence between the second application transaction request number, the second transaction hash value, and the second transaction business number, and store the second correspondence in the database module; The second transaction order number is sent to the upper-layer application through the transaction input interface; the second transaction order number is used to send feedback to the upper-layer application that the contract transaction information has been successfully received.

8. The transaction on-chain method according to claim 7, characterized in that, The method further includes: The second transaction result information corresponding to the second transaction hash value is determined from the transaction result information of the multiple on-chain transactions; the second transaction result information includes the second transaction hash value, the second receipt event result, and the on-chain result information; The database module stores the second receipt event result and on-chain result information corresponding to the second transaction hash value.

9. The transaction on-chain method according to claim 8, characterized in that, The transaction query interface is specifically used to receive a second transaction result query request sent by the upper-layer application; the second transaction result query request includes the second transaction business number / the second application transaction request number; The method further includes: In response to the second transaction result query request, determine the second transaction hash value corresponding to the second transaction business order number / second application transaction request number according to the second correspondence relationship; The database module determines the second receipt event information and on-chain result information corresponding to the second transaction hash value. The transaction query interface sends the second receipt event result corresponding to the second transaction hash value and the on-chain result information to the upper-layer application.

10. The transaction on-chain method according to claim 2, characterized in that, The method further includes: Identify the target transactions to be uploaded to the blockchain that have not yielded any results among the multiple transactions to be uploaded to the blockchain within the second preset time period; The target transaction to be uploaded to the blockchain is then placed back into the local transaction pool; Recalculate the transaction hash value for the target transaction to be uploaded to the blockchain.

11. A processing device for on-chain transactions, characterized in that, The processing device includes an on-chain transaction platform, which is connected to an upper-layer application with a wallet system via a transaction upload interface, and is connected to the blockchain via a batch upload interface and a batch query interface; the processing device includes: The receiving unit is used to receive transaction information input by the upper-layer application through the transaction upload interface; The processing unit is used to process the transaction information input by the upper-layer application and generate transactions to be uploaded to the blockchain. A storage unit is used to temporarily store the transactions to be uploaded to the blockchain in a local transaction pool; The acquisition unit is used to poll the local transaction pool according to a first preset time period and acquire multiple transactions to be uploaded to the blockchain from the local transaction pool. The processing unit is also used to simultaneously upload the multiple transactions to be uploaded to the blockchain through the batch upload port; The query unit is used to simultaneously query the transaction results of multiple transactions that have been uploaded to the blockchain through the batch query interface; the multiple transactions to be uploaded to the blockchain correspond to the multiple transactions that have been uploaded to the blockchain. The transaction upload interface includes a contract deployment interface; the transaction information is contract deployment transaction information, which includes the original contract code file and the first application transaction request number; the transactions to be uploaded to the blockchain include contract deployment transactions to be uploaded to the blockchain. The process of processing the transaction information input by the upper-layer application to generate transactions to be uploaded to the blockchain includes: The original contract code file is compiled to obtain a contract binary file and an application binary interface (ABI) file corresponding to the original contract code file; wherein, the ABI file includes a constructor file; The contract binary file and the constructor file are packaged together to generate a contract to be signed and deployed for transaction purposes. Call the wallet signing service of the upper-layer application to obtain the signature corresponding to the upper-layer application; The signature is used to sign the contract deployment transaction to be signed, thus obtaining the contract deployment transaction to be uploaded to the blockchain.

12. An electronic device, characterized in that, The electronic device includes: a memory and a processor; the memory and the processor are coupled. The memory is used to store one or more computer instructions; The processor is used to execute one or more computer instructions to implement the transaction on-chain method as described in any one of claims 1 to 10.

13. A computer-readable storage medium storing one or more computer instructions, characterized in that, The instruction is executed by the processor to implement the on-chain transaction method as described in any one of claims 1 to 10.

Images