Smart contract-based processing method, apparatus, device, medium, and program product

Abstract

The application relates to a smart contract-based processing method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: receiving a contract interaction interface file about a smart contract; parsing the contract interaction interface file to obtain parameter names of various events in the smart contract, and creating various event tables about the smart contract according to the parameter names of the various events; obtaining on-chain event log data generated after a function in the smart contract is executed; parsing the on-chain event log data based on the parameter names of the events to obtain transaction data, and storing the transaction data into corresponding event tables; and the event tables are used to display corresponding transaction data when a transaction query request about the smart contract is received, thereby enhancing the flexibility of data analysis of the smart contract.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a smart contract-based processing method, apparatus, computer device, computer-readable storage medium, and computer program product. Background Technology

[0002] With the rapid development of blockchain technology, blockchain explorers, as crucial tools for users to interact with the blockchain, have become a core component of the blockchain technology ecosystem. As a vital tool for interacting with the blockchain network, blockchain explorers are responsible for displaying various types of data on the blockchain, including block information, transaction history, and contract calls. Typically, blockchain explorers parse smart contracts based on fixed contract templates to display the parsed data. However, there is a lack of effective parsing solutions for smart contracts that do not conform to common standards, resulting in limited flexibility in smart contract data parsing. Summary of the Invention

[0003] Therefore, it is necessary to provide a smart contract-based processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve the flexibility of smart contract data parsing, in order to address the aforementioned technical problems.

[0004] Firstly, this application provides a processing method based on smart contracts, including:

[0005] Receive the contract interaction interface file regarding smart contracts;

[0006] Parse the contract interaction interface file to obtain the parameter names of each event in the smart contract, and create an event table for the smart contract based on the parameter names of each event.

[0007] Obtain on-chain event log data generated after an event is triggered following the execution of a function in the smart contract;

[0008] The on-chain event log data is parsed based on the parameter name of the event to obtain transaction data, and the transaction data is stored in the corresponding event table. The event table is used to display the corresponding transaction data when a transaction query request about the smart contract is received.

[0009] Secondly, this application also provides a processing device based on smart contracts, comprising:

[0010] The file receiving module is used to receive contract interaction interface files related to smart contracts;

[0011] The event table generation module is used to parse the contract interaction interface file, obtain the parameter names of each event in the smart contract, and create various event tables about the smart contract based on the parameter names of each event.

[0012] The data generation module is used to acquire on-chain event log data generated after the execution of a function in the smart contract.

[0013] The data parsing module is used to parse the on-chain event log data based on the parameter name of the event to obtain transaction data, and store the transaction data in the corresponding event table. The event table is used to display the corresponding transaction data when a transaction query request about the smart contract is received.

[0014] In one embodiment, the device further includes a contract detection module, configured to obtain a contract runtime environment field from the raw transaction data obtained by executing the smart contract; based on the contract runtime environment field, detect whether the smart contract is a standard smart contract according to the corresponding standard smart contract verification method; and if the smart contract is a non-standard smart contract, execute the step of parsing the contract interaction interface file to obtain the parameter names of each event in the smart contract.

[0015] In one embodiment, the contract detection module is configured to, when the contract runtime environment field indicates that the smart contract is running on the Ethereum Virtual Machine (EVM), verify whether the smart contract is a standard smart contract running on the EVM based on the function declarations of multiple standard smart contracts and the function declaration of the smart contract, wherein the contract runtime environment required by the multiple standard smart contracts is the EVM; and when the contract runtime environment field indicates that the smart contract is running on a virtual container, call the software tool development kit (SDK) of the blockchain on which the smart contract is deployed to verify whether the smart contract is a standard smart contract running on the virtual container.

[0016] In one embodiment, the data parsing module is further configured to, when verifying that the smart contract belongs to a standard smart contract, identify the event topic from the transaction receipt; match the corresponding parsing logic according to the event topic, the parsing logic including the event data structure of the corresponding event; and decode the transaction data of the event according to the parameter name of the event in the event data structure.

[0017] In one embodiment, the event table generation module is used to obtain the event data structure of each event in the smart contract from the contract interaction interface file, wherein the event data structure includes the parameter name of each corresponding event; and to obtain the parameter name of each event in the smart contract based on the event data structure.

[0018] In one embodiment, the data generation module is used to obtain the event name of each event involved in the smart contract based on the contract interaction interface file; and to obtain on-chain event log data generated after the event is triggered from the original transaction data based on the event name of each event.

[0019] In one embodiment, the data parsing module is used to determine the parameter fields corresponding to each parameter name in the on-chain event log data based on the event data structure of the event in the contract interaction interface file; and to determine the transaction data of the event based on the parameter fields corresponding to each parameter name.

[0020] In one embodiment, the apparatus further includes a call relationship parsing module, configured to obtain the transaction read / write set after each transaction execution from the original transaction data of the smart contract; identify the cross-contract call relationship of the smart contract based on the transaction read / write set of each transaction; construct a cross-contract call relationship graph of the smart contract based on the cross-contract call relationship; and store the cross-contract call relationship graph in a graph database, wherein the cross-contract call relationship graph is used to query the cross-contract call status of the smart contract when a call query request about the smart contract is received.

[0021] In one embodiment, the call relationship parsing module is used to construct a contract call topology graph of the blockchain based on the cross-contract call relationship graph of each smart contract on the blockchain. The contract call topology graph is used to display when a blockchain call query request is received.

[0022] In one embodiment, the call relationship parsing module is used to parse the transaction read-write set for each transaction; when the transaction read-write set records other contract addresses besides the smart contract's contract address, it is determined that the smart contract has called other smart contracts corresponding to those other contract addresses; a call record of the smart contract calling the other smart contracts is created; the call record and the transaction identifier of the transaction are stored in the smart contract's cross-contract call table, which is used to record the cross-contract call relationships involved in transactions generated based on the smart contract.

[0023] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described smart contract-based processing method.

[0024] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described smart contract-based processing method.

[0025] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described smart contract-based processing method.

[0026] The aforementioned smart contract-based processing methods, devices, computer equipment, computer-readable storage media, and computer program products, by parsing the contract interaction interface file of the smart contract, can identify the parameter names of each event in the smart contract and create event tables for each event based on the parameter names of each event. Thus, after obtaining the on-chain event log data generated by events triggered after executing functions in the smart contract, the on-chain event log data can be automatically and accurately parsed based on the event parameter names to obtain transaction data. By storing the transaction data in the corresponding event tables, it can be ensured that the corresponding transaction data is displayed promptly when a transaction query request related to the smart contract is received. Throughout the data parsing process, the contract interaction interface file of the smart contract allows for flexible identification of the parameter names of each event in the smart contract, eliminating the need to parse the smart contract according to a fixed contract template. Therefore, based on the identified event parameter names, accurate data parsing of the on-chain event log data is possible, enhancing the flexibility of smart contract data parsing. Attached Figure Description

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

[0028] Figure 1 This is an application environment diagram of a smart contract-based processing method in one embodiment;

[0029] Figure 2 This is a flowchart illustrating a smart contract-based processing method in one embodiment;

[0030] Figure 3 This is a schematic diagram of a contract display page in one embodiment;

[0031] Figure 4 This is a schematic diagram of the contract verification process in one embodiment;

[0032] Figure 5 This is a schematic diagram of the standard smart contract judgment steps in one embodiment;

[0033] Figure 6a This is a schematic diagram of a contract details page in one embodiment;

[0034] Figure 6b This is a schematic diagram of the contract details page in another embodiment;

[0035] Figure 6c This is a schematic diagram of the contract details page in another embodiment;

[0036] Figure 7a This is a schematic diagram of the contract details page in another embodiment;

[0037] Figure 7b This is a schematic diagram of the contract details page in another embodiment;

[0038] Figure 7c This is a schematic diagram of the contract details page in another embodiment;

[0039] Figure 8 This is a schematic diagram illustrating a cross-contract call in one embodiment;

[0040] Figure 9 This is a schematic diagram of the event table generation steps in one embodiment;

[0041] Figure 10 This is a schematic diagram of the data parsing steps in one embodiment;

[0042] Figure 11 This is a schematic diagram of the contract call topology graph construction steps in one embodiment;

[0043] Figure 12 This is a structural block diagram of a smart contract-based processing device in one embodiment;

[0044] Figure 13 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0045] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0046] Before proceeding with the specific details, let me first explain some of the terms used in this application.

[0047] Blockchain explorer: A tool for displaying blockchain data, capable of viewing different types of blocks, transactions, smart contracts, and their interactions on the blockchain.

[0048] Standard smart contracts: refer to smart contracts that conform to a certain general specification or standard.

[0049] Non-standard smart contracts: These are smart contracts that do not conform to standard specifications or are custom-developed blockchain contracts, and typically have unique business logic or implementation methods.

[0050] Contract interaction interface file (ABI, Application Binary Interface): The interface used to interact with smart contracts, defining information such as the functions, events, and data structures of smart contracts.

[0051] IDA (Intelligent Data Asset) contracts: A type of contract that handles data asset transfer and notarization on the blockchain, such as for storing data and confirming ownership.

[0052] DID (Decentralized Identifiers) contracts: Blockchain contracts based on a decentralized identity framework used for identity verification and authentication.

[0053] BNS (Blockchain Name System) contract: A blockchain-based name system used for account binding, identity identification, etc.

[0054] Evidence storage contract: A type of blockchain contract used to store and prove the existence and recording of certain events or data.

[0055] Cross-contract call: refers to the operation of one contract calling another contract in a blockchain system. For example, contract A calling contract B, or mutual calls between multiple contracts.

[0056] Blockchain explorers in related technologies parse standard smart contracts based on fixed contract templates. Therefore, traditional blockchain explorers typically only support a few standard smart contract types. However, when faced with non-standard or customized contracts, the fixed contract templates cannot accurately parse the event data of non-standard smart contracts, resulting in the inability to correctly display key information such as transaction flow and asset changes. Parsing these non-standard smart contracts often requires users to manually upload data or develop a corresponding parsing scheme for each non-standard smart contract. In other words, for smart contracts that do not conform to general standards, there is a lack of effective parsing schemes, leading to low flexibility in smart contract data parsing.

[0057] The smart contract-based processing method provided in this application, by parsing the contract interaction interface file of the smart contract, can identify the parameter names of each event in the smart contract and create event tables for each event based on the parameter names of each event. Thus, after obtaining the on-chain event log data generated by events triggered after executing functions in the smart contract, the on-chain event log data can be automatically and accurately parsed based on the event parameter names to obtain transaction data. By storing the transaction data in the corresponding event tables, it can ensure that the corresponding transaction data is displayed promptly when a transaction query request related to the smart contract is received. Throughout the data parsing process, the contract interaction interface file of the smart contract can flexibly identify the parameter names of each event in the smart contract, eliminating the need to parse the smart contract according to a fixed contract template. Therefore, based on the identified event parameter names, accurate data parsing of the on-chain event log data can be performed, enhancing the flexibility of smart contract data parsing.

[0058] The smart contract-based processing method provided in this application can be applied to, for example... Figure 1In the application environment shown, terminal 110 sends a contract interaction interface file about the smart contract to server 120. Server 120 parses the contract interaction interface file to obtain the parameter names of each event in the smart contract and creates event tables for the smart contract based on the parameter names of each event. Server 120 initiates a data acquisition request to blockchain network 130 and obtains the blockchain data returned by blockchain network 130 in response to the data acquisition request. Based on the blockchain data, server 120 determines the on-chain event log data generated after the execution of the function in the smart contract. Server 120 parses the on-chain event log data based on the parameter names of the events to obtain transaction data and stores the transaction data in the corresponding event table. The event table is used by server 120 to return the corresponding transaction data to terminal 110 when it receives a transaction query request about the smart contract sent by terminal 110. Terminal 110 displays the corresponding transaction data. Exemplarily, server 120 can be a blockchain explorer server or a data parsing server. In one embodiment, terminal 110 can execute the smart contract-based processing method provided in this application independently. Specifically, terminal 110 receives the contract interaction interface file for the smart contract; parses the contract interaction interface file to obtain the parameter names of each event in the smart contract, and creates various event tables for the smart contract based on the parameter names of each event; terminal 110 obtains on-chain event log data generated after the execution of functions in the smart contract; terminal 110 parses the on-chain event log data based on the parameter names of the events to obtain transaction data, and terminal 110 stores the transaction data into the corresponding event table. The event table is used to display the corresponding transaction data in the blockchain explorer of terminal 110 when a transaction query request for the smart contract is received.

[0059] Terminal 110 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. Server 120 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0060] In one exemplary embodiment, such as Figure 2 As shown, a processing method based on smart contracts is provided, which can be applied to... Figure 1Taking server 120 as an example, the explanation includes the following steps S202 to S208. Wherein:

[0061] Step S202: Receive the contract interaction interface file for the smart contract.

[0062] Smart contracts can be either non-standard or standard. The Application Binary Interface (ABI) file is used to interact with the smart contract, defining its functions, events, and data structures.

[0063] In one embodiment, the server receives a contract interaction interface file about a smart contract from the terminal. This contract interaction interface file is created and uploaded to the terminal's blockchain explorer by the user who created the smart contract. This blockchain explorer is used to display blockchain data. After entering the blockchain explorer, any user can access the contract display page by clicking on the contract list. Figure 3 The image shown is a schematic diagram of a contract display page in one embodiment. Figure 3 The Contract Showcase Page 310 lists all smart contracts deployed on the blockchain and displays detailed information for each smart contract. This information includes the smart contract's level information, transaction history, and related parsing data. For example, it illustrates that the smart contract named Name1 has a contract address of Address1, a current version number of 1.0, a contract type of OTHER, a cumulative transaction count of 3, a creation user of USER1, and a creation time of Time1. Users can view each smart contract or add it to a plugin. Contract Showcase Page 310 further categorizes smart contracts into Token (Fungible Token) smart contracts, NFT (Non-Fungible Token) smart contracts, and data asset smart contracts.

[0064] In one embodiment, after obtaining the contract interaction interface file, the server executes step S204 after verifying that the format of the contract interaction interface file conforms to the contract definition requirements. Specifically, the step of verifying whether the format conforms to the contract definition requirements includes: verifying whether the contract interaction interface file is a JSON (a data exchange format) file, and verifying whether the type in the contract interaction interface file contains one or more of the following: event, function, and constructor.

[0065] In one embodiment, whether the smart contract is a standard smart contract or a non-standard smart contract, the data can be parsed by executing the following steps S204-S208.

[0066] In another embodiment, since standard smart contracts are built using common standards and their data structures are open-source, data parsing of standard smart contracts can be directly performed according to these common standards, without needing to use the contract interaction interface file. That is, to ensure the efficiency of smart contract parsing, before executing step S204, it can be verified whether the smart contract is a non-standard smart contract; if so, step S204 is executed. Therefore, in one embodiment, the method further includes: obtaining the contract runtime environment field from the raw transaction data obtained from executing the smart contract; based on the contract runtime environment field, detecting whether the smart contract is a standard smart contract according to the corresponding standard smart contract verification method; and, if the smart contract is a non-standard smart contract, executing the step of parsing the contract interaction interface file to obtain the parameter names of each event in the smart contract.

[0067] The raw transaction data consists of the fundamental data generated by smart contracts. This raw data records detailed information about the transaction, including a runtime type field. This runtime type indicates the smart contract's runtime environment; for example, it determines whether the smart contract runs on the Ethereum Virtual Machine (EVM) or a virtual container (DockerGo, a Docker container developed in Go). Standard smart contract verification methods are used to verify whether a smart contract is a standard smart contract. Different contract runtime environments use different standard smart contract verification methods.

[0068] In one embodiment, the server subscribes to on-chain data of the blockchain, obtains raw transaction data from the on-chain data, parses the contract runtime environment field in the raw transaction data, determines the smart contract's runtime environment based on the contract runtime environment field, and checks whether the smart contract is a standard smart contract based on the standard smart contract verification method corresponding to that runtime environment. If the smart contract is detected to be a non-standard smart contract, the server executes step S204.

[0069] In this embodiment, the smart contract's runtime environment is identified through the contract runtime environment field, and the smart contract verification method matching the runtime environment is used to accurately verify whether the smart contract is a standard smart contract.

[0070] In one embodiment, such as Figure 4The diagram illustrates a contract verification process in one embodiment. Based on the contract runtime environment field, and following the corresponding standard smart contract verification method, it checks whether the smart contract is a standard smart contract, including:

[0071] Step S402: If the contract runtime environment field indicates that the smart contract runs on the Ethereum Virtual Machine, based on the function declarations of multiple standard smart contracts and the function declaration of the smart contract, verify whether the smart contract belongs to the standard smart contracts running on the Ethereum Virtual Machine. The contract runtime environment required by multiple standard smart contracts is the Ethereum Virtual Machine.

[0072] Among them, multiple standard smart contracts refer to standard smart contracts that run in the Ethereum Virtual Machine.

[0073] In one embodiment, where the contract runtime environment field indicates that the smart contract runs on the Ethereum Virtual Machine (EVM), the server obtains the smart contract's source code, analyzes the source code, and matches the function signature to determine the smart contract's function declaration set, which includes at least one function declaration. The server then obtains the function declaration sets of multiple standard smart contracts running on the EVM. For each standard smart contract, the server compares its function declaration set with the smart contract's function declaration set to obtain a matching result. If a matching result indicates a match, the smart contract is determined to be a standard smart contract running on the EVM. If all matching results indicate a mismatch, the smart contract is determined to be a non-standard smart contract running on the EVM. For example, the server loads a predefined ABI rule base for standard smart contracts running on the EVM. The ABI rule base includes a set of function declarations for ERC20 contracts (Ethereum Request for Comments20) and ERC721 contracts (Ethereum Request for Comments721). The set of function declarations for ERC20 contracts includes function declarations such as transfer and approve, while the set of function declarations for ERC721 contracts includes function declarations such as mint and transferFrom. The server verifies whether the function declaration set of the smart contract contains function declarations such as transfer and approve, i.e., whether it matches the set of function declarations for ERC20 contracts, thus obtaining a matching result corresponding to the ERC20 contract. The server also verifies whether the function declaration set of the smart contract contains function declarations such as mint and transferFrom, i.e., whether it matches the set of function declarations for ERC721 contracts, thus obtaining a matching result corresponding to the ERC721 contract.

[0074] Step S404: If the contract runtime environment field indicates that the smart contract is running in a virtual container, call the software tool development kit of the blockchain on which the smart contract is deployed to verify whether the smart contract is a standard smart contract running in a virtual container.

[0075] The Software Development Kit (SDK) provides a Standards method. If the smart contract is written according to the standard smart contract (a standard smart contract that runs on a virtual contract), the specific contract type can be obtained through the Standards method; otherwise, the returned contract type is OTHER, indicating that it is a non-standard smart contract.

[0076] In one embodiment, such as Figure 5 The diagram illustrates a standard smart contract determination process in one embodiment. The specific steps are as follows: Step S502: The server subscribes to on-chain data, obtains the original transaction data from the blockchain's on-chain data, and parses the contract runtime environment field in the original transaction data. Step S504: The server determines whether the smart contract is running in the EVM based on the contract runtime environment field. If so, step S506 is executed, whereby the server loads the ABI rule base running in the EVM and parses the ABI rule base to determine the function declaration set for ERC20 contracts and the function declaration set for ERC721 contracts. Step S508: The server extracts function declarations from the smart contract's source code to obtain the smart contract's function declaration set. Step S510: The server performs function declaration matching based on the function declaration sets of the ERC20 contract, the ERC721 contract, and the smart contract to determine whether the smart contract is a standard smart contract. Specifically, the server matches the function declaration set of the smart contract with the function declaration sets of the ERC20 contract and the ERC721 contract, respectively, obtaining a first matching result for the ERC20 contract and a second matching result for the ERC721 contract. If the first matching result indicates a match and the second matching result indicates a mismatch, the smart contract is determined to be a standard smart contract, i.e., an ERC20 contract. If the first matching result indicates a mismatch and the second matching result indicates a match, the smart contract is determined to be a standard smart contract, i.e., an ERC721 contract. If both the first and second matching results indicate a mismatch, the smart contract is determined to be a non-standard smart contract. If the smart contract runs in DockerGo, i.e., not in the EVM, then step S512 is executed, where the server calls the blockchain's SDK (Software Development Kit). Step S514: Based on the SDK, a standard interface matching is performed to determine whether the smart contract is a standard smart contract. If a match is found with any standard smart contract running in DockerGo, the matched standard smart contract is returned, confirming the smart contract as a standard smart contract. If no match is found with any standard smart contract running in DockerGo (e.g., an IDA contract, a DID contract, a notarization contract, etc.), then OTHER is returned, confirming the smart contract as a non-standard smart contract.

[0077] In this embodiment, if the smart contract runs on the Ethereum Virtual Machine, function declaration matching is used to accurately identify whether the smart contract running on the Ethereum Virtual Machine is a standard smart contract. If the smart contract runs on a virtual container, the Direct Blockchain Software Development Kit accurately identifies whether the smart contract running on the virtual container is a standard smart contract. This achieves standard judgment of smart contracts in specific operating environments and improves the accuracy of standard judgment.

[0078] In one embodiment, the method further includes: if the smart contract is verified to be a standard smart contract, identifying the event topic from the transaction receipt; matching the corresponding parsing logic according to the event topic, the parsing logic including the event data structure of the corresponding event; and decoding the transaction data of the event according to the parameter name of the event in the event data structure.

[0079] Transaction receipts are the results of transactions executed on the blockchain. A transaction receipt includes an event topic, which identifies the event type. Each event has corresponding parsing logic, which defines the event data structure. This event data structure defines the data structure of the event data. For example, for event 1, it involves parameter fields such as the from address (source contract address), to address (target contract address), transaction amount, DID information, and asset changes. Therefore, the event data structure specifies that the first parameter field in the data structure of event 1 is the from address field, the second parameter field is the to address field, and so on.

[0080] In one embodiment, if the smart contract is determined to be a standard smart contract, the server detects relevant events on the blockchain and determines the event topic based on the transaction receipts of the identified events. The server obtains the mapping relationship between the event topic and the parsing logic, determines the corresponding parsing logic based on the identified event topic and the mapping relationship, and parses the parameters of the event names from the on-chain event log data based on the event parameter names in the event data structure of the corresponding parsing logic. Based on the parameters of each parameter name, the transaction data is determined. The on-chain event log data is the data generated after the smart contract triggers the event; the on-chain event log data is unparsed data.

[0081] It's important to note that standard smart contracts are built according to predefined specifications. This means that the event data structure for each event is constructed according to a standard, specifying the position and meaning of each parameter field within the event data structure. Therefore, for each event in a standard smart contract, the corresponding event data structure is pre-determined based on the standard smart contract's ABI file, and a mapping is established between the event and this event data structure. This way, if the event is applied within a standard smart contract, parsing the on-chain event log data for that event does not require traversing the ABI file to find the corresponding event data structure; a quick query can be performed directly based on this mapping relationship.

[0082] In one embodiment, for a standard smart contract, after executing a function within the standard smart contract and triggering an event, and after parsing the transaction data of that event using the above embodiment, when the terminal presents the contract display page, in response to the triggering operation of the standard smart contract on the contract display page, the terminal initiates a transaction query request regarding the smart contract and sends it to the server. The terminal receives the transaction data corresponding to the transaction query request sent by the server and displays the transaction data on the contract details page. Figure 6a The image shown is a schematic diagram of a contract details page in one embodiment. Figure 6a The contract details page 610 displays basic contract information, such as the contract name (Name2), contract address (Address2), contract type (CMNFA, a non-fungible asset protocol contract), and virtual machine type (runtime environment type) (Docker Go). The contract details page 610 also displays the parsed transaction data, such as the transfer history, holder list, and NFT overview. In response to the triggering operation of the transfer history control on the contract details page 610, an information display pop-up window 611 indicates that the triggering event time is Time3, the transaction ID (transaction identifier) ​​involved is id1, the contract method used to complete the transaction is MinBatch (minimum batch processing), the transfer address is Address2, and there are 4 NFTs. That is, at Time3, a transaction with id1 was executed, using the MinBatch method to transfer 4 non-fungible tokens to Address2. Similarly, as... Figure 6b The diagram shown is a schematic of a contract details page in another embodiment. In response to a triggering operation on the holder control in the contract details page 610, a list of holders of the non-fungible coin is displayed, sorted by the number of shares held. Figure 6b The text indicates that Address2's account address holds 5 non-fungible cryptocurrencies, representing 100% of the total. Similarly, as... Figure 6cAs shown, this is a schematic diagram of the contract details page in another embodiment. In response to the triggering operation of the NFT overview control in the contract details page 610, the details of five non-fungible tokens with token IDs (token IDs) 0-4 are displayed. The record shows that the owner of each non-fungible token is the user corresponding to Address2.

[0083] In this embodiment, when the smart contract is a standard smart contract, the corresponding parsing logic is matched using the identified event theme, thereby performing fast data parsing and improving the efficiency of data parsing.

[0084] Step S204: Parse the contract interaction interface file to obtain the parameter names of each event in the smart contract, and create an event table for the smart contract based on the parameter names of each event.

[0085] In this context, the parameter name of an event refers to the name of the relevant parameter, such as the source address or the destination address. The event table is the data table for the corresponding event, used to store the transaction data for that event. The smart contract's contract interaction interface file defines the event definition data for the relevant events. This event definition data includes the event data structure and event attribute description data. The event data structure specifies the data structure of the event data, such as the position of each parameter field in the event data and the parameter information for each parameter field. The parameter information includes at least the parameter name of the corresponding parameter. For example, the event data structure specifies that parameter field 1 precedes parameter field 2, and also records parameter information 1 for parameter field 1 and parameter information for parameter field 2. Parameter information 1 includes "indexed": true, "name": "issuerDID", indicating that the corresponding parameter field 1 is a parameter with the name issuerDID (source DID). "indexed" is the index field; when the indexed field is true, it indicates that a query index has been created for this parameter, facilitating querying of the parameter after parsing. Parameter information 2 includes "indexed": true, "name": "holderDID", indicating that the corresponding parameter field 2 is a parameter about the parameter name holderDID (target DID), and the index field of this parameter is true. Therefore, after obtaining the on-chain event log data, based on this event data structure, it can be known that the first parameter field in the on-chain event log data is a parameter named issuerDID (source DID), and the second parameter field is a parameter named holderDID (target DID), thus enabling data parsing. The event attribute description data specifies the data type as event, the event name, and the event type. For example, the event attribute description data includes: "name": "VcIssueLog", "describe": "Vc issuance event", "type": "event", indicating that the data type is event, the event name is VcIssueLog, and it is about a Vc issuance event. Therefore, based on the event definition data, not only can the events in the on-chain event log data be identified, but also the parameters involved in the event can be identified to construct transaction data.

[0086] In one embodiment, the server iterates through the data types in the smart contract's contract interaction interface file, queries the event definition data where the data type is the event type, and for each event definition data, determines the event name of the corresponding event from the event attribute description data in that event definition data, and determines that the event data structure in the event definition data is the event data structure of the event with that event name. Based on the event data structure of each event, the parameter name of the event is determined.

[0087] In one embodiment, parsing the contract interaction interface file to obtain the parameter names of each event in the smart contract includes: obtaining the event data structure of each event in the smart contract from the contract interaction interface file, wherein the event data structure includes each parameter name for the corresponding event; and obtaining the parameter names of each event in the smart contract based on the event data structure.

[0088] For example, the server iterates through the data types in the smart contract's contract interaction interface file, queries the event definition data where the data type is the event type, and for each event definition data, the server retrieves the corresponding event data structure. The server parses the event data structure to obtain at least one parameter name field, and determines the parameter name of the corresponding parameter from each parameter name field. For example, the event data structure specifies that parameter field 1 precedes parameter field 2, and also records parameter information 1 for parameter field 1 and parameter information for parameter field 2. In parameter information 1, "name": "holderDID" is the corresponding parameter name field; therefore, the parameter name can be parsed as holderDID.

[0089] In this embodiment, the event data structure of each event is automatically identified through the contract interaction interface file. Based on the event data structure, the parameter name of each event in the smart contract can be quickly identified, ensuring the efficiency of data parsing.

[0090] Step S206: Obtain on-chain event log data generated after the function in the smart contract is executed and an event is triggered.

[0091] The on-chain event log data consists of event data generated by triggering events after executing functions in a smart contract. This data includes transaction information. This on-chain event log data is unparsed. It's important to note that for non-standard smart contracts, these can be contracts without contract specifications (e.g., a custom transaction contract) or contracts written outside of contract specifications (e.g., user-added or modified functionality to a DID contract). Therefore, other users cannot understand the meaning of each field in the on-chain event log data, nor which fields are parameters, and thus cannot parse the transaction data.

[0092] In one embodiment, the server determines the event name of at least one event involved in executing the smart contract from the smart contract's contract interaction interface file, and based on the event name of at least one event, after detecting the current event, retrieves the on-chain event log data generated after triggering the event from the on-chain data.

[0093] In one embodiment, obtaining on-chain event log data generated after an event is triggered following the execution of a function in a smart contract includes: obtaining the event name of each event involved in the smart contract based on the contract interaction interface file; and obtaining on-chain event log data generated after the event is triggered from the original transaction data based on the event name of each event.

[0094] For example, the server iterates through the data types in the smart contract's contract interaction interface file, queries the event definition data where the data type is the event type, and for each event definition data, determines the event name from the event attribute description data within that event definition data. The server subscribes to on-chain data from the blockchain and retrieves the raw transaction data obtained from executing the smart contract from the on-chain data. This raw transaction data also includes the execution result of the smart contract. For each event name, the server queries the corresponding on-chain event log data from the execution result based on that event name.

[0095] In this embodiment, the event name of each event in the smart contract can be automatically identified based on the contract interaction interface file. In this way, the on-chain event log data generated after the corresponding event is triggered can be accurately found from the original transaction data according to the identified event name.

[0096] Step S208: Parse the on-chain event log data based on the event parameter name to obtain transaction data, and store the transaction data in the corresponding event table. The event table is used to display the corresponding transaction data when a transaction query request about the smart contract is received.

[0097] Transaction data is derived from on-chain event log data through data parsing. Each event has a corresponding event table, which stores the transaction data involved in that event. For example, for each event involved in each version of the smart contract, a corresponding event table is set up for that event in that version of the smart contract.

[0098] In one embodiment, for each parameter name of an event, the server parses the on-chain event log data according to the parameter name to obtain the parameter of that parameter name, generates transaction data based on the various parameters involved in the event, and stores the transaction data in the event table corresponding to the current smart contract version and the event.

[0099] In one embodiment, in response to selecting a target event name on the contract details page, the terminal generates a transaction query request carrying the target event name. The terminal sends the transaction query request to the server. Based on the target event name in the transaction query request, the server queries the corresponding event table, sends the transaction data from the event table to the terminal, and the terminal displays the transaction data on the contract details page. For example, the transaction query request may also include a target version. Based on the target event name, the server queries at least one event table corresponding to the target event name, filters the event table corresponding to the target version from the at least one event table, retrieves the transaction data from the filtered event table, and returns it to the terminal.

[0100] In one embodiment, parsing on-chain event log data based on the parameter names of events to obtain transaction data includes: determining the parameter fields corresponding to each parameter name in the on-chain event log data according to the event data structure of the events in the on-chain event log data and the contract interaction interface file; and determining the transaction data of the event based on the parameter fields corresponding to each parameter name.

[0101] For example, for each parameter name, based on the event data structure of the event, the server determines the position of the parameter field corresponding to the parameter name in the on-chain event log data, and based on that position, retrieves the parameter field from the on-chain event position data, and retrieves the parameter of the parameter name from that parameter field. The server determines the transaction data of the event based on the parameters of each parameter field. For example, the event data structure specifies that parameter field 1 precedes parameter field 2, and also records parameter information 1 for parameter field 1 and parameter information for parameter field 2. Parameter information 1 includes "indexed": true, "name": "issuerDID", and parameter information 2 includes "indexed": true, "name": "holderDID". The on-chain event log data is as follows: [

[0102] "DID:22abss",

[0103] "DID:23acxs",

[0104] ...

[0105] Based on the event data structure, the first parameter field corresponding to the source DID is located in the first position of the on-chain event log data, and the second parameter field corresponding to the target DID is located in the second position of the on-chain event log data. Therefore, the first parameter field in the on-chain event log data is the source DID, with the corresponding parameter DID:22abss; the second parameter field in the on-chain event log data is the target DID, with the corresponding parameter DID:23acxs.

[0106] In this embodiment, the event-based event data structure can determine the position of the parameter fields corresponding to each parameter name in the event in the on-chain event log data. Thus, the parameter fields in the on-chain event log data can be quickly identified, thereby achieving accurate and fast data parsing and improving data parsing efficiency.

[0107] In one embodiment, such as Figure 7a The diagram shown illustrates a contract details page in another embodiment. When the terminal displays the contract display page 310, in response to the selection operation of the smart contract named Name3 in the contract display page 310, the terminal displays the contract details page 610 for the smart contract Name3 and initiates a request to the server to obtain basic information of the smart contract. The server responds to the request by obtaining detailed information such as the contract status, contract address, current version, and virtual machine type (runtime environment type) of the smart contract, and determines whether the smart contract is a non-standard smart contract. Based on the detailed information and the determination result, the server generates basic information and returns it to the terminal. The terminal displays the basic information (such as...) Figure 7a The terminal displays the basic contract information (and, based on the judgment result in the basic information, indicates a non-standard smart contract). In response to the selection of the ABI information control in the information display pop-up window, the terminal displays the ABI parsing control 612 in the information display pop-up window on the contract details page 610. This ABI parsing control 612 is used to initiate data parsing of the smart contract based on the contract interaction interface file. In response to the triggering operation of the ABI parsing control 612, the terminal displays the account login pop-up window 613, which provides two login methods: password login and plugin login. In response to the input operation in the password input box for password login in the account login pop-up window 613, the terminal obtains the entered password, and based on the password query, determines whether the corresponding login account is the user account that created the smart contract. If so, a file upload pop-up window is displayed on the contract details page. Figure 7b The image shown is a schematic diagram of the contract details page in another embodiment. Figure 7b The file upload pop-up window 614 is used to obtain the contract interaction interface file in JSON format. In response to the triggering operation of the JSON file upload control in the file upload pop-up window 614, after selecting the corresponding contract interaction interface file for upload and clicking the submit operation, the terminal sends the uploaded contract interaction interface file to the server. This allows the server to execute the step of parsing the contract interaction interface file to obtain the parameter names of each event in the smart contract, thereby determining the transaction data of each event in the smart contract, and returning it to the terminal. In response to the triggering operation of the information display pop-up window, the terminal displays the received transaction data of each event in the information display pop-up window, such as... Figure 7c The image shown is a schematic diagram of a contract details page in another embodiment. For example, Figure 7c The text displays the transaction data corresponding to each event name (1-3) in the smart contract Name3. Selecting event name 1 displays the transaction data for the event corresponding to event name 1, such as... Figure 7c The transaction data in the middle is the transaction details of transaction ID2. For example, the transaction of transaction ID2 involves a chain account from Address4, the amount involved is M, the initiation time is Time5, and the specific content of the transaction is Text. In addition, the information display pop-up 611 also displays a search control 615 that can be searched. During the parsing of on-chain event log data, for each parameter name, if the index field of the parameter in the event data structure is true, then an index is created for that parameter. The server sends the parameter names that are allowed to be indexed to the terminal. The terminal generates a corresponding parameter input box based on the received parameter names, so that the parameter name can be entered in the parameter input box and then searched by clicking the search control. For example Figure 7c In the pop-up information display window, parameter input boxes 616 for the chain account "from" and "to" are shown. Responding to input operations in parameter input boxes 616, the system retrieves the input parameter names and then, in response to a trigger operation on the search control 615, performs a parameter search on the input parameter names. This allows for efficient parameter searches based on requirements, ensuring fast search response times.

[0108] In the aforementioned smart contract-based processing method, by parsing the contract interaction interface file of the smart contract, the parameter names of each event in the smart contract can be identified, and event tables for the smart contract can be created based on the parameter names of each event. Thus, after obtaining the on-chain event log data generated by events triggered after executing functions in the smart contract, the on-chain event log data can be automatically and accurately parsed based on the event parameter names to obtain transaction data. By storing the transaction data in the corresponding event tables, it can be ensured that the corresponding transaction data is displayed promptly when a transaction query request related to the smart contract is received. Throughout the data parsing process, the contract interaction interface file of the smart contract allows for flexible identification of the parameter names of each event in the smart contract, eliminating the need to parse the smart contract according to a fixed contract template. Therefore, based on the identified event parameter names, accurate data parsing of the on-chain event log data is possible, enhancing the flexibility of smart contract data parsing.

[0109] In one embodiment, the method further includes: obtaining the transaction read / write set after each transaction is executed from the original transaction data of the smart contract; identifying the cross-contract call relationship of the smart contract based on the transaction read / write set of each transaction; constructing a cross-contract call relationship graph of the smart contract based on the cross-contract call relationship; storing the cross-contract call relationship graph in a graph database, wherein the cross-contract call relationship graph is used to query the cross-contract call status of the smart contract when a call query request about the smart contract is received.

[0110] The transaction read / write set describes the collection of state data read, modified, or written during transaction execution. The cross-contract call relationship of a smart contract reflects other smart contracts called when executing a function of that smart contract. The cross-contract call relationship graph of a smart contract is used to query information about other smart contracts called by that smart contract. In one embodiment, the server subscribes to the raw transaction data of smart contracts in real time through the RPC (Remote Procedure Call) interface and message queue of the blockchain node, and obtains the transaction read / write set after each transaction execution from the raw transaction data. For each transaction read / write set, the server parses the set to determine the function executed for that transaction and the other smart contracts called by that function. The server associates the smart contracts with each other, using the association result as the cross-contract call relationship corresponding to that transaction. Based on the cross-contract call relationships corresponding to each transaction, a cross-contract call relationship graph of smart contracts is constructed. In one embodiment, the server stores the cross-contract call relationship graph and the contract identifier of the smart contract in a graph database. In one embodiment, when the server receives a call query request for a smart contract from the terminal, it retrieves the cross-contract call relationship graph corresponding to the smart contract from the graph database based on the contract identifier of the smart contract.

[0111] In this embodiment, the cross-contract call relationship of smart contracts is automatically identified through the transaction read-write set, thereby constructing a cross-contract call relationship graph of smart contracts. Based on this, the cross-contract call relationship graph can be used to understand the cross-contract call situation of the smart contract, which helps users understand the dependencies between contracts and further improves the traceability and transparency of contracts.

[0112] In one embodiment, the method further includes: constructing a contract call topology graph of the blockchain based on the cross-contract call relationship graph of each smart contract on the blockchain, the contract call topology graph being used to display when a blockchain call query request is received.

[0113] The contract call topology diagram illustrates the invocation of each smart contract and the invocation process. In one embodiment, the server determines the invocation frequency and called frequency of each smart contract based on the cross-contract call relationship graph. Based on the invocation and called frequencies of each smart contract, and the contract runtime environment type, the server dynamically generates the blockchain's contract call topology diagram. In one embodiment, the contract call topology diagram supports filtering operations based on filtering conditions to generate sub-graphs. Filtering conditions can include time range, contract type, etc.

[0114] In one embodiment, during the display of the contract call topology diagram, in response to a selection operation of a target smart contract in the diagram, the terminal switches to the target smart contract's contract details page. The details page then displays the target smart contract's call sub-topology diagram and called sub-topology diagram in an information pop-up window. The call sub-topology diagram reflects the target smart contract's calls to other smart contracts, while the called sub-topology diagram reflects which other smart contracts call the target smart contract. For example, ... Figure 8 The diagram illustrates a cross-contract call in one embodiment. In response to the selection of the target smart contract (Name3) in the contract call topology graph, the user is redirected to the contract details page 610. The information display pop-up window 611 on this page includes the call sub-topology graph of the target smart contract, such as the target smart contract calling other smart contracts with names Name1, NameN, etc. The information display pop-up window 611 also includes the called sub-topology graph of the target smart contract, such as other smart contracts with names Name8, Namex, etc., calling the target smart contract. The contract display pop-up window 611 can also display the smart contracts called by the smart contract's contract methods (functions). For example, when executing contract method 1, it needs to call the smart contracts with names Name3 and Name1; when executing contract method 2, it needs to call the smart contracts with names Name2, Name3, and NameN. Thus, by using the call sub-topology graph, the user can query in real time which other smart contracts the target smart contract calls, displaying the call records of the target smart contract to other smart contracts, helping the user understand the dependencies of the target smart contract. The called sub-topology graph allows users to query in real time which other smart contracts have called the target smart contract, displaying the historical records of other smart contracts calling the target smart contract, and helping users trace the interaction path of the target smart contract.

[0115] In this embodiment, by constructing a contract call topology diagram that reflects the contract call situation on the entire blockchain through the cross-contract call relationship graph of each smart contract on the blockchain, it is possible to make users understand the dependencies between contracts on the entire blockchain, effectively enhance the transparency and traceability of blockchain data, and improve users' comprehensive understanding of the contract execution process.

[0116] In one embodiment, based on the transaction read / write set of each transaction, the cross-contract call relationship of the smart contract is identified, including: for each transaction, parsing the transaction read / write set; if the transaction read / write set records other contract addresses besides the smart contract's contract address, then it is determined that the smart contract has called other smart contracts corresponding to other contract addresses; creating a call record of the smart contract calling other smart contracts; and storing the call record and the transaction identifier of the transaction in the smart contract's cross-contract call table, which is used to record the cross-contract call relationship involved in transactions generated based on the smart contract.

[0117] For example, for each transaction, the server parses the transaction read / write set to obtain the contract addresses recorded in the transaction read / write set. If no other contract addresses are included in the recorded contract addresses, it means that no other smart contracts were invoked when the transaction was executed. If other contract addresses besides the smart contract's address are included in the recorded contract addresses, the server determines that the smart contract invoked other smart contracts corresponding to those other contract addresses, and the server creates a call record for the smart contract invoking other smart contracts. The server stores this call record and the transaction identifier of the transaction in the smart contract's cross-contract call table, which is used to record the cross-contract call relationships involved in transactions generated based on smart contracts.

[0118] In this embodiment, by parsing the transaction read / write set of a transaction, it is possible to efficiently and accurately determine whether the smart contract calls other smart contracts when the transaction is executed. When it is determined that there is a call, a smart contract is created to investigate the call records of other smart contracts. By storing the call records and the transaction identifier of the transaction in the cross-contract call table, it is easy to quickly query the cross-contract call relationships involved in the transaction generated by the smart contract.

[0119] In a specific embodiment, the implementation is described using a server as the implementing entity, and the specific steps are as follows: Stage 1: The server constructs the event table of the smart contract. For example... Figure 9 The diagram shown illustrates the event table generation steps in one embodiment. (Refer to...) Figure 9 The first phase is explained in detail in steps S902-S914 below:

[0120] Step S902: The server obtains the contract interaction interface file.

[0121] Optionally, when displaying the contract display page, in response to the selection of any smart contract on the contract display page, the terminal displays the contract details page of the selected smart contract. In response to the triggering of the file upload control on the contract details page, the terminal obtains the contract interaction interface file of the smart contract. The terminal sends the contract interaction interface file of the smart contract to the server.

[0122] For example, in response to selecting any smart contract on the contract display page, the terminal initiates a request to the server to obtain basic information about the smart contract. The server responds to this request by acquiring detailed information such as the smart contract's state, address, current version, and virtual machine type (runtime environment type), and determines whether the smart contract is a non-standard smart contract. Based on the detailed information and the determination result, it generates basic information and returns it to the terminal. The terminal displays the basic information, and if the determination result based on the basic information indicates a non-standard smart contract, the terminal always displays a file upload control on the contract details page of the selected smart contract.

[0123] For example, the contract runtime environment field is obtained from the raw transaction data obtained by executing the smart contract. If the contract runtime environment field indicates that the smart contract runs on the Ethereum Virtual Machine (EVM), the smart contract is verified to be a standard smart contract running on the EVM based on the function declarations of multiple standard smart contracts and the function declaration of this smart contract. All standard smart contracts require the EVM as their runtime environment. If the contract runtime environment field indicates that the smart contract runs on a virtual container, the software toolkit (SDK) of the blockchain on which the smart contract is deployed is invoked to verify whether the smart contract is a standard smart contract running on the virtual container. If the smart contract is a non-standard smart contract, the step of parsing the contract interaction interface file is performed to obtain the parameter names of each event in the smart contract.

[0124] Step S904: The server determines whether the file format verification passes. If yes, proceed to steps S906 to S912; otherwise, proceed to step S914.

[0125] For example, the server verifies whether the contract interaction interface file is a JSON file (a data exchange format), and verifies whether the type in the contract interaction interface file contains one or more of the following: event, function, and constructor, to obtain the file format verification result. If it is a JSON file and the type in the contract interaction interface file contains one or more of the following: event, function, and constructor, the file format verification result is determined to be successful, and step S906 is executed.

[0126] Step S906: The server extracts the event name and index fields based on the contract interaction interface file and identifies the contract version identifier. The contract version identifier represents the current smart contract version.

[0127] Step S908: The server dynamically generates the table structure of the event table.

[0128] Step S910: The server creates an event table based on the table structure and event name, and maps the event table to the contract version identifier.

[0129] Step S912: The server creates an index based on the indexed fields and uses a data initialization tool to parse historical data.

[0130] Optionally, the server verifies the parameters that need to be indexed based on the index field in the event data structure of the events in the contract interaction interface file, and creates indexes for the parameters that need to be indexed. The server obtains historical data from the historical period before uploading the contract interaction interface file. This historical data consists of historical on-chain event log data generated by the smart contract due to triggered events during the historical period, and the server uses a data initialization tool to parse the historical on-chain event log data.

[0131] Step S914: The server reports a file error.

[0132] Phase 2: The server performs data parsing. For example... Figure 10 The diagram shown illustrates a data parsing step in one embodiment. (Refer to...) Figure 10 The second phase will be explained as follows: If the smart contract is a non-standard smart contract, then the following steps S1002-S1022 will be executed:

[0133] Step S1002: The server obtains the original transaction data of the smart contract.

[0134] Step S1004: The server detects events in the smart contract.

[0135] Step S1006: The server matches the event table corresponding to the contract version of the smart contract. If the match is successful, that is, the event table corresponding to the contract version is matched, then proceed to steps S1008-S1020 below; if the match fails, then proceed to step S1022.

[0136] Step S1008: The server parses the contract interaction interface file to determine the parameter names of the events.

[0137] Optionally, the server obtains the event data structure of each event in the smart contract from the contract interaction interface file. The event data structure includes the parameter name of each corresponding event. Based on the event data structure, the parameter name of each event in the smart contract is obtained.

[0138] Step S1010: The server obtains the on-chain event log data generated when the event was triggered.

[0139] Optionally, the server retrieves on-chain event log data generated after the event is triggered from the raw transaction data.

[0140] Step S1012: The server parses the event log data on the chain using the event parameter name.

[0141] Optionally, the server determines the parameter fields corresponding to each parameter name in the on-chain event log data based on the event data structure of the events in the contract interaction interface file; and determines the transaction data of the event based on the parameter fields corresponding to each parameter name.

[0142] Step S1014: The server writes the parsed transaction data into the event table of successful matches.

[0143] Step S1016: After receiving a transaction query request for the smart contract, the server queries the corresponding event table;

[0144] Step S1018: If the transaction query request is sent by the user's front end, the server will send the queried event table to the user's front end for data display.

[0145] Step S1020: If the transaction query request is sent by the data analysis platform, the server will send the queried event table to the data analysis platform for data analysis.

[0146] Step S1022: The server generates and stores an exception log for the matching failure.

[0147] The above describes the parsing process for a non-standard smart contract. If the smart contract is a standard smart contract, the server identifies the event topic from the transaction receipt; based on the event topic, it matches the corresponding parsing logic, which includes the event data structure of the corresponding event; and decodes the transaction data of the event based on the parameter names of the event in the event data structure.

[0148] In the third stage, the server constructs the blockchain's contract call topology graph. For example... Figure 11 The diagram shown illustrates the contract call topology graph construction steps in one embodiment. (Refer to...) Figure 11 The third stage will be explained in detail in steps S1102-S1112 below:

[0149] Step S1102: The server obtains the original transaction data of the smart contract.

[0150] Step S1104: The server obtains the transaction read / write set for each transaction from the original transaction data.

[0151] Step S1106: The server parses each transaction read / write set to determine the cross-contract call relationship of the smart contract.

[0152] Optionally, the server obtains the transaction read / write set after each transaction execution from the original transaction data of the smart contract; for each transaction, it parses the transaction read / write set; if the transaction read / write set records other contract addresses besides the smart contract's contract address, it determines that the smart contract has called other smart contracts corresponding to those other contract addresses; it creates a call record for the smart contract calling other smart contracts; and it stores the call record and the transaction identifier of the transaction in the smart contract's cross-contract call table, which is used to record the cross-contract call relationships involved in transactions generated based on the smart contract.

[0153] Step S1108: The server generates a cross-contract call relationship graph of smart contracts based on the cross-contract call relationship of smart contracts.

[0154] Step S1110: The server stores the cross-contract call relationship graph in the graph database.

[0155] Among them, the cross-contract call relationship graph is used to query the cross-contract call status of a smart contract when a call query request about a smart contract is received.

[0156] Step S1112: The server constructs a contract call topology graph based on the cross-contract call relationship graph of various smart contracts. Thus, when a user's front-end blockchain call query request is received, the server returns the contract call topology graph to the user's front-end for display; or, when an audit request is received from a terminal, the server returns the contract call topology graph to the terminal, enabling the terminal to perform security audits based on the contract call topology graph and generate a security audit report. Alternatively, when a dependency analysis request is received from a terminal, the server returns the contract call topology graph to the terminal, enabling the terminal to perform dependency analysis based on the contract call topology graph.

[0157] In this embodiment, by parsing the contract interaction interface file of the smart contract, the parameter names of each event in the smart contract can be identified, and event tables for the smart contract can be created based on the parameter names of each event. Thus, after obtaining the on-chain event log data generated by events triggered after executing functions in the smart contract, the on-chain event log data can be automatically and accurately parsed based on the event parameter names to obtain transaction data. By storing the transaction data in the corresponding event tables, it can be ensured that the corresponding transaction data is displayed promptly when a transaction query request related to the smart contract is received. Throughout the data parsing process, the contract interaction interface file of the smart contract allows for flexible identification of the parameter names of each event in the smart contract, eliminating the need to parse the smart contract according to a fixed contract template. Therefore, based on the identified event parameter names, accurate data parsing of the on-chain event log data is possible, enhancing the flexibility of smart contract data parsing. Furthermore, it effectively avoids the complexity of processing each smart contract detail individually and improves the overall system's compatibility and scalability with standard contracts.

[0158] The smart contract-based processing method provided in this application can be applied to scenarios involving the analysis of smart contract transactions and the detection of abnormal transactions in the blockchain. For example, in the scenario of analyzing smart contract transactions, if the smart contract is non-standard, the server receives the contract interaction interface file uploaded by the terminal; parses the contract interaction interface file to obtain the parameter names of each event in the smart contract, and creates event tables for each event based on the parameter names; obtains the on-chain event log data generated after the execution of functions in the smart contract; parses the on-chain event log data based on the event parameter names to obtain transaction data, and stores the transaction data in the corresponding event table. When receiving a transaction query request for the smart contract from the terminal, the server retrieves the transaction data from the event table and returns it to the terminal. The terminal then displays and analyzes the retrieved transaction data.

[0159] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0160] Based on the same inventive concept, this application also provides a smart contract-based processing apparatus for implementing the aforementioned smart contract-based processing method. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more embodiments of the smart contract-based processing apparatus provided below can be found in the limitations of the smart contract-based processing method described above, and will not be repeated here.

[0161] In one exemplary embodiment, such as Figure 12 As shown, a smart contract-based processing device 1200 is provided, including: a file receiving module 1202, an event table generation module 1204, a data generation module 1206, and a data parsing module 1208, wherein:

[0162] The file receiving module 1202 is used to receive contract interaction interface files related to smart contracts;

[0163] The event table generation module 1204 is used to parse the contract interaction interface file, obtain the parameter names of each event in the smart contract, and create various event tables for the smart contract based on the parameter names of each event.

[0164] Data generation module 1206 is used to obtain on-chain event log data generated after the execution of functions in a smart contract.

[0165] The data parsing module 1208 is used to parse on-chain event log data based on the parameter name of the event to obtain transaction data, and store the transaction data into the corresponding event table. The event table is used to display the corresponding transaction data when a transaction query request about a smart contract is received.

[0166] In one embodiment, the device further includes a contract detection module, which is used to obtain the contract runtime environment field from the raw transaction data obtained by executing the smart contract; based on the contract runtime environment field, detect whether the smart contract is a standard smart contract according to the corresponding standard smart contract verification method; and if the smart contract is a non-standard smart contract, execute the step of parsing the contract interaction interface file to obtain the parameter names of each event in the smart contract.

[0167] In one embodiment, the contract detection module is used to verify whether a smart contract is a standard smart contract running in the Ethereum Virtual Machine (EVM) based on the function declarations of multiple standard smart contracts and the function declaration of the smart contract, when the contract runtime environment field indicates that the smart contract is running in the Ethereum Virtual Machine (EVM). The multiple standard smart contracts all require the EVM as their runtime environment. When the contract runtime environment field indicates that the smart contract is running in a virtual container, the module calls the software development kit (SDK) of the blockchain on which the smart contract is deployed to verify whether the smart contract is a standard smart contract running in the virtual container.

[0168] In one embodiment, the data parsing module 1208 is further configured to, when verifying that the smart contract belongs to a standard smart contract, identify the event topic from the transaction receipt; match the corresponding parsing logic according to the event topic, the parsing logic including the event data structure of the corresponding event; and decode the transaction data of the event according to the parameter name of the event in the event data structure.

[0169] In one embodiment, the event table generation module 1204 is used to obtain the event data structure of each event in the smart contract from the contract interaction interface file. The event data structure includes the parameter name of each corresponding event. Based on the event data structure, the parameter name of each event in the smart contract is obtained.

[0170] In one embodiment, the data generation module 1206 is used to obtain the event name of each event involved in the smart contract based on the contract interaction interface file; and to obtain on-chain event log data generated after the event is triggered from the original transaction data based on the event name of each event.

[0171] In one embodiment, the data parsing module 1208 is used to determine the parameter fields corresponding to each parameter name in the on-chain event log data based on the event data structure of the events in the contract interaction interface file; and to determine the transaction data of the event based on the parameter fields corresponding to each parameter name.

[0172] In one embodiment, the device further includes a call relationship parsing module, used to obtain the transaction read / write set after each transaction execution from the original transaction data of the smart contract; identify the cross-contract call relationship of the smart contract based on the transaction read / write set of each transaction; construct a cross-contract call relationship graph of the smart contract based on the cross-contract call relationship; and store the cross-contract call relationship graph in a graph database, the cross-contract call relationship graph being used to query the cross-contract call status of the smart contract when a call query request about the smart contract is received.

[0173] In one embodiment, the call relationship resolution module is used to construct a blockchain contract call topology graph based on the cross-contract call relationship graph of each smart contract on the blockchain. The contract call topology graph is used to display when a blockchain call query request is received.

[0174] In one embodiment, the call relationship resolution module is used to parse the transaction read-write set for each transaction; if the transaction read-write set records other contract addresses besides the smart contract's contract address, it is determined that the smart contract has called other smart contracts corresponding to those other contract addresses; a call record of the smart contract calling other smart contracts is created; the call record and the transaction identifier of the transaction are stored in the smart contract's cross-contract call table, which is used to record the cross-contract call relationships involved in transactions generated based on smart contracts.

[0175] The modules in the aforementioned smart contract-based processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the operations corresponding to each module.

[0176] In one exemplary embodiment, a computer device is provided, which may be a server or a terminal, and its internal structure diagram may be as follows. Figure 13 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media to run. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a smart contract-based processing method.

[0177] Those skilled in the art will understand that Figure 13 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0178] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0179] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0180] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0181] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0182] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0183] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0184] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A processing method based on smart contracts, characterized in that, The method includes: Receive the contract interaction interface file regarding smart contracts; Parse the contract interaction interface file to obtain the parameter names of each event in the smart contract, and create an event table for the smart contract based on the parameter names of each event. Obtain on-chain event log data generated after an event is triggered following the execution of a function in the smart contract; The on-chain event log data is parsed based on the parameter name of the event to obtain transaction data, and the transaction data is stored in the corresponding event table. The event table is used to display the corresponding transaction data when a transaction query request about the smart contract is received.

2. The method according to claim 1, characterized in that, The method further includes: Obtain the contract runtime environment field from the raw transaction data obtained by executing the smart contract; Based on the contract runtime environment field, the system checks whether the smart contract is a standard smart contract according to the corresponding standard smart contract verification method. In the case that the smart contract is a non-standard smart contract, the step of parsing the contract interaction interface file to obtain the parameter names of each event in the smart contract is executed.

3. The method according to claim 2, characterized in that, The step of detecting whether the smart contract is a standard smart contract based on the contract runtime environment field and according to the corresponding standard smart contract verification method includes: When the contract runtime environment field indicates that the smart contract runs on the Ethereum Virtual Machine, based on the function declarations of multiple standard smart contracts and the function declaration of the smart contract, it is verified whether the smart contract belongs to the standard smart contract running on the Ethereum Virtual Machine. The contract runtime environment required by the multiple standard smart contracts is the Ethereum Virtual Machine. If the contract runtime environment field indicates that the smart contract is running in a virtual container, the software tool development kit of the blockchain on which the smart contract is deployed is invoked to verify whether the smart contract is a standard smart contract running in a virtual container.

4. The method according to claim 2, characterized in that, The method further includes: If the smart contract is verified to be a standard smart contract, the event subject is identified from the transaction receipt; Based on the event topic, the corresponding parsing logic is matched, and the parsing logic includes the event data structure of the corresponding event; The transaction data of the event is decoded based on the parameter name of the event in the event data structure.

5. The method according to claim 1, characterized in that, The process of parsing the contract interaction interface file yields the parameter names of each event in the smart contract, including: Obtain the event data structure of each event in the smart contract from the contract interaction interface file. The event data structure includes the parameter name for each corresponding event. Based on the event data structure, the parameter names of each event in the smart contract are obtained.

6. The method according to claim 1, characterized in that, The acquisition of on-chain event log data generated after the execution of a function in the smart contract includes: Based on the contract interaction interface file, obtain the event name of each event involved in the smart contract; Based on the event name of each event, retrieve the on-chain event log data generated after the event is triggered from the original transaction data.

7. The method according to claim 1, characterized in that, The on-chain event log data is parsed based on the parameter name of the event to obtain transaction data, including: Based on the on-chain event log data and the event data structure of the events in the contract interaction interface file, determine the parameter fields corresponding to each parameter name in the on-chain event log data; The transaction data for the event is determined based on the parameter fields corresponding to each parameter name.

8. The method according to claim 1, characterized in that, The method further includes: Obtain the transaction read / write set after each transaction is executed from the original transaction data of the smart contract; Based on the transaction read / write set of each transaction, the cross-contract call relationship of the smart contract is identified; Based on the cross-contract call relationship, construct the cross-contract call relationship graph of the smart contract; The cross-contract call relationship graph is stored in a graph database. The cross-contract call relationship graph is used to query the cross-contract call status of the smart contract when a call query request about the smart contract is received.

9. The method according to claim 8, characterized in that, The method further includes: Based on the cross-contract call relationship graph of each smart contract on the blockchain, a contract call topology graph of the blockchain is constructed. The contract call topology graph is used to display when a blockchain call query request is received.

10. The method according to claim 8, characterized in that, The transaction read / write set based on each transaction identifies the cross-contract call relationships of the smart contract, including: For each transaction, parse the transaction read / write set; If the transaction read / write set records contract addresses other than the smart contract's contract address, then it is determined that the smart contract called other smart contracts corresponding to those other contract addresses. Create a call record for the smart contract calling the other smart contracts; The call record and the transaction identifier of the transaction are stored in the cross-contract call table of the smart contract. The cross-contract call table is used to record the cross-contract call relationships involved in the transactions generated based on the smart contract.

11. A processing device based on smart contracts, characterized in that, The device includes: The file receiving module is used to receive contract interaction interface files related to smart contracts; The event table generation module is used to parse the contract interaction interface file, obtain the parameter names of each event in the smart contract, and create various event tables about the smart contract based on the parameter names of each event. The data generation module is used to acquire on-chain event log data generated after the execution of a function in the smart contract. The data parsing module is used to parse the on-chain event log data based on the parameter name of the event to obtain transaction data, and store the transaction data in the corresponding event table. The event table is used to display the corresponding transaction data when a transaction query request about the smart contract is received.

12. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 10.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 10.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 10.

Images