Nft contract identification method and device and related equipment

Abstract

The application provides an NFT contract identification method and device and related equipment. The method comprises the following steps: obtaining transaction information; determining the contract address of the transaction information, and judging whether the transaction information belongs to a contract transaction according to the contract address; in response to the transaction information belonging to the contract transaction, obtaining log information of the transaction information, determining whether a signature field of the log information conforms to a specific type; in response to the signature field conforming to the specific type, determining whether a first source field of the log information conforms to a set condition; and in response to the first source field conforming to the set condition, determining that a transaction corresponding to the transaction information is an NFT contract transaction.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data recognition, and in particular to an NFT contract identification method and device and related equipment. BACKGROUND

[0002] There are two main NFT contract identification methods at present, one is to judge the interface of the smart contract, and the other is to judge the interface of the smart contract and then judge the metadata storage.

[0003] However, the first method can only identify typical contracts; the second method is optimized on the basis of the first method, but this method does not store in a third-party storage center, such as ipfs. Therefore, both methods have the defect of being unable to comprehensively identify NFT contracts. SUMMARY

[0004] Therefore, the present application provides an NFT contract identification method, device and related equipment to solve or partially solve the above problems.

[0005] To achieve the above purpose, the present application provides an NFT contract identification method, comprising:

[0006] obtaining transaction information;

[0007] determining the contract address of the transaction information, and judging whether the transaction information belongs to a contract transaction according to the contract address;

[0008] in response to the transaction information belonging to the contract transaction, obtaining log information of the transaction information, and determining whether a signature field of the log information conforms to a specific type;

[0009] in response to the signature field conforming to the specific type, determining whether a first source field of the log information conforms to a set condition;

[0010] in response to the first source field conforming to the set condition, determining that the transaction information corresponds to an NFT contract transaction.

[0011] In some embodiments, the transaction information is obtained by:

[0012] connecting a blockchain network using a remote call protocol;

[0013] determining the block information of the blockchain network by returning a specified block instruction;

[0014] determining the transaction information in the block corresponding to the block information by returning a specified transaction object instruction.

[0015] In some embodiments, the determining the contract address of the transaction information comprises:

[0016] determining a second source field and an identification code field of the transaction information;

[0017] recursively length prefix encoding the second source field and the identification code field to determine a serialization format result of the second source field;

[0018] decoding the serialization format result by a keccak algorithm to obtain the contract address.

[0019] In some embodiments, the determining whether the transaction information belongs to the contract transaction according to the contract address comprises:

[0020] determining whether a receiver field of a transaction field of the contract address is empty;

[0021] in response to the receiver field being empty, determining a return value of the contract address by returning a specified address code instruction, and determining whether a length of the return value reaches a set length;

[0022] in response to the length of the return value reaching the set length, determining that the transaction information belongs to the contract transaction.

[0023] In some embodiments, the signature field at least includes a topic0 field; and the specific type at least includes a Transfer type and a SafeTransferFrom type.

[0024] The determining whether the signature field of the log information conforms to the specific type comprises:

[0025] determining whether a type of the topic0 field belongs to one of the Transfer type and the SafeTransferFrom type.

[0026] In some embodiments, before the obtaining the transaction information, the method further comprises:

[0027] establishing and merging a Geth client and a Prysm client to form a network node;

[0028] determining whether the network node can normally synchronize data by checking a block synchronization instruction;

[0029] in response to the network node being able to normally synchronize data, obtaining and running a monitoring process to monitor a data synchronization state of the network node.

[0030] In some embodiments, after determining that the transaction corresponding to the transaction information is an NFT contract transaction, the method further comprises:

[0031] interface identification on the transaction corresponding to the transaction information;

[0032] in response to the identified interface of the transaction corresponding to the transaction information belonging to a set interface, classifying the transaction corresponding to the transaction information according to the identified interface type;

[0033] in response to the identified interface of the transaction corresponding to the transaction information not belonging to the set interface, classifying the transaction corresponding to the transaction information as other types.

[0034] Based on the same concept, the present application also provides an NFT contract identification device, comprising:

[0035] an acquisition module for acquiring transaction information;

[0036] a first determination module for determining the contract address of the transaction information and determining whether the transaction information belongs to a contract transaction according to the contract address;

[0037] a second determination module for, in response to the transaction information belonging to the contract transaction, acquiring log information of the transaction information and determining whether a signature field of the log information conforms to a specific type;

[0038] a third determination module for, in response to the signature field conforming to the specific type, determining whether a first source field of the log information conforms to a set condition;

[0039] a fourth determination module for, in response to the first source field conforming to the set condition, determining that the transaction corresponding to the transaction information is an NFT contract transaction.

[0040] Based on the same concept, the present application also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method according to any one of the above.

[0041] Based on the same concept, the present application also provides a non-transitory computer readable storage medium, which stores computer instructions for causing a computer to implement the method according to any one of the above.

[0042] It can be seen from the above that the NFT contract identification method, device and related equipment provided by the application include: obtaining transaction information; determining the contract address of the transaction information, and judging whether the transaction information belongs to a contract transaction according to the contract address; in response to the transaction information belonging to the contract transaction, obtaining log information of the transaction information, determining whether a signature field of the log information meets a specific type; in response to the signature field meeting the specific type, determining whether a first source field of the log information meets a set condition; and in response to the first source field meeting the set condition, determining that a transaction corresponding to the transaction information is an NFT contract transaction. The application obtains the log information of the transaction information belonging to the contract transaction, and determines the signature field and the source field of the log information, so as to determine whether it is an NFT contract transaction. Since the most original appearance of the log information of any form of NFT contract transaction meets a specific form, the accurate identification of the NFT contract transaction can be more comprehensively realized by identifying the signature field and the source field of the log information, the identification accuracy and credibility are improved, and the user experience is improved. BRIEF DESCRIPTION OF DRAWINGS

[0043] In order to more clearly illustrate the technical solutions in the embodiments of the application or the related art, the drawings needed to be used in the embodiments or the related art description will be briefly introduced. Obviously, the drawings in the following description are only embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor.

[0044] Figure 1 The structural schematic diagram of the exemplary system provided by the embodiments of the application.

[0045] Figure 2 The flowchart of the exemplary method provided by the embodiments of the application.

[0046] Figure 3 The flowchart of the exemplary method provided by the embodiments of the application for establishing a data synchronization node.

[0047] Figure 4 The flowchart of the exemplary method provided by the embodiments of the application for contract classification.

[0048] Figure 5 The working flowchart of the foundry transaction identification unit of the exemplary system provided by the embodiments of the application.

[0049] Figure 6 The working flowchart of the contract classification unit of the exemplary system provided by the embodiments of the application.

[0050] Figure 7 The structural schematic diagram of the exemplary device provided by the embodiments of the application.

[0051] Figure 8 An electronic device structure schematic diagram is provided for the embodiments of the present application. DETAILED DESCRIPTION

[0052] For the purpose of making the purpose, technical scheme and advantages of the present application more clear, the present application is further described in detail below with reference to the embodiments and the accompanying drawings.

[0053] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present application should be understood as the common meanings understood by those with ordinary skills in the art to which the embodiments of the present application belong. The terms “first”, “second” and similar terms used in the embodiments of the present application do not represent any order, number or importance, but are only used to distinguish different components. The terms “include”, “contain” and similar terms mean that the elements, objects or method steps listed before the terms cover the elements, objects or method steps listed after the terms and their equivalents, and do not exclude other elements, objects or method steps. The terms “connect” or “connected” and similar terms are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. The terms “up”, “down”, “left”, “right” and the like are only used to represent relative positional relationships, and when the absolute positions of the described objects change, the relative positional relationships may also change accordingly.

[0054] As described in the background section, Non Fungible Token (NFT) is a type of cryptocurrency on the blockchain that represents the ownership of a unique item. NFTs can represent both real assets (such as a piece of land) and digital assets (such as a rare virtual card). NFTs were first proposed in Ethereum Improvement Proposal (EIP) 721 and were improved in EIP-1155. Blockchain is the standard medium for displaying and trading NFT assets, providing a secure and distributed environment that makes these assets transparent and available for trading worldwide. Today's NFTs exist in two main standards: ERC-721 and ERC-1155, which complete most transactions in the NFT ecosystem market. During the minting process of NFTs, due to the transformation of the metadata storage link attached to the on-chain, buyers may find that the metadata of the NFT is inconsistent after completing the transaction, increasing the risk of fraud. This phenomenon not only poses a potential threat to individual buyers, but also presents new challenges for regulators. However, using traditional regulatory methods is difficult to effectively and timely identify and address these issues. To address this phenomenon, new regulatory methods need to be explored to adapt to the rapidly developing digital field. Ethereum's transaction behavior can uniquely identify the blockchain, and by tracking transaction records, various behaviors of NFTs can be understood, including creation, transfer, and destruction. Similar to the Bitcoin network, which uses "mining" (or "minting") to add new blocks with transaction information to the blockchain, NFT networks use "minting" to write Token ID, metadata or metadata URL, digital asset file URL, and other data into new blocks of the blockchain, achieving so-called "data on-chain." The life cycle of NFTs is divided into several stages: creating works, minting NFTs, owning and selling, changing property rights, displaying and exhibiting, managing and preserving, and finally destroying. Minting transactions are crucial in the NFT dissemination market and play a key role in the life cycle of NFTs. Minting transactions are not just the initial creation process of digital assets, but also a crucial step in ensuring the unique identity of each NFT. Through minting transactions, each NFT obtains a unique identifier, making it non-fungible and unique on the blockchain.

[0055] For the two main identification methods currently in use, the first method is to compare the interfaces of the smart contract to determine whether it is an ERC-721 or ERC-1155 standard. The other method is to obtain the source code of the smart contract and abstract the metadata storage function into a syntax tree, which is then converted into a feature vector for classification using machine learning for more in-depth comparison and identification.

[0056] The first method, identifying NFTs through interface standards, is not comprehensive because some NFT contracts do not implement this interface, although their transaction behavior belongs to minting transactions and there are transaction circulation behaviors of NFTs. Therefore, the NFT contracts identified by relying solely on this method are incomplete. For example, the current mainstream NFT platforms, such as Opensea and NFTscan, check whether the contract implements the ERC-721 or ERC-1155 standard interface to determine whether the contract is an NFT contract. Through the ERC-165 standard, a smart contract can declare the interfaces it supports for other contracts to check. Therefore, the ERC-165 can be used to check whether a smart contract supports the ERC-721 or ERC-1155 interface. The ERC-165 interface contract only declares a supportsInterface function, which inputs the interface id (type bytes4) to be queried. If the contract implements the interface id, it returns true; otherwise, it returns false. The ERC-721 contract implements the supportsInterface function of the ERC-165 interface contract, and returns true when querying 0x80ac58cd (ERC-721 interface id). The ERC-1155 contract returns true when using 0xd9b67a26 to interact with the contract, which proves that it is an ERC-1155 contract, otherwise it is not. Through this, the identification of NFT contracts can be achieved. However, there is still a contract that returns false to both interface ids, but analysis of its behavior does exist a step of minting transactions. This contract does not conform to the complete ERC-721 or ERC-1155 standard, but there is a step of minting transactions in the life cycle of NFTs, which can be judged as an NFT contract. At the same time, there is also a situation that the ERC-721 or ERC-1155 contract does not use the ERC-165 contract interface, so using this interface to judge will be wrong, and there is no way to identify it as an NFT contract.

[0057] The second type of method has certain limitations by obtaining the source code of the smart contract, converting it into a syntax tree, and further determining whether the NFT interface is ERC-721 or ERC-1155, and whether the metadata implementation adopts the tokenURI or uri function. In the process of training, this method determines the storage method of the metadata after determining the interface, which is an improvement over the first method. However, even if the syntax tree meets the two conditions, it cannot be determined whether the tokenURI or uri function exists. The storage function of the metadata can be customized, or even stored directly on the chain, resulting in a contract that meets the ERC-721 or ERC-1155 standard but uses other methods to store metadata. This method of identifying NFT contracts is essentially based on existing NFT standards, and there are also defects in the number of incomplete standards.

[0058] It can be seen that the first method is to identify NFT according to the interface implementation, but only typical contracts can be distinguished. The second type of method is optimized based on the first type of method, and adds a judgment on the storage method of the metadata. However, this method does not store in a third-party storage center, such as ipfs, so both of these two methods have the defect of being unable to comprehensively identify NFT contracts.

[0059] In view of the above actual situation, the embodiment of the present application provides an NFT contract identification scheme. The present application obtains the log information of the transaction information of the contract transaction, determines the signature field and the source field of the log information, and judges whether it is an NFT contract transaction. Since the most original form of the log information of any form of NFT contract transaction meets a certain form, the identification of the signature field and the source field of the log information can more comprehensively and accurately identify the NFT contract transaction, improve the identification accuracy and credibility, and improve the user experience.

[0060] Among them, Figure 1 Fig. 1 shows a structural schematic diagram of an exemplary system 100 according to an embodiment of the present application.

[0061] As Figure 1As shown, the NFT contract identification system 100 can mainly be composed of a data synchronization unit 110, a mint transaction identification unit 120, and a contract classification unit 130. The mint transaction identification unit 120 is the core unit, which is used to identify the corresponding transaction information. The data synchronization unit 110 is the front unit of the mint transaction identification unit 120, which is used to establish a data synchronization node and monitor its data synchronization state in real time, and is a unit for data acquisition. The contract classification unit 130 is used to reclassify the transaction information identified as NFT contract transactions, to facilitate the convenience of downstream or subsequent operations. It should be noted that, for the convenience of understanding, the NFT contract identification system 100 is divided into corresponding units, and in specific application scenarios, the corresponding division can not be performed, and the terminal, server, or a unified electronic device can independently complete the corresponding method steps, or form a complete process or only an independent program product.

[0062] Further, first, the operation basis and method of the core unit, the mint transaction identification unit 120, are introduced.

[0063] Figure 2 The flowchart of the example method provided by the embodiment of the application is shown. The example method can be completed by the mint transaction identification unit 120, that is, a NFT contract identification method.

[0064] As Figure 2 shown, the NFT contract identification method exemplarily provided by the embodiment of the application specifically includes the following steps.

[0065] Step 202, acquiring transaction information.

[0066] In this step, the transaction information is the information corresponding to the interaction detected as belonging to the transaction type in the blockchain network. The information can be the corresponding information of the NFT contract transaction, or the corresponding information of the transaction in other ways. In this step, as long as it involves a transaction, the corresponding transaction information will be acquired. In specific applications, there are generally a large amount of information in a blockchain network, and there are generally a large amount of transaction information in these information. In this embodiment, only one transaction information is described. For the scene of a large amount of information, the scheme of the embodiment can be repeatedly used for each information.

[0067] In some embodiments, the method of obtaining transaction information can be obtained in real time from the blockchain network by using the data synchronization unit 110, can also be obtained directly, or through the direct input of the operator, etc. Among them, since the local synchronization node is established, the efficiency and speed of Ethereum data synchronization can be improved, the safety and integrity of the data synchronization process can be ensured, the efficiency and speed of identifying Ethereum NFT contracts can be ensured, the risk and cost in the process of identifying Ethereum NFT contracts can be reduced, the integrity, security and availability of obtaining transaction data of identifying Ethereum NFT contracts can be ensured. In some embodiments, the data synchronization unit 110 can be set up first, which can obtain data in real time before obtaining transaction information, so as to synchronize the blockchain information in Ethereum in real time, and obtain transaction information through the network node when needed.

[0068] For the process of data acquisition by using the data synchronization unit 110, or the process of directly obtaining data from the blockchain network. In some embodiments, the network connection can be performed through the remote calling protocol first, that is, connected to the Ethereum blockchain network through the eth-rpc technology. Then, the corresponding instructions are used to obtain the corresponding information, through step-by-step data feedback, it can be finally judged whether the corresponding information is transaction information, and the transaction information is finally obtained. Specifically, the block information of the blockchain network can be obtained first by returning the specified block instruction, and the specific form of the returning specified block instruction can be web3.eth.getblock('blockNumber') instruction. Then, all interaction information in the block is traversed by returning the specified transaction object instruction, and the interaction belonging to the transaction is identified from the interaction information, and the transaction information of the transaction is obtained, and the specific form of the returning specified transaction object instruction can be web3.eth.getTransaction('txhash'). That is, in some embodiments, the transaction information includes: connecting the blockchain network by using the remote calling protocol; determining the block information of the blockchain network by returning the specified block instruction; determining the transaction information in the block corresponding to the block information by returning the specified transaction object instruction.

[0069] Step 204, determining the contract address of the transaction information, and judging whether the transaction information belongs to the contract transaction according to the contract address.

[0070] In this step, the contract address is converted from the contract hash value, which is the positioning information of the smart contract on the blockchain. Each smart contract will obtain a unique contract address after deployment, which is used to identify the smart contract. Since there are many types of smart contract forms, after obtaining a transaction information, it is necessary to first determine whether the corresponding transaction is a transaction for interacting with the contract, i.e., determine whether the transaction information belongs to the contract transaction.

[0071] After that, since the contract address itself is determined when the smart contract or the corresponding transaction information is determined, the way to determine the contract address of the transaction information can be calculated and derived through the information carried by the transaction information itself, or directly retrieved through a pre-imported comparison table, etc. For the calculation and derivation method, in some embodiments, the Ethereum blockchain RLP encoding (Recursive Length Prefix) and keccak algorithm operation can be used to determine whether the transaction belongs to the contract transaction.

[0072] Specifically, in some embodiments, the process of determining the contract address of the transaction information can be obtained by jointly performing recursive length prefix encoding on the from field (source field) and nonce field (identification code field) in the transaction information, obtaining the result of serializing the from field in the transaction information, and obtaining its contract address by keccak algorithm operation. That is, in some embodiments, the contract address of the transaction information is determined, including: determining the second source field and the identification code field of the transaction information; performing recursive length prefix encoding on the second source field and the identification code field to determine the serialization format result of the second source field; and performing decoding operation on the serialization format result by keccak algorithm to obtain the contract address. The second source field is the from field in the transaction information.

[0073] Afterwards, in some embodiments, for the specific process of judging whether the transaction information belongs to the contract transaction according to the contract address, after obtaining the contract address, it can be judged whether the to field (recipient field) of the transaction field therein is empty. If it is not empty, it means that it does not belong to the contract transaction, and the identification process is exited. If it is empty, the return value of the contract address can be determined using the return specified address code instruction, and if the return value length is greater than 2, it means that this is a smart contract that meets the requirements and belongs to the contract transaction, and vice versa, if it is less than or equal to 2, the identification process is exited. The specific form of the return specified address code instruction can be the web3.eth.getCode instruction, that is, if the final getCode return value is greater than 2, it is identified that this transaction is a transaction interacting with the contract. That is, in some embodiments, the contract address is determined whether the transaction information belongs to the contract transaction, including: determining whether the recipient field of the transaction field of the contract address is empty; in response to the recipient field being empty, determining the return value of the contract address through the return specified address code instruction, determining whether the length of the return value reaches the set length; in response to the length of the return value reaching the set length, determining that the transaction information belongs to the contract transaction.

[0074] Step 206, in response to the transaction information belonging to the contract transaction, obtaining the log information of the transaction information, and determining whether the signature field of the log information conforms to a specific type.

[0075] First of all, it needs to be introduced that according to the foregoing introduction, the casting transaction is not only the initial creation process of the digital asset, but also the key step to ensure the unique identity of each NFT. Through the casting transaction, each NFT obtains a unique identifier, making it non-fungible and unique on the blockchain. The applicant found in the research process of NFT contract transaction that once the casting transaction is written into the blockchain, it is the only identifier of the NFT on the blockchain, and it is the first step operation in the entire life cycle of the NFT, and also the most important operation. From a technical point of view, no matter how the casting transaction function is customized, the most original form in the log log is the operation of transfer or safe transfer with empty from. In view of this feature, in this step and the following steps, the data in the log log can be identified to determine whether the function action is transfer or safe transfer, and then whether the from field of the log log is empty, so as to realize the identification of the NFT contract.

[0076] Specifically, in this step, after judging that the transaction information is a contract transaction, the corresponding log information can be obtained, that is, the aforementioned log information is obtained. In some embodiments, the log information can be obtained by using corresponding instructions, for example, using a receipt object instruction that returns a specified transaction, that is, a web3.eth.getTransactionReceipt(‘txhash’) instruction. After obtaining the log information, the log information is parsed, and various fields can be obtained, such as a signature field (a topic field), a source field (a from field), and the like. In this embodiment, the topic0 field in the signature field is mainly identified. In the research process of the current NFT contract, it is found that no matter what the final form of the NFT contract is, its most original form in the current environment is generally to use the ERC-721 standard or the ERC-1155 standard. Further, if it is an NFT contract, the topic0 field of the log log is either a Transfer type, which belongs to the ERC-721 standard, or a SafeTransferFrom type, which belongs to the ERC-1155 standard. The Transfer type and the SafeTransferFrom type are the specific types mentioned in this step. When the signature field conforms to one of the types, it is considered that the signature field conforms to the specific type. That is, in some embodiments, the signature field includes at least a topic0 field; the specific type includes at least a Transfer type and a SafeTransferFrom type; and the determination of whether the signature field of the log information conforms to the specific type includes a determination of whether the type of the topic0 field belongs to one of the Transfer type and the SafeTransferFrom type.

[0077] Of course, with the development of the fields of blockchain technology, information technology, and the like, other standards that can be used to define NFT contracts can also appear. According to the foregoing analysis, in this scenario, the topic0 field of the log log will also correspond to a fixed type. Therefore, when other standards appear, the corresponding type can also be included in the specific type mentioned in this step.

[0078] Step 208, in response to the signature field conforming to the specific type, determining whether a first source field of the log information conforms to a set condition.

[0079] In this step, further judgment needs to be made on the log information for the transaction information meeting the specific type. According to the introduction in step 206, after determining that it meets the specific type, the source field of the log information needs to be judged to determine whether it meets the set condition. It needs to be explained here that the source field in this step is the source field of the log information in the transaction information, and the source field mentioned in some embodiments in step 204 is the source field of the transaction information. Therefore, in this scheme, the source field of the log information in the transaction information is determined as the first source field, and the source field of the transaction information is determined as the second source field.

[0080] Specifically, for the log information of the transaction information meeting the specific type, the parameters for running the Transfer and Safetransfer functions can be obtained, and it is judged whether the from field obtained in the log information is null. If it is null, it proves to be a mint transaction. The set condition in this step can be to judge whether the from field (the first source field) is null.

[0081] Step 210, in response to the first source field meeting the set condition, determining that the transaction corresponding to the transaction information is an NFT contract transaction.

[0082] In this step, when the first source field meets the set condition, it can be proved that the transaction information belongs to the corresponding information of the mint transaction, and the transaction corresponding to the transaction information is an NFT contract transaction. Of course, in some embodiments, during the judgment or confirmation process of any of the above steps, when it is determined that the corresponding transaction information does not belong to the information of the NFT contract transaction, although the current identification process will be directly ended and the corresponding result will be output, it can continue to identify the information for a set time interval in the subsequent process, continuously judge whether the subsequent transaction of the information exists mint transaction, and once the identification is passed, the corresponding transaction information can be identified as an NFT contract transaction.

[0083] At this point, the mint transaction identification unit 120 has completed its main work and identified whether the transaction corresponding to the current transaction information is an NFT contract transaction. After that, it can continue to classify the transaction (using the contract classification unit 130, etc.) or can be input to other downstream programs for other related work. In this scheme, for the key point of NFT mint transaction, through the identification of the mint transaction, the most important step for an NFT contract is completed, the identification of the NFT contract on Ethereum is realized, including ERC-721, ERC-1155 and other NFT contracts that meet the mint condition but do not belong to the two standards. In this way, the NFT contract transaction is more accurately identified, the identification accuracy and credibility are improved, and the user experience is improved.

[0084] After that, the data synchronization unit 110 will be described. Since the local synchronization node is established, the efficiency and speed of Ethereum data synchronization can be improved, the security and integrity of the data synchronization process can be ensured, the efficiency and speed of identifying Ethereum NFT contracts can be ensured, the risk and cost in the process of identifying Ethereum NFT contracts can be reduced, the completeness, security and availability of transaction data obtained by identifying Ethereum NFT contracts can be ensured. Further, transaction information acquisition can be performed using the data synchronization unit 110, that is, the data synchronization unit 110 can be established before transaction information acquisition.

[0085] In some embodiments, due to the consensus mechanism of Ethereum being transformed from the energy-consuming PoW (Proof of Work) to the environmentally friendly PoS (Proof of Stake) mechanism, which is referred to as Ethereum Merge (i.e., some PoW chains are merged into a PoS chain running in parallel). Therefore, the ETH full node needs to execute the client and the beacon node client to keep synchronization. At the same time, in order to ensure the uninterrupted operation of the Ethereum node, a monitoring daemon process needs to be written to ensure the normal operation of the node.

[0086] As shown in Figure 3 , a flowchart of an exemplary method for establishing a data synchronization node according to an embodiment of the present application is shown, which specifically includes the following steps.

[0087] Step 302, establish and merge the running Geth client and Prysm client to form a network node.

[0088] In this step, since the PoW mechanism and the PoS mechanism are monitored or obtained, the network node needs to execute the client and the beacon node client to keep synchronization.

[0089] Specifically, by using the Geth client, the execution client of Ethereum is run. The geth--rpc command is used to start Geth and open the RPC interface, so that other application programs can communicate with the node. Then, by using the Prysm client, the beacon client of Ethereum is run. The jwt-secret command is used to sign the JWT token, and once the key issuance service is in running state, the JWT token can be generated by sending an HTTP request to it to interact with the Prysm client. In this way, the ETH full node is built, that is, the corresponding network node is established.

[0090] Step 304, determine whether the network node can normally synchronize data by checking the block synchronization condition.

[0091] In this step, the block synchronization checking instruction is eth.syncing instruction, and this step is to determine whether the network node is running normally by using eth.syncing. Specifically, the geth attach command can be used to enter the Geth console, and then the eth.syncing command can be used to observe whether the Ethereum node is normally synchronized. If not, check the network reason, or re-execute the above steps to ensure that the running node and the beacon node are normally running.

[0092] Step 306, in response to the network node being able to normally synchronize data, a monitoring process is acquired and run to monitor the data synchronization state of the network node.

[0093] In this step, after determining that the network node can normally synchronize data, the corresponding synchronization data needs to be monitored in real time, and immediate feedback needs to be provided if an abnormality is found in the data synchronization process. That is, in a specific scenario, if the data can be normally synchronized, a monitoring daemon process needs to be further programmed to ensure the normal operation of the node. The operator can program a bash script using the ps-ef|grep command to monitor the programs in the server and check whether there is a Geth process. If not, the running node and the beacon node are restarted. Then, the corresponding timing task is added in the crontab (timing task), for example, the monitoring script is run every half hour to ensure the normal synchronization of the Ethereum node. In this step, the monitoring process is the corresponding program script programmed and input by the operator, and the corresponding monitoring task is completed by running the script.

[0094] Further, the contract classification unit 130 is described. After the NFT contract identification is completed, for the transactions belonging to the NFT contract transactions, since the current mainstream is still based on the ERC-721 standard and the ERC-1155 standard, the NFT contract transactions of the two standards can be classified accordingly to facilitate downstream work. Further, after the identification is completed, a contract classification unit 130 can be added. For the specific implementation process of the contract classification unit 130, as shown in Figure 4 As shown in FIG. 13, a flowchart of contract classification according to an example method of an embodiment of the present application is shown. It specifically includes the following steps.

[0095] Step 402, interface identification is performed on the transaction corresponding to the transaction information.

[0096] Step 404, in response to the interface of the transaction corresponding to the transaction information belonging to the set interface, the transaction corresponding to the transaction information is classified according to the identified interface type.

[0097] Step 406, in response to the identified interface of the transaction corresponding to the transaction information does not belong to the set interface, the transaction corresponding to the transaction information is classified as other type.

[0098] In the embodiment, the interface identification process can be to check whether the corresponding transaction information supports the ERC-721 or ERC-1155 interface through ERC-165. For example, the abi interface parsing function is used to perform read operation, since the ERC-165 interface contract only declares a supportsInterface function, the function can be used to input the interface id (type bytes4) to be queried, if the contract implements the interface id, then return true; otherwise, return false. Then the bytes string of the interface id of ERC-721 and ERC-1155 can be sent to identify, wherein the bytes string of the ERC-721 standard is 0x80ac58cd, and the bytes string of the ERC-1155 standard is 0xd9b67a26. After sending the two bytes strings, if the return of any one is true, it means that the transaction information belongs to the corresponding ERC-721 standard or ERC-1155 standard, and then the classification can be performed accordingly. If both return false or an error occurs, the transaction information can be classified as other type (others).

[0099] It should be noted that the other type here represents a type, not a generalization of multiple types that are not determined, in the embodiment, the transaction information will only be classified into three sets, one corresponding to the ERC-721 standard, one corresponding to the ERC-1155 standard, and the other being other type (others).

[0100] Then, another point to be explained is that in the current environment, the set interface of the embodiment is the interface corresponding to the ERC-721 standard or the ERC-1155 standard, and as described in the foregoing embodiment, if other standards that can be used to define NFT contract appear with the development of blockchain technology, information technology and the like, the set interface here can also include the interface corresponding to the new standard.

[0101] Finally, the exemplary system 100 is exemplarily illustrated as a whole, as follows.

[0102] (1) The data synchronization unit 110 builds an Ethereum node to facilitate obtaining data on the Ethereum blockchain network. Building an Ethereum full node requires executing a client and a beacon node client.

[0103] (2) The mint transaction identification unit 120, such asFigure 5 As shown, the eth-rpc technology is used to interact with geth.ipc through the package of web3. The data on the entire blockchain is traversed to obtain transaction information. The from field in each transaction is decoded and operated to obtain the contract address through keccak operation. It is identified whether the transaction is a transaction interacting with the contract, that is, whether it is a contract transaction. If it is determined to be a transaction interacting with the contract, the log information is obtained through the getTransactionReceipt instruction. The log information is decoded to obtain the hexadecimal log information. It is determined whether there is a transfer transaction or a safe transfer transaction. If there is any one of them, it is further determined whether the from field of the log information is empty. If all of them are met, it is proved to be an NFT minting transaction, that is, an NFT contract transaction.

[0104] (3) The contract classification unit 130, such as Figure 6 As shown, if the NFT minting transaction identification is realized, the ERC-721 and ERC-1155 standards are detected through the supportsInterface function of the contract of the transaction information in the form of corresponding bytes string. If the query 0x80ac58cd returns true, the classification result is ERC-721. If the query 0xd9b67a26 returns true, the classification result is ERC-1155. If neither of them is true, it is determined that the classification result is others, and it is judged as other NFT contract types. After the classification is completed, the final storage is stored.

[0105] As can be seen from the above embodiments, the NFT contract identification method and system provided by the embodiments of the present application include: obtaining transaction information; determining the contract address of the transaction information, and determining whether the transaction information belongs to a contract transaction according to the contract address; in response to the transaction information belonging to the contract transaction, obtaining log information of the transaction information, determining whether a signature field of the log information meets a specific type, in response to the signature field meeting the specific type, determining whether a first source field of the log information meets a set condition, and in response to the first source field meeting the set condition, determining that a transaction corresponding to the transaction information is an NFT contract transaction. The present application determines whether it is an NFT contract transaction by obtaining the log information of the transaction information belonging to the contract transaction, and determining the signature field and the source field of the log information. Since the most original appearance of the log information in any form of NFT contract transaction meets a specific form, the accurate identification of the NFT contract transaction can be more comprehensively realized by identifying the signature field and the source field of the log information, the identification accuracy and credibility are improved, and the user experience is improved.

[0106] It should be noted that the method of the embodiments of the present application can be executed by a single device, such as a computer or a server, etc. The method of the embodiments of the present application can also be applied to a distributed scenario, and be completed by multiple devices cooperating with each other. In the case of such a distributed scenario, one of the multiple devices can only execute one or more steps in the method of the embodiments of the present application, and the multiple devices can interact with each other to complete the method.

[0107] It should be noted that the above describes specific embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the acts or steps recited in the claims can be performed in a different order than those described above and still achieve desirable results. In addition, the processes depicted in the figures do not necessarily require the particular order shown, or sequential order, to achieve the desired results. In certain implementations, multitasking and parallel processing can be advantageous.

[0108] Based on the same concept, the present application also provides an NFT contract identification device corresponding to the method of any of the above embodiments.

[0109] Reference Figure 7 , the NFT contract identification device comprises:

[0110] The acquisition module 710 is configured to acquire transaction information.

[0111] The first determination module 720 is configured to determine the contract address of the transaction information, and determine whether the transaction information belongs to a contract transaction according to the contract address.

[0112] The second determination module 730 is configured to, in response to the transaction information belonging to the contract transaction, acquire log information of the transaction information, and determine whether a signature field of the log information conforms to a specific type.

[0113] The third determination module 740 is configured to, in response to the signature field conforming to the specific type, determine whether a first source field of the log information conforms to a set condition.

[0114] The fourth determination module 750 is configured to, in response to the first source field conforming to the set condition, determine that a transaction corresponding to the transaction information is an NFT contract transaction.

[0115] In some example embodiments, the acquisition module 710 is further configured to:

[0116] Connect to a blockchain network using a remote call protocol;

[0117] Determine block information of the blockchain network by returning a specified block instruction;

[0118] determining the transaction information in the block corresponding to the block information by returning a transaction object designation instruction.

[0119] In some example embodiments, the first determination module 720 is further configured to:

[0120] determine a second source field and an identification code field of the transaction information;

[0121] perform recursive length prefix coding on the second source field and the identification code field to determine a serialization format result of the second source field;

[0122] perform decoding operation on the serialization format result through a keccak algorithm to obtain the contract address.

[0123] In some example embodiments, the first determination module 720 is further configured to:

[0124] determine whether a receiver field of a transaction field of the contract address is empty;

[0125] in response to the receiver field being empty, determine a return value of the contract address by returning an address code designation instruction, and determine whether a length of the return value reaches a set length;

[0126] in response to the length of the return value reaching the set length, determine that the transaction information belongs to the contract transaction.

[0127] In some example embodiments, the signature field includes at least a topic0 field; and the specific type includes at least a Transfer type and a SafeTransferFrom type.

[0128] The second determination module 730 is further configured to:

[0129] determine whether a type of the topic0 field belongs to one of the Transfer type and the SafeTransferFrom type.

[0130] In some example embodiments, the acquisition module 710 is further configured to:

[0131] establish and merge a Geth client and a Prysm client to form a network node;

[0132] determine whether the network node can normally synchronize data by checking a block synchronization instruction;

[0133] In response to the network node being able to normally synchronize data, a monitoring process is acquired and run to monitor the data synchronization state of the network node.

[0134] In some example embodiments, the fourth determining module 750 is further configured to:

[0135] interface recognizing the transaction corresponding to the transaction information;

[0136] In response to the interface of the transaction corresponding to the transaction information belonging to the set interface, classifying the transaction corresponding to the transaction information according to the identified interface type;

[0137] In response to the interface of the transaction corresponding to the transaction information not belonging to the set interface, classifying the transaction corresponding to the transaction information as other types.

[0138] For the convenience of description, the above apparatus is described in various modules according to functions. Of course, the functions of each module can be implemented in one or more software and / or hardware in the implementation of the embodiments of the present application.

[0139] The apparatus of the above embodiments is used to implement the corresponding NFT contract identification method in the above embodiments, and has the beneficial effects of the corresponding method embodiments, which are not described here again.

[0140] Based on the same concept, corresponding to any of the above embodiment methods, the present application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to realize the NFT contract identification method according to any one of the above embodiments.

[0141] Figure 8 A more specific hardware structure schematic diagram of an electronic device provided by the present embodiment is shown, which can include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040 and a bus 1050. The processor 1010, the memory 1020, the input / output interface 1030 and the communication interface 1040 are connected to each other through the bus 1050 for communication within the device.

[0142] The processor 1010 can be implemented by a general-purpose CPU (Central Processing Unit, central processor), a microprocessor, an application specific integrated circuit (ASIC), or one or more integrated circuits, etc., for executing related programs to implement the technical solutions provided by the embodiments of the present specification.

[0143] The memory 1020 can be implemented in the form of a ROM (Read Only Memory), a RAM (Random Access Memory), a static storage device, a dynamic storage device, etc. The memory 1020 can store an operating system and other application programs, and when the technical solutions provided by the embodiments of the present specification are implemented by software or firmware, the related program codes are stored in the memory 1020 and are called and executed by the processor 1010.

[0144] The input / output interface 1030 is configured to connect an input / output module to realize information input and output. The input / output module can be configured as a component in the device (not shown in the figure) or can be externally connected to the device to provide corresponding functions. The input device can include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output device can include a display, a speaker, a vibrator, an indicator light, etc.

[0145] The communication interface 1040 is configured to connect a communication module (not shown in the figure) to realize the communication interaction between the device and other devices. The communication module can realize communication through a wired manner (such as USB, network cable, etc.) or through a wireless manner (such as mobile network, WIFI, Bluetooth, etc.).

[0146] The bus 1050 includes a channel for transmitting information between various components (such as the processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040) of the device.

[0147] It should be noted that although the above device only shows the processor 1010, the memory 1020, the input / output interface 1030, the communication interface 1040, and the bus 1050, in the specific implementation process, the device can also include other components necessary for normal operation. In addition, those skilled in the art can understand that the above device can also only contain the components necessary to implement the embodiments of the present specification, and does not have to contain all the components shown in the figure.

[0148] The electronic device of the above embodiments is used to implement the corresponding NFT contract identification method in any of the preceding embodiments, and has the beneficial effects of the corresponding method embodiments, which are not described here.

[0149] Based on the same concept, corresponding to any of the above embodiment methods, the present application also provides a non-transitory computer readable storage medium, which stores computer instructions for causing the computer to execute the NFT contract identification method according to any one of the above embodiments.

[0150] The computer readable medium of the embodiments includes permanent and non-permanent, removable and non-removable media, and can be implemented by any method or technology to store information. The information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible by a computing device.

[0151] The storage medium of the above embodiments stores computer instructions for causing the computer to perform the NFT contract identification method as described in any of the above embodiments, and has the beneficial effects of the corresponding method embodiments, which are not repeated here.

[0152] Based on the same concept, corresponding to the method of any of the above embodiments, the present application also provides a computer program product comprising computer program instructions. In some embodiments, the computer program instructions can be executed by one or more processors of a computer to cause the computer and / or the processor to perform the NFT contract identification method. Corresponding to the execution subject of each step in each embodiment of the NFT contract identification method, the processor performing the corresponding step can belong to the corresponding execution subject.

[0153] The computer program product of the above embodiments is used to cause the computer and / or the processor to perform the NFT contract identification method as described in any of the above embodiments, and has the beneficial effects of the corresponding method embodiments, which are not repeated here.

[0154] Those skilled in the art should understand that the discussion of any of the above embodiments is only exemplary and is not intended to imply that the scope of the present application (including claims) is limited to these examples; the above embodiments or technical features between different embodiments can also be combined, the steps can be implemented in any order, and there are many other changes of the aspects of the embodiments of the present application as described above. In order to be brief, they are not provided in detail.

[0155] Additionally, to simplify the description and discussion, and so as not to obscure the embodiments of the application being presented, the well-known functions or constructions of integrated circuit (IC) chips and other components can or can not be shown in the figures and will be omitted as not to unnecessarily obscure the embodiments of the application being presented. Moreover, the devices can be shown in block diagram form in order to avoid obscuring the embodiments of the application, and this also acknowledges the fact that the details in regard to the implementation of the block diagram devices are highly dependent on the platform within which the embodiments of the application are to be implemented (i.e., these details should be well within the purview of one of ordinary skill in the art). Where specific details are set forth in order to describe an illustrative embodiment of the application, it will be apparent to one of ordinary skill in the art that the embodiments of the application can be practiced without, or with variation of, these specific details. Thus, the description is to be considered as illustrative only and not restrictive in nature.

[0156] While the application has been described in connection with specific embodiments thereof, it will be understood that many modifications, substitutions and changes will be apparent to those of ordinary skill in the art once they have the benefit of the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) can use the embodiments discussed.

[0157] It is intended that the embodiments of the application encompass all such substitutions, modifications and variations as fall within the scope of the appended claims. Accordingly, any omission, modification, equivalent replacement, improvement, etc. made in the spirit and principle of the embodiments of the application should be included in the scope of protection of the application.

Claims

1. A method for identifying NFT contracts, characterized in that, include: Obtain transaction information; Determine the contract address of the transaction information, and determine whether the transaction information belongs to a contract transaction based on the contract address; In response to the fact that the transaction information belongs to the contract transaction, the log information of the transaction information is obtained, and it is determined whether the signature field of the log information conforms to a specific type; In response to the signature field conforming to the specific type, it is determined whether the first source field of the log information meets the set conditions; wherein, the set conditions include determining whether the from field is empty, and if it is empty, it proves that it is a minting transaction; In response to the first source field meeting the set conditions, the transaction corresponding to the transaction information is determined to be an NFT contract transaction; The signature field includes at least the topic0 field; the specific type includes at least the Transfer type and the SafeTransferFrom type. Determining whether the signature field of the log information conforms to a specific type includes: Determine whether the type of the topic0 field belongs to either the Transfer type or the SafeTransferFrom type.

2. The method according to claim 1, characterized in that, The acquisition of transaction information includes: Connect to the blockchain network using a remote procedure call protocol; The block information of the blockchain network is determined by returning a specified block instruction; By returning a specified transaction object instruction, the transaction information within the block corresponding to the block information is determined.

3. The method according to claim 1, characterized in that, The process of determining the contract address for the transaction information includes: Determine the second source field and the identification code field of the transaction information; Recursive length prefix encoding is performed on the second source field and the identification code field to determine the serialization format result of the second source field; The serialization format result is decoded using the Keccak algorithm to obtain the contract address.

4. The method according to claim 1, characterized in that, The step of determining whether the transaction information belongs to a contract transaction based on the contract address includes: Determine whether the recipient field of the transaction field of the contract address is empty; In response to the receiver field being empty, the return value of the contract address is determined by returning a specified address code instruction, and it is determined whether the length of the return value reaches the set length. In response to the return value reaching the set length, it is determined that the transaction information belongs to the contract transaction.

5. The method according to claim 1, characterized in that, Before obtaining transaction information, the method further includes: Establish and merge the Geth client and Prysm client to form a network node; The command to check the block synchronization status determines whether the network node can synchronize data normally. In response to the network node's ability to synchronize data normally, a monitoring process is acquired and run to monitor the data synchronization status of the network node.

6. The method according to claim 1, characterized in that, After determining that the transaction corresponding to the transaction information is an NFT contract transaction, the method further includes: The transaction corresponding to the transaction information is identified via an interface. In response to the identified transaction information, if the interface of the transaction belongs to a defined interface, the transactions corresponding to the transaction information are classified according to the identified interface type. If the interface corresponding to the identified transaction information does not belong to the set interface, the transaction corresponding to the transaction information is classified as another type.

7. An NFT contract recognition device, characterized in that, include: The acquisition module is used to acquire transaction information; The first determining module is used to determine the contract address of the transaction information and determine whether the transaction information belongs to a contract transaction based on the contract address. The second determining module is used to, in response to the fact that the transaction information belongs to the contract transaction, obtain the log information of the transaction information and determine whether the signature field of the log information conforms to a specific type; The third determining module is used to determine whether the first source field of the log information meets the set conditions in response to the signature field conforming to the specific type; wherein, the set conditions include determining whether the from field is empty, and if it is empty, it proves that it is a minting transaction; The fourth determining module is used to determine that the transaction corresponding to the transaction information is an NFT contract transaction in response to the first source field meeting the set conditions; The signature field includes at least the topic0 field; the specific type includes at least the Transfer type and the SafeTransferFrom type. Determining whether the signature field of the log information conforms to a specific type includes: Determine whether the type of the topic0 field belongs to either the Transfer type or the SafeTransferFrom type.

8. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method as claimed in any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores computer instructions for causing a computer to perform the method described in any one of claims 1 to 6.

Images