Transaction monitoring method and related device

Abstract

The invention relates to the technical field of block chains, and discloses a transaction monitoring method and a related device, which are used for improving the transaction efficiency and reducing the transaction security risk, and the method comprises the steps: after a main node in an alliance chain obtains the transaction information of a target transaction, carrying out the transaction processing of the transaction information, and obtaining a transaction result, the method comprises the following steps that: firstly, a node identifier of a node, transaction information and a transaction result are associated and recorded in a log file, and then, a main node broadcasts the transaction information and the transaction result to other nodes in a block chain for transaction verification, and respectively receives transaction verification results returned by the other nodes; the method comprises the following steps: acquiring the node identification of each other node, recording the other node identification of each other node and the corresponding transaction verification result in a log file in an associated manner, and finally, sending the log file to a server, so that the server analyzes the transaction condition of the target transaction based on the node identification, the transaction information, the transaction result, each other node identification and the corresponding transaction verification result.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a transaction monitoring method and related devices. Background Art

[0002] As a special type of blockchain, consortium chain is widely used in electronic resource trading business in various industries. In the transaction process based on consortium chain, a transaction often needs to be verified by multiple consortium chain nodes based on transaction information before it can be completed.

[0003] In the existing alliance chain system, since it is impossible to monitor the transaction process throughout the entire life cycle, the following problems arise:

[0004] 1. It is impossible to obtain the verification status of transactions by each alliance chain node in real time. When problems such as transaction processing delays or transaction verification failures occur, the problems cannot be checked in time, resulting in the inability to complete the transaction on time, thereby reducing transaction efficiency. In addition, it is also impossible to detect functional or performance abnormalities of the blockchain system in a timely manner, thereby increasing the difficulty of operation and maintenance management of the alliance chain system.

[0005] 2. When the transaction information in the alliance chain node is intercepted by a third party or maliciously tampered with by a third party, the alliance chain system cannot quickly discover and solve the problem, which increases the security risk of the transaction.

[0006] In view of this, it is necessary to propose a transaction monitoring method to overcome the above defects. Summary of the invention

[0007] The present application provides a transaction monitoring method and related devices to improve transaction efficiency and reduce transaction security risks.

[0008] In a first aspect, an embodiment of the present application provides a transaction monitoring method, which is applied to a blockchain node of a consortium chain, and the method includes:

[0009] Obtaining transaction information of a target transaction; the transaction information includes the identity of the transaction party;

[0010] Performing transaction processing on the transaction information to obtain the transaction result, and encrypting the transaction party identity in the transaction information based on the transaction party public key to obtain encrypted transaction information, and associating and recording the node identity of the blockchain node, the encrypted transaction information and the transaction result in a log file;

[0011] Broadcasting the transaction information and transaction results to other blockchain nodes in the blockchain for transaction verification, and receiving the transaction verification results returned by the other blockchain nodes respectively, and associating and recording the other node identifiers of the other blockchain nodes and the corresponding transaction verification results in the log file respectively;

[0012] The log file is sent to the server so that the server can decrypt the encrypted transaction party identity based on the transaction party's private key, and analyze the transaction status of the target transaction based on the node identification, transaction information, transaction results, other node identifications and corresponding transaction verification results.

[0013] In a second aspect, an embodiment of the present application further provides a transaction monitoring device, the device comprising:

[0014] An information acquisition module is used to acquire transaction information of a target transaction; the transaction information includes the identity of the transaction party;

[0015] The first recording module is used to perform transaction processing on the transaction information to obtain the transaction result, and to encrypt the identity of the transaction party in the transaction information based on the public key of the transaction party to obtain the encrypted transaction information, and to associate the node identity of the blockchain node, the encrypted transaction information and the transaction result and record them in a log file;

[0016] The second recording module is used to broadcast the transaction information and transaction results to other blockchain nodes in the blockchain for transaction verification, and respectively receive the transaction verification results returned by the other blockchain nodes, and respectively associate the other node identifiers of the other blockchain nodes with the corresponding transaction verification results and record them in a log file;

[0017] The log sending module is used to send the log file to the server so that the server can decrypt the encrypted transaction party identity based on the transaction party's private key, and analyze the transaction status of the target transaction based on the node identification, transaction information, transaction results, other node identifications and corresponding transaction verification results.

[0018] Optionally, the transaction information carries a public key certificate including a public key and a digital signature of a transaction party. After acquiring the transaction information of the target transaction and before performing transaction processing on the transaction information, the first recording module is further configured to:

[0019] Based on the digital signature, the legitimacy of the public key of the transaction party is verified; the public key and the private key of the transaction party constitute a public-private key pair; the public-private key pair is generated by the terminal that sends the transaction information.

[0020] When the public key of the transaction party passes the legitimacy verification, the node identification, transaction information and legitimacy verification result are associated and recorded in the log file.

[0021] Optionally, the first recording module is further used for:

[0022] When the public key of the transaction party fails the legitimacy verification, the target transaction is terminated, and the node identification, transaction information and the legitimacy verification failure result are associated and recorded in the log file, and the log file is sent to the server.

[0023] Optionally, the transaction information includes the identity of the transaction party. After obtaining the transaction result, before recording the node identifier, the transaction information and the transaction result in a log file in association with each other, the first recording module is further configured to:

[0024] The transaction party's identity is encrypted based on the transaction party's public key, so that the server can decrypt the encrypted transaction party's identity after obtaining the transaction party's private key.

[0025] Optionally, after receiving the transaction verification results returned by each other node and before sending the log file to the server, the second recording module is further used to:

[0026] Based on the received verification results of each transaction, obtain the verification pass number;

[0027] When the number of verification passes is not less than the preset threshold, the transaction information and transaction results are packaged into blocks and added to the blockchain, and the block identifier of the block is recorded in the log file.

[0028] Optionally, the second recording module is further used for:

[0029] When the number of verification passes is less than the preset threshold, the target transaction is terminated, and the number of verification passes, the preset threshold and the consensus failure result are recorded in the log file, and the log file is sent to the server.

[0030] Optionally, the second recording module is further used for:

[0031] Broadcast the block to other block nodes, and associate the target transaction ID with the block broadcast event ID in the log file.

[0032] Optionally, the second recording module is further used for:

[0033] The transaction events and the corresponding time spent in the transaction process of the target transaction are recorded in a log file, and the log file is sent to the server so that the server can analyze the transaction situation of the target transaction. The log sending module is also used to:

[0034] The log file is sent to the server so that the server can perform a time consumption analysis on the target transaction based on the time consumption of each transaction event.

[0035] In a third aspect, an embodiment of the present application 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 implements any method of the first aspect when executing the computer program.

[0036] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, which implements the steps of any method of the first aspect when the computer program is executed by a processor.

[0037] In a fifth aspect, an embodiment of the present application provides a computer program product, which, when called by a computer, enables the computer to execute the method of the first aspect.

[0038] The beneficial effects of this application are as follows:

[0039] The present application provides a transaction monitoring method and related devices, which relate to the field of blockchain technology and are applied to nodes in a blockchain.

[0040] In the embodiment of the present application, first, after obtaining the transaction information of the target transaction, the master node in the alliance chain processes the transaction information, obtains the transaction result, and records the node identification, transaction information and transaction result of the node in the log file. Therefore, when there are problems such as transaction processing delay or transaction failure, the cause of the problem can be promptly checked, avoiding the problem of untimely completion of the transaction and improving the transaction efficiency; wherein, the target transaction identification is carried in the transaction information. Then, the master node broadcasts the transaction information and transaction result to each other node in the blockchain for transaction verification, and receives the transaction verification results returned by each other node respectively, and records the other node identifications of each other node and the corresponding transaction verification results in the log file, realizing the real-time recording of the transaction verification results of each other node. When the transaction information in the node is intercepted by a third party or maliciously tampered by a third party, resulting in the failure of the transaction verification, the node server that failed the transaction verification can be located according to the node identification in the log file, and then the cause of the problem is checked. Finally, the log file is sent to the server, so that the server analyzes the transaction situation of the target transaction based on the node identification, transaction information, transaction results, each other node identification and the corresponding transaction verification result.

[0041] In summary, the solution provided in the embodiment of the present application realizes the full life cycle monitoring and surveillance of transactions on the alliance chain, and comprehensively reflects the operating status of the alliance chain system. When problems such as transaction failure or transaction delay occur, the node server that may have problems can be accurately located, thereby providing a guarantee for timely discovery of problems and maintaining the normal operation of the blockchain system, thereby improving the operation and maintenance management efficiency of the alliance chain system; and, it can timely discover problems where transaction information has been intercepted or tampered with, thereby reducing the security risks of transactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1A This is a schematic diagram of the blockchain network in the embodiment of this application;

[0043] Figure 1B This is a schematic diagram of the blockchain in the embodiment of this application;

[0044] Figure 2 A schematic diagram of an application scenario in an embodiment of the present application;

[0045] Figure 3 This is a schematic diagram of a first process of a transaction monitoring method in an embodiment of the present application;

[0046] Figure 4 This is a schematic diagram of the legality verification process in the embodiment of this application;

[0047] Figure 5A This is a schematic diagram of the interaction process between the terminal and the blockchain master node in an embodiment of the present application;

[0048] Figure 5B This is a schematic diagram of the interaction logic between the terminal and the blockchain master node in the embodiment of the present application;

[0049] Figure 6 This is a schematic diagram of a log file after the legality verification is passed in the embodiment of the present application;

[0050] Figure 7 This is a schematic diagram of a log file after transaction information is processed in an embodiment of the present application;

[0051] Figure 8 A schematic diagram of the interaction between the master node and the slave node in an embodiment of the present application;

[0052] Fig. 9 A schematic diagram of a log file after obtaining a slave node transaction verification result in an embodiment of the present application;

[0053] Fig.10 A schematic diagram of the process of generating a new block in an embodiment of the present application;

[0054] Fig.11A This is a second flow chart of a transaction monitoring method in an embodiment of the present application;

[0055] Fig. 11B A logical diagram of a transaction monitoring method in an embodiment of the present application;

[0056] Fig.12 This is a schematic diagram of a transaction monitoring device in an embodiment of the present application;

[0057] Fig.13 A schematic diagram of an electronic device corresponding to a transaction monitoring method in an embodiment of the present application. DETAILED DESCRIPTION

[0058] In order to make the purpose, technical solution and beneficial effects of this application clearer, the technical solution in the embodiment of this application will be clearly and completely described below in conjunction with the drawings in the embodiment of this application. Obviously, the described embodiment is only a part of the embodiment of this application, not all the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0059] Some of the terms used in the embodiments of the present application are explained below to facilitate understanding by those skilled in the art.

[0060] (1) Blockchain: A distributed ledger technology in the field of information technology, generally composed of consensus, transaction blocks and status data storage, cryptographic identity security, etc. Since the ledger is stored in a distributed manner and the blocks are based on consensus, it has the characteristics of being tamper-proof, traceable, and jointly maintained.

[0061] (2) Consortium chain: A special type of blockchain, which is a semi-decentralized network. Unlike the public chain, the consortium chain only allows specific organizations or entities to join the network. These organizations or entities jointly manage and maintain the blockchain and share data and consensus processes. Compared with the public chain, the consortium chain has higher performance, better privacy protection and stricter permission control.

[0062] (3) Smart contract: A computer protocol designed to communicate, verify or execute contracts in an information-based manner. Smart contracts allow trusted transactions to be conducted without a third party, and these transactions are monitorable and irreversible.

[0063] (4) Process pool: A resource pool used to manage multiple processes, responsible for creating, maintaining, scheduling, and recycling processes. The process pool can improve the concurrent performance of the system because it allows multiple tasks to be executed simultaneously in different processes. In the blockchain system, the process pool can be used to handle concurrent transaction requests and improve the throughput of the entire system.

[0064] (5) Contract repository: A database for storing and managing smart contracts, which contains the code, status, and metadata of all smart contracts deployed on the blockchain. The contract repository allows users to query, call, and update smart contracts, and also provides the infrastructure for blockchain nodes to execute smart contracts.

[0065] (6) Blockchain ledger: The blockchain ledger is the core data structure in the blockchain system, which is used to store and manage all confirmed blocks. The blockchain ledger is organized in a chain structure, and each block contains a set of transactions, a block header (including the hash value of the previous block, timestamp and other metadata), and other information. The blockchain ledger provides a public, tamper-proof transaction history record for the blockchain system, ensuring the transparency and consistency of the system.

[0066] (7) State data: State data is a data structure used in blockchain systems to represent the current state of the system. State data includes the balances of all accounts, the status of smart contracts, and other related information. State data is continuously updated as transactions are executed, reflecting the global state of the blockchain system at a certain point in time. In blockchain systems, state data is usually stored in the form of Merkle trees or other encrypted data structures to ensure its integrity and security.

[0067] (8) Zipkin service: a distributed monitoring system used to collect and analyze request call link data in a distributed system; the Zipkin service associates the monitoring information in each service through the monitoring ID to form a complete call link.

[0068] (9) Zipkin Span: A basic concept in the Zipkin monitoring system, representing an independent operation or work unit in a distributed system. In a distributed monitoring system, a complete call chain consists of multiple spans, forming a tree structure. By collecting and analyzing these spans, you can understand the execution status of the entire call chain, including the time consumption and dependencies of each operation.

[0069] The following is a brief introduction to the design concept of the embodiments of the present application.

[0070] Under existing technologies, a transaction on a consortium chain usually requires multiple blockchain nodes to verify the transaction based on the transaction information before it can be completed. However, the existing blockchain system cannot monitor the transaction process throughout its life cycle, resulting in the following problems:

[0071] Since it is impossible to obtain the verification status of transactions by each blockchain node in real time, when problems such as transaction processing delays or transaction verification failures occur, the cause of the problem cannot be promptly identified, resulting in the transaction being unable to be completed on time; in addition, since it is impossible to monitor the execution and time consumption of transactions at each stage in real time, it is impossible to fully understand the operating status of the system, and therefore it is impossible to promptly discover functional or performance abnormalities of the blockchain system.

[0072] In terms of transaction security, when transaction information is intercepted by a third party or maliciously tampered with by a third party, the problem cannot be discovered and resolved in a timely manner, resulting in increased transaction security risks.

[0073] In view of this, an embodiment of the present application provides a transaction monitoring method and related devices, which relate to the field of blockchain technology and are applied to nodes in a consortium chain.

[0074] In the embodiment of the present application, after the master node in the alliance chain receives the transaction information of the target transaction, it records the entire process of the execution of the target transaction through a log file, including the master node's verification of the legitimacy of the public key of the transaction party, the master node's processing of the transaction information, the slave node's verification of the target transaction, and the generation of new blocks. Therefore, when the server receives the log file sent by the master node, it can analyze the transaction situation of the target transaction, promptly discover transaction anomalies, investigate the causes of transaction failures, avoid untimely completion of transactions, and thus improve transaction efficiency.

[0075] In addition, the log file also records the duration of each transaction event during the transaction process of the target transaction. When a transaction event takes longer than the normal duration, it means that the node server executing the transaction event may have functional or performance abnormalities. Therefore, the log file can help maintenance personnel promptly discover problems in the blockchain system, thereby improving operation and maintenance efficiency.

[0076] Secondly, the log file also records the transaction information. The identity of the transaction party contained in the transaction information is encrypted, which avoids the leakage of the transaction party's privacy data and provides security for the transaction data.

[0077] After introducing the design concept of this application, the blockchain technology used in the embodiments of this application is introduced in detail below.

[0078] See also Figure 1A In the blockchain network shown, the blockchain network 100 refers to a system for sharing data between nodes, and the blockchain network may include multiple nodes 101, and the multiple nodes 101 may refer to each client in the blockchain network. Each node 101 can receive input information during normal operation and maintain the shared data in the blockchain network based on the received input information. In order to ensure the intercommunication of information in the blockchain network, there may be an information connection between each node in the blockchain network, and information can be transmitted between nodes through the above information connection. For example, when any node in the blockchain network receives input information, other nodes in the blockchain network obtain the input information according to the consensus algorithm, and store the input information as data in the shared data, so that the data stored on all nodes in the blockchain network are consistent.

[0079] Each node in the blockchain network has a corresponding node identifier, and each node in the blockchain network can store the node identifiers of other nodes in the blockchain network, so that the generated blocks can be broadcast to other nodes in the blockchain network according to the node identifiers of other nodes. Each node can maintain a node identifier list as shown in the following table, and store the node name and node identifier in the node identifier list accordingly. Among them, the node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address and any other information that can be used to identify the node. Table 1 only uses the IP address as an example for illustration.

[0080] Table 1

[0081] Node Name Node ID Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.189.258

[0082] Each node in the blockchain network stores the same blockchain. The blockchain consists of multiple blocks, see Figure 1B The blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores the input information characteristic value, version number, timestamp and difficulty value, and the block body stores the input information; the next block of the genesis block takes the genesis block as the parent block, and the next block also includes a block header and a block body. The block header stores the input information characteristic value of the current block, the block header characteristic value, version number, timestamp and difficulty value of the parent block, and so on, so that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input information in the block.

[0083] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, platform product service layer, and application service layer.

[0084] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operation monitoring. Among them, the user management module is responsible for the identity information management of all blockchain participants, including maintaining public and private key generation (account management), key management, and the maintenance of the correspondence between the user's real identity and the blockchain address (authority management), etc., and, under authorization, supervises and audits the transactions of certain real identities and provides risk control rule configuration (risk control audit); the basic service module is deployed on all blockchain node devices to verify the validity of business requests, and records valid requests to storage after consensus is reached. For a new business request, the basic service first adapts the interface for parsing and authentication (interface adaptation), and then encrypts the business information through the consensus algorithm (consensus management). The smart contract module is responsible for the registration and issuance of contracts, as well as contract triggering and contract execution. Developers can define the contract logic in a programming language and publish it to the blockchain (contract registration). According to the logic of the contract terms, the key or other events are called to trigger the execution and complete the contract logic. It also provides the function of contract upgrade and cancellation. The operation monitoring module is mainly responsible for the deployment, configuration modification, contract setting, cloud adaptation and real-time status visualization output of the product during the product release process, such as alarm, network status monitoring, node equipment health status monitoring, etc.

[0085] The platform product service layer provides the basic capabilities and implementation framework of typical applications. Developers can superimpose business features based on these basic capabilities to complete the blockchain implementation of business logic. The application service layer provides application services based on blockchain solutions for business participants to use.

[0086] In the solution provided in the embodiment of the present application, after the terminal sends a transaction request to a node in the blockchain network, the node records the execution status of the transaction in each node of the blockchain in a log file and then sends it to the server, thereby realizing full life cycle monitoring of the transaction on the blockchain.

[0087] The transaction monitoring method provided by the exemplary embodiment of the present application is described below in conjunction with the accompanying drawings. It should be noted that the above application scenarios are only shown to facilitate understanding of the spirit and principles of the present application, and the embodiments of the present application are not limited in this regard. In addition, although the operations of the method of the present application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in this specific order, or that all the operations shown must be performed to achieve the desired results. Additionally or alternatively, certain steps can be omitted, multiple steps can be combined into one step for execution, and / or one step can be decomposed into multiple steps for execution.

[0088] like Figure 2As shown, it is a schematic diagram of an application scenario in an embodiment of the present application. It is a schematic diagram of an application scenario in an embodiment of the present application. The application scenario includes: a terminal 20, a blockchain network 21, and a server 22, wherein the blockchain network 21 includes nodes 211, 212, 213, and 214. It can be understood that the terminal 20 and the server 22 are connected to the blockchain network 21 through network communication, respectively, and the nodes included in the blockchain network 21 are also interconnected through a communication network. The network can include various connection types, such as wireless communication links, wired and optical fiber cables, etc.

[0089] Among them, terminal 20 is used to send transaction information corresponding to the target transaction to the blockchain network. The terminal devices include but are not limited to mobile phones, tablets, laptops, desktop computers, e-book readers, intelligent voice interaction devices, smart home appliances, car terminals and other devices. Various clients can be installed on the terminal. The client can be an online platform that supports transaction functions, an application (such as a browser, game software, shopping software, video player, etc.), or a web page, a small program, etc.

[0090] Nodes 211 , 212 , 213 , and 214 in the blockchain network 21 are servers, which are used to process transaction services, record transaction execution status in log files, and send the log files to the server 22 .

[0091] The server 22 is a server that is used to receive and store log files sent by nodes in the blockchain network, and analyze transaction status based on the data in the log files.

[0092] The following describes the transaction monitoring method provided by the exemplary embodiment of the present application in combination with the application scenario described above and with reference to the accompanying drawings. It should be noted that the above application scenario is only shown to facilitate understanding of the spirit and principles of the present application, and the implementation of the present application is not limited in this regard.

[0093] See also Figure 3 As shown, it is a first flow diagram of a transaction monitoring method in an embodiment of the present application. The specific implementation process of the method is as follows:

[0094] Step 31: Obtain transaction information of the target transaction.

[0095] The transaction information carries a target transaction identifier.

[0096] In an embodiment of the present application, the terminal sends a transaction request to the master node in the blockchain, that is, the terminal sends a transaction message to the node in the blockchain. The transaction message includes a node identifier, a transaction party identifier, a transaction object identifier, a transaction content, and a public key certificate including a transaction party public key and a digital signature. The transaction message carries a target transaction identifier.

[0097] For example, object A sends transaction information to the master node 211 in the blockchain through terminal 20. The transaction information includes the master node identifier, the transaction party identifier UserA, the transaction object identifier UserB, and the transaction content: UserA transfers 100 yuan to UserB. At the same time, the transaction information carries the target transaction identifier TR100.

[0098] In a possible implementation, the transaction information carries a public key certificate including the public key and digital signature of the transaction party. After receiving the transaction information of the target transaction, the master node 211 can also verify the legitimacy of the identity of the transaction party, such as Figure 4 As shown, it is a schematic diagram of the legality verification process in the embodiment of the present application. Figure 4 , the specific execution steps 311-313 are described in detail:

[0099] Step 311: Based on the digital signature, the legitimacy of the public key of the transaction party is verified. If the verification passes, execute step 312; otherwise, execute step 313.

[0100] Among them, the public key and the private key of the transaction party constitute a public-private key pair; the public-private key pair is generated by the terminal that sends the transaction information;

[0101] Specifically, Figure 5A and Figure 5B As shown, they are respectively the interaction diagram and logic diagram between the terminal and the blockchain master node in the embodiment of the present application. Before initiating a transaction request, the terminal needs to generate a public-private key pair (transaction party public key PubKey, transaction party private key PriKey) for the transaction party initiating the transaction, for example: using the Rivest-Shamir-Adleman (RSA) algorithm to generate, or using the Ellipse CurveCryptography (ECC) algorithm to generate. After that, the transaction party initiating the transaction sends the transaction information and the transaction party's public key to the certification authority. The certification authority uses the certification authority's private key to digitally sign the transaction party's public key PubKey and generate a public key certificate, and sends the transaction information, public key certificate, and certification authority public key to the blockchain master node. The blockchain master node receiving the transaction information uses the certification authority's public key to verify the correctness of the digital signature. When the digital signature is confirmed to be correct, the transaction party's public key is extracted from the public key certificate for subsequent encryption of related data, and the transaction is processed according to the transaction information.

[0102] Step 312: The node identification, transaction information and legitimacy verification result are recorded in a log file in association.

[0103] In the embodiment of the present application, when the public key of the transaction party passes the verification, the master node records the target transaction identifier, node identifier, transaction party identity identifier, transaction object identity identifier, transaction content and the result of the legality verification, and the time consumed for the legality verification in the log file. In the log file, the legality verification of the public key of the transaction party is recorded in a table form. It is worth noting that other forms can also be used for recording, and the embodiment of the present application does not limit this.

[0104] For example, Figure 6 As shown, it is a schematic diagram of the log file after the legitimacy verification in the embodiment of the present application, wherein the target transaction identifier carried in the transaction information is Tr100; the master node identifier is 117.114.151.174; the legitimacy verification result of the transaction party's public key is Success, that is, the verification is passed; the transaction initiator, that is, the transaction party in the embodiment of the present application corresponds to the transaction party identity identifier UserA, the transaction object identity identifier is UserB, and the transaction content is the electronic asset exchange between UserA and UserB; this legitimacy verification process takes 10 seconds.

[0105] Furthermore, when the public key of the transaction party passes the legitimacy verification, the master node also verifies the authority of the transaction party. The verification method is: search for the transaction party's identity in the preset transaction party authority list. When the transaction party's identity exists in the transaction party authority list, add the target transaction identity to the transaction pool. When there are enough transactions in the transaction pool for block generation, the transaction scheduler starts to schedule transactions for parallel execution, and the master node records the transaction scheduling event in the log file. Step 313: End the target transaction, and associate the node identity, transaction information and the result of the legitimacy verification failure in the log file, and send the log file to the server.

[0106] In an embodiment of the present application, when the public key of the transaction party fails the legitimacy verification, the master node records the target transaction identifier, node identifier, transaction party identity identifier, transaction object identity identifier, transaction content and legitimacy verification failure result, and the time consumed for the legitimacy verification in a log file, and ends the target transaction, sends a legitimacy verification failure message to the terminal device that initiated the transaction, and sends a log file to the server.

[0107] In another possible implementation, transaction monitoring on the alliance chain can be implemented using the Zipkin service. The Zipkin client is installed on the master node. The master node creates a root Span and a corresponding root Span identifier for the target transaction. The root Span has the same function as the log file, which is used to record the legitimacy verification of the transaction and the transaction authority verification. In addition, the root Span also includes the target transaction identifier, the root Span identifier, and the parent Span identifier "NULL". The Span can be sent to the Zipkin server through the Zipkin client.

[0108] In this way, the server can locate the node server that failed the legitimacy verification according to the node identifier in the log file or the root span, and investigate the cause of the failure of the legitimacy verification. At the same time, according to the time consumed by the legitimacy verification, it can analyze whether there are any functional or performance abnormalities in the corresponding node server.

[0109] Step 32: performing transaction processing on the transaction information to obtain a transaction result, and encrypting the identity identifier of the transaction party in the transaction information based on the public key of the transaction party to obtain encrypted transaction information, and recording the node identifier of the blockchain node, the encrypted transaction information and the transaction result in a log file in association with each other;

[0110] In the embodiment of the present application, after the public key of the transaction party is verified, the master node calls the relevant smart contract code from the contract warehouse to execute the transaction, obtain the transaction result, and use the hash function to hash the transaction result to obtain the corresponding hash value; the master node obtains the public key of the transaction party from the transaction information carried by the transaction information, and based on the public key of the transaction party, encrypts the identity of the transaction party in the transaction information, and records the master node identification, transaction information, the hash value corresponding to the transaction result and the time taken for the transaction execution in the log file. It can be understood that the master node can execute multiple transactions in parallel at the same time, and generate multiple log files to record the execution of each transaction. The server distinguishes different transactions by the transaction identification carried in the transaction information.

[0111] For example, Figure 7 As shown, it is a schematic diagram of the log file after the transaction information is processed in the embodiment of the present application, and PubKey is used to encrypt the transaction party identity UserA in the transaction party public key PubKey verification module to obtain the ciphertext hfgjkdshjdhsfjka; the Transaction Execution module is added to the log file to record the transaction execution status in the master node, wherein Transaction Result indicates that the hash value corresponding to the transaction result is Ox93efc72abocx45gsdf13djks, and Time indicates that the time consumed for transaction processing is 20s.

[0112] In another possible implementation, based on the Zipkin service, a first child span is created to record transaction execution status, and the child span also includes a target transaction identifier, a first child span identifier, and a parent identifier, that is, the root span identifier.

[0113] In this way, the transaction execution results and transaction time within the master node are recorded in the log file or Span, which is convenient for maintenance personnel to grasp the details of the transaction execution; at the same time, the transaction party's identity is encrypted to avoid the leakage of the transaction party's privacy data after the master node sends the log file to the server. That is, only by using the transaction party's private key PriKey can the encrypted transaction party's identity be decrypted, thereby determining the transaction party corresponding to the log file.

[0114] Step 33: Broadcast the transaction information and transaction results to other nodes in the blockchain for transaction verification, and receive the transaction verification results returned by each other node respectively, and associate the other node identifiers of each other node with the corresponding transaction verification results and record them in the log file.

[0115] Specifically, Figure 8 As shown, it is a schematic diagram of the interaction between the master node and the slave node in the embodiment of the present application. Figure 8 , and explain the specific execution steps in detail:

[0116] Step 801: The master node processes the transaction information and obtains a first transaction result.

[0117] Step 802: The master node performs hash calculation on the first transaction result to obtain a first hash value;

[0118] Step 803: The master node sends the first hash value and transaction information to the slave node;

[0119] Step 804: The slave node executes the transaction according to the transaction information to obtain a second transaction result;

[0120] Step 805: The slave node performs hash calculation on the second transaction result to obtain a second hash value;

[0121] Step 806: The slave node compares the first hash value and the second hash value to obtain a transaction verification result;

[0122] Step 807: The slave node sends its own node identification and transaction verification result to the master node;

[0123] Step 808: The master node records the slave node identification and transaction verification results in a log file.

[0124] For example, suppose the slave node is Figure 2 Nodes 212, 213, and 214 in the blockchain, the master node 211 calls the relevant smart contract from the contract warehouse, processes the transaction information to obtain the transaction result, performs hash calculation on the transaction result, obtains the corresponding hash value, and broadcasts the transaction information and the hash value corresponding to the transaction result to other slave nodes in the blockchain for consensus. After each slave node receives the transaction information and transaction result sent by the master node 211, it also calls the relevant smart contract from the contract warehouse to execute the transaction and obtain the transaction result. The electronic assets owned by UserA and UserB after the electronic asset exchange are used as the transaction result, and a hash function is used to perform hash calculation on the transaction result to obtain the corresponding hash value, which is compared with the hash value corresponding to the transaction result of the master node. If the two hash values ​​are the same, the transaction verification is passed, otherwise, the transaction verification fails.

[0125] like Fig. 9 As shown in the figure, it is a schematic diagram of the log file after obtaining the transaction verification results of the slave nodes in the embodiment of the present application. As shown in the Consensus module, the transaction verification results of the slave nodes 117.114.151.174, 119.123.789.258, 117.114.151.175, and 117.116.189.146 are all passed, and the transaction verification result of the slave node 117.116.189.145 is not passed. In addition, the time taken for each slave node to perform transaction verification is recorded.

[0126] In another possible implementation, after receiving the transaction information sent by the master node, each other slave node on the alliance chain verifies the legitimacy of the public key of the transaction party in the transaction information, and verifies the authority of the transaction based on the transaction identification number; each other slave node is installed with a Zipkin client, and records the legitimacy verification and transaction authority verification by creating a second child Span. In addition, the second child Span also includes the target transaction identifier, the second child Span identifier and the parent identifier, that is, the above-mentioned root Span identifier; the Zipkin client is installed on each other slave node, and the second child Span is created to record the legitimacy verification and transaction authority verification. Fig. 9 The content of the Consensus module shown in the figure. In addition, the grandchild span also contains the target transaction identifier, grandchild span identifier and parent span identifier, that is, the second child span identifier. After each slave node sends the second child span and grandchild span to the master node, the master node reports all spans to the Zipkin server through the installed Zipkin client.

[0127] In this way, operation and maintenance personnel can obtain the transaction verification results of each node by viewing the log files or spans on the server side, locate the nodes where transaction verification fails, and investigate the causes of failure. At the same time, by conducting a time analysis based on the time consumed for transaction verification at each node, it is possible to monitor whether there are any functional or performance abnormalities at each node server.

[0128] Furthermore, in a possible implementation, after receiving the transaction verification results returned by the other slave nodes, the master node can also generate a new block based on the executed transactions, such as Fig.10 As shown, it is a schematic diagram of the process of generating a new block in the embodiment of the present application. Fig.10 , the specific execution steps 331-334 are described in detail:

[0129] Step 331: Based on the received transaction verification results, obtain the verification pass number.

[0130] For example, according to Fig. 9 From the transaction verification results shown, it can be seen that among the transaction verification results of the 5 slave nodes, 4 passed and 1 failed, so the calculated verification pass number is 4.

[0131] Step 332: Determine whether the number of verification passes is less than a preset threshold. If so, execute step 334; otherwise, execute step 333.

[0132] Step 333: Package the transaction information and transaction results into a block and add it to the blockchain, and record the block identifier of the block in the log file. For example, when the preset threshold is set to 3, the number of verification passes is 4, which is greater than the preset threshold, then the transaction is successful, and the transaction information and transaction results are packaged into a new block and added to the block ledger of the blockchain. The transaction information and transaction results are used as input information, and the eigenvalue algorithm SHA256 is used to calculate the eigenvalue corresponding to the input information, and the eigenvalue is recorded as a block identifier in the log file. At the same time, the master node and each slave node update the status data in the storage module, including the electronic assets of UserA and UserB and the status of the smart contract. The above new block is generated by the following method:

[0133] Verify the input information. After verification, store the input information in the memory pool and update the hash tree used to record the input information. Then, update the update timestamp to the time when the input information is received, try different random numbers, and calculate the eigenvalue multiple times so that the calculated eigenvalue can satisfy the following formula:

[0134] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x)) <TARGET

[0135] Among them, SHA256 is the eigenvalue algorithm used to calculate the eigenvalue; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header eigenvalue of the parent block of the current block; merkle_root is the eigenvalue of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value within a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the eigenvalue threshold, which can be determined based on nbits.

[0136] In an embodiment of the present application, after packaging the transaction information and transaction results into a block, the master node also broadcasts the block to other slave nodes, and associates the target transaction identifier with the block broadcast event identifier and records it in a log file.

[0137] For example, in Fig. 9 The block consensus module is added to the log file shown, and the target transaction identifier "Tr100" and the broadcast event identifier "broadcast" are recorded.

[0138] In another possible implementation, the target transaction identifier and the block broadcast event identifier are recorded in the aforementioned first sub-Span, and the Zipkin client reports the Span to the Zipkin server.

[0139] Step 334: End the target transaction, record the number of verification passes, the preset threshold, and the consensus failure result in a log file, and send the log file to the server.

[0140] For example, in Fig. 9 A consensus result module is added to the log file shown in the figure. The number of verification passes, the preset threshold and the consensus result "Failed" are recorded in the consensus result module, so that maintenance personnel can grasp the details of consensus failure in a timely manner.

[0141] Step 34: Send the log file to the server, so that the server can search for the corresponding log file based on the target transaction identifier, and analyze the transaction status of the target transaction based on the node identifier, transaction information, transaction results, other node identifiers and corresponding transaction verification results.

[0142] In the embodiment of the present application, when the server stores multiple log files, since the corresponding transaction identifiers are recorded in each log file, the server can find the corresponding log file according to the target transaction identifier. According to the log file corresponding to the target transaction, the server can monitor the transaction execution status of the target transaction throughout its life cycle, locate the node server that may have abnormal conditions, and promptly investigate the causes of the abnormal conditions to improve transaction efficiency.

[0143] In another possible implementation, when the Zipkin server collects multiple spans, it finds the spans corresponding to the target transaction through the target transaction identifier, and then links the spans into a complete transaction monitoring link based on the parent span identifier recorded in each span, so as to analyze the transaction execution status and transaction time consumption.

[0144] In practical applications, the technical solutions provided in the embodiments of the present application can also be applied in the following aspects:

[0145] 1. Blockchain performance monitoring and optimization: By monitoring the entire life cycle of transactions and the time consumed in each stage, developers and operation and maintenance personnel can discover performance bottlenecks in the system and optimize system performance in a targeted manner.

[0146] 2. Blockchain fault diagnosis and troubleshooting: This solution can help developers and operation and maintenance personnel quickly locate the specific links where the problem occurs, thereby improving the efficiency of fault diagnosis and troubleshooting. This is of great significance for ensuring the stable operation of the blockchain system and reducing maintenance costs.

[0147] 3. Blockchain security audit: By encrypting and protecting sensitive data in the contract process, this solution can ensure that user privacy is not leaked. This makes the blockchain system suitable for more application scenarios involving sensitive data, such as finance, medical care, government affairs, etc.

[0148] 4. Blockchain visualization analysis: This solution can provide developers and operation and maintenance personnel with an intuitive visualization interface to display the execution status of transactions at each stage, which helps to improve the management efficiency of the blockchain system and reduce the difficulty of operation and maintenance.

[0149] 5. Blockchain customer support: By providing detailed information on the entire life cycle of a transaction, customers can better understand the progress of the transaction, thereby improving customer satisfaction with the system. In addition, this also helps the customer support team quickly locate and solve problems encountered by customers.

[0150] In summary, this solution has a wide range of application scenarios in blockchain performance monitoring and optimization, fault diagnosis and troubleshooting, security auditing, visual analysis, and customer support, which will help improve the performance, availability, security, and user experience of the blockchain system.

[0151] On the other hand, the embodiment of the present application also provides a second flow chart of a transaction monitoring method, which will be described below in conjunction with Fig.11A and Fig. 11B The specific execution steps are described in detail:

[0152] Step 1101: Obtain transaction information of the target transaction.

[0153] The transaction information includes the target transaction identifier and the public key of the transaction party.

[0154] Step 1102: Verify the legitimacy of the public key of the transaction party. If the legitimacy verification passes, execute step 1103; otherwise, execute step 1104.

[0155] Step 1103: The node identification, transaction information and legitimacy verification result are recorded in a log file in association.

[0156] Step 1104: associate the node identification, transaction information and the result of the legality verification failure and record them in a log file, and then execute step 1113.

[0157] Step 1105: Perform transaction processing on the transaction information to obtain the transaction result.

[0158] Step 1106: Use the transaction party's public key to encrypt the transaction party's identity in the transaction information.

[0159] Step 1107: associate the node identification, transaction information and transaction results and record them in a log file.

[0160] Step 1108: Broadcast the transaction information and transaction results to other nodes in the blockchain.

[0161] Step 1109: Receive transaction verification results returned by other nodes.

[0162] Step 1110: associate other node identifiers and corresponding transaction verification results and record them in a log file;

[0163] Step 1111: Calculate the number of transaction verification passes and determine whether it is greater than a preset threshold. If so, execute step 1112; otherwise, execute step 1113.

[0164] Step 1112: Package the transaction information and transaction results into blocks and add them to the blockchain, and record the block identifier in the log file.

[0165] Step 1113: End the target transaction.

[0166] Step 1114: Send the log file to the server.

[0167] Based on the same technical concept, see Fig.12 As shown, the embodiment of the present application also provides a transaction monitoring device, which includes:

[0168] The information acquisition module 1201 is used to acquire the transaction information of the target transaction; the transaction information carries the target transaction identifier;

[0169] The first recording module 1202 is used to perform transaction processing on the transaction information to obtain the transaction result, and to encrypt the transaction party identity in the transaction information based on the transaction party public key to obtain the encrypted transaction information, and to associate the node identity of the blockchain node, the encrypted transaction information and the transaction result and record them in a log file;

[0170] The second recording module 1203 is used to broadcast the transaction information and transaction results to other nodes in the blockchain for transaction verification, and respectively receive the transaction verification results returned by the other nodes, and respectively associate the other node identifiers of the other nodes with the corresponding transaction verification results and record them in a log file;

[0171] The log sending module 1204 is used to send the log file to the server so that the server can decrypt the encrypted transaction party identity based on the transaction party's private key, and analyze the transaction status of the target transaction based on the node identification, transaction information, transaction results, other node identifications and corresponding transaction verification results.

[0172] Optionally, if the transaction information carries a public key certificate including a public key and a digital signature of a transaction party, after obtaining the transaction information of the target transaction and before performing transaction processing on the transaction information, the first recording module 1202 is further configured to:

[0173] Based on the digital signature, the legitimacy of the public key of the transaction party is verified; the public key and the private key of the transaction party constitute a public-private key pair; the public-private key pair is generated by the terminal that sends the transaction information.

[0174] When the public key of the transaction party passes the legitimacy verification, the node identification, transaction information and legitimacy verification result are associated and recorded in the log file.

[0175] Optionally, the first recording module 1202 is further used for:

[0176] When the public key of the transaction party fails the legitimacy verification, the target transaction is terminated, and the node identification, transaction information and the legitimacy verification failure result are associated and recorded in the log file, and the log file is sent to the server.

[0177] Optionally, if the transaction information includes the identity of the transaction party, after obtaining the transaction result and before associating and recording the node identifier, the transaction information, and the transaction result of the node in the log file, the first recording module 1202 is further configured to:

[0178] The transaction party's identity is encrypted based on the transaction party's public key, so that the server can decrypt the encrypted transaction party's identity after obtaining the transaction party's private key.

[0179] Optionally, after receiving the transaction verification results returned by each other node and before sending the log file to the server, the second recording module 1203 is further used to:

[0180] Based on the received verification results of each transaction, obtain the verification pass number;

[0181] When the number of verification passes is not less than the preset threshold, the transaction information and transaction results are packaged into blocks and added to the blockchain, and the block identifier of the block is recorded in the log file.

[0182] Optionally, the second recording module 1203 is further used for:

[0183] When the number of verification passes is less than the preset threshold, the target transaction is terminated, and the number of verification passes, the preset threshold and the consensus failure result are recorded in the log file, and the log file is sent to the server.

[0184] Optionally, the second recording module 1203 is further used for:

[0185] Broadcast the block to other block nodes, and associate the target transaction ID with the block broadcast event ID in the log file.

[0186] Optionally, the second recording module 1203 is further used for:

[0187] The transaction events and the corresponding time spent in the transaction process of the target transaction are respectively recorded in a log file, and the log file is sent to the server so that the server can analyze the transaction situation of the target transaction. The log sending module 1204 is also used to:

[0188] The log file is sent to the server so that the server can perform a time consumption analysis on the target transaction based on the time consumption of each transaction event.

[0189] Based on the same technical concept, an embodiment of the present application also provides an electronic device, which can implement the method flow of transaction monitoring provided in the above embodiment of the present application.

[0190] In one embodiment, the electronic device may be a server, or a terminal device or other electronic device.

[0191] See also Fig.13 As shown, the electronic device may include:

[0192] At least one processor 1301, and a memory 1302 connected to the at least one processor 1301. The specific connection medium between the processor 1301 and the memory 1302 is not limited in the embodiment of the present application. Fig.13In the example, the processor 1301 and the memory 1302 are connected via the bus 1300. The bus 1300 is Fig.13 The bus 1300 is represented by a bold line, and the connection between other components is only for schematic illustration and is not intended to be limiting. The bus 1300 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.13 Only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus. Alternatively, the processor 1301 can also be called a controller, and there is no limitation on the name.

[0193] In the embodiment of the present application, the memory 1302 stores instructions that can be executed by at least one processor 1301. The at least one processor 1301 can execute a transaction monitoring method discussed above by executing the instructions stored in the memory 1302. The processor 1301 can implement Fig.12 The functions of each module in the device shown.

[0194] Among them, the processor 1301 is the control center of the device, which can use various interfaces and lines to connect the various parts of the entire control device, and monitor the device as a whole by running or executing instructions stored in the memory 1302 and calling the data stored in the memory 1302, the various functions of the device and processing data.

[0195] In one possible design, the processor 1301 may include one or more processing units, and the processor 1301 may integrate an application processor and a modem processor, wherein the application processor mainly processes an operating system, a user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the modem processor may not be integrated into the processor 1301. In some embodiments, the processor 1301 and the memory 1302 may be implemented on the same chip, and in some embodiments, they may also be implemented separately on separate chips.

[0196] Processor 1301 may be a general-purpose processor, such as a CPU, a digital signal processor, an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, and may implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present application. A general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of a transaction monitoring method disclosed in the embodiments of the present application may be directly embodied as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor.

[0197] Memory 1302 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules. Memory 1302 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (Random Access Memory, RAM), static random access memory (Static Random Access Memory, SRAM), programmable read-only memory (Programmable Read Only Memory, PROM), read-only memory (Read Only Memory, ROM), electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), magnetic memory, disk, optical disk, etc. Memory 1302 is any other medium that can be used to carry or store a desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited thereto. The memory 1302 in the embodiment of the present application can also be a circuit or any other device that can realize a storage function, for storing program instructions and / or data.

[0198] By programming the processor 1301, the code corresponding to the transaction monitoring method described in the above embodiment can be fixed into the chip, so that the chip can execute the code when running. Figure 3 The steps of a transaction monitoring method in the embodiment shown are as follows: How to design and program the processor 1301 is a technique known to those skilled in the art and will not be described in detail here.

[0199] Based on the same inventive concept, an embodiment of the present application further provides a storage medium, which stores computer instructions. When the computer instructions are executed on a computer, the computer executes a transaction monitoring method discussed above.

[0200] In some possible implementations, various aspects of a transaction monitoring method provided by the present application may also be implemented in the form of a program product, which includes a program code. When the program product is run on an apparatus, the program code is used to enable the control device to execute the steps of a transaction monitoring method according to various exemplary implementations of the present application described above in this specification.

[0201] It should be noted that, although several units or subunits of the device are mentioned in the above detailed description, this division is merely exemplary and not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided into multiple units to be embodied.

[0202] In addition, although the operations of the method of the present application are described in a specific order in the drawings, this does not require or imply that the operations must be performed in this specific order, or that all the operations shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0203] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0204] The present application is described with reference to the flowchart and / or block diagram of the method, device (system), and computer program product according to the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the process and / or box in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the function specified in one process or multiple processes in the flowchart and / or one box or multiple boxes in the block diagram.

[0205] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0206] These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0207] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A transaction monitoring method, characterized in that: Blockchain nodes used in consortium chains include: Acquire transaction information of a target transaction; the transaction information includes an identity identifier of a transaction party; Performing transaction processing on the transaction information to obtain a transaction result, and encrypting the identity of the transaction party in the transaction information based on the public key of the transaction party to obtain encrypted transaction information, and recording the node identifier of the blockchain node, the encrypted transaction information and the transaction result in a log file in association with each other; Broadcasting the transaction information and the transaction result to other blockchain nodes in the blockchain for transaction verification, and receiving the transaction verification results returned by the other blockchain nodes respectively, and recording the other node identifiers of the other blockchain nodes and the corresponding transaction verification results in the log file in association with each other; The log file is sent to the server, so that the server decrypts the encrypted transaction party identity based on the transaction party's private key, and analyzes the transaction status of the target transaction based on the node identifier, the transaction information, the transaction result, the other node identifiers and the corresponding transaction verification results.

2. The method according to claim 1, characterized in that The transaction information carries a public key certificate containing the public key and digital signature of the transaction party; After acquiring the transaction information of the target transaction and before performing transaction processing on the transaction information, the method further includes: Based on the digital signature, the legitimacy of the public key of the transaction party is verified; the public key of the transaction party and the private key of the transaction party form a public-private key pair; the public-private key pair is generated by the terminal that sends the transaction information; When the transaction party public key passes the legitimacy verification, the node identifier, the transaction information and the legitimacy verification result are associated and recorded in the log file.

3. The method according to claim 2, characterized in that Also includes: When the public key of the transaction party fails the legitimacy verification, the target transaction is terminated, and the node identifier, the transaction information and the legitimacy verification failure result are associated and recorded in the log file, and the log file is sent to the server.

4. The method according to any one of claims 1 to 3, characterized in that: After receiving the transaction verification results returned by the other blockchain nodes and before sending the log file to the server, the method further includes: Based on the received verification results of each transaction, obtain the verification pass number; When the number of verification passes is not less than a preset threshold, the transaction information and the transaction result are packaged into a block and added to the blockchain, and the block identifier of the block is recorded in the log file.

5. The method according to claim 4, characterized in that Also includes: When the number of verification passes is less than a preset threshold, the target transaction is terminated, and the number of verification passes, the preset threshold and the consensus failure result are recorded in the log file, and the log file is sent to the server.

6. The method according to claim 4, characterized in that The transaction information includes a target transaction identifier; Then the sending of the log file to the server so that the server performs transaction analysis on the target transaction also includes: The log file is sent to a server, so that the server searches for the corresponding log file based on the target transaction identifier.

7. The method according to claim 6, characterized in that Also includes: The block is broadcasted to each of the other block nodes, and the target transaction identifier and the block broadcast event identifier are associated and recorded in the log file.

8. The method according to claim 7, characterized in that The respectively associating and recording the other node identifiers of the other blockchain nodes and the corresponding transaction verification results in the log file further includes: Respectively recording in the log file the transaction events and the corresponding time consumed in the transaction process of the target transaction; Then the sending of the log file to the server so that the server performs transaction analysis on the target transaction also includes: The log file is sent to a server, so that the server performs a time consumption analysis on the target transaction based on the time consumption of each transaction event.

9. A transaction monitoring device, characterized in that: include: An information acquisition module, used to acquire transaction information of a target transaction; The transaction information includes the identity of the transaction party; A first recording module is used to perform transaction processing on the transaction information to obtain a transaction result, and to encrypt the identity identifier of the transaction party in the transaction information based on the public key of the transaction party to obtain encrypted transaction information, and to associate and record the node identifier of the blockchain node, the encrypted transaction information and the transaction result in a log file; A second recording module is used to broadcast the transaction information and the transaction result to other blockchain nodes in the blockchain for transaction verification, and respectively receive the transaction verification results returned by the other blockchain nodes, and respectively associate and record other node identifiers of the other blockchain nodes and corresponding transaction verification results in the log file; The log sending module is used to send the log file to the server so that the server can decrypt the encrypted transaction party identity based on the transaction party's private key, and analyze the transaction situation of the target transaction based on the node identifier, the transaction information, the transaction result, the other node identifiers and the corresponding transaction verification results.

10. An electronic device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 8 is implemented.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented.

12. A computer program product, characterized in that When the computer program product is called by a computer, the computer executes the method according to any one of claims 1 to 8.

Images