A method, system and device for consensus transaction trajectory visualized tracking

Abstract

The application discloses a kind of consensus transaction trajectory visual tracking method, including the following steps: S110: embedding custom log in Hyperledger Fabric consensus transaction key source code;S120: the running transaction log generated in Hyperledger Fabric node container is collected, and the custom log embedded in step S110;S130: the content of custom log collected in step S120 is parsed;S140: custom log content is converted into point edge relationship by logical processing.This embodiment of the application is based on the technical field of blockchain node tracking and visualization supervision, using log analysis technology, to restore the calling track between nodes in the consensus transaction process in a visual manner.On the one hand, it fills the gap in the technical field of blockchain node tracking and visualization supervision, and on the other hand, based on the tracked calling data, it facilitates subsequent research on detecting abnormal blockchain transaction behavior.

Description

Technical Field

[0001] This invention relates to the field of blockchain regulatory technology, specifically to a method, system, and device for visually tracking consensus transaction trajectories. Background Technology

[0002] Blockchain technology boasts advantages such as immutability, transparency, traceability, and decentralization, making it an essential infrastructure for building trust among on-chain participants. According to available data, blockchain technology has already been applied in various fields and scenarios, including software engineering, electronic voting, government services, smart transportation, supply chain management, education, financial transactions, healthcare, and microgrids.

[0003] However, the development of blockchain technology has also brought significant pressure and challenges to the current regulatory environment. For example, the decentralized nature of blockchain leads to fragmented regulatory bodies; its anonymity and immutability make it difficult to regulate on-chain content. Furthermore, the development of blockchain technology has also brought about many negative phenomena, such as the misuse of the blockchain concept; the spread of online rumors, inflammatory rhetoric, and offensive language using blockchain as a medium; and even instances of using blockchain as a gimmick to conduct illegal activities. In addition, security incidents related to blockchain have occurred frequently in recent years, revealing that the blockchain technology itself, as well as decentralized applications based on it, also have security risks.

[0004] Blockchain node tracking and visualization involves constructing a "graph" of all nodes in a blockchain. For consortium blockchains, regulators, in addition to focusing on basic node information, also pay close attention to the consensus transaction process, as the consensus mechanism involved in these transactions is crucial for ensuring the consistency and immutability of the ledger. By monitoring the consensus transaction process, regulators can clearly control details such as whether the transaction initiator, transaction processor, and endorsement strategies involved in the transaction meet the preset effects, and whether newly generated blocks are synchronously submitted to the local ledgers of peer nodes.

[0005] However, research and solutions for regulatory technologies involving blockchain node tracking and visualization are still in their infancy.

[0006] To address the above situation, we need a method, system, and device for visually tracking consensus transaction trajectories. Based on the regulatory technology of blockchain node tracking and visualization, this system employs log analysis technology to visually reconstruct the call trajectories between nodes during Hyperledger Fabric consensus transactions. This fills the gap in regulatory technology for blockchain node tracking and visualization, and the tracked call data facilitates subsequent research into detecting abnormal blockchain transaction behavior. Summary of the Invention

[0007] The purpose of this invention is to provide a method, system, and device for visually tracking consensus transaction trajectories, in order to solve the problems mentioned in the background art.

[0008] To solve the above-mentioned technical problems, the present invention provides the following technical solution: a method for visually tracking consensus transaction trajectories, characterized by comprising the following steps:

[0009] S110: Embed custom logs in the key source code of Hyperledger Fabric consensus transactions;

[0010] S120: Collect the running transaction logs generated in the Hyperledger Fabric node container, which includes the running transaction logs that come with Hyperledger Fabric and the custom logs embedded in step S110;

[0011] S130: Parse the custom log content collected in step S120;

[0012] S140: Perform logical processing on custom log content to convert it into point-edge relationships;

[0013] S150: Visualize datasets of vertex-edge relationships using Graphin, which focuses on graph analysis;

[0014] The node container is a Peer or Orderer node container launched in the Hyperledger Fabric network.

[0015] Graphin is an open-source React component library based on G6, developed by Ant Group.

[0016] Furthermore, in step S110, embedding custom logs in the key source code of Hyperledger Fabric consensus transactions includes:

[0017] Add a custom log to the entry point for Hyperledger Fabric endorsement service processing;

[0018] Add a custom log to the entry point for Hyperledger Fabric broadcast service processing;

[0019] Add a custom log to the entry point of the Hyperledger Fabric block distribution service processing;

[0020] Add a custom log to the entry point of the Hyperledger Fabric method for committing block data to the local ledger;

[0021] The endorsement service is served by Client nodes on the client side and Peer nodes on the server side. Peer nodes register the endorsement service with the local gRPC server upon startup.

[0022] The client for the broadcast service is a Client node, and the server is an Orderer node. The Orderer node registers the broadcast service with the local gRPC server when it starts up.

[0023] The block distribution service's client is the Leader Peer node, and the server is the Orderer node. The Orderer node registers the block distribution service with its local gRPC server upon startup.

[0024] The Client node is a client node that interacts with the Hyperledger Fabric network.

[0025] The Orderer node is the Orderer node used for sorting in the Hyperledger Fabric network.

[0026] The Leader Peer node is the master / leader peer node set up in the Hyperledger Fabric network.

[0027] Furthermore, in step S110, adding a custom log to the entry point of the endorsement service processing includes:

[0028] When the endorsement service in the Endorser Peer node receives the endorsement service request from the Client node, it prints a log representing the endorsement service request call.

[0029] Before the endorsement service in the Endorser Peer node returns the transaction proposal response to the Client node, it prints a log representing the endorsement service response.

[0030] The Endorser Peer node is a Peer node in the Hyperledger Fabric network that serves as an endorsement service.

[0031] The printed custom log content representing endorsement service requests and responses includes: the IP address of the endorsement client, the domain name information of the endorsement server, the identifier representing the endorsement service, the consensus transaction ID, the channel ID, the identifier that distinguishes it from the original Hyperledger Fabric transaction log, and the timestamp.

[0032] Furthermore, in step S110, adding a custom log to the broadcast service processing entry point includes:

[0033] After receiving the transaction ordering service request from the Client node, the broadcast server in the Orderer node prints a log representing the broadcast service request call.

[0034] Before the broadcast server in the Orderer node returns the transaction proposal response to the Client node, it prints a log representing the broadcast service response.

[0035] The printed custom log content representing broadcast service requests and responses includes: the IP address of the broadcast client, the domain name information of the broadcast server, the identifier representing the broadcast service, the consensus transaction ID, the channel ID, the identifier that distinguishes it from the original Hyperledger Fabric transaction log, and the timestamp.

[0036] Furthermore, in step S110, adding a custom log to the block distribution service processing entry includes:

[0037] After receiving block data from the Orderer node, the client of the block distribution service in the Leader Peer node prints a processing log representing the block distribution service.

[0038] Before the block distribution service client in the Leader Peer node sends a Gossip message, print a log representing the forwarding of the Gossip message;

[0039] The printed processing log content representing the block distribution service includes: the domain name information of the block distribution client, the domain name information of the block distribution service, the identifier representing the block distribution service, the consensus transaction ID, the channel ID, the identifier that distinguishes it from the original Hyperledger Fabric transaction log, and the timestamp.

[0040] The log content printed to represent the forwarding of Gossip messages includes: the domain name information of the current Peer node, the organization name to which the Gossip message is forwarded, the identifier representing the forwarding of the Gossip message, the consensus transaction ID, the channel ID, the identifier that distinguishes it from the original Hyperledger Fabric transaction log, and the timestamp.

[0041] Furthermore, in step S110, adding a custom log at the entry point of the method for submitting block data to the local ledger includes: processing Gossip messages and parsing block information in the Committer Peer node of the Hyperledger Fabric network, submitting the block to the local ledger, and printing a log representing the processing of Gossip messages.

[0042] The Committer Peer node is a peer node in the Hyperledger Fabric network used for ledger recording.

[0043] The log content printed to represent Gossip message processing includes: the domain name information of the current Peer node, the organization name to which the current Peer node belongs, the identifier representing Gossip message processing, the consensus transaction ID, the channel ID, the identifier that distinguishes it from the original Hyperledger Fabric transaction log, and the timestamp.

[0044] Furthermore, step S140, which involves logically processing the custom log content to convert it into point-edge relationships, also includes:

[0045] Treat the sender information in the custom log as a dot;

[0046] Treat the recipient information in the custom log as dots;

[0047] Treat the custom log itself as an edge;

[0048] Treat the gRPC service identifier in the custom log as the label of the edge;

[0049] Treat the timestamps in the custom log as the times when the edges were generated.

[0050] A consensus transaction trajectory visualization and tracking system, comprising:

[0051] The transaction log collection unit is used to collect the transaction logs of Peer nodes and Orderer node containers in the Hyperledger Fabric network.

[0052] A custom log parsing unit is used to identify custom log content from the transaction log collection unit and parse the custom log content.

[0053] The log storage unit is used to store the log data after it has been parsed.

[0054] A custom log logic processing unit is used to retrieve custom log content from the log storage unit and convert it into point-edge relationships;

[0055] A custom log visualization unit is used to render the point-edge dataset using Graphin after the custom log logic has been processed, and to draw the trajectory of Hyperledger Fabric consensus transactions.

[0056] A consensus transaction trajectory visualization and tracking device includes: a processor and a memory.

[0057] The processor may be one or more;

[0058] The memory is used to store one or more programs.

[0059] Compared with existing technologies, the beneficial effects achieved by this invention are as follows: This invention embeds custom logs into the key source code of Hyperledger Fabric consensus transactions; then collects the runtime transaction logs generated in Hyperledger Fabric node containers; then parses out the custom log content; next, logically processes the custom log content to convert it into node-edge relationships; finally, it uses Graffin, a graph analytics-focused technology, to visualize the node-edge relationship dataset. This invention, based on the regulatory technology of blockchain node tracking and visualization, employs log analysis technology to visually reconstruct the call trajectories between nodes during Hyperledger Fabric consensus transactions. On the one hand, it fills the gap in regulatory technology for blockchain node tracking and visualization; on the other hand, based on the tracked call data, it facilitates subsequent research on detecting abnormal blockchain transaction behavior. Attached Figure Description

[0060] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0061] Figure 1 This is a flowchart illustrating a method for visually tracking consensus transaction trajectories according to Embodiment 1 of the present invention;

[0062] Figure 2 This is a schematic diagram of a custom log embedded in the Hyperledger Fabric source code location according to Embodiment 1 of the present invention;

[0063] Figure 3 This is a schematic diagram of a process for embedding custom logs in the key source code of Hyperledger Fabric consensus transactions, according to Embodiment 1 of the present invention.

[0064] Figure 4 A schematic diagram illustrating the principle of converting custom log content into point-edge relationships in Embodiment 1 of the present invention;

[0065] Figure 5 This is a schematic diagram of a process for converting custom log content into point-edge relationships in Embodiment 1 of the present invention;

[0066] Figure 6 This is a flowchart illustrating a consensus transaction trajectory visualization and tracking system according to Embodiment 2 of the present invention;

[0067] Figure 7 This is a schematic diagram illustrating the visualization effect of a consensus transaction trajectory visualization tracking system according to Embodiment 2 of the present invention. Detailed Implementation

[0068] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0069] Please see Figure 1-7 The present invention provides a technical solution: Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but may also have additional steps not included in the figures. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0070] The term "Client node" used in this article refers to a client node that interacts with the Hyperledger Fabric network. This interaction can be achieved by calling the APIs or SDKs provided by Hyperledger Fabric, or directly through the CLI command-line terminal.

[0071] The term "Endorser Peer node" used in this article refers to a peer node that acts as an endorser in a Hyperledger Fabric network.

[0072] The term "Orderer node" as used in this article refers to the Orderer node in a Hyperledger Fabric network that acts as the orderer.

[0073] The term "Leader Peer node" used in this article refers to the master / leader peer node set up in a Hyperledger Fabric network, primarily to alleviate the pressure on the Orderer node in distributing blocks. By setting up a Leader Peer node, the Orderer node does not need to distribute blocks to all peer nodes within a specified channel, but only to the Leader Peer node.

[0074] The term "Committer Peer node" used in this article refers to the peer node in the Hyperledger Fabric network used for ledger recording. The Committer Peer node parses block data from Gossip messages, verifies the validity of the block data, and commits the block to the local ledger after successful verification.

[0075] The term "endorsement service" used in this article refers to the endorsement service provided by Hyperledger Fabric. Specifically, it refers to the "ProcessProposal" gRPC service located in the peer / peer.proto path within the fabric-proto project. The client for this service is the Client node, and the server is the Peer node. Upon startup, the Peer node registers the endorsement service with its local gRPC server. The endorsement service receives endorsement requests from Client nodes, then initiates user chaincode to simulate transaction execution, finally signs the simulated execution result, and returns it to the Client node.

[0076] The term "broadcast service" used in this article refers to the broadcast service provided by Hyperledger Fabric. Specifically, it refers to the "Broadcast" gRPC service located at ` / orderer / ab.proto` in the `fabric-proto` project. The client for this service is the Client node, and the server is the Orderer node. The Orderer node registers the broadcast service with its local gRPC server upon startup. The broadcast service receives transaction ordering requests from Client nodes, which are then ordered and processed by the Orderer node to produce blocks.

[0077] The term "block distribution service" used in this article refers to the block distribution service provided by Hyperledger Fabric. Specifically, it refers to the "Deliver" gRPC service located at ` / orderer / ab.proto` in the `fabric-proto` project. The client for this service is the Leader Peer node, and the server is the Orderer node. The Orderer node registers the block distribution service with its local gRPC server upon startup. The Orderer node distributes newly generated blocks to the Leader Peer nodes through the block distribution service. The Leader Peer nodes then receive the blocks and disseminate them to other Peer nodes within the same organization via Gossip messages, ensuring data synchronization.

[0078] The term "node container" used in this article refers to the Peer and Orderer node containers launched in a Hyperledger Fabric network.

[0079] The term "Graphin" used in this article refers to a React component library based on G6, which was open-sourced by Ant Group.

[0080] For ease of understanding, the main inventive concepts of the embodiments of the present invention will be briefly described.

[0081] Example 1

[0082] Figure 1 This is a flowchart illustrating a method for visually tracking consensus transaction trajectories according to Embodiment 1 of the present invention. The technical solution of this embodiment is applicable to the Hyperledger Fabric network, enabling visual tracking of the call trajectories of each node in a consensus transaction. The supervisory node can be launched as a node container in Hyperledger Fabric and participate in the Hyperledger Fabric network.

[0083] The method described in this embodiment can be executed by a consensus transaction trajectory visualization and tracking device, which can be implemented in hardware and / or software. The method specifically includes the following steps:

[0084] S110. Embed custom logs in the key source code of Hyperledger Fabric consensus transactions.

[0085] This requires specifying the location of the custom logs within the Hyperledger Fabric source code and the content of the custom logs.

[0086] Custom log embedding location reference Figure 2 , Figure 2 This is a schematic diagram illustrating the principle of embedding custom logs into the Hyperledger Fabric source code in Embodiment 1 of the present invention. Because Hyperledger Fabric consensus transactions involve interactions between multiple nodes with different responsibilities, the detailed process of calling smart contracts to update the ledger is as follows:

[0087] (1) The Client node first constructs a transaction proposal and sends it to the EndorserPeer node through the endorsement service. When the EndorserPeer node receives the endorsement request from the Client node, it prints a custom log representing the endorsement request;

[0088] (2) After the Endorser Peer node finishes processing the endorsement service, before signing the simulated transaction execution result and sending it to the Client node, it prints a custom log representing the endorsement response.

[0089] (3) After receiving sufficient endorsement responses, the Client node sends a transaction ordering request to the Orderer node via broadcast service. When the Orderer node receives the broadcast request from the Client node, it prints a custom log representing the broadcast request;

[0090] (4) After the Orderer node finishes processing the broadcast service, before returning the success or failure status of the transaction ordering to the Client node, it prints a custom log representing the broadcast response.

[0091] (5) When an Orderer node discovers that a new block has been generated, it will distribute the new block to all Leader Peer nodes in the current channel through the block distribution service. When a Leader Peer node receives a block from an Orderer node, it prints a custom log representing the receipt of the block;

[0092] (6) After the Leader Peer node constructs a Gossip message, before synchronizing the block to other Peer nodes in the organization via the Gossip protocol, it prints a custom log representing the forwarding of the Gossip message.

[0093] (7) After the Committer Peer node receives the Gossip message, it parses the block data from the message and submits it to the local ledger, and then prints a custom log representing the processing of the Gossip message.

[0094] By using (1) and (2), the interaction trajectory between the Client node and the Endorser Peer node can be clearly identified, and the initiator and processor of the endorsement can be identified. By using (3) and (4), the interaction trajectory between the Client node and the Orderer node can be determined. By using (5), the interaction trajectory between the Orderer node and the Leader Peer node can be clearly identified, and the Leader Peer node of each organization can be identified by which Peer node in the organization is responsible for it. By using (6) and (7), it can be clearly identified which Peer nodes have submitted the blocks to the local ledger when synchronizing block data within the organization through the Gossip protocol.

[0095] In this embodiment, the names of the custom log content fields are not limited, but basic examples of custom log content are shown in Table 1:

[0096] Table 1

[0097]

[0098]

[0099] Because the combination of channel ID and transaction ID can uniquely identify a consensus transaction process in Hyperledger Fabric, the unrelated custom log information generated by Peer nodes and Orderer nodes in different consensus transaction stages in Hyperledger Fabric can be linked together using the combination of channel ID and transaction ID.

[0100] Figure 3 This is a schematic diagram illustrating a process for embedding custom logs in the key source code of Hyperledger Fabric consensus transactions, as described in Embodiment 1 of the present invention. Further, step S110 also includes:

[0101] S1101. Add a custom log to the entry point for Hyperledger Fabric endorsement service processing;

[0102] S1102. Add a custom log to the entry point for Hyperledger Fabric broadcast service processing;

[0103] S1103. Add a custom log to the entry point of Hyperledger Fabric block distribution service processing;

[0104] S1104. Add a custom log to the entry point of the Hyperledger Fabric method for submitting block data to the local ledger.

[0105] Step S1101 further includes:

[0106] 1) When the endorsement service in the Endorser Peer node receives the endorsement service request from the Client node, it prints a log representing the endorsement request call.

[0107] 2) Before the endorsement server in the Endorser Peer node returns the transaction proposal response to the Client node, print a log representing the endorsement response.

[0108] Since the endorsement service is a gRPC service, the endorsement server can resolve the IP address of the endorsement client using the "peer library" under the "grpc-go" package provided by the Golang official documentation. The endorsement server itself is an Endorser Peer node, and its domain name information can be obtained through the environment variables of the node container. Specifically, this can be obtained using the "getenv()" method in the "os library" provided by Goalng.

[0109] The log content representing endorsement requests and endorsement responses includes: the IP address of the endorsement client, the domain name information of the endorsement server, the identifier representing the endorsement service (e.g., "endorser"), the consensus transaction ID, the channel ID, the identifier that distinguishes it from the original Hyperledger Fabric transaction log (e.g., "for_trace_log"), and the timestamp.

[0110] Step S1102 further includes:

[0111] 1) After receiving the transaction ordering service request from the Client node, the broadcast server in the Orderer node prints a log representing the broadcast request call;

[0112] 2) Before the broadcast server in the Orderer node returns the transaction proposal response to the Client node, it prints a log representing the broadcast response.

[0113] Since the broadcast service is a gRPC service, the broadcast server can resolve the IP address of the broadcast client using the "peer library" under the "grpc-go" package provided by the Golang official documentation. The broadcast server itself is an Orderer node, and its domain name information can be obtained through the environment variables of the node container. Specifically, this can be obtained using the "getenv()" method in the "os library" provided by Goalng.

[0114] The custom log content for broadcast requests and responses is printed as follows: the IP address of the broadcast client, the domain name information of the broadcast server, the identifier representing the broadcast service (e.g., "broadcast"), the consensus transaction ID, the channel ID, the identifier that distinguishes it from the original Hyperledger Fabric transaction log (e.g., "for_trace_log"), and the timestamp.

[0115] Step S1103 further includes:

[0116] 1) After receiving the block data from the Orderer node, the block distribution client in the Leader Peer node prints a processing log representing the block distribution.

[0117] 2) Before the block distribution client in the Leader Peer node sends the Gossip message, print the log representing the Gossip message distribution.

[0118] When a Peer node joins a channel, it establishes a streaming connection with the Orderer node. At this time, an Orderer node is randomly selected from the configuration file, containing the Orderer node's domain name information. Once a Peer node is dynamically elected or statically configured as a Leader Peer node, its domain name information can be obtained through the node container's environment variables. Specifically, this can be obtained using the "getenv()" method in the "os library" provided by Goalng.

[0119] The processing log for block distribution is printed as follows: the domain name information of the block distribution client, the domain name information of the block distribution server, the identifier representing the block distribution service (e.g., "deliver"), the consensus transaction ID, the channel ID, the identifier that distinguishes it from the original Hyperledger Fabric transaction log (e.g., "for_trace_log"), and the timestamp.

[0120] When a Leader Peer node receives block data from an Orderer node via the block distribution service, it needs to construct a Gossip message and propagate it to the organization to which the Leader Peer node belongs using the Gossip protocol. At this point, data transmission is not done through gRPC, but rather through channels provided by Golang. Since Gossip forwarding is random, the recipient information in the custom log cannot be determined by IP address or domain name; instead, it should specify the organization name. The Leader Peer node's own domain name information can be obtained through the node container's environment variables. Specifically, it can be obtained using the `getenv()` method in the `os` library provided by Goalng.

[0121] The log content representing the distribution of Gossip messages includes: the domain name information of the current Leader Peer node, the organization name to which the Gossip message is forwarded (e.g., "org1"), the identifier representing the forwarding of the Gossip message (e.g., "gossip"), the consensus transaction ID, the channel ID, the identifier that distinguishes it from the original Hyperledger Fabric transaction log (e.g., "for_trace_log"), and the timestamp.

[0122] Step S1104 further includes:

[0123] 1) After receiving Gossip messages and parsing block information in the Committer Peer node, the block is committed to the local ledger, and a log representing the processing of Gossip messages is printed.

[0124] Because Gossip message forwarding ultimately results in the Committer Peer node receiving the data, parsing the block data, and then committing it to the local ledger, the sender information in the custom log content cannot be determined by IP address or domain name; instead, it indicates the organization name. The domain name information of the Committer Peer node itself can be obtained through the node container's environment variables. Specifically, it can be obtained using the "getenv()" method in the "os library" provided by Goalng.

[0125] The log content representing Gossip message processing is printed as follows: the domain name information of the current Committer Peer node, the organization name to which the current Peer node belongs (e.g., "org1"), the identifier representing Gossip message processing (e.g., "gossip"), the consensus transaction ID, the channel ID, the identifier that distinguishes it from the original Hyperledger Fabric transaction log (e.g., "for_trace_log"), and the timestamp.

[0126] S120. Collect runtime transaction logs generated in Hyperledger Fabric node containers.

[0127] In this embodiment, the form in which runtime transaction logs generated in Hyperledger Fabric node containers are collected is not limited. Hyperledger Fabric only supports logs being output in stderr (standard error output) format, and there are various forms of log collection. The purpose is to obtain runtime transaction logs generated in Hyperledger Fabric node containers, specifically including the runtime transaction logs that come with Hyperledger Fabric itself, as well as the custom log data introduced in this embodiment.

[0128] S130, Parse the custom log content.

[0129] In this embodiment, the method of parsing custom log content is not limited. The goal is to extract custom log information from all log content after the Hyperledger Fabric runtime logs have been collected. Custom logs are then extracted based on the identifiers contained within the custom log content that distinguish them from the original Hyperledger Fabric transaction logs.

[0130] S140. Perform logical processing on the custom log content to convert it into a point-edge relationship.

[0131] Figure 4 This diagram illustrates the basic principle of converting custom log content into point-edge relationships. The sender (source_ip) and receiver (dest_ip) in the custom log data are considered as points. The log itself implicitly represents an edge, indicating that the sender requested or responded to the receiver, establishing a connection between them. An edge contains two points and a relationship description. Points are abstracted as Verte objects, containing at least a `name` attribute representing basic information about the point, such as "peer0.org1.example.com," representing the peer0 node in organization Org1. Edges are abstracted as Edge objects, containing at least three attributes: `source` (sender), `target` (receiver), and `label` (edge ​​identifier). The `source` and `target` attributes in an Edge are of type Verte object. An Edge object contains two Verte objects, indicating that an edge contains two points. The `label` attribute describes the meaning of the edge; for example, "endorser" indicates that this edge is in an endorsement process. Furthermore, when converting custom information into vertex-edge objects, it's necessary to override the methods for determining if Verte objects are identical, such as overriding the `equals()` and `hashCode()` methods in Java. For example, in the endorsement request log, the sender Client's name is "172.0.0.1", and the receiver Endorser Peer's name is "peer0.org1.example.com"; while in the endorsement response log, the sender Endorser Peer's name is "peer0.org1.example.com", and the receiver Client's name is "172.0.0.1". These two logs translate into two different edges, but two of the four extracted points are duplicates. Therefore, it's necessary to override the `equals()` and `hashCode()` methods in the Verte object to filter out Verte objects with identical meanings, ensuring the vertex-edge dataset remains error-free when visualizing consensus transaction call traces.

[0132] Figure 5 This document describes a flowchart illustrating the conversion of custom log content into vertex-edge relationships. The logical processing of log content to convert it into vertex-edge relationships includes:

[0133] S1401, Treat the sender's information in the custom log as a point.

[0134] Sender information may include at least one of the following: IP address, domain name information, or auxiliary information. Auxiliary information will appear in the custom log during the data synchronization phase using the Gossip protocol. For example, in the custom log during the Gossip message reception and processing phase, the sender information may be the organization name.

[0135] S1402, Treat the recipient's information in the custom log as a dot.

[0136] The recipient information may include at least one of the following: IP address, domain name information, or auxiliary information such as organization name. Auxiliary information will appear in the custom log during the data synchronization phase using the Gossip protocol. For example, in the custom log during the Gossip message forwarding phase, the recipient information may be the organization name.

[0137] S1403, Treat the custom log itself as an edge.

[0138] Once the sender and receiver are converted into nodes, the custom log itself represents that the sender sent a request or response to the receiver, which means that a call relationship has been established between the two parties, i.e., an edge.

[0139] S1404. Treat the gRPC service identifier in the custom log as the label of the edge, that is, the description of the edge.

[0140] Each custom log entry contains an identifier indicating the consensus transaction stage in which the log entry is located. For example, the "broacast" identifier indicates that the call information is in the broadcast process within the consensus transaction stage.

[0141] S1405. Treat the timestamps in the custom log as the times when the edge was generated.

[0142] Based on the timestamp information in the custom logs, the order in which key services are called in a consensus transaction can be determined.

[0143] S150. Visualize the vertex-edge relationship dataset using Graphin, which focuses on graph analysis.

[0144] Example 2

[0145] Figure 6 This is a flowchart illustrating a consensus transaction trajectory visualization tracking system according to Embodiment 2 of the present invention. This embodiment is applicable to Hyperledger Fabric networks to visualize and track the call trajectories of various nodes in a consensus transaction.

[0146] The system includes:

[0147] The transaction log collection unit 210 is used to collect the transaction logs of Peer nodes and Orderer node containers in the Hyperledger Fabric network.

[0148] The custom log parsing unit 220 is used to identify custom log content from the transaction log collection unit and parse the custom log content.

[0149] Log storage unit 230 is used to store log data after the log data has been parsed;

[0150] The custom log logic processing unit 240 is used to obtain custom log content from the log storage unit and convert it into point-edge relationships;

[0151] Custom log visualization unit 250 is used to render the point edge dataset using Grafin after the custom log logic has been processed.

[0152] Specifically, the custom log visualization unit 250 is used for:

[0153] Obtain the transformed initial point-edge dataset from the custom log logic processing unit;

[0154] The initial point and edge dataset is styled to conform to the format required by Graphin data and to make the content more user-friendly. The style packaging of a point should include at least: the shape and size of the point, the content of the point, the display position of the content, the font size, and the icon; the style packaging of an edge should include at least: the display of the edge label, the curvature of the edge, the thickness of the edge, and the color fill of the edge.

[0155] You can query the trajectory of the corresponding Hyperledger Fabric consensus transaction based on the combination of channel ID and transaction ID.

[0156] Figure 7 This is a schematic diagram illustrating the visualization effect of a consensus transaction trajectory visualization tracking system in Embodiment 2. Figure 7 The example shows two organizations, each with two peer nodes and one orderer node. No leader peer node is set for each organization; by default, the orderer node will send block data to all peer nodes in all organizations. The endorsement policy is set to OR('Org1MSP.peer', 'Org2MSP.peer'), meaning only one member needs to participate in the endorsement.

[0157] Example 3

[0158] Figure 3The device for visually tracking consensus transaction trajectories provided in Embodiment 3 of the present invention includes:

[0159] One or more processors;

[0160] Memory, used to store one or more programs.

[0161] When the one or more programs are executed by the one or more processors, the one or more processors implement any of the consensus transaction trajectory visualization and tracking methods in the embodiments of the present invention.

[0162] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0163] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for visually tracking consensus transaction trajectories, characterized in that, Includes the following steps: S110: Embed custom logs in the key source code of Hyperledger Fabric consensus transactions; S120: Collect the runtime transaction logs generated in the Hyperledger Fabric node container, which includes the runtime transaction logs that come with Hyperledger Fabric and the custom logs embedded in step S110. S130: Parse the custom log content collected in step S120; S140: Perform logical processing on custom log content to convert it into point-edge relationships; S150: Visualize datasets of vertex-edge relationships using Graphin, which focuses on graph analysis; The node container is a Peer or Orderer node container launched in the Hyperledger Fabric network. The aforementioned Grafin is an open-source React component library based on G6, developed by Ant Group. In step S110, embedding custom logs into the key source code of Hyperledger Fabric consensus transactions includes: Add a custom log to the entry point for Hyperledger Fabric endorsement service processing; Add a custom log to the entry point for Hyperledger Fabric broadcast service processing; Add a custom log to the entry point of the Hyperledger Fabric block distribution service processing; Add a custom log to the entry point of the Hyperledger Fabric method for committing block data to the local ledger; The endorsement service is served by Client nodes on the client side and Peer nodes on the server side. Peer nodes register the endorsement service with the local gRPC server upon startup. The client for the broadcast service is a Client node, and the server is an Orderer node. The Orderer node registers the broadcast service with the local gRPC server when it starts up. The block distribution service's client is the Leader Peer node, and the server is the Orderer node. The Orderer node registers the block distribution service with its local gRPC server upon startup. The Client node is a client node that interacts with the Hyperledger Fabric network. The Orderer node is the Orderer node used for sorting in the Hyperledger Fabric network. The Leader Peer node is the master / leader peer node set up in the Hyperledger Fabric network; The custom log content for endorsement service requests and responses includes: the IP address of the endorsement client, the domain name information of the endorsement server, the identifier representing the endorsement service, the consensus transaction ID, the channel ID, the identifier that distinguishes it from the original Hyperledger Fabric transaction logs, and the timestamp. The custom log content for broadcast service requests and responses includes: the IP address of the broadcast client, the domain name information of the broadcast server, the identifier representing the broadcast service, the consensus transaction ID, the channel ID, the identifier that distinguishes it from the original Hyperledger Fabric transaction logs, and the timestamp. The processing log content of the block distribution service includes: the domain name information of the block distribution client, the domain name information of the block distribution service, the identifier representing the block distribution service, the consensus transaction ID, the channel ID, the identifier that distinguishes it from the original Hyperledger Fabric transaction log, and the timestamp. The log content for Gossip message forwarding includes: the domain name information of the current Peer node, the organization name to which the Gossip message is forwarded, the identifier representing the forwarding of the Gossip message, the consensus transaction ID, the channel ID, the identifier that distinguishes it from the original Hyperledger Fabric transaction log, and the timestamp. The log content for Gossip message processing includes: the domain name information of the current Peer node, the organization name to which the current Peer node belongs, the identifier representing Gossip message processing, the consensus transaction ID, the channel ID, the identifier that distinguishes it from the original Hyperledger Fabric transaction log, and the timestamp.

2. The method for visually tracking consensus transaction trajectories according to claim 1, characterized in that, in step S110, adding a custom log at the entry point of the endorsement service processing includes: When the endorsement service in the Endorser Peer node receives the endorsement service request from the Client node, it prints a log representing the endorsement service request call. Before the endorsement service in the Endorser Peer node returns the transaction proposal response to the Client node, it prints a log representing the endorsement service response. The Endorser Peer node is a Peer node in the Hyperledger Fabric network that serves as an endorsement service.

3. The method for visually tracking consensus transaction trajectories according to claim 1, characterized in that, in step S110, adding a custom log at the broadcast service processing entry includes: After receiving the transaction ordering service request from the Client node, the broadcast server in the Orderer node prints a log representing the broadcast service request call. Before the broadcast server in the Orderer node returns the transaction proposal response to the Client node, it prints a log representing the broadcast service response.

4. The method for visually tracking consensus transaction trajectories according to claim 1, characterized in that, in step S110, adding a custom log to the block distribution service processing entry includes: After receiving block data from the Orderer node, the client of the block distribution service in the Leader Peer node prints a processing log representing the block distribution service. Before the clients of the block distribution service in the Leader Peer node send Gossip messages, logs representing the forwarding of Gossip messages are printed.

5. The method for visually tracking consensus transaction trajectories according to claim 1, characterized in that, in step S110, adding a custom log at the entry point of the method for submitting block data to the local ledger includes: In the Committer Peer node of the HyperledgerFabric network, Gossip messages are processed and block information is parsed. After the block is committed to the local ledger, logs representing the processing of Gossip messages are printed. The Committer Peer node is a peer node used for accounting in the Hyperledger Fabric network.

6. The method for visually tracking consensus transaction trajectories according to claim 1, characterized in that, Step S140, which involves logically processing the custom log content to convert it into point-edge relationships, further includes: Treat the sender information in the custom log as a dot; Treat the recipient information in the custom log as dots; Treat the custom log itself as an edge; Treat the gRPC service identifier in the custom log as the label of the edge; Treat the timestamps in the custom log as the times when the edges were generated.

7. A system for consensus transaction trajectory visualization and tracking using the method described in any one of claims 1 to 6, characterized in that, include: The transaction log collection unit is used to collect the transaction logs of Peer nodes and Orderer node containers in the Hyperledger Fabric network. A custom log parsing unit is used to identify custom log content from the transaction log collection unit and parse the custom log content. The log storage unit is used to store the log data after it has been parsed. A custom log logic processing unit is used to retrieve custom log content from the log storage unit and convert it into point-edge relationships; A custom log visualization unit is used to render the point-edge dataset using Graphin after the custom log logic has been processed, and to draw the trajectory of Hyperledger Fabric consensus transactions.

8. A device for visually tracking consensus transaction trajectories, characterized in that, include: Processor and memory, The processor may be one or more; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors execute the programs to implement the consensus transaction trajectory visualization and tracking method as described in any one of claims 1 to 6.

Images