WO2020022599A1 - 블록체인 네트워크 상에서 그룹키 기반의 이중 서명 트랜잭션 구조를 구성하는 노드 그룹 관리 장치 및 컴퓨팅 장치 - Google Patents

블록체인 네트워크 상에서 그룹키 기반의 이중 서명 트랜잭션 구조를 구성하는 노드 그룹 관리 장치 및 컴퓨팅 장치 Download PDF

Info

Publication number
WO2020022599A1
WO2020022599A1 PCT/KR2019/001731 KR2019001731W WO2020022599A1 WO 2020022599 A1 WO2020022599 A1 WO 2020022599A1 KR 2019001731 W KR2019001731 W KR 2019001731W WO 2020022599 A1 WO2020022599 A1 WO 2020022599A1
Authority
WO
WIPO (PCT)
Prior art keywords
group
node
nodes
secret key
transaction
Prior art date
Application number
PCT/KR2019/001731
Other languages
English (en)
French (fr)
Inventor
박기업
손영욱
도현철
정미라
채광은
전병렬
윤주원
Original Assignee
박기업
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 KR1020190014619A external-priority patent/KR102120703B1/ko
Application filed by 박기업 filed Critical 박기업
Priority to JP2021505768A priority Critical patent/JP2021533638A/ja
Priority to CN201980063538.8A priority patent/CN112913185A/zh
Publication of WO2020022599A1 publication Critical patent/WO2020022599A1/ko
Priority to US17/159,021 priority patent/US20210258154A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords

Definitions

  • Embodiments of this document relate to a technique for enhancing security by constructing a transaction structure requiring double signing and verification based on a group key on a blockchain network.
  • the blockchain system operates a blockchain in which a block containing information is chained as a distributed database, so that nodes constituting the blockchain network can share common information.
  • a node In order to record or change information on the blockchain, a node generates a transaction on the network and is verified by other nodes to verify that the transaction is correct. The generation and verification of such a transaction is performed by a private key and a public key held by each node.
  • Each node exposes only its public key on the blockchain network, and signs the information to be delivered with its own private key, and then propagates the information to the other nodes.
  • the other node that receives this decrypts the signature through the public key, checks whether the transaction is signed by the correct party, and then verifies the transaction.
  • the public key is generated based on the secret key, but because it is generated through an irreversible function, it is difficult to recover the secret key from the public key even if it is known. However, if the secret key itself is hacked, there is a fatal problem that the hacker can generate all desired transactions in the account. Because of this, if a hacker creates a malicious transaction that records all the cryptocurrencies held in the account and transfers them to the block, it cannot be reversed again on the blockchain.
  • Embodiments of the present invention intend to solve the above-described problem through a technique of generating a group secret key shared only between nodes in a group based on information of a group of a plurality of nodes.
  • the generated group secret key is generated by a trusted node that manages node information in the group, and the group secret key can be leaked to nodes inside the group that share the same benefits of improved security due to the group secret key. It can be designed so that the group secret key can not be inferred because there is no profit and node information outside the group cannot know the information of other groups.
  • embodiments of the present document prevent hacking damage from occurring through a technique that allows a group secret key to be periodically updated even if a group secret key is leaked, and also when a change occurs in a node group. can do.
  • additional signing through the other key is required, giving the account holder time to recognize the hack and to prepare for an alternative.
  • the embodiments of this document are intended to improve the security of the blockchain network by constructing a structure in which transaction signing and verification are doubled.
  • the node group management apparatus manages a first group to which some nodes of the nodes forming a blockchain network sharing a distributed database belong.-All nodes participating in the blockchain network each have a secret key and a public key.
  • a communication interface for communicating with the blockchain network; One or more memories for storing information about the nodes of the first group and instructions for performing an operation of a processor, wherein the information about the nodes of the first group includes a public key of each node of the first group; And at least one memory connected to the at least one memory to operate through the command, and based on information about the node of the first group, together with the signature of the secret key in the transaction when the node of the first group creates a transaction. At least one processor for generating a group secret key to perform additional signing of the transaction and distributing the group secret key to the first group so that the nodes of the first group have in common. have.
  • a computing device performs a node constituting a blockchain network sharing a distributed database, wherein all nodes participating in the blockchain network each have a secret key and a public key, and the blockchain network.
  • a communication interface for communicating Stores information about the node group device of claim 1 for managing the first group to which one node belongs, a plurality of group secret keys distributed by the node group device over time, and instructions for performing operations of the processor.
  • One or more memories the plurality of group secret keys including time information; And a group, which is connected to the one or more memories to operate through the command, and a group created before a predetermined period from a group secret key stored most recently among the plurality of group secret keys with reference to the time information when generating a transaction.
  • One or more processors may be configured to perform an operation of including a signature using a private key in the transaction.
  • the node group management method is performed by a node constituting a blockchain network sharing a distributed database and a node group management apparatus—all nodes constituting the blockchain network each have a private key and a public key.
  • the information about the nodes of the group includes a public key of each of the nodes of the first group;
  • the secret key and the group secret key are used together in the transaction signature, even if the secret key is hacked, the damage caused by the hack can be prevented through the configuration requesting the signature of the group secret key.
  • the reliability of the group key-based transaction signature can be increased by generating and distributing the group secret key and the group public key through the gateway having reliability.
  • the node when a node creates a transaction, the node performs a signature through a group secret key distributed all over the blockchain network, thereby preventing a transaction verification error due to a communication delay.
  • FIG. 1 is a block diagram of a distributed network system according to an embodiment.
  • FIG. 2 is a diagram illustrating a blockchain structure according to an embodiment.
  • FIG. 3 is a diagram for describing types of nodes included in a distributed network system according to an exemplary embodiment.
  • FIG. 4 is a block diagram of a full node according to an embodiment.
  • FIG. 5 is a block diagram of a light node according to an exemplary embodiment.
  • FIG. 6 is a block diagram of a server according to an exemplary embodiment.
  • FIG. 7 is a flowchart illustrating a registration process of a gateway according to an embodiment.
  • FIG. 8 is a flowchart illustrating a management operation of a gateway according to an embodiment.
  • 9A, 9B, and 9C are flowcharts for describing an operation in which a node joins a group in an embodiment.
  • FIG. 10 is a flowchart of an operation of synchronizing gateway lists between servers according to an embodiment.
  • 11 is an exemplary diagram of an operation of generating, by a gateway, a group secret key according to an embodiment.
  • FIG. 12 is a flowchart for describing an operation of generating and distributing a group secret key and a group public key by a gateway according to an embodiment.
  • FIG. 13 is a flowchart illustrating a situation in which a node can verify and a situation in which verification cannot be performed according to a selection of a group secret key according to an embodiment.
  • FIG. 14 is an exemplary diagram illustrating a group public key state distributed to each group according to an embodiment.
  • 15 is a conceptual diagram of transaction double signature based on group secret key and transaction double verification based on group public key, according to an embodiment.
  • FIG. 1 is a block diagram of a distributed network system 100 according to one embodiment.
  • a distributed network system 100 may be implemented through a plurality of computing devices 110, 120, 130, and 140. Although four computing devices 110, 120, 130, and 140 are illustrated in FIG. 1, the present disclosure is not limited thereto, and the distributed network system 100 may further include any number of computing devices that are not shown.
  • Network 105 may include a wired network and / or a wireless network.
  • the network 105 may be at least one of a local area network (LAN), a wide area network (WAN), a virtual network, and a telecommunications network.
  • the distributed network system 100 forms a blockchain network, which is a peer-to-peer network in which computing devices 110, 120, 130, 140 are connected to each other so as to be operable through a network 105, sharing a distributed database with the same information. can do.
  • the computing devices 110, 120, 130, 140 may generate a transaction on the distributed network system 100, which is a unit of work performed to change the state of the distributed database.
  • the computing devices 110, 120, 130, and 140 may verify and execute a transaction occurring in the distributed network system 100, and store a record of the transaction in a blockchain structure to manage a distributed database. .
  • Each computing device 110, 120, 130, 140 may have a blockchain account information to generate a transaction and verify the integrity of the transaction.
  • the blockchain account information may include a private key and a public key (hereinafter collectively referred to as 'private key').
  • the private key is a digital signature means for verifying that a transaction is generated by a valid party.
  • the secret key may be generated by hashing a message and a private key to be included in the transaction.
  • the public key may serve as the user's account address or as a means to verify that the digital signature included in the transaction is generated by the correct user's private key.
  • computing devices 110, 120, 130, and 140 in addition to a private key, are group private keys and group public keys that are used in the role of signing and verifying transactions, dually. public key) (hereafter collectively referred to as a 'group key'). A more detailed description of the group key will be described later with reference to FIGS. 11 to 15.
  • the computing devices 110, 120, 130, and 140 verify the integrity of the transaction when the transaction occurs, and based on the consensus algorithm (eg, POW, POS, DPOS, etc.) promised in the distributed network system 100.
  • a new block is created to follow the generated block, and the newly generated block is propagated to other computing devices 110, 120, 130, and 140 to execute a transaction.
  • the block may include a plurality of transaction information.
  • FIG. 2 is a diagram illustrating a blockchain structure according to an embodiment.
  • the block chain may linearly connect data stored in block units.
  • Each block may be concatenated by pointing to the previous block (eg, the previous block of 'block 2' is 'block 1').
  • the connection form of the blocks is not limited to this example.
  • the block 210 may be composed of a header (220) and a body (230).
  • Data stored in the header 220 may be understood as summary information about the block 210.
  • the header 220 includes a software version that is version information of the software, a previous block hash that serves as a hash pointer of the previous block as a hash value of the header of the previous block, a merkle root that is information summarizing transactions, and a block 210.
  • the block hash value may be calculated based on the data stored in the header 220 of the block 210.
  • the next block can point to the previous block by storing the block hash value of the previous block.
  • the distributed network system 100 may be referred to as a blockchain network system.
  • the body 230 may include a transaction list including transactions that are data to be stored and preserved in the block 210, and a transaction number that is the total number of transactions included in the block 210.
  • the transaction may be a transaction history, but is not limited thereto.
  • Computing device 110 may include a processor 111 and a memory 112.
  • memory 112 may include random access memory (RAM), memory buffers, hard drives, databases, erasable programmable read-only memory (EPROM), electrically erasable read-only memory (EEPROM), and read-only memory (ROM). ) And / or the like.
  • the processor 111 may be a general-purpose processor, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a digital signal processor (DSP), and / or the like.
  • FPGA field programmable gate array
  • ASIC application specific integrated circuit
  • DSP digital signal processor
  • One or more portions of computing device 110, 120, 130, 140 may be hardware-based modules (eg, digital signal processors (DSPs), field programmable gate arrays (FPGAs)) and / or software-based modules (eg, Modules of computer code stored in memory and / or executed on a processor.
  • DSPs digital signal processors
  • FPGAs field programmable gate arrays
  • software-based modules eg, Modules of computer code stored in memory and / or executed on a processor.
  • one or more functions associated with computing devices 110, 120, 130, 140 eg, functions associated with processors 111, 121, 131, 141) may be included in one or more modules.
  • Memory 112 of computing device 110 may include a distribution database 114.
  • Computing devices 110, 120, 130, 140 may implement distributed database 114, 124, 134, 144 over network 105.
  • Distributed databases 114, 124, 134, and 144 may be understood as public ledgers in which a plurality of computing devices 110, 120, 130, and 140 share the same information.
  • the processor 111 may be configured to update the distributed database 114 in response to receiving synchronization data and the like associated with transactions (eg, messages for changing data in the distributed database) from other computing devices. And / or to execute a process.
  • FIG. 3 is a diagram for describing types of nodes included in a distributed network system 100 according to an exemplary embodiment.
  • each of the computing devices included in the distributed network system 100 may be understood as a node.
  • Nodes included in the distributed network system 100 may be divided into a full node 300 and a light node 400.
  • the full node 300 is a node that synchronizes and maintains all information (eg, header 220 information and body 230 information) included in the blockchain 200 in real time.
  • the write node 400 is a node capable of performing a transaction function (eg, a wallet function).
  • the write node 400 may generate a transaction and propagate the generated transaction to the neighbor node through the network 105.
  • the write node 400 may perform verification on the generated block with only some information (eg, header 220 information) included in the blockchain 300.
  • the full node 300 and the light node 400 may be collectively referred to as the node 600 included in the distributed network system 100.
  • Nodes included in the distributed network system 100 may belong to different or the same group based on location information. Nodes located in close proximity can be classified into the same group.
  • the group may be determined by at least one server (500 in FIG. 6) in communication with the distributed network system 100.
  • one server 500 will be described, but a plurality of servers 500 may perform group classification.
  • the server 500 may classify adjacent nodes into the same group based on the location information of the nodes. Accordingly, neighboring nodes that frequently communicate with each other belong to a group, and communication efficiency can be increased.
  • the server 500 may be operated by a third party.
  • At least a portion of the full node 300 may act as a gateway (Gateway or GW, also referred to as 'node group management device' in some of this document) 301.
  • the gateway 301 may generate block 210 and manage one group.
  • the gateway 301 may receive the block reward by generating the block 210 and distribute the received block reward to nodes of a group to which the gateway 301 belongs.
  • Different gateways 301 may manage different groups.
  • the gateway 301 may generate a group private key and a group public key, share the group private key with nodes in the same group, and distribute the group public key outside of the group.
  • group 1 includes four full nodes 300 and six light nodes 400.
  • One full node 300 of the four full nodes 300 may operate as the gateway 301.
  • the gateway 301 may have information about nodes belonging to group 1.
  • the gateway 301 may distribute the block reward to the nodes belonging to the group 1.
  • Distributed network system 100 may have one or more groups, and each group may have at least one gateway 301.
  • each group including group 1, and the number of each node are merely exemplary, and the number of full nodes 300 and the number of light nodes 400 except for one full node operable as the gateway 301. May be arbitrarily determined. According to an embodiment, the total number of nodes included in one group may be up to 512, but it is not limited thereto.
  • FIG. 4 shows a block diagram of a full node 300 according to one embodiment.
  • the full node 300 may include a communication interface 305, a processor 310, and a memory 320.
  • the full node 300 may communicate with nodes and the server 500 included in the distributed network system 100 through the communication interface 305.
  • the processor 310 may include a transaction generation module 312 and a transaction verification module 314.
  • the processor 310 may further include a group secret key generation module 316 and a group public key generation module 318.
  • the processor 310 executes instructions stored in the memory 320 to execute at least one of the transaction generation module 312, the transaction verification module 314, the group secret key generation module 316, and the group public key generation module 318. Can be driven.
  • Each of the transaction generation module 312, the transaction verification module 314, the group secret key generation module 316, and the group public key generation module 318 may be driven by executing instructions included in the wallet program 328. It is not limited.
  • Each of the transaction generation module 312, the transaction verification module 314, the group secret key generation module 316, and the group public key generation module 318 may be implemented in hardware, software, or a combination thereof. An operation performed by each of the transaction generation module 312, the transaction verification module 314, the group secret key generation module 316, and the group public key generation module 318 may be understood as an operation performed by the processor 310. Can be.
  • the transaction generation module 312 may generate a transaction requesting that the block include data (eg, transaction details) that are to be stored and preserved in the block.
  • the transaction generation module 312 may include the digital signature using the secret key and the digital signature using the group key in the transaction.
  • the transaction verification module 314 may verify a transaction generated by itself or a transaction received from another node based on the private public key and the group public key.
  • the group secret key generation module 316 may generate a group secret key based on information of nodes included in a group managed by the full node 300 which is the gateway 301.
  • a group secret key is information shared only between nodes within the same group and may be used to sign a transaction with the secret key.
  • the group public key generation module 318 may generate a group public key through an operation on the generated group private key.
  • the group public key is information distributed to a blockchain network outside the group and may be used to verify a transaction signature.
  • Memory 320 may include blockchain information 322 (e.g., information associated with blockchain 200 of FIG. 2), server list 324, group subscription history 326, wallet program 328, and group key list ( 329).
  • blockchain information 322 e.g., information associated with blockchain 200 of FIG. 2
  • server list 324 e.g., information associated with blockchain 200 of FIG. 2
  • group subscription history 326 e.g., information associated with blockchain 200 of FIG. 2
  • wallet program 328 e.g., information associated with blockchain 200 of FIG. 2
  • group key list 329
  • the blockchain information 322 may include information included in the blockchain 200 of FIG. 2.
  • the full node 300 may be a computing device in a Windows or Linux environment.
  • the full node 300 may have hardware resources that store information related to the blockchain 200 and synchronize in real time.
  • the server list 324 may include information associated with servers that perform grouping on nodes of the distributed network system 100.
  • the server list 324 may include a unique ID of the server 500 and server 500 location information (IP, latitude, longitude).
  • IP IP, latitude, longitude.
  • the full node 300 may send a request to at least one server 500 included in the server list 324 to join a group or become a gateway 301.
  • the group subscription history 326 may include information associated with the group when the full node 300 has previously joined the group.
  • the group subscription history 326 may include account information of the gateway 301 of the group to which the group has subscribed.
  • the wallet program 328 may include instructions and associated data for creating and verifying a transaction. According to an embodiment, when the full node 300 operates as the gateway 301, the wallet program 328 may include instructions for generating a group secret key and a group public key and related data. The account of the full node 300 may be the node address of the wallet program 328.
  • the wallet program 328 may be a program running in an environment of Windows or Linux.
  • the group key list 329 may store a group secret key of a group to which the full node 300 belongs and a group public key generated from an external group including a group to which the full node 300 belongs.
  • the full node 300 may store the information on the group in which the group private key and the group public key are generated, the order information on which the group private key is generated, and the order information on which the group public key is generated. A more detailed description thereof will be described later with reference to FIGS. 11 to 15.
  • the full node 300 may further include a gateway list 330 and a node pool 335.
  • the gateway list 330 may include information associated with the gateways 301-1, 301-2, ⁇ 301-n currently operating as the gateway 301 and operating the group.
  • the gateway list 330 may also be stored in the server 500 and may serve as a backup in exceptional situations such as the server 500 being inoperable.
  • one full node 300 may operate as a plurality of gateways.
  • the plurality of gateways may have the same IP but different port numbers.
  • the node pool 335 may include information associated with nodes (computing devices) belonging to a group operated by the gateway 301.
  • the node pool 335 may include a list of nodes 600 belonging to its group.
  • the node pool 335 may include a public key of the node 600 belonging to its group and index information identifying each node 600, and the index information and the public key may be mapped and stored. have.
  • the write node 400 may include a communication interface 405, a processor 410, and a memory 420.
  • the write node 400 may communicate with nodes and the server 500 included in the distributed network system 100 through the communication interface 405.
  • the processor 510 may include a transaction generation module 412.
  • the processor 510 may execute the instructions stored in the memory 520 to drive the transaction generation module 412.
  • the transaction generation module 412 may be driven by executing instructions included in the wallet program 422, but is not limited thereto.
  • Transaction generation module 412 may be implemented in hardware, software, or a combination thereof. An operation performed by the transaction generation module 412 may be understood as an operation performed by the processor 410.
  • the transaction generation module 412 may generate a transaction requesting that the block include data (eg, transaction details) that are to be stored and preserved in the block.
  • the transaction generation module 412 may include the electronic signature using the secret key and the electronic signature using the group key in the transaction.
  • the transaction generation module 412 may select a group secret key to be used for signing a transaction in consideration of the order information of the generated group key. The description thereof will be described later with reference to FIGS. 14 and 15.
  • the write node 400 may store the wallet program 422, the server list 424, and the group subscription history 426 in the memory 420.
  • the wallet program 422 may include instructions and related data for creating and verifying a transaction.
  • the wallet program 422 may be a program that operates in a mobile environment such as Android or IOS.
  • the server list 424 and group subscription details 426 are substantially the same as the server list 324 and group subscription details 326 of the full node 300.
  • the group key list 428 may store a group secret key of a group to which the write node 400 belongs.
  • the group key list 428 does not include the group public key for each group, unlike the group key list 329 of the full node 300, since the write node 400 does not perform verification of the transaction. to be.
  • the server 500 may include a communication interface 505, a processor 510, and a memory 520.
  • the server 500 may communicate with nodes (full node 300, light node 400) of the distributed network system 100 through the communication interface 505.
  • the processor 510 may include a grouping module 512.
  • the processor 510 may execute the instructions stored in the memory 520 to drive the grouping module 512.
  • the grouping module 512 may be implemented in hardware, software, or a combination thereof. An operation performed by the grouping module 512 may be understood as an operation performed by the processor 510.
  • the grouping module 512 may determine a group for the nodes based on the location information of the nodes.
  • the memory 520 may store the gateway list 522 and the server list 524.
  • the gateway list 522 may be synchronized with the gateway list 330 stored in the full node 300.
  • the server list 524 may include information about other servers that perform the same role as the server 500.
  • FIG. 7 is a flowchart illustrating a registration process of a gateway according to an embodiment.
  • the full node 300 may transmit a gateway registration request message to any one server (the first server 500-1) to operate as the gateway 301 (701).
  • the full node 300 may transmit the message to any one server included in the server list by using the server list stored therein. For example, an example in which the message is transmitted to the first server 500-1 is illustrated.
  • the gateway registration message may include at least one of IP address information of the full node 300, port number information of the full node 300, latitude information of the full node 300, and longitude information of the full node 300. It may include.
  • the information may be understood as information associated with the location of the gateway 301.
  • the first server 500-1 may check the validity of the received gateway registration message (703) and transmit the gateway registration response message to the full node 300 (705).
  • the first server 500-1 may compare gateway list information with data included in the gateway registration request message.
  • the first server 500-1 may select a gateway 301 located at a location adjacent to the full node 300 from a list of gateways by using information associated with the location of the full node 300.
  • the gateway registration response message may include success / failure return_val for the processing result of the gateway registration message, and may include a gateway ID to be assigned to the full node 300.
  • the full node 300 registers the received gateway ID as its ID (707), and sends a gateway registration processing message to the first server 500-1. Can transmit (709).
  • the gateway registration process message may include a gateway ID registered by the full node 300. If the processing result included in the gateway registration response message fails, the full node 300 performs operations 701 to 709 with other servers included in the server list.
  • the first server 500-1 may update the gateway list using the gateway ID included therein (711).
  • the first server 500-1 may propagate the updated gateway list by transmitting a gateway addition request message to other servers.
  • the gateway add request message may include at least one of the following information.
  • the gateway add request message may include a synchronization index (number) of the first server 500-1.
  • the synchronization index may be a number that is updated when the gateway list is updated (when a gateway is added). For example, the synchronization index may be a number in the range of 0 to (pow (2,32) -1).
  • the gateway addition request message may include the number of gateways registered in the first server 500-1 and a list of gateways included in the first server 500-1.
  • the gateway addition request message may include at least one of an IP address, a port number, latitude information, and longitude information of the gateway included in the gateway list.
  • the gateway addition request message may be transmitted to, for example, the second server 500-2 to the n-th server 500-n included in the server list stored in the first server 500-1 (713, 717).
  • the second server 500-2 may identify the first server 500-1 that transmitted the message.
  • the second server 500-2 may identify the first server 500-1 by using the IP of the transmission destination where the message is transmitted.
  • the second server 500-2 may load the gateway list stored in the second server 500-2.
  • the second server 500-2 may compare the first synchronization index included in the received message with the second synchronization index stored in the second server 500-2.
  • the second server 500-2 updates the gateway list stored in the second server 500-2 with the gateway list received through the message,
  • the second synchronization index may be updated.
  • the second server 500-2 may transmit a gateway addition response message reflecting the processing result to the first server 500-1 (715). Operation 713 to operation 715 may be performed on the third server to the nth server 500-n in addition to the second server 500-2 included in the server list of the first server 500-1.
  • FIG. 8 is a flowchart illustrating a management operation of a gateway according to an embodiment.
  • the first server 500-1 manages the gateway 301.
  • the full node 300 performs an operation as the gateway 301.
  • the first server 500-1 may periodically check whether the message is reachable at the gateway 301. For example, the first server 500-1 may determine whether the gateway 301 is operating normally by transmitting a ping message to the gateway 301 (801) and receiving a response message (803). have. Operations 801 and 803 may be repeatedly performed every predetermined period (for example, 2 minutes).
  • the ping message may include any number for identifying the ping message.
  • the ping response message may include any number included in the received ping message.
  • the first server 500-1 may compare the random number to confirm that a response to the corresponding ping message has been received.
  • the gateway 301 may be deleted from the gateway list (807). For example, when the first server 500-1 transmits a predetermined number of ping messages (eg, three times) and no response is received, the first server 500-1 terminates the related program at the corresponding gateway 301, or It may be determined that the network of 301 is disconnected.
  • a predetermined number of ping messages eg, three times
  • the first server 500-1 may synchronize the gateway list with other servers by transmitting a gateway deletion request message to the other servers (809, 813).
  • the gateway deletion request message may include a synchronization index (number) of the first server 500-1.
  • the synchronization index may be a number that is updated when the gateway list is updated (ie, when the gateway is deleted).
  • the synchronization index may be a number in the range of 0 to (pow (2,32) -1).
  • the gateway deletion request message may include the number of gateways registered in the first server 500-1 and a list of gateways included in the first server 500-1.
  • the gateway deletion request message may be transmitted to the second server 500-2 to the n-th server 500-n included in the server list stored in the first server 500-1 (809). 813).
  • the second server 500-2 may identify the first server 500-1 that has transmitted the message.
  • the second server 500-2 may identify the first server 500-1 by using the IP of the transmission destination where the message is transmitted.
  • the second server 500-2 may load the gateway list stored in the second server 500-2.
  • the second server 500-2 may compare the first synchronization index included in the received message with the second synchronization index stored in the second server 500-2.
  • the second server 500-2 updates the gateway list stored in the second server 500-2 with the gateway list received through the message,
  • the second synchronization index may be updated.
  • the second server 500-2 may transmit a gateway deletion response message reflecting the processing result to the first server 500-1 (811).
  • Operations 809 and 813 may be performed with respect to the third server to the nth server 500-n in addition to the second server 500-2 included in the server list of the first server 500-1.
  • 9A, 9B, and 9C are flowcharts for describing an operation in which a node joins a group in an embodiment.
  • the full node 300 (full node not acting as a gateway) and the light node 400 included in the distributed network system 100 may join any one group operated by at least one gateway 301.
  • an operation of joining the group to the light node 400 will be described as an example, but the full node 300 may join the group by performing the same operation.
  • the write node 400 may include group subscription details.
  • the group subscription history may include, for example, information associated with a gateway that has been connected when there is a history of connection with at least one gateway of the distributed network system 100.
  • the write node 400 may inquire a group subscription history (901).
  • the group subscription history may include the address of at least one gateway.
  • the address may be understood as an address (eg, a public key, a wallet address) registered on the distributed network system 100 as an address of a gateway.
  • the group subscription history may include, for example, an address of the first gateway 301-1 and an address of the second gateway 301-2.
  • the light node 400 may first select the first gateway 301-1 in the group subscription history (903) and transmit a group join request message to the first gateway 301-1 (905).
  • the group join request message may include an address (eg, a wallet address) of the write node 400.
  • the first gateway 301-1 may check whether the write node 400 can join (907).
  • the first gateway 301-1 may check the address of the received light node 400 and check whether the light node 400 is acceptable.
  • the number of acceptable nodes for each gateway may be limited. The number may be preset according to the hardware environment and / or software policy of each gateway.
  • the first gateway 301-1 may store the address of the light node 400 in the node pool of the first gateway 301-1.
  • the first gateway 301-1 may generate a node ID corresponding to the light node 400 and store the node ID and the address of the light node 400 in the node pool.
  • the node ID and the address of the write node 400 may be mapped and stored.
  • the first gateway 301-1 cannot accept the light node 400, the light node 400 must request to join another group again.
  • the first gateway 301-1 may transmit a group join response message to the write node 400 with respect to the group join request message of the write node 400.
  • the group join response message may include success / failure for the group join request.
  • the node ID generated for the light node 400 may be included.
  • a group join response message including a failure (eg, null) response may be transmitted to the light node 400. (909).
  • the write node 400 parses the received group join response message and confirms the failure, the write node 400 may select a gateway other than the first gateway 301-1 from the group join history. If there are no other gateways in the group subscription details, the write node 400 may perform operations to be described later with reference to FIG. 9B.
  • the write node 400 may select the second gateway 301-2 included in the group subscription history (911).
  • the write node 400 may transmit a group join request message to the second gateway 301-2 (913).
  • the second gateway 301-2 may check the address of the received light node 400 and check whether the light node 400 is acceptable (915).
  • the second gateway 301-2 may store the address of the light node 400 in the node pool of the second gateway 301-2 when the light node 400 can be accommodated (917).
  • the second gateway 301-2 may generate a node ID corresponding to the light node 400 and store the node ID and the address of the light node 400 in the node pool.
  • the second gateway 301-2 may transmit a group join response message to the write node 400 with respect to the group join request message of the write node 400 (919).
  • the group join response message may include a response of success to the group join request, and may include a node ID for the write node 400.
  • the light node 400 may transmit a gateway information request message to any one of the servers 500 included in the server list. 950.
  • the gateway information request message may include at least one of IP information of the light node 400, port information of the light node 400, latitude information of the light node 400, and longitude information of the light node 400. have.
  • the server 500 may generate a candidate gateway list in response to the gateway information request message (953).
  • the server 500 may transmit a gateway information response message (955).
  • the gateway information response message may include the generated candidate gateway list and information on the number of candidate gateways.
  • the write node 400 may perform operations 901 to 919 described above with reference to FIG. 9A using the received candidate gateway list. If there is no group currently available to join, operations 951 to 955 may be repeatedly performed.
  • the light node 400 may obtain latitude information and / or longitude information as location information of the light node 400 (961).
  • the light node 400 may be a portable device (eg, smartphone, tablet PC). The position of the light node 400 may be changed in real time.
  • the write node 400 may transmit a gateway information request message including the latitude and / or longitude information to the server 500 (963).
  • a gateway information request message including the latitude and / or longitude information
  • information about a gateway to be connected to the server 500 may be requested.
  • the write node 400 may request information about a gateway to be connected to the server 500 based on the current location information at regular intervals.
  • the gateway information request message includes the number of gateways requested by the light node 400, the IP address of the light node 400, latitude information of the light node 400, and longitude information of the light node 400. can do.
  • the server 500 may register the light node 400 with the node standby pool (965).
  • the server 500 may operate a node standby pool to sequentially process the request.
  • operations of the server 500 may be performed by the grouping module 512 of the processor 510 of the server 500.
  • the server 500 may query the gateway list (967), and calculate the distance between the gateways included in the gateway list and the light node 400 (969). For example, the server 500 may calculate a distance between the two (eg, a distance in GPS coordinates) based on latitude and longitude information of the light node 400 and latitude and longitude information of the gateways. The server 500 may perform the calculation with respect to the gateways included in the gateway list, and determine the candidate gateways in the order of having a close distance to the light node 400. The server 500 may generate a candidate gateway list including the determined candidate gateways (971). The candidate gateway list may include the number of candidate gateways requested by the write node 400. The server 500 may transmit a gateway information response message including the candidate gateway list to the write node 400 (983).
  • a distance between the two eg, a distance in GPS coordinates
  • the server 500 may perform the calculation with respect to the gateways included in the gateway list, and determine the candidate gateways in the order of having a close distance to the light node 400.
  • FIG. 10 is a flowchart of an operation of synchronizing gateway lists between servers according to an embodiment.
  • the server 500 may share the gateway list included in the server 500 to other servers at predetermined intervals. Referring to FIG. 10, for example, a synchronization process between the first server 500-1 and the second server 500-2 is illustrated.
  • the second server 500-2 may transmit a synchronization request message for the gateway list to the first server 500-1 (1001).
  • the synchronization request message may include a synchronization index (number) and a gateway list stored in the second server 500-2.
  • the synchronization index may be a number that is updated when the gateway list is updated. For example, the synchronization index may be a number in the range of 0 to (pow (2,32) -1).
  • the first server 500-1 may compare the first synchronization index stored in the first server 500-1 with the second synchronization index received from the second server 500-2. If the second synchronization index is larger than the first synchronization index, the first server 500-1 updates the gateway list stored in the first server 500-1 with the gateway list received through the message, The first synchronization index may be updated (1003).
  • the first server 500-1 may transmit a synchronization request response message to the second server 500-2.
  • the synchronization request response message may include the processing result (success or failure) for the synchronization request.
  • Operations 1001 to 1005 may be performed between different servers included in the distributed network system 100 at predetermined intervals.
  • the newly added n-th server 500-n may perform an initial boot (1011) and transmit an initial synchronization request message to the first server 500-1, which is a neighbor server (1013). ).
  • the first server 500-1 may transmit an initial synchronization response message to the n-th server 500-n.
  • the initial synchronization response message may include information about servers included in the distributed network system 100.
  • the information about the servers may include a number of servers, a list of gateways stored in the servers, a number of gateways, and a synchronization index for the gateway list.
  • the n-th server 500-n may store information included in the message and perform synchronization.
  • 11 is an exemplary diagram illustrating an operation of generating a group secret key by the gateway 301 ('node group management apparatus' according to one embodiment).
  • the gateway 301 may function to manage some of the nodes participating in the blockchain network as a group.
  • the group secret key generation module 316 of the gateway 301 may generate a group secret key that can be used for double signing in addition to the secret key when the nodes in the group sign a transaction.
  • the gateway 301 may share with the nodes in its group and distribute the group public key to another group to be used for signature verification of the group secret key.
  • the gateway 301 stores information of nodes participating in its group in the node pool 335.
  • the node pool 335 may map and store index information for identifying each node in the group and public key information of each node. For example, when the first gateway 301 manages 100 nodes, the node pool 335 may map and store index information 1 to 100 of each 100 nodes and respective public keys.
  • the gateway 301 may select some of the public keys of the nodes stored in the node pool 335 to generate the group secret key. As illustrated in FIG. 11, the gateway 301 may randomly select a public key mapped to index information 1, 3, 25, and 99, or use the following example method.
  • the gateway 301 may select a public key having an index corresponding to a multiple of the quotient obtained by dividing the total number of nodes in the group by a predetermined natural number. For example, if the total number of nodes is 100, a public key mapped with an index of 14, 28, 42, 56, 50, 84, and 98, which is a multiple of 14 divided by a random natural number 7, may be selected.
  • the gateway 301 may convert each selected public key through a predetermined hash generation algorithm so that bit information consisting of only bits is output. For example, a bit stream consisting of 160 bits may be extracted by applying base58 decoding to each public key.
  • the gateway 301 performs a bitwise operation (for example, ⁇ , &, >>, ⁇ , or a combination thereof) on each bit string to form one synthesized bit string (FIG. 11, 160 bits). 1101001010011 ⁇ 00) can be generated.
  • a bitwise operation for example, ⁇ , &, >>, ⁇ , or a combination thereof
  • the gateway 301 may generate a group secret key by connecting the bit string consisting of time information to the synthesized bit string.
  • the time information bit string may use UNIX TIME.
  • the gateway 301 may connect an arbitrary bit string to the bit string of the time information so that the number of bits of the group secret key is the same as the bit number of the secret key.
  • the synthesized bit string is 160 bits, 96 bits must be concatenated, so the time information bit string can be configured as Currnet Time (32bit) x sysrandom (64bit).
  • the group secret key generation method is not limited to this example.
  • the gateway 301 generates a new group secret key at predetermined intervals or manages it by the gateway 301 in order to prevent the possibility of exposing the group secret key by malicious attack when one group secret key is continuously used.
  • a new group secret key can be generated and distributed to the nodes in the group.
  • the generation period of the group secret key should be selected in consideration of the communication delay (for example, 2 to 4 seconds) of messages transmitted and received between the gateways 301 because the group public keys generated from the group secret keys must be shared between the gateways 301. Can be. According to an embodiment, the generation period of the group secret key may be 5 to 60 seconds, but this number is only an example.
  • the group shared key generation module 316 of the gateway 301 may generate a group public key from a group secret key through a predetermined function.
  • the predetermined function is an irreversible function that can generate a group public key based on the group secret key, but cannot generate a group secret key based on the first group public key, for example, an elliptic curve multiplication function. Curve Digital Signature Algorithm (ECDSA), but is not limited thereto.
  • FIG. 12 is a flowchart illustrating an operation of generating and distributing a group secret key and a group public key by the gateway 301 according to an embodiment.
  • the gateway 301 selects a node to be included in the group, or a method of determining the group by receiving a request from the node to join the group may refer to the operations of FIGS. 9A to 9C described above.
  • the method of forming a group consisting of a plurality of nodes is not limited to this, and various methods may be used.
  • a gateway for managing the first group is referred to as a first group gateway 301-1
  • a node included in the first group is referred to as a first group node 600-1
  • a gateway for managing a second group is referred to.
  • the operation of the gateway 301 generating and distributing the group secret key and the group public key will be described by referring to the group gateway 301-2 and the node included in the second group as the second group node 600-2. do.
  • the first group gateway 301-1 may generate a first group secret key and a first group public key based on information of nodes included in the first group (2001).
  • the first group gateway 301-1 may distribute a first group secret key (or may include a first group public key) to the first group node (2003).
  • One of the first group nodes, the first group node a (600-1a) may receive the first group secret key and generate the first group public key by itself.
  • the first group gateway 301-1 may distribute the first group public key to an external group (2005).
  • the second group gateway 301-2 managing the second group of the external groups may receive and store the first group public key (2007).
  • the second group gateway 301-2 may distribute the first group public key to the second group node (2009).
  • the first group node a (600-2a) having a transaction verification function among the second group nodes may store the first group public key and use it to verify a transaction generated in the first group.
  • the node b may transmit a group join request to the first group gateway 301-1 (2011).
  • the first group gateway 301-1 may approve a group join request of the node b, and may store information of the first group node b 600-1b in the node pool 335 upon approval (2013).
  • the group join operation may be performed through the operations of FIGS. 9A to 9C, but is not limited thereto.
  • the first group gateway 301-1 may newly generate a first group secret key and a first group public key based on the newly changed information of the node pool 335 (2015).
  • the first group gateway 301-1 may distribute a first group secret key (or may include a first group public key) to the first group node (2017).
  • the first group node a (600-1a) and the second group node b corresponding to the first group node may generate the first group public key by receiving the first group secret key.
  • the first group gateway 301-1 may distribute the first group public key to an external group (2019).
  • the second group gateway 301-2 managing the second group of the external groups may receive and store the first group public key (2021).
  • the second group gateway 301-2 may distribute the first group public key to the second group node (2023).
  • the first group node a (600-2a) having a transaction verification function among the second group nodes may store the first group public key and use it to verify a transaction generated in the first group.
  • the first group gateway 301-1 may generate the first group secret key and the first group public key periodically even if no change is made to the group.
  • FIG. 13 is a flowchart illustrating a situation in which a node can verify and a situation in which verification cannot be performed according to a selection of a group secret key according to an embodiment.
  • the second group gateway 301-2 may generate a second group secret key a and a second group public key a based on information of nodes included in the second group (2201).
  • the second group gateway 301-2 may distribute a second group secret key a (or may include a second group public key a) to the second group node (2203).
  • the first group node a 600-2a which is one of the second group nodes, may generate the second group public key a by receiving the second group secret key a.
  • the second group gateway 301-2 may distribute the second group public key a to an external group (2205).
  • the first group gateway 301-1 managing the first group of the external groups may receive and store the second group public key a (2207).
  • the second group gateway 301-2 may distribute the second group public key a to the first group node (2209).
  • the second group gateway 301-2 changes the group information or the generation cycle arrives, so that the second group gateway 301-2 receives the second group secret key b and the second group public key b based on the information of the nodes included in the second group.
  • the second group secret key b may be distributed to the second group node (2211) (2213).
  • Each large box represents the current state of the group public key distributed in the first group, second group, and third group.
  • the first to sixth periods in the vertical direction refer to a period for generating the group key, which means the latest generated group public key.
  • A-1 to A-6 are group public keys generated in the first group
  • B-1 to B-6 are group public keys generated in the second group
  • C-1 to C-6 are generated in the third group.
  • the first group generated the A-6 group public key, but due to the delay of distribution 2219, the second group has not yet reached the A-6 group public key, and the third group. Has not yet reached the A-5 and A-6 group public keys. Therefore, even if the node of the first group has signed with the group secret key of A-6, the nodes of the second group and the third group cannot verify the transaction. In addition, even if the node of the first group has signed with the group secret key of A-5, the node of the third group cannot verify the transaction. Accordingly, the execution delay of the transaction may occur.
  • the node of the first group can sign the transaction using the group secret key already distributed in the blockchain network even if the group secret key is recently distributed.
  • the node receives the distributed group secret key time information, stores a predetermined number of group secret keys in the latest order, and generates a transaction from the latest stored group secret device, as in operation 2217 of FIG. 15.
  • the signature can be prevented. Can be.
  • 15 is a conceptual diagram of transaction double signature based on group secret key and transaction double verification based on group public key, according to an embodiment.
  • the node may generate second signature information that hashes the message content and the group secret key together with the first signature information that hashes the message content and the secret key together.
  • the node may include a message, first signature information, second signature information, public key, and group public key as a structure of a transaction to be generated in the blockchain network.
  • a transaction that is distributed to the blockchain network might be 1 027d774e8a4f7e03d226dcab58298fa8a0acc
  • 78afeb309d7195cb930f55dccaf2234603a6960346cc0698247d4178f521e0c5e43f1b28b3b647b9413e0058f6108f6ddd it may include a hexadecimal column in which the order of information is arranged according to a predetermined convention.
  • the node receiving the transaction can classify the hexadecimal information in a predetermined format and stack it on the stack.
  • the node that received the transaction corresponds to ⁇ Sig-Wallet>.
  • the node receiving the transaction verifies that the first signature is signed by the correct private key through the public key, and further verifies that the second signature is signed by the correct group private key through the group public key, Finally, we can verify that the transaction is correct.
  • the secret key and the group secret key are used together in the transaction signature, even if the secret key is hacked, a configuration requesting the signature of the group secret key can be prevented, thereby preventing damage caused by the hack. .
  • the reliability of the group key-based transaction signature can be increased.
  • the possibility of exposing the group secret key can be minimized by periodically generating the group secret key or whenever the group is changed.
  • the node when a node generates a transaction, the node performs a signature through a group secret key distributed all over the blockchain network, thereby preventing a transaction verification error due to a distribution delay.
  • the order of operations described with reference to FIGS. 11 to 15 is merely an example, and the time series order is not limited and may be changed logically according to design.
  • the operation of the gateway 301 described with reference to FIGS. 11 to 15 may be understood as an operation performed by a module included in the processor of FIG. 4.
  • the operation of the node described with reference to FIGS. 11 to 15 may be understood as an operation performed by a module included in the processor of the full node of FIG. 4 or the write node of FIG. 5.
  • a or B at least one of A and B”, “at least one of A or B,” “A, B or C,” “at least one of A, B and C,” and “A And phrases such as “at least one of B, or C” may include all possible combinations of items listed together in the corresponding one of the phrases.
  • Terms such as “first”, “second”, or “first” or “second” may be used merely to distinguish a component from other corresponding components, and to separate the components from other aspects (e.g. Order).
  • Some (eg, first) component may be referred to as “coupled” or “connected” to another (eg, second) component, with or without the term “functionally” or “communically”. When mentioned, it means that a component can be connected directly to another component (eg, by wire), wirelessly, or via a third component.
  • module may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit.
  • a module can be a unit or part of a minimum of parts that perform an integrally configured part or one or more functions.
  • the module may be implemented in the form of an application-specific integrated circuit (ASIC).
  • ASIC application-specific integrated circuit
  • Various embodiments of the present disclosure may be implemented as software (eg, a program) including one or more instructions stored on a storage medium (eg, a memory) that can be read by a machine (eg, an electronic device).
  • Storage media may include random access memory (RAM), memory buffers, hard drives, databases, erasable programmable read-only memory (EPROM), electrically erasable read-only memory (EEPROM), read-only memory (ROM), and / or the like. It may include.
  • the processor of embodiments of the present disclosure may call and execute at least one of the one or more instructions stored from the storage medium. This enables the device to be operated to perform at least one function in accordance with at least one command called.
  • These one or more instructions may include code generated by a compiler or code that may be executed by an interpreter.
  • the processor may be a general purpose processor, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a digital signal processor (DSP), and / or the like.
  • the device-readable storage medium may be provided in the form of a non-transitory storage medium.
  • 'non-transitory' means only that the storage medium is a tangible device and does not contain a signal (e.g. electromagnetic wave), which is the term used when the data is stored semi-permanently on the storage medium. It does not distinguish cases where it is temporarily stored.
  • a signal e.g. electromagnetic wave
  • the method according to various embodiments disclosed in the present disclosure may be provided in a computer program product.
  • the computer program product may be traded between the seller and the buyer as a product.
  • the computer program product may be distributed in the form of a device-readable storage medium (eg compact disc read only memory (CD-ROM)), or through an application store (eg play store) or two user devices (eg It can be distributed (e.g., downloaded or uploaded) directly, online between smartphones).
  • a device-readable storage medium eg compact disc read only memory (CD-ROM)
  • an application store eg play store
  • two user devices eg It can be distributed (e.g., downloaded or uploaded) directly, online between smartphones).
  • at least a portion of the computer program product may be stored at least temporarily or temporarily created on a device-readable storage medium such as a server of a manufacturer, a server of an application store, or a memory of a relay server.
  • each component eg, module or program of the described components may include a singular or plural entity.
  • one or more of the aforementioned components or operations may be omitted, or one or more other components or operations may be added.
  • a plurality of components eg, a module or a program
  • the integrated component may perform one or more functions of the component of each of the plurality of components the same as or similar to that performed by the corresponding component of the plurality of components prior to integration.
  • operations performed by a module, program, or other component may be executed sequentially, in parallel, repeatedly, or heuristically, or one or more of the operations may be executed in a different order, omitted, or Or one or more other operations may be added.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

일 실시예에 따른 노드 그룹 관리 장치는 분산 데이터베이스를 공유하는 블록체인 네트워크를 구성하는 노드 중 일부 노드가 속한 제1 그룹을 관리하고 -상기 블록체인 네트워크에 참여하는 모든 노드는 각각 비밀키 및 공개키를 보유함-, 상기 블록체인 네트워크와 통신하는 통신 인터페이스; 상기 제1 그룹의 노드에 관한 정보 및 프로세서의 동작 수행에 관한 명령어를 저장하는 하나 이상의 메모리- 상기 제1 그룹의 노드에 관한 정보는 상기 제1 그룹의 노드 각각의 공개키를 포함함-; 및 상기 명령어를 통해 동작하도록 상기 하나 이상의 메모리와 연결되고 상기 제1 그룹의 노드가 트랜잭션을 생성하는 경우 상기 트랜잭션에 상기 비밀키의 서명과 함께, 상기 제1 그룹의 노드에 관한 정보를 기초로 상기 트랜잭션에 추가적인 서명을 수행하도록 하는 그룹 비밀키를 생성하여 상기 제1 그룹의 노드가 공통적으로 보유하도록 상기 그룹 비밀키를 상기 제1 그룹에 배포하는 동작을 수행하는 하나 이상의 프로세서를 포함한다.

Description

블록체인 네트워크 상에서 그룹키 기반의 이중 서명 트랜잭션 구조를 구성하는 노드 그룹 관리 장치 및 컴퓨팅 장치
본 문서의 실시예들은 블록체인 네트워크 상에서 그룹키를 기반으로 이중적으로 서명과 검증이 요구되는 트랜잭션 구조를 구성하여 보안성을 강화시키는 기술에 관한 것이다.
블록체인 시스템은 정보가 담겨있는 블록이 체인 형태로 이어진 블록체인을 분산형 데이터베이스로서 운영하여, 블록체인 네트워크를 구성하는 노드들이 공통된 정보를 공유할 수 있게 한다. 이러한 블록체인에 정보를 기록하거나 변경을 가하기 위해 노드는 네트워크 상에 트랜잭션을 발생시키고, 다른 노드들에 의해 해당 트랜잭션이 올바른 것인지 검증받는 과정을 거치게 된다. 이러한 트랜잭션의 발생 및 검증은 각각의 노드가 보유하는 비밀키(private key) 및 공개키(public key)에 의해 수행된다.
각 노드는 자신의 공개키만 블록체인 네트워크 상에 노출시키고, 전달하고자 하는 정보를 자신의 비밀키로 서명하여, 전달하고자 하는 정보와 서명을 묶은 트랜잭션을 다른 노드에 전파한다. 이를 수신한 다른 노드는 공개키를 통해 서명을 복호화 하여, 해당 트랜잭션이 올바른 자에 의해 서명된 것인지를 체크하여 트랜잭션의 검증 과정을 거친다.
공개키는 비밀키를 기반으로 생성되지만, 비가역함수를 통해 생성되기 때문에 공개키가 알려진다 하여도 그로부터 비밀키를 복원해내기 어렵다. 그러나, 비밀키 자체가 해킹된다면 해킹한 자가 해당 계정에서 원하는 트랜잭션을 모두 발생시킬 수 있다는 치명적인 문제가 있다. 이 때문에, 해킹한 자가 계정에 보유된 모든 암호화폐를 다른 곳으로 이체시키는 악의의 트랜잭션을 발생시켜 블록에 기록시킨다면, 블록체인 상에서는 이를 다시 돌이킬 수 없기에 매우 큰 피해로 이어지게 된다.
하지만, 비밀키는 한번 정해지면 변경이 불가하기 때문에, 단 한 번의 유출만으로 곧바로 계정을 교체해야 하며, 유출되었다는 사실을 알기도 전에 이미 돌이킬 수 없는 심각한 피해가 발생하는 경우가 대다수이다.
이와 같이, 비밀키 하나만으로 보호되는 블록체인 계정은 비밀키 자체의 해킹이라는 치명적인 약점이 있어, 계정을 보다 효과적으로 보호할 수 있는 새로운 대안이 필요하다.
본 문서의 실시예들은 복수의 노드로 이루어진 그룹의 정보를 기반으로 그룹 내의 노드끼리만 공유되는 그룹 비밀키를 생성하는 기술을 통해 상술한 문제를 해결하고자 한다. 이때 생성되는 그룹 비밀키는 그룹 내부의 노드 정보를 관리하는 신뢰성이 확보된 노드에 의해 생성되고, 그룹 비밀키로 인해 보안성 향상이라는 같은 이익을 공유하는 그룹 내부의 노드 입장에서는 그룹 비밀키를 유출시킬 실익이 없으며, 그룹 외부의 노드 입장에서는 다른 그룹의 정보를 알 수 없기 때문에 그룹 비밀키를 유추해 낼 수 없도록 설계될 수 있다.
또한, 본 문서의 실시예들은 설령 그룹 비밀키가 유출된다고 하여도, 그룹 비밀키가 주기적으로 갱신되고, 또한 노드 그룹 내에 변경이 일어난 경우에 갱신되도록 하는 기술을 통해, 해킹 피해가 발생하는 것을 방지할 수 있다. 더하여, 해킹한 자가 악의적인 트랜잭션 발생을 시도하는 경우, 나머지 하나의 키를 통한 서명이 추가적으로 요구되므로 계정 소유자가 해킹을 인지한 후 대안을 준비할 시간을 확보시킬 수 있다.
이와 같이, 본 문서의 실시예들은 트랜잭션 서명과 검증이 이중적으로 요구되는 구조를 구성하여 블록체인 네트워크의 보안성을 향상시키고자 한다.
일 실시예에 따른 노드 그룹 관리 장치는 분산 데이터베이스를 공유하는 블록체인 네트워크를 구성하는 노드 중 일부 노드가 속한 제1 그룹을 관리하고 -상기 블록체인 네트워크에 참여하는 모든 노드는 각각 비밀키 및 공개키를 보유함-, 상기 블록체인 네트워크와 통신하는 통신 인터페이스; 상기 제1 그룹의 노드에 관한 정보 및 프로세서의 동작 수행에 관한 명령어를 저장하는 하나 이상의 메모리- 상기 제1 그룹의 노드에 관한 정보는 상기 제1 그룹의 노드 각각의 공개키를 포함함-; 및 상기 명령어를 통해 동작하도록 상기 하나 이상의 메모리와 연결되고, 상기 제1 그룹의 노드가 트랜잭션을 생성하는 경우 상기 트랜잭션에 상기 비밀키의 서명과 함께, 상기 제1 그룹의 노드에 관한 정보를 기초로 상기 트랜잭션에 추가적인 서명을 수행하도록 하는 그룹 비밀키를 생성하여, 상기 제1 그룹의 노드가 공통적으로 보유하도록 상기 그룹 비밀키를 상기 제1 그룹에 배포하는 동작을 수행하는 하나 이상의 프로세서를 포함할 수 있다.
일 실시예에 따른 컴퓨팅 장치는 분산 데이터베이스를 공유하는 블록체인 네트워크를 구성하는 노드를 수행하고 -상기 블록체인 네트워크에 참여하는 모든 노드는 각각 비밀키 및 공개키를 보유함-, 상기 블록체인 네트워크와 통신하는 통신 인터페이스; 상기 하나의 노드가 속한 제1 그룹을 관리하는 제1항의 노드 그룹 장치에 관한 정보, 상기 노드 그룹 장치가 시간이 흐름에 따라 배포한 복수의 그룹 비밀키, 및 프로세서의 동작 수행에 관한 명령어를 저장하는 하나 이상의 메모리-상기 복수의 그룹 비밀키는 시간 정보를 포함함-; 및 상기 명령어를 통해 동작하도록 상기 하나 이상의 메모리와 연결되고, 트랜잭션을 생성하는 경우 상기 시간 정보를 참조하여, 상기 복수의 그룹 비밀키 중 가장 최신으로 저장된 그룹 비밀키로부터 기 설정된 주기 이전에 생성된 그룹 비밀키를 이용한 서명을 상기 트랜잭션에 포함시키는 동작을 수행하는 하나 이상의 프로세서를 포함할 수 있다.
일 실시예에 따른 노드 그룹 관리 방법은 분산 데이터베이스를 공유하는 블록체인 네트워크를 구성하는 노드 및 노드 그룹 관리 장치에 의해 수행되고-상기 블록체인 네트워크를 구성하는 모든 노드는 각각의 비밀키 및 공개키를 보유함-, 상기 노드 그룹 관리 장치가 제1 그룹의 노드에 관한 정보를 상기 제1 그룹의 노드로부터 수신하는 단계- 상기 제1 그룹은 상기 장치가 관리하는 노드들이 포함된 그룹이고, 상기 제1 그룹의 노드에 관한 정보는 상기 제1 그룹의 노드 각각의 공개키를 포함함-; 상기 노드 그룹 관리 장치가 상기 제1 그룹의 노드가 트랜잭션을 생성하는 경우 상기 제1 그룹의 노드에 관한 정보를 기초로 상기 비밀키와 함께 추가적인 서명으로 사용되는 그룹 비밀키를 생성하는 단계; 및 상기 노드 그룹 관리 장치가, 상기 제1 그룹의 노드가 공통적으로 보유하도록 상기 그룹 비밀키를 상기 제1 그룹의 노드에 배포하는 단계를 포함할 수 있다.
상술한 실시예들에 따르면, 트랜잭션 서명에 비밀키와 그룹 비밀키를 함께 사용하기 때문에, 비밀키가 해킹되었다고 하더라도 그룹 비밀키의 서명을 요청하는 구성을 통해 해킹으로 인한 피해를 방지할 수 있다.
또한, 신뢰성이 확보된 게이트웨이를 통해 그룹 비밀키와 그룹 공개키의 생성 및 배포하여 그룹키 기반의 트랜잭션 서명에 대한 신뢰도를 높일 수 있다.
더하여, 그룹 비밀키의 생성을 주기적으로 수행하고, 또는 노드 그룹에 변경이 일어날 경우마다 수행함으로써, 그룹 비밀키의 노출 가능성을 최소화할 수 있다.
아울러, 노드가 트랜잭션을 생성할 경우, 블록체인 네트워크 상에 모두 배포된 그룹 비밀키를 통한 서명을 수행함으로써, 통신 딜레이로 인한 트랜잭션 검증 오류를 방지할 수 있다.
이 외에, 본 문서를 통해 직접적 또는 간접적으로 파악되는 다양한 효과들이 제공될 수 있다.
도 1은 일 실시예에 따른 분산 네트워크 시스템의 블록도이다.
도 2는 일 실시예에 따른 블록체인 구조를 설명하기 위한 도면이다.
도 3은 일 실시예에 따른 분산 네트워크 시스템에 포함되는 노드들의 종류를 설명하기 위한 도면이다.
도 4는 일 실시예에 따른 풀 노드에 대한 블록도를 나타낸다.
도 5는 일 실시예에 따른 라이트 노드에 대한 블록도를 나타낸다.
도 6은 일 실시예에 따른 서버에 대한 블록도를 나타낸다.
도 7은 일 실시예에 따른 게이트웨이의 등록 과정을 설명하기 위한 흐름도이다.
도 8은 일 실시예에 따른 게이트웨이의 관리 동작을 설명하기 위한 흐름도이다.
도 9a, 도 9b 및 도 9c는 일 실시예에서 노드가 그룹에 가입하는 동작을 설명하기 위한 흐름도이다.
도 10은 일 실시예에 따른 서버들 간의 게이트웨이 목록을 동기화하는 동작의 흐름도이다.
도 11은 일 실시예에 따라 게이트웨이가 그룹 비밀키를 생성하는 동작의 예시도이다.
도 12는 일 실시예에서 게이트웨이가 그룹 비밀키 및 그룹 공개키를 생성 및 배포하는 동작을 설명하기 위한 흐름도이다.
도 13은 일 실시예에서 노드가 그룹 비밀키의 선택에 따라 검증이 가능한 상황과 검증이 불가한 상황을 설명하기 위한 흐름도이다.
도 14는 일 실시예에 따라 각 그룹에 배포된 그룹 공개키 상태를 나타내는 예시도이다.
도 15는 일 실시예에 따른 그룹 비밀키 기반의 트랜잭션 이중 서명 및 그룹 공개키 기반의 트랜잭션 이중 검증의 개념도이다.
도면의 설명과 관련하여, 동일 또는 유사한 구성요소에 대해서는 동일 또는 유사한 참조 부호가 사용될 수 있다.
이하, 다양한 실시예가 첨부된 도면을 참조하여 기재된다. 그러나, 이는 특정한 실시 형태에 대해 한정하려는 것이 아니며, 실시예의 다양한 변경(modification), 균등물(equivalent), 및/또는 대체물(alternative)을 포함하는 것으로 이해되어야 한다.
도 1은 일 실시예에 따른 분산 네트워크 시스템(100)의 블록도이다.
도 1을 참조하면, 일 실시예에 따른 분산 네트워크 시스템(100)은 복수의 컴퓨팅 장치(110, 120, 130, 140)를 통하여 구현될 수 있다. 도 1에서 4개의 컴퓨팅 장치(110, 120, 130, 140)가 도시 되었으나, 이에 한정되지 않고 분산 네트워크 시스템(100)은 도시되지 않은 임의의 수의 컴퓨팅 장치를 더 포함할 수 있다.
네트워크(105)는 유선 네트워크 및/또는 무선 네트워크를 포함할 수 있다. 예를 들어, 네트워크(105)는 LAN(local area network), WAN(wide area network), 가상 네트워크, 원격 통신 네트워크 중 적어도 하나일 수 있다.
분산 네트워크 시스템(100)은 컴퓨팅 장치들(110, 120, 130, 140)이 네트워크(105)를 통해 동작 가능하도록 서로 연결되어, 동일한 정보를 갖는 분산 데이터베이스를 공유하는 피투피 네트워크인 블록체인 네트워크를 구성할 수 있다.
컴퓨팅 장치(110, 120, 130, 140)들은 분산 데이터베이스의 상태를 변화시키기 위해 수행하는 작업의 단위인 트랜잭션(transaction)을 분산 네트워크 시스템(100)상에 발생시킬 수 있다. 컴퓨팅 장치(110, 120, 130, 140)들은 분산 네트워크 시스템(100)에서 발생하는 트랜잭션을 검증 및 실행하고, 트랜잭션의 기록을 블록체인(blockchain) 구조 형태로 저장하여, 분산 데이터베이스를 관리할 수 있다.
각각의 컴퓨팅 장치(110, 120, 130, 140)는 트랜잭션을 발생시키고, 트랜잭션의 무결성을 검증하기 위해 블록체인 계정 정보를 가질 수 있다. 블록체인 계정 정보는 비밀키(private key)와 공개키(public key) (이하 통칭하는 경우'개인키'로 지칭)를 포함할 수 있다. 비밀키는 트랜잭션이 올바른 자에 의해 발생한 것을 검증하도록 하기 위한 디지털 서명 수단으로서, 트랜잭션에 포함될 메시지와 비밀키를 해싱하여 생성할 수 있다.
공개키는 사용자의 계정 주소(account address)로 기능하거나, 트랜잭션에 포함된 디지털 서명이 올바른 사용자의 비밀키에 의해 생성된 것임을 검증하기 위한 수단으로 기능할 수 있다.
본 문서의 실시예에 따르면, 컴퓨팅 장치(110, 120, 130, 140)들은 개인키와 더불어, 이중적으로 트랜잭션의 서명 및 검증 역할에 사용되는 그룹 비밀키(group private key) 및 그룹 공개키(group public key) (이하 통칭하는 경우'그룹키'로 지칭)를 보유할 수 있다. 그룹키에 대한 보다 자세한 설명은 도 11 내지 도 15와 함께 후술하기로 한다.
컴퓨팅 장치(110, 120, 130, 140)들은 트랜잭션이 발생하면, 발생한 트랜잭션의 무결성을 검증하고, 분산 네트워크 시스템(100)에서 약속된 합의 알고리즘(예: POW, POS, DPOS 등)에 기초해 기 생성된 블록에 이어질 새로운 블록을 생성하며, 새로이 생성된 블록은 다른 컴퓨팅 장치(110, 120, 130, 140)들에게 전파되면서 트랜잭션이 실행될 수 있다. 블록은 복수의 트랜잭션 정보를 포함할 수 있다.
도 2는 일 실시예에 따른 블록체인 구조를 설명하기 위한 도면이다.
도 2의 (1)을 참조하면, 블록체인은 블록 단위로 저장된 데이터들이 선형적으로 연결될 수 있다. 각 블록은 이전 블록(예를 들어, ‘블록2’의 이전 블록은 ‘블록1’)을 가리킴으로써 연결될 수 있다. 다만, 블록의 연결 형태가 이러한 예시에 한정되는 것은 아니다.
도 2의 (2)를 참조하면, 블록(210)은 헤더(header)(220)와 바디(body)(230)로 구성될 수 있다.
헤더(220)에 저장된 데이터들은 해당 블록(210)에 대한 요약 정보로 이해될 수 있다. 헤더(220)는 소프트웨어의 버전 정보인 소프트웨어 버전, 이전 블록의 헤더의 해시 값으로서 이전 블록을 가리키는 해시 포인터 역할을 하는 이전 블록 해시, 트랜잭션들을 요약한 정보인 머클 루트(Merkle Root), 블록(210)이 생성된 날짜 및 시간인 타임 스탬프를 포함할 수 있다. 블록 해시 값은 블록(210)의 헤더(220)에 저장된 데이터들을 기초로 계산될 수 있다. 다음 블록은 이전 블록의 블록 해시 값을 저장함으로써 이전 블록을 가리킬 수 있다. 이에 따라 분산 네트워크 시스템(100)은 블록체인 네트워크 시스템으로 호칭될 수 있다.
바디(230)는 블록(210) 내에 저장 및 보존의 대상이 되는 데이터인 트랜잭션들을 포함하는 트랜잭션 목록 및 블록(210)에 포함된 트랜잭션의 총 개수인 트랜잭션 개수를 포함할 수 있다. 예를 들어, 트랜잭션은 거래 내역일 수 있으나, 예시일 뿐 이에 한정되지 않는다.
컴퓨팅 장치(110)는 프로세서(111) 및 메모리(112)를 포함할 수 있다. 예를 들어, 메모리(112)는 RAM(random access memory), 메모리 버퍼, 하드 드라이브, 데이터베이스, EPROM(erasable programmable read-only memory), EEPROM(electrically erasable read-only memory), ROM(read-only memory) 및/또는 등등을 포함할 수 있다.
프로세서(111)는 범용 프로세서, FPGA(Field Programmable Gate Array), ASIC(Application Specific Integrated Circuit), DSP(Digital Signal Processor) 및/또는 등등일 수 있다.
컴퓨팅 장치(110, 120, 130, 140)의 하나 이상의 부분은 하드웨어 기반 모듈(예를 들어, DSP(digital signal processor), FPGA(field programmable gate array)) 및/또는 소프트웨어 기반 모듈(예를 들어, 메모리에 저장되고 및/또는 프로세서에서 실행되는 컴퓨터 코드의 모듈)을 포함할 수 있다. 일부 실시예에서, 컴퓨팅 장치(110, 120, 130, 140)와 연관된 하나 이상의 기능(예를 들어, 프로세서(111,121,131,141)와 연관된 기능)은 하나 이상의 모듈에 포함될 수 있다.
컴퓨팅 장치(110)의 메모리(112)는 분산 데이터베이스(114)를 포함할 수 있다. 컴퓨팅 장치들(110, 120, 130, 140)은 네트워크(105)를 통하여 분산 데이터베이스(114, 124, 134, 144)를 구현할 수 있다. 분산 데이터베이스(114, 124, 134, 144)는 복수 개의 컴퓨팅 장치(110, 120, 130, 140)들이 같은 정보를 공유하는 공공 원장(public ledger)으로 이해될 수 있다. 프로세서(111)는 다른 컴퓨팅 장치로부터 트랜잭션(transaction)(예: 분산 데이터베이스의 데이터를 변경시키기 위한 메시지)과 연관된 동기화 데이터 등등을 수신하는 것에 응답하여 분산 데이터베이스(114)를 업데이트하기 위해 모듈, 기능 및/또는 프로세스를 실행하도록 구성될 수 있다.
도 3은 일 실시예에 따른 분산 네트워크 시스템(100)에 포함되는 노드들의 종류를 설명하기 위한 도면이다.
도 3을 참조하면, 분산 네트워크 시스템(100)에 포함되는 컴퓨팅 장치들(예: 도 1의 컴퓨팅 장치들(110, 120, 130, 140)) 각각은 노드(node)로 이해될 수 있다. 분산 네트워크 시스템(100)에 포함되는 노드들은 풀 노드(full node)(300)와 라이트 노드(light node)(400)로 구분될 수 있다.
풀 노드(300)는, 블록체인(200)에 포함되는 모든 정보(예: 헤더(220) 정보 및 바디(230) 정보)를 실시간으로 동기화하고 유지하는 노드이다. 라이트 노드(400)는 트랜잭션 기능(예: 지갑 기능)을 수행할 수 있는 노드이다. 라이트 노드(400)는 트랜잭션을 발생시키고, 발생한 트랜잭션을 네트워크(105)를 통하여 이웃 노드에게 전파할 수 있다. 일부 실시예에서, 라이트 노드(400)는 블록체인(300)에 포함되는 일부 정보(예: 헤더(220) 정보)만을 가지고, 생성된 블록에 대한 검증을 수행할 수도 있다.
이하, 풀 노드(300)와 라이트 노드(400)는 분산 네트워크 시스템(100)에 포함되는 노드(600)로 통칭될 수 있다.
분산 네트워크 시스템(100)에 포함된 노드들은 위치 정보에 기초하여 서로 다른 또는 동일한 그룹에 소속될 수 있다. 위치적으로 가까운 곳에 위치한 노드들은 같은 그룹으로 분류될 수 있다.
그룹은 분산 네트워크 시스템(100)과 통신하는 적어도 하나 이상의 서버(도 6의 500)에 의하여 결정될 수 있다. 이하 하나의 서버(500)로 설명하나, 복수의 서버들(500)이 그룹의 분류를 수행할 수 있다. 서버(500)는 노드들의 위치 정보를 기초로, 인접한 노드를 같은 그룹으로 분류할 수 있다. 이에 따라 상호간에 통신을 자주 수행하는 이웃 노드들이 한 그룹에 속하게 되고, 통신의 효율성이 증가될 수 있다. 서버(500)는 서드 파티에 의하여 운영될 수 있다.
풀 노드(300)의 적어도 일부는 게이트웨이(gateway 또는 GW, 본 문서의 일부에서'노드 그룹 관리 장치'로도 지칭됨)(301)로 동작할 수 있다. 게이트웨이(301)는 블록(210)을 생성할 수 있고, 하나의 그룹을 관리할 수 있다. 게이트웨이(301)는 블록(210)을 생성함으로써 블록 보상을 수령하고, 수령한 블록 보상을 자신이 속한 그룹의 노드들에게 분배할 수 있다. 서로 다른 게이트웨이(301)는 서로 다른 그룹을 관리할 수 있다. 게이트웨이(301)는 그룹 비밀키 및 그룹 공개키를 생성할 수 있고, 같은 그룹 내의 노드에 그룹 비밀키를 공유하고, 그룹의 외부에 그룹 공개키를 배포할 수 있다.
도 3에서, 그룹 1은 4개의 풀 노드(300)와 6개의 라이트 노드(400)를 포함하고 있다. 4개의 풀 노드(300) 중 1개의 풀 노드(300)가 게이트웨이(301)로 동작할 수 있다. 게이트웨이(301)는 그룹 1에 소속된 노드들에 대한 정보를 가질 수 있다. 게이트웨이(301)는 블록 보상을 수령하면 그룹 1에 소속된 노드들에게 블록 보상을 분배할 수 있다. 분산 네트워크 시스템(100)은 하나 이상의 그룹을 가질 수 있고, 각각의 그룹은 적어도 하나의 게이트웨이(301)를 가질 수 있다.
그룹 1를 비롯한 각 그룹의 그룹 구성 및 각 노드의 개수는 예시적인 것에 불과하며, 게이트웨이(301)로 동작 가능한 하나의 풀 노드를 제외하고 풀 노드(300)의 개수 및 라이트 노드(400)의 개수는 임의로 정해질 수 있다. 일 실시예에 따라, 하나의 그룹에 포함되는 노드들의 총 개수는 최대 512개일 수 있으나, 예시일 뿐 이에 한정되지 않는다.
도 4는 일 실시예에 따른 풀 노드(300)에 대한 블록도를 나타낸다.
도 4를 참조하면, 풀 노드(300)는 통신 인터페이스(305), 프로세서(310), 메모리(320)를 포함할 수 있다. 풀 노드(300)는 통신 인터페이스(305)를 통하여 분산 네트워크 시스템(100)에 포함되는 노드들 및 서버(500)와 통신을 수행할 수 있다.
프로세서(310)는 트랜잭션 생성모듈(312) 및 트랜잭션 검증모듈(314)을 포함할 수 있다.
또한, 풀 노드(300)가 게이트웨이(301)로 동작하는 경우, 프로세서(310)는 그룹 비밀키 생성모듈(316) 및 그룹 공개키 생성모듈(318)을 더 포함할 수 있다.
프로세서(310)는 메모리(320)에 저장된 명령어들을 실행하여 트랜잭션 생성모듈(312), 트랜잭션 검증모듈(314), 그룹 비밀키 생성모듈(316) 및 그룹 공개키 생성모듈(318) 중 적어도 하나를 구동시킬 수 있다. 트랜잭션 생성모듈(312), 트랜잭션 검증모듈(314), 그룹 비밀키 생성모듈(316) 및 그룹 공개키 생성모듈(318) 각각은 지갑 프로그램(328)에 포함된 명령어들이 실행되어 구동될 수 있으나 이에 한정되지 않는다.
트랜잭션 생성모듈(312), 트랜잭션 검증모듈(314), 그룹 비밀키 생성모듈(316) 및 그룹 공개키 생성모듈(318) 각각은 하드웨어, 소프트웨어 또는 이들의 조합으로 구현될 수도 있다. 트랜잭션 생성모듈(312), 트랜잭션 검증모듈(314), 그룹 비밀키 생성모듈(316) 및 그룹 공개키 생성모듈(318) 각각에 의해 수행되는 동작은 프로세서(310)에 의해 수행되는 동작으로 이해될 수 있다.
트랜잭션 생성모듈(312)은 블록 내에 저장 및 보존의 대상이 되는 데이터(예: 거래 내역)를 블록에 포함시킬 것을 요청하는 트랜잭션을 생성할 수 있다. 트랜잭션 생성모듈(312)은 비밀키를 이용한 전자서명과 그룹키를 이용한 디지털 서명을 트랜잭션에 포함시킬 수 있다.
트랜잭션 검증모듈(314)은 스스로 생성한 트랜잭션 또는 다른 노드로부터 수신한 트랜잭션을 개인 공개키 및 그룹 공개키에 기반하여 검증할 수 있다.
비밀키 및 그룹키를 이용한 디지털 서명과 트랜잭션의 검증은 도 14 및 도 15에서 자세히 후술한다.
그룹 비밀키 생성모듈(316)은 게이트웨이(301)인 풀 노드(300)가 관리하는 그룹 내에 포함된 노드들의 정보를 기초로 그룹 비밀키를 생성할 수 있다. 그룹 비밀키는 동일한 그룹 내부의 노드들 사이에만 공유되는 정보로서, 비밀키와 함께 트랜잭션의 서명에 이용될 수 있다.
그룹 공개키 생성모듈(318)은 생성된 그룹 비밀키에 대한 연산을 통해 그룹 공개키를 생성할 수 있다. 그룹 공개키는 그룹 외부의 블록체인 네트워크에 배포되는 정보로서 트랜잭션 서명의 검증에 이용될 수 있다.
메모리(320)는 블록체인 정보(322)(예: 도 2의 블록체인(200)과 연관된 정보), 서버 목록(324), 그룹 가입 내역(326), 지갑 프로그램(328) 및 그룹키 목록(329)을 포함할 수 있다.
블록체인 정보(322)는 도 2의 블록체인(200)에 포함되는 정보를 포함할 수 있다. 본 문서에 개시된 다양한 실시예들에 따른 풀 노드(300)는 윈도우나 리눅스 환경의 컴퓨팅 장치일 수 있다. 풀 노드(300)는 블록체인(200)과 관련된 정보를 저장하고 실시간으로 동기화할 수 있는 하드웨어 자원을 가질 수 있다.
서버 목록(324)은 분산 네트워크 시스템(100)의 노드들에 대하여 그룹핑을 수행하는 서버들과 연관된 정보를 포함할 수 있다. 예를 들어, 서버 목록(324)은 서버(500)의 고유 ID와 서버(500) 위치 정보(IP, 위도, 경도)를 포함할 수 있다. 풀 노드(300)는 그룹에 가입하거나 게이트웨이(301)가 되기 위하여 서버 목록(324)에 포함되는 적어도 하나의 서버(500)에 요청을 보낼 수 있다.
그룹 가입 내역(326)은 풀 노드(300)가 이전에 그룹에 가입한 이력이 있는 경우, 그 그룹과 연관된 정보를 포함할 수 있다. 예를 들어 그룹 가입 내역(326)은 가입했던 그룹의 게이트웨이(301)의 계정 정보를 포함할 수 있다.
지갑 프로그램(328)은 트랜잭션의 생성 및 검증을 위한 명령어와 관련 데이터를 포함할 수 있다. 일 실시예에 따라, 풀 노드(300)가 게이트웨이(301)로 동작하는 경우, 지갑 프로그램(328)은 그룹 비밀키와 그룹 공개키의 생성을 위한 명령어와 관련 데이터를 포함할 수 있다. 풀 노드(300)의 계정은 지갑 프로그램(328)의 노드 주소가 될 수 있다. 지갑 프로그램(328)은 윈도우나 리눅스의 환경에서 동작하는 프로그램일 수 있다.
그룹키 목록(329)은 풀 노드(300)가 속한 그룹의 그룹 비밀키 및 풀 노드(300)가 속한 그룹을 비롯한 외부 그룹에서 생성된 그룹 공개키를 저장할 수 있다. 풀 노드(300)는 그룹 비밀키 및 그룹 공개키가 생성된 그룹에 관한 정보, 및 그룹 비밀키가 생성된 순서 정보와 그룹 공개키가 생성된 순서 정보를 함께 저장할 수 있다. 이에 대한 보다 상세한 설명은 도 11 내지 15와 함께 후술한다.
풀 노드(300)가 게이트웨이(301)로 동작하는 경우, 풀 노드(300)는 게이트웨이 목록(330)과 노드 풀(335)을 더 포함할 수 있다. 게이트웨이 목록(330)은 현재 게이트웨이(301)로 동작하며 그룹을 운영하고 있는 게이트웨이(301-1, 301-2, ~ 301-n)들과 연관된 정보를 포함할 수 있다. 게이트웨이 목록(330)은 서버(500)에도 보관될 수 있고, 서버(500)의 동작 불가와 같은 예외 상황에서 백업 역할을 할 수 있다.
다양한 실시예에서, 하나의 풀 노드(300)가 복수 개의 게이트웨이로 동작할 수 있다. 이 경우, 상기 복수 개의 게이트웨이들은 IP가 동일하지만, 상이한 포트 번호를 가질 수 있다.
노드 풀(335)은 게이트웨이(301)가 운영하는 그룹에 소속된 노드들(컴퓨팅 장치들)과 연관된 정보를 포함할 수 있다. 노드 풀(335)은 자신의 그룹에 속하는 노드(600)의 목록을 포함할 수 있다. 예를 들어, 노드 풀(335)은 자신의 그룹에 속하는 노드(600)의 공개키 및 각 노드(600)를 식별하는 인덱스 정보를 포함할 수 있고, 인덱스 정보와 공개키는 매핑되어 저장될 수 있다.
도 5는 일 실시예에 따른 라이트 노드(400)에 대한 블록도를 나타낸다. 도 5를 참조하면, 라이트 노드(400)는 통신 인터페이스(405), 프로세서(410), 메모리(420)를 포함할 수 있다. 라이트 노드(400)는 통신 인터페이스(405)를 통하여 분산 네트워크 시스템(100)에 포함되는 노드들 및 서버(500)와 통신을 수행할 수 있다.
프로세서(510)는 트랜잭션 생성모듈(412)을 포함할 수 있다. 예를 들어, 프로세서(510)는 메모리(520)에 저장된 명령어들을 실행하여 트랜잭션 생성모듈(412)을 구동시킬 수 있다. 트랜잭션 생성모듈(412)은 지갑 프로그램(422)에 포함된 명령어들이 실행되어 구동될 수 있으나, 이에 한정되지 않는다.
트랜잭션 생성모듈(412)은 하드웨어, 소프트웨어 또는 이들의 조합으로 구현될 수도 있다. 트랜잭션 생성모듈(412)에 의해 수행되는 동작은 프로세서(410)에 의해 수행되는 동작으로 이해될 수 있다.
트랜잭션 생성모듈(412)은 블록 내에 저장 및 보존의 대상이 되는 데이터(예: 거래 내역)를 블록에 포함시킬 것을 요청하는 트랜잭션을 생성할 수 있다. 트랜잭션 생성모듈(412)은 비밀키를 이용한 전자서명과 그룹키를 이용한 전자서명을 트랜잭션에 포함시킬 수 있다. 트랜잭션 생성모듈(412)은 생성된 그룹키의 순서 정보를 고려하여 트랜잭션의 서명에 사용될 그룹 비밀키를 선택할 수 있다. 이에 대한 설명은 도 14 및 15와 함께 후술한다.
라이트 노드(400)는 메모리(420)에 지갑 프로그램(422), 서버 목록(424), 및 그룹 가입 내역(426)을 저장할 수 있다.
지갑 프로그램(422)은 트랜잭션의 생성 및 검증을 위한 명령어와 관련 데이터를 포함할 수 있다. 지갑 프로그램(422)은 안드로이드나 IOS 같은 모바일 환경에서 동작하는 프로그램일 수 있다. 서버 목록(424)와 그룹 가입 내역(426)은 풀 노드(300)의 서버 목록(324) 및 그룹 가입 내역(326)과 실질적으로 동일하다.
그룹키 목록(428)은 라이트 노드(400)가 속한 그룹의 그룹 비밀키를 저장할 수 있다. 여기서, 그룹키 목록(428)은 풀 노드(300)의 그룹키 목록(329)와 달리 각 그룹별 그룹 공개키를 포함하지 않는데, 이는 라이트 노드(400)는 트랜잭션에 대한 검증을 수행하지 않기 때문이다.
도 6은 일 실시예에 따른 서버(500)에 대한 블록도를 나타낸다. 도 6을 참조하면, 서버(500)는 통신 인터페이스(505), 프로세서(510), 및 메모리(520)를 포함할 수 있다. 서버(500)는 통신 인터페이스(505)를 통하여 분산 네트워크 시스템(100)의 노드들(풀 노드(300), 라이트 노드(400))과 통신을 수행할 수 있다.
프로세서(510)는 그룹핑 모듈(512)을 포함할 수 있다. 예를 들어, 프로세서(510)는 메모리(520)에 저장된 명령어들을 실행하여 그룹핑 모듈(512)을 구동시킬 수 있다. 그룹핑 모듈(512)은 하드웨어, 소프트웨어 또는 이들의 조합으로 구현될 수 있다. 그룹핑 모듈(512)에 의해 수행되는 동작은 프로세서(510)에 의해 수행되는 동작으로 이해될 수 있다. 그룹핑 모듈(512)은 노드들의 위치 정보를 기초로 노드들에 대한 그룹을 결정할 수 있다.
메모리(520)는 게이트웨이 목록(522)과 서버 목록(524)을 저장할 수 있다. 게이트웨이 목록(522)은 풀 노드(300)에 저장되는 게이트웨이 목록(330)과 서로 동기화될 수 있다. 서버 목록(524)은 서버(500)와 동일한 역할을 수행하는 다른 서버들에 대한 정보를 포함할 수 있다.
도 7은 일 실시예에 따른 게이트웨이의 등록 과정을 설명하기 위한 흐름도이다.
풀 노드(300)는 게이트웨이(301)로 동작하기 위하여 어느 하나의 서버(제1 서버(500-1))로 게이트웨이 등록 요청 메시지를 송신할 수 있다(701). 풀 노드(300)는 내부에 저장된 서버 목록을 이용하여, 서버 목록에 포함되는 어느 하나의 서버로 상기 메시지를 송신할 수 있다. 예를 들어, 제1 서버(500-1)에 상기 메시지가 송신된 예시가 도시되었다.
게이트웨이 등록 메시지는 풀 노드(300)의 IP 주소 정보, 풀 노드(300)의 포트(port) 번호 정보, 풀 노드(300)의 위도 정보, 풀 노드(300)의 경도 정보 중 적어도 어느 하나 정보를 포함할 수 있다. 상기 정보들은 게이트웨이(301)의 위치와 연관된 정보로 이해될 수 있다.
제1 서버(500-1)는 수신된 게이트웨이 등록 메시지의 유효성을 검사하고(703), 게이트웨이 등록 응답 메시지를 풀 노드(300)로 송신할 수 있다(705). 제1 서버(500-1)는 게이트웨이 등록 요청 메시지에 포함된 데이터와 게이트웨이 목록 정보를 비교할 수 있다. 제1 서버(500-1)는 풀 노드(300)의 위치와 연관된 정보를 이용하여, 상기 풀 노드(300)와 인접한 위치에 있는 게이트웨이(301)를 게이트웨이 목록 중에서 선택할 수 있다.
게이트웨이 등록 응답 메시지는, 게이트웨이 등록 메시지에 대한 처리 결과에 대한 성공/실패 여부(return_val)를 포함할 수 있고, 상기 풀 노드(300)에 할당될 게이트웨이 ID를 포함할 수 있다.
풀 노드(300)는 게이트웨이 등록 응답 메시지에 포함된 상기 처리 결과가 성공인 경우, 수신된 게이트웨이 ID를 자신의 ID 로 등록하고(707), 제1 서버(500-1)에 게이트웨이 등록 처리 메시지를 송신할 수 있다(709). 게이트웨이 등록 처리 메시지는 풀 노드(300)가 등록한 게이트웨이 ID를 포함할 수 있다. 만약, 게이트웨이 등록 응답 메시지에 포함된 상기 처리 결과가 실패인 경우, 풀 노드(300)는 서버 목록에 포함된 다른 서버로 동작 701 내지 동작 709 동작을 수행하게 된다.
제1 서버(500-1)는 게이트웨이 등록 처리 메시지를 수신하면, 그에 포함된 게이트웨이 ID를 이용하여 게이트웨이 목록을 갱신할 수 있다(711). 제1 서버(500-1)는 게이트웨이 추가 요청 메시지를 다른 서버들에게 전송함으로써, 갱신된 게이트웨이 목록을 전파할 수 있다. 게이트웨이 추가 요청 메시지는 아래의 정보들 중 적어도 하나 이상의 정보를 포함할 수 있다. 게이트웨이 추가 요청 메시지는 제1 서버(500-1)의 동기화 인덱스(번호)를 포함할 수 있다. 동기화 인덱스는 게이트웨이 목록이 갱신될 때(게이트웨이가 추가될 때) 갱신되는 숫자일 수 있다. 예를 들어, 동기화 인덱스는 0 ~ (pow(2,32)-1)값의 범위 내의 숫자일 수 있다. 게이트웨이 추가 요청 메시지는 제1 서버(500-1)에 등록된 게이트웨이 개수와 제1 서버(500-1)에 포함된 게이트웨이 목록을 포함할 수 있다. 게이트웨이 추가 요청 메시지는 게이트웨이 목록에 포함된 게이트웨이의 IP 주소, 포트 번호, 위도 정보, 경도 정보 중 적어도 하나를 포함할 수 있다.
게이트웨이 추가 요청 메시지는, 예를 들어, 제1 서버(500-1)에 저장된 서버 목록에 포함된 제2 서버(500-2) 내지 제n 서버(500-n)에 전송될 수 있다(713, 717). 게이트웨이 추가 요청 메시지를 수신한 제2 서버(500-2)는 상기 메시지를 송신한 제1 서버(500-1)를 식별할 수 있다. 예를 들어 제2 서버(500-2)는 상기 메시지가 송신된 송신지의 IP를 이용하여 제1 서버(500-1)를 식별할 수 있다. 제2 서버(500-2)는 제2 서버(500-2)에 저장된 게이트웨이 목록을 로드할 수 있다. 구체적으로, 제2 서버(500-2)는 수신된 메시지에 포함된 제1 동기화 인덱스와 제2 서버(500-2)에 저장된 제2 동기화 인덱스를 비교할 수 있다. 만약 제1 동기화 인덱스가 제2 동기화 인덱스보다 크다면, 제2 서버(500-2)는 제2 서버(500-2)에 저장된 게이트웨이 목록을 상기 메시지를 통하여 수신된 게이트웨이 목록으로 갱신하고, 자신의 제2 동기화 인덱스를 갱신할 수 있다. 게이트웨이 갱신 과정이 완료되면, 제2 서버(500-2)는 처리 결과가 반영된 게이트웨이 추가 응답 메시지를 제1 서버(500-1)로 전송할 수 있다(715). 713 동작 내지 715 동작은 제1 서버(500-1)의 서버 목록에 포함된 제2 서버(500-2) 외에 제3 서버 내지 제 n 서버(500-n)에 대하여 수행될 수 있다.
도 8은 일 실시예에 따른 게이트웨이의 관리 동작을 설명하기 위한 흐름도이다.
풀 노드(300)가 제1 서버(500-1)에 의하여 게이트웨이(301)로 등록되면, 제1 서버(500-1)는 게이트웨이(301)를 관할하게 된다. 또한 풀 노드(300)는 게이트웨이(301)로서 동작을 수행하게 된다. 제1 서버(500-1)는 주기적으로 게이트웨이(301)에 메시지가 도달가능한지 여부를 검사할 수 있다. 예를 들어, 제1 서버(500-1)는 핑 메시지를 게이트웨이(301)로 전송하고(801), 그에 대한 응답 메시지를 수신함으로써(803) 게이트웨이(301)가 정상 동작 중인지 여부를 판단할 수 있다. 동작 801 및 동작 803은 미리 정해진 주기(예: 2분)마다 반복하여 수행될 수 있다.
예를 들어, 핑 메시지는 핑 메시지를 식별하기 위한 임의의 수를 포함할 수 있다. 핑 응답 메시지는 수신한 핑 메시지에 포함된 임의의 수를 포함할 수 있다. 제1 서버(500-1)는 상기 임의의 수를 비교함으로써, 해당 핑 메시지에 대한 응답이 수신된 것을 확인할 수 있다.
만약 제1 서버(500-1)가 게이트웨이(301)에 반복적으로 핑 메시지를 보냈으나 그에 대한 응답이 없는 경우에는, 게이트웨이(301)를 게이트웨이 목록에서 삭제할 수 있다(807). 예를 들어, 제1 서버(500-1)는 미리 정해진 횟수(예: 3회)의 핑 메시지를 전송하고 그에 대한 응답이 수신되지 않는 경우, 해당 게이트웨이(301)에서 관련 프로그램이 종료되었거나, 게이트웨이(301)의 네트워크가 단절된 것으로 판단할 수 있다.
이 경우 제1 서버(500-1)는 다른 서버들에게 게이트웨이 삭제 요청 메시지를 전송함으로써, 다른 서버들과 게이트웨이 목록을 동기화할 수 있다(809, 813). 게이트웨이 삭제 요청 메시지는 제1 서버(500-1)의 동기화 인덱스(번호)를 포함할 수 있다. 동기화 인덱스는 게이트웨이 목록이 갱신될 때(즉, 게이트웨이가 삭제될 때) 갱신되는 숫자일 수 있다. 예를 들어, 동기화 인덱스는 0 ~ (pow(2,32)-1)값의 범위 내의 숫자일 수 있다. 게이트웨이 삭제 요청 메시지는 제1 서버(500-1)에 등록된 게이트웨이 개수와 제1 서버(500-1)에 포함된 게이트웨이 목록을 포함할 수 있다.
게이트웨이 삭제 요청 메시지는, 예를 들어, 제1 서버(500-1)에 저장된 서버 목록에 포함된 제2 서버(500-2) 내지 제n 서버(500-n)에 전송될 수 있다(809, 813). 게이트웨이 삭제 요청 메시지를 수신한 제2 서버(500-2)는 상기 메시지를 송신한 제1 서버(500-1)를 식별할 수 있다. 예를 들어 제2 서버(500-2)는 상기 메시지가 송신된 송신지의 IP를 이용하여 제1 서버(500-1)를 식별할 수 있다. 제2 서버(500-2)는 제2 서버(500-2)에 저장된 게이트웨이 목록을 로드할 수 있다. 구체적으로, 제2 서버(500-2)는 수신된 메시지에 포함된 제1 동기화 인덱스와 제2 서버(500-2)에 저장된 제2 동기화 인덱스를 비교할 수 있다. 만약 제1 동기화 인덱스가 제2 동기화 인덱스보다 크다면, 제2 서버(500-2)는 제2 서버(500-2)에 저장된 게이트웨이 목록을 상기 메시지를 통하여 수신된 게이트웨이 목록으로 갱신하고, 자신의 제2 동기화 인덱스를 갱신할 수 있다. 게이트웨이 갱신 과정이 완료되면, 제2 서버(500-2)는 처리 결과가 반영된 게이트웨이 삭제 응답 메시지를 제1 서버(500-1)로 전송할 수 있다(811). 809 동작 및 813 동작은 제1 서버(500-1)의 서버 목록에 포함된 제2 서버(500-2) 외에 제3 서버 내지 제 n 서버(500-n)에 대하여 수행될 수 있다.
도 9a, 도 9b 및 도 9c는 일 실시예에서 노드가 그룹에 가입하는 동작을 설명하기 위한 흐름도이다.
분산 네트워크 시스템(100)에 포함되는 풀 노드(300)(게이트웨이로 동작하지 않는 풀 노드)와 라이트 노드(400)는 적어도 하나의 게이트웨이(301)에 의하여 운영되는 어느 하나의 그룹에 가입할 수 있다. 이하, 라이트 노드(400)가 그룹에 가입하는 동작을 예시로서 설명하나, 풀 노드(300)도 같은 동작을 수행함으로써 그룹에 가입할 수 있다.
일 예에서, 라이트 노드(400)는 그룹 가입 내역을 포함할 수 있다. 그룹 가입 내역은 예를 들어, 분산 네트워크 시스템(100)의 적어도 하나의 게이트웨이와 연결된 이력이 있을 경우 연결되었던 게이트웨이와 연관된 정보를 포함할 수 있다.
라이트 노드(400)는 그룹 가입 내역을 조회할 수 있다(901). 그룹 가입 내역은 적어도 하나의 게이트웨이의 주소를 포함할 수 있다. 예를 들어, 상기 주소는 게이트웨이의 주소로 분산 네트워크 시스템(100)상에 등록되어 있는 주소(예: 퍼블릭 키, 지갑 주소)로 이해될 수 있다. 그룹 가입 내역은 예를 들어, 제1 게이트웨이(301-1)의 주소, 및 제2 게이트웨이(301-2)의 주소를 포함할 수 있다. 라이트 노드(400)는 그룹 가입 내역에서 제1 게이트웨이(301-1)를 먼저 선택하고(903), 제1 게이트웨이(301-1)로 그룹 가입 요청 메시지를 전송할 수 있다(905). 그룹 가입 요청 메시지는 라이트 노드(400)의 주소(예: 지갑 주소)를 포함할 수 있다. 제1 게이트웨이(301-1)는 그룹 가입 요청 메시지를 수신 받으면, 라이트 노드(400)의 가입 가능 여부를 확인할 수 있다(907). 제1 게이트웨이(301-1)는 수신된 라이트 노드(400)의 주소를 확인하고, 상기 라이트 노드(400)를 수용가능한지 여부를 확인할 수 있다. 예를 들어, 각각의 게이트웨이에 대하여 수용가능한 노드들의 개수가 제한될 수 있다. 상기 개수는 각각의 게이트웨이의 하드웨어 환경 및/또는 소프트웨어의 정책에 따라 미리 설정될 수 있다.
제1 게이트웨이(301-1)는, 라이트 노드(400)을 수용 가능한 경우, 라이트 노드(400)의 주소를 제1 게이트웨이(301-1)의 노드 풀에 저장할 수 있다. 제1 게이트웨이(301-1)는 라이트 노드(400)에 대응되는 노드 ID를 생성하고, 상기 노드 ID와 상기 라이트 노드(400)의 주소를 상기 노드 풀에 저장할 수 있다. 상기 노드 ID와 라이트 노드(400)의 주소는 매핑되어 저장될 수 있다.
그러나 제1 게이트웨이(301-1)가 라이트 노드(400)을 수용 불가능한 경우, 라이트 노드(400)는 다른 노드에 다시 그룹 가입 요청을 해야 한다.
제1 게이트웨이(301-1)는 라이트 노드(400)의 그룹 가입 요청 메시지에 대한, 그룹 가입 응답 메시지를 라이트 노드(400)에 전송할 수 있다. 그룹 가입 응답 메시지는, 그룹 가입 요청에 대한 성공/실패 여부를 포함할 수 있다. 또한 그룹 가입이 성공한 경우, 라이트 노드(400)에 대하여 생성된 노드 ID가 포함될 수 있다.
예를 들어, 제1 게이트웨이(301-1)가 라이트 노드(400)를 수용할 수 없는 경우, 실패(예: null)의 응답을 포함하는 그룹 가입 응답 메시지를 라이트 노드(400)로 전송할 수 있다(909). 라이트 노드(400)는 수신된 그룹 가입 응답 메시지를 파싱하고, 실패 여부를 확인하면, 그룹 가입 내역 중 제1 게이트웨이(301-1)가 아닌 다른 게이트웨이를 선택할 수 있다. 만약 그룹 가입 내역에 다른 게이트웨이가 더 이상 없을 경우에는, 라이트 노드(400)는 도 9b를 통해 후술될 동작들을 수행할 수 있다.
도 9a에서, 라이트 노드(400)는 그룹 가입 내역에 포함된 제2 게이트웨이(301-2)를 선택할 수 있다(911). 라이트 노드(400)는 제2 게이트웨이(301-2)로 그룹 가입 요청 메시지를 전송할 수 있다(913). 제2 게이트웨이(301-2)는 수신된 라이트 노드(400)의 주소를 확인하고, 상기 라이트 노드(400)를 수용가능한지 여부를 확인할 수 있다(915). 제2 게이트웨이(301-2)는, 라이트 노드(400)를 수용 가능한 경우, 라이트 노드(400)의 주소를 제2 게이트웨이(301-2)의 노드 풀에 저장할 수 있다(917). 예를 들어, 제2 게이트웨이(301-2)는 라이트 노드(400)에 대응되는 노드 ID를 생성하고, 상기 노드 ID와 상기 라이트 노드(400)의 주소를 상기 노드 풀에 저장할 수 있다. 제2 게이트웨이(301-2)는 라이트 노드(400)의 그룹 가입 요청 메시지에 대한, 그룹 가입 응답 메시지를 라이트 노드(400)에 전송할 수 있다(919). 해당 그룹 가입 응답 메시지는 그룹 가입 요청에 대한 성공의 응답을 포함할 수 있고, 라이트 노드(400)에 대한 노드 ID를 포함할 수 있다.
도 9b를 참조하면, 라이트 노드(400)가 그룹 가입 내역을 포함하지 않는 경우, 라이트 노드(400)는 서버 목록에 포함되는 서버들 중 어느 하나의 서버(500)에 게이트웨이 정보 요청 메시지를 전송할 수 있다(950). 게이트웨이 정보 요청 메시지는 라이트 노드(400)의 IP 정보, 라이트 노드(400)의 포트 정보, 라이트 노드(400)의 위도 정보, 및 라이트 노드(400)의 경도 정보 중 적어도 하나의 정보를 포함할 수 있다.
서버(500)는 게이트웨이 정보 요청 메시지에 응답하여, 후보 게이트웨이 목록을 생성할 수 있다(953). 서버(500)는 게이트웨이 정보 응답 메시지를 전송할 수 있다(955). 게이트웨이 정보 응답 메시지는, 상기 생성한 후보 게이트웨이 목록과 후보 게이트웨이의 개수 정보를 포함할 수 있다.
라이트 노드(400)는 수신된 후보 게이트웨이 목록을 이용하여 도 9a를 통하여 상술된 동작 901 내지 동작 919을 수행할 수 있다. 만약 현재 가입 가능한 그룹이 없을 경우에 동작 951 내지 동작 955는 반복하여 수행될 수 있다.
도 9c를 참조하면 일 예시에서, 라이트 노드(400)는 라이트 노드(400)의 위치 정보로서 위도 정보 및/또는 경도 정보를 획득할 수 있다(961). 예를 들어, 라이트 노드(400)는 포터블 디바이스(예: 스마트폰, 태블릿 PC)일 수 있다. 라이트 노드(400)의 위치는 실시간으로 변경될 수 있다.
라이트 노드(400)는 상기 위도 정보 및/또는 경도 정보를 포함하는 게이트웨이 정보 요청 메시지를 서버(500)에 전송할 수 있다(963). 다양한 실시예에서, 라이트 노드(400)의 위도 좌표 및/또는 경도 좌표가 변경됨에 따라 서버(500)에 접속해야 할 게이트웨이에 대한 정보를 요청할 수 있다. 또는 라이트 노드(400)는 서버(500)에 일정 주기마다 현재의 위치 정보를 기초로 접속해야 할 게이트웨이에 대한 정보를 요청할 수 있다.
일부 실시예에서, 게이트웨이 정보 요청 메시지는 라이트 노드(400)가 요청한 게이트웨이의 개수, 라이트 노드(400)의 IP 주소, 라이트 노드(400)의 위도 정보, 및 라이트 노드(400)의 경도 정보를 포함할 수 있다.
서버(500)는 노드 대기 풀에 라이트 노드(400)를 등록할 수 있다(965). 서버(500)는 라이트 노드들로부터 게이트웨이 정보 요청 메시지를 수신하면, 상기 요청을 순차적으로 처리하기 위하여 노드 대기 풀을 운영할 수 있다. 이하 서버(500)의 동작들은 서버(500)의 프로세서(510)의 그룹핑 모듈(512)에 의하여 수행될 수 있다.
서버(500)는 게이트웨이 목록을 조회하고(967), 게이트웨이 목록에 포함된 게이트웨이들과 라이트 노드(400) 사이의 거리를 계산할 수 있다(969). 예를 들어, 서버(500)는 라이트 노드(400)의 위도 정보 및 경도 정보와 게이트웨이들의 위도 정보 및 경도 정보를 기초로, 양자 사이의 거리(예: GPS 좌표 상 거리)를 계산할 수 있다. 서버(500)는 게이트웨이 목록에 포함된 게이트웨이들에 대하여 상기 계산을 수행하고, 라이트 노드(400)와 가까운 거리를 가지는 순서로 후보 게이트웨이를 결정할 수 있다. 서버(500)는 결정된 후보 게이트웨이들이 포함된 후보 게이트웨이 목록을 생성할 수 있다(971). 후보 게이트웨이 목록은 라이트 노드(400)에 의하여 요청된 개수의 후보 게이트웨이들을 포함할 수 있다. 서버(500)는 후보 게이트웨이 목록을 포함하는 게이트웨이 정보 응답 메시지를 라이트 노드(400)에 전송할 수 있다(983).
도 10은 일 실시예에 따른 서버들 간의 게이트웨이 목록을 동기화하는 동작의 흐름도이다.
서버(500)는 미리 정해진 주기마다 서버(500)에 포함된 게이트웨이 목록을 다른 서버에 공유할 수 있다. 도 10을 참조하면, 예를 들어 제1 서버(500-1)와 제2 서버(500-2)의 동기화 과정이 예시되었다. 제2 서버(500-2)는 게이트웨이 목록에 대한 동기화 요청 메시지를 제1 서버(500-1)로 전송할 수 있다(1001). 상기 동기화 요청 메시지는, 제2 서버(500-2)에 저장된 동기화 인덱스(번호), 게이트웨이 목록을 포함할 수 있다. 동기화 인덱스는 게이트웨이 목록이 갱신될 때 갱신되는 숫자일 수 있다. 예를 들어, 동기화 인덱스는 0 ~ (pow(2,32)-1)값의 범위 내의 숫자일 수 있다.
제1 서버(500-1)는 제1 서버(500-1)에 저장된 제1 동기화 인덱스와 제2 서버(500-2)로부터 수신된 제2 동기화 인덱스를 비교할 수 있다. 만약 제2 동기화 인덱스가 제1 동기화 인덱스보다 크다면, 제1 서버(500-1)는 제1 서버(500-1)에 저장된 게이트웨이 목록을 상기 메시지를 통하여 수신된 게이트웨이 목록으로 갱신하고, 자신의 제1 동기화 인덱스를 갱신할 수 있다(1003). 제1 서버(500-1)는 동기화 요청 응답 메시지를 제2 서버(500-2)로 전송할 수 있다. 동기화 요청 응답 메시지는 동기화 요청에 대한 처리 결과(성공 또는 실패)를 포함할 수 있다. 동작 1001 내지 동작 1005는 미리 정해진 주기마다 분산 네트워크 시스템(100)에 포함되는 서로 다른 서버들 사이에 수행될 수 있다.
다양한 실시예에서, 새로 추가된 제n 서버(500-n)는 초기화 부팅을 수행하고(1011), 임의의 이웃 서버인 제1 서버(500-1)에 초기 동기화 요청 메시지를 전송할 수 있다(1013). 제1 서버(500-1)는 초기 동기화 응답 메시지를 제n 서버(500-n)로 전송할 수 있다. 초기 동기화 응답 메시지는, 분산 네트워크 시스템(100)에 포함된 서버들에 대한 정보를 포함할 수 있다. 서버들에 대한 정보는, 서버들의 개수, 서버들에 저장된 게이트웨이의 목록, 게이트웨이의 개수, 게이트웨이 목록에 대한 동기화 인덱스를 포함할 수 있다. 제n 서버(500-n)는 초기 동기화 응답 메시지를 수신하면, 상기 메시지에 포함된 정보를 저장하고, 동기화를 수행할 수 있다.
도 11은 일 실시예에 따라 게이트웨이(301, 청구항의'노드 그룹 관리 장치')가 그룹 비밀키를 생성하는 동작의 예시도이다.
게이트웨이(301)는 상술한 바와 같이, 블록체인 네트워크에 참여하는 노드 중 일부의 노드를 하나의 그룹으로서 관리하는 기능을 할 수 있다. 게이트웨이(301)의 그룹 비밀키 생성모듈(316)은 자신의 그룹 안의 노드들이 트랜잭션 서명 시 비밀키와 더불어, 이중적으로 서명에 사용될 수 있는 그룹 비밀키를 생성할 수 있다. 게이트웨이(301)는 자신의 그룹 안의 노드와 공유하고, 그룹 비밀키의 서명 검증에 사용될 그룹 공개키를 다른 그룹에 배포할 수 있다.
도 11을 참조하면, 게이트웨이(301)는 자신의 그룹에 참여하는 노드의 정보를 노드 풀(335)에 저장하고 있다. 노드 풀(335)은 그룹 내 각 노드를 식별하는 인덱스 정보 및 각 노드의 공개키 정보를 매핑하여 저장할 수 있다. 예를 들어, 제1 게이트웨이(301)가 100개의 노드를 관리하는 경우, 노드 풀(335)에는 100개 노드의 인덱스 정보 1~100과 각각의 공개키를 매핑하여 저장할 수 있다.
우선, 게이트웨이(301)는 그룹 비밀키를 생성하기 위해, 노드 풀(335)에 저장된 노드의 공개키 중 일부를 선정할 수 있다. 도 11과 같이 게이트웨이(301)는 랜덤하게 인덱스 정보 1, 3, 25, 99에 매핑된 공개키를 선정할 수 있고, 또는 아래 예시의 방법을 사용할 수 있다.
예를 들어, 게이트웨이(301)는 그룹 내의 노드의 총 수를 소정의 자연수로 나눈 몫의 배수에 해당하는 인덱스를 가진 공개키를 선정할 수 있다. 가령, 노드의 총 수가 100개인 경우, 랜덤한 자연수 7로 나눈 몫인 14의 배수인 14, 28, 42, 56, 50, 84, 98의 인덱스와 매핑된 공개키를 선정할 수 있다.
다음으로, 게이트웨이(301)는 선정된 각 공개키를 비트로만 이루어진 비트 정보가 출력되도록 소정의 해쉬 생성 알고리즘을 통하여 변환할 수 있다. 가령 각 공개키에 base58 decoding을 적용하여 160 비트로 이루어진 비트열을 추출할 수 있다.
이후, 게이트웨이(301)는 각각의 비트열에 비트 연산(bitwise operation, 예를 들어, ^, &, >>, << 또는 이들의 조합)을 수행하여 하나의 합성된 비트열(도 11, 160비트의 1101001010011쪋00)을 생성할 수 있다.
이후, 게이트웨이(301)는 합성된 비트열에 시간 정보로 이루어진 비트열을 연결하여 그룹 비밀키를 생성할 수 있다. 이때 시간 정보 비트열은 UNIX TIME을 사용할 수 있다. 게이트웨이(301)는 그룹 비밀키의 비트수가 비밀키의 비트수와 같도록 하기 위해, 시간 정보의 비트열에 임의의 비트열을 연결할 수 있다.
예를 들어, 256 비트의 그룹 비밀키를 만들기 위해, 합성된 비트열이 160 비트일 때, 96비트를 연결해야 하므로, 시간 정보 비트열을 Currnet Time(32bit) x sysrandom(64bit)로 구성할 수 있다. 다만, 이는 예시일 뿐 그룹 비밀키 생성 방법이 이러한 예시에 한정되는 것은 아니다.
게이트웨이(301)는 하나의 그룹 비밀키가 지속적으로 사용될 경우, 악의적인 공격에 의해 그룹 비밀키가 노출될 우려를 방지하기 위해, 소정의 주기로 그룹 비밀키를 새롭게 생성하거나, 게이트웨이(301)가 관리하는 그룹에 변경(예: 노드의 추가 또는 탈퇴)이 발생할 경우에 그룹 비밀키를 새롭게 생성하여 그룹 내의 노드에 배포할 수 있다.
그룹 비밀키의 생성 주기는, 그룹 비밀키로부터 생성된 그룹 공개키가 게이트웨이(301) 간에 공유되어야 하므로 게이트웨이(301) 간의 송수신되는 메시지의 통신 딜레이(예: 2~4초)를 고려하여 선택될 수 있다. 일 실시예에 따라, 그룹 비밀키의 생성 주기는 5~60초일 수 있으나, 이러한 수치는 예시일 뿐 한정하는 것은 아니다.
게이트웨이(301)의 그룹 공유키 생성모듈(316)은 그룹 비밀키로부터 소정의 함수를 통해 그룹 공개키를 생성할 수 있다. 소정의 함수는 그룹 비밀키를 기초로는 그룹 공개키를 생성할 수 있으나, 제1 그룹 공개키를 기초로는 그룹 비밀키를 만들 수 없는 비가역함수로서, 예를 들면, 타원곡선곱셈 함수(Elliptic Curve Digital Signature Algorithm, ECDSA)를 포함할 수 있으나, 이에 한정되지는 않는다.
도 12는 일 실시예에서 게이트웨이(301)가 그룹 비밀키 및 그룹 공개키를 생성 및 배포하는 동작을 설명하기 위한 흐름도이다.
전제 동작으로서 게이트웨이(301)가 그룹에 포함될 노드를 선정하거나, 노드로부터 그룹으로의 참여를 요청 받아 그룹을 결정하는 방법은 상술한 도 9a 내지 도 9c의 동작을 참조할 수 있으나, 게이트웨이(301)가 복수의 노드로 이루어진 그룹을 결성하는 방법은 이에 한정되지 않고 다양한 방법을 이용할 수 있다.
이하, 제1 그룹을 관리하는 게이트웨이를 제1 그룹 게이트웨이(301-1), 제1 그룹에 포함된 노드를 제1 그룹 노드(600-1)로 지칭하며, 제2 그룹을 관리하는 게이트웨이를 제2 그룹 게이트웨이(301-2), 제2 그룹에 포함된 노드를 제2 그룹 노드(600-2)로 지칭하여, 게이트웨이(301)가 그룹 비밀키 및 그룹 공개키를 생성 및 배포하는 동작을 설명한다.
제1 그룹 게이트웨이(301-1)는 제1 그룹에 포함된 노드의 정보를 기초로 제1 그룹 비밀키 및 제1 그룹 공개키를 생성할 수 있다(2001).
제1 그룹 게이트웨이(301-1)는 제1 그룹 노드에 제1 그룹 비밀키(또는 제1 그룹 공개키를 포함할 수 있음)를 배포할 수 있다(2003). 제1 그룹 노드 중 하나인 제1 그룹 노드 a(600-1a)는 제1 그룹 비밀키를 수신하여 스스로 제1 그룹 공개키를 생성할 수 있다.
제1 그룹 게이트웨이(301-1)는 외부 그룹에 제1 그룹 공개키를 배포할 수 있다(2005). 외부 그룹 중 제2 그룹을 관리하는 제2 그룹 게이트웨이(301-2)는 제1 그룹 공개키를 수신하여 저장할 수 있다(2007). 제2 그룹 게이트웨이(301-2)는 제2 그룹 노드에 제1 그룹 공개키를 배포할 수 있다(2009). 제2 그룹 노드 중 트랜잭션 검증 기능을 하는 제1 그룹 노드 a(600-2a)는 제1 그룹 공개키를 저장하여, 제1 그룹에서 생성된 트랜잭션의 검증에 사용할 수 있다.
아울러, 제1 그룹 비밀키가 생성된 이후 제1 그룹 노드에 변경이 발생하는 상황을 가정하여 본다. 노드 b가 제1 그룹 게이트웨이(301-1)에 그룹 가입 요청을 전송할 수 있다(2011). 제1 그룹 게이트웨이(301-1)는 노드 b의 그룹 가입 요청을 승인할 수 있고, 승인 시 제1 그룹 노드 b(600-1b)의 정보를 노드 풀(335)에 저장할 수 있다(2013). 이러한 그룹 가입 동작은 도 9a 내지 도 9c의 동작을 통해 수행될 수 있으나, 이에 한정되지는 않는다.
제1 그룹 게이트웨이(301-1)는 새롭게 변경된 노드 풀(335)의 정보를 기초로 제1 그룹 비밀키 및 제1 그룹 공개키를 새롭게 생성할 수 있다(2015).
제1 그룹 게이트웨이(301-1)는 제1 그룹 노드에 제1 그룹 비밀키(또는 제1 그룹 공개키를 포함할 수 있음)를 배포할 수 있다(2017). 제1 그룹 노드에 해당하는 제1 그룹 노드 a(600-1a) 및 제2 그룹 노드 b는 제1 그룹 비밀키를 수신하여 스스로 제1 그룹 공개키를 생성할 수 있다.
제1 그룹 게이트웨이(301-1)는 외부 그룹에 제1 그룹 공개키를 배포할 수 있다(2019). 외부 그룹 중 제2 그룹을 관리하는 제2 그룹 게이트웨이(301-2)는 제1 그룹 공개키를 수신하여 저장할 수 있다(2021). 제2 그룹 게이트웨이(301-2)는 제2 그룹 노드에 제1 그룹 공개키를 배포할 수 있다(2023). 제2 그룹 노드 중 트랜잭션 검증 기능을 하는 제1 그룹 노드 a(600-2a)는 제1 그룹 공개키를 저장하여, 제1 그룹에서 생성된 트랜잭션의 검증에 사용할 수 있다. 제1 그룹 게이트웨이(301-1)는 그룹에 대한 변경이 발생하지 않더라도 주기적으로 제1 그룹 비밀키 및 제1 그룹 공개키를 생성할 수 있다.
한편, 외부 그룹에서 최신으로 생성된 그룹 비밀키로 서명된 트랜잭션을 수신하는 시점보다, 외부 그룹에서 최신으로 생성된 그룹 공개키를 수신하는 시간차가 발생하여, 최신의 그룹 공개키를 더 늦게 수신한다면 올바르게 생성된 트랜잭션이더라도 검증에 실패하는 상황을 도 13과 함께 살펴본다.
도 13은 일 실시예에서 노드가 그룹 비밀키의 선택에 따라 검증이 가능한 상황과 검증이 불가한 상황을 설명하기 위한 흐름도이다.
먼저, 제2 그룹 게이트웨이(301-2)는 제2 그룹에 포함된 노드의 정보를 기초로 제2 그룹 비밀키a 및 제2 그룹 공개키a를 생성할 수 있다(2201).
제2 그룹 게이트웨이(301-2)는 제2 그룹 노드에 제2 그룹 비밀키a(또는 제2 그룹 공개키a를 포함할 수 있음)를 배포할 수 있다(2203). 제2 그룹 노드 중 하나인 제1 그룹 노드 a(600-2a)는 제2 그룹 비밀키a를 수신하여 스스로 제2 그룹 공개키a를 생성할 수 있다.
제2 그룹 게이트웨이(301-2)는 외부 그룹에 제2 그룹 공개키a를 배포할 수 있다(2205). 외부 그룹 중 제1 그룹을 관리하는 제1 그룹 게이트웨이(301-1)는 제2 그룹 공개키a를 수신하여 저장할 수 있다(2207). 제2 그룹 게이트웨이(301-2)는 제1 그룹 노드에 제2 그룹 공개키a를 배포할 수 있다(2209).
한편, 제2 그룹 게이트웨이(301-2)는 그룹 정보가 변경되거나, 생성 주기가 도래되어, 제2 그룹에 포함된 노드의 정보를 기초로 제2 그룹 비밀키b 및 제2 그룹 공개키b를 새롭게 생성하고(2211), 제2 그룹 노드에 제2 그룹 비밀키b를 배포할 수 있다(2213).
다만, 제1 그룹에 제2 그룹 공개키b가 배포되기 전, 제1 그룹 노드 a(600-2a)가 제2 그룹 비밀키b를 통해 서명한 트랜잭션이 제1 그룹에 도달한 경우(2215)에는 제1 그룹 노드 a(600-1a)는 제2 그룹 비밀키b를 저장하고 있지 않기 때문에, 해당 트랜잭션이 올바른 서명이더라도 검증을 할 수가 없다.
따라서, 제1 그룹에 제2 그룹 공개키b가 배포되기 전이라면, 제1 그룹 노드 a(600-2a)는 설사 새로운 제2 그룹 비밀키b를 배포 받았다고 하더라도, 이전에 저장하고 있었던 제2 그룹 비밀키a로 서명해야지만, 해당 트랜잭션을 검증받을 수 있다. 보다 자세하게 도 14를 통해 각 그룹이 보유하고 있는 그룹 공개키의 상태를 살펴보기로 한다.
도 14는 일 실시예에 따라 각 그룹에 배포된 그룹 공개키 상태를 나타내는 예시도이다. 각각의 큰 박스는 제1 그룹, 제2 그룹, 제3 그룹에 배포되어 있는 그룹 공개키의 현 상태를 나타낸다. 그리고 세로 방향의 제1 주기 내지 제6 주기는 그룹키를 생성하는 주기를 의미하여 아래로 내려갈수록 최신으로 생성된 그룹 공개키를 의미한다. 또한 A-1 내지 A-6은 제1 그룹에서 생성된 그룹 공개키, B-1 내지 B-6은 제2 그룹에서 생성된 그룹 공개키, C-1 내지 C-6은 제3 그룹에서 생성된 그룹 공개키를 의미한다.
도 14를 참조하면, 현 상태에서 제1 그룹은 A-6 그룹 공개키까지 생성하였지만, 배포의 딜레이(2219)로 제2 그룹에는 아직 A-6 그룹 공개키가 도달하지 않았으며, 제3 그룹에는 아직 A-5 및 A-6 그룹 공개키가 도달하지 않은 상태이다. 따라서, 제1 그룹의 노드가 A-6의 그룹 비밀키로 서명을 하였다고 하더라도, 제2 그룹 및 제3 그룹의 노드는 해당 트랜잭션을 검증할 수 없다. 또한, 제1 그룹의 노드가 A-5의 그룹 비밀키로 서명을 하였다고 하더라도 제3 그룹의 노드는 해당 트랜잭션을 검증할 수 없다. 이에 따라, 트랜잭션의 실행 지연이 발생할 수 있다.
따라서 이러한 상황을 방지하기 위해, 제1 그룹의 노드는 최신으로 배포된 그룹 비밀키가 있다고 하더라도, 이미 블록체인 네트워크에 모두 배포되어 있는 그룹 비밀키를 사용하여 트랜잭션에 서명할 수 있다.
이를 위해, 노드는 배포된 그룹 비밀키 시각 정보와 함께 수신하여 최신 순으로 소정의 개수의 그룹 비밀키를 저장하고, 트랜잭션을 생성하는 경우 도 15의 2217 동작과 같이, 최신으로 저장된 그룹 비밀기로부터 기 설정된 주기 또는 시간(예: 블록체인 상에 그룹 공개키가 모두 배포될 수 있는 통신 딜레이 시간을 고려하여 설정) 이전에 생성된 그룹 비밀키를 이용하여 서명하여, 트랜잭션의 검증 불가 상황을 방지할 수 있다.
도 15는 일 실시예에 따른 그룹 비밀키 기반의 트랜잭션 이중 서명 및 그룹 공개키 기반의 트랜잭션 이중 검증의 개념도이다.
도 15를 참조하면, 노드는 메시지의 내용과 비밀키를 함께 해싱한 제1 서명 정보와 더불어, 메시지의 내용과 그룹 비밀키를 함께 해싱한 제2 서명 정보를 생성할 수 있다. 이에 따라, 노드는 블록체인 네트워크에 발생시킬 트랜잭션의 구조로서 메시지, 제1 서명 정보, 제2 서명 정보, 공개키 및 그룹 공개키를 포함시킬 수 있다. 예를 들어, 블록체인 네트워크에 배포되는 트랜잭션은 1　027d774e8a4f7e03d226dcab58298fa8a0acc
78afeb309d7195cb930f55dccaf22　03a6960346cc0698247d4178f521e0c5e43f1b28b3b647b9413e0058f6108f6ddd의 실제 예시로서 정해진 규약에 따라 정보의 순서가 배열된 16진수 열을 포함할 수 있다. 해당 트랜잭션을 수신한 노드는 정해진 형식으로 16진수 정보를 분류하여 스택에 쌓을 수 있다. 예를 들어, 형식에 대한 규약이 OP_0 <Sig-Wallet><Sig-Group> OP_2 <Public Key Wallet><Public Key Group> OP_2 OP_CHECKMULTISIG 와 같은 경우, 트랜잭션을 수신한 노드는 <Sig-Wallet>에 해당하는 숫자열로부터 제1 서명 정보, <Sig-Group>에 해당하는 숫자열로부터 제2 서명 정보, <Public Key Wallet>에 해당하는 숫자열로부터 공개키 정보, <Public Key Group>에 해당하는 숫자열로부터 그룹 공개키 정보를 추출할 수 있다.
이에 따라, 트랜잭션을 수신한 노드는 공개키를 통해 제1 서명이 올바른 비밀키에 의해 서명된 것인지 검증하고, 더하여 그룹 공개키를 통해 제2 서명이 올바른 그룹 비밀키에 의해 서명된 것인지 검증하여, 최종적으로 해당 트랜잭션이 올바른 것인지를 검증할 수 있다.
상술한 실시예들에 따르면, 트랜잭션 서명에 비밀키와 그룹 비밀키를 함께 사용하기 때문에, 비밀키가 해킹되었다고 하더라도 그룹 비밀키의 서명을 요청하는 구성을 통해, 해킹으로 인한 피해를 방지할 수 있다. 또한, 신뢰성이 확보된 게이트웨이(301)를 통해 그룹 비밀키와 그룹 공개키의 생성 및 배포하여, 그룹키 기반의 트랜잭션 서명에 대한 신뢰도를 높일 수 있다. 더하여, 그룹 비밀키의 생성을 주기적으로 수행하거나, 또는 그룹에 변경이 일어난 경우마다 수행함으로써, 그룹 비밀키의 노출 가능성을 최소화할 수 있다. 아울러, 노드가 트랜잭션을 생성할 경우, 블록체인 네트워크 상에 모두 배포된 그룹 비밀키를 통한 서명을 수행함으로써, 배포 딜레이로 인한 트랜잭션 검증 오류를 방지할 수 있다.
도 11 내지 도 15와 함께 설명된 동작의 순서는 예시일 뿐, 그 시계열적 순서가 한정되는 것이 아니며 설계에 따라 논리적으로 변경할 수 있다. 또한, 도 11 내지 도 15와 함께 설명된 게이트웨이(301)의 동작은 도 4의 프로세서가 포함하는 모듈에 의해 수행되는 동작으로 이해될 수 있다. 더불어, 도 11 내지 도 15와 함께 설명된 노드의 동작은 도 4의 풀 노드 또는 도 5의 라이트 노드의 프로세서가 포함하는 모듈에 의해 수행되는 동작으로 이해될 수 있다.
본 문서의 다양한 실시예들 및 이에 사용된 용어들은 본 문서에 기재된 기술적 특징들을 특정한 실시예들로 한정하려는 것이 아니며, 해당 실시예의 다양한 변경, 균등물, 또는 대체물을 포함하는 것으로 이해되어야 한다. 도면의 설명과 관련하여, 유사한 또는 관련된 구성요소에 대해서는 유사한 참조 부호가 사용될 수 있다. 아이템에 대응하는 명사의 단수 형은 관련된 문맥상 명백하게 다르게 지시하지 않는 한, 아이템 한 개 또는 복수 개를 포함할 수 있다.
본 문서에서, "A 또는 B", "A 및 B 중 적어도 하나", “A 또는 B 중 적어도 하나,”"A, B 또는 C," "A, B 및 C 중 적어도 하나,”및 “A, B, 또는 C 중 적어도 하나"와 같은 문구들 각각은 그 문구들 중 해당하는 문구에 함께 나열된 항목들의 모든 가능한 조합을 포함할 수 있다. "제 1", "제 2", 또는 "첫째" 또는 "둘째"와 같은 용어들은 단순히 해당 구성요소를 다른 해당 구성요소와 구분하기 위해 사용될 수 있으며, 해당 구성요소들을 다른 측면(예: 중요성 또는 순서)에서 한정하지 않는다. 어떤(예: 제 1) 구성요소가 다른(예: 제 2) 구성요소에, “기능적으로” 또는 “통신적으로”라는 용어와 함께 또는 이런 용어 없이, “커플드” 또는 “커넥티드”라고 언급된 경우, 그것은 어떤 구성요소가 다른 구성요소에 직접적으로(예: 유선으로), 무선으로, 또는 제 3 구성요소를 통하여 연결될 수 있다는 것을 의미한다.
본 문서에서 사용된 용어 "모듈"은 하드웨어, 소프트웨어 또는 펌웨어로 구현된 유닛을 포함할 수 있으며, 예를 들면, 로직, 논리 블록, 부품, 또는 회로 등의 용어와 상호 호환적으로 사용될 수 있다. 모듈은, 일체로 구성된 부품 또는 하나 또는 그 이상의 기능을 수행하는, 부품의 최소 단위 또는 그 일부가 될 수 있다. 예를 들면, 일 실시예에 따르면, 모듈은 ASIC(application-specific integrated circuit)의 형태로 구현될 수 있다.
본 문서의 다양한 실시예들은 기기(machine)(예: 전자 장치)에 의해 읽을 수 있는 저장 매체(예: 메모리)에 저장된 하나 이상의 명령어들을 포함하는 소프트웨어(예: 프로그램)로서 구현될 수 있다. 저장 매체는 RAM(random access memory), 메모리 버퍼, 하드 드라이브, 데이터베이스, EPROM(erasable programmable read-only memory), EEPROM(electrically erasable read-only memory), ROM(read-only memory) 및/또는 등등을 포함할 수 있다.
또한, 본 문서의 실시예들의 프로세서는, 저장 매체로부터 저장된 하나 이상의 명령어들 중 적어도 하나의 명령을 호출하고, 그것을 실행할 수 있다. 이것은 기기가 호출된 적어도 하나의 명령어에 따라 적어도 하나의 기능을 수행하도록 운영되는 것을 가능하게 한다. 이러한 하나 이상의 명령어들은 컴파일러에 의해 생성된 코드 또는 인터프리터에 의해 실행될 수 있는 코드를 포함할 수 있다. 프로세서는 범용 프로세서, FPGA(Field Programmable Gate Array), ASIC(Application Specific Integrated Circuit), DSP(Digital Signal Processor) 및/또는 등등 일 수 있다.
기기로 읽을 수 있는 저장매체는, 비일시적(non-transitory) 저장매체의 형태로 제공될 수 있다. 여기서, ‘비일시적’은 저장매체가 실재(tangible)하는 장치이고, 신호(signal)(예: 전자기파)를 포함하지 않는다는 것을 의미할 뿐이며, 이 용어는 데이터가 저장매체에 반영구적으로 저장되는 경우와 임시적으로 저장되는 경우를 구분하지 않는다.
본 문서에 개시된 다양한 실시예들에 따른 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다. 컴퓨터 프로그램 제품은 기기로 읽을 수 있는 저장 매체(예: compact disc read only memory (CD-ROM))의 형태로 배포되거나, 또는 어플리케이션 스토어(예: 플레이 스토어)를 통해 또는 두 개의 사용자 장치들(예: 스마트폰들) 간에 직접, 온라인으로 배포(예: 다운로드 또는 업로드)될 수 있다. 온라인 배포의 경우에, 컴퓨터 프로그램 제품의 적어도 일부는 제조사의 서버, 어플리케이션 스토어의 서버, 또는 중계 서버의 메모리와 같은 기기로 읽을 수 있는 저장 매체에 적어도 일시 저장되거나, 임시적으로 생성될 수 있다.
다양한 실시예들에 따르면, 기술한 구성요소들의 각각의 구성요소(예: 모듈 또는 프로그램)는 단수 또는 복수의 개체를 포함할 수 있다. 다양한 실시예들에 따르면, 전술한 해당 구성요소들 중 하나 이상의 구성요소들 또는 동작들이 생략되거나, 또는 하나 이상의 다른 구성요소들 또는 동작들이 추가될 수 있다. 대체적으로 또는 추가적으로, 복수의 구성요소들(예: 모듈 또는 프로그램)은 하나의 구성요소로 통합될 수 있다. 이런 경우, 통합된 구성요소는 복수의 구성요소들 각각의 구성요소의 하나 이상의 기능들을 통합 이전에 복수의 구성요소들 중 해당 구성요소에 의해 수행되는 것과 동일 또는 유사하게 수행할 수 있다. 다양한 실시예들에 따르면, 모듈, 프로그램 또는 다른 구성요소에 의해 수행되는 동작들은 순차적으로, 병렬적으로, 반복적으로, 또는 휴리스틱하게 실행되거나, 동작들 중 하나 이상이 다른 순서로 실행되거나, 생략되거나, 또는 하나 이상의 다른 동작들이 추가될 수 있다.

Claims (15)

  1. 분산 데이터베이스를 공유하는 블록체인 네트워크를 구성하는 노드 중 일부 노드가 속한 제1 그룹을 관리하는 노드 그룹 관리 장치에 있어서-상기 블록체인 네트워크에 참여하는 모든 노드는 각각 비밀키 및 공개키를 보유함-,
    상기 블록체인 네트워크와 통신하는 통신 인터페이스;
    상기 제1 그룹의 노드에 관한 정보 및 프로세서의 동작 수행에 관한 명령어를 저장하는 하나 이상의 메모리- 상기 제1 그룹의 노드에 관한 정보는 상기 제1 그룹의 노드 각각의 공개키를 포함함-; 및
    상기 명령어를 통해 동작하도록 상기 하나 이상의 메모리와 연결되고, 상기 제1 그룹의 노드가 트랜잭션을 생성하는 경우 상기 트랜잭션에 상기 비밀키의 서명과 함께, 상기 제1 그룹의 노드에 관한 정보를 기초로 상기 트랜잭션에 추가적인 서명을 수행하도록 하는 그룹 비밀키를 생성하여, 상기 제1 그룹의 노드가 공통적으로 보유하도록 상기 그룹 비밀키를 상기 제1 그룹에 배포하는 동작을 수행하는 하나 이상의 프로세서를 포함하는,
    노드 그룹 관리 장치.
  2. 제1항에 있어서,
    상기 하나 이상의 프로세서는,
    상기 제1 그룹의 노드 중 일부 노드의 공개키 및 시간 정보를 기초로 상기 그룹 비밀키를 생성하는,
    노드 그룹 관리 장치.
  3. 제2항에 있어서,
    상기 하나 이상의 프로세서는,
    상기 일부 노드의 공개키가 각각 일련의 비트열이 되도록 소정의 해쉬 생성 알고리즘을 기초로 변환하고, 상기 각각의 일련의 비트열에 소정의 비트 연산(bitwise operation)을 수행하여 하나의 합성된 비트열이 변환하고, 상기 시간 정보를 비트열로 구성 후 상기 합성된 비트열과 연결하여, 상기 비밀키와 동일한 비트수를 갖는 상기 그룹 비밀키를 생성하는,
    노드 그룹 관리 장치.
  4. 제3항에 있어서,
    상기 하나 이상의 프로세서는,
    소정의 주기 마다 새로운 시간 정보를 기초로 상기 그룹 비밀키를 새롭게 생성하여 상기 제1 그룹에 배포하고,
    상기 소정의 주기는 상기 블록체인 네트워크 상에서 데이터가 모두 배포되는 통신 딜레이 시간보다 긴,
    노드 그룹 관리 장치.
  5. 제3항에 있어서,
    상기 하나 이상의 프로세서는,
    상기 제1 그룹에 변경이 발생할 경우, 상기 변경이 일어난 제1 그룹의 노드 중 일부의 공개키에 대한 정보를 기초로 상기 그룹 비밀키를 새롭게 생성하여 상기 그룹에 배포하는,
    노드 그룹 관리 장치.
  6. 제1항에 있어서,
    상기 하나 이상의 프로세서는,
    소정의 주기로 상기 그룹 비밀키를 새롭게 생성하여 상기 제1 그룹의 노드에 배포하고,
    상기 제1 그룹의 노드는,
    상기 배포된 그룹 비밀키를 수신한 시각 정보와 함께 복수의 그룹 비밀키를 저장하고, 상기 트랜잭션을 생성하는 경우 상기 복수의 그룹 비밀키 중 현재 주기로부터 기 설정된 주기 이전에 생성된 그룹 비밀키를 이용하여 서명하는,
    노드 그룹 관리 장치.
  7. 제6항에 있어서,
    상기 트랜잭션은,
    메시지, 상기 메시지에 대해 상기 비밀키를 통한 제1 서명, 상기 비밀키와 대응되는 공개키, 상기 메시지에 대해 상기 그룹 비밀키를 통한 제2 서명 및 상기 그룹 비밀키와 대응되는 그룹 공개키를 포함하는,
    노드 그룹 관리 장치.
  8. 제6항에 있어서,
    상기 하나 이상의 프로세서는,
    소정의 주기로 생성된 상기 그룹 비밀키와 대응되는 그룹 공개키를 생성하여 상기 블록체인 네트워크의 다른 그룹인 제2 그룹에 배포하고,
    상기 제2 그룹의 노드는,
    상기 배포된 그룹 공개키를 수신한 시각 정보와 함께 복수의 그룹 공개키를 저장하고, 상기 제1 그룹의 노드가 생성한 트랜잭션을 검증하는 경우 상기 복수의 그룹 공개키를 모두 사용하여, 상기 제1 그룹의 노드가 생성한 트랜잭션을 검증하는,
    노드 그룹 관리 장치.
  9. 분산 데이터베이스를 공유하는 블록체인 네트워크를 구성하는 노드를 수행하는 컴퓨팅 장치에 있어서-상기 블록체인 네트워크에 참여하는 모든 노드는 각각 비밀키 및 공개키를 보유함-,
    상기 블록체인 네트워크와 통신하는 통신 인터페이스;
    상기 하나의 노드가 속한 제1 그룹을 관리하는 제1항의 노드 그룹 장치에 관한 정보, 상기 노드 그룹 장치가 시간이 흐름에 따라 배포한 복수의 그룹 비밀키, 및 프로세서의 동작 수행에 관한 명령어를 저장하는 하나 이상의 메모리-상기 복수의 그룹 비밀키는 시간 정보를 포함함-; 및
    상기 명령어를 통해 동작하도록 상기 하나 이상의 메모리와 연결되고, 트랜잭션을 생성하는 경우 상기 시간 정보를 참조하여, 상기 복수의 그룹 비밀키 중 가장 최신으로 저장된 그룹 비밀키로부터 기 설정된 주기 이전에 생성된 그룹 비밀키를 이용한 서명을 상기 트랜잭션에 포함시키는 동작을 수행하는 하나 이상의 프로세서를 포함하는,
    컴퓨팅 장치.
  10. 분산 데이터베이스를 공유하는 블록체인 네트워크를 구성하는 노드 및 노드 그룹 관리 장치에 의해 수행되는 노드 그룹 관리 방법에 있어서-상기 블록체인 네트워크를 구성하는 모든 노드는 각각의 비밀키 및 공개키를 보유함-,
    상기 노드 그룹 관리 장치가, 제1 그룹의 노드에 관한 정보를 상기 제1 그룹의 노드로부터 수신하는 단계- 상기 제1 그룹은 상기 장치가 관리하는 노드들이 포함된 그룹이고, 상기 제1 그룹의 노드에 관한 정보는 상기 제1 그룹의 노드 각각의 공개키를 포함함-;
    상기 노드 그룹 관리 장치가, 상기 제1 그룹의 노드가 트랜잭션을 생성하는 경우 상기 제1 그룹의 노드에 관한 정보를 기초로 상기 비밀키와 함께 추가적인 서명으로 사용되는 그룹 비밀키를 생성하는 단계; 및
    상기 노드 그룹 관리 장치가, 상기 제1 그룹의 노드가 공통적으로 보유하도록 상기 그룹 비밀키를 상기 제1 그룹의 노드에 배포하는 단계를 포함하는
    노드 그룹 관리 방법.
  11. 제10항에 있어서,
    상기 그룹 비밀키를 생성하는 단계는,
    상기 일부 노드의 공개키가 각각 일련의 비트열이 되도록 소정의 해쉬 생성 알고리즘을 기초로 변환하고, 상기 각각의 일련의 비트열에 소정의 비트 연산(bitwise operation)을 수행하여 하나의 합성된 비트열이 변환하고, 상기 시간 정보를 비트열로 구성 후 상기 합성된 비트열과 연결하여, 상기 비밀키와 동일한 비트수를 갖는 상기 그룹 비밀키를 생성하는 단계를 포함하는,
    노드 그룹 관리 방법.
  12. 제10항에 있어서,
    상기 배포하는 단계는,
    상기 노드 그룹 관리 장치가, 소정의 주기로 상기 그룹 비밀키를 새롭게 생성하여 상기 제1 그룹의 노드에 배포하는 단계를 포함하고,
    상기 방법은,
    상기 제1 그룹의 노드가, 상기 배포된 그룹 비밀키를 수신한 시각 정보와 함께 복수의 그룹 비밀키를 저장하고, 상기 트랜잭션을 생성하는 경우 상기 복수의 그룹 비밀키 중 현재 주기로부터 기 설정된 주기 이전에 생성된 그룹 비밀키를 이용하여 서명하는 단계를 포함하는,
    노드 그룹 관리 방법.
  13. 제12항에 있어서,
    상기 배포하는 단계는,
    소정의 주기로 생성된 상기 그룹 비밀키와 대응되는 그룹 공개키를 생성하여 상기 블록체인 네트워크의 다른 그룹인 제2 그룹에 배포하는 단계를 포함하고,
    상기 방법은,
    상기 제2 그룹의 노드가, 상기 배포된 그룹 공개키를 수신한 시각 정보와 함께 복수의 그룹 공개키를 저장하는 단계; 및
    상기 제2 그룹의 노드가, 상기 제1 그룹의 노드가 생성한 트랜잭션을 검증하는 경우 상기 복수의 그룹 공개키를 모두 사용하여 상기 제1 그룹의 노드가 생성한 트랜잭션을 검증하는 단계를 더 포함하는,
    노드 그룹 관리 방법.
  14. 제10항 내지 제13항 중 어느 한 항의 방법을 프로세서가 수행하게 하는 명령어를 포함하는 컴퓨터 프로그램이 기록된 컴퓨터 판독 가능 기록매체.
  15. 제10항 내지 제13항 중 어느 한 항의 방법을 프로세서가 수행하도록 하는 컴퓨터 판독 가능 기록매체에 저장된 컴퓨터 프로그램.
PCT/KR2019/001731 2018-07-27 2019-02-13 블록체인 네트워크 상에서 그룹키 기반의 이중 서명 트랜잭션 구조를 구성하는 노드 그룹 관리 장치 및 컴퓨팅 장치 WO2020022599A1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2021505768A JP2021533638A (ja) 2018-07-27 2019-02-13 ブロックチェーンネットワーク上でグループ鍵基盤の二重署名トランザクション構造を構成するノードグループ管理装置およびコンピューティング装置
CN201980063538.8A CN112913185A (zh) 2018-07-27 2019-02-13 在区块链网络上构建基于组密钥的双重签名交易结构的节点组管理装置以及计算装置
US17/159,021 US20210258154A1 (en) 2018-07-27 2021-01-26 Node group managing device and computing device for configuring group key-based dual signature transaction structure in blockchain network

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201862703896P 2018-07-27 2018-07-27
US62/703,896 2018-07-27
KR1020190014619A KR102120703B1 (ko) 2018-07-27 2019-02-07 블록체인 네트워크 상에서 그룹키 기반의 이중 서명 트랜잭션 구조를 구성하는 노드 그룹 관리 장치 및 컴퓨팅 장치
KR10-2019-0014619 2019-02-07

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/159,021 Continuation US20210258154A1 (en) 2018-07-27 2021-01-26 Node group managing device and computing device for configuring group key-based dual signature transaction structure in blockchain network

Publications (1)

Publication Number Publication Date
WO2020022599A1 true WO2020022599A1 (ko) 2020-01-30

Family

ID=69181845

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2019/001731 WO2020022599A1 (ko) 2018-07-27 2019-02-13 블록체인 네트워크 상에서 그룹키 기반의 이중 서명 트랜잭션 구조를 구성하는 노드 그룹 관리 장치 및 컴퓨팅 장치

Country Status (1)

Country Link
WO (1) WO2020022599A1 (ko)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111431728A (zh) * 2020-03-30 2020-07-17 腾讯科技（深圳）有限公司 一种分布式应用程序的用户群组管理方法
CN111524012A (zh) * 2020-05-06 2020-08-11 杭州复杂美科技有限公司 数据延时公布方法、设备和存储介质
CN111523895A (zh) * 2020-05-06 2020-08-11 杭州复杂美科技有限公司 数据延时公布方法、设备和存储介质
CN111523894A (zh) * 2020-05-06 2020-08-11 杭州复杂美科技有限公司 数据延时公布方法、设备和存储介质
CN112199382A (zh) * 2020-05-28 2021-01-08 支付宝(杭州)信息技术有限公司 在联盟链网络中创建节点组、基于节点组的交易方法
WO2021239072A1 (zh) * 2020-05-28 2021-12-02 支付宝(杭州)信息技术有限公司 在联盟链网络中创建节点组、基于节点组的交易方法
JP2022041950A (ja) * 2020-09-01 2022-03-11 ソブリン ウォレット カンパニー，リミテッド それぞれが身元元帳とデジタル通貨元帳とを含む複数のバンクノードを含むブロックチェーンシステムとその作動方法
WO2022202865A1 (ja) * 2021-03-24 2022-09-29 株式会社デンソー 分散型台帳システム及び方法
DE102022111959A1 (de) 2022-05-12 2023-11-16 KETEK GmbH Halbleiter- und Reinraumtechnik Ionisationsdetektor und Detektionsverfahren
DE102023112454A1 (de) 2022-05-12 2023-11-16 KETEK GmbH Halbleiter- und Reinraumtechnik Filteranlage und Trennverfahren
DE102022005104A1 (de) 2022-05-12 2024-01-04 KETEK GmbH Halbleiter- und Reinraumtechnik Ionisationsdetektor und Detektionsverfahren
CN117579256A (zh) * 2023-10-12 2024-02-20 智慧工地科技(广东)有限公司 一种物联网数据管理方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110047202A1 (en) * 2009-08-18 2011-02-24 Microsoft Corporation Distributed algorithm for changing a shared value
US20170180122A1 (en) * 2015-12-17 2017-06-22 Intel Corporation Privacy Preserving Group Formation with Distributed Content Key Generation
WO2017145010A1 (en) * 2016-02-23 2017-08-31 nChain Holdings Limited Secure multiparty loss resistant storage and transfer of cryptographic keys for blockchain based systems in conjunction with a wallet management system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110047202A1 (en) * 2009-08-18 2011-02-24 Microsoft Corporation Distributed algorithm for changing a shared value
US20170180122A1 (en) * 2015-12-17 2017-06-22 Intel Corporation Privacy Preserving Group Formation with Distributed Content Key Generation
WO2017145010A1 (en) * 2016-02-23 2017-08-31 nChain Holdings Limited Secure multiparty loss resistant storage and transfer of cryptographic keys for blockchain based systems in conjunction with a wallet management system

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
LEI AO: "A Secure Key Management Scheme for Heterogeneous Secure Vehicular Communication Systems", ZTE COMMUNICATIONS, vol. 14, 13 June 2016 (2016-06-13), XP055680051 *
XIAOZHOU STEVE LI: "Batch Rekeying for Secure Group Communications", 10TH INTERNATIONAL WORLD WIDE WEB CONFERENCE, Hong Kong, pages 525 - 534, XP058105240 *

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111431728A (zh) * 2020-03-30 2020-07-17 腾讯科技（深圳）有限公司 一种分布式应用程序的用户群组管理方法
CN111431728B (zh) * 2020-03-30 2024-02-09 腾讯科技（深圳）有限公司 一种分布式应用程序的用户群组管理方法
CN111524012A (zh) * 2020-05-06 2020-08-11 杭州复杂美科技有限公司 数据延时公布方法、设备和存储介质
CN111523895A (zh) * 2020-05-06 2020-08-11 杭州复杂美科技有限公司 数据延时公布方法、设备和存储介质
CN111523894A (zh) * 2020-05-06 2020-08-11 杭州复杂美科技有限公司 数据延时公布方法、设备和存储介质
CN112199382B (zh) * 2020-05-28 2023-12-15 支付宝(杭州)信息技术有限公司 在联盟链网络中创建节点组、基于节点组的交易方法
CN112199382A (zh) * 2020-05-28 2021-01-08 支付宝(杭州)信息技术有限公司 在联盟链网络中创建节点组、基于节点组的交易方法
WO2021239072A1 (zh) * 2020-05-28 2021-12-02 支付宝(杭州)信息技术有限公司 在联盟链网络中创建节点组、基于节点组的交易方法
JP2022041950A (ja) * 2020-09-01 2022-03-11 ソブリン ウォレット カンパニー，リミテッド それぞれが身元元帳とデジタル通貨元帳とを含む複数のバンクノードを含むブロックチェーンシステムとその作動方法
WO2022202865A1 (ja) * 2021-03-24 2022-09-29 株式会社デンソー 分散型台帳システム及び方法
DE102023112454A1 (de) 2022-05-12 2023-11-16 KETEK GmbH Halbleiter- und Reinraumtechnik Filteranlage und Trennverfahren
DE102022111959A1 (de) 2022-05-12 2023-11-16 KETEK GmbH Halbleiter- und Reinraumtechnik Ionisationsdetektor und Detektionsverfahren
DE102022005104A1 (de) 2022-05-12 2024-01-04 KETEK GmbH Halbleiter- und Reinraumtechnik Ionisationsdetektor und Detektionsverfahren
CN117579256A (zh) * 2023-10-12 2024-02-20 智慧工地科技(广东)有限公司 一种物联网数据管理方法及装置
CN117579256B (zh) * 2023-10-12 2024-04-23 智慧工地科技(广东)有限公司 一种物联网数据管理方法及装置

Similar Documents

Publication Publication Date Title
WO2020022599A1 (ko) 블록체인 네트워크 상에서 그룹키 기반의 이중 서명 트랜잭션 구조를 구성하는 노드 그룹 관리 장치 및 컴퓨팅 장치
WO2021060854A1 (ko) 네트워크 접속 제어 시스템 및 그 방법
WO2020022760A1 (ko) 시스템에 포함되는 노드들에 대하여 그룹을 운영하는 분산 네트워크 시스템
WO2021071157A1 (en) Electronic device and method for managing blockchain address using the same
WO2018030707A1 (ko) 인증 시스템 및 방법과 이를 수행하기 위한 사용자 단말, 인증 서버 및 서비스 서버
WO2023033586A1 (ko) Tcp 세션 제어에 기초하여 애플리케이션의 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
WO2022231306A1 (ko) 컨트롤러 기반의 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
WO2017135669A1 (ko) 파일에 대한 노터리 서비스를 제공하고 상기 노터리 서비스를 사용하여 기록된 파일에 대한 검증을 수행하는 방법 및 서버
WO2020189926A1 (ko) 블록체인 네트워크를 이용하여 사용자의 아이덴티티를 관리하는 방법 및 서버, 그리고, 블록체인 네트워크 기반의 사용자 아이덴티티를 이용하여 사용자를 인증하는 방법 및 단말
WO2020189927A1 (ko) 블록체인 네트워크를 이용하여 사용자의 아이덴티티를 관리하는 방법 및 서버, 그리고, 블록체인 네트워크 기반의 사용자 아이덴티티를 이용하여 사용자를 인증하는 방법 및 단말
WO2020220413A1 (zh) 个人信息的零知识证明方法、系统及存储介质
WO2018124718A1 (ko) 블록체인 내의 블록별로 밸런스 데이터베이스를 관리하여 통합 포인트 서비스를 제공하는 방법 및 이를 이용한 지원 서버
WO2022131441A1 (ko) 블록체인 네트워크를 이용하여 웹페이지를 저장 및 검증하는 방법 및 시스템
WO2023146308A1 (ko) 컨트롤러 기반의 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
WO2020189800A1 (ko) 블록체인에서 생성된 데이터를 인증하는 방법 및 시스템
WO2020027408A1 (ko) 암호화폐 교환을 위한 트랜잭션을 매칭하는 전자 장치 및 방법
WO2018124716A1 (ko) Utxo 기반 프로토콜에서 머클 트리 구조를 사용하여 통합 포인트 서비스를 제공하는 방법 및 이를 이용한 지원 서버
WO2023085793A1 (ko) 컨트롤러 기반의 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
WO2023090755A1 (ko) 가상화 인스턴스의 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
WO2020141782A1 (ko) 블록체인 네트워크를 이용하여 사용자의 아이덴티티를 관리하는 방법 및 서버, 그리고, 블록체인 네트워크 기반의 사용자 아이덴티티를 이용하여 사용자를 인증하는 방법 및 단말
WO2023211104A1 (ko) 컨트롤러 기반 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
WO2022231304A1 (ko) 컨트롤러 기반의 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
WO2020130331A1 (ko) 블록체인에서 노드들간 블록 및 전자 문서를 공유 및 검증하는 방법
WO2021194114A1 (ko) 전자 지갑과 상기 전자 지갑을 이용하여 두개의 서로 다른 블록체인 토큰들의 원자성 교환 방법
WO2021177639A1 (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: 19840209

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021505768

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 06.07.2021)

122 Ep: pct application non-entry in european phase

Ref document number: 19840209

Country of ref document: EP

Kind code of ref document: A1