WO2023249166A1 - 멀티 클라우드의 블록 데이터 전송을 위한 유효 대역폭 추정 방법과 제어 메시지 생성 방법 및 트리 정보 전달 방법과 이를 위한 블록 전송 시스템 - Google Patents

멀티 클라우드의 블록 데이터 전송을 위한 유효 대역폭 추정 방법과 제어 메시지 생성 방법 및 트리 정보 전달 방법과 이를 위한 블록 전송 시스템 Download PDF

Info

Publication number
WO2023249166A1
WO2023249166A1 PCT/KR2022/015119 KR2022015119W WO2023249166A1 WO 2023249166 A1 WO2023249166 A1 WO 2023249166A1 KR 2022015119 W KR2022015119 W KR 2022015119W WO 2023249166 A1 WO2023249166 A1 WO 2023249166A1
Authority
WO
WIPO (PCT)
Prior art keywords
block
node
nodes
effective bandwidth
transactions
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/KR2022/015119
Other languages
English (en)
French (fr)
Inventor
송황준
지승규
노현민
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
POSTECH Research and Business Development Foundation
Original Assignee
POSTECH Research and Business Development Foundation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020220075510A external-priority patent/KR102748246B1/ko
Priority claimed from KR1020220085477A external-priority patent/KR102723667B1/ko
Application filed by POSTECH Research and Business Development Foundation filed Critical POSTECH Research and Business Development Foundation
Publication of WO2023249166A1 publication Critical patent/WO2023249166A1/ko
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1042—Peer-to-peer [P2P] networks using topology management mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Definitions

  • the present invention relates to a block transmission system for a multi-cloud scalable Hyperledger Fabric blockchain, an effective bandwidth estimation method for block data transmission applicable to the block transmission system, a control message generation method, and a tree information transmission method.
  • Blockchain systems which are distributed ledgers, are attracting considerable attention in academia and industry as they make it impossible to change or deceive stored data.
  • One of the most popular blockchain applications is cryptocurrency.
  • blockchain-based non-fungible tokens (NFTs) have been rapidly emerging in the online market, creating a new paradigm of value.
  • NFTs non-fungible tokens
  • Blockchain applications of various services are raising high-level scalability requirements.
  • the well-known blockchain trilemma is that it is inherently impossible to design a secure and scalable blockchain in a distributed environment. Therefore, blockchain systems are usually designed for a purpose by sacrificing one of these properties.
  • blockchain systems are divided into two types: permissioned blockchains that sacrifice decentralization, and permissionless blockchains that sacrifice scalability.
  • permissioned blockchains that sacrifice decentralization
  • permissionless blockchains that sacrifice scalability.
  • a permissioned blockchain only permissioned peers can participate in the consensus, whereas in a permissionless blockchain, anyone can participate in the consensus.
  • Hyperledger Fabric is one of the most widely used permissioned blockchain platforms. Hyperledger Fabric verifies user transactions through a series of execution, ordering, and validation performed on various nodes to achieve high scalability. To further improve the performance of Hyperledger Fabric, many research efforts are being made to separate execution and consensus procedures.
  • Hyperledger Fabric Despite the high level of scalability of Hyperledger Fabric, there are inherent concerns about the poor security and decentralization of Hyperledger Fabric blockchains, such as the integrity of the distributed ledger, simple consensus mechanism, and deployment of the system in a single data center or cloud.
  • Hyperledger Fabric Working Group is attempting to specify and standardize an interoperability workflow that will allow service providers hosted in different clouds to build and join business networks independently of their infrastructure.
  • fabric blockchain architecture through multiple clouds may have significantly lower transaction throughput compared to a single cloud environment due to network delay, which may eventually lead to scalability problems.
  • P2P peer-to-peer
  • Fabric and Ethereum blockchains typically implement P2P network modules such as Gossip P2P and devP2P.
  • P2P network protocols can be classified into two groups: tree-based technologies and mesh-based technologies.
  • tree-based technology a peer has a parent peer and several child peers. The peer receives data from the upper peer and relays the received data to the lower peer.
  • existing tree-based technologies typically have low latency because they push data from source to destination to minimize latency.
  • QoS quality of service
  • mesh-based technology was proposed.
  • peers In mesh-based technologies, peers have multiple links to other peers and there is no parent-child relationship. Peers exchange data with each other, and pull forwarding is adopted as the forwarding mechanism. Examples of existing mesh-based technologies include CoolStreaming, Bullet, Chainsaw, IPTV over P2P networks, and P2P streaming based on mesh pools.
  • the present invention was derived to meet the needs of the prior art described above, and the purpose of the present invention is to deliver blocks as quickly as possible to all participating nodes randomly located in the multi-cloud, thereby improving the scalability of the Hyperledger Fabric blockchain in the multi-cloud.
  • the goal is to provide an intelligent block transfer system that can increase transaction throughput.
  • Another object of the present invention is to provide an effective bandwidth estimation method and device for block data transmission that can be applied to a block transmission system for a multi-cloud scalable Hyperledger Fabric blockchain.
  • Another purpose of the present invention is to estimate the effective bandwidth for block data transmission, which can increase the scalability and transaction throughput of Hyperledger Fabric blockchain in multi-cloud by delivering blocks as quickly as possible to all participating nodes randomly located in multi-cloud.
  • the purpose is to provide methods and devices.
  • Another purpose of the present invention is to provide a method for generating a control message of a block transmission system for a multi-cloud scalable Hyperledger Fabric blockchain and a control message format for the same.
  • Another purpose of the present invention is to deliver tree information in an intelligent block transfer system that can increase the scalability and transaction throughput of Hyperledger Fabric blockchain in multi-cloud by delivering blocks as quickly as possible to all participating nodes randomly located in multi-cloud.
  • the goal is to provide a method.
  • Another object of the present invention is to provide a P2P (peer to peer) network protocol using a control message format applicable to the above-described intelligent block transfer system.
  • P2P peer to peer
  • the present invention focuses on improving the transaction throughput of fabric blockchain through multi-cloud rather than a single data center.
  • the block transmission system of the present invention designs a P2P system based on a hybrid P2P (peer to peer) multicast tree network to successfully perform the role of the backbone network of the fabric blockchain in multi-cloud, and combines the fabric's P2P network module and It is designed to integrate.
  • the block transmission process of the block transmission system of the present invention includes a delay estimation process, an effective bandwidth estimation process, a node clustering and cluster leader selection process, and a hybrid P2P multicast tree construction process as major components.
  • the present invention provides a method and device for estimating effective bandwidth for block data transmission that can be applied to a block transmission system for a multi-cloud scalable Hyperledger Fabric blockchain.
  • Effective bandwidth estimation for block data transmission is to estimate the effective bandwidth required for block propagation to construct an effective P2P multicast tree in Hyperledger Fabric. Transactions are distributed exponentially and blocks are distributed by the orderer. Assuming that a block is generated at a fixed size, the block generation cycle follows a Gaussian model and the block transmission time is calculated to complete the transmission of the previous block at a certain probability or higher before the next block is created, and the effective bandwidth at that time is calculated. It is configured to calculate . The calculated effective bandwidth can increase depending on the number of transactions included in the block and the transaction occurrence rate.
  • An effective bandwidth estimation method for block data transmission in a multi-cloud for solving the above technical problem is an effective bandwidth estimation method for block data transmission in a multi-cloud, where the block data following the Gaussian model is estimated.
  • the generation cycle calculating a block transmission time to complete transmission of the previous block with a preset success probability before generation of the next block; and estimating effective bandwidth based on the number of transactions included in the block, transaction size, block header size, and block transmission time.
  • the method may further include generating the block when a preset number of transactions arrive at the orderer.
  • the time interval between two adjacent transactions included in the block may be set to be distributed exponentially.
  • the method may further include defining a time interval until the transactions arrive using the Gaussian model when the number of transactions included in the block is greater than a preset reference value.
  • the Gaussian model may be defined as Equation 12.
  • the block transmission time may be defined as Equation 13.
  • the method may further include setting a probability of success that probabilistically guarantees a smaller block buffering time at the expense of upload bandwidth usage as the block transfer time is set smaller.
  • the effective bandwidth can be estimated based on an equation such as Equation 14.
  • the transaction size is the block header size, is the time interval until the transactions arrive.
  • the effective bandwidth increases linearly according to the transaction rate of the exponential distribution probability model.
  • the effective bandwidth decreases exponentially with respect to the number of transactions.
  • the exponential decrease rate of the number of transactions may be set to increase as the probability of success increases in the calculation step.
  • the method sets the buffering time of the oldest transaction among the transactions to keep the time interval until the transactions arrive smaller than the preset size, even if the number of transactions is less than the predetermined number of transactions.
  • a step of immediately generating a block if it is greater than a predetermined threshold may be further included.
  • An effective bandwidth estimating device for block data transmission in a multi-cloud for solving the above technical problem is an effective bandwidth estimating device for block data transmission in a multi-cloud, comprising: a processor; and a memory coupled to the processor and storing at least one instruction to be executed by the processor, wherein the at least one instruction is configured to, by the processor, generate a next block in a generation cycle of a block following a Gaussian model. Calculating block transmission time to complete transmission of the previous block with a previously set success probability, and estimating effective bandwidth based on the number of transactions included in the block, transaction size, block header size, and block transmission time. It can be configured to perform steps.
  • the at least one command is, by the processor, in the calculation step, in the generation cycle of the block that follows the Gaussian model, transactions for transmitting the block data are distributed exponentially and the errors of the multi-cloud are distributed exponentially.
  • the orderer can process blocks to be created with a fixed size.
  • the at least one command may cause the processor to further perform the step of generating the block when a preset number of transactions arrive at the orderer.
  • the at least one command may be processed by the processor to exponentially distribute the time interval between two adjacent transactions included in the block.
  • the at least one command may define, by the processor, a time interval until transactions arrive when the number of transactions included in the block is greater than a preset reference value using the Gaussian model. .
  • the at least one instruction sets the probability of success, by the processor, to probabilistically ensure a smaller block buffering time at the expense of upload bandwidth usage as the block transfer time is set smaller. It may be configured to perform further steps.
  • the at least one instruction is configured to, by the processor, keep the time interval until the transactions arrive less than a preset size even if the number of transactions included in the block is less than a predetermined number of transactions. To this end, if the buffering time of the oldest transaction among the transactions is greater than a predetermined threshold, a step of immediately generating a block may be further performed.
  • control message format applicable to a block transmission system for a multi-cloud scalable Hyperledger Fabric blockchain and a tree information transfer process using this control message format.
  • the control message format of the present invention relates to a method or device for generating, storing, or transmitting a control message format, and may include such a method and device.
  • a control message generation method for solving the above technical problem is a control message generation method of a block transmission system for a multi-cloud scalable Hyperledger Fabric blockchain, wherein a plurality of participating nodes are connected to a plurality of nodes. Classifying nodes into clusters; selecting a cluster leader for each of the plurality of clusters from among the plurality of participating nodes; and constructing a hybrid P2P (peer to peer) multicast tree based on the plurality of clusters and information about the cluster leader.
  • P2P peer to peer
  • the configuring step includes tree information of each participating node included in the hybrid P2P multicast tree, including a node IP (internet protocol) field, the number of child nodes field, and a child node list. It may include the step of forming a combination of offset (offset of child nodes lists) fields.
  • the node IP field represents the IP address of the current node
  • the child node number field represents the number of child nodes connected to the current node through the hybrid P2P multicast tree
  • the offset of the child node list may indicate the position of the first child node within the control message itself.
  • the configuring step may further include forming a payload in which tree information of each participating node is arranged in a preset order.
  • control message generation method further includes the step of a specific participating node receiving the control message including the payload among the plurality of participating nodes reconstructing the control message by removing information about the subtree. can do.
  • control message generation method is based on an estimated end-to-end delay between each node of the plurality of participating nodes and an orderer of the multi-cloud.
  • the method may further include determining whether at least one of the acquired effective bandwidth of the plurality of participating nodes and the number of supportable child nodes fluctuates beyond a preset reference range.
  • the configuring step may be performed when the determination result of the determining step is variable.
  • control message generation method may further include the step of repeatedly performing the classifying, selecting, and configuring steps to finally determine the number of clusters and the cluster leader.
  • the control message format according to another aspect of the present invention for solving the above technical problem is a control message format used in any one of the embodiments of the control message generation method described above, and includes a header and a payload.
  • the header contains information about the version, message type, and message length, and the payload sequentially contains tree information of a plurality of nodes according to predetermined sequential numbers. It is provided in the form listed.
  • the tree information of each of the plurality of nodes includes fields for a node IP (internet protocol), the number of child nodes, and an offset of child node lists. can do.
  • IP internet protocol
  • the tree information transmission method for solving the above technical problem is a tree information transmission method of a block transmission system for a multi-cloud scalable Hyperledger Fabric blockchain, and is performed in a verification node connected to the multi-cloud.
  • control message may be delivered to all participating nodes and used to update the message delivery table at each participating node.
  • the tree information transmission method includes repeatedly performing the clustering step, selecting the cluster leader, and constructing the overlapping multicast tree to finally determine the number of clusters and the cluster leader. It may further include.
  • the tree information delivery method further includes the step of a specific participating node receiving the control message including the payload among the plurality of participating nodes reconstructing the control message by removing information about some subtrees. It can be included.
  • the size of the control message may be reduced step by step at each parent node while being passed from the orderer to leaf nodes through the nested multicast tree.
  • control messages containing tree information are propagated through a hybrid P2P (peer to peer) multicast tree configured between nodes to control each cloud.
  • Tree information of nodes can be propagated with low overhead, thereby improving the scalability and transaction throughput of Hyperledger Fabric blockchain.
  • an effective bandwidth estimation method for block data transmission or a modeling method for the same can be provided in order to efficiently provide hybrid P2P multicast tree information to all participating nodes in a block transmission system.
  • Figure 1 is an exemplary diagram of a multi-cloud environment to which a block transmission system according to an embodiment of the present invention can be applied.
  • Figure 2 is a diagram for explaining the main components of a block transmission system according to an embodiment of the present invention.
  • FIG. 3 is a schematic block diagram of the detailed configuration of a network monitoring & management module that can be employed in the block transmission system of FIG. 2.
  • FIG. 4 is a schematic block diagram of the detailed configuration of a block transmission module that can be employed in the block transmission system of FIG. 2.
  • FIG. 5 is a flowchart of the overall operating procedure of the block transmission system of FIG. 2.
  • FIGS. 6 to 11 are diagrams for explaining a delay estimation process using a 0(n) control message that can be employed in the block transmission system of FIG. 2.
  • FIGS. 12 to 15 are diagrams for explaining an effective bandwidth estimation process for block transmission that can be employed in the block transmission system of FIG. 2.
  • FIG. 16 is an example diagram of a control message format for transmitting tree information that can be adopted in the block transmission system of FIG. 2.
  • Figures 17 and 18 are exemplary diagrams for explaining the tree structure identification process using the control message of Figure 16.
  • FIG. 19 is an example diagram of a multi-cloud network topology to which the block transmission system of FIG. 1 can be applied.
  • FIG. 20 is an exemplary diagram of the system architecture of a multi-cloud testbed that can be employed in the multi-cloud network of FIG. 19.
  • FIG. 21 is a graph showing performance verification results for the delay estimation process in the block transmission system of FIG. 2.
  • FIGS. 22A to 22C are graphs showing a comparison of measured and estimated delays from node #0 to all nodes in relation to the delay estimation process of FIG. 21.
  • Figures 23 and 24 are graphs showing performance verification results for clustering and hybrid P2P multicast tree constructing processes (CCP) in the block transmission system of Figure 2.
  • Figures 25 and 26 are graphs for comparison of delays between the average block arrival time and the maximum block arrival time when the uplink bandwidth is 200 Mbps in relation to the CCP of Figures 23 and 24.
  • Figure 27 is a schematic block diagram of the configuration of a block transmission system according to another embodiment of the present invention.
  • first, second, etc. may be used to describe various components, but the components should not be limited by the terms. The above terms are used only for the purpose of distinguishing one component from another.
  • a first component may be named a second component, and similarly, the second component may also be named a first component without departing from the scope of the present invention.
  • the term and/or includes any of a plurality of related stated items or a combination of a plurality of related stated items.
  • 'at least one of A and B' may mean 'at least one of A or B' or 'at least one of combinations of one or more of A and B'. Additionally, in the embodiments of the present application, 'one or more of A and B' may mean 'one or more of A or B' or 'one or more of combinations of one or more of A and B'.
  • Figure 1 is an exemplary diagram of a multi-clouds environment to which a block transmission system according to an embodiment of the present invention can be applied.
  • the multi-cloud environment is a gateway where the first cloud (Cloud A), the second cloud (Cloub B), the third cloud (Cloud C), and the fourth cloud (Cloud D) are connected to the Internet. It can have a structure connected to each other by (700).
  • Each cloud includes at least one participating node (500), and at least one of these clouds, such as the first cloud (Cloud A), has a validation node (100) and a block generation node (block). generating node).
  • the block generation node may be referred to as an orderer (300) and may also be referred to as a Hyperledger Fabric blockchain platform. Participating nodes 500 participating in multi-cloud may be placed in each cloud in a random pattern.
  • the block transmission system that can be employed in a multi-cloud environment quickly delivers block data used in blockchain services to all participating nodes to increase transactions per second (TPS) in multi-cloud. It is composed.
  • Figure 2 is a diagram for explaining the main components of a block transmission system according to an embodiment of the present invention.
  • the block transmission system may include a network monitoring & management module (110), a block generation module (310), and a block transmission module (510). there is.
  • the network monitoring management module 110 may be mounted on the verification node 100, the block generation module 310 may be mounted on the block generation node 300, and the block transmission module 510 may be mounted on the participating node 500. It can be mounted on . Additionally, the verification node 100 or the block generation node 300 may be equipped with a module equivalent or similar to the block transmission module 510.
  • the network monitoring management module 110, the block creation module 310, and the block transfer module 510 may communicate with each other through an application programming interface (API) coupled to each of them.
  • API application programming interface
  • the network monitoring management module 110 and the block transfer module 510 may exchange a first control message (control message #1) with each other.
  • the first control message may be a control message for tree construction.
  • the network monitoring management module 110 will be described in more detail as follows.
  • FIG. 3 is a schematic block diagram of the detailed configuration of a network monitoring & management module that can be employed in the block transmission system of FIG. 2.
  • the network monitoring management module 110 may include a blockchain interface 120, a network monitoring submodule 130, and a network topology configuration submodule 140.
  • the network monitoring management module 110 may be connected to the hardware of the node on which it is mounted or may be connected to an external computer or computer program through the API 150.
  • the blockchain interface 120 may include a means for exchanging data with nodes participating in the blockchain network or a component that performs functions corresponding to such means.
  • the network monitoring submodule 130 monitors the network with O(n) overhead.
  • O(n) is one of the big-O notations and represents the time complexity of the algorithm.
  • the scales for judging the complexity of an algorithm include time complexity and space complexity
  • O(n) is related to the number of operations within the algorithm or the number of transactions per second.
  • the network topology configuration submodule 140 performs network topology constructing of a hybrid P2P multicast tree structure.
  • FIG. 4 is a schematic block diagram of the detailed configuration of a block transmission module that can be employed in the block transmission system of FIG. 2.
  • the block transmission module 510 may include a block data transmitter 520, a block data receiver 530, and a message forwarding table (message forwarding table, 550).
  • the block data transmitter 520 and the block data receiver 530 may be formed as a block data transceiver 540.
  • the block transfer module 510 may be connected to the hardware of the node on which it is mounted or connected to an external computer or computer program through the API 560.
  • the block data transceiver 540 is configured to send and receive block data including messages in a control message format described later with participating nodes on a blockchain network or multi-network.
  • the message delivery table 550 may be set or updated to deliver a control message configured in the control message format according to this embodiment or a message including such a control message based on the multicast Cree structure described later.
  • FIG. 5 is a flowchart of the overall operating procedure of the block transmission system of FIG. 2.
  • the verification node 100 receives coordinate values from all participating nodes (paticipating nodes #1, #2, #3, #4) and receives the transaction speed ( transaction rate) (S50). Based on this information, the verification node 100 executes a clustering process and a hybrid P2P multicast tree constructing process (S51 to S59). Then, the verification node 100 transmits tree information to the orderer and all participating nodes through a control message.
  • the orderer updates the message delivery table based on the tree information and delivers the updated message delivery table to at least one specific participating node (S60).
  • the message forwarding table may be simply referred to as the forwarding table (FT).
  • the orderer may create a new block (NB) based on the tree information and transmit the generated blocks to at least one other participating node based on the tree information (S62).
  • Participating nodes may have a relationship between a parent node and a child node, and the parent node is a tree structure containing at least one child node at its position.
  • the forwarding table can be updated, and the updated message forwarding table can be forwarded to child nodes (S61a to S61d).
  • At least one parent node may receive a new block (NB) from the orderer and transmit the new block to its child nodes (S63a to S63d). That is, at least one participating node is in the form of a relay node and can function as both a parent node and a child node, and at least one other participating node can function only as a child node.
  • NB new block
  • CCP clustering and hybrid P2P multicast tree constructing processes
  • the verification node 100 configures and manages delay-based n-dimensional coordinates based on information received from the orderer and all participating nodes (S51).
  • the verification node 100 monitors the uplink bandwidth and transaction speed based on first information about the transaction speed received from the orderer and second information about coordinate values received from all participating nodes (S54).
  • the verification node 100 calculates the effective bandwidth and the number of supportable child nodes (S55).
  • the verification node 100 estimates the end-to-end delay between all participating nodes through management of delay-based n-dimensional coordinate values (S56).
  • a fluctuation event occurs in which at least one of the effective bandwidth and the number of supportable child nodes is outside the preset reference range or is outside the preset error range. Determine whether it was done (S57). If no change event occurs, the verification node 100 may return to the step of monitoring the uplink bandwidth and transaction speed in the decision step of the current process.
  • the verification node 100 performs clustering of all participating nodes into a plurality of clusters and selects a cluster leader for each cluster (S58).
  • the verification node 100 constructs an overlapping multicast tree based on a plurality of clusters (S59). And the verification node 100 transmits a control message containing tree information to the orderer. This control message can be delivered to all participating nodes and used to update the message delivery table at each participating node.
  • FIGS. 6 to 11 are diagrams for explaining a delay estimation process using a 0(n) control message that can be employed in the block transmission system of FIG. 2.
  • the two nodes described in this embodiment can be logically connected to each other in a P2P network. Therefore, when the number of all participating nodes for estimating the end-to-end delay value between all participating nodes is a predetermined number (n nd ), theoretically O(n 2 nd ) control message overhead will occur. This allows the weight or number of network transactions to increase by the number of all participating nodes. Accordingly, this embodiment provides an effective delay estimation process with O(n 2 nd ) message overhead.
  • each node is placed in three-dimensional coordinates based on the delay value, and the Euclidean distance between two nodes in the three-dimensional vector space is configured to represent the delay value.
  • each step may be performed by a verification node that works with the orderer, or by an intelligent block transfer system that couples to the verification node.
  • the intelligent block transfer system may include verification nodes.
  • the verification node exchanges control messages with the orderer and randomly selected anchor nodes of the hyperledger fabric, thereby constructing three-dimensional coordinates between the orderer and anchor nodes.
  • An anchor node may refer to a node connected to an orderer among participating nodes.
  • a new participating node can find its own coordinate values by sending request messages to orderer and anchor nodes, receiving corresponding reply messages containing their coordinate values, and simultaneously measuring the delay value.
  • a self-cross check algorithm can be performed to maintain the accuracy of the coordinates of participating nodes (step 7).
  • d i,j represents the round-trip time (RTT) measured between node #i and node #j
  • node #0 is Hyperledger Indicates the orderer of the hyperledger fabric. In fact, time-varying delays can cause coordinate uncertainty. To reduce this effect, an anchor node can be selected among participating nodes that are as far away from the orderer and other anchor nodes as possible.
  • the orderer's coordinates are fixed to (0,0,0).
  • the orderer may be referred to as an origin node or reference node in addition to Node #0.
  • the line connecting the orderer and the first anchor node is defined as the x-axis. That is, the coordinates of the first anchor node may be set to (x 1,0,0 ) as shown in FIG. 6.
  • x 1 may have the value of the first distance (d 0,1 ) corresponding to the distance from the origin (0,0.0).
  • the first anchor node may be referred to as Node #1 as well as the first node.
  • a second anchor node is selected from among participating nodes that are not located on the line connecting the orderer and the first anchor node.
  • the plane including the orderer's coordinates, the first anchor node's coordinates, and the second anchor node's coordinates can be configured as the xy plane.
  • the second anchor node may be referred to as Node #2 or a second node, and its coordinates may be expressed as (x 2 , y 2 , 0).
  • the second distance between node #2 and node #0 can be defined as d 0,2
  • the third distance between node #2 and node #1 can be defined as d 1,2 .
  • the verification node can obtain the following equations 1 and 2 based on the RTT value measured at the node and the coordinate values received from the orderer and the first anchor node.
  • Equation 3 and Equation 4 two coordinate values actually satisfy Equation 1 and Equation 2.
  • one of two coordinate values is selected in the fifth step below.
  • the third anchor node is selected from among participating nodes that are not located in the xy plane. Accordingly, a predetermined xyz space is composed of an orderer, a first anchor node, a second anchor node, and a third anchor node.
  • the third anchor node may be referred to as Node #3 or a third node, and its coordinates may be expressed as (x 3 , y 3 , z 3 ).
  • the fourth distance between node #3 and the reference node is defined as d 0,3
  • the fifth distance between node #3 and node #1 is defined as d 1,3
  • node #3 and node #2 are defined as d 1,3
  • the sixth distance from can be defined as d 2,3 .
  • Equations 5 to 7 (x 3 , y 3 , z 3 ) are coordinate values of the third anchor node. There may be two coordinate values of the third anchor node. One of these coordinate values can be finally selected in the fifth step.
  • the coordinates of any other participating node can be determined through the following equations 8 to 11. The existence of coordinate values can be guaranteed.
  • Equations 8 to 11 (x 4 , y 4 , z 4 ) may correspond to the coordinate values of each of the arbitrary participating nodes.
  • a three-dimensional coordinate system with the orderer as the origin can be created through the orderer and three anchor nodes, and the coordinates of any participating nodes can be calculated in the created three-dimensional coordinate system.
  • the coordinate values of participating nodes may change due to network conditions that change over time. In that case, it performs its own cross-checking algorithm to efficiently update the coordinate values.
  • the self-cross-checking algorithm is as shown in Figure 11, where the orderer sends a request message to a set of participating nodes that already identify their coordinate values, and the orderer participates based on the response message in the same way as in step 6. Approximate coordinate values of nodes can be calculated.
  • the block transmission system can be configured to update the coordinate system only when the size of the orderer's coordinate change is greater than the threshold.
  • the control message complexity is O(n nd ).
  • the number of child nodes that can be supported is closely coupled with the block generation policy, which determines the bursts of block traffic, and the effective bandwidth for delivering block traffic varies depending on the bursts.
  • block creation policy and the effective bandwidth estimating process for block traffic that is, block transmission, are described as follows.
  • a predetermined number of blocks ( ) transactions are assumed to be created as soon as they arrive at the orderer. Additionally, it is assumed that the time interval between two adjacent transactions is exponentially distributed as is commonly used.
  • block transfer time ( ) is the previous block transmission at a given success probability before the next block is generated to avoid block buffering delay in relay nodes as much as possible. ) may be decided to complete. i.e. block transfer time is obtained as in Equation 13 below.
  • weight which is a predetermined probability of success as shown in FIG. 12 ( ) can be fixed while taking into account. and represents the probability that the previous block has already been transmitted before the next block is created. As this increases, that is, When set to a smaller number, smaller block buffering times are probabilistically guaranteed at the expense of upload bandwidth usage, and vice versa.
  • the effective bandwidth can be estimated as shown in Equation 14 below.
  • Figure 13 shows When this is 84.13%
  • Figure 14 shows When this is 93.32%
  • Figure 15 When this is 97.72% , and Indicates the theoretical effective bandwidth on each side.
  • the time interval until transactions arrive can be so large that it can seriously degrade the quality of service (QoS) of the blockchain.
  • QoS quality of service
  • the buffering time of the oldest transaction is set to a threshold (see Figure 12), the number of transactions arriving is Even if it is smaller, it can be configured to generate blocks immediately.
  • Gaussian mixture model Gaussian mixture mdel, GMM
  • the participating nodes are grouped into several clusters based on the 3D coordinate values of the participating nodes obtained in advance, and a hybrid P2P multicast tree of the participating nodes can be constructed based on this.
  • a GMM-based clustering algorithm well known in the machine learning field is used, but it is not limited to this, and of course, other existing clustering algorithms that perform the same or similar functions as GMM-based clustering can be used.
  • GMM estimates the sample distribution using a finite set of Gaussian probability density functions.
  • GMM-based clustering algorithms are designed to maximize the probability density of data points. That is, each cluster is represented by a Gaussian probability density function and each point is inserted into the cluster with the maximum probability density.
  • EM expectation maximum
  • N is the number of data
  • K is the number of Gaussian components
  • D is the dimension of the data point.
  • GMM-based clustering algorithms can be implemented with reasonable complexity in block transfer systems because the coordinates of participating nodes are only three-dimensional.
  • a given node When clustering is completed, a given node can be selected as the cluster leader of each cluster by considering the delay obtained through the delay estimation process and the uplink bandwidth obtained through the effective bandwidth estimation process. In this way, the measurement of node #j in cluster #i (cluster #i) can be defined as in Equation 15 below.
  • Upload bandwidth is calculated by dividing by the effective bandwidth estimated in the effective bandwidth estimation process.
  • the node with the smallest measurement value can be selected as the cluster leader.
  • the optimal number of clusters and cluster leader can be determined by repeatedly performing the above clustering and cluster leader selection process with the hybrid P2P multicast tree construction process described later.
  • a modified Dijkstra algorithm for constructing a hybrid P2P multicast tree with minimum average delay assuming that all delay values between participating nodes, clusters, and the number of child nodes that can be supported by each node are provided.
  • MDA modified Dijkstra's algorithm
  • MDA can be adopted as a component of the block transmission system of this embodiment.
  • the number of clusters and the MDA-based hybrid P2P multicast tree can be repeatedly determined to minimize the average delay based on the delay information obtained through the delay estimation process.
  • the delay occurring in the cluster leader can be calculated using Equation 16 below.
  • the orderer and cluster leader (if directly received from the orderer) ) is the delay between is not received directly from the orderer (otherwise), the two cluster leaders ( and ) is the delay between
  • Equation 17 The delay experienced by any blockchain node through the multicast tree of this embodiment can be estimated by Equation 17 below.
  • Equation 18 the total delay sum of participating nodes through the multicast tree.
  • Equation 19 shows that the number of child nodes processed by the orderer is less than or equal to the number of child nodes supportable by the orderer, and the number of child nodes processed by the j-th node is less than or equal to the number of children supported by the j-th node.
  • the following conditions can be applied (subject to) for the number of nodes or less.
  • Participating nodes may include end systems.
  • the number of participating nodes can be expressed as Equation 20.
  • Equation 19 is the number of child nodes processed by the orderer, represents the number of child nodes processed by the j-th node, respectively, is the number of child nodes that can be supported by the orderer, represents the number of child nodes that can be supported by the j-th node, respectively.
  • Equation 19 the condition that the number of child nodes processed by the orderer and the j-th node is less than the maximum number of supportable child nodes is related to stress and degree constraint.
  • the link cost from the orderer to the specific node with the minimum weighted RTT is the distance from the orderer to the first node divided by the number of nodes participating in the v-th cluster ( ), otherwise set to infinity.
  • Equation 22 the link cost for all nodes that are adjacent to the second node (w) or any node (k) and are not part of the set (S) Update . This is expressed as Equation 22.
  • Control message overhead can be a significant burden on P2P backbone networks as the number of participating nodes increases. Accordingly, this embodiment includes an effective control message format and a delivery process using it as main features.
  • FIG. 16 is an example diagram of a control message format for transmitting tree information that can be adopted in the block transmission system of FIG. 2.
  • Figures 17 and 18 are examples for explaining the tree structure identification process using the control message of Figure 16.
  • the control message format 180 is designed hierarchically to reduce overhead when delivered through a hybrid P2P multicast tree. That is, the control message format 180 includes a header 181 and a payload, and the header 181 contains information about the version, message type, and message length, and the payload.
  • the load may have the form of sequentially arranging the tree information of a plurality of nodes according to predetermined sequential numbers (#0 to #n).
  • the header 181 and the tree information of each node are 32 bytes. It may have any length, but is not limited thereto.
  • Tree information of one node includes fields representing the node IP, the number of child nodes, and the offset of child node lists, respectively. It is provided (see 184, 185 and 186 in FIG. 18).
  • Node IP represents the IP (internet protocol) address of the current node
  • the number of child nodes represents the number of child nodes connected to the current node through a hybrid P2P multicast tree.
  • the offset of child node lists indicates the position of the first child node in the control message.
  • FIGS. 17 and 18 An example of application of the above-described control message format and its delivery processor is as follows. As illustrated in FIGS. 17 and 18, when nodes #0 to #13, respectively indicated by numbers 0 to 13, are directly or indirectly connected in the relationship of parent node and child node, a control message is sent from node #0 (170). Upon arriving at node #2 (172), node #2 (172) determines the number of child nodes through the child node number field 185 of the control message and the byte value of the offset field 186 of the child node list, such as From the position of the first child node indicated by byte 384, it can be seen that node #5 and node #6 are its child nodes.
  • node #2 172 can reconstruct the control message by removing unnecessary information about the subtree of the control message. Unnecessary information may refer to information about node #1 (171) and its lower nodes (#3, #4, #7 to #9). The reconstructed control message is delivered to the corresponding child nodes, that is, node #5 and node #6.
  • the size of the control message can obviously decrease as it moves through the hybrid P2P multicast tree. Moreover, as soon as a control message arrives at leaf nodes that have no children, the hybrid P2P multicast tree is fully visible among all participating nodes.
  • FIG. 19 is an example diagram of a multi-cloud network topology to which the block transmission system of FIG. 1 can be applied.
  • FIG. 20 is an exemplary diagram of the system architecture of a multi-cloud testbed that can be employed in the multi-cloud network of FIG. 19.
  • the block transmission system according to this embodiment can verify its performance in a realistic multi-cloud emulation environment as shown in FIGS. 19 and 20.
  • the multi-cloud network topology includes a plurality of clouds from cloud A to cloud G, a verification node 100 and an orderer included in a specific cloud, such as cloud A. (orderer, 300) and participating nodes (500) included in each cloud.
  • Each participating node may be assigned one of predetermined serial numbers (1 to 59), and the orderer 300 may be assigned a serial number of 0.
  • Clouds are connected to each other through at least one gateway, and nodes within each cloud can also be connected to each other through gateways.
  • the delay value can be set considering the RTT value observed over the Internet. Delay values were set to 3 ms, 5 ms, 6 ms, 10 ms, 12 ms, etc.
  • the testbed is Hyperledger Fabric, Docker (https://www.docker.com), Containernet (https://containernet.github.io), Mininet (http://mininet.org), C/ It can be implemented using open sources such as C++, Python, etc.
  • the system architecture 200 of the multi-cloud testbed can realistically emulate multi-cloud using Mininet and Containernet.
  • the system architecture of the multi-cloud Tatebed assumes that there are an orderer (300), a block generation node, one verification node, and 59 participating nodes.
  • the orderer is included in the participating nodes, the participating nodes can be referred to as 60.
  • the orderer (300) corresponding to node #0 or mounted on node #0 may include or be combined with Hyperledger Fabric (200), which is a modular architecture platform.
  • the orderer 300 is connected to node #1, node #6, and node #55. Node #1, node #6 and node #55 correspond to anchor nodes.
  • node #1 is connected to nodes #2 through node #5, node #7, node #9, and node #10 respectively, and node #9 and node #10 are common to node #8. connected, and node #7 is connected to node #13 and node #15, respectively. Additionally, node #6 is connected to node #11, and node #11 is connected to node #12.
  • the header size and transaction size of the block were set to 1000 bytes and 4000 bytes, respectively, and the number of transactions in one block ( ) were set to 10, 15, 20, and 25, respectively. Additionally, the effective bandwidth estimation process The value was fixed at 3 to ensure that the previous block transfer completes with a 97.72% probability. This was very conservative, resulting in data that was close to the lower limit of performance. That is, the maximum block transfer time Can be set as in Equation 23.
  • FIG. 21 is a graph showing performance verification results for the delay estimation process in the block transmission system of FIG. 2.
  • FIGS. 22A to 22C show the measured delay for each of all nodes based on node #0 and the estimated delay using the coordinate value of each node in relation to the delay estimation process of FIG. 21. These are graphs that compare coordinate values by node (Node ID).
  • the nodes are widely distributed in a three-dimensional space, which means that large delay estimation errors are inevitable when the nodes are expressed in a two-dimensional plane.
  • Figures 23 and 24 are graphs showing performance verification results for clustering and hybrid P2P multicast tree constructing processes (CCP) in the block transmission system of Figure 2.
  • the number of clusters can be changed from 2 to 10 and the delay estimation process described with reference to FIGS. 6 to 9 can be executed using coordinate values obtained during execution.
  • cluster leader selection is empirically fixed to 0.5, and transaction speed ( ) was set to 15 and 30, and the uplink bandwidth value of all participating nodes was set to the same 10 Mbps.
  • Transaction speed ( ) is 15, the effective bandwidth is 1,480 kbps and the number of child nodes that can be supported is 6.
  • Average delay and maximum delay according to the number of clusters For example, when changing the number of clusters from 2 to 10, the average delay (avg. delay) value and maximum delay ( max. delay) values are shown in Table 1.
  • transaction speed ( ) is 15 and the number of clusters is 6, the average delay value is minimized.
  • the resulting multicast tree is as shown in Figure 23. Additionally, the transaction speed ( ) is 30, the effective bandwidth and the number of corresponding child nodes are 2,960 kbps and 3, respectively, and it can be seen that the average delay is minimized when the number of clusters is 4.
  • Figures 25 and 26 are graphs for comparison of delays between the average block arrival time and the maximum block arrival time when the uplink bandwidth is 200 Mbps in relation to the CCP of Figures 23 and 24.
  • the block transmission system of this embodiment is compared with Gossip, Enhanced Gossip, and Unicast.
  • Gossip is one of the basic embedded transmission algorithms of the Hyperledger Fabric platform, and Enhanced Gossip maintains the time-to-live (TTL) value to effectively deliver blocks to neighboring nodes. It additionally includes a counter field for unicast, and unicast is configured so that the orderer individually sends blocks to all participating nodes.
  • TTL time-to-live
  • Gossip is implemented by randomly selecting a set of nodes and delivering blocks to them, so the maximum value of the block arrival time is the largest, as shown in Figure 26.
  • Enhanced Gossip slightly improves the performance of Gossip.
  • the orderer's access network bandwidth can cause a bottleneck.
  • the block transfer system of this embodiment can significantly improve blockchain scalability and transaction throughput.
  • Figure 27 is a schematic block diagram of the configuration of a block transmission system according to another embodiment of the present invention.
  • the block transmission system 1000 may be installed or coupled to at least one of a verification node, an orderer, or a participating node, and vice versa.
  • This block transfer system 1000 may include at least one processor 1100 and memory 1200. Additionally, the block transmission system 1000 may further include a transmitting and receiving device 1300 that is connected to a network and performs communication. Additionally, the block transfer system 1000 may further include an input interface device 1400, an output interface device 1500, a storage device 1600, etc. Each component included in the block transmission system 1000 is connected by a bus 1700 and can communicate with each other.
  • the processor 1100 may execute a program command stored in at least one of the memory 1200 and the storage device 1600.
  • the processor 1100 may refer to 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.
  • a program command is a command for configuring in software at least one component of a block transmission system that transmits a block having the control message format of this embodiment in a multi-task tree structure, and driving at least some components. It may include instructions for executing the functions of at least some components, etc.
  • program commands include commands for network monitoring and management, commands for block creation, commands for treeblock transmission based on multi-task tree information, commands for blockchain interface, commands for network monitoring, and n-dimensional Commands for constructing coordinates, commands for managing n-dimensional coordinates, commands for monitoring uplink bandwidth, commands for monitoring transaction rates, commands for calculating effective bandwidth, commands for calculating the number of supportable child nodes, participating nodes.
  • command to receive coordinate values from nodes command to receive transaction speed information, command to estimate end-to-end delay between all participating nodes, command for clustering of all participating nodes, command to select cluster leader, overlap
  • a command for configuring a multicast tree a command for configuring a network topology, a command for generating a control message according to the control message format of this embodiment, a command for passing tree information through a control message, a command for updating the message passing table, update It can include a command to pass the message passing table to the child node.
  • Each of the memory 1200 and the storage device 1600 may be comprised of at least one of a volatile storage medium and a non-volatile storage medium.
  • the memory 1200 may be comprised of at least one of read only memory (ROM) and random access memory (RAM).
  • the transmitting and receiving device 1300 can be used for a short-range wireless network or cable connection, communication with a satellite, wired or wireless communication with a general-purpose base station, an ideal backhaul link with a mobile edge core network or a core network, or a non-( non)-It may include a communication interface or sub-communication system for connection of an ideal backhaul link.
  • the input interface device 1400 includes at least one selected from input means such as a keyboard, microphone, touch pad, and touch screen, and an input signal processor that maps or processes a signal input through at least one input means with a pre-stored command. It can be included.
  • the output interface device 1500 includes an output signal processing unit that maps or processes a signal output under the control of the processor 1100 into a pre-stored signal form or level, and a signal in the form of vibration, light, etc. according to the signal of the output signal processing unit. It may include at least one output means for outputting information.
  • 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, and a vibration output device.
  • this embodiment can provide an intelligent block transfer system for a scalable Hyperledger Fabric blockchain on multi-cloud.
  • the intelligent block transmission system applies a three-dimensional coordinate system to estimate the delay between the orderer and all participating nodes with O(n) control message overhead, and performs clustering and cluster leader selection based on the calculated coordinate values of the nodes.
  • bandwidth estimation and hybrid P2P multicast tree construction processes and then distributing them to participating nodes on multi-cloud, the performance of the blockchain block transmission system can be improved and blocks can be quickly sent to all participating nodes.
  • Computer-readable media may include program instructions, data files, data structures, etc., singly or in combination.
  • Program instructions recorded on a computer-readable medium may be specially designed and constructed for the present invention or may be known and usable by those skilled in the computer software art.
  • 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 machine language code, such as that produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc.
  • the above-described hardware device may be configured to operate with at least one software module to perform the operations of the present invention, and vice versa.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

멀티 클라우드의 블록 전송 시스템과 블록 데이터 전송을 위한 유효 대역폭 추정 방법과 제어 메시지 생성 방법 및 트리 정보 전달 방법이 개시된다. 유효 대역폭 추정 방법은, 가우시안 모델을 따르는 블록의 생성 주기에서, 다음 블록의 생성 전에 기설정된 성공 확률로 이전 블록의 전송을 완료하기 위한 블록 전송 시간을 계산하는 단계, 및 블록에 포함되는 트랜잭션 개수와 트랜잭션 크기와 블록 헤더 크기 및 블록 전송 시간에 기초하여 유효 대역폭을 추정하는 단계를 포함한다.

Description

멀티 클라우드의 블록 데이터 전송을 위한 유효 대역폭 추정 방법과 제어 메시지 생성 방법 및 트리 정보 전달 방법과 이를 위한 블록 전송 시스템
본 발명은 멀티 클라우드의 확장가능한 하이퍼레저 패브릭 블록체인을 위한 블록 전송 시스템과 블록 전송 시스템에 적용할 수 있는 블록 데이터 전송을 위한 유효 대역폭 추정 방법, 제어 메시지 생성 방법 및 트리 정보 전달 방법에 관한 것이다.
분산 원장인 블록체인 시스템은 저장된 데이터를 변경하고 속이는 것을 불가능하게 하여 학계와 산업계에서 상당한 주목을 받고 있다. 가장 인기 있는 블록체인 애플리케이션 중 하나는 암호화폐이다. 최근 온라인 시장에서 블록체인 기반의 대체 불가능 토큰(non-fungible token, NFT)이 급부상하면서 가치(value)의 새로운 패러다임을 만들고 있다. 다양한 서비스의 블록체인 애플리케이션은 높은 수준의 확장성 요구 사항을 제기하고 있다. 잘 알려진 블록체인 트릴레마(trilemma)는 본질적으로 분산 환경에서 안전하고 확장 가능한 블록체인을 설계하는 것이 불가능하다는 것이다. 따라서 블록체인 시스템은 통상 이러한 속성 중 하나를 희생하여 목적에 따라 설계된다.
일반적으로 블록체인 시스템은 탈중앙화를 희생하는 허가형 블록체인과 확장성을 희생하는 무허가형 블록체인의 두 가지 유형으로 나누어진다. 허가된 블록체인에서는 허가된 피어들만 합의에 참여할 수 있는 반면, 허가 없는 블록체인에서는 누구나 합의에 참여할 수 있습니다.
하이퍼레저 패브릭(hyperledger fabric)은 가장 널리 사용되는 허가된 블록체인 플랫폼 중 하나이다. 하이퍼레저 패브릭은 높은 확장성을 달성하기 위해 다양한 노드에서 수행되는 일련의 실행, 주문 및 유효성 검사를 통해 사용자 트랜잭션을 확인한다. 하이퍼레저 패브릭의 성능을 더욱 향상시키기 위해 실행과 합의 절차를 분리하기 위한 많은 연구 노력이 이루어지고 있다.
예를 들어, 하이퍼레저 패브릭의 높은 처리량(throughtput)을 위해 실행 및 주문의 순차적 워크플로가 병렬로 수행되는 병렬 워크플로가 개발되었다. 또한, 하이러레저 패브릭이 유효하지 않은 트랜잭션을 최소화하면서 동시 트랜잭션 실행을 사용하는 효과적인 하이브리드 트랜잭션 실행 접근 방식이 도입되었다.
그러나 하이퍼레저 패브릭의 높은 수준의 확장성에도 불구하고 분산 원장의 무결성, 간단한 합의 메커니즘 및 단일 데이터 센터나 클라우드의 시스템 배포와 같이 하이퍼레저 패브릭 블록체인의 취약한 보안 및 분산화에 대한 본질적인 우려가 있다.
지금까지, 허가된 블록체인에서도 보안 및 탈중앙화 문제를 다루기 위한 연구가 진행되어 왔다. 예를 들어, 중앙 집중식 서비스 공급업체에 의존하는 시스템의 보안 위협을 완화하기 위해 신뢰할 수 있는 BaaS(blockchain-as-a-service)를 위한 시행자 아키텍처가 제안되었다. 또한, 스마트 계약이 보안 스토리지 감사를 위해 모델링된 온체인 개인정보보호 문제(on-chain privacy concerns)를 해결하기 위해 블록체인 지원 감사 프레임워크(blockchain-enabled auditing framework)가 도입되었다.
또한, 하이퍼레저 패브릭 워킹 그룹은 서로 다른 클라우드에 호스팅된 서비스 공급업체가 인프라와 독립적으로 비즈니스 네트워크를 구축하고 가입할 수 있도록 하는 상호 운용성 워크플로(interoperability workflow)를 지정하고 표준화하려고 시도하고 있다. 그러나 다중 클라우드를 통한 패브릭 블록체인 아키텍처는 네트워크 지연으로 인해 단일 클라우드 환경에 비해 트랜잭션 처리량이 현저히 낮을 수 있고, 결국 확장성 문제가 발생할 수 있다.
게다가, 효율적인 P2P(Peer-to-Peer) 네트워크 프로토콜이 합의와 검증 프로세스 사이의 대기 시간을 줄임으로써 높은 트랜잭션 처리량을 달성할 수 있다는 사실이 이미 알려져 있다. 실제로 P2P 네트워크는 블록체인의 백본 네트워크에서 역할을 하기 때문에 P2P 네트워크의 설계는 블록체인의 확장성을 향상시키는 중요한 요소이다. 패브릭 및 이더리움(Ethereum) 블록체인은 통상 가십(Gossip) P2P 및 devP2P와 같은 P2P 네트워크 모듈을 구현한다.
전통적으로 P2P 네트워크 프로토콜은 트리 기반 기술과 메시 기반 기술의 두 그룹으로 분류할 수 있다. 트리 기반 기술에서 피어(Peer)에는 상위 피어와 여러 하위 피어가 있다. 피어는 상위 피어로부터 데이터를 수신하고 수신된 데이터를 하위 피어에게 중계한다. 예를 들어, 기존의 트리 기반 기술은 통상 소스에서 대상으로 데이터를 푸시하여 지연을 최소화할 수 있으므로 짧은 지연을 가진다. 그러나 피어 이탈 또는 패킷 손실이 발생하면 모든 하위 노드들이 서비스 품질(quality of service, QoS) 저하를 경험한다. 이러한 트리 기반 기술의 단점을 극복하기 위해 메쉬 기반 기술이 제안되었다.
메쉬 기반 기술에서 피어는 다른 피어에 대한 다중 링크를 가지며 상위-하위 관계는 없다. 피어들을 서로 데이터를 주고받고, 전달 메커니즘으로서 풀(pull) 전달을 채택한다. 기존 메시 기반 기술의 일례로는 쿨스트리밍(CoolStreaming), 불릿(Bullet), 체인소(Chainsaw), P2P 네트워크를 통한 IPTV, 메시 풀 기반 P2P 스트리밍 등이 있다.
이와 같이 패브릭 블록체인의 성능을 개선하기 위한 다양한 연구 노력에도 불구하고 아직까지 멀티 클라우드(multi-clouds) 상에서 패브릭 블록체인의 트랜잭션 처리량을 개선하기 위한 방안은 미흡한 실정이다.
본 발명은 전술한 종래 기술의 요구에 부응하기 위해 도출된 것으로, 본 발명의 목적은 멀티 클라우드에 무작위로 위치한 모든 참여 노드에 가능한 한 빨리 블록을 전달하여 멀티 클라우드에서 하이퍼레저 패브릭 블록체인의 확장성과 트랜잭션 처리량을 높일 수 있는 지능형 블록 전송 시스템을 제공하는데 있다.
본 발명의 다른 목적은 멀티 클라우드의 확장가능한 하이퍼레저 패브릭 블록체인을 위한 블록 전송 시스템에 적용할 수 있는 블록 데이터 전송을 위한 유효 대역폭 추정 방법 및 장치를 제공하는데 있다.
본 발명의 또 다른 목적은 멀티 클라우드에 무작위로 위치한 모든 참여 노드들에 가능한한 블록을 빠르게 전달하여 멀티 클라우드에서 하이퍼레저 패브릭 블록체인의 확장성과 트랜잭션 처리량을 높일 수 있는 블록 데이터 전송을 위한 유효 대역폭 추정 방법 및 장치를 제공하는데 있다.
본 발명의 또 다른 목적은 멀티 클라우드의 확장가능한 하이퍼레저 패브릭 블록체인을 위한 블록 전송 시스템의 제어 메시지 생성 방법 및 이를 위한 제어 메시지 포맷을 제공하는데 있다.
본 발명의 또 다른 목적은 멀티 클라우드에 무작위로 위치한 모든 참여 노드들에 가능한한 블록을 빠르게 전달하여 멀티 클라우드에서 하이퍼레저 패브릭 블록체인의 확장성과 트랜잭션 처리량을 높일 수 있는 지능형 블록 전송 시스템의 트리 정보 전달 방법을 제공하는데 있다.
본 발명의 또 다른 목적은 전술한 지능형 블록 전송 시스템에 적용할 수 있는 제어 메시지 포맷을 이용하는 P2P(peer to peer) 네트워크 프로토콜을 제공하는데 있다.
상기 기술적 과제를 해결하기 위하여 본 발명에서는 단일 데이터 센터가 아닌 멀티 클라우드를 통해 패브릭 블록체인(fabric blockchain)의 트랜잭션 처리량을 개선하는 데 중점을 둔다. 즉, 본 발명의 블록 전송 시스템은 멀티 클라우드에서 패브릭 블록체인의 백본 네트워크 역할을 성공적으로 수행하기 위해 하이브리드 P2P(peer to peer) 멀티캐스트 트리 네트워크를 기반으로 P2P 시스템을 설계하고 패브릭의 P2P 네트워크 모듈과 통합하도록 구성된다.
한편, 클라우드 환경에서는 업로드 대역폭이 다운로드 대역폭보다 제한될 수 있다. 즉, 한 쌍의 노드는 P2P 네트워크를 통해 논리적으로 연결될 수 있지만 상대적으로 넓은 범위에서 지연이 변하고 네트워크 상황에 따라 연결이 깨지는 경우가 있다. 이는 효과적인 P2P 네트워크 구축에 큰 걸림돌이 된다. 이에 본 발명의 블록 전송 시스템의 블록 전송 프로세스에서는 주요 구성요소들로서 지연 추정 과정, 유효 대역폭 추정 과정, 노드 클러스터링 및 클러스터 리더 선정 과정, 하이브리드 P2P 멀티캐스트 트리 구축 과정을 포함한다.
특히, 본 발명은 멀티 클라우드의 확장 가능한 하이퍼레저 패브릭 블록체인을 위한 블록 전송 시스템에 적용할 수 있는 블록 데이터 전송을 위한 유효 대역폭 추정 방법 및 장치를 제공한다. 블록 데이터 전송을 위한 유효 대역폭(effective bandwidth) 추정은, 하이퍼레저 패브릭에서 효과적인 P2P 멀티캐스트 트리를 구성하기 위한 블록 전파에 필요한 유효 대역폭을 추정하는 것으로서, 트랜잭션이 기하급수적으로 분포하고 오더러에서 블록이 고정된 크기로 생성된다고 가정할 때, 블록이 생성되는 주기는 가우시안 모델을 따르고 다음 블록이 생성되기 전에 이전 블록의 전송을 일정 확률 이상에서 완료하기 위한 블록 전송 시간을 계산하고, 그 때의 유효 대역폭을 계산하도록 구성된다. 계산된 유효 대역폭은 블록에 포함된 트랜잭션 개수와 트랜잭션 발생 속도에 따라 증가할 수 있다.
상기 기술적 과제를 해결하기 위한 본 발명의 일 측면에 따른 멀티 클라우드에서의 블록 데이터 전송을 위한 유효 대역폭 추정 방법은, 멀티 클라우드에서의 블록 데이터 전송을 위한 유효 대역폭 추정 방법으로서, 가우시안 모델을 따르는 블록의 생성 주기에서, 다음 블록의 생성 전에 기설정된 성공 확률로 이전 블록의 전송을 완료하기 위한 블록 전송 시간을 계산하는 단계; 및 상기 블록에 포함되는 트랜잭션 개수와 트랜잭션 크기와 블록 헤더 크기 및 상기 블록 전송 시간에 기초하여 유효 대역폭을 추정하는 단계를 포함한다.
일실시예에서, 상기 계산하는 단계에서 상기 가우시안 모델을 따르는 블록의 생성 주기에서 상기 블록 데이터 전송을 위한 트랜잭션들은 기하급수적으로 분포하고, 상기 멀티 클라우드의 오더러(orderer)에서 블록이 고정된 크기로 생성되는 것으로 설정될 수 있다.
일실시예에서, 상기 방법은 미리 설정된 개수의 트랜잭션들이 오더러에 도착할 때 상기 블록을 생성하는 단계를 더 포함할 수 있다.
일실시예에서, 상기 계산하는 단계에서 상기 블록에 포함된 인접한 두 트랜잭션들 사이의 시간 간격은 기하급수적으로 분포하는 것으로 설정될 수 있다.
일실시예에서, 상기 방법은, 상기 블록에 포함된 트랜잭션 개수가 미리 설정된 기준값 이상으로 클 때, 상기 트랜잭션들이 도착할 때까지의 시간 간격을 상기 가우시안 모델로 정의되는 단계를 더 포함할 수 있다.
일실시예에서, 상기 가우시안 모델은 수학식 12와 같이 정의될 수 있다.
일실시예에서, 상기 블록 전송 시간은 수학식 13과 같이 정의될 수 있다.
일실시예에서, 상기 방법은 상기 블록 전송 시간이 더 작게 설정됨에 따라서 업로드 대역폭 사용을 희생하면서 더 작은 블록 버퍼링 시간을 확률적으로 보장하는 성공 확률을 설정하는 단계를 더 포함할 수 있다.
일실시예에서, 상기 유효 대역폭은 수학식 14와 같은 수식에 기초하여 추정될 수 있다.
[수학식 14]
Figure PCTKR2022015119-appb-img-000001
여기서,
Figure PCTKR2022015119-appb-img-000002
는 상기 트랜잭션 크기이고,
Figure PCTKR2022015119-appb-img-000003
는 상기 블록 헤더 크기이며,
Figure PCTKR2022015119-appb-img-000004
는 상기 트랜잭션들이 도착할 때까지의 시간 간격이다.
일실시예에서, 상기 트랜잭션 개수가 소정의 기준값보다 클 때, 상기 유효 대역폭은 상기 지수 분포 확률 모델의 트랜잭션 속도에 따라 선형적으로 증가한다.
일실시예에서, 상기 지수 분포 확률 모델의 트랜잭션 속도가 소정의 기준값보다 크면, 상기 유효 대역폭은 상기 트랜잭션 개수에 대해 기하급수적으로 감소한다.
일실시예에서, 상기 계산하는 단계에서 상기 성공 확률이 커질수록 상기 트랜잭션 개수의 기하급수적 감소율은 더 커지도록 설정될 수 있다.
일실시예에서, 상기 방법은, 상기 트랜잭션 개수가 미리 결정된 트랜잭션 개수보다 작더라도, 상기 트랜잭션들이 도착할 때까지의 시간 간격을 미리 설정된 크기보다 작게 유지하기 위하여 상기 트랜잭션들 중 가장 오래된 트랜잭션의 버퍼링 시간이 소정의 임계값보다 크면 그 즉시 블록을 생성하는 단계를 더 포함할 수 있다.
상기 기술적 과제를 해결하기 위한 본 발명의 일 측면에 따른 멀티 클라우드에서의 블록 데이터 전송을 위한 유효 대역폭 추정 장치는, 멀티 클라우드에서의 블록 데이터 전송을 위한 유효 대역폭 추정 장치로서, 프로세서; 및 상기 프로세서에 연결되고 상기 프로세서에 의해 실행되는 적어도 하나의 명령을 저장하는 메모리를 포함하고, 상기 적어도 하나의 명령은, 상기 프로세서에 의해, 가우시안 모델을 따르는 블록의 생성 주기에서, 다음 블록의 생성 전에 기설정된 성공 확률로 이전 블록의 전송을 완료하기 위한 블록 전송 시간을 계산하는 단계, 및 상기 블록에 포함되는 트랜잭션 개수와 트랜잭션 크기와 블록 헤더 크기 및 상기 블록 전송 시간에 기초하여 유효 대역폭을 추정하는 단계를 수행하도록 구성될 수 있다.
일실시예에서, 상기 적어도 하나의 명령은, 상기 프로세서에 의해, 상기 계산하는 단계에서 상기 가우시안 모델을 따르는 블록의 생성 주기에서 상기 블록 데이터 전송을 위한 트랜잭션들은 기하급수적으로 분포하고 상기 멀티 클라우드의 오더러(orderer)에서 블록을 고정된 크기로 생성하도록 처리할 수 있다.
일실시예에서, 상기 적어도 하나의 명령은, 상기 프로세서에 의해, 미리 설정된 개수의 트랜잭션들이 오더러에 도착할 때 상기 블록을 생성하는 단계를 더 수행하도록 할 수 있다.
일실시예에서, 상기 적어도 하나의 명령은, 상기 프로세서에 의해, 상기 블록에 포함된 인접한 두 트랜잭션들 사이의 시간 간격을 기하급수적으로 분포하는 것으로 처리할 수 있다.
일실시예에서, 상기 적어도 하나의 명령은, 상기 프로세서에 의해, 상기 블록에 포함된 트랜잭션 개수가 미리 설정된 기준값 이상으로 클 때, 트랜잭션들이 도착할 때까지의 시간 간격을 상기 가우시안 모델로 정의할 수 있다.
일실시예에서, 상기 적어도 하나의 명령은, 상기 프로세서에 의해, 상기 블록 전송 시간이 더 작게 설정됨에 따라서 업로드 대역폭 사용을 희생하면서 더 작은 블록 버퍼링 시간을 확률적으로 보장하도록 상기 성공 확률을 설정하는 단계를 더 수행하도록 구성될 수 있다.
일실시예에서, 상기 적어도 하나의 명령은, 상기 프로세서에 의해, 상기 블록에 포함된 트랜잭션들의 개수가 미리 결정된 트랜잭션 개수보다 작더라도, 상기 트랜잭션들이 도착할 때까지의 시간 간격을 미리 설정된 크기보다 작게 유지하기 위하여, 상기 트랜잭션들 중 가장 오래된 트랜잭션의 버퍼링 시간이 소정의 임계값보다 크면 그 즉시 블록을 생성하는 단계를 더 수행하도록 구성될 수 있다.
또한, 본 발명은 멀티 클라우드의 확장 가능한 하이퍼레저 패브릭 블록체인을 위한 블록 전송 시스템에 적용할 수 있는 제어 메시지 포맷과 이러한 제어 메시지 포맷을 이용하는 트리 정보 전달 프로세스를 제공한다. 본 발명의 제어 메시지 포맷은 제어 메시지 포맷을 생성하거나, 저장하거나, 전송하는 방법이나 장치에 대한 것으로, 이러한 방법 및 장치를 포함할 수 있다.
상기 기술적 과제를 해결하기 위한 본 발명의 또 다른 측면에 따른 제어 메시지 생성 방법은, 멀티 클라우드의 확장 가능한 하이퍼레저 패브릭 블록체인을 위한 블록 전송 시스템의 제어 메시지 생성 방법으로서, 복수의 참여 노드들을 복수의 클러스터들에 속한 노드들로 구분하는 단계; 상기 복수의 참여 노드들 중에서 상기 복수의 클러스터들 각각의 클러스터 리더를 선택하는 단계; 및 상기 복수의 클러스터들과 상기 클러스터 리더에 대한 정보에 기초하여 하이브리드 P2P(peer to peer) 멀티캐스트 트리(multicast tree)를 구성하는 단계를 포함한다.
일실시예에서, 상기 구성하는 단계는, 상기 하이브리드 P2P 멀티캐스트 트리에 포함되는 각 참여 노드의 트리 정보를 노드 IP(internet protocol) 필드, 자식 노드 수(the number of child nodes) 필드 및 자식 노드 목록의 오프셋(offset of child nodes lists) 필드의 조합으로 형성하는 단계를 포함할 수 있다.
일실시예에서, 상기 노드 IP 필드는 현재 노드의 IP 주소를 나타내고, 상기 자식 노드 수 필드는 상기 하이브리드 P2P 멀티캐스트 트리를 통해 상기 현재 노드에 연결된 자식 노드의 수를 나타내고, 상기 자식 노드 목록의 오프셋 필드는 제어 메시지 자체 내에서 첫 번째 자식 노드의 위치를 나타낼 수 있다.
일실시예에서, 상기 구성하는 단계는, 상기 각 참여 노드의 트리 정보를 미리 설정된 순서대로 일렬로 배열한 페이로드를 형성하는 단계를 더 포함할 수 있다.
일실시예에서, 상기 제어 메시지 생성 방법은, 상기 복수의 참여 노드들 중 상기 페이로드를 포함한 제어 메시지를 받은 특정 참여 노드가 하위 트리에 대한 정보를 제거하여 상기 제어 메시지를 재구성하는 단계를 더 포함할 수 있다.
일실시예에서, 상기 제어 메시지 생성 방법은, 상기 복수의 참여 노드들의 각 노드와 상기 멀티 클라우드의 오더러(orderer) 간에 추정된 엔드투엔드(end-to-end) 지연(delay)에 기초하여 획득되는 상기 복수의 참여 노드들의 유효 대역폭과 지원가능한 자식 노드들의 개수 중 적어도 어느 하나가 미리 설정된 기준 범위를 벗어난 변동이 있는지를 판단하는 단계를 더 포함할 수 있다. 여기서, 상기 구성하는 단계는 상기 판단하는 단계의 판단 결과가 변동 있음인 경우에 수행될 수 있다.
일실시예에서, 상기 제어 메시지 생성 방법은, 상기 구분하는 단계, 상기 선택하는 단계 및 상기 구성하는 단계를 반복적으로 수행하여 클러스터 개수와 클러스터 리더를 최종 결정하는 단계를 더 포함할 수 있다.
상기 기술적 과제를 해결하기 위한 본 발명의 다른 측면에 따른 제어 메시지 포맷은, 전술한 제어 메시지 생성 방법의 실시예들 중 어느 하나의 제어 메시지 생성 방법에 이용되는 제어 메시지 포맷으로서, 헤더 및 페이로드를 포함하고, 상기 헤더는 버전(version), 메시지 유형(message type) 및 메시지 길이(message length)에 대한 정보를 담고, 상기 페이로드는 소정의 순번들에 따라 복수의 노드들의 트리 정보를 각각 순차적으로 나열한 형태를 구비한다.
일실시예에서, 상기 복수의 노드들 각각의 트리 정보는 노드 IP(internet protocol), 자식 노드 수(the number of child nodes) 및 자식 노드 목록의 오프셋(offset of child nodes lists)에 대한 필드들을 구비할 수 있다.
상기 기술적 과제를 해결하기 위한 본 발명의 또 다른 측면에 따른 트리 정보 전달 방법은, 멀티 클라우드의 확장가능한 하이퍼레저 패브릭 블록체인을 위한 블록 전송 시스템의 트리 정보 전달 방법으로서, 멀티 클라우드에 연결된 검증 노드에서 모든 참여 노드들로부터 좌표 값들을 수신하는 단계; 오더러(orderer)로부터 트랜잭션 속도(transaction rate)를 수신하는 단계; 상기 모든 참여 노드들 중 상기 오더러에 연결되는 앵커 노드들의 업링크 대역폭을 추정하는 단계; 상기 모든 참여 노드들의 유효 대역폭과 지원가능한 자식 노드들의 개수를 계산하는 단계; 상기 모든 참여 노드들의 각 참여 노드와 상기 오더러 간의 엔드투엔드 지연을 추정하는 단계; 상기 엔드투엔드 지연에 기초하여 상기 유효 대역폭과 상기 지원가능한 자식 노드들의 개수가 미리 설정된 기준 범위를 벗어하는 변동이 있는지를 판단하는 단계; 상기 변동이 있는 경우, 상기 좌표 값들과 상기 트랜잭션 속도에 대한 정보에 기초하여 상기 모든 참여 노드들을 복수의 클러스터들로 클러스터링하는 단계; 상기 복수의 클러스터들 각각의 클러스터 리더를 선택하는 단계; 상기 복수의 클러스터와 상기 클러스터 리더를 토대로 중첩 멀티캐스트 트리를 구성하는 단계; 및 상기 중첩 멀티캐스트 트리를 제어 메시지에 담아 상기 오더러로 전송하는 단계를 포함한다.
일실시예에서, 상기 제어 메시지는 상기 모든 참여 노드들에 전달되어 각 참여 노드에서 메시지 전달 테이블의 업데이트에 이용될 수 있다.
일실시예에서, 상기 트리 정보 전달 방법은, 상기 클러스터링하는 단계, 상기 클러스터 리더를 선택하는 단계 및 상기 중첩 멀티캐스트 트리를 구성하는 단계를 반복적으로 수행하여 클러스터 개수와 클러스터 리더를 최종적으로 결정하는 단계를 더 포함할 수 있다.
일실시예에서, 상기 트리 정보 전달 방법은, 상기 복수의 참여 노드들 중 상기 페이로드를 포함한 제어 메시지를 받은 특정 참여 노드가 일부 하위 트리에 대한 정보를 제거하여 상기 제어 메시지를 재구성하는 단계를 더 포함할 수 있다.
일실시예에서, 상기 제어 메시지의 크기는 상기 중첩 멀티캐스트 트리를 통해 상기 오더러로부터 리프 노드들까지 전달되는 동안 각 부모 노드에서 단계적으로 감소될 수 있다.
전술한 멀티 클라우드 기반 확장 가능한 하이퍼레저 패브릭 블록체인을 위한 지능형 블록 전송 시스템을 사용하면, 노드들 간 구성된 하이브리드 P2P(peer to peer) 멀티캐스트 트리를 통해 트리 정보가 담긴 제어 메시지를 전파함으로써 각 클라우드의 노드들의 트리 정보를 적은 오버헤드로 전파할 수 있고, 그에 의해 하이퍼레저 패브릭 블록체인의 확장성과 트랜잭션 처리량을 향상시킬 수 있다.
또한, 본 발명에 의하면, 블록 전송 시스템에서 모든 참여 노드에 하이브리드 P2P 멀티캐스트 트리 정보를 효율적으로 제공하기 위해 블록 데이터 전송을 위한 유효 대역폭 추정 방안이나 이를 위한 모델링 방법을 제공할 수 있다.
또한, 본 발명에 의하면, 블록 전송 시스템에서 모든 참여 노드에 하이브리드 P2P 멀티캐스트 트리 정보를 효율적으로 제공하기 위한 제어 메시지 형식과 전달 프로세스를 제공할 수 있다.
도 1은 본 발명의 일실시예에 따른 블록 전송 시스템을 적용할 수 있는 멀티 클라우드 환경에 대한 예시도이다.
도 2는 본 발명의 일실시예에 따른 블록 전송 시스템의 주요 구성요소들을 설명하기 위한 도면이다.
도 3은 도 2의 블록 전송 시스템에 채용할 수 있는 네트워크 모니터링 관리 모듈(network monitoring & management module)의 상세 구성에 대한 개략적인 블록도이다.
도 4는 도 2의 블록 전송 시스템에 채용할 수 있는 블록 전송 모듈(block transmission module)의 상세 구성에 대한 개략적인 블록도이다.
도 5는 도 2의 블록 전송 시스템의 전체적인 작동 절차에 대한 흐름도이다.
도 6 내지 도 11은 도 2의 블록 전송 시스템에 채용할 수 있는 0(n) 제어 메시지를 이용한 지연 추정 프로세스를 설명하기 위한 도면들이다.
도 12 내지 도 15는 도 2의 블록 전송 시스템에 채용할 수 있는 블록 전송을 위한 유효 대역폭 추정 프로세스를 설명하기 위한 도면들이다.
도 16은 도 2의 블록 전송 시스템에 채용할 수 있는 트리 정보 전달을 위한 제어 메시지 포맷에 대한 예시도이다.
도 17 및 도 18은 도 16의 제어 메시지를 이용한 트리 구조 식별 과정을 설명하기 위한 예시도들이다.
도 19는 도 1의 블록 전송 시스템이 적용될 수 있는 멀티 클라우드의 네트워크 토폴로지에 대한 예시도이다.
도 20은 도 19의 멀티 클라우드 네트워크에 채용할 수 있는 멀티 클라우드 테스트베드의 시스템 아키텍처에 대한 예시도이다.
도 21은 도 2의 블록 전송 시스템에서의 지연 추정 프로세스에 대한 성능 검증 결과를 나타낸 그래프이다.
도 22a 내지 도 22c는 도 21의 지연 추정 프로세스와 관련하여 노드#0에서 모든 노드들까지 측정된 지연과 추정된 지연을 비교하여 나타낸 그래프들이다.
도 23 및 도 24는 도 2의 블록 전송 시스템에서의 클러스터링 및 하이브리드 P2P 멀티캐스트 트리 컨스트럭팅 프로세스(clustering & hybrid P2P multicast tree constructing processes, CCP)에 대한 성능 검증 결과를 나타낸 그래프들이다.
도 25 및 도 26은 도 23 및 도 24의 CCP와 관련하여 업링크 대역폭이 200Mbps일 때의 평균 블록 도착 시간과 최대 블록 도착 시간의 지연 비교를 위한 그래프들이다.
도 27은 본 발명의 다른 실시예에 따른 블록 전송 시스템의 구성에 대한 개략적인 블록도이다.
본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.
제1, 제2 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.
본 출원의 실시예들에서, 'A 및 B 중에서 적어도 하나'는 'A 또는 B 중에서 적어도 하나' 또는 'A 및 B 중 하나 이상의 조합들 중에서 적어도 하나'를 의미할 수 있다. 또한, 본 출원의 실시예들에서, 'A 및 B 중에서 하나 이상'은 'A 또는 B 중에서 하나 이상' 또는 'A 및 B 중 하나 이상의 조합들 중에서 하나 이상'을 의미할 수 있다.
어떤 구성요소가 다른 구성요소에 '연결되어' 있다거나 '접속되어' 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 '직접 연결되어' 있다거나 '직접 접속되어'있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.
본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, '포함한다' 또는 '가진다' 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가진 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.
이하, 첨부한 도면들을 참조하여, 본 발명의 바람직한 실시예를 보다 상세하게 설명하고자 한다. 본 발명을 설명함에 있어 전체적인 이해를 용이하게 하기 위하여 도면상의 동일한 구성요소에 대해서는 동일한 참조부호를 사용하고 동일한 구성요소에 대해서 중복된 설명은 생략한다.
도 1은 본 발명의 일실시예에 따른 블록 전송 시스템을 적용할 수 있는 멀티 클라우드(multi-clouds) 환경에 대한 예시도이다.
도 1을 참조하면, 멀티 클라우드 환경은 제1 클라우드(Cloud A), 제2 클라우드(Cloub B), 제3 클라우드(Cloud C) 및 제4 클라우드(Cloud D)가 인터넷(internet)에 연결된 게이트웨이들(700)에 의해 서로 연결된 구조를 구비할 수 있다. 각 클라우드는 적어도 하나 이상의 참여 노드(participating node, 500)을 포함하고, 이 클라우드들 중 적어도 어느 하나의 클라우드 예컨대 제1 클라우드(Cloud A)는 검증 노드(validation node, 100)와 블록 생성 노드(block generating node)를 포함할 수 있다. 블록 생성 노드는 오더러(orderer, 300)로 지칭될 수 있고, 하이퍼레저 패브릭 블록체인 플랫폼으로도 지칭될 수 있다. 멀티 클라우드에 참여하는 참여 노드들(500)은 랜덤한 패턴으로 각 클라우드에 배치될 수 있다.
본 실시예에서 멀티 클라우드 환경에 채용할 수 있는 블록 전송 시스템은 블록체인 서비스에 사용되는 블록 데이터를 빠르게 모든 참여 노드들에 전달하여 멀티 클라우드에서 초당 트랜잭션 수(transactions per second, TPS)를 높일 수 있도록 구성된다.
도 2는 본 발명의 일실시예에 따른 블록 전송 시스템의 주요 구성요소들을 설명하기 위한 도면이다.
도 2를 참조하면, 블록 전송 시스템은 네트워크 모니터링 관리 모듈(network monitoring & management module, 110), 블록 생성 모듈(block generation module, 310), 및 블록 전송 모듈(block transmission module, 510)을 구비할 수 있다.
네트워크 모니터링 관리 모듈(110)은 검증 노드(100)에 탑재될 수 있고, 블록 생성 모듈(310)은 블록 생성 노드(300)에 탑재될 수 있고, 블록 전송 모듈(510)은 참여 노드(500)에 탑재될 수 있다. 또한, 검증 노드(100)나 블록 생성 노드(300)에는 블록 전송 모듈(510)과 동등 혹은 유사한 모듈이 탑재될 수 있다.
네트워크 모니터링 관리 모듈(110)과 블록 생성 모듈(310)과 블록 전송 모듈(510)은 이들 각각에 결합된 응용 프로그래밍 인터페이스(application programming interface, API)를 통해 서로 통신할 수 있다.
네트워크 모니터링 관리 모듈(110)과 블록 전송 모듈(510)은 제1 제어 메시지(control message #1)을 서로 주고 받을 수 있다. 제1 제어 메시지는 트리 구성을 위한 제어 메시지일 수 있다. 네트워크 모니터링 관리 모듈(110)을 좀더 상세히 설명하면 다음과 같다.
도 3은 도 2의 블록 전송 시스템에 채용할 수 있는 네트워크 모니터링 관리 모듈(network monitoring & management module)의 상세 구성에 대한 개략적인 블록도이다.
도 3을 참조하면, 네트워크 모니터링 관리 모듈(110)은 블록체인 인터페이스(120), 네트워크 모니터링 서브모듈(130), 네트워크 토폴로지 구성 서브모듈(140)을 구비할 수 있다. 네트워크 모니터링 관리 모듈(110)은 API(150)를 통해 자신이 탑재된 노드의 하드웨어와 연결되거나 외부의 컴퓨터나 컴퓨터 프로그램과 연결될 수 있다.
블록체인 인터페이스(120)는 블록체인 네트워크에 참여하는 노드들과 데이터를 주고 받기 위한 수단이나 이러한 수단에 상응하는 기능을 수행하는 구성부를 포함할 수 있다.
네크워크 모니터링 서브모듈(130)은 O(n) 오버헤드로 네트워크를 모니터링한다. 여기서 O(n)은 빅오 표기법(big-O notation)의 하나로서 알고리즘의 시간 복잡도를 나타낸다. 즉, 알고리즘의 복잡도를 판단하는 척도로는 시간 복잡도와 공간 복잡도가 있는데, O(n)은 알고리즘 내 연산의 횟수나 초당 트랜잭션 수와 관계가 있다.
네트워크 토폴로지 구성 서브모듈(140)은 하이브리드 P2P 멀티캐스트 트리(hybrid P2P multicast tree) 구조의 네트워크 토폴로지 컨스트럭팅(network topology constructing)을 수행한다.
도 4는 도 2의 블록 전송 시스템에 채용할 수 있는 블록 전송 모듈(block transmission module)의 상세 구성에 대한 개략적인 블록도이다.
도 4를 참조하면, 블록 전송 모듈(510)은 블록 데이터 송신기(520), 블록 데이터 수신기(530) 및 메시지 전달 테이블(message forwarding table, 550)을 구비할 수 있다. 블록 데이터 송신기(520) 및 블록 데이터 수신기(530)은 블록 데이터 송수신기(540)로 형성될 수 있다. 블록 전송 모듈(510)은 API(560)를 통해 자신이 탑재된 노드의 하드웨어와 연결되거나 외부의 컴퓨터나 컴퓨터 프로그램과 연결될 수 있다.
블록 데이터 송수신기(540)는 후술하는 제어 메시지 포맷으로 구성된 메시지를 포함한 블록 데이터를 블록체인 네트워크 또는 멀티 네트워크 상의 참여 노드들과 주고 받도록 구성된다.
메시지 전달 테이블(550)은 본 실시예에 따른 제어 메시지 포맷으로 구성된 제어 메시지 또는 이러한 제어 메시지를 포함한 메시지를 후술하는 멀티캐스트 크리 구조에 기반하여 전달하기 위해 설정되거나 업데이트될 수 있다.
도 5는 도 2의 블록 전송 시스템의 전체적인 작동 절차에 대한 흐름도이다.
도 5를 참조하면, 블록 전송 시스템에서 검증 노드(100)는 모든 참여 노드들(paticipating nodes #1, #2, #3, #4)로부터 좌표 값들을 수신하고 오더러(orderer)로부터 트랜잭션 속도(transaction rate)를 수신한다(S50). 이러한 정보에 기초하여 검증 노드(100)는 클러스터링 프로세스(clustering process)와 하이브리드 P2P 멀티캐스트 트리 컨스트럭팅 프로세스(hybrid P2P multicast tree constructing process)를 실행한다(S51 내지 S59). 그리고, 검증 노드(100)는 오더러와 모든 참여 노드들에 제어 메시지(control message)를 통해 트리 정보(tree information)를 전달한다.
그런 다음, 오더러는 트리 정보를 토대로 메시지 전달 테이블을 업데이트하고 업데이트한 메시지 전달 테이블을 적어도 하나의 특정 참여 노드로 전달한다(S60). 메시지 전달 테이블(message forwarding table)은 간략히 전달 테이블(forwarding table, FT)로 지칭될 수 있다. 또한, 오더러는 트리 정보를 토대로 새로운 블록(new block, NB)을 생성하고 생성한 블록들(blocks)을 트리 정보에 기초하여 적어도 하나의 다른 참여 노드로 전송할 수 있다(S62).
참여 노드들(paticipating nodes #1, #2, #3, #4)은 부모 노드와 자식 노드의 관계를 가질 수 있고, 부모 노드는 자신의 위치에서 적어도 하나의 자식 노드를 포함하는 트리 구조로 메시지 전달 테이블을 업데이트하고, 업데이트된 메시지 전달 테이블을 자식 노드로 전달할 수 있다(S61a 내지 S61d).
또한, 적어도 하나의 부모 노드는 오더러로부터 새로운 블록(NB)을 받고, 그 자식 노드로 새로운 블록을 전달할 수 있다(S63a 내지 S63d). 즉, 적어도 하나의 참여 노드는 중계 노드 형태로서 부모 노드와 자식 노드 모두로 기능할 수 있고, 적어도 하나의 다른 참여 노드는 자식 노드로서만 기능할 수 있다.
전술한 클러스터링 및 하이브리드 P2P 멀티캐스트 트리 컨스트럭팅 프로세스(hybrid P2P multicast tree constructing processes, CCP)를 좀더 상세히 설명하면 다음과 같다.
먼저 검증 노드(100)는 오더러와 모든 참여노드들로부터 수신한 정보를 토대로 지연 기반 n-차원 좌표를 구성하고 관리한다(S51).
다음, 검증 노드(100)는 오더러로부터 받은 트랜잭션 속도에 대한 제1 정보와 모든 참여 노드들로부터 받은 좌표 값들에 대한 제2 정보에 기초하여 업링크 대역폭과 트랜잭션 속도를 모니터링한다(S54).
다음, 검증 노드(100)는 유효 대역폭과 지원가능한 자식 노드들의 개수를 계산한다(S55).
다음, 검증 노드(100)는 지연 기반 n-차원 좌표 값들의 관리를 통해 모든 참여 노드들 사이의 엔드 투 엔드(end-to-end) 지연을 추정한다(S56).
다음, 추정된 엔드 투 엔드(end-to-end) 지연에 기초하여, 유효 대역폭과 지원가능한 자식 노드들의 개수 중 적어도 하나 이상이 미리 설정된 기준 범위를 벗어나거나 미리 설정된 오차 범위를 벗어나는 변동 이벤트가 발생하였는지를 판단한다(S57). 변동 이벤트가 발생하지 않은 경우, 검증 노드(100)는 현재 프로세스의 판단 단계에서 업링크 대역폭과 트랜잭션 속도를 모니터링하는 단계로 되돌아갈 수 있다.
다음, 변동 이벤트가 발생한 경우, 검증 노드(100)는 모든 참여 노드들에 대해 복수의 클러스터들로 클러스터링을 수행하고 각 클러스터의 클러스터 리더를 선택한다(S58).
다음, 검증 노드(100)는 복수의 클러스터들을 토대로 중첩 멀티캐스트 트리를 구성한다(S59). 그리고 검증 노드(100)는 오더러에 트리 정보(tree information)를 담은 제어 메시지(control message)를 전달한다. 이러한 제어 메시지는 모든 참여 노드들에 전달되어 각 참여 노드에서 메시지 전달 테이블의 업데이트에 이용될 수 있다.
도 6 내지 도 11은 도 2의 블록 전송 시스템에 채용할 수 있는 0(n) 제어 메시지를 이용한 지연 추정 프로세스를 설명하기 위한 도면들이다.
본 실시예에서 설명되는 두 노드들은 P2P 네트워크에서 논리적으로 서로 연결될수 있다. 따라서 모든 참여 노드들 사이의 종단(end-to-end) 간 지연 값을 추정하기 위한 모든 참여 노드들의 개수가 소정 개수(nnd)일 때 이론적으로 O(n2 nd) 제어 메시지 오버헤드가 발생할 수 있고, 그에 의해 모든 참여 노드들의 개수만큼 네트워크 트랜잭션의 무게 혹은 개수가 증가하게 된다. 이에 본 실시예에서는 O(n2 nd) 메시지 오버헤드에서 효과적인 지연 추정 프로세스를 제공한다.
이를 위해, 본 실시예에서는 각 노드가 지연 값을 기준으로 3차원 좌표에 배치되고, 3차원 벡터 공간에서 두 노드들 사이의 유클리드 거리가 지연 값을 나타내도록 구성된다. 이를 구체적으로 예시하면 다음과 같다. 이하의 예시의 프로세스에서 각 단계는 오더러와 연동하는 검증 노드에 의해 수행되거나 또는 검증 노드에 결합하는 지능형 블록 전송 시스템에 의해 수행될 수 있다. 지능형 블록 전송 시스템은 검증 노드를 포함할 수 있다.
먼저, 검증 노드는 하이퍼레저 패브릭(hyperledger fabric)의 오더러(orderer) 및 무작위로 선택된 앵커 노드들(anchor nodes)과 제어 메시지들을 교환함으로써 오더러와 앵커 노드를 사이에 3차원 좌표들이 구성된다. 3차원 좌표들의 구성은 아래의 제1 단계 내지 제5 단계를 참조할 수 있다. 앵커 노드는 참여 노드들에서 오더러와 연결되는 노드를 지칭할 수 있다.
그런 다음, 새로운 참여 노드의 좌표 값을 찾을 수 있다(제6 단계). 즉, 새로운 참여 노드는 오더러 및 앵커 노드들로 요청 메시지들을 보내고 이들의 좌표 값을 포함한 대응 응답 메시지들(corresponding reply messages)를 받고 이와 동시에 지연 값을 측정함으로써 자신의 좌표 값을 찾을 수 있습니다.
마지막으로, 참여 노드들의 좌표들의 정확도를 유지하기 위해 자체 교차 검사 알고리즘(self-cross check algorithm)을 수행할 수 있다(제7 단계).
전술한 제어 메시지 교환에 따라 3차원 좌표들을 구성하는 과정을 나타내면 다음의 제1 단계 내지 제5 단계와 같다. 제1 단계 내지 제5 단계에서, di,j는 노드 #i와 노드 #j 사이에 측정된 왕복 시간(round-trip-time, RTT)을 나타내고, 노드 #0(Node #0)은 하이퍼레저 패브릭(hyperledger fabric)의 오더러(orderer)를 나타낸다. 사실, 시변 지연은 좌표의 불확실성을 유발할 수 있다. 이 효과를 줄이기 위해서 오더러와 다른 앵커 노드들과 최대한 멀리 떨어진 참여 노드들 중에서 앵커 노드를 선택할 수 있다.
제1 단계에서는 오더러의 좌표를 (0,0,0)으로 고정한다. 이하 오더러는 노드#0(Node #0) 외에 원점 노드 또는 기준 노드로 지칭될 수 있다.
제2 단계에서는 오더러와 제1 앵커 노드를 연결하는 라인을 x-축으로서 정의한다. 즉, 제1 앵커 노드의 좌표는 도 6에 도시한 바와 같이 (x1,0,0)으로 설정될 수 있다. 여기서, x1은 원점(0,0.0)과의 간격에 대응하는 제1 거리(d0,1)의 값을 가질 수 있다. 제1 앵커 노드는 노드#1(Node #1)뿐 아니라 제1 노드로도 지칭될 수 있다.
제3 단계에서는 도 7에 도시한 바와 같이 오더러와 제1 앵커 노드를 연결하는 라인 상에 위치하지 않는 참여 노드들 중에서 제2 앵커 노드를 선택한다. 이 경우, 오더러의 좌표와 제1 앵커 노드의 좌표와 제2 앵커 노드의 좌표를 포함하는 평면을 x-y 평면으로 구성할 수 있다. 제2 앵커 노드는 노드#2(Node #2) 또는 제2 노드로 지칭될 수 있고, 그 좌표는 (x2,y2,0)로 표현될 수 있다. 여기서, 노드#2와 노드#0과의 제2 거리를 d0,2로 정의하고, 노드#2와 노드#1과의 제3 거리를 d1,2로 정의할 수 있다.
검증 노드는 해당 노드에서 측정된 RTT 값과 오더러 및 제1 앵커 노드로부터 받은 좌표 값들을 기반으로 다음의 수학식 1 및 수학식 2를 얻을 수 있다.
Figure PCTKR2022015119-appb-img-000005
Figure PCTKR2022015119-appb-img-000006
수학식 1 및 수학식 2에서 (x2,y2)는 제2 앵커 노드의 좌표이다. 이에 의하면, 제2 앵커 노드의 좌표 값은 수학식 3 및 수학식 4에 의해 결정될 수 있다.
Figure PCTKR2022015119-appb-img-000007
Figure PCTKR2022015119-appb-img-000008
수학식 3과 수학식 4에서 알 수 있듯이, 실제로 두 개의 좌표 값들이 수학식 1과 수학식 2를 만족한다. 본 실시예에서는 하기의 제5 단계에서 두 개의 좌표 값들 중 하나를 선택하도록 구성된다.
제4 단계에서는 도 8에 도시한 바와 같이 x-y 평면에 위치하지 않는 참여 노드들 중에서 제3 앵커 노드(the third anchor node)를 선택한다. 따라서, 소정의 x-y-z 공간이 오더러, 제1 앵커 노드, 제2 앵커 노드 및 제3 앵커 노드로 구성된다. 제3 앵커 노드는 노드#3(Node #3) 또는 제3 노드로 지칭될 수 있고, 그 좌표는 (x3,y3,z3)로 표현될 수 있다. 여기서, 노드#3과 기준 노드와의 제4 거리를 d0,3으로 정의하고, 노드#3과 노드#1과의 제5 거리를 d1,3으로 정의하고, 노드#3과 노드#2와의 제6 거리를 d2,3으로 정의할 수 있다.
또한, 검증 노드는 도 8에서와 같이 오더러, 제1 앵커 노드, 제2 앵커 노드 및 제3 앵커 노드에 대해 RTT 값들을 측정하거나 측정된 값을 수신한 후, 제3 앵커 노드의 후보 좌표 값들을 수학식 5 내지 수학식 7을 이용하여 계산할 수 있다.
Figure PCTKR2022015119-appb-img-000009
Figure PCTKR2022015119-appb-img-000010
Figure PCTKR2022015119-appb-img-000011
수학식 5 내지 수학식 7에서, (x3,y3,z3)는 제3 앵커 노드의 좌표 값들이다. 제3 앵커 노드의 좌표 값들은 2개가 존재할 수 있다. 이들 좌표 값들 중 하나는 제5 단계에서 최종적으로 선택될 수 있다.
제5 단계에서는 도 9에 도시한 바와 같이 임의의 노드를 선택한다. 임의의 노드는 오더러 및 제1 내지 제3 앵커 노드들과 RTT 값들을 측정하기 위한 것이다. 임의의 노드는 노드#4(Node #4) 또는 제4 노드로 지칭될 수 있고, 그 좌표는 (x4,y4,z4)로 표현될 수 있다.
임의의 노드를 이용하면, 오더러를 기준으로 제1 앵커 노드, 제2 앵커 노드 및 제3 앵커 노드의 좌표들을 확정지은 상태에서 다음의 수학식 8 내지 수학식 11을 통해 임의의 다른 참여 노드의 좌표 값의 존재를 보장할 수 있다.
Figure PCTKR2022015119-appb-img-000012
Figure PCTKR2022015119-appb-img-000013
Figure PCTKR2022015119-appb-img-000014
Figure PCTKR2022015119-appb-img-000015
수학식 8 내지 수학식 11에서 (x4,y4,z4)는 임의의 참여 노드들 각각의 좌표 값들에 대응될 수 있다.
이와 같이, 오더러와 3개의 앵커 노드들을 통해 오더러를 원점으로 하는 3차원 좌표계를 생성하고, 생성된 3차원 좌표계에서 임의의 참여 노드의 좌표를 계산할 수 있다.
한편, 전술한 제6 단계를 좀더 구체적으로 설명하면, 제6 단계에서는 3차원 좌표계가 생성된 후에, 모든 참여 노드들 각각이 오더러, 앵커 노드들 및 임의의 참조 노드들로 요청 메시지를 보내도록 구성될 수 있다. 여기서 오더러의 좌표 값과, 앵커 노드들의 좌표 값들과 임의의 참조 노드들의 좌표 값들은 검증 노드나 오더러에서 식별가능하다. 즉, 위의 제5 단계와 유사하게, 도 10에 도시한 바와 같이, 임의의 참여 노드의 좌표를 구할 수 있다. 임의의 참여 노드는 노드#k(Node #k) 또는 제k 노드로 지칭될 수 있고, 그 좌표는 (xk,yk,zk)로 표현될 수 있다.
또 한편으로, 분산 환경에서는 좌표 값을 식별할 수 있는 참여 노드에 대한 정보를 얻기가 쉽지 않다. 즉, 위에서 설명한 제1 단계 내지 제5 단계의 프로세스에서 예컨대 역행렬이 행렬 형태로 존재하지 아니하는 미확인 케이스(case)가 발생할 수 있다. 이러한 문제 발생을 대비하기 위해, 본 실시예에서는 새로운 참여 노드가 앵커 노드들을 포함하고 충분한 개수로 임의로 선택되는 노드들과 접촉하도록 구성될 수 있다. 또한, 새로운 참여 노드를 충분한 개수의 임의로 선택되는 노드들과 접촉시키는 경우, 해당 노드의 좌표가 중복 결정되는 케이스가 유발될 수 있으므로, 이러한 문제 발생을 고려하여 본 실시예에서는 근사해를 구하여 그 오차를 최소화할 수 있다.
또한, 전술한 제7 단계를 좀더 구체적으로 설명하면 다음과 같다. 먼저 참여 노드의 좌표 값은 시간에 따라 변하는 네트워크 조건으로 인해 변경될 수 있다. 그 경우, 좌표 값을 효율적으로 업데이트하기 위해 자체 교차 검사 알고리즘을 수행한다.
자체 교차 검사 알고리즘은 도 11에 도시된 바와 같이 오더러가 이미 그들의 좌표 값을 식별하고 있는 참여 노드 세트에 요청 메시지를 전송하고, 오더러가 제6 단계에서와 같은 방법으로 응답 메시지를 기반으로 참여 노드들의 대략적인 좌표값들을 계산할 수 있다.
즉, 제1 노드(Node #1)의 좌표 (x1,y1,z1), 제2 노드(Node #2)의 좌표 (x2,y2,z2), 제3 노드(Node #3)의 좌표 (x3,y3,z3), 제4 노드(Node #4)의 좌표 (x4,y4,z4) 및 임의의 제N번째 노드(Node #N)의 좌표 (xN,yN,zN)를 구하고, 일정 시간 후에 좌표값을 식별하고 있는 각 노드와 오더러인 제0 노드(Node #0)의 좌표 (x0,y0,z0)와의 거리를 통해 오더러의 좌표를 다시 구할 수 있다.
그리고, 참여 노드들의 거리와 기설정 좌표 값들에 의해 얻어지는 오더러의 좌표가 0이 아닌(non-zero) 경우, 좌표계를 새롭게 업데이트한다. 특히, 좌표계의 업데이트에 따른 오버헤드를 줄이기 위해, 본 실시예에 따른 블록 전송 시스템은 오더러의 좌표 변동 크기가 임계값보다 큰 경우에만 좌표계를 업데이트하도록 구성될 수 있다. 결과적으로 제어 메시지 복잡도는 O(nnd)이다.
전술한 지연 추정 프로세스를 이용하는 지능한 블록 전송 시스템은, 블록 트래픽이 급증함에 따라 업로드 채널을 통해 블록 데이터를 전달하기 위해 더 많은 네트워크 리소스가 필요할 수 있다. 즉, 때때로 추가 지연이 발생할 수 있고, 그 경우 사용가능한 네트워크 리소스 양이 제한되어 블록체인 서비스 품질(QoS)이 저하될 수 있다. 실제로 업로드 대역폭은 위에서 언급한 클라우드 환경의 다운로드 대역폭보다 업로드 대역폭이 제한될 수 있고, 이러한 환경에서 각 부모 노드가 블록의 여러 복사본을 해당 자식 노드로 전송해야 하기 때문에 블록체인 서비스에서 병목 현상이 발생할 수 있다. 이에 본 실시예에서는 블록체인 QoS 및 확장성을 향상시킬 수 있는 능력을 고려하여 P2P 네트워크 상에서 피어 스트레스를 유지할 수 있도록 구성된다.
즉, 본 실시예의 지능형 블록 전송 시스템에서는 중복 블록 전송 횟수를 제어하여 전체 평균 지연을 최소화하고, 피어 스트레스를 처리하기 위해 P2P 멀티캐스트 기술을 채택한다. P2P 멀티캐스트 기술에서는 다음의 문제를 고려할 수 있다. 즉,주어진 업로드 대역폭으로 얼마나 많은 자식 노드를 지원할 수 있는지, 참여하는 노드를 어떻게 클러스터링할 것인지, 그리고 하이브리드 P2P 멀티캐스트 트리를 어떻게 구성할 것인지를 고려할 수 있다.
도 12 내지 도 15는 도 2의 블록 전송 시스템에 채용할 수 있는 블록 전송을 위한 유효 대역폭 추정 프로세스를 설명하기 위한 도면들이다.
P2P 멀티캐스트 기술에서, 먼저 지원 가능한 자식 노드의 수는 블록 트래픽의 버스트를 결정하는 블록 생성 정책과 밀접하게 결합되며 블록 트래픽을 전달하기 위한 유효 대역폭은 버스트(bursts)에 따라 달라진다.
먼저, 블록 생성 정책과 블록 트래픽에 대한 즉, 블록 전송(block transmission)을 위한 유효 대역폭 추정 프로세스(effective bandwidth estimating process)를 설명하면 다음과 같다.
유효 대역폭 추정 프로세스에서 블록은 소정 개수(
Figure PCTKR2022015119-appb-img-000016
)의 트랜잭션들이 오더러에 도착하자마자 생성된다고 가정한다. 또한, 인접한 두 트랜잭션들 사이의 시간 간격은 통상 사용되는 것과 같이 기하급수적으로 분포한다고 가정한다.
중심 극한 정리(central limit theorem, CLT)에 의하면,
Figure PCTKR2022015119-appb-img-000017
트랜잭션들이 도착할 때까지의 시간 간격은,
Figure PCTKR2022015119-appb-img-000018
이 소정의 기준값 이상으로 클 때, 즉 다음의 수학식 12와 같이 표현될 수 있을 때, 도 12와 같은 가우시안(Gaussian) 모델(G)로 나타낼 수 있다.
Figure PCTKR2022015119-appb-img-000019
여기서,
Figure PCTKR2022015119-appb-img-000020
는 지수 분포 확률 모델(exponentially distributed stochastic model)의 트랜잭션 속도이다.
위의 가정을 토대로 하면, 블록 전송 시간(
Figure PCTKR2022015119-appb-img-000021
)은 릴레이 노드들(relay nodes)에서 블록 버퍼링 지연(block buffering delay)을 가능한한 피하기 위해 다음 블록(the next block)이 생성되기 전에 주어진 성공 확률(given success probability)에서 이전 블록 전송(previous block transmission)을 완료하도록 결정될 수 있다. 즉, 블록 전송 시간
Figure PCTKR2022015119-appb-img-000022
는 다음의 수학식 13과 같이 구해진다.
Figure PCTKR2022015119-appb-img-000023
여기서,
Figure PCTKR2022015119-appb-img-000024
는 가중치로서 도 12에 도시한 바와 같이 미리 결정된 성공 확률(
Figure PCTKR2022015119-appb-img-000025
)을 고려하면서 고정될 수 있다. 그리고
Figure PCTKR2022015119-appb-img-000026
은 이전 블록이 다음 블록이 생성되기 전에 이미 전송되는 확률을 나타낸다.
Figure PCTKR2022015119-appb-img-000027
이 증가함에 따라 즉,
Figure PCTKR2022015119-appb-img-000028
이 더 작은 숫자로 설정될 때, 업로드 대역폭 사용을 희생하면서 더 작은 블록 버퍼링 시간이 확률적으로 보장되며, 그 반대의 경우도 마찬가지이다.
위에서 언급한 조건에 따라 유효 대역폭은 다음의 수학식 14와 같이 추정될 수 있다.
Figure PCTKR2022015119-appb-img-000029
여기서
Figure PCTKR2022015119-appb-img-000030
는 트랜잭션 크기이고,
Figure PCTKR2022015119-appb-img-000031
는 블록 헤더 크기이다. 이론적 유효 대역폭은
Figure PCTKR2022015119-appb-img-000032
,
Figure PCTKR2022015119-appb-img-000033
및
Figure PCTKR2022015119-appb-img-000034
의 측면에서 도 13 내지 도 15와 같이 예시될 수 있다.
도 13 내지 도 15를 참조하면,
Figure PCTKR2022015119-appb-img-000035
이 클 때, 유효 대역폭은
Figure PCTKR2022015119-appb-img-000036
에 따라 선형적으로 증가한다는 것이 명백하게 관찰된다. 반면에
Figure PCTKR2022015119-appb-img-000037
가 상대적으로 크면, 유효 대역폭은
Figure PCTKR2022015119-appb-img-000038
에 대해 거의 기하급수적으로 감소하고,
Figure PCTKR2022015119-appb-img-000039
이 커질수록 감소율은 더 민감해진다.
일례로, 도 13은
Figure PCTKR2022015119-appb-img-000040
이 84.13%일 때, 도 14는
Figure PCTKR2022015119-appb-img-000041
이 93.32%일 때, 그리고 도 15는
Figure PCTKR2022015119-appb-img-000042
이 97.72%일 때의
Figure PCTKR2022015119-appb-img-000043
,
Figure PCTKR2022015119-appb-img-000044
및
Figure PCTKR2022015119-appb-img-000045
측면에서의 이론적인 유효 대역폭을 각각 나타낸다.
Figure PCTKR2022015119-appb-img-000046
트랜잭션들이 도착할 때까지의 시간 간격은, 때때로 낮은 확률로, 너무 커서 블록체인의 서비스 품질(QoS)을 심각하게 저하시킬 수 있다. 이러한 원하지 않는 경우를 방지하기 위해, 가장 오래된 트랜잭션의 버퍼링 시간이 임계값
Figure PCTKR2022015119-appb-img-000047
(도 12 참조)보다 더 크면, 도달하는 트랜잭션들의 개수가
Figure PCTKR2022015119-appb-img-000048
보다 작더라도, 즉시 블록을 생성하도록 구성될 수 있다.
다음은 가우시안 혼합 모델(gaussian mixture mdel, GMM) 기반 노드 클러스터링(clustering) 및 클러스터 리더 선택 프로세스(cluster leader selecting process)를 설명하기로 한다.
클러스터링 프로세스에서는 미리 구해진 참여 노드들의 3D 좌표 값을 기반으로 여러 클러스터로 그룹화하고 이를 토대로 참여 노드들의 하이브리드 P2P 멀티캐스트 트리를 구성할 수 있다. 본 실시예에서는 기계학습 분야 등에 잘 알려져 있는 GMM 기반 클러스터링 알고리즘을 사용하나 이에 한정되지는 아니하며, GMM 기반 클러스터링과 동일하거나 유사한 기능을 수행하는 기존의 다른 클러스터링 알고리즘을 사용할 수 있음은 물론이다.
GMM은 유한한 집합의 가우시안 확률 밀도 함수를 사용하여 샘플 분포를 추정한다. 기본적으로 GMM 기반 클러스터링 알고리즘은 데이터 포인트의 확률 밀도를 최대화하도록 설계된다. 즉, 각 클러스터는 가우시안 확률 밀도 함수로 표현되고 각 포인트는 최대 확률 밀도로 클러스터에 삽입된다. 본 실시예의 블록 전송 시스템에서는 GMM 파라미터 추정에 널리 사용되는 기댓값 최대화(expectation maximum, EM) 알고리즘을 자체 구현하여 적용하였다. GMM에서 EM 알고리즘의 복잡성은
Figure PCTKR2022015119-appb-img-000049
이다.
여기서, N은 데이터의 개수이고, K는 가우시안 성분들의 개수이고, D는 데이터 포인트의 차원이다.
한편, GMM 기반 클러스터링 알고리즘은 참여 노드의 좌표가 3차원에 불과하기 때문에 블록 전송 시스템에서 합리적인 복잡성을 갖고 실행될 수 있다.
클러스터링이 완료되면, 지연 추정 프로세스를 통해 구한 지연 및 유효 대역폭 추정 프로세스를 통해 구한 업링크 대역폭을 고려하여 소정의 노드를 각 클러스터의 클러스터 리더로 선택할 수 있다. 이와 같이, 클러스터 #i(cluster #i)에서의 노드 #j(node #j)에 대한 측정은 다음의 수학식 15와 같이 정의될 수 있다.
Figure PCTKR2022015119-appb-img-000050
여기서
Figure PCTKR2022015119-appb-img-000051
는 실수,
Figure PCTKR2022015119-appb-img-000052
는 클러스터 #i의 노드 집합,
Figure PCTKR2022015119-appb-img-000053
는 지원 가능한 자식 노드의 수를 각각 나타낸다. 업로드 대역폭은 유효 대역폭 추정 프로세스에서 추정된 유효 대역폭으로 나누어 계산된다.
본 실시예의 블록 전송 시스템에서는 측정값이 가장 작은 노드를 클러스터 리더로 선택할 수 있다.
한편, GMM 기반 클러스터링 알고리즘은 최적의 클러스터 개수를 자동으로 제공하지 않는 것으로 잘 알려져 있다. 이에 본 실시예에서는 위의 클러스터링과 클러스터 리더 선택 과정을 후술하는 하이브리드 P2P 멀티캐스트 트리 구성 과정과 반복적으로 수행하여 최적의 클러스터 수와 클러스터 리더를 결정할 수 있다.
다음은 하이브리드 P2P 멀티캐스트 트리 구성(hybrid P2P multicast tree constructing) 프로세스를 설명하기로 한다.
본 프로세스에 대한 설명에 있어서, 참여 노드, 클러스터 간의 모든 지연 값과 각 노드에서 지원 가능한 자식 노드의 수가 제공된다는 가정 하에, 최소 평균 지연을 갖는 하이브리드 P2P 멀티캐스트 트리를 구성하기 위한 수정된 다익스트라 알고리즘(modified Dijkstra's algorithm, MDA)을 이용할 수 있다. MDA는 본 실시예의 블록 전송 시스템의 구성 요소로 채택될 수 있다. 블록 전송 시스템에서는 지연 추정 프로세스를 통해 얻은 지연 정보를 기반으로 평균 지연을 최소화하기 위해 클러스터 수와 MDA 기반 하이브리드 P2P 멀티캐스트 트리를 반복적으로 결정할 수 있다. 그리고 클러스터 리더에서 발생되는 지연은 다음의 수학식 16에 의해 계산될 수 있다.
Figure PCTKR2022015119-appb-img-000054
여기서,
Figure PCTKR2022015119-appb-img-000055
는 오더러로부터 직접 받은 경우(if directly received from the orderer)의 오더러와 클러스터 리더(
Figure PCTKR2022015119-appb-img-000056
) 간의 지연이고,
Figure PCTKR2022015119-appb-img-000057
는 오더러로부터 직접 받은 경우가 아닌(otherwise), 두 클러스터 리더들(
Figure PCTKR2022015119-appb-img-000058
및
Figure PCTKR2022015119-appb-img-000059
) 간의 지연이다.
본 실시예의 멀티캐스트 트리를 통해 임의의 블록체인 노드가 경험하는 지연은 다음의 수학식 17에 의해 추정될 수 있다.
Figure PCTKR2022015119-appb-img-000060
여기서,
Figure PCTKR2022015119-appb-img-000061
는 i-번째 클러스터의 j-번째 노드와 i-번째 클러스터 내 클러스터 리더(
Figure PCTKR2022015119-appb-img-000062
) 간의 지연이다.
전술한 추정 결과에 의하면, 멀티캐스트 트리를 통해 참여 노드들의 전체 지연 합은 다음의 수학식 18과 같이 표현될 수 있다.
Figure PCTKR2022015119-appb-img-000063
여기서
Figure PCTKR2022015119-appb-img-000064
는 클러스터의 수이고,
Figure PCTKR2022015119-appb-img-000065
는 i-번째 클러스터에 참여하는 노드의 개수이다. 따라서 평균 지연은 수학식 19로 표현될 수 있다. 수학식 19는 오더러에 의해 처리되는 자식 노드들의 개수가 오더러에 의해 지원가능한 자식 노드들의 개수 이하이고, j-번째 노드에 의해 처리되는 자식 노드들의 개수가 j-번째 노드에 의해 지원가능한 자식 노드들의 개수 이하에 대하여 하기 조건으로(subject to) 적용될 수 있다.
Figure PCTKR2022015119-appb-img-000066
여기서,
Figure PCTKR2022015119-appb-img-000067
은 멀티캐스트에 참여하는 참여 노드들의 개수이다. 참여 노드는 엔드 시스템(end system)을 포함할 수 있다. 참여 노드들의 개수는 수학식 20으로 표현될 수 있다.
Figure PCTKR2022015119-appb-img-000068
또한, 수학식 19에서,
Figure PCTKR2022015119-appb-img-000069
는 오더러에 의해 처리되는 자식 노드들의 개수를,
Figure PCTKR2022015119-appb-img-000070
는 j-번째 노드에 의해 처리되는 자식 노드들의 개수를 각각 나타내고,
Figure PCTKR2022015119-appb-img-000071
는 오더러에 의해 지원가능한 자식 노드들의 개수를,
Figure PCTKR2022015119-appb-img-000072
는 j-번째 노드에 의해 지원가능한 자식 노드들의 개수를 각각 나타낸다.
그리고 수학식 19에서, 오더러와 j-번째 노드의 처리되는 자식 노드들의 개수가 지원가능한 자식 노드들의 최대 개수 이하인 조건은 스트레스(stress) 및 정도 제한(degree constraint)과 관련이 있습니다. 위에서 언급한 바와 같이, 수정된 다익스트라 알고리즘은 위에서 언급한 문제에 대한 효과적인 솔루션을 제공할 수 있음을 보여준다.
이와 같이 수정된 다익스트라 알고리즘을 구현하여 평균 지연을 최소화하는 하이브리드 P2P 멀티캐스트 트리를 구성할 수 있다.
수정된 다익스트라 알고리즘을 이용하여 평균 지연을 최소화하는 하이브리드 P2P 멀티캐스트 트리를 구성하는 간략히 예시하면 다음과 같다.
먼저, 오더러(O)를 공집합(S)에 추가한다. 그리고 모든 참여 노드들 중 v-번째 클러스터에 속한 제1 노드(v)에 대하여, 특정한 제1 노드가 오더러에 인접하게 위치할 때, 오더러로부터 최소 가중 RTT를 갖는 특정 노드까지의 링크 비용
Figure PCTKR2022015119-appb-img-000073
를, 오더러로부터 제1 노드까지의 거리를 v-번째 클러스터에 참여하는 노드들의 개수로 나눈 값(
Figure PCTKR2022015119-appb-img-000074
)으로 설정하고, 그렇지 않으면 무한대(infinity)로 설정한다.
다음, 오더러로부터 해당 노드까지의 링크 비용이 가장 작은 조건을 만족하고, 집합(S)에 속하지 않는 제2 노드(w)를 찾는다.
Figure PCTKR2022015119-appb-img-000075
임의의 클러스터에 속한 임의의 노드(k)에 대하여 상기의 수학식 21을 만족하는 제2 노드(w)가 존재하는 경우, 제1 노드(v)가 새로운 자식 노드들을 지원할 수 있으면, 제2 노드(w)를 집합(S)에 추가한다. 한편, 제1 노드(v)가 새로운 자식 노드들을 지원할 수 없으면, 제2 노드까지의 링크 비용
Figure PCTKR2022015119-appb-img-000076
를 상대적으로 큰 수 또는 무한대로 대체한 후, 또 다른 제2 노드를 찾는 단계로 되돌아간다.
그리고, 임의의 노드(k)에 대하여 상기의 수학식 21을 만족하는 제2 노드(w)가 존재하지 않는 경우, 하기의 수학식 22를 만족하는 임의의 노드(k)를 집합(S)에 추가하고, 제1 노드(v)가 새로운 자식 노드들을 지원할 수 있을 때, 제2 노드(w) 또는 임의의 노드(k)에 인접하고 집합(S)에 속하지 않은 모든 노드에 대해 링크 비용
Figure PCTKR2022015119-appb-img-000077
를 업데이트한다. 이를 나타내면 수학식 22와 같다.
Figure PCTKR2022015119-appb-img-000078
마지막으로, 모든 노드들이 집합(S) 내에 있으면, 현재의 프로세스를 종료하고, 그렇지 않으면, 또 다른 제2 노드를 찾는 단계로 되돌아간다.
다음은 트리 정보에 대한 제어 메시지 포맷 및 전달 프로세스를 설명하기로 한다.
제어 메시지 오버헤드는 참여 노드의 수가 증가함에 따라 P2P 백본 네트워크에 큰 부담이 될 수 있다. 이에 본 실시예에서는 효과적인 제어 메시지 포맷과 이를 이용한 전달 프로세스를 주요 특징으로 포함한다.
도 16은 도 2의 블록 전송 시스템에 채용할 수 있는 트리 정보 전달을 위한 제어 메시지 포맷에 대한 예시도이다. 그리고 도 17 및 도 18은 도 16의 제어 메시지를 이용한 트리 구조 식별 과정을 설명하기 위한 예시도들이다.
도 16을 참조하면, 제어 메시지 포맷(180)은 하이브리드 P2P 멀티캐스트 트리를 통해 전달될 때 오버헤드를 줄이기 위해 계층적으로 설계된다. 즉, 제어 메시지 포맷(180)은 헤더(181)와 페이로드를 포함하고, 헤더(181)는 버전(version), 메시지 유형(message type), 메시지 길이(message length)에 대한 정보를 담고, 페이로드는 소정의 순번들(#0 내지 #n)에 따라 복수의 노드들의 트리 정보를 각각 순차적으로 나열한 형태를 구비할 수 있다.헤더(181)와 각 노드의 트리 정보는 32 바이트(byte)의 길이를 가질 수 있으나, 이에 한정되지는 않는다.
하나의 노드의 트리 정보(도 18의 183 참조)는 노드 IP(Node IP), 자식 노드 수(the number of child nodes) 및 자식 노드 목록의 오프셋(offset of child node lists)을 각각 표현하는 필드들을 구비한다(도 18의 184, 185 및 186 참조).
여기서 노드 IP(Node IP)는 현재 노드의 IP(internet protocol) 주소를 나타내고, 자식 노드 수(the number of child nodes)는 하이브리드 P2P 멀티캐스트 트리를 통해 현재 노드에 연결된 자식 노드의 수를 나타내며, 자식 노드 목록의 오프셋(offset of child node lists)은 제어 메시지에서 첫 번째 자식 노드의 위치를 나타낸다.
전술한 제어 메시지 포맷의 적용과 그 전달 프로세서를 예시하면 다음과 같다. 도 17 및 도 18에 예시한 바와 같이, 0 내지 13으로 각각 표시된 노드 #0 내지 노드 #13이 부모 노드와 자식 노드의 관계로 직간접으로 연결되어 있을 때, 제어 메시지가 노드 #0(170)로부터 노드 #2(172)에 도착하면, 노드 #2(172)는 제어 메시지의 자식 노드 수 필드(185)를 통해 자식 노드의 수를 파악하고, 자식 노드 목록의 오프셋 필드(186)의 바이트 값 예컨대 384 바이트가 가리키는 첫번째 자식 노드의 위치로부터 노드 #5 및 노드 #6가 자신의 자식 노드들임을 알 수 있다.
또한, 노드 #2(172)는 제어 메시지의 하위 트리에 대한 불필요한 정보를 제거하여 제어 메시지를 재구성할 수 있다. 불필요한 정보는 노드 #1(171)과 그 하위 노드들(#3, #4, #7 내지 #9)에 대한 정보를 지칭할 수 있다. 재구성된 제어 메시지는 해당 자식 노드들 즉, 노드 #5와 노드 #6으로 전달된다.
이와 같이 제어 메시지의 크기는 하이브리드 P2P 멀티캐스트 트리를 통해 이동함에 따라 명백하게 줄어들 수 있다. 더욱이, 제어 메시지가 자식 노드가 없는 리프 노드들에 도착하는 즉시 모든 참여 노드들 사이에 하이브리드 P2P 멀티캐스트 트리를 완전히 파악할 수 있게 된다.
도 19는 도 1의 블록 전송 시스템이 적용될 수 있는 멀티 클라우드의 네트워크 토폴로지에 대한 예시도이다. 도 20은 도 19의 멀티 클라우드 네트워크에 채용할 수 있는 멀티 클라우드 테스트베드의 시스템 아키텍처에 대한 예시도이다.
본 실시예에 따른 블록 전송 시스템은 도 19 및 도 20과 같이 현실적인 멀티 클라우드 에뮬레이션 환경에서 그 성능을 검증할 수 있다.
멀티 클라우드 네트워크 토폴로지는, 도 19에 도시한 바와 같이, 클라우드 A(cloud A) 내지 클라우드 G(cloud G)의 복수의 클라우드들과, 특정 클라우드 예컨대 클라우드 A에 포함된 검증노드(100) 및 오더러(orderer, 300)와, 각 클라우드에 포함된 참여 노드들(500)을 포함한다. 각 참여 노드에는 소정의 일련 번호(1 내지 59) 중 하나가 부여될 수 있고, 오더러(300)에는 일련 번호 0이 부여될 수 있다. 클라우드들을 서로 적어도 하나 이상의 게이트웨이를 통해 서로 연결되고, 각 클라우드 내부의 노드들도 게이트웨이를 통해 서로 연결될 수 있다.
멀티 클라우드의 네트워크 토폴로지에서, 지연 값은 인터넷을 통해 관찰된 RTT 값을 고려하여 설정될 수 있다. 지연 값은 3㎳, 5㎳, 6㎳, 10㎳, 12㎳ 등으로 설정되었다.
테스트베드는 하이퍼레저 패브릭(hyperledger fabric), Docker(https://www.docker.com), Containernet(https://containernet.github.io), Mininet(http://mininet.org), C/C++, 파이썬(Python) 등과 같은 오픈 소스를 사용하여 구현될 수 있다. 멀티 클라우드 테스트베드의 시스템 아키텍처(200)는 도 20에 나타낸 바와 같이, 미니넷(Mininet)과 컨테이너넷(Containernet)을 사용하여 멀티 클라우드를 현실적으로 에뮬레이트할 수 있다.
멀티 클라우드 테이트베드의 시스템 아키텍처는 블록 생성 노드인 오더러(orderer, 300), 1개의 검증 노드, 그리고 59개의 참여 노드들이 있다고 가정하였다. 오더러를 참여 노드에 포함시키는 경우, 참여 노드들은 60개로 지칭될 수 있다.
멀티 클라우드 테이트베드의 시스템 아키텍처에서 노드 #0에 대응하거나 노드 #0에 탑재되는 오더러(orderer, 300)는 모듈형 아키텍처 플랫폼인 하이퍼레저 패브릭(200)를 포함하거나 이와 결합될 수 있다. 오더러(300)는 노드 #1(node #1), 노드 #6(node #6), 노드 #55(node #55)에 연결된다. 노드 #1, 노드 #6 및 노드 #55는 앵커 노드들에 대응된다.
예를 들어, 노드 #1(node #1)은 노드 #2 내지 노드 #5, 노드 #7, 노드 #9 및 노드 #10에 각각 연결되고, 노드 #9 및 노드 #10은 노드 #8에 공통 연결되고, 노드 #7은 노드 #13, 내지 노드 #15에 각각 연결된다. 또한 노드 #6(node #6)은 노드 #11(node #11)에 연결되고, 노드 #11은 노드 #12(node #12)에 연결된다.
실험 시, 블록의 헤더 크기와 트랜잭션 크기는 각각 1000 바이트와 4000 바이트로 설정하고, 하나의 블록의 트랜잭션 개수(
Figure PCTKR2022015119-appb-img-000079
)는 10, 15, 20, 25로 각각 설정하였다. 또한, 유효 대역폭 추정 프로세스의
Figure PCTKR2022015119-appb-img-000080
값은 97.72%의 확률로 이전 블록 전송을 완료하기 위해 3로 고정되었다. 이는 매우 보수적이어서 결과 데이터가 성능의 하한에 가깝게 나타났다. 즉, 최대 블록 전송 시간
Figure PCTKR2022015119-appb-img-000081
을 수학식 23과 같이 설정할 수 있다.
Figure PCTKR2022015119-appb-img-000082
도 21은 도 2의 블록 전송 시스템에서의 지연 추정 프로세스에 대한 성능 검증 결과를 나타낸 그래프이다. 도 22a 내지 도 22c는 도 21의 지연 추정 프로세스와 관련하여 노드 #0을 기준으로 모든 노드들 각각에 대해 측정한 지연(measured delay)과 각 노드의 좌표 값을 이용하여 추정된 지연(estimated delay using coordinate values)을 노드별(Node ID)로 비교하여 나타낸 그래프들이다.
본 실험 결과에서는 블록 전송 시스템의 지연 추정 프로세스의 성능을 보여준다. 본 실험은 도 19를 참조하여 앞서 설명한 것과 같은 네트워크 토폴로지를 통해 실행되었다. 모든 참여 노드들 중 노드 #1, 노드 #2, 노드 #3이 연이어 앵커 노드로 선택되고 3차원(3D) 공간에서 결과적인 노드 위치들이 원형 점 형태로 도 21에 도시되어 있다.
도 21을 참조하면, 노드들이 3차원 공간에 넓게 분포되어 있음을 분명히 알 수 있으며, 이는 노드들이 2차원 평면에서 표현될 경우 큰 지연 추정 오차가 불가피함을 의미한다.
지연 추정 프로세스의 성능은 도 22a 내지 도 22c에 요약되어 있다. 한 쌍의 노드들 사이의 지연 값을 모두 측정하고 앞서 언급한 좌표 값들 간의 유클리드 거리(Euclidean distance)를 계산하여 해당 지연 값을 추정하였다. 성능 검증 결과, 평균 오류(average error)는 약 0.82ms이므로 추정 오류가 허용가능함을 알 수 있다.
도 23 및 도 24는 도 2의 블록 전송 시스템에서의 클러스터링 및 하이브리드 P2P 멀티캐스트 트리 컨스트럭팅 프로세스(clustering & hybrid P2P multicast tree constructing processes, CCP)에 대한 성능 검증 결과를 나타낸 그래프들이다.
본 성능 검증 과정에서는 클러스터의 수를 2에서 10으로 변경하여 도 6 내지 도 9를 참조하여 설명한 지연 추정 프로세스를 실행 과정에서 얻어지는 좌표 값들로 본 프로세스를 실행할 수 있다.
성능 검증 과정 중 클러스터 리더 선택은 경험적으로 0.5로 고정하고, 트랜잭션 속도(
Figure PCTKR2022015119-appb-img-000083
)는 15와 30으로 설정하고, 모든 참여 노드의 상향링크 대역폭 값은 10Mbps로 동일하게 설정하였다. 트랜잭션 속도(
Figure PCTKR2022015119-appb-img-000084
)가 15일 때 유효 대역폭은 1,480kbps이고 지원 가능한 자식 노드의 수는 6이다.
클러스터의 개수에 따른 평균 지연과 최대 지연(average delay and maximum delay according to the number of clusters) 예컨대, 클러스터의 개수를 2개에서 10개로 변경했을 때의 평균 지연(avg. delay) 값과 최대 지연(max. delay) 값을 나타내면 표 1과 같다.
λ= 15 λ= 30
클러스터수 Avg. delay
(ms)		 Max. delay
(ms)		 Avg. delay
(ms)		 Max. delay
(ms)
2 15.55 29.80 22.59 31.05
3 15.63 29.80 17.42 31.05
4 15.64 29.80 16.02 31.05
5 15.55 28.85 17.07 28.85
6 15.54 28.84 17.00 28.84
7 15.66 28.84 19.10 28.84
8 15.89 29.64 41.16 62.85
9 16.38 33.30 16.78 31.02
10 16.49 33.30 28.62 56.55
표 1에 나타낸 바와 같이, 트랜잭션 속도(
Figure PCTKR2022015119-appb-img-000085
)가 15일 때 그리고 클러스터 개수가 6개일 때 평균 지연값이 최소화됨을 알 수 있다. 그 결과 멀티캐스트 트리는 도 23에 도시한 바와 같다.또한, 트랜잭션 속도(
Figure PCTKR2022015119-appb-img-000086
)가 30일 때 유효 대역폭과 해당 자식 노드의 수는 각각 2,960kbps와 3이며, 클러스터 수가 4일 때 평균 지연이 최소화되는 것을 확인할 수 있다.
한편, 본 실시예의 블록 전송 시스템은 평균 지연만을 최소화하도록 설계되어 있기 때문에 최대 지연은 도 24에 나타낸 바와 같이 때때로 약간 증가할 수 있다. 도 23 및 도 24의 두 트리들의 차이가 가시적으로 확연히 드러나는 것을 알 수 있다.
도 25 및 도 26은 도 23 및 도 24의 CCP와 관련하여 업링크 대역폭이 200Mbps일 때의 평균 블록 도착 시간과 최대 블록 도착 시간의 지연 비교를 위한 그래프들이다.
본 성능 검증에서는 본 실시예(proposed)의 블록 전송 시스템을 가십(Gossip), 확장형 가십(Enhanced Gossip), 유니캐스트(Unicast)와 비교한다. 가십(Gossip)은 하이퍼레저 패브릭(hyperledger fabric) 플랫폼의 기본 임베디드 전송 알고리즘 중 하나이며, 확장형 가십(Enhanced Gossip)은 블록을 이웃 노드로 효과적으로 전달하기 위해 TTL(time-to-live) 값을 유지하기 위한 카운터 필드를 추가로 포함하며, 유니캐스트(Unicast)는 오더러가 모든 참여 노드들에 개별적으로 블록을 보내도록 구성된다.
본 성능 검증에서는 25초 동안 실험을 수행하고 12초에 트랜잭션 속도(
Figure PCTKR2022015119-appb-img-000087
)를 15에서 30으로 변경한다. 실험 중 업링크 대역폭 값은 50Mbps, 100Mbps 및 200Mbps로 설정된다. 그리고 블록의 트랜잭션 개수(
Figure PCTKR2022015119-appb-img-000088
)는 10, 15, 20, 25로 각각 설정하였다. 전체 실험 결과는 도 25 및 도 26과 및 표 2에 요약되어 있다.
업링크
대역폭
(Mbps)		 알고리즘 평균 블록 도착 시간(ms) 최대 블록 도착 시간(ms)
Figure PCTKR2022015119-appb-img-000089

= 10
Figure PCTKR2022015119-appb-img-000090

= 15
Figure PCTKR2022015119-appb-img-000091

= 20
Figure PCTKR2022015119-appb-img-000092

= 25
Figure PCTKR2022015119-appb-img-000093

= 10
Figure PCTKR2022015119-appb-img-000094

= 15
Figure PCTKR2022015119-appb-img-000095

= 20
Figure PCTKR2022015119-appb-img-000096

= 25
50 Gossip 2 8 4 3 651 478 466 632
Enhanced Gossip 156 142 180 183 775 796 896 855
50 Unicast 226 363 931 1,386 509 916 2,617 5,335
Proposed 55 76 117 141 119 129 197 250
100 Gossip 107 117 132 143 1,455 1,475 1,503 1,691
Enhanced Gossip 110 139 136 149 725 785 807 1,005
Unicast 127 185 249 316 252 377 576 823
Proposed 45 58 71 86 84 107 132 192
200 Gossip 101 103 121 128 1,464 1,462 1,504 1,576
Enhanced Gossip 86 99 119 125 714 735 800 929
Unicast 81 113 148 181 163 228 296 374
Proposed 31 40 52 61 68 91 128 157
표 2에 나타낸 바와 같이, 가십(Gossip)은 노드들의 집합을 무작위로 선택하여 그들에게 블록을 전달하는 방식으로 구현되기 때문에 도 26과 같이 블록 도달 시간의 최대값이 가장 크다. 확장형 가십(Enhanced Gossip)은 가십의 성능을 약간 향상시키고 있다. 그리고 유니캐스트(Unicast)의 경우 오더러의 액세스 네트워크 대역폭이 병목 현상을 유발할 수 있다.
도 25 및 도 26과 표 2에서 블록 도달 시간의 평균값과 최대값은 오더러의 액세스 네트워크 대역폭의 제한으로 인해 크게 증가함을 명백히 알 수 있다. 특히, 이러한 값은 트랜잭션 속도(
Figure PCTKR2022015119-appb-img-000097
)가 증가함에 따라 급격히 증가한다. 즉, 업링크 대역폭이 50Mbps이고 블록의 트랜잭션 개수(
Figure PCTKR2022015119-appb-img-000098
)가 20일 때 평균 및 최대 블록 도달 시간은,
Figure PCTKR2022015119-appb-img-000099
=15(0~12s)의 경우에 477ms 및 894ms에서 변경되었고,
Figure PCTKR2022015119-appb-img-000100
=30(12~12초)의 경우에 1,144ms 및 2,617ms로 변경되었다. 반면에, 본 실시예(Proposed)의 블록 전송 시스템은 비교예들의 다른 어떤 알고리즘보다 블록 도달 시간의 평균값과 최대값을 훨씬 더 작게 지원할 수 있음을 분명히 알 수 있다. 위와 같은 결과의 이유는 본 실시예의 시스템이 추정된 지연 값을 기반으로 트래픽 부하를 여러 참여 노드에 체계적으로 할당할 수 있기 때문이다.
한편, 본 실시예의 경우
Figure PCTKR2022015119-appb-img-000101
에 따라 유효 대역폭이 감소함에도 불구하고 블록 도달 시간의 평균과 최대값은 약간 증가함을 알 수 있다. 실제로, 이러한 현상은
Figure PCTKR2022015119-appb-img-000102
에 따라 블록 크기가 증가하기 때문에 릴레이 노드들에서 누적된 전송 지연에 의해 발생할 수 있다.
전술한 성능 검증 결과에 의하면, 본 실시예의 블록 전송 시스템은 블록체인 확장성과 트랜잭션 처리량을 눈에 띄게 향상시킬 수 있음을 알 수 있다.
도 27은 본 발명의 다른 실시예에 따른 블록 전송 시스템의 구성에 대한 개략적인 블록도이다.
도 27을 참조하면, 블록 전송 시스템(1000)은 검증 노드, 오더러 또는 참여 노드 중 적어도 어느 하나의 노드에 설치되거나 결합될 수 있으며, 그 역도 가능하다. 이러한 블록 전송 시스템(1000)은 적어도 하나의 프로세서(1100) 및 메모리(1200)를 포함할 수 있다. 또한, 블록 전송 시스템(1000)은 네트워크와 연결되어 통신을 수행하는 송수신 장치(1300)를 더 포함할 수 있다. 또한, 블록 전송 시스템(1000)은 입력 인터페이스 장치(1400), 출력 인터페이스 장치(1500), 저장 장치(1600) 등을 더 포함할 수 있다. 블록 전송 시스템(1000)에 포함된 각각의 구성 요소들은 버스(bus, 1700)에 의해 연결되어 서로 통신을 수행할 수 있다.
프로세서(1100)는 메모리(1200) 및 저장 장치(1600) 중에서 적어도 하나에 저장된 프로그램 명령(program command)을 실행할 수 있다. 프로세서(1100)는 중앙 처리 장치(central processing unit, CPU), 그래픽 처리 장치(graphics processing unit, GPU), 또는 본 발명의 실시예들에 따른 방법들이 수행되는 전용의 프로세서를 의미할 수 있다.
프로그램 명령(program command)은 본 실시예의 제어 메시지 포맷을 갖는 블록을 멀터태스크 트리 구조로 전송하는 블록 전송 시스템의 적어도 하나의 구성요소를 소프트웨어적으로 구성하기 위한 명령, 적어도 일부의 구성요소를 구동하기 위한 명령, 적어도 일부의 구성요소의 기능을 실행하기 위한 명령 등을 포함할 수 있다.
일례로, 프로그램 명령은, 네트워크 모니터링 및 관리를 위한 명령, 블록 생성을 위한 명령, 멀티태스크 트리 정보에 기초한 트리블록 전송을 위한 명령, 블록체인 인터페이스를 위한 명령, 네트워크 모니터링을 위한 명령, n-차원 좌표를 구성하는 명령, n-차원 좌표를 관리하는 명령, 업링크 대역폭을 모니터링하는 명령, 트랜잭션 속도를 모니터링하는 명령, 유효 대역폭을 계산하는 명령, 지원가능한 자식 노드들의 수를 계산하는 명령, 참여 노드들로부터 좌표 값을 수신하는 명령, 트랜잭션 속도 정보를 수신하는 명령, 모든 참여 노드들 사이의 엔드 투 엔드 지연을 추정하는 명령, 모든 참여 노드들의 클러스터링을 위한 명령, 클러스터 리더를 선택하기 위한 명령, 중첩 멀티캐스트 트리를 구성하는 명령, 네트워크 토폴로지 구성을 위한 명령, 본 실시예의 제어 메시지 포맷에 따라 제어 메시지를 생성하는 명령, 제어 메시지를 통해 트리 정보를 전달하는 명령, 메시지 전달 테이블을 업데이트하는 명령, 업데이트된 메시지 전달 테이블을 자식 노드로 전달하는 명령을 포함할 수 있다.
메모리(1200) 및 저장 장치(1600) 각각은 휘발성 저장 매체 및 비휘발성 저장 매체 중에서 적어도 하나로 구성될 수 있다. 예를 들어, 메모리(1200)는 읽기 전용 메모리(read only memory, ROM) 및 랜덤 액세스 메모리(random access memory, RAM) 중에서 적어도 하나로 구성될 수 있다.
송수신 장치(1300)는 근거리 무선 네트워크나 케이블 연결, 위성과의 통신, 범용 기지국과의 유선 또는 무선 통신, 모바일 에지 코아 네트워크나 코아 네트워크(core network)와의 아이디얼 백홀 링크(ideal backhaul link) 또는 넌(non)-아이디얼 백홀 링크의 연결 등을 위한 통신인터페이스나 서브통신시스템을 포함할 수 있다.
입력 인터페이스 장치(1400)는 키보드, 마이크, 터치패드, 터치스크린 등의 입력 수단들에서 선택되는 적어도 하나와 적어도 하나의 입력 수단을 통해 입력되는 신호를 기저장된 명령과 매핑하거나 처리하는 입력 신호 처리부를 포함할 수 있다.
출력 인터페이스 장치(1500)는 프로세서(1100)의 제어에 따라 출력되는 신호를 기저장된 신호 형태나 레벨로 매핑하거나 처리하는 출력 신호 처리부와, 출력 신호 처리부의 신호에 따라 진동, 빛 등의 형태로 신호나 정보를 출력하는 적어도 하나의 출력 수단을 포함할 수 있다. 적어도 하나의 출력 수단은 스피커, 디스플레이 장치, 프린터, 광 출력 장치, 진동 출력 장치 등의 출력 수단들에서 선택되는 적어도 하나를 포함할 수 있다.
이와 같이 본 실시예에서는 멀티 클라우드 상에서 확장 가능한 하이퍼레저 패브릭(hyperledger fabric) 블록체인을 위한 지능형 블록 전송 시스템을 제공할 수 있다. 지능형 블록 전송 시스템은 3차원 좌표계를 적용하여 O(n) 제어 메시지 오버헤드로 오더러와 모든 참여 노드들 간의 지연 값을 추정하고, 계산된 노드의 좌표 값을 기반으로 클러스터링 및 클러스터 리더 선정, 유효 대역폭 추정, 하이브리드 P2P 멀티캐스트 트리 구성 과정을 수행한 다음, 멀티 클라우드 상의 참여 노드들로 배포함으로써, 블록체인 블록 전송 시스템의 성능을 향상시켜 모든 참여 노드들에 블록을 빠르게 보낼 수 있다.
전술한 본 실시예에 따른 방법들은 다양한 컴퓨터 수단을 통해 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 컴퓨터 판독 가능 매체에 기록되는 프로그램 명령은 본 발명을 위해 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다.
컴퓨터 판독 가능 매체의 예에는 롬(rom), 램(ram), 플래시 메모리(flash memory) 등과 같이 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러(compiler)에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터(interpreter) 등을 사용해서 컴퓨터에 의해 실행될 수 있는 고급 언어 코드를 포함한다. 상술한 하드웨어 장치는 본 발명의 동작을 수행하기 위해 적어도 하나의 소프트웨어 모듈로 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
이상 실시예를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.

Claims (35)

  1. 멀티 클라우드에서의 블록 데이터 전송을 위한 유효 대역폭 추정 방법으로서,
    가우시안 모델을 따르는 블록의 생성 주기에서, 다음 블록의 생성 전에 기설정된 성공 확률로 이전 블록의 전송을 완료하기 위한 블록 전송 시간을 계산하는 단계; 및
    상기 블록에 포함되는 트랜잭션 개수와 트랜잭션 크기와 블록 헤더 크기 및 상기 블록 전송 시간에 기초하여 유효 대역폭을 추정하는 단계;
    를 포함하는 블록 데이터 전송을 위한 유효 대역폭 추정 방법.
  2. 청구항 1에 있어서,
    상기 가우시안 모델을 따르는 블록의 생성 주기에서 상기 블록 데이터 전송을 위한 트랜잭션들이 기하급수적으로 분포하고, 상기 멀티 클라우드의 오더러(orderer)에서 블록이 고정된 크기로 생성되는, 블록 데이터 전송을 위한 유효 대역폭 추정 방법.
  3. 청구항 2에 있어서,
    상기 블록은 미리 설정된 개수의 트랜잭션들이 오더러에 도착할 때 생성되는, 블록 데이터 전송을 위한 유효 대역폭 추정 방법.
  4. 청구항 3에 있어서,
    상기 블록에 포함된 인접한 두 트랜잭션들 사이의 시간 간격은 기하급수적으로 분포하는 것으로 설정되는, 블록 데이터 전송을 위한 유효 대역폭 추정 방법.
  5. 청구항 4에 있어서,
    상기 블록에 포함된 트랜잭션 개수가 미리 설정된 기준값 이상으로 클 때, 상기 트랜잭션들이 도착할 때까지의 시간 간격은 상기 가우시안 모델로 정의되는, 블록 데이터 전송을 위한 유효 대역폭 추정 방법.
  6. 청구항 5에 있어서,
    상기 가우시안 모델(
    Figure PCTKR2022015119-appb-img-000103
    )은 수학식 12로 정의되고,
    [수학식 12]
    Figure PCTKR2022015119-appb-img-000104
    여기서,
    Figure PCTKR2022015119-appb-img-000105
    는 상기 트랜잭션 개수를 나타내고,
    Figure PCTKR2022015119-appb-img-000106
    는 지수 분포 확률 모델(exponentially distributed stochastic model)의 트랜잭션 속도인, 블록 데이터 전송을 위한 유효 대역폭 추정 방법.
  7. 청구항 6에 있어서,
    상기 블록 전송 시간은 수학식 13으로 정의되고,
    [수학식 13]
    Figure PCTKR2022015119-appb-img-000107
    여기서,
    Figure PCTKR2022015119-appb-img-000108
    는 가중치로서 상기 성공 확률에 대응하여 고정되는, 블록 데이터 전송을 위한 유효 대역폭 추정 방법.
  8. 청구항 7에 있어서,
    상기 성공 확률은 상기 블록 전송 시간이 더 작게 설정됨에 따라서 업로드 대역폭 사용을 희생하면서 더 작은 블록 버퍼링 시간을 확률적으로 보장하는, 블록 데이터 전송을 위한 유효 대역폭 추정 방법.
  9. 청구항 7에 있어서,
    상기 유효 대역폭은 수학식 14로 추정되고,
    [수학식 14]
    Figure PCTKR2022015119-appb-img-000109
    여기서,
    Figure PCTKR2022015119-appb-img-000110
    는 상기 트랜잭션 크기이고,
    Figure PCTKR2022015119-appb-img-000111
    는 상기 블록 헤더 크기이며,
    Figure PCTKR2022015119-appb-img-000112
    는 상기 트랜잭션들이 도착할 때까지의 시간 간격인, 블록 데이터 전송을 위한 유효 대역폭 추정 방법.
  10. 청구항 9에 있어서,
    상기 트랜잭션 개수가 소정의 기준값보다 클 때, 상기 유효 대역폭은 상기 지수 분포 확률 모델의 트랜잭션 속도에 따라 선형적으로 증가하는, 블록 데이터 전송을 위한 유효 대역폭 추정 방법.
  11. 청구항 10에 있어서,
    상기 지수 분포 확률 모델의 트랜잭션 속도가 소정의 기준값보다 크면, 상기 유효 대역폭은 상기 트랜잭션 개수에 대해 기하급수적으로 감소하는, 블록 데이터 전송을 위한 유효 대역폭 추정 방법.
  12. 청구항 11에 있어서,
    상기 성공 확률이 커질수록 상기 트랜잭션 개수에 대한 기하급수적 감소율은 더 커지는, 블록 데이터 전송을 위한 유효 대역폭 추정 방법.
  13. 청구항 9에 있어서,
    상기 트랜잭션 개수가 미리 결정된 트랜잭션 개수보다 작더라도, 상기 트랜잭션들 중 가장 오래된 트랜잭션의 버퍼링 시간이 소정의 임계값보다 크면 그 즉시 블록을 생성하여, 상기 트랜잭션들이 도착할 때까지의 시간 간격을 미리 설정된 크기보다 작게 유지하는 단계를 더 포함하는, 블록 데이터 전송을 위한 유효 대역폭 추정 방법.
  14. 멀티 클라우드에서의 블록 데이터 전송을 위한 유효 대역폭 추정 장치로서,
    프로세서; 및
    상기 프로세서에 연결되고 상기 프로세서에 의해 실행되는 적어도 하나의 명령을 저장하는 메모리를 포함하고,
    상기 적어도 하나의 명령은, 상기 프로세서에 의해,
    가우시안 모델을 따르는 블록의 생성 주기에서, 다음 블록의 생성 전에 기설정된 성공 확률로 이전 블록의 전송을 완료하기 위한 블록 전송 시간을 계산하는 단계, 및
    상기 블록에 포함되는 트랜잭션 개수와 트랜잭션 크기와 블록 헤더 크기 및상기 블록 전송 시간에 기초하여 유효 대역폭을 추정하는 단계를 수행하도록 하는, 블록 데이터 전송을 위한 유효 대역폭 추정 장치.
  15. 청구항 14에 있어서,
    상기 적어도 하나의 명령은, 상기 프로세서에 의해,
    상기 계산하는 단계에서 상기 가우시안 모델을 따르는 블록의 생성 주기에서 상기 블록 데이터 전송을 위한 트랜잭션들은 기하급수적으로 분포하고 상기 멀티 클라우드의 오더러(orderer)에서 블록이 고정된 크기로 생성되도록 처리하는, 블록 데이터 전송을 위한 유효 대역폭 추정 장치.
  16. 청구항 15에 있어서,
    상기 적어도 하나의 명령은, 상기 프로세서에 의해,
    상기 계산하는 단계에서 미리 설정된 개수의 트랜잭션들이 오더러에 도착할 때 상기 블록을 생성하는 단계를 더 수행하도록 하는, 블록 데이터 전송을 위한 유효 대역폭 추정 장치.
  17. 청구항 16에 있어서,
    상기 적어도 하나의 명령은, 상기 프로세서에 의해,
    상기 블록에 포함된 인접한 두 트랜잭션들 사이의 시간 간격을 기하급수적으로 분포하는 것으로 처리하도록 하는, 블록 데이터 전송을 위한 유효 대역폭 추정 장치.
  18. 청구항 14에 있어서,
    상기 블록에 포함된 트랜잭션 개수가 미리 설정된 기준값 이상으로 클 때, 트랜잭션들이 도착할 때까지의 시간 간격은 상기 가우시안 모델로 정의되는, 블록 데이터 전송을 위한 유효 대역폭 추정 장치.
  19. 청구항 14에 있어서,
    상기 성공 확률은 상기 블록 전송 시간이 더 작게 설정됨에 따라서 업로드 대역폭 사용을 희생하면서 더 작은 블록 버퍼링 시간을 확률적으로 보장하도록 설정되는, 블록 데이터 전송을 위한 유효 대역폭 추정 장치.
  20. 청구항 14에 있어서,
    상기 적어도 하나의 명령은, 상기 프로세서에 의해,
    상기 블록에 포함된 트랜잭션들의 개수가 미리 결정된 트랜잭션 개수보다 작더라도, 상기 트랜잭션들 중 가장 오래된 트랜잭션의 버퍼링 시간이 소정의 임계값보다 크면 그 즉시 블록을 생성하는 단계를 더 수행하도록 하여, 상기 트랜잭션들이 도착할 때까지의 시간 간격을 미리 설정된 크기보다 작게 유지하는, 블록 데이터 전송을 위한 유효 대역폭 추정 장치.
  21. 멀티 클라우드의 확장 가능한 하이퍼레저 패브릭 블록체인을 위한 블록 전송 시스템의 제어 메시지 생성 방법으로서,
    복수의 참여 노드들을 복수의 클러스터들에 속한 노드들로 구분하는 단계;
    상기 복수의 참여 노드들 중에서 상기 복수의 클러스터들 각각의 클러스터 리더를 선택하는 단계; 및
    상기 복수의 클러스터들과 상기 클러스터 리더에 대한 정보에 기초하여 하이브리드 P2P(peer to peer) 멀티캐스트 트리(multicast tree)를 구성하는 단계를 포함하고,
    상기 구성하는 단계는, 상기 하이브리드 P2P 멀티캐스트 트리에 포함되는 각 참여 노드의 트리 정보를 노드 IP(internet protocol) 필드, 자식 노드 수(the number of child nodes) 필드 및 자식 노드 목록의 오프셋(offset of child nodes lists) 필드의 조합으로 형성하는 단계를 포함하는, 제어 메시지 생성 방법.
  22. 청구항 21에 있어서,
    상기 노드 IP 필드는 현재 노드의 IP 주소를 나타내고, 상기 자식 노드 수 필드는 상기 하이브리드 P2P 멀티캐스트 트리를 통해 상기 현재 노드에 연결된 자식 노드의 수를 나타내고, 상기 자식 노드 목록의 오프셋 필드는 제어 메시지 자체 내에서 첫 번째 자식 노드의 위치를 나타내는, 제어 메시지 생성 방법.
  23. 청구항 21에 있어서,
    상기 구성하는 단계는, 상기 각 참여 노드의 트리 정보를 미리 설정된 순서대로 일렬로 배열한 페이로드를 형성하는 단계를 더 포함하는 제어 메시지 생성 방법.
  24. 청구항 23에 있어서,
    상기 복수의 참여 노드들 중 상기 페이로드를 포함한 제어 메시지를 받은 특정 참여 노드가 하위 트리에 대한 정보를 제거하여 상기 제어 메시지를 재구성하는 단계를 더 포함하는 제어 메시지 생성 방법.
  25. 청구항 21에 있어서,
    상기 복수의 참여 노드들의 각 노드와 상기 멀티 클라우드의 오더러(orderer) 간에 추정된 엔드투엔드(end-to-end) 지연(delay)에 기초하여 획득되는 상기 복수의 참여 노드들의 유효 대역폭과 지원가능한 자식 노드들의 개수 중 적어도 어느 하나가 미리 설정된 기준 범위를 벗어난 변동이 있는지를 판단하는 단계를 더 포함하며,
    상기 구성하는 단계는 상기 판단하는 단계의 판단 결과가 변동 있음인 경우에 수행되는, 제어 메시지 생성 방법.
  26. 청구항 21에 있어서,
    상기 구분하는 단계, 상기 선택하는 단계 및 상기 구성하는 단계를 반복적으로 수행하여 클러스터 개수와 클러스터 리더를 최종 결정하는 단계를 더 포함하는, 제어 메시지 생성 방법.
  27. 청구항 21 내지 청구항 26 중 어느 하나의 제어 메시지 생성 방법에 이용되는 제어 메시지 포맷으로서,
    헤더 및 페이로드를 포함하고,
    상기 헤더는 버전(version), 메시지 유형(message type) 및 메시지 길이(message length)에 대한 정보를 담고,
    상기 페이로드는 소정의 순번들에 따라 복수의 노드들의 트리 정보를 각각 순차적으로 나열한 형태를 구비하는, 제어 메시지 포맷.
  28. 청구항 27에 있어서,
    상기 복수의 노드들 각각의 트리 정보는 노드 IP(internet protocol), 자식 노드 수(the number of child nodes) 및 자식 노드 목록의 오프셋(offset of child nodes lists)에 대한 필드들을 구비하는, 제어 메시지 포맷.
  29. 멀티 클라우드의 확장가능한 하이퍼레저 패브릭 블록체인을 위한 블록 전송 시스템의 트리 정보 전달 방법으로서,
    멀티 클라우드에 연결된 검증 노드에서 모든 참여 노드들로부터 좌표 값들을 수신하는 단계;
    오더러(orderer)로부터 트랜잭션 속도(transaction rate)를 수신하는 단계;
    상기 모든 참여 노드들 중 상기 오더러에 연결되는 앵커 노드들의 업링크 대역폭을 추정하는 단계;
    상기 모든 참여 노드들의 유효 대역폭과 지원가능한 자식 노드들의 개수를 계산하는 단계;
    상기 모든 참여 노드들의 각 참여 노드와 상기 오더러 간의 엔드투엔드 지연을 추정하는 단계;
    상기 엔드투엔드 지연에 기초하여 상기 유효 대역폭과 상기 지원가능한 자식 노드들의 개수가 미리 설정된 기준 범위를 벗어하는 변동이 있는지를 판단하는 단계;
    상기 변동이 있는 경우, 상기 좌표 값들과 상기 트랜잭션 속도에 대한 정보에 기초하여 상기 모든 참여 노드들을 복수의 클러스터들로 클러스터링하는 단계;
    상기 복수의 클러스터들 각각의 클러스터 리더를 선택하는 단계;
    상기 복수의 클러스터와 상기 클러스터 리더를 토대로 중첩 멀티캐스트 트리를 구성하는 단계; 및
    상기 중첩 멀티캐스트 트리를 제어 메시지에 담아 상기 오더러로 전송하는 단계;를 포함하는 트리 정보 전달 방법.
  30. 청구항 29에 있어서,
    상기 제어 메시지는 상기 모든 참여 노드들에 전달되어 각 참여 노드에서 메시지 전달 테이블의 업데이트에 이용되는, 트리 정보 전달 방법.
  31. 청구항 29에 있어서,
    상기 클러스터링하는 단계, 상기 클러스터 리더를 선택하는 단계 및 상기 중첩 멀티캐스트 트리를 구성하는 단계를 반복적으로 수행하여 클러스터 개수와 클러스터 리더를 최종적으로 결정하는 단계를 더 포함하는, 트리 정보 전달 방법.
  32. 청구항 29에 있어서,
    상기 제어 메시지의 포맷은 헤더 및 페이로드를 포함하고,
    상기 헤더는 버전(version), 메시지 유형(message type) 및 메시지 길이(message length)에 대한 정보를 담고, 상기 페이로드는 소정의 순번들에 따라 복수의 노드들의 트리 정보를 각각 순차적으로 나열한 형태를 구비하는, 트리 정보 전달 방법.
  33. 청구항 22에 있어서,
    상기 복수의 노드들의 각 노드의 트리 정보는 노드 IP(internet protocol), 자식 노드 수(the number of child nodes) 및 자식 노드 목록의 오프셋(offset of child nodes lists)에 대한 필드들을 구비하는, 트리 정보 전달 방법.
  34. 청구항 22에 있어서,
    상기 복수의 참여 노드들 중 상기 페이로드를 포함한 제어 메시지를 받은 특정 참여 노드가 일부 하위 트리에 대한 정보를 제거하여 상기 제어 메시지를 재구성하는 단계를 더 포함하는 트리 정보 전달 방법.
  35. 청구항 29에 있어서,
    상기 제어 메시지의 크기는 상기 중첩 멀티캐스트 트리를 통해 상기 오더러로부터 리프 노드들까지 전달되는 동안 각 부모 노드에서 단계적으로 감소되는, 트리 정보 전달 방법.
PCT/KR2022/015119 2022-06-21 2022-10-07 멀티 클라우드의 블록 데이터 전송을 위한 유효 대역폭 추정 방법과 제어 메시지 생성 방법 및 트리 정보 전달 방법과 이를 위한 블록 전송 시스템 Ceased WO2023249166A1 (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR1020220075510A KR102748246B1 (ko) 2022-06-21 2022-06-21 멀티 클라우드의 블록 전송 시스템의 제어 메시지 생성 방법과 이를 위한 제어 메시지 포맷 및 이를 이용하는 트리 정보 전달 방법
KR10-2022-0075510 2022-06-21
KR1020220085477A KR102723667B1 (ko) 2022-07-12 2022-07-12 멀티 클라우드에서의 블록 데이터 전송을 위한 유효 대역폭 추정 방법 및 장치
KR10-2022-0085477 2022-07-12

Publications (1)

Publication Number Publication Date
WO2023249166A1 true WO2023249166A1 (ko) 2023-12-28

Family

ID=89380177

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/015119 Ceased WO2023249166A1 (ko) 2022-06-21 2022-10-07 멀티 클라우드의 블록 데이터 전송을 위한 유효 대역폭 추정 방법과 제어 메시지 생성 방법 및 트리 정보 전달 방법과 이를 위한 블록 전송 시스템

Country Status (1)

Country Link
WO (1) WO2023249166A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN119316298A (zh) * 2024-09-29 2025-01-14 电子科技大学 一种适用于动态网络环境下的自适应通信联邦学习方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20090053298A (ko) * 2007-11-23 2009-05-27 한국정보통신대학교 산학협력단 대역폭 산정 모델 및 그 방법
KR20190041784A (ko) * 2017-10-13 2019-04-23 주식회사 포스링크 멀티클라우드 환경에서 블록체인 기반의 분산동기화 접근 제어 시스템 및 그 방법
KR20200062889A (ko) * 2018-11-27 2020-06-04 한국전자통신연구원 블록체인 시스템에서 계층적 합의 알고리즘에 기초하여 블록 합의를 수행하는 방법 및 장치
KR20210082890A (ko) * 2019-12-26 2021-07-06 서강대학교산학협력단 블록체인 네트워크에서의 처리 성능 향상 방법
KR20220064744A (ko) * 2020-11-12 2022-05-19 주식회사 티맥스엔터프라이즈 클라우드 시스템 기반 블록 체인

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20090053298A (ko) * 2007-11-23 2009-05-27 한국정보통신대학교 산학협력단 대역폭 산정 모델 및 그 방법
KR20190041784A (ko) * 2017-10-13 2019-04-23 주식회사 포스링크 멀티클라우드 환경에서 블록체인 기반의 분산동기화 접근 제어 시스템 및 그 방법
KR20200062889A (ko) * 2018-11-27 2020-06-04 한국전자통신연구원 블록체인 시스템에서 계층적 합의 알고리즘에 기초하여 블록 합의를 수행하는 방법 및 장치
KR20210082890A (ko) * 2019-12-26 2021-07-06 서강대학교산학협력단 블록체인 네트워크에서의 처리 성능 향상 방법
KR20220064744A (ko) * 2020-11-12 2022-05-19 주식회사 티맥스엔터프라이즈 클라우드 시스템 기반 블록 체인

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KANDA REIKI KANDA.R.AA@M.TITECH.AC.JP; SHUDO KAZUYUKI SHUDO@IS.TITECH.AC.JP: "Estimation of Data Propagation Time on the Bitcoin Network", PROCEEDINGS OF THE 35TH IEEE/ACM INTERNATIONAL CONFERENCE ON AUTOMATED SOFTWARE ENGINEERING, ACM, 2 PENN PLAZA, SUITE 701NEW YORKNY10121-0701USA, 7 August 2019 (2019-08-07) - 15 November 2019 (2019-11-15), 2 Penn Plaza, Suite 701New YorkNY10121-0701USA , pages 47 - 52, XP058936373, ISBN: 978-1-4503-7001-1, DOI: 10.1145/3340422.3343641 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN119316298A (zh) * 2024-09-29 2025-01-14 电子科技大学 一种适用于动态网络环境下的自适应通信联邦学习方法

Similar Documents

Publication Publication Date Title
WO2020226360A1 (en) Apparatus and method for supporting burst arrival time reference clock based on time-sensitive communication assistance information in wireless communication network
JP4396859B2 (ja) 負荷分散方法、ノード及び制御プログラム
WO2023132443A1 (ko) 산업용 IoT에서 사용되는 TSN 네트워크를 위한 비결정적 중단을 제거하는 공동 트래픽 라우팅 및 스케줄링 방법
WO2015026186A1 (ko) 무선 통신 시스템에서 데이터 패킷 송수신 방법 및 장치
WO2017219476A1 (zh) 数据传输方法和装置
WO2024128676A1 (en) Method and apparatus for supporting hybrid federated learning workload in communication system
Mohan et al. Resilient VNF placement for service chain embedding in diversified 5G network slices
Avin et al. Renets: Statically-optimal demand-aware networks
WO2022255694A1 (en) Methods and systems for determining dss policy between multiple rats
WO2021230464A1 (ko) 모바일 에지 컴퓨팅 시스템의 비동기식 자원 할당 방법 및 장치
EP3857855A1 (en) Method and apparatus for enhanced assertion management in cloud media processing
KR101658824B1 (ko) 소프트웨어 정의 네트워크에서 플로우 룰을 변경하는 방법, 장치 및 컴퓨터 프로그램
WO2016148370A1 (ko) 데이터 전송률 향상을 위한 다중 연결 제어 방법 및 장치
WO2019143181A1 (en) Method and an electronic device for dynamically controlling tcp congestion window
Yaghoubi et al. Consistency-aware weather disruption-tolerant routing in SDN-based wireless mesh networks
WO2016148527A1 (ko) 이동 통신 시스템에서 패킷 생성 방법 및 장치
WO2019027142A1 (ko) 동적 네트워크에서 네트워크 형성 방법 및 장치
WO2014065586A1 (en) Source, relay, and destination executing cooperation transmission and method for controlling each thereof
WO2017131285A1 (ko) 컨테이너 네트워크 관리 시스템 및 컨테이너 네트워킹 방법
WO2024071762A1 (ko) 가입 검사를 위한 전자 장치 및 방법
CN119234404A (zh) 时刻同步装置、时刻同步方法和时刻同步程序
WO2024005562A1 (en) Embedding neural networks as a matrix for network device in wireless network
WO2016006783A1 (ko) Ｐ２ｐ를 이용한 하이브리드 스토리지 시스템 및 이를 이용한 데이터 전송 방법
WO2024039144A1 (en) Method and apparatus for choosing operating mode for multi-link device
WO2015065003A1 (ko) 서비스에 따른 트래픽 처리를 이용한 ＱｏＳ 제어 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22948100

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22948100

Country of ref document: EP

Kind code of ref document: A1