Ethereum online topology reconstruction method, system, equipment and medium

Abstract

The invention relates to the technical field of Ethereum, in particular to an Ethereum online topology reconstruction method, system and device and a medium. The method comprises the following steps: creating a graph database instance, and storing and managing topological information of an Ethereum network, including nodes and a connection relationship thereof; starting a monitoring cycle, keeping the running state of a main thread, starting a thread for regularly updating the node state of the graph database, and actively discovering other nodes in the network; processing a sending request data packet of a local node, establishing communication with a known node, acquiring neighbor node information of the known node, and verifying the integrity and authenticity of a received target data packet; and the monitoring cycle is continuously executed, processing is performed according to the data packet type of the target data packet, and node information and a topological structure in the graph database are dynamically updated. According to the embodiment of the invention, efficient storage and query are realized through node relation management based on the graph database, real-time topology change display is supported, and the dynamic adaptive capacity of network topology can be improved.

Description

Technical Field

[0001] This application relates to the technical field of Ethereum, and more specifically, to an Ethereum online topology reconstruction method, system, device, and medium. Background Art

[0002] Ethereum is an open-source blockchain platform that supports the development of smart contracts and the construction of decentralized applications. It achieves secure, transparent, and tamper-proof data records through distributed ledger technology, allowing developers to create various decentralized applications covering multiple fields such as finance, supply chain, and voting. The core value of Ethereum lies in its powerful smart contract function and flexible development environment, providing broad space for the innovation and application of blockchain technology.

[0003] Sensing and reconstructing the Ethereum network topology is an important means to improve the efficiency, security, robustness, and scalability of the Ethereum network, and can guarantee the stability and performance of the network in multiple aspects. There are mainly three existing methods for sensing and reconstructing the Ethereum network topology: First, it is based on a modified version of the Ethereum client; second, it infers the connection relationship between nodes by generating marker transactions and using the transaction replacement and propagation mechanism of Ethereum; third, based on the isolation characteristics of future transactions in the Ethereum memory pool, it verifies the active connections between nodes through transaction propagation and replacement strategies.

[0004] Although these existing methods have achieved the sensing and reconstruction of the Ethereum network topology to a certain extent, they also have the following limitations and challenges. Specifically, most of the existing methods are difficult to quickly adapt to this dynamic change, that is, the network dynamic adaptability is poor; the existing methods lack the visualization of the Ethereum topology, and the visualization ability is limited. Summary of the Invention

[0005] The embodiments of this application provide an Ethereum online topology reconstruction method, system, device, and medium, which support real-time display of topology changes and can improve the dynamic adaptability of the network topology.

[0006] In a first aspect, the present invention provides an Ethereum online topology reconstruction method, and the method includes:

[0007] Create a graph database instance, and store and manage the topology information of the Ethereum network, including nodes and their connection relationships;

[0008] Start a listening loop, keep the main thread running, and start a thread for periodically updating the node status of the graph database to actively discover other nodes in the network;

[0009] Process the sent request data packets of the local node, establish communication with known nodes, obtain their neighbor node information, and verify the integrity and authenticity of the received target data packets;

[0010] The monitoring loop continuously executes, processes according to the data packet type of the target data packet, and dynamically updates the node information and topological structure in the graph database.

[0011] In a second aspect, the present invention provides an Ethereum online topology reconstruction system, which includes:

[0012] A graph database node management module, which is used to create a graph database instance and store and manage the topological information of the Ethereum network, including nodes and their connection relationships;

[0013] A node discovery module, which is used to start a monitoring loop, keep the main thread running, and start a thread for periodically updating the node status of the graph database to actively discover other nodes in the network;

[0014] A data packet processing module, which is used to process the request data packets sent by the local node, establish communication with known nodes, obtain the information of their neighbor nodes, and verify the integrity and authenticity of the received target data packets; the monitoring loop continuously executes, processes according to the data packet type of the target data packet, and dynamically updates the node information and topological structure in the graph database.

[0015] In a third aspect, the present invention provides a computer device, which includes a memory and a processor. A computer program is stored on the memory, and when the processor executes the computer program, the method described in any one of the foregoing embodiments is implemented.

[0016] In a fourth aspect, the present invention provides a computer-readable storage medium, which stores a computer program, and when the computer program is executed by a processor, the method described in any one of the foregoing embodiments can be implemented.

[0017] The embodiments of the present application provide an Ethereum online topology reconstruction method, system, device, and medium. Among them, the method includes: creating a graph database instance and storing and managing the topological information of the Ethereum network, including nodes and their connection relationships; starting a monitoring loop, keeping the main thread running, and starting a thread for periodically updating the node status of the graph database to actively discover other nodes in the network; processing the request data packets sent by the local node, establishing communication with known nodes, obtaining the information of their neighbor nodes, and verifying the integrity and authenticity of the received target data packets; the monitoring loop continuously executes, processes according to the data packet type of the target data packet, and dynamically updates the node information and topological structure in the graph database. The embodiments of the present application achieve efficient storage and query through node relationship management based on the graph database, support real-time display of topological changes, and can improve the dynamic adaptability of the network topology. Description of the Drawings

[0018] To more clearly illustrate the technical solutions of the embodiments of the present application, the accompanying drawings required for the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present application and should not be regarded as limiting the scope. For those of ordinary skill in the art, without creative efforts, other related drawings can also be obtained based on these drawings.

[0019] Figure 1 The flowchart of an Ethereum online topology reconstruction method provided by the embodiments of the present application is shown;

[0020] Figure 2 One of the schematic structural diagrams of an Ethereum online topology reconstruction system provided by the embodiments of the present application is shown;

[0021] Figure 3 Another schematic structural diagram of an Ethereum online topology reconstruction system provided by the embodiments of the present application is shown;

[0022] Figure 4 The schematic structural diagram of an electronic device provided by the embodiments of the present application is shown. Detailed implementation manners

[0023] To make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present application. It should be understood that the accompanying drawings in the present application are only for the purposes of illustration and description and are not used to limit the protection scope of the present application. Additionally, it should be understood that the schematic drawings are not drawn to actual scale. The flowcharts used in the present application show the operations implemented according to some embodiments of the present application. It should be understood that the operations in the flowchart may not be implemented in sequence, and steps without logical context relationships may be reversed or implemented simultaneously. In addition, those skilled in the art can add one or more other operations to the flowchart or remove one or more operations from the flowchart under the guidance of the content of the present application.

[0024] In addition, the described embodiments are only some embodiments of the present application, rather than all embodiments. The components of the embodiments of the present application usually described and shown in the accompanying drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the present application to be protected, but only represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative efforts fall within the protection scope of the present application.

[0025] To enable those skilled in the art to use the content of this application, in combination with the specific application scenario of "Ethereum network topology reconstruction", the following implementation manners are provided. For those skilled in the art, without departing from the spirit and scope of this application, the general principles defined here can be applied to other embodiments and application scenarios.

[0026] The following methods, devices, electronic devices or computer-readable storage media in the embodiments of this application can be applied to any scenario that requires Ethereum network topology reconstruction. The embodiments of this application do not limit the specific application scenario. Any solution that uses the Ethereum online topology reconstruction method and system provided by the embodiments of this application is within the protection scope of this application.

[0027] It should be noted that before this application was proposed, there were mainly three existing methods for the perception and reconstruction of the Ethereum network topology: First, based on a modified version of the Ethereum client, by extending the default node discovery mechanism and data collection function, the search, information collection and topology reconstruction of all participating nodes in the Ethereum network were realized; Second, by generating marker transactions and using the transaction replacement and propagation mechanism of Ethereum to infer the connection relationship between nodes, and then through a distributed measurement architecture, the measurement efficiency and coverage were improved. Finally, based on the collected link information, the network topology was reconstructed and the network characteristics were analyzed; Third, the discv4 communication protocol (Ethereum node discovery protocol version 4) was improved. By iteratively requesting the routing table information of the target node, a set of potentially active connection nodes was obtained, and based on the isolation characteristics of future transactions in the Ethereum memory pool, the active connections between nodes were verified through transaction propagation and replacement strategies, realizing the active topology perception and analysis of the Ethereum network.

[0028] Although these existing methods have achieved the perception and reconstruction of the Ethereum network topology to a certain extent, there are also the following limitations and challenges. Specifically, on the one hand, the Ethereum network has a high degree of dynamism, that is, nodes will frequently join and leave the network, but most of the existing methods are difficult to quickly adapt to this dynamic change, that is, the network dynamic adaptability is poor; for example, the node search method based on client modification will have a perception delay when facing rapid node changes, and the marker transaction mechanism and the distributed measurement architecture still require a long time to update the topology information when the dynamic change is relatively fast. On the other hand, only the node search method based on client modification among the existing methods has realized the visualization of the Ethereum topology, but the visualization ability is limited, and the Ethereum network has a high degree of dynamism. This method is difficult to reflect the changes in the joining, leaving and connection states of nodes in real time, and fails to effectively display the hierarchical structure of the network, making it difficult for users to understand the overall architecture of the network.

[0029] In view of the above problems, the embodiments of the present application provide a method, system, device and medium for online topology reconstruction of Ethereum. First, a graph database instance is created, and the topology information of the Ethereum network is stored and managed, including nodes and their connection relationships. Then, a listening loop is started to keep the main thread running, and a thread for periodically updating the node status of the graph database is started to actively discover other nodes in the network. Next, the sent request data packets of the local node are processed, communication is established with known nodes, their neighbor node information is obtained, and the integrity and authenticity of the received target data packets are verified. The listening loop continues to execute, and is processed according to the data packet type of the target data packet, and the node information and topology structure in the graph database are dynamically updated. The embodiments of the present application achieve efficient storage and query through node relationship management based on the graph database, support real-time display of topology changes, and can improve the dynamic adaptability of the network topology.

[0030] To facilitate the understanding of the present application, the technical solutions provided by the present application will be described in detail below with reference to specific embodiments.

[0031] Figure 1 The flowchart of a method for online topology reconstruction of Ethereum provided by the embodiments of the present application is shown. As Figure 1 shown, the method for online topology reconstruction of Ethereum provided by the embodiments of the present application includes the following steps:

[0032] S101. Create a graph database instance, and store and manage the topology information of the Ethereum network, including nodes and their connection relationships.

[0033] It should be noted that based on the discv4 protocol, the embodiments of the present application propose a method for online topology reconstruction of Ethereum. The specific implementation code can be divided into four main modules: a data packet processing module, a graph database node management module, a node discovery module, and a node set operation module. Among them, the data packet processing module is mainly responsible for managing endpoint information and packing or unpacking various data packets in network communication (such as heartbeat request packet Ping, heartbeat response packet Pong, find neighbor request packet FindNeighbors, neighbor list response packet Neighbors, node record request packet EnrRequest, node record response packet EnrResponse, etc.). The graph database node management module mainly realizes four functions: node management, relationship management, status management, and exception handling. The node discovery module is used to listen for network requests, process asynchronous requests, and actively discover other nodes in the topology network through a network protocol-based method. The node set operation module realizes the core logic of routing table management, including functions such as node addition, bucket management, neighbor node search, and re-verification.

[0034] In a specific implementation, first use the graph database node management module to create a graph database instance and store and manage the topological information of the Ethereum network, including nodes and their connection relationships, so as to present the perceived topological network in the form of a graph later. Specifically, for the node management function, the embodiment of the present application defines a create_node() method to create a new node for the graph database. The specific implementation follows the following steps: First, accept the basic information of the node, create a node instance with it as an attribute, and then store it in the graph database Neo4j.

[0035] Here, Neo4j is a high-performance graph database that uses graph structures (including nodes, edges, and attributes) to store and manage data. Different from traditional relational databases (such as MySQL and PostgreSQL), Neo4j is specifically used to process highly connected data and can efficiently process complex relationships and network structures.

[0036] It should be noted that by introducing the graph database (Neo4j) to store and manage the nodes and their connection relationships of the Ethereum network, the present application can provide efficient node storage, query, update, and deletion operations, and support dynamic update of neighbor relationships. The management method based on the graph database can greatly improve the persistence and query efficiency of topological information, providing a reliable guarantee for the stable operation of the Ethereum network.

[0037] S102. Start a listening loop to keep the main thread running, and start a thread to periodically update the status of the graph database nodes to actively discover other nodes in the network.

[0038] In a specific implementation, use the node discovery module to start a listening loop, keep the main thread running, and start a thread to periodically update the status of the graph database nodes to actively discover other nodes in the network.

[0039] Here, the embodiment of the present application adopts a real-time dynamic topology reconstruction strategy. When nodes join, leave, or the connection relationship changes, the Ethereum topology graph can be updated immediately, and optimization adjustments are made by periodically checking the node activity status and communication conditions. In the prior art, most rely on passive response to node changes and lack the ability of active real-time optimization. In the case of large-scale network fluctuations, the topology adjustment lags seriously and it is difficult to meet the requirements of rapid network changes. This strategy improvement of the present application enables the network to quickly adapt to node dynamic changes, greatly improves the topology adjustment efficiency, effectively maintains the stability and performance of the network under complex working conditions, and significantly enhances the network's ability to handle large-scale node changes.

[0040] S103. Process the sending request data packet of the local node, establish communication with known nodes, obtain their neighbor node information, and verify the integrity and authenticity of the received target data packet.

[0041] In a specific implementation, the data packet processing module is used to process the sending request data packet of the local node. Specifically, the local node first establishes communication with known nodes through the sending request data packet and obtains their neighbor node information. The entire process of the listening loop keeps executing. When a data packet sent by other nodes is monitored in the thread, the receive() function in the data packet processing module is first called to verify the integrity and authenticity of the received UDP data packet (target data packet). After parsing the data packet type, the data packet processing module is called, and the corresponding data packet processing function is used for processing.

[0042] Here, multiple classes are defined in the data packet processing module provided in the embodiment of the present application. Each class corresponds to a data packet type. Each class contains three methods: __str__(), pack(), and unpack(). Among them, __str__() is a string conversion method, which is responsible for converting elements into string form. pack() is a packing method, which is responsible for encoding each field of the data packet according to a specific format to generate a byte stream that can be transmitted in the network. The RLP (Recursive Length Prefix) library is used to implement recursive length prefix encoding, and important data is encrypted and signed to enhance security. unpack() is an unpacking method, which is responsible for extracting data from the byte stream. This process is carried out in accordance with the predetermined field order, and the integrity of the data packet (such as check hash value or signature) is verified.

[0043] Here, the packing and unpacking operations of the data packet processing module include the following steps: using the RLP library to perform recursive length prefix encoding on the data packet; encrypting and signing important data to enhance the security of the data packet; when unpacking, extracting data in accordance with the predetermined field order, and verifying the integrity and signature of the data packet.

[0044] In a specific implementation, the embodiment of the present application provides a strict data packet verification mechanism. Specifically, when receiving a data packet, the first 32 bytes are extracted as the message hash, and the Keccak256 hash value of the remaining part is calculated for comparison. At the same time, the signature is deserialized and verified. In the Ethereum network, malicious nodes often interfere with communication by tampering with data packets or disguising their identities. The prior art lacks effective countermeasures for this, resulting in damage to network security and reliability. With this improvement of the present application, relying on its multi-step rigorous verification process, it can accurately identify illegal or tampered data packets, significantly enhancing the network's ability to resist malicious behaviors such as Sybil attacks and denial-of-service attacks, and effectively ensuring the security and stability of network communication.

[0045] In addition, the embodiments of the present application also provide an efficient data packet parsing and node information extraction process. Specifically, for different types of data packets, the present application adopts targeted unpacking and processing methods to accurately extract key information from the verified data packets. The prior art is inefficient and disorganized in processing node information, and cannot construct and update the network topology in a timely and accurate manner in the case of frequent changes in Ethereum network nodes. This process improvement of the present application can quickly and accurately obtain the communication relationships and related information between nodes, lay a solid foundation for topology reconstruction, effectively improve the efficiency of topology graph construction and update, ensure the timeliness and accuracy of network topology information, and thereby enhance the stability and performance of the network.

[0046] S104. The listening loop continuously executes, processes according to the data packet type of the target data packet, and dynamically updates the node information and topology structure in the graph database.

[0047] In a specific implementation, the data packet processing module is used to continuously execute the listening loop and process according to the data packet type. That is, different types of data packets adopt different processing methods. Among them, the data packet types include request data packets and response data packets. If the target data packet is a request data packet (Ping, FindNeighbors, EnrRequest), the node discovery module is used to send corresponding response data packets (Pong, Neighbors, EnrResponse) to the remote node; if the target data packet is a response data packet (Pong, Neighbors, EnrResponse), the timestamp is updated through the graph database node management module, the response content is verified, and the node information and topology structure in the graph database are dynamically updated, including adding the relationships of new active neighbor nodes and deleting the relationships with offline nodes.

[0048] Exemplarily, the order of sending request data packets provided in the embodiment of the present application includes the link of instantiating the graph database and the link of instantiating the local server class instance, wherein the link of instantiating the local server class instance includes a processing stage according to the data packet type (including the heartbeat ping request type, the neighbor search FindNeighbors request type, and the node record EnrRequest request type) and a verification stage. For example, for the ping type, a ping data packet is sent to the target endpoint, the corresponding ping class object is instantiated, the ping data packet is encapsulated into a byte stream, the ping data packet is RLP encoded, the ping class object is encapsulated, the hash value of the ping data packet is calculated and signed with a private key, the final data packet hash is calculated, the signature and the data packet are combined into a final byte stream, a callback function is defined, the network address of the target node is obtained, the Pengding class function of the request message is instantiated, the instantiated request to-do is saved, and the ping data packet is sent using the socket service.

[0049] Exemplarily, the order of receiving data packets includes determining the length of the data packet and processing according to the type of data packet. The processing stage includes the processing of Ping request data packet, pong response data packet, FindNeighbors request data packet, EnrRequest request data packet, Neighbors response data packet, and EnrResponse response data packet. For example, enable monitoring in the gevent green thread, use the green thread to asynchronously process the received UDP data packet, record the error log, verify the data packet hash, extract the signature, verify and reply to the sent public key, verify the digital signature, and parse the data packet type and content. For the ping data packet, parse the sequence number of the ping data packet, calculate the id of the remote node, create a concurrent pong response, update the information in the routing table, and update the time of the last received ping type data packet.

[0050] In the embodiment of the present application, by creating a graph database instance, storing and managing the topological information of the Ethereum network, including nodes and their connection relationships; starting a monitoring loop, keeping the main thread running, and starting a thread that regularly updates the graph database node status, actively discovering other nodes in the network; processing the local node's send request data packet, establishing communication with known nodes, obtaining its neighbor node information, and verifying the integrity and authenticity of the received target data packet; the monitoring loop is continuously executed, processing is performed according to the data packet type of the target data packet, and the node information and topological structure in the graph database are dynamically updated. The embodiment of the present application achieves efficient storage and query through node relationship management based on the graph database, supports real-time display of topological changes, and can improve the dynamic adaptability of the network topology.

[0051] In a possible implementation, the following node set operation steps are performed during the creation of a graph database instance:

[0052] Step (1): Calculate the bucket to which a node belongs according to the XOR distance, store nodes with closer distances in buckets with smaller numbers, and when the distance is less than the minimum threshold, assign them to a special bucket numbered 0.

[0053] Step (2): Add the node to the routing table. If the node already exists, update its position to indicate activity. If the bucket is full, add the node to the replacement cache and attempt to replace unreachable nodes.

[0054] Step (3): Find the neighbors of the target node, select several nodes close to the target node from the routing table, send a neighbor search request, gradually narrow the search scope, and return the top N closest nodes.

[0055] Step (4): Regularly verify the reachability of nodes, remove unreachable nodes from the routing table, and attempt to replace them with nodes in the replacement cache.

[0056] Step (5): Regularly refresh the routing table, find neighbor nodes and random nodes to ensure that the latest network information is stored in the routing table.

[0057] Step (6): Use a queue to manage asynchronous tasks, asynchronously send neighbor search requests, and store the returned neighbor nodes in the queue for subsequent processing.

[0058] In a specific implementation, the embodiments of the present application utilize a node set operation module to implement the core logic of routing table management, including functions such as node addition, bucket management, neighbor node search, and re-verification.

[0059] Here, the embodiments of the present application adopt the get_bucket method for bucket allocation to determine which bucket a node should be stored in according to the XOR distance (Exclusive OR distance) between nodes. Specifically, calculate the bucket number to which the node belongs according to the XOR distance between nodes, that is, store the node in the appropriate bucket. Among them, the XOR distance is the distance calculated by performing an exclusive OR operation (XOR) on two node identifiers. The smaller the XOR distance, the closer the two nodes; the larger the XOR distance, the farther the two nodes. The bucket number is determined according to the number of leading zeros of the XOR distance. Nodes with closer distances are stored in buckets with smaller numbers. When the distance is less than a certain minimum threshold, the node is assigned to a special bucket numbered 0.

[0060] Implement bucket management to ensure that the number of nodes in each bucket does not exceed a preset upper limit. When a bucket is full, replace unreachable nodes through a verification mechanism. Specifically, use the add_node method to add a node to the routing table. Check if the node is the current node itself. If the node already exists, move it to the end of the bucket to indicate its activity. If the bucket is full, add the node to the replacement cache and try to replace unreachable nodes through the verification mechanism.

[0061] Implement neighbor node lookup. By finding the bucket to which the target node belongs, quickly locate the neighbor nodes of the target node. Specifically: Use the lookup method to find the neighbors of the target node. Select several nodes closest to the target node from the routing table, send FindNeighbors requests (neighbor lookup requests) to these nodes, and gradually narrow the lookup range based on the returned neighbor list. Use the closest method (nearest neighbor method) to find the node closest to the target node. Traverse all buckets, sort the nodes according to the XOR distance, and return the first N nodes.

[0062] Exemplarily, the lookup method provided in the embodiments of the present application includes the following steps: Calculate the target node ID, initialize the nearest node list as empty, determine whether the nearest node list is empty. If it is empty, find the node closest to the target ID. If the node is found, record the queried node ID, initialize the number of nodes being queried as 0, initialize the list for receiving neighbor nodes, and determine whether the number of queried nodes reaches the upper limit. If it reaches, return the nearest node list.

[0063] Implement node verification. Use the re_validate method (re-verification method) to verify the reachability of nodes. Periodically randomly select nodes from non-empty buckets, send Ping requests (heartbeat requests) to the nodes, and check if they respond. If a node is unreachable, remove it from the bucket and try to replace it with a node from the replacement cache.

[0064] Implement routing table refresh. Use the refresh method (refresh method) to keep the routing table active. Periodically find neighbor nodes and random nodes to ensure that the routing table stores the latest network information and avoid performance degradation of the routing table due to outdated information.

[0065] Implement asynchronous operations and queue management. Use Queue as the result storage queue to transfer data between asynchronous tasks. Asynchronously send FindNeighbors requests through the find_neighbours method and store the returned neighbor nodes in the queue for subsequent processing.

[0066] Exemplarily, the embodiments of the present application further provide a routing lookup and maintenance sequence process. Specifically, the routing lookup and maintenance sequence includes creating a routing table RoutingTable in a server class instance and starting a gevent green thread. Among them, thread 1 performs self-lookup and random lookup loop operations, and thread 2 checks whether the last node in the random bucket is reachable. If it is reachable, the node is moved to the end of the bucket; if it is not reachable, a node is selected from the replacement cache for replacement.

[0067] It should be noted that the embodiments of the present application use the XOR distance metric mechanism to store nodes in buckets and dynamically adjust the node storage strategy when the bucket is full through the replacement cache mechanism. At the same time, the system provides a regular re-verification function for nodes, and combines Ping and Pong message interactions to ensure the reachability of nodes. By regularly refreshing the routing table and actively discovering new nodes, the activity and up-to-date status of the routing table are maintained. This dynamic adjustment and maintenance mechanism solves the problem of inaccurate routing table information caused by frequent joining and leaving of nodes, ensures that the routing table efficiently adapts to changes in the dynamic network topology, and reduces the network performance degradation caused by outdated information.

[0068] In a possible implementation manner, for an asynchronous task class instance Pending class, the actively discovering other nodes in the network in S102 includes the following steps:

[0069] Step 1021a: Initialize the asynchronous task class instance, specifying the target node, the expected response type, the callback function, and the timeout time.

[0070] Step 1022a: Listen to the response queue. If a correct response is received, call the callback function to process the response data and store the discovered node information in the graph database; if a timeout occurs, record the timeout log.

[0071] Step 1023a: Store the received response packets through the queue to avoid blocking the main thread and provide a convenient method to put the received packets into the queue.

[0072] Step 1024a: For each successfully responded target node, store the newly discovered node and its related information in the graph database. If the node already exists, update the timestamp of the node.

[0073] In a specific implementation, for the Pending class instance of the asynchronous task class, the Pending class instance is first initialized, which is the starting point of the node discovery process and prepares for subsequent request and response processing. The response queue is listened to, implemented through the __run method, to ensure that responses or timeouts can be processed in a timely manner, and the discovered node information is stored in the graph database. The response data is processed, and the response data is stored in a queue to avoid blocking the main thread, support dynamic processing, and improve the concurrent processing ability of the system. For each successfully responded target node, the method of the graph database node management module is called to store the newly discovered node and its related information in the graph database. If the node already exists, its timestamp is updated.

[0074] Exemplarily, the embodiments of the present application also provide the order of the to-do and graph database maintenance threads. Specifically, through the mutual interaction between the local server, the Pending class instance, and the graph database, and by starting multiple threads, the maintenance of the graph database is implemented. Among them, the GraphDatabaseHandler class represents the graph database handler or graph database processor.

[0075] Among them, the Pending class instance is used to process requests and responses in the node discovery protocol. After sending a request, it waits for a response of a specified type (such as Pong or Neighbors), and performs specific operations after receiving the response or timing out. Concurrency is achieved by using the green thread Greenlet, supporting the simultaneous processing of multiple pending network requests. And the received response packets are stored in a queue to avoid blocking the main thread. At the same time, attributes and methods are provided to check the task status, process responses, or record timeout logs. In a specific implementation, first, the Pending object is initialized, specifying the target node, the expected response type, the callback function, and the timeout time. Then, the __run method is used to listen to the response queue. If the correct response is received, the callback function is called for processing; if it times out, a log is recorded. In addition, convenient methods (such as emit) are provided within the class to put the received packets into the queue, supporting dynamic processing.

[0076] In a possible implementation manner, for the Server class instance of the network service class, the actively discovering other nodes in the network in S102 includes the following steps:

[0077] Step 1021b: Start the network service class instance, perform non-blocking input / output operations, listen to UDP data packets, and define corresponding methods to verify the integrity of the data packets and parse the data types.

[0078] Step 1022b: Create a routing table instance to store and manage the information of neighboring nodes, and configure the list of bootstrap nodes to support the initial network connection.

[0079] Step 1023b: Initialize the private key for signing and verifying messages.

[0080] Step 1024b: For each newly discovered node, check if the newly discovered node already exists in the graph database. If not, store the node and its related information in the graph database.

[0081] In a specific implementation, for the Server class of network service instances, first start the Server class, use the select module to implement non-blocking I / O operations to ensure efficient handling of network requests. Manage the routing table, create a routing table instance, store and manage neighboring node information, and support initial network connections. Initialize the private key for signing and verifying messages to ensure communication security. Check and store node information. For each newly discovered node, check if the node already exists in the graph database through the node_exists() method (node existence check method). If not, call the create_node() method to store the node and its related information in the graph database. Security and optimization measures include verifying the integrity of datagrams, increasing the response rate limit, and making asynchronous calls to enhance the security and processing capacity of the system.

[0082] Among them, the Server class instance is responsible for starting and listening for network requests, managing the routing table and pending requests, and processing and responding to various message types specified by the protocol (such as Ping, Pong, FindNeighbors). Specifically, use the select module to implement non-blocking I / O operations to achieve the function of listening for UDP packets. And define corresponding methods to verify the integrity of the packet, parse the data type, and process according to different packet types. At the same time, it also has the function of regularly checking the node status and maintaining the latest network topology. In a specific implementation, first create a routing table (RoutingTable) to store and manage neighboring node information, configure the list of bootstrap nodes to support initial network connections, and then initialize the private key for signing and verifying messages. It can verify the integrity of packets to prevent forged messages, increase the response rate limit to prevent traffic amplification attacks, and add asynchronous calls to the message processing flow to enhance the high-concurrency processing ability.

[0083] It should be noted that, in the embodiments of the present application, by adopting asynchronous I / O operations and coroutine technology (Greenlet), high-concurrency task processing is achieved. The response results are stored in a queue to avoid blocking the main thread. At the same time, a Pending class is introduced to manage requests and responses, supporting a dynamic processing mechanism for suspended tasks. This improvement significantly enhances the concurrent processing ability of network requests and responses, solves the impact of task blocking on performance, greatly reduces the occupancy of system resources, provides strong technical support for the efficient operation of the Ethereum network, and can improve the efficiency of node discovery and routing table maintenance.

[0084] In a possible implementation manner, the thread for periodically updating the node status of the graph database in S102 includes the following steps: periodically checking the timestamps of the nodes in the graph database, deleting the expired nodes whose timestamps exceed a preset threshold and their related relationships in the graph database; and / or, periodically cleaning up orphan nodes.

[0085] In specific implementation, creating a graph database instance is the basis of the entire topology reconstruction method. On this basis, here, the specific steps for node management in the graph database are further refined, including the new node creation link, which is the starting point of node management to ensure that new nodes are correctly recorded in the graph database. The node existence query link, which checks whether a node already exists before creating a new node or in other scenarios where the node status needs to be verified, to avoid duplicate creation or processing of non-existent nodes. The node timestamp update link, which periodically updates the timestamp of an existing node to record its active status. The node timestamp acquisition link, which determines whether a node is expired by querying the timestamp, and this is the key step for deciding whether to delete a node. The expired node and its relationship deletion link, which cleans up the expired nodes and their relationships to ensure that the information in the graph database always remains up-to-date and accurate.

[0086] It should be noted that in order to implement the node management function in the embodiments of this application, five methods are defined, namely, the create_node() method, the node_exists() method, the update_timestamp() method (the method for updating the timestamp), the get_timestamp() method (the method for obtaining the timestamp), and the delete_node() method (the method for deleting nodes). Among them, the create_node() method is responsible for creating a new node for the graph database. The specific implementation follows the following steps: First, accept the basic information of the node, create a Node instance with it as the attribute, and then store it in Neo4j. The node_exists() method is responsible for querying whether a node already exists in the graph database, which is implemented by using a Cypher query to match the id of the node. The update_timestamp() method is responsible for updating the timestamp, which is also implemented by a Cypher statement. The get_timestamp() method is responsible for querying the timestamp of a specified node to determine whether it has expired. The delete_node() method is responsible for deleting the expired node and all its related relationships, which is implemented by a Cypher statement. Here, through the automated expired node cleaning and orphan node management functions, the negative impact of expired nodes on the routing table is effectively avoided, thus ensuring the real-time nature and accuracy of the network topology information.

[0087] For relationship management, in order to implement simple management of the relationships between nodes in the graph database, that is, creation, deletion, and query operations, the following three functions are defined. Specifically, the create_relationship() function (the function for creating a relationship) is used to create a relationship of the NEIGHBOR type (neighbor type) between two nodes to represent their neighbor relationship. The relationship_exists() function (the function for checking the existence of a relationship) is used to check whether a specified type of relationship exists between two nodes, which is implemented by a Cypher statement. The delete_relationship() function (the function for deleting a relationship) is used to delete the NEIGHBOR relationship between two nodes. Among them, the Cypher statement is a query language for the Neo4j graph database. It is similar to SQL but is specifically used for querying and operating on graph-structured data.

[0088] For status management, in order to facilitate the management of the node status, orphan nodes are cleaned up when the delete_node() method is called, and the get_old_nodes() method (the method for obtaining old nodes) is defined. This method is used to query nodes whose timestamps exceed 24 hours (or a specified time threshold) and return the basic information of the nodes for further operations (such as cleaning).

[0089] Among them, for exception handling, in order to improve the robustness of the program, an exception capture mechanism is added to all key methods to record error logs and throw exceptions when necessary, avoiding program crashes caused by database interaction failures.

[0090] In a possible implementation, if the target data packet is a request data packet, the processing according to the data packet type of the target data packet in S104 includes the following situations:

[0091] Situation 1a: If a heartbeat request data packet is received, a response heartbeat response data packet is sent to the remote node, and it is checked whether the last communication with the remote node exceeds a preset time threshold or no communication has been carried out; if so, the remote node is added to the routing table, and the time when the last heartbeat request data packet was received is updated; if not, the time when the last heartbeat request data packet was received is directly updated.

[0092] In a specific implementation, for Ping request processing, a Pong response data packet is sent to the remote node. The routing table module is called to check the communication status with the remote node. If the preset time threshold is exceeded or no communication has been carried out, the remote node is added to the routing table and the timestamp is updated. If the preset time threshold is not exceeded, the timestamp is directly updated.

[0093] Situation 2a: If a find neighbors request data packet is received, a neighbors list response data packet is sent to the remote node.

[0094] In a specific implementation, for FindNeighbors request processing, a Neighbors response data packet is sent to the remote node.

[0095] Situation 3a: If a node record request data packet is received, a node record response data packet is sent to the remote node.

[0096] In a specific implementation, for EnrRequest request processing, an EnrResponse response data packet is sent to the remote node.

[0097] In a possible implementation, if the target data packet is a request data packet, the processing according to the data packet type of the target data packet in S104 includes the following situations:

[0098] Situation 1b: If a response heartbeat response data packet is received, the timestamp is updated, and the handle response method is called for verification.

[0099] In a specific implementation, for the Pong data packet, that is, if a "response heartbeat" response data packet is received, the timestamp is updated, and the handle_reply method (handle reply method) is called for verification.

[0100] Case 2b: If a neighbor list response data packet is received, update the timestamp, call the processing response method for verification, and at the same time check whether the remote node already exists in the graph database; if it exists, add the relationship with the new active neighbor nodes and delete the relationship with the offline nodes; if it does not exist, directly add the remote node to the graph database.

[0101] In a specific implementation, for the Neighbors data packet, that is, if a "neighbor list" response data packet is received, update the timestamp, call the handle_reply method for verification, and at the same time call the graph database node management module: check whether the remote node already exists in the graph database; if it exists, add the relationship with the new active neighbor nodes and delete the relationship with the offline nodes; if it does not exist, directly add the remote node to the graph database;

[0102] Case 3b: If a node record response data packet is received, update the timestamp and call the processing response method for verification.

[0103] It should also be noted that the graph database Neo4j provided in the embodiments of the present application also provides a topology analysis tool, enabling the network topology graph obtained to be analyzed from multiple perspectives, providing convenience for subsequent analysis of the security of the Ethereum network and load balancing optimization, and helping to improve the robustness of the Ethereum network. In a specific implementation, for the EnrResponse data packet, that is, if a "node record response" data packet is received, update the timestamp and call the handle_reply method for verification. Exemplarily, the embodiments of the present application also provide the handle_reply method flow. Among them, is_match is a boolean variable used to represent whether a certain matching condition is established; is_match = Falsse indicates that the matching condition is not established, and is_match = True indicates that the matching condition is established. For example, in scenarios such as data verification, pattern matching, or condition judgment, it can be used to determine whether the input data conforms to specific rules or whether the text matches a specific pattern. pending_hold indicates that a certain task is in a pending state, waiting for further conditions to be met or instructions to be issued. For example, in a task queue, a certain task is in the pending_hold state because the dependent resources are not ready. gevent is a library in Python for implementing asynchronous programming, and spawn is a function in gevent used to create and start a new green thread to execute the specified function or coroutine, enabling the program to execute multiple tasks concurrently and achieve asynchronous operations.

[0104] It should also be noted that the graph database Neo4j provided in the embodiments of the present application also provides a topology analysis tool, which enables the network topology graph obtained to be analyzed from multiple perspectives, provides convenience for subsequent analysis of the security of the Ethereum network and load balancing optimization, and helps to improve the robustness of the Ethereum network.

[0105] Here, the load balancing optimization based on node relationships is one of the core improvements in the embodiments of this application. By comprehensively recording the communication relationships between nodes to construct a topology graph and reasonably allocating node loads based on this, the problem of overloaded super nodes is effectively avoided. In previous technologies, the situation of unbalanced loads on super nodes could never be properly resolved in terms of topology structure optimization, which seriously affected the overall network efficiency and stability. This optimization measure of this application realizes the reasonable utilization of node resources, reduces network latency and the risk of failures caused by super node bottlenecks, improves the overall performance of the network, and enhances the robustness and sustainability of the network.

[0106] It should also be noted that the embodiments of this application significantly improve the dynamic adaptability of the network topology, the perception accuracy of active connections, and the visualization ability of topology information by optimizing the Ethereum network topology perception and reconstruction method based on the Discv4 protocol. Technologies such as dynamic bucket allocation, node re-verification, and asynchronous task management are adopted to ensure that the routing table can quickly respond to the frequent joining and leaving of nodes, reduce topology update latency, and improve the security and privacy of network communication through encryption signature and transaction verification strategies. At the same time, the node relationship management based on the graph database realizes efficient storage and query, supporting the real-time display of topology changes. The overall solution enhances the stability, robustness, and scalability of the Ethereum network while reducing resource consumption, providing important support for network performance optimization and application innovation.

[0107] Based on the same inventive concept, the embodiments of this application also provide an Ethereum online topology reconstruction system corresponding to the Ethereum online topology reconstruction method provided in the above embodiments. Since the principle of the device in the embodiments of this application for solving problems is similar to the Ethereum online topology reconstruction method in the above embodiments of this application, the implementation of the system can refer to the implementation of the method, and the repeated parts will not be elaborated.

[0108] Figure 2 Fig. 10 shows one of the schematic structural diagrams of an Ethereum online topology reconstruction system 200 provided by the embodiments of this application. Figure 3 Fig. 11 shows another schematic structural diagram of an Ethereum online topology reconstruction system 200 provided by the embodiments of this application. As Figure 2 shown, the Ethereum online topology reconstruction system 200 includes:

[0109] A graph database node management module 210, configured to create a graph database instance and store and manage the topology information of the Ethereum network, including nodes and their connection relationships;

[0110] A node discovery module 220, configured to start a listening loop, keep the main thread running, and start a thread for periodically updating the status of graph database nodes to actively discover other nodes in the network;

[0111] The data packet processing module 230 is used to process the request data packets sent by the local node, establish communication with known nodes, obtain their neighbor node information, and verify the integrity and authenticity of the received target data packets; the listening loop continuously executes, processes according to the data packet type of the target data packet, and dynamically updates the node information and topological structure in the graph database.

[0112] As Figure 3 shown, the Ethereum online topology reconstruction system 200 further includes a node set operation module 240; the node set operation module 240 is used to perform the following node set operation steps in creating a graph database instance:

[0113] Calculate the bucket to which the node belongs according to the XOR distance, store the nodes with closer distances in the buckets with smaller numbers, and when the distance is less than the minimum threshold, allocate them to the special bucket numbered 0;

[0114] Add the node to the routing table, update its position to indicate activity if the node already exists, and add the node to the replacement cache and try to replace the unreachable node if the bucket is full;

[0115] Find the neighbors of the target node, select several nodes close to the target node from the routing table, send a neighbor search request, gradually narrow the search range, and return the top N closest nodes;

[0116] Regularly verify the reachability of nodes, remove the unreachable nodes from the routing table, and try to replace them with the nodes in the replacement cache;

[0117] Regularly refresh the routing table, find neighbor nodes and random nodes to ensure that the latest network information is stored in the routing table;

[0118] Use a queue to manage asynchronous tasks, asynchronously send neighbor search requests, and store the returned neighbor nodes in the queue for subsequent processing.

[0119] In the embodiment of the present application, a graph database instance is created through the graph database node management module, and the topological information of the Ethereum network is stored and managed, including nodes and their connection relationships; the node discovery module starts a listening loop to keep the main thread running, and starts a thread for regularly updating the node status of the graph database to actively discover other nodes in the network; the data packet processing module processes the request data packets sent by the local node, establishes communication with known nodes, obtains their neighbor node information, and verifies the integrity and authenticity of the received target data packets; the listening loop continuously executes, processes according to the data packet type of the target data packet, and dynamically updates the node information and topological structure in the graph database. The embodiment of the present application realizes efficient storage and query through the node relationship management based on the graph database, supports real-time display of topological changes, and can improve the dynamic adaptation ability of the network topology.

[0120] Based on the same inventive concept, refer to Figure 4 as shown Figure 4 FIG. 5 shows a schematic structural diagram of an electronic device 400 provided in an embodiment of the present application, including: a processor 410, a memory 420, and a bus 430. The memory 420 stores machine-readable instructions executable by the processor 410. When the electronic device 400 runs, the processor 410 communicates with the memory 420 through the bus 430. When the machine-readable instructions are run by the processor 410, the steps of the Ethereum online topology reconstruction method described in any one of the above embodiments are executed.

[0121] Based on the same inventive concept, an embodiment of the present application further provides a computer-readable storage medium. A computer program is stored on the computer-readable storage medium. When the computer program is run by a processor, the steps of the Ethereum online topology reconstruction method provided in the above embodiment are executed.

[0122] Specifically, the storage medium can be a general storage medium, such as a removable disk, a hard disk, etc. When the computer program on the storage medium is run, it can execute the above Ethereum online topology reconstruction method. Through node relationship management based on a graph database, efficient storage and query are achieved, real-time display of topology changes is supported, and the dynamic adaptability of the network topology can be improved.

[0123] In the embodiment of the present application, when the computer program is run by a processor, it can also execute other machine-readable instructions to execute other methods described in the embodiments. For the specific method steps and principles executed, refer to the description of the embodiments, and details are not described herein again.

[0124] The computer program product for performing Ethereum online topology reconstruction provided by the embodiment of the present application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the foregoing method embodiments. For the specific implementation, refer to the method embodiments, and details are not described herein again.

[0125] The Ethereum online topology reconstruction system provided by the embodiment of the present application can be specific hardware on a device or software or firmware installed on the device, etc. The implementation principle and the technical effects generated by the device provided by the embodiment of the present application are the same as those of the foregoing method embodiments. For the sake of brief description, for the parts not mentioned in the device embodiment, reference can be made to the corresponding content in the foregoing method embodiments. Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the foregoing-described systems, devices, and units can all refer to the corresponding processes in the above method embodiments, and details are not described herein again.

[0126] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For another example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection between each other can be through some communication interfaces. The indirect coupling or communication connection of the devices or units can be in electrical, mechanical or other forms.

[0127] The units described as separate components may or may not be physically separated. The components shown as units may or may not be physical units, that is, they can be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0128] In addition, each functional unit in the embodiments provided in the present application can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit.

[0129] If the functions are implemented in the form of software function units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical discs that can store program codes.

[0130] It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. In addition, the terms "first", "second", "third", etc. are only used for distinguishing descriptions and cannot be understood as indicating or implying relative importance.

[0131] Finally, it should be noted that the above-described embodiments are only specific implementation manners of the present application, used to illustrate the technical solutions of the present application, rather than limiting it. The protection scope of the present application is not limited thereto. Although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that any person skilled in the art within the technical scope disclosed by the present application can still modify the technical solutions recorded in the foregoing embodiments or can easily think of changes, or perform equivalent replacements on some of the technical features; and these modifications, changes or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application. All should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. An Ethereum online topology reconstruction method, characterized in that, The method includes: Create a graph database instance, and store and manage the topology information of the Ethereum network, including nodes and their connection relationships; Start a listening loop to keep the main thread running, and start a thread for periodically updating the status of graph database nodes to actively discover other nodes in the network; Process the send request packets of the local node, establish communication with known nodes, obtain their neighbor node information, and verify the integrity and authenticity of the received target packets; The listening loop continuously executes, processes according to the packet type of the target packet, and dynamically updates the node information and topology structure in the graph database.

2. The method according to claim 1, characterized in that The method further includes the following node set operation steps in creating the graph database instance: Calculate the bucket to which the node belongs according to the XOR distance, store the nodes with closer distances in the buckets with smaller numbers, and when the distance is less than the minimum threshold, assign them to a special bucket numbered 0; Add the node to the routing table, update its location to indicate activity if the node already exists, and if the bucket is full, add the node to the replacement cache and try to replace unreachable nodes; Find the neighbors of the target node, select several nodes close to the target node from the routing table, send a request to find neighbors, gradually narrow down the search range, and return the top N closest nodes; Periodically verify the reachability of nodes, remove unreachable nodes from the routing table, and try to replace them with nodes in the replacement cache; Periodically refresh the routing table, find neighbor nodes and random nodes to ensure that the latest network information is stored in the routing table; Use a queue to manage asynchronous tasks, asynchronously send requests to find neighbors, and store the returned neighbor nodes in the queue for subsequent processing.

3. The method according to claim 1, characterized in that, The actively discovering other nodes in the network includes the following steps: Initialize an instance of the asynchronous task class, specifying the target node, the expected response type, the callback function, and the timeout; Listen to the response queue, if a correct response is received, call the callback function to process the response data, and store the discovered node information in the graph database; if it times out, record the timeout log; Store the received response packets through the queue to avoid blocking the main thread, and provide a convenient method to put the received packets into the queue; For each successfully responded target node, store the newly discovered node and its related information in the graph database, and if the node already exists, update the timestamp of the node.

4. The method according to claim 1, characterized in that The actively discovering other nodes in the network includes the following steps: Start an instance of the network service class, perform non-blocking input / output operations, listen for UDP packets, and define corresponding methods to verify the integrity of the packets and parse the data types; Create an instance of the routing table, store and manage the information of neighboring nodes, and configure the list of bootstrap nodes to support the initial network connection; Initialize the private key for signing and verifying messages; For each newly discovered node, check whether the newly discovered node already exists in the graph database, and if not, store the node and its related information in the graph database.

5. The method according to claim 1, wherein The thread for periodically updating the status of graph database nodes includes the following steps: Periodically check the timestamps of the nodes in the graph database, delete the expired nodes whose timestamps exceed the preset threshold and their related relationships in the graph database; and / or, Periodically clean up isolated nodes.

6. The method according to claim 1, characterized in that, If the target data packet is a request data packet, processing according to the data packet type of the target data packet includes the following steps: If a heartbeat request data packet is received, send a response heartbeat response data packet to the remote node, and check whether the last communication with the remote node exceeds a preset time threshold or there has been no communication; if so, add the remote node to the routing table and update the time of the last received heartbeat request data packet; if not, directly update the time of the last received heartbeat request data packet; If a find neighbor request data packet is received, send a neighbor list response data packet to the remote node; If a node record request data packet is received, send a node record response data packet to the remote node.

7. The method according to claim 1, wherein If the target data packet is a response data packet, processing according to the data packet type of the target data packet includes the following steps: If a response heartbeat response data packet is received, update the timestamp and call the processing response method for verification; If a neighbor list response data packet is received, update the timestamp and call the processing response method for verification, and at the same time check whether the remote node already exists in the graph database; if it exists, add the relationship with the new active neighbor node and delete the relationship with the offline node; if it does not exist, directly add the remote node to the graph database; If a node record response data packet is received, update the timestamp and call the processing response method for verification.

8. An Ethereum online topology reconstruction system, characterized in that, The system includes: A graph database node management module, used to create a graph database instance and store and manage the topology information of the Ethereum network, including nodes and their connection relationships; A node discovery module, used to start a listening loop, keep the main thread running, and start a thread for periodically updating the status of graph database nodes to actively discover other nodes in the network; A data packet processing module, used to process request data packets sent by the local node, establish communication with known nodes, obtain information about their neighbor nodes, and verify the integrity and authenticity of the received target data packets; the listening loop continuously executes, processes according to the data packet type of the target data packet, and dynamically updates the node information and topology structure in the graph database.

9. An electronic device, characterized in that, Including: A processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device runs, the processor communicates with the memory through the bus. When the machine-readable instructions are run by the processor, the steps of the Ethereum online topology reconstruction method according to any one of claims 1-7 are executed.

10. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium. When the computer program is run by the processor, the steps of the Ethereum online topology reconstruction method according to any one of claims 1-7 are executed.

Images