System and method for estimating e2e delay among blockchain nodes over p2p networks

Abstract

To provide a scalable and accurate system and method for estimating an end-to-end (E2E) delay among large-scale blockchain nodes over peer-to-peer (P2P) networks.SOLUTION: In an E2E delay estimation system, an E2E delay estimation unit 300 included in a network monitoring and management unit 100 comprises: a coordinate system construction unit to designate an origin node and anchor nodes among participating nodes having a distributed ledger of P2P networks, construct a first coordinate system of a predetermined dimension through exchange of control messages between the origin node and the anchor nodes and the participating nodes, and construct a second coordinate system of another predetermined dimension; and a dimension determination unit to determine a dimension to be applied to current networks by comparing respective dimension-specific delays or control message overheads of the first and second coordinate systems.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present disclosure relates to network latency estimation techniques, and more particularly to a system and method for estimating scalable and accurate edge-to-edge (E2E) latency between large-scale blockchain nodes in a peer-to-peer (P2P) network. [Background technology]

[0002] Blockchain systems are decentralized and distributed ledgers, making it nearly impossible to alter or tamper with the data stored on them. Blockchain systems have attracted considerable attention in recent years due to their potential to revolutionize various industries by providing a secure, transparent, and distributed system. Cryptocurrency is one of the most popular blockchain applications.

[0003] Recently, blockchain-based non-fungible tokens (NFTs) have suddenly emerged in online marketplaces, creating a new value paradigm. Blockchain applications for various services pose high scalability requirements. However, it is very difficult to realize a secure and scalable blockchain in a decentralized environment, known as the blockchain trilemma. Therefore, blockchain systems are designed for different purposes while sacrificing some of their attributes.

[0004] For example, blockchain systems are divided into two types: permissionless blockchains, which focus on decentralization while partially sacrificing scalability, and permissioned blockchains, which emphasize scalability while partially sacrificing decentralization. Permissionless blockchains are fully distributed blockchains where anyone can join the blockchain and create new blocks. Usually, Bitcoin and Ethereum are widely used permissionless blockchains.

[0005] However, such blockchains sacrifice scalability, making 51% attacks possible, which can limit the performance of blockchains, especially in large-scale network environments. Therefore, considerable research efforts are underway to improve the scalability of permissionless blockchains.

[0006] For example, a Byzantine contract protocol that uses a pure proof-of-stake approach to quickly and securely confirm transactions, a child chain that processes transactions independently and periodically settles the results of the main chain in an extensible off-chain framework for Ethereum with the goal of increasing transaction processing volume and reducing fees, etc. Also, a protocol that integrates the advantages of a directed acyclic graph structure and existing blockchains to achieve high scalability and fast transaction processing has been proposed.

[0007] Also, in permissioned blockchains such as Hyperledger Fabric, Corda, and Quorum, only authenticated nodes can participate in the blockchain network. Unlike permissionless blockchains, a 51% attack is not a big threat in permissioned blockchains because all nodes are considered trusted and administrators control access. Therefore, the consensus process of permissioned blockchains can be simplified compared to permissionless blockchains, and therefore transactions are committed to the distributed ledger faster without computationally intensive mining operations.

[0008] However, decentralization issues can still occur in permissioned blockchains. To solve the decentralization issues in permissioned blockchains, we propose a trusted enforcer architecture for Blockchain as a Service (BaaS) to mitigate system security threats that rely on centralized service providers in the prior art, and introduce a blockchain-assisted audit framework to solve the on-chain privacy issue. In the blockchain-assisted audit framework, smart contracts are modeled for secure storage auditing.

[0009] Additionally, the Hyperledger Fabric Working Group is seeking to specify and standardize interoperability workflows that will enable service providers hosted on different clouds to create and join business networks independently of the infrastructure.

[0010] Thus, the performance of blockchains in both permissionless and permissioned blockchains is closely related to network latency, especially block broadcast and consensus. For example, large block propagation latency seriously impacts the consistency of the blockchain network, which increases the rate of stale blocks and blockchain forks. This not only reduces transactions per second (TPS), but can also cause security and fairness issues.

[0011] A P2P (peer-to-peer) network can act as a blockchain backbone network. However, in a P2P network, any pair of nodes can be logically connected through the P2P network, so the end-to-end (edge ​​to edge, E2E) latency between blockchain nodes can be measured in theoretical terms in the order of O(N 2) control messages may be required, and it is widely known that these E2E delay values ​​vary over a relatively wide range, and the connections may be fragile due to the nature of the P2P network itself.

[0012] This indicates that measuring all E2E latencies between blockchain nodes is a heavy burden for network management. Therefore, accurately estimating network latencies with a small amount of control message overhead in a time-varying P2P network environment is a key factor in effectively solving blockchain problems.

[0013] Some research efforts have been made to estimate E2E delays through P2P networks. For example, Global Network Positioning (GNP), a coordinate-based network distance estimation method through the Internet that models the Internet as a geometric space, has been proposed. However, this method has difficulty in selecting the optimal reference node without geographical information, and it has difficulty in effectively responding to changes in the network status of nodes in a time-varying P2P network environment.

[0014] For example, the Vivaldi algorithm has been proposed, which assigns composite coordinates to Internet hosts in a distributed manner without a fixed network infrastructure. However, this method still has a large difference between measured and estimated delays, requires a large amount of control message overhead because each node independently constructs its own coordinate system, and convergence is very slow compared to the time-varying conditions of a P2P network.

[0015] In addition, a method has been proposed that introduces Pharos control, which improves the accuracy of the Vivaldi algorithm by assigning multiple coordinates to each node according to the network distance range metric. However, this method still requires a lot of control message overhead to configure the coordinate system.

[0016] In addition, a method has been proposed that divides the entire space into three clusters, constructs subspaces, and processes triangle inequality violations (TIVs) using existing algorithms. However, this method has the disadvantage that it requires nodes to know which cluster they belong to, and requires a large amount of control message overhead.

[0017] Thus, network latency not only affects the transactions per second and scalability of blockchain, but also poses a high risk of security issues, and remains a major obstacle to blockchain performance. Therefore, a new method is required to estimate E2E latency between multiple blockchain nodes with O(N) level control message overhead in P2P networks. Summary of the Invention [Problem to be solved by the invention]

[0018] The present disclosure has been derived in response to the above-mentioned demands in the prior art, and the objective of the present disclosure is to provide a method and system that can accurately estimate end-to-edge (E2E) latency between all blockchain nodes with O(N) control message overhead.

[0019] Another object of the present disclosure is to provide an E2E delay estimation system and method that can detect changes in network conditions in a time-varying P2P network environment and effectively manage coordinates applied to each blockchain node. [Means for solving the problem]

[0020] A delay estimation system according to one aspect of the present disclosure for solving the above technical problems is an E2E (edge ​​to edge) delay estimation system between blockchain nodes in a P2P (peer to peer) network, and includes a coordinate system configuration unit that designates an origin node among participating nodes having a distributed ledger of the P2P network, designates an anchor node, and configures a first coordinate system of a predetermined dimension through control message exchange between the origin node, the anchor node, and the participating nodes, and configures a second coordinate system of a further predetermined dimension; and a dimension determination unit that compares delays for each dimension of the first coordinate system and the second coordinate system to determine a dimension to be applied to the current P2P network.

[0021] A control message exchange between a verification node including the coordinate system construction unit and the dimension determination unit and the origin node may be performed through a first control message, a control message exchange between the verification node and the anchor node may be performed through the first control message, and a control message exchange between the anchor node and the participating nodes may be performed through a second control message.

[0022] The first control message may include information indicating a dimension, information indicating a node identifier, information indicating an event type, and information indicating the number of reference nodes.

[0023] The event type may be used to distinguish a control message for configuring a coordinate system from a control message for managing the coordinate system.

[0024] The second control message may include information indicating a message type and information indicating a dimension.

[0025] The E2E delay estimation system may further include a coordinate system management unit that requests the origin node's own coordinate value in the current P2P network after the coordinate system is constructed, and updates the coordinate value of the origin node when the new coordinate value received from the origin node has a difference between the previous coordinate value and a reference value or more.

[0026] A delay estimation method according to another aspect of the present disclosure for solving the above technical problem includes an E2E (edge ​​to edge) delay estimation method between blockchain nodes in a P2P (peer to peer) network. a first reference node information to a plurality of anchor nodes selected from the plurality of participating nodes, the first reference node information being an orderer or an origin node; a second reference node information to a third participating node not belonging to the origin node and the plurality of anchor nodes; a third reference node information to the third participating node; a first control message overhead for a preset first-dimensional coordinate system constructed based on the coordinate values ​​and the E2E delay measurement values ​​from the plurality of anchor nodes and the third participating node; a second control message overhead for a preset second-dimensional coordinate system different from the first dimension constructed based on the coordinate values ​​and the E2E delay measurement values ​​from the plurality of anchor nodes and the third participating node; and a second control message overhead for determining a dimension of an E2E delay estimation coordinate system to be applied to a current P2P network by comparing the first control message overhead with the second control message overhead.

[0027] The delay estimation method may further include a step of requesting the origin node for its own coordinate value in the current P2P network after the coordinate system is constructed, and managing the coordinate value of the origin node to be updated when the new coordinate value received from the origin node has a difference between the previous coordinate value and a reference value or more.

[0028] A delay estimation system according to yet another aspect of the present disclosure for solving the technical problem is an E2E (edge ​​to edge) delay estimation system between blockchain nodes in a P2P (peer to peer) network, comprising: a memory for storing at least one instruction; and a processor coupled to the memory for executing the at least one instruction.

[0029] Here, according to the at least one instruction, the processor performs the steps of: setting one node (e.g., a "first participating node") among a plurality of participating nodes that are blockchain nodes as an orderer or origin node; transmitting first reference node information to a plurality of anchor nodes selected from the plurality of participating nodes; receiving reports of coordinate values ​​and E2E delay measurement values ​​from the plurality of anchor nodes; transmitting second reference node information to a third participating node among the plurality of participating nodes that does not belong to the origin node or the plurality of anchor nodes; receiving reports of coordinate values ​​and E2E delay measurement values ​​from the third participating node. ; calculating a first control message overhead for a preset first-dimensional coordinate system constructed based on coordinate values ​​and E2E delay measurement values ​​from the plurality of anchor nodes and the third participating node; calculating a second control message overhead for the preset second-dimensional coordinate system different from the first dimension constructed based on coordinate values ​​and E2E delay measurement values ​​from the plurality of anchor nodes and the third participating node; and comparing the first control message overhead with the second control message overhead to determine a dimension of the E2E delay estimation coordinate system to be applied to the current P2P network.

[0030] The processor may perform a control message exchange between a verification node and the origin node through a first control message, and may perform a control message exchange between the verification node and the anchor node through the first control message, where the control message exchange between the anchor node and the participating node may be performed through a second control message having a format different from the first control message.

[0031] After the coordinate system is constructed, the processor may further perform a step of requesting the origin node for its own coordinate values ​​in the current P2P network, and managing the coordinate values ​​of the origin node to be updated when the new coordinate values ​​received from the origin node have a difference from the previous coordinate values ​​that is equal to or greater than a reference value. Effect of the Invention

[0032] According to the present disclosure, by defining the Euclidean distance between two blockchain nodes in a P2P (peer to peer) network as indicating the corresponding edge to edge (E2E) delay, all blockchain nodes can be placed in a high-dimensional (four or more dimensions) vector space based on the E2E delay value, and the actual network transmission delay can be quickly calculated through a multidimensional coordinate system, thereby significantly reducing the control message overhead for handling large-scale blockchain nodes and providing a highly scalable and accurate E2E delay estimation method.

[0033] In addition, according to the present disclosure, it is possible to provide an E2E delay estimation system equipped with a coordinate maintenance process so that a coordinate system supporting coordinate values ​​assigned to each blockchain node can be accurately maintained despite time-varying P2P network conditions, i.e., in a time-varying P2P network environment. According to this new E2E delay estimation system, a coordinate maintenance management process can be introduced to effectively maintain the coordinate system, thereby effectively grasping and maintaining the inter-node transmission delay required to build a blockchain P2P network.

[0034] In addition, according to the present disclosure, it is possible to provide E2E delay information estimated between blockchain nodes not only for block transmission but also for the formation of a consensus committee within a blockchain platform. Such E2E delay estimation information can be used not only for permissioned blockchains but also for permissionless blockchains to improve the stability and reliability of the blockchain system. Moreover, an E2E delay estimation system can be easily implemented using already widely known open source, and the performance of the implemented system can be effectively verified through this. [Brief description of the drawings]

[0035] [Figure 1] 1 is an illustrative diagram of a P2P network topology in which an E2E delay estimation method according to an embodiment of the present disclosure may be employed. [Diagram 2] FIG. 1 is a block diagram of a blockchain platform architecture in which an E2E delay estimation system according to an embodiment of the present disclosure can be employed. [Diagram 3] FIG. 3 is a schematic block diagram of an E2E delay estimation system configuration that can be applied to the blockchain platform architecture of FIG. [Figure 4] 4 is a flow chart for explaining the main working principle of the coordinate system construction unit of FIG. 3; [Diagram 5] 4 is a flow chart for explaining the main operating principle of the coordinate system managing unit of FIG. 3; [Figure 6] 1 is a diagram showing a first control message format for transmitting referencing nodes information that can be adopted in the E2E delay estimation method of the present embodiment. [Figure 7] 13 is a diagram showing a second control message format for transmitting and receiving coordinate values ​​that can be adopted in the E2E delay estimation method of the present embodiment. [Figure 8] 10 is an exemplary diagram for more specifically explaining a multi-dimensional coordinate system configuration procedure that can be adopted in the E2E delay estimation method of the present embodiment. FIG. [Figure 9] 10 is an exemplary diagram for more specifically explaining a multi-dimensional coordinate system configuration procedure that can be adopted in the E2E delay estimation method of the present embodiment. FIG. [Figure 10] 10 is an exemplary diagram for more specifically explaining a multi-dimensional coordinate system configuration procedure that can be adopted in the E2E delay estimation method of the present embodiment. FIG. [Figure 11] 10 is an exemplary diagram for more specifically explaining a multi-dimensional coordinate system configuration procedure that can be adopted in the E2E delay estimation method of the present embodiment. FIG. [Figure 12] 1 is an exemplary diagram for explaining a three-dimensional coordinate management process that can be adopted in the E2E delay estimation method of the present embodiment. FIG. [Figure 13] FIG. 11 is a schematic block diagram for explaining the configuration of an E2E delay estimation system according to yet another embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0036] The present invention can be modified in various ways and can have various embodiments, and therefore, a specific embodiment will be illustrated in the drawings and described in detail. However, this is not intended to limit the present invention to a specific embodiment, and it should be understood that the present invention includes all modifications, equivalents, and alternatives within the spirit and technical scope of the present invention.

[0037] Terms such as first, second, etc. may be used to describe various components, but the components should not be limited by the terms. The terms are used only to distinguish one component from another. For example, a first component may be named a second component, and similarly, a second component may be named a first component, without departing from the scope of the invention. The term and / or includes a combination of multiple associated listed items or any item among multiple associated listed items.

[0038] In the examples of this application, "at least one of A and B" may mean "at least one of A or B" or "at least one of a combination of one or more of A and B." Also, in the examples of this application, "one or more of A and B" may mean "one or more of A or B" or "one or more of a combination of one or more of A and B."

[0039] When a component is said to be "coupled" or "connected" to another component, it should be understood that it may be directly coupled or connected to the other component, but there may be other components in between. Conversely, when a component is said to be "directly coupled" or "directly connected" to another component, it should be understood that there are no other components in between.

[0040] The terms used in this application are merely used to describe certain embodiments and are not intended to limit the present invention. A singular expression includes a plural expression unless the context clearly indicates otherwise. In this application, the terms "include" or "have" are intended to specify the presence of features, numbers, steps, operations, components, parts, or combinations thereof described in the specification, and should be understood not to preclude the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0041] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person of ordinary skill in the art to which this invention pertains. Terms as defined in commonly used dictionaries should be interpreted as having a meaning consistent with the meaning they have in the context of the relevant art, and should not be interpreted in an idealized or overly formal sense unless expressly defined in this application.

[0042] Hereinafter, preferred embodiments of the present invention will be described in more detail with reference to the accompanying drawings. In the description of the present invention, the same reference numerals are used for the same components in the drawings to facilitate overall understanding, and duplicate descriptions of the same components will be omitted.

[0043] FIG. 1 is an exemplary diagram of a peer-to-peer (P2P) network topology in which an edge-to-edge (E2E) delay estimation method according to an embodiment of the present disclosure can be employed.

[0044] As shown in FIG. 1, the P2P network topology may be configured taking into account the actual network delay values ​​from Korea to the western and eastern United States. In the P2P network topology, the network delay values ​​may be set based on delay values ​​measured through the actual Internet. For example, the delay values ​​are displayed as numbers on each communication node. In the P2P network topology, the three maximum E2E delays between nodes in each region are about 46 ms, about 37 ms, and about 36 ms. For simplicity, these delay values ​​may be measured assuming that there is one origin node and one verification node, and that 80 nodes are distributed approximately evenly among edge routers. In addition, the coordinate maintenance critical value may be set to 10 ms in consideration of the time-varying P2P network.

[0045] The performance of the blockchain node can be examined by estimating the end-to-end E2E delay between blockchain nodes in a P2P network in a realistic router-level network connected to an edge router or a corresponding realistic router-level network emulation environment. The blockchain node is a validator node and can be any one of the communication nodes including the edge and router on the P2P network.

[0046] Mininet, Containernet, etc. can be used to realistically emulate a network environment. The E2E delay estimation system of this embodiment can be implemented as a container in a blockchain node and can be easily integrated with other containers of an existing blockchain platform.

[0047] In this embodiment, all blockchain nodes in the P2P network may be participating nodes with a distributed ledger. Also, among the blockchain nodes, validating nodes may be designated by participating nodes that are responsible for voluntarily configuring and managing the coordinate system. The validating nodes may be replaced at any time by mutual agreement depending on the node status and network status.

[0048] FIG. 2 is a block diagram of a blockchain platform architecture in which an E2E delay estimation system according to an embodiment of the present disclosure can be employed.

[0049] 2, the blockchain platform for the E2E delay estimation system includes a blockchain module 900 that is responsible for consensus and a network module 1000 that processes block data and consensus message transmission. The blockchain module 900 and the network module 1000 can cooperate closely with each other to improve the blockchain quality of service (QoS).

[0050] The blockchain module 900 may include a committee management module 200, a blockchain interface client module 400, and an audit chain module 600. And the network module 1000 may include a network monitoring & management module 100, a BD / CM transmission module 500 for transmitting blockchain data (BD) and / or consensus messages (CM), and a consensus network module 700.

[0051] The E2E delay estimation system of the present embodiment may include an E2E delay estimation unit 300 included in the network monitoring and management unit 100 of the network module 1000. The E2E delay estimation unit 300 has O(N) control message overhead. Thus, the E2E delay estimation unit 300 is an improvement over the existing O(N 2 ) It has superior performance compared to existing delay estimation techniques that have control message overhead.

[0052] In the following description, for convenience, the E2E delay estimation unit 300 will be referred to as an E2E delay estimation system.

[0053] FIG. 3 is a schematic block diagram of an E2E delay estimation system configuration that can be applied to the blockchain platform architecture of FIG. 2.

[0054] 3, the E2E delay estimation system 300 includes a coordinate system configuration unit 310, a dimension determination unit 330, and a coordinate system management unit 350. The E2E delay estimation system 300 may be installed in a verification node designated by a participating node that is responsible for voluntarily configuring and managing the coordinate system.

[0055] The coordinate system construction unit 310 can perform an E2E delay-based coordinate system constructing process. In other words, the coordinate system construction unit 310 can perform a scalable E2E delay estimation process in a high-dimensional vector space.

[0056] To this end, the coordinate system configuration unit 310 may designate an origin node among the participating nodes having a distributed ledger of the P2P network, designate an anchor node, and configure a coordinate system through control message exchanges with the origin node, the anchor node, and the remaining participating nodes. In particular, the coordinate system configuration unit 310 may configure a coordinate system for a predetermined dimension and configure a coordinate system for another predetermined dimension. That is, the coordinate system configuration unit 310 may configure each coordinate system for a plurality of predetermined dimensions in substantially the same manner.

[0057] The dimension determination unit 330 has functional elements including a dimension-specific delay estimation module 332, a comparison unit 334, and a determination unit 336. Through these functional elements, the dimension determination process estimates the dimensional delay in a multidimensional coordinate system such as 2-dimensional, 3-dimensional, 4-dimensional, 5-dimensional, or 6-dimensional system, compares the estimated dimensional delay values, and determines to use one of the dimensions having the smallest overall delay estimation error value, the dimension having the smallest control message cost required for constructing the coordinate system, and the dimension selected by a preset dimension determination policy as the coordinate system of the P2P network.

[0058] The coordinate system management unit 350 can perform a coordinate maintenance process. The coordinate system management unit 350 can manage the coordinates of the origin node, the anchor node, and the remaining participating nodes in the P2P network that change over time through the coordinate maintenance process, and update them as necessary.

[0059] According to the E2E delay estimation system of the present embodiment, it is possible to estimate the E2E delay between many blockchain nodes with O(N) control message overhead through a P2P network. In particular, it is possible to provide a scalable and accurate E2E delay estimation system with low control message overhead to accommodate large-scale blockchain nodes. In addition, it is possible to accurately maintain the coordinate system despite time-varying P2P network conditions.

[0060] In addition, according to the E2E delay estimation system of the present embodiment, the estimated E2E delay information between blockchain nodes can be used not only for block transmission but also for forming a consensus committee within the blockchain platform. Therefore, the E2E delay estimation system can be effectively applied not only to permissioned blockchains but also to permissionless blockchains.

[0061] Meanwhile, to actually improve the performance of a blockchain platform, it is necessary to estimate the E2E latency between distributed blockchain nodes with low control message overhead. To achieve this goal, we propose an n-dimensional N-dimensional metric where blockchain nodes are represented as points and the Euclidean distance between two points indicates the E2E latency between the nodes. dim An E2E delay-based coordinate system can be constructed in the vector space.

[0062] FIG. 4 is a flow chart for explaining the main working principle of the coordinate system construction unit of FIG.

[0063] 4, the E2E delay estimation system including the coordinate system configuration unit and corresponding to the validation node 410 may first set one of the participating nodes, which is a blockchain node, as the origin node 420 of the coordinate system for a predetermined dimension (S41). The origin node 420 may be one of the validators of Ethereum or an orderer of Hyperledger Fabric.

[0064] Next, the verification node 410 can transmit the referencing node information to the first anchor node 430 selected from the participating nodes using a first control message (S42). The first anchor node 430 can request the coordinate value from the origin node 420 using the second control message based on the referencing node information and can receive the coordinate value response from the origin node 420 (S43a, S43b). At the same time, the first anchor node 430 measures the E2E delay with the origin node 420 (S44). The first anchor node 430 can calculate the coordinate value of the first anchor node 430 through the coordinate value of the origin node 420 received from the origin node 420 and the measured E2E delay. Then, the first anchor node 430 can report the coordinate values ​​of the anchor nodes including the first anchor node 430 and the second anchor node to the verification node 410 (S45).

[0065] In addition, the first anchor node 430 can request coordinate values ​​from at least one second anchor node (not shown) based on the reference node information and using a second control message, and receive a coordinate value response from the second anchor node.

[0066] Next, the verification node 410 may transmit reference node information to at least one second anchor node based on the coordinate value report of the first anchor node 430 and receive a coordinate value report from at least one second anchor node. At this time, before transmitting a control message for reporting the coordinate value to the verification node 410, the second anchor node may request a coordinate value from the origin node 420 based on the reference node information of the verification node 410 and receive a response to the coordinate value from the origin node 420, request a coordinate value from another anchor node, and receive a response to the coordinate value from the other anchor node, thereby measuring an E2E delay with the origin node 420 and an E2E delay with another anchor node.

[0067] In this way, the verification node 410 can obtain the coordinate values ​​of all anchor nodes, and can also obtain the E2E delay value measured at each anchor node.

[0068] Next, the verification node 410 can transmit a first control message to the origin node 420 and participating nodes 440 other than the anchor node (S46). The first control message can include reference node information. The participating node 440 that receives the first control message from the verification node 410 can request coordinate values ​​from anchor nodes including the first anchor node 430 and the origin node 420 through a second control message (S47a, S47b) and can receive responses to the coordinate values ​​from each node through a second control message (S48a, S48b). At this time, the participating node 440 can measure the E2E delay with the origin node 420 and the E2E delay with each anchor node (S49). Then, the participating node 440 can report the coordinate values ​​and the measured E2E delay values ​​to the verification node 410 (S50).

[0069] In this way, the verification node 410 can obtain the coordinate values ​​of all participating nodes 440 other than the origin node 420 and the anchor node. Also, the verification node 410 can obtain the E2E delay values ​​measured at each of all participating nodes.

[0070] According to the above-mentioned configuration, the coordinate system construction unit or the E2E delay estimation system including the coordinate system construction unit can construct a coordinate system of a specific dimension. Also, the coordinate system construction unit or the E2E delay estimation system including the coordinate system construction unit can construct a coordinate system for a predetermined further dimension by repeating the above process substantially identically for the further dimension. For example, a three-dimensional coordinate system includes at least three anchor nodes, a four-dimensional coordinate system includes at least four anchor nodes, a five-dimensional coordinate system includes at least five anchor nodes, and a six-dimensional coordinate system includes at least six anchor nodes to construct a coordinate axis starting from an origin node.

[0071] FIG. 5 is a flow chart for explaining the main working principle of the coordinate system managing unit of FIG.

[0072] 5, an E2E delay estimation system including a coordinate system management unit and corresponding to a validation node 410 can transmit reference node information to an origin node 420, which is an orderer of a P2P network (S51). Here, the origin node 420 operates as an origin node of a coordinate system for a specific dimension determined by a dimension determination unit among the dimensions in which the E2E delay is estimated by the coordinate system configuration unit. That is, the origin node 420 can receive reference node information from the validation node 410 through a first control message (S51).

[0073] The origin node 420 can use the second control message to request coordinate values ​​from each anchor node including the first anchor node 430 and each participating node 440 (S52a, S52b) and receive responses to the coordinate values ​​from each anchor node and each participating node (S53a, S53b). At this time, the origin node 420 can measure the E2E delay with each anchor node and the E2E delay with each participating node 440 by transmitting and receiving the second control message (S54).

[0074] Thereafter, the origin node 420 can calculate new coordinate values ​​based on the measured E2E delay value and the coordinate values ​​received from each anchor node and each participating node (S54), and can generate relative position change information based on the calculated new coordinate values ​​and the existing coordinate values.

[0075] Next, the origin node 420 can report the new coordinate values ​​and relative position change information to the verification node 410 (S56). That is, the verification node 410 can receive a report of the new coordinate values ​​and relative position change information from the origin node 420. The new coordinate values ​​may follow the fluctuation of the P2P network itself, which changes over time.

[0076] Next, the verification node 410 can determine whether a coordinate update is necessary based on the new coordinate values ​​(S57). If a coordinate update is necessary, the verification node 410 can transmit a first control message for the coordinate value update to the origin node 420 (S58). That is, the origin node 420 can receive the first control message for the coordinate value update from the verification node 410.

[0077] When the first control message for coordinate value update is received, the origin node 420 can update its own coordinates and the coordinate system including the origin node 420 based on the coordinate value update information.

[0078] According to the above-mentioned configuration, the verification node 410 can configure an E2E delay-based coordinate system through the anchor node, configure a coordinate system for each dimension by configuring a control message with all participating nodes, and estimate the E2E delay of each coordinate system. According to this configuration, the verification node 410, i.e., the E2E delay estimation system, can select and manage a specific dimensional coordinate system that shows optimal performance for the current P2P network based on the E2E delay state estimated for each dimensional coordinate system.

[0079] In addition, a specific control message format can be designed and used to efficiently obtain the coordinate values ​​of each node in the P2P network.

[0080] FIG. 6 illustrates a first control message format for transmitting referencing nodes information that can be adopted in the E2E delay estimation method of the present embodiment.

[0081] 6, the first control message 610 may include information indicating an N-dim dimension (Ndim), information indicating a node identifier (NodeIdx), information indicating an event type (EventType), and information indicating the number of reference nodes (NumRef), where N may be a natural number between 2 and 10.

[0082] An event type (EventType) can be used to distinguish whether it is a control message for constructing a coordinate system or a control message for managing a coordinate system. For example, an event type of 0 indicates a control message for constructing a coordinate system, and an event type of 1 indicates a control message for managing a coordinate system. In addition to the format of 0 and 1, the event type can be configured in various formats of at least two different values, numbers, letters, symbols, or combinations thereof.

[0083] Also, the first control message 610 may include reference node information including a first reference node IP (internet protocol) (Ref Node IP #1), a second reference node IP (Ref Node IP #2), etc. Such a first control message 610 is transmitted from a verification node to a participating node. The participating node may include an origin node and an anchor node.

[0084] FIG. 7 illustrates a second control message format for transmitting and receiving coordinate values ​​that can be adopted in the E2E delay estimation method of the present embodiment.

[0085] Referring to FIG 7, the second control message 710 may include information indicating a message type (MsgType) and information indicating a corresponding dimension (Ndim). The message type is for indicating whether the corresponding control message is a request message or a response message. The message type may be displayed as "A" when the corresponding control message is a request message, and may be displayed as "B" when the corresponding control message is a response message, but is not limited thereto. The message type may be configured in various forms of at least two different values, numbers, letters, symbols, or combinations thereof.

[0086] In addition, the second control message 710 may include coordinate values ​​represented as a first coordinate value (coordinate value x_1), a second coordinate value (coordinate value x_2), an Nth coordinate value (coordinate value x_Ndim), and so on.

[0087] The second control message 710 is exchanged between the participating nodes, which may include the origin node and the anchor node.

[0088] According to the control message formats of Figures 6 and 7 described above, each participating node can measure the E2E delay value while exchanging a second control message with other reference nodes, i.e., participating nodes that already identify the coordinate value, to obtain the coordinate value.

[0089] After the E2E delay-based coordinate system is established, the validating node can perform a coordinate maintenance process periodically or on-demand upon request of at least one of the participating nodes to detect changes in the network state and manage the coordinate system.

[0090] As mentioned above, any two nodes can be logically connected to each other through a P2P network, so multiple (N peer ) to measure all E2E delays between participating nodes in peer 2 ) control message overhead. Such overhead can place a heavy burden on the P2P network as the number of participating nodes increases. Therefore, in the E2E delay estimation system of the present embodiment, peer ) to provide an efficient E2E delay estimation process with message overhead.

[0091] 8 to 11 are exemplary diagrams for more specifically explaining a multi-dimensional coordinate system configuration procedure that can be adopted in the E2E delay estimation method of this embodiment.

[0092] Referring to FIG. 8 to FIG. 11, the E2E delay estimation system is a preselected verification node with a minimum dimension D min to maximum dimension D max A specific dimension n is selected from the range dim A coordinate system can be constructed between the origin node and a randomly selected anchor node through control message exchange.

[0093] Here, the specific dimension n dim can be a natural number between 1 and 10, and the number of anchor nodes selected by the validating node is n dim There can be one.

[0094] In the following, (x i 1,x i 2,···,x i Ndim ) is n dim Let us denote the coordinate value of node i in the dimensional vector space, and ij denotes the E2E delay measured between node i and node j, where the origin node may be represented as Node#0, and the anchor node may be set to be located as far away as possible from the origin node to reduce the effect of time-varying E2E delay and increase the accuracy of the coordinate system.

[0095] Specifically, as shown in FIG. 8, the E2E delay estimation system (hereinafter also referred to simply as the "delay estimation system") can set one of the validators of Ethereum or the orderer of Hyperledger Fabric as the origin node (Node#0) as the origin of the coordinate system. The coordinates of the origin can be set as (0,0,...,0). That is, in the N-dimension, the origin node (x 0 1,x 0 2,···,x 0 Ndim ) can be set to (0,0,...,0).

[0096] Next, the delay estimation system can select an arbitrary node among the participating nodes as the first node (Node#1) and define the line between the orderer and the first node (Node#1) as the first axis (x1). Then, the delay between the orderer and the first node (Node#1) can be measured through the orderer. Then, the x1 coordinate of the first node (Node#1) can be defined as the measured delay or a value corresponding to the delay.

[0097] The x1 coordinate of the first node (Node#1) is (x 1 1, 0, , 0), the first node (Node#1) is the first anchor node and (t 0,1 t can be set as 1, 0, . . . , 0). 0,1 indicates the delay time (time, t) between the origin node (Node#0) and the first anchor node (Node#1).

[0098] Next, as shown in Figure 9, the delay estimation system selects an arbitrary node from among the participating nodes as the second node (Node#2). That is, the delay estimation system selects the second node (Node#2), which is not located on the line connecting the origin node (Node#0) and the first node (Node#1), as the second anchor node. After that, the delay estimation system constructs the x1-x2 plane using the origin node, the first anchor node, and the second anchor node.

[0099] Then, the delay estimation system acquires a delay value between the second node (Node #2) and the orderer and a delay value between the first node (Node #1), and can calculate the delay between the origin node and the first anchor node based on the acquired E2E delay value and the coordinate values ​​received from the origin node and the first anchor node as shown in the following Equation 1 and Equation 2, respectively.

number

number

[0100] Here, the second node (Node#2) is the second anchor node, and its coordinate value is (x 2 1,x 2 2,...,0).

[0101] Therefore, among the candidate coordinate values ​​of the second anchor node, the second node (Node#2), 2 1 Coordinate value and x 2 The two coordinate values ​​are shown in Equation 3 and Equation 4, respectively.

number

number

[0102] In fact, the two coordinate values ​​x 2 1 and x 2 2 satisfies equation 1 and equation 2.

[0103] Next, as shown in Figure 10, the delay estimation system can select the third anchor node (Node#3) that is not placed on the x1-x2 plane set above. That is, the delay estimation system can construct an x1-x2-x3 space with the origin node (Node#0) as the origin using the origin node (Node#0), the first anchor node (Node#1), the second anchor node (Node#2), and the third anchor node (Node#3).

[0104] Thereafter, the delay estimation system can obtain the E2E delays with the origin node, the first anchor node, and the second anchor node through the third anchor node (Node#3), and can obtain the candidate coordinate value of the third anchor node calculated by the third anchor node. Of course, the candidate coordinate value of the third anchor node can be calculated and obtained based on the E2E delay value received from the third anchor node by the delay estimation system, which is the verification node.

[0105] The coordinate value of the third anchor node is (x 3 1,x 3 2,x 3 3, , 0), the candidate coordinate value of the third anchor node x 3 1,x 3 2,x 3 3 can be expressed as the following Equation 5, Equation 6, and Equation 7.

number

number

number

[0106] Now, the remaining anchor nodes, i.e., the fourth anchor node to n dim The equations for anchor nodes up to the th anchor node can be generalized.

[0107] Among the number of anchor nodes predetermined according to the preset dimension, the i-th (1≦i≦n dim ) The anchor node measures the E2E delay value with the origin node and the E2E delay value with the previous anchor node, respectively. After measuring the E2E delay value and receiving the coordinate value of the previous anchor node, the candidate coordinate value of the i-th anchor node can be determined by the generalized formula.

[0108] As shown in Figure 11, the coordinates of the i-th anchor node are (x i 1,x i 2,···x i i ,0,···,0), the candidate coordinate values ​​of the i-th anchor node can be generalized as in Equation 8 and Equation 9.

number

number

[0109] Based on Equation 8 and Equation 9, the delay estimation system is dim ) th The same procedure can be repeated until the candidate coordinate values ​​of the anchor node 4 are found. Meanwhile, since it is difficult to explain the coordinate system construction process from the fourth anchor node in a diagram, the pseudo code mentioned in the present inventor's paper can be referred to.

[0110] To measure the E2E delay between the origin node and all anchor nodes, we use an arbitrary (n dim +1) th Nodes of (n dim +1) th By using this node, the coordinates of the previous anchor node can be finally determined, and the existence of the coordinate values ​​of the current node can be guaranteed, as shown in Equation 10.

number

[0111] Here, (x ndim+1 1,x ndim+1 2,···,x ndim+1 ndim ) is (n dim +1) th The coordinate values ​​of the participating nodes may be:

[0112] Once a coordinate system of a particular dimension is constructed, the new joining node can find its own coordinates by transmitting a request message to the origin node, multiple anchor nodes, and multiple reference nodes, and then measuring the E2E delay value until it receives a corresponding response message containing the coordinates. The coordinates of the new joining node can be obtained through the same process as described above.

[0113] In a distributed network environment, obtaining sufficient information about nodes can sometimes be more difficult than identifying their coordinate values, i.e., in the above-mentioned coordinate system construction process, for example, when an inverse matrix does not exist in a matrix form, it may be difficult to determine the coordinates or additional delays may occur while changing the reference node. Therefore, in order to solve such problems without additional delays, the delay estimation system of the present embodiment allows a new joining node to contact a sufficient number of randomly selected nodes including the anchor node to obtain its coordinate values.

[0114] In the above case, for example, when only the origin node (Node#0) and three reference nodes are used, the inverse matrix of Equation 6 may not exist. To prepare for such a case, the delay estimation system may be configured to exchange control messages with four or more nodes in an overdetermined system operation mode to measure transmission delays and request coordinate values ​​to obtain an approximate solution.

[0115] The process of obtaining the approximate solution is shown in the following Equation 11.

number

[0116] In formula 11, N ref is the number of referencing nodes.

[0117] According to Equation 11, the approximate solution (vector ω app ) and (vector ω app -The error expressed by the norm of vector b) can be minimized.

number

[0118] Meanwhile, the delay estimation system can stably maintain the coordinate system by performing a coordinate maintenance process for the accuracy of coordinates in a time-varying P2P network. That is, the coordinate values ​​of participating nodes change depending on the P2P network conditions that change over time. Therefore, the delay estimation system can operate the coordinate maintenance process to efficiently maintain the accuracy of the coordinate system despite the changes in network conditions.

[0119] That is, the origin node (Node#0) can periodically calculate its own coordinates using the coordinate values ​​of other nodes and the newly measured delay. At this time, if the calculated coordinate values ​​of the origin node (Node#0) deviate from the origin by more than a reference value, a new coordinate system can be constructed.

[0120] For this reason, in the coordinate maintenance process, the origin node (Node#0) is dim Any number of nodes (Node#1, ..., Node#N ref ), measure the transmission delay between each node through control message exchange, and calculate the coordinate value of the origin node (Node#0) by inverting Equation 13.

[0121] Thus, the delay estimation system is a coordinate maintenance process, the origin node is N ref The origin node can transmit a request message to the reference node. After the current coordinate system is constructed, the origin node performs the same procedure as the process in which a new joining node obtains its coordinates, and can calculate its approximated coordinate value based on the response message as shown in Equation 13.

number

[0122] FIG. 12 shows an example of a coordinate maintenance process that can be applied to a three-dimensional coordinate system.

[0123] FIG. 12 is an exemplary diagram for explaining a three-dimensional coordinate management process that can be adopted in the E2E delay estimation method of the present embodiment.

[0124] Referring to Figure 12, in the coordinate management process of the delay estimation system, the origin node (Node #0) can select multiple nodes selected by any anchor node or participating node, for example, at least the first node (Node #1), the second node (Node #2), the third node (Node #3), and the kth node (Node #k).

[0125] After that, the origin node (Node#0) exchanges control messages with each of the selected nodes to determine the transmission delay (d 0,1 ,d 0,2 , ,d 0,k ) can be measured.

[0126] Next, the origin node can calculate the coordinate values ​​(x0, y0, z0) of the origin node (Node#0) through the inverse matrix operation of the matrix as shown in Equation 14.

number

[0127] If the calculated coordinate value of the origin node (Node #0) deviates from the existing coordinate value of the previous origin node (Node #0), the origin (0,0,0), by more than a predetermined reference value, the delay estimation system can operate to reconstruct the coordinate system.

[0128] On the other hand, in the above embodiment, the origin node (Node #0), which is the orderer, was illustrated as being located at the reference coordinates (0,0,0), but this embodiment is described assuming that the origin node has been moved to arbitrary coordinates (x0,y0,z0).

[0129] In this manner, according to the present embodiment, even if the E2E delay between nodes changes due to time-varying changes in the P2P network status, it is possible to monitor the changes in the network status, effectively manage the coordinate system centered on a specific reference node, and update it as necessary.

[0130] As mentioned above, non-zero coordinates of the origin node indicate that the network state between blockchain nodes in a P2P network has changed. Therefore, the coordinate system needs to be updated immediately. To reduce the overhead for updating the coordinate system, the delay estimation system can be configured to update the coordinate system only if the difference between the newly calculated coordinates of the origin node and the origin is greater than a critical value. The critical value may depend on the time-varying nature of the network environment. Therefore, the control message complexity in E2E delay estimation between blockchain nodes in a P2P network is O(N peer )

[0131] FIG. 13 is a schematic block diagram for explaining a configuration of an E2E delay estimation system according to still another embodiment of the present disclosure.

[0132] 13, the delay estimation system 1300 may include at least one processor 1310. The delay estimation system 1300 may further include a memory 1320 or a transceiver 1330 connected to a network to perform communication. The delay estimation system 1300 may further include at least one of an input interface device 1340, an output interface device 1350, and a storage device 1360. Each component included in the delay estimation system 1300 may be connected to a bus 1370 to perform communication.

[0133] The processor 1310 may represent a central processing unit (CPU), a graphics processing unit (GPU), or a dedicated processor on which methods according to embodiments of the present invention are performed.

[0134] Each of the memory 1320 and the storage device 1360 may be composed of at least one of a volatile storage medium and a non-volatile storage medium, for example, the memory 1320 may be composed of at least one of a read only memory (ROM) and a random access memory (RAM).

[0135] The processor 1310 may also execute program commands stored in at least one of the memory 1320 and the storage device 1360. The program commands may include at least one command for a coordinate system configuration process, at least one command for a dimension determination process, at least one command for a coordinate management process, etc.

[0136] The transceiver device 1330 may include communication interfaces or sub-communication systems for short-range wireless networks or cable connections, communication with satellites, wired or wireless communication with general-purpose base stations, and connections to mobile edge core networks or core networks via ideal backhaul links or non-ideal backhaul links.

[0137] The input interface device 1340 may include at least one selected from input means such as a keyboard, a microphone, a touchpad, a touch screen, etc., and an input signal processing unit that maps or processes a signal input through the at least one input means with a pre-stored command.

[0138] The output interface device 1350 may include an output signal processing unit that maps or processes a signal outputted under the control of the processor 1310 in a pre-stored signal form or level, and at least one output means that outputs a signal or information in the form of vibration, light, etc. according to a signal from the output signal processing unit. The at least one output means may include at least one selected from output means such as a speaker, a display device, a printer, an optical output device, a vibration output device, etc.

[0139] In addition, the methods according to the present invention may be embodied in the form of program instructions that can be executed by various computer means and recorded on a computer readable medium. The computer readable medium may include, alone or in combination with the program instructions, data files, data structures, and the like. The program instructions recorded on the computer readable medium may be those specially designed and constructed for the present invention, or they may be of the type that is well known and available to those skilled in the art of computer software.

[0140] Examples of computer readable media include hardware devices specially configured to store and execute program instructions, such as ROM, RAM, flash memory, etc. Examples of program instructions include high level language code that may be executed by a computer using an interpreter, as well as machine code, such as produced by a compiler. The aforementioned hardware devices may be configured to operate with at least one software module to perform the operations of the present invention, and vice versa.

[0141] Although some aspects of the invention have been described in the context of an apparatus, they may also be presented as corresponding method descriptions, where the blocks or apparatus correspond to method steps or features of the method steps. Similarly, aspects described in the context of a method may also be presented as corresponding blocks or items or features of the corresponding apparatus. Some or all of the method steps may be performed by (or using) a hardware apparatus, such as, for example, a microprocessor, a programmable computer, or electronic circuitry. In some embodiments, at least one or more of the most significant method steps may be performed by such an apparatus.

[0142] In some embodiments, a programmable logic device, such as a field programmable gate array, may be used to perform some or all of the functionality of the methods described herein. In some embodiments, a field programmable gate array may operate in conjunction with a microprocessor to perform one of the methods described herein. In general, the methods are preferably performed by some hardware device.

[0143] Although the present invention has been described with reference to the embodiments, it will be understood that those skilled in the art can make various modifications and variations of the present invention without departing from the spirit and scope of the present invention as set forth in the claims below.

Claims

1. An edge-to-edge (E2E) delay estimation system between blockchain nodes in a peer-to-peer (P2P) network, comprising: A coordinate system configuration unit that designates an origin node among participating nodes having a distributed ledger of a P2P network, designates an anchor node, and configures a first coordinate system of a predetermined dimension through control message exchanges between the origin node, the anchor node, and the participating nodes, and configures a second coordinate system of yet another predetermined dimension; and a dimension determination unit for comparing delays for each dimension of the first coordinate system and the second coordinate system to determine a desired dimension.

2. 2. The E2E delay estimation system of claim 1, wherein a control message exchange between a verification node including the coordinate system construction unit and the dimension determination unit and the origin node is performed through a first control message, a control message exchange between the verification node and the anchor node is performed through the first control message, and a control message exchange between the anchor node and the participating nodes is performed through a second control message.

3. The E2E delay estimation system of claim 2 , wherein the first control message includes information indicating a dimension, information indicating a node identifier, information indicating an event type, and information indicating a number of reference nodes.

4. The E2E delay estimation system of claim 3 , wherein the event type is used to distinguish a control message for configuring a coordinate system from a control message for managing the coordinate system.

5. The E2E delay estimation system of claim 2 , wherein the second control message includes information indicating a message type and information indicating a dimension.

6. The E2E delay estimation system of claim 1, further comprising a coordinate system management unit that, after the coordinate system is constructed, requests the origin node for its own coordinate value in the current P2P network, and updates the coordinate value of the origin node when the new coordinate value received from the origin node has a difference between the previous coordinate value and a reference value or more.

7. A method for estimating edge-to-edge (E2E) delay between blockchain nodes in a peer-to-peer (P2P) network, comprising: A step of setting a first participating node among a plurality of participating nodes, which are blockchain nodes, as an orderer or an origin node by the validating node; transmitting first reference node information to a plurality of anchor nodes selected from the plurality of participating nodes; receiving reports of coordinate values ​​and E2E delay measurements from the plurality of anchor nodes; transmitting second reference node information to a third participating node not belonging to the origin node and the plurality of anchor nodes among the plurality of participating nodes; receiving a report of coordinate values ​​and E2E delay measurement values ​​from the third participating node; calculating a first control message overhead for a preset first-dimensional coordinate system constructed based on coordinate values ​​and E2E delay measurements from the plurality of anchor nodes and the third participating node; calculating a second control message overhead for a second dimensional coordinate system different from the first dimension, the second dimensional coordinate system being constructed based on coordinate values ​​and E2E delay measurements from the plurality of anchor nodes and the third participating node; and determining a dimension of an E2E delay estimation coordinate system to be applied to a current P2P network by comparing the first control message overhead with the second control message overhead.

8. 8. The E2E delay estimation method of claim 7, wherein a control message exchange between the verification node and the origin node is performed through a first control message, a control message exchange between the verification node and the anchor node is performed through the first control message, and a control message exchange between the anchor node and the participating nodes is performed through a second control message.

9. The method of claim 8 , wherein the first control message includes information indicating a dimension, information indicating a node identifier, information indicating an event type, and information indicating a number of reference nodes.

10. The E2E delay estimation method of claim 9 , wherein the event type is used to distinguish a control message for configuring a coordinate system from a control message for managing the coordinate system.

11. The method of claim 8 , wherein the second control message includes information indicating a message type and information indicating a dimension.

12. 8. The E2E delay estimation method of claim 7, further comprising the step of requesting the origin node for its own coordinate value in the current P2P network after the coordinate system is constructed, and managing the coordinate value of the origin node to be updated when the new coordinate value received from the origin node has a difference between the previous coordinate value and a reference value or more.

13. An edge-to-edge (E2E) delay estimation system between blockchain nodes in a peer-to-peer (P2P) network, comprising: a processor coupled to a memory storing at least one instruction for executing the at least one instruction; The at least one instruction causes the processor to: Setting a first participating node among a plurality of participating nodes, which are blockchain nodes, as an orderer or an origin node; transmitting first reference node information to a plurality of anchor nodes selected from the plurality of participating nodes; receiving reports of coordinate values ​​and E2E delay measurements from the plurality of anchor nodes; transmitting second reference node information to a third participating node not belonging to the origin node and the plurality of anchor nodes among the plurality of participating nodes; receiving a report of coordinate values ​​and E2E delay measurement values ​​from the third participating node; calculating a first control message overhead for a preset first-dimensional coordinate system constructed based on coordinate values ​​and E2E delay measurements from the plurality of anchor nodes and the third participating node; calculating a second control message overhead for a second dimensional coordinate system different from the first dimension, the second dimensional coordinate system being constructed based on coordinate values ​​and E2E delay measurements from the plurality of anchor nodes and the third participating node; and determining a dimension of an E2E delay estimation coordinate system to be applied to a current P2P network by comparing the first control message overhead with the second control message overhead.

14. The processor performs a control message exchange between a verification node and the origin node through a first control message, and performs a control message exchange between the verification node and the anchor node through the first control message; The E2E delay estimation system of claim 13 , wherein the control message exchange between the anchor node and the participating nodes is performed through a second control message having a format different from that of the first control message.

15. The E2E delay estimation system of claim 14 , wherein the first control message includes information indicating a dimension, information indicating a node identifier, information indicating an event type, and information indicating a number of reference nodes.

16. The E2E delay estimation system of claim 15, wherein the event type is used to distinguish a control message for configuring a coordinate system from a control message for managing the coordinate system.

17. The E2E delay estimation system of claim 14 , wherein the second control message includes information indicating a message type and information indicating a dimension.

18. The E2E delay estimation system of claim 13, wherein the processor further performs a step of requesting the origin node for its own coordinate value in the current P2P network after the coordinate system is constructed, and managing the coordinate value of the origin node to be updated when the new coordinate value received from the origin node has a difference between the previous coordinate value and a reference value or more.

Images