WO2020189800A1 - 블록체인에서 생성된 데이터를 인증하는 방법 및 시스템 - Google Patents

블록체인에서 생성된 데이터를 인증하는 방법 및 시스템 Download PDF

Info

Publication number
WO2020189800A1
WO2020189800A1 PCT/KR2019/003001 KR2019003001W WO2020189800A1 WO 2020189800 A1 WO2020189800 A1 WO 2020189800A1 KR 2019003001 W KR2019003001 W KR 2019003001W WO 2020189800 A1 WO2020189800 A1 WO 2020189800A1
Authority
WO
WIPO (PCT)
Prior art keywords
chain
leaf
blockchain network
data
contract
Prior art date
Application number
PCT/KR2019/003001
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
Application filed by 라인플러스 주식회사 filed Critical 라인플러스 주식회사
Priority to KR1020247001901A priority Critical patent/KR20240011890A/ko
Priority to PCT/KR2019/003001 priority patent/WO2020189800A1/ko
Priority to JP2021555454A priority patent/JP7304963B2/ja
Priority to KR1020217022073A priority patent/KR102627868B1/ko
Publication of WO2020189800A1 publication Critical patent/WO2020189800A1/ko

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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • 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
    • 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
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the description below relates to a method and system for authenticating data generated in a blockchain.
  • Block-chain is an electronic ledger and is implemented as a computer-based distributed, peer-to-peer (P2P) system composed of blocks for transactions.
  • Each transaction (Tx) is a data structure that encodes the control transfer of digital assets between participants in the blockchain system, and includes at least one input and at least one output.
  • Each block, including the hash of the previous block, is linked together to create a permanent, unalterable record of all transactions recorded on the blockchain from the beginning.
  • Korean Patent Application Publication No. 10-2018-0113143 discloses a blockchain-based user-defined currency transaction system and its operation method. This blockchain itself does not scale out. For example, even if a node to generate a block is added in a blockchain network, the cost of consensus for block generation increases, but the block generation speed for transactions does not increase.
  • It provides a data authentication method and system that authenticates data generated in a blockchain that can be scaled out by adding a leaf chain based on the root chain.
  • a method for authenticating data of a node implemented by a computer device participating in a blockchain network wherein a private key representing a chain of the blockchain network is transmitted to the block by at least one processor included in the computer device. Sharing with at least one other node participating in the chain network; Generating, by the at least one processor, a public address of the blockchain network using the private key; Signing, by the at least one processor, data to be transferred from the blockchain network to another blockchain network with the private key through a contract installed in the blockchain network; And transmitting, by the at least one processor, the signed data to another blockchain network through the contract, wherein the signed data is converted to the blockchain through comparison between the signed data and the public address. It provides a data authentication method, characterized in that it is verified that it is sent through a network.
  • the blockchain network includes a root chain for managing data transmission between a plurality of leaf chains
  • the data authentication method includes, by the at least one processor, the generated public address as the plurality of leaf chains. It may be characterized in that it further comprises the step of writing to the genesis (genesis) block of each of the chains.
  • the signed data is sent from the root chain by comparing the signed data with the public address recorded in the genesis block of the leaf chain in the leaf chain receiving the signed data. You can do it.
  • the blockchain network includes a first leaf chain among a plurality of leaf chains in which data transmission is managed by a root chain, and the data authentication method is generated by the at least one processor. It may be characterized in that it further comprises the step of registering the established public address in a leaf chain contract installed in association with the first leaf chain in the root chain.
  • the signed data in the root chain may be characterized in that it is verified that the signed data is sent from the first leaf chain.
  • a method for authenticating data of a node implemented by a computer device participating in a blockchain network comprising: generating, by at least one processor included in the computer device, a public address of the node using a private key of the node; Signing, by the at least one processor, data to be transferred from the blockchain network to another blockchain network using the private key of the node; And transmitting the signed data to the other blockchain network by the at least one processor, and verifying that the signed data is sent through the blockchain network using the public address. It provides a data authentication method, characterized in that.
  • It provides a computer-readable recording medium, characterized in that a computer program for executing the method in a computer device is recorded.
  • a computer device implementing a node of a blockchain network comprising at least one processor implemented to execute an instruction readable by the computer device, and representing a chain of the blockchain network by the at least one processor Share a private key with at least one other node participating in the blockchain network, generate a public address of the blockchain network using the private key, and from the blockchain network to another blockchain network.
  • the data to be transferred is signed with the private key through a contract installed in the blockchain network, the signed data is transferred to another blockchain network through the contract, and the signed data is compared with the public address. It provides a computer device, characterized in that it is verified that the signed data is sent through the blockchain network.
  • a computer device implementing a node of a blockchain network comprising at least one processor implemented to execute a command readable by the computer device, and the at least one processor uses the node's private key.
  • Create a public address of a node sign data to be transmitted from the blockchain network to another blockchain network using the node's private key, deliver the signed data to the other blockchain network, and the public It provides a computer device, characterized in that it is verified that the signed data is sent through the blockchain network using an address.
  • FIG. 1 is a diagram showing an example of a network environment according to an embodiment of the present invention.
  • FIG. 2 is a block diagram showing an example of a computer device according to an embodiment of the present invention.
  • FIG. 3 is a diagram showing an example of a general configuration of an expandable blockchain network according to an embodiment of the present invention.
  • FIG. 4 is a diagram showing an example of a detailed configuration of a transaction processing system according to an embodiment of the present invention.
  • FIG. 5 is a flowchart illustrating an example of a process of adding a new leaf chain according to an embodiment of the present invention.
  • FIG. 7 is a flow chart showing an example of a process of issuing coins to a service according to an embodiment of the present invention.
  • FIG. 8 is a flow chart showing an example of a coin exchange process in an embodiment of the present invention.
  • FIG. 9 is a diagram illustrating the flow of coin exchange data through smart contracts between chains in an embodiment of the present invention.
  • FIG. 10 is a diagram showing an example of a process of installing a signable contract according to an embodiment of the present invention.
  • FIG. 11 is a diagram illustrating an example of a process of signing data according to an embodiment of the present invention.
  • FIG. 12 is a diagram illustrating another example of a process of installing a signable contract according to an embodiment of the present invention.
  • FIG. 13 is a diagram illustrating another example of a process of signing data according to an embodiment of the present invention.
  • FIG. 14 is a diagram showing another example of a coin exchange process according to an embodiment of the present invention.
  • 15 is a flowchart illustrating a first example of a data authentication method according to an embodiment of the present invention.
  • 16 is a flow chart illustrating a second example of a data authentication method according to an embodiment of the present invention.
  • 17 is a flowchart illustrating a third example of a data authentication method according to an embodiment of the present invention.
  • FIG. 18 is a flowchart showing a fourth example of a data authentication method according to an embodiment of the present invention.
  • the data authentication system may be implemented by at least one computer device.
  • a computer program according to an embodiment of the present invention may be installed and driven in a computer device, and the computer device may perform a data authentication method according to an embodiment of the present invention under control of the driven computer program.
  • the above-described computer program may be combined with a computer device and stored in a computer-readable recording medium to execute a data authentication method on the computer device.
  • the computer program described herein may have a form of an independent program package, or a form of an independent program package may be pre-installed on a computer device to be linked to an operating system or other program packages.
  • FIG. 1 is a diagram showing an example of a network environment according to an embodiment of the present invention.
  • the network environment of FIG. 1 shows an example including a plurality of electronic devices 110, 120, 130, and 140, a plurality of servers 150 and 160, and a network 170. 1 is an example for explaining the present invention, and the number of electronic devices or servers is not limited as in FIG. 1.
  • the network environment of FIG. 1 is only for describing one example of environments applicable to the embodiments, and the environment applicable to the embodiments is not limited to the network environment of FIG. 1.
  • the plurality of electronic devices 110, 120, 130, and 140 may be a fixed terminal implemented as a computer device or a mobile terminal.
  • Examples of the plurality of electronic devices 110, 120, 130, 140 include smart phones, mobile phones, navigation, computers, notebook computers, digital broadcasting terminals, personal digital assistants (PDAs), portable multimedia players (PMPs). ), tablet PC, etc.
  • PDAs personal digital assistants
  • PMPs portable multimedia players
  • FIG. 1 the shape of a smartphone is shown as an example of the electronic device 1 110, but in the embodiments of the present invention, the electronic device 1 110 substantially connects the network 170 using a wireless or wired communication method. Through this, it may mean one of various physical computer devices capable of communicating with other electronic devices 120, 130, and 140 and/or the servers 150 and 160.
  • the communication method is not limited, and short-range wireless communication between devices as well as a communication method using a communication network (for example, a mobile communication network, a wired Internet, a wireless Internet, a broadcasting network) that the network 170 may include may be included.
  • the network 170 includes a personal area network (PAN), a local area network (LAN), a campus area network (CAN), a metropolitan area network (MAN), a wide area network (WAN), and a broadband network (BBN). , Internet, and the like.
  • the network 170 may include any one or more of a network topology including a bus network, a star network, a ring network, a mesh network, a star-bus network, a tree or a hierarchical network, etc. Not limited.
  • FIG. 2 is a block diagram showing an example of a computer device according to an embodiment of the present invention.
  • Each of the plurality of electronic devices 110, 120, 130, and 140 described above or each of the servers 150 and 160 may be implemented by the computer apparatus 200 shown in FIG. 2, and an embodiment of the present invention The method according to these can be performed by such a computer device 200.
  • the computer device 200 may include a memory 210, a processor 220, a communication interface 230, and an input/output interface 240.
  • the memory 210 is a computer-readable recording medium and may include a permanent mass storage device such as a random access memory (RAM), read only memory (ROM), and a disk drive.
  • a non-destructive large-capacity recording device such as a ROM and a disk drive may be included in the computer device 200 as a separate permanent storage device separated from the memory 210.
  • an operating system and at least one program code may be stored in the memory 210. These software components may be loaded into the memory 210 from a computer-readable recording medium separate from the memory 210.
  • Such a separate computer-readable recording medium may include a computer-readable recording medium such as a floppy drive, disk, tape, DVD/CD-ROM drive, and memory card.
  • software components may be loaded into the memory 210 through a communication interface 230 other than a computer-readable recording medium.
  • software components may be loaded into the memory 210 of the computer device 200 based on a computer program installed by files received through the network 170.
  • the processor 220 may be configured to process instructions of a computer program by performing basic arithmetic, logic, and input/output operations. Commands may be provided to the processor 220 by the memory 210 or the communication interface 230. For example, the processor 220 may be configured to execute a command received according to a program code stored in a recording device such as the memory 210.
  • the communication interface 230 may provide a function for the computer device 200 to communicate with other devices (eg, storage devices described above) through the network 170. For example, requests, commands, data, files, etc., generated by the processor 220 of the computer device 200 according to a program code stored in a recording device such as the memory 210, are transmitted through the network ( 170) can be transferred to other devices. Conversely, signals, commands, data, files, etc. from other devices may be received by the computer device 200 through the communication interface 230 of the computer device 200 via the network 170. Signals, commands, data, etc. received through the communication interface 230 may be transmitted to the processor 220 or the memory 210, and the file, etc. may be a storage medium (described above) that the computer device 200 may further include. Permanent storage).
  • the computer device 200 may include fewer or more components than the components of FIG. 2. However, there is no need to clearly show most of the prior art components.
  • the computer device 200 may be implemented to include at least some of the input/output devices 250 described above, or may further include other components such as a transceiver and a database.
  • the root chain 310 may be considered an absolute trust system, and each of the leaf chains 320 and 330 must prove to the root chain 310 that it is a trust system.
  • each of the leaf chains 320 and 330 may be associated with an individual service, and when a new service is added, a new leaf chain may be added.
  • FIG. 3 shows two leaf chains 320 and 330, three or more leaf chains may be included, which may mean that the blockchain can be expanded.
  • "service” may include an online service provided by the same or different subjects to their users through a network.
  • a plurality of leaf chains corresponding to each of the Internet banking services provided by a plurality of different banks may be configured.
  • a plurality of leaf chains corresponding to each of a plurality of different social network services may be configured.
  • Each of the leaf chains 320 and 330 must be trusted by writing a hash of the block to the root chain 310.
  • a merkle tree root hash may be used.
  • the root chain 310 does not exchange coins between users, and the coin exchange may be made within each of the leaf chains 320 and 330 and/or between the leaf chains 320 and 330. At this time, the exchange of coins between the leaf chains 320 and 330 may be mediated and managed by the root chain 310 through the relay 340.
  • Each of the leaf chains 320 and 330 may include at least one decentralized application (DApp).
  • DApp decentralized application refers to an application in which the backend code runs on a decentralized peer-to-peer network (or calls and registers data in a blockchain database) and provides it as an interface from the front end.
  • a chain and a smart contract irrelevant to coin exchange may be installed according to the needs of the DApp, and this may not be involved in the root chain 310.
  • permission for installation of the smart contract must be obtained through the root chain 310.
  • Interchain coin exchange using a smart contract that is not authorized by the root chain 310 may be restricted so as not to occur.
  • Coin exchange within each of the leaf chains 320 and 330 can be processed in each of the leaf chains 320 and 330 without having to go through the root chain 310, and a summary of all blocks containing the processed content Information (for example, the Merkle tree root hash described above) can be recorded in the root chain 310.
  • the coin exchange between the leaf chains 320 and 330 must be made through the root chain 310, and the processing of coin exchange in the block of each of the leaf chains 320 and 330 and the block of the root chain 310 Content should be recorded.
  • exchange of coins between the leaf chains 320 and 330 may be performed through the relay 340.
  • the root chain 310 may include a root chain manager contract 411, which is a smart contract for the root chain 310, and several leaf chains 320 and 330 included in the blockchain network 300 You can include smart contracts for each.
  • the root chain 310 is a leaf chain A contract (LeafChain A Contract, 412) and a leaf chain B (Leaf Chain B, 330), which are smart contracts for leaf chain A (320). It shows an example including the LeafChain B Contract (413), which is a smart contract for use.
  • each of the leaf chains 320 and 330 may include a smart contract for a DApp.
  • a leaf chain A 320 includes a dApp contract 421 and a leaf chain B 330 includes a dApp contract 431.
  • Leaf Chain A (320) is a smart contract for Leaf Chain A (320), a Leaf ChainManager Contract (422), and
  • Leaf Chain A (330) is a smart contract for Leaf Chain B (330).
  • a leaf chain manager contract 432 may be further included.
  • the relay 340 observes the block generation of the root chain 310 and leaf chains 320 and 330 while recording and/or transmitting information required in the root chain 310 and leaf chains 320 and 330 Can be invoked.
  • the relay 340 includes a Producer (441), Kafka (442), an InterChain Consumer (443), an InterChain Failover (444), and a database (Database, 445). I can.
  • the producer 441 may collect information on newly created blocks of all chains including the root chain 310 and input it to the Kafka 442.
  • Kafka 442 is a kind of queue server and may store collected information in a queue and provide sequentially.
  • the interchain consumer 443 may filter an event requiring an invocation for each chain. Multiple filtering may be required depending on the event.
  • the interchain consumer 443 invokes each chain, it can create a separate user for each chain for signification, and record the user's authority in the smart contract.
  • the interchain consumer 443 may detect the following events (1) to (7).
  • the interchain consumer 443 may detect the remittance request event in the leaf chain and transmit the remittance request content to the root chain.
  • the interchain consumer 443 may detect a remittance request event in the root chain and transmit the content of the remittance request to a leaf chain that will receive the remittance request.
  • the interchain consumer 443 may transmit, to the root chain, remittance failure information including identification information of the leaf chain that will receive the remittance request when delivery to the receiving leaf chain fails.
  • the interchain consumer 443 may transmit the details of the remittance failure to the leaf chain that requested the remittance.
  • the interchain consumer 443 can deliver the transfer completion details to the root chain.
  • the interchain consumer 443 may deliver the remittance completion details to the leaf chain that requested the remittance.
  • the interchain consumer 443 can deliver the content of issuance to the leaf chain where the coin is issued.
  • the interchain consumer 443 can deliver the Merkle tree root hash of the block to the root chain.
  • Interchain failover 444 can provide a failover function so that (3-1), (4-1), (5-1), (6-1) and (7-1) can be delivered normally.
  • a database (Database) 445 may be used to store information received and/or transmitted (transferred) from the interchain consumer 443 and the interchain failover 444.
  • FIG. 5 is a flowchart illustrating an example of a process of adding a new leaf chain according to an embodiment of the present invention.
  • the blockchain network 300 may build a leaf chain.
  • a new leaf chain can be built to add a new service, which will be described later.
  • the blockchain network 300 may install a contract (hereinafter referred to as a leaf chain contract) capable of processing the leaf chain in the root chain.
  • a leaf chain contract capable of processing the leaf chain in the root chain.
  • the blockchain network 300 may register the leaf chain contract address of the installed root chain in the root chain manager contract.
  • the address of a signing enable contract of the leaf chain may be further registered in the root chain manager contract.
  • a public address representing a leaf chain may be registered in the root chain manager contract.
  • the blockchain network 300 may add a relay user who can access the leaf chain contract of the root chain.
  • the blockchain network 300 may add a relay user who can access the leaf chain manager contract of the leaf chain.
  • the relay users in steps 550 and 560 may be the same user or different users. It can be advantageous in terms of security to set and use a separate relay user for each leaf chain and also for the root chain.
  • the relay user may correspond to an account of a service provided by the blockchain network 300.
  • FIG. 6 is a flowchart illustrating an example of a process of adding a new service according to an embodiment of the present invention.
  • the blockchain network 300 may install a contract for the service in the leaf chain.
  • the address of the installed contract can be used as a value that identifies the service.
  • the service may be a contract with an interchain coin exchange protocol.
  • the blockchain network 300 may register the address of the contract installed for the service in the leaf chain manager contract of the leaf chain.
  • a leaf chain manager contract can be installed in the leaf chain, which is responsible for remittance of coins between chains or between contracts.
  • the address of the contract for the service can be registered in the leaf chain manager contract.
  • the blockchain network 300 may register the address of the installed contract in the root chain manager contract of the root chain.
  • the address of the installed contract may be registered through the administrator authority of the root chain manager contract. If the address of the contract installed for the leaf chain service in the root chain manager contract is registered with the leaf chain contract of the leaf chain installed in the root chain, the leaf chain contract of the root chain also has the address of the contract installed for the leaf chain service. It can be registered as a service of the leaf chain.
  • FIG. 7 is a flow chart showing an example of a process of issuing coins to a service according to an embodiment of the present invention.
  • the root chain manager contract of the root chain may request coin issuance for the address of the contract for the service registered in the leaf chain contract installed in the root chain.
  • the root chain manager contract of the root chain can identify the corresponding service through the address of the contract for the service to issue coins through the leaf chain contract installed on the root chain, and the coin issuance event for the identified service. Can occur.
  • the interchain consumer may detect a coin issuance event for the corresponding service and request a coin issuance of the service to the leaf chain manager contract of the corresponding leaf chain.
  • the leaf chain manager contract can find a corresponding service and issue a coin.
  • the coin may be issued to the service operator (for example, the relay user added in step 560 of FIG. 5) input when installing the contract for the service.
  • FIG. 8 is a flow chart showing an example of a coin exchange process in an embodiment of the present invention.
  • Coin exchange in the same service on the same chain can be done through a smart contract for coin exchange on the leaf chain.
  • exchange of coins between different services of the same chain can be performed through the leaf chain manager contract of the corresponding leaf chain.
  • remittance from the first service of the same chain to the second service may be performed by a leaf chain manager contract calling the address of the contract of the second service according to the remittance request of the first service.
  • the coin exchange result can be transmitted to the root chain. This is to enable the root chain to understand the changes in the amount of coins held by each service of the leaf chains.
  • leaf chain A 320 may receive a coin exchange request (remittance request) for user b of leaf chain B 330 of user a. At this time, the leaf chain A 320 may determine the balance of the user a and record the coin exchange request in the block of the leaf chain A 320 when the coin exchange request is a normal request. The coins requested for exchange (coins requested for remittance) may be deducted from the balance of user a by the leaf chain manager contract included in the leaf chain A 320 and may be locked so as not to be used.
  • the leaf chain manager contract of leaf chain A (320) checks the balance of user a and the service requesting remittance as much as the amount requested for remittance, and then the amount deducted from the currency volume of leaf chain A (320) is not used. You can set a lock to prevent it. Information on the amount of the deducted user a may be recorded in the escrow contract. A record of the success of such remittance may be recorded in Kafka 442 by producer 441. If the remittance request is not normal, the leaf chain A 320 may record the failure of the remittance request in a block. In addition, leaf chain A 320 may prevent remittance from occurring by not recording an event when the remittance request fails.
  • the interchain consumer 443 may detect a remittance request event from the leaf chain A 320 to the leaf chain B 330, and transmit the remittance request to the root chain 310.
  • the detection of the remittance request event may be detected by the producer 441 collecting transactions, and the interchain consumer 443 may transmit the remittance request to the root chain 310 in response to detection of the detected remittance request event. .
  • the root chain 310 analyzes the total amount of coins issued by the leaf chain A 320 using the remittance request information to check whether the remittance request is a normal request, and the remittance request is a normal request.
  • a request for coin exchange from leaf chain A 320 to leaf chain B 330 may be recorded in a block.
  • the exchange request can be locked so that the amount of coins being transferred is not used.
  • the root chain 310 may record failure details in a block when the corresponding remittance request is not a normal request.
  • the remittance request recorded as a failure may be detected as a remittance failure event in the interchain consumer 443 again and transmitted to the leaf chain A 320, and the leaf chain A 320 receiving the remittance failure event receives the locked coin. It can be released and returned back to user a.
  • the interchain consumer 443 may detect a remittance request event from the root chain 310 to the leaf chain B 330, and transmit a corresponding remittance request to the leaf chain B 330. If the invocation fails because the leaf chain B 330 does not operate normally, the contents of the transmission failure due to the system error of the leaf chain B 330 may be transmitted to the root chain 310 again. The request recorded as a failure can be detected as a remittance failure event in the interchain consumer 443 again and transmitted to the leaf chain A 320, and the leaf chain A 320 receiving the remittance failure event unlocks the locked coin. You can return it back to user a.
  • step 850 when the remittance request is a normal request, the leaf chain B 330 may remit the coin to the user b and increase the total amount of currency of the leaf chain B 330 by the amount of the remitted coin. If the remittance request fails, the details of the failure can be recorded in the block.
  • the interchain consumer 443 may detect the result of remittance completion of the leaf chain B as an event, and transmit a hash and success or failure to the root chain 310.
  • the root chain 310 may receive the remittance result and process it according to the remittance failure and remittance success, and record the result in a block along with a hash. If the remittance is successful, the root chain 310 may release the locked coin remittance request, proceed with remittance from the leaf chain A 320 to the leaf chain B 330 and change the amount of each currency. If the remittance fails, the root chain 310 may release the locked coin remittance request and return it to the leaf chain A 320 again.
  • the interchain consumer 443 may detect the remittance result event processed by the root chain 310 and transmit the result to the leaf chain A 320.
  • the leaf chain A 320 receives the remittance result and, if successful, unlocks the locked coin and adjusts the total amount of money of the leaf chain A 320 (subtracts the total amount of money by the amount of remittance). If the remittance fails, the leaf chain A 320 may release the locked coin and return it to the user a again. Leaf chain A 320 may record the result of this transfer in a block along with a hash recorded in the root chain 310.
  • FIG. 9 is a diagram illustrating the flow of coin exchange data through smart contracts between chains in an embodiment of the present invention.
  • Leaf Chain Manager Contract A 910 creates an exchange transaction hash (eTxHash), exchange transaction hash, user a (identifier of) and service a (identifier of), and service b (identifier of) and user b to be remitted. (Identifier of), amount information (remittance amount), and/or request time can be recorded (remittance request record (escrow information)).
  • the leaf chain manager contract A (910) may deduct the total amount of currency of the contract of the DApp 1 (920) and the amount held by the user a.
  • the producer 441 may collect the transaction generated in (1), and the interchain consumer 443 may request a remittance to the leaf chain A contract 412 of the root chain 310.
  • the leaf chain A contract 412 may separately record remittance request information for the root chain 310 through the root chain manager contract 411. At this time, the total amount of money of the DApp 1 920 managed by the leaf chain manager A contract 412 may be deducted by the amount of remittance.
  • the producer 441 can collect the transaction created in (3), and the interchain consumer 443 is in the leaf chain manager contract B 940 of the leaf chain B 330, which has a remittance service. You can request a remittance.
  • Leaf chain manager contract B 940 of leaf chain B 330 can call DApp 3 950, the service to be remitted, so that the remittance can be made to user b in the contract of DAPP 3 950.
  • the contract of DApp 3 (950) may also increase the total amount of money in Leaf Chain B (330).
  • the producer 441 may collect the transaction generated in (5), and the interchain consumer 443 may request completion of the remittance from the leaf chain B contract 413 of the root chain 310.
  • the leaf chain B contract 413 of the root chain 310 may process the remittance completion by bringing the escrow information of the remittance request to the root chain manager contract 411. If the remittance is successful, the total amount of money in the leaf chain B 330 can be increased by the amount of the remittance in DApp 3 950 managed by the leaf chain B contract 413, and the root chain manager contract of the root chain 310 At 411, the remittance request record may be deleted.
  • the total amount of money in the leaf chain A 320 may be increased again by the amount of remittance to the dapp 1 920, which is a service that requested remittance, registered in the leaf chain A contract 412. ), the remittance request record may be deleted from the root chain manager contract 411.
  • the producer 441 can collect the transaction created in (7), and the interchain consumer 443 requests the leaf chain manager contract A (910) of the remitted leaf chain A (320) to complete the remittance. I can.
  • relays may exist for each chain.
  • the relay of the root chain 310 may handle the transfer of requests, data and/or events with the two leaf chains 320 and 330, and each of the two leaf chains 320 and 330 The relay may handle the transfer of requests, data and/or events to and from the root chain 310.
  • the chain connected to each of the relay words may be dynamically changed every preset time period (for example, block time period).
  • the hash can prevent exchange transactions from being intercepted or altered by the relay when moving between chains through a hash time lock contract.
  • This hash time lock can be used to provide time for users to directly check the results of exchange transactions.
  • a separate exchange transaction identifier may be used as a unique identifier for preventing unintentional double payment of the relay. This exchange transaction identifier can be used to uniquely identify and track exchange transactions when there is a value shift between leaf chains.
  • the blockchain network 300 When data is transmitted between chains in such a blockchain network 300, there is a possibility that the data to be transmitted is altered by the transmitting system. For example, when transferring data from leaf chain A 320 to root chain 310, there is a possibility that the data in leaf chain A 320 will be modulated.
  • the blockchain network 300 has five requirements as follows.
  • the base coin may mean a coin used in the unique coin system of the blockchain network 300.
  • remittance between chains should be made quickly without confirmation of the user receiving the base coin.
  • the root chain can cause the mint and burn of base coins to occur through authorized users.
  • authorized users can be verified with a multisig-wallet to issue or burn base coins.
  • issuance can be executed when a coin issuance request is received from the root chain.
  • issuance and incineration can be executed after confirming that the authenticated information of the root chain has been transmitted in both leaf chains. For example, a leaf chain that remits a base coin can burn the base coin, and a leaf chain that receives a base coin can issue the base coin.
  • the contract can be created with its own private key, and a public key corresponding to the private key can be disclosed.
  • the contract can sign information that needs to be transmitted to other chains and record it as an event, thus proving that the original data has been processed from the contract.
  • a contract can sign the original data and its contract address with the contract's private key.
  • an arbitrary user can verify the signed original data using the public key corresponding to the contract's private key, and the contract is uniquely created in all chains through the contract address of the contract. It can be proved that the data has been transmitted.
  • the contract's private key must be stored in the contract's database, and since the database is shared and open on the blockchain network, the private key is shared among all nodes in the chain, and thus it is no longer a private key. .
  • the public address which is an identification value created through the public key paired with the root chain's private key, is recorded in the leaf chain's genesis block, making it impossible to tamper with the leaf chain.
  • Data signed with the private key through the root chain can be compared to the public address recorded in the genesis block on the leaf chain to verify that the signed data was sent from the loop chain.
  • the public address created by the leaf chain's private key can be registered in the leaf chain contract installed in association with the leaf chain in the root chain.
  • the root chain can verify that the signed data is sent from the leaf chain by comparing the data signed with the leaf chain's private key through the leaf chain with the public address registered in the leaf chain contract.
  • the second method can be used in a private blockchain that can share a private key in C-nodes for consensus, but it cannot be used in a public blockchain (public leaf chain) that is open to provide external services. .
  • the third method is to use a unique private key that each of all C-nodes in the root chain has for consensus.
  • the root chain includes 8 C-nodes, there may be 8 private keys.
  • public addresses of each of all C-nodes of the root chain generated by corresponding private keys may be stored in each of all leaf chains.
  • the data that needs to be confirmed that it is generated in the root chain can be recorded in the block by signing it with its own private key by the leader node of the root chain, and the data can be transferred to the leaf chain.
  • the leader node may be a randomly selected node among C-nodes, and may be changed to one of other C-nodes if necessary.
  • the leaf chain can verify that the signed data was sent from the loop chain by comparing the signed data with the public address stored in the leaf chain. As explained earlier, since the leaf chain knows the public addresses of all C-nodes in the root chain, whether the public address obtained when validating the signed data is one of the public addresses of the C-nodes of the root chain that it already knows. By verifying whether or not, the signed data can be verified. However, if the number of C-nodes included in the loop chain is disclosed, and when a change such as adding or deleting C-nodes to the root chain occurs, the information recorded in each of all leaf chains must be updated.
  • the fourth method is to share a common public address created by a combination of public addresses generated by all C-nodes in the root chain to each of the leaf chains. Even in this case, if changes such as adding or deleting C-nodes in the loop chain occur, the information recorded in each of all leaf chains must be updated, but the public address to be shared by each of the leaf chains is reduced to one representative public address. It has the advantage that the number of C-nodes included in the loop chain is not disclosed. However, since the representative public address is changed, be careful about security when changing. In the fourth method, each of all C-nodes must know each public address of every C-node in the root chain.
  • one public address (representative public address) can be created, and an algorithm for signing and an algorithm for verifying it so that the private key can decrypt the password through one or more confirmations.
  • a modified module is required.
  • the encrypted private key can be decrypted through a password, which will be described later, and can be stored in a database by a signable contract.
  • a password for decrypting the data to be signed and the encrypted private key stored in the signable contract may be delivered to the signable contract as parameters.
  • information according to all requests for example, requests using HTTPS (Hypertext Transfer Protocol Secure)
  • HTTPS Hypertext Transfer Protocol Secure
  • the password parameter can be defined as a type that is not stored/recorded anywhere such as a block or log (hereinafter,'secure type').
  • the leaf chain is data transmitted from the root chain
  • the signable contract that signed the data is a contract installed on the root chain by inquiring into the root chain, and the signing contract is a contract on the root chain. If it is proved that it is a contract that exists in, it can be proved that the signed data is data created or processed in the root chain.
  • FIG. 10 is a diagram showing an example of a process of installing a signable contract according to an embodiment of the present invention.
  • FIG. 10 shows that the signable contract 1010 receives the encrypted private key 1020 and the public key 1030 as parameters, generates a public address using the received public key 1030 and stores it in the database 1040 An example is shown.
  • the database 1040 may store an encrypted private key 1020, a public key 1030, and a public address generated by using the public key 1030.
  • 11 is a diagram illustrating an example of a process of signing data according to an embodiment of the present invention.
  • 11 shows an example in which the signable contract 1010 receives a signature request from a user or another contract 1110.
  • the signing request may include data for signing and a password for decrypting the encrypted private key 1020 described in FIG. 10.
  • the signable contract 1010 may decrypt the encrypted private key 1020 using a password to obtain a private key, and may use the decrypted private key to sign the transmitted data as a parameter. Thereafter, the signable contract 1010 may return the signed data to the user or another contract 1110 as a result.
  • users can respond to the nodes of the blockchain.
  • the fifth method's signable contract can be automatically installed as a system contract of the blockchain.
  • a signable contract can also be installed.
  • a node that creates a system contract for the first time such as a leader node, can generate a private key and install a signable contract.
  • the generated private key may be encrypted through a signable contract and stored in a database, and the password for decrypting the encrypted private key may be encrypted with the public key of the corresponding node and stored locally.
  • Other nodes can replicate transactions and search for nodes that know the latest password.
  • the other node may transmit its own public key to the searched node, receive a password encrypted with the public key, and store it locally of the other node.
  • each node requests a signature, it can obtain a password by decrypting the encrypted password stored locally with its public key, and pass the obtained password to the signable contract as a parameter of the signature request function.
  • Requests can be processed using signature APIs or functions provided by the blockchain.
  • the public address of a signable contract can be recorded in the genesis block of each leaf chain. Signable contracts can be used to prove that the data is transmitted from the root chain.
  • 13 is a diagram illustrating another example of a process of signing data according to an embodiment of the present invention.
  • 13 shows an example in which the node 1310 decrypts the encrypted password with the private key of the node 1310 to obtain the password, and then transmits the obtained password as a parameter to the system 1320 to request data signature.
  • the system 1320 may correspond to a blockchain system.
  • data to be signed may also be transmitted to the system 1320 as a parameter.
  • the system 1320 may request the signing of data to the signable contract 1210 using the password.
  • the signable contract 1210 may decrypt the encrypted private key through the password, sign the data using the decrypted private key, and then return the signed data.
  • System 1320 may pass the returned signed data to node 1310.
  • the list of proof hashes of the Merkle tree of the transaction that processed the remittance must be delivered through an event as a result of processing. If there is a watchdog, it is necessary to decide whether to pass the proof information of the Merkle tree.
  • the event information to be delivered can be signed with the contract's private key and recorded in the event. In this case, it is possible to know that the transaction has been processed, but a watcher may be required because it cannot be determined whether the transaction has been altered. At this time, the watcher can check whether the corresponding block exists and whether the remittance was successful or failed, such as data transmitted as an event by the corresponding transaction. If fraud is discovered by the watcher, the leaf chain may be penalized.
  • the monitor can be implemented in the form of a node that executes the above function.
  • 14 is a diagram showing another example of a coin exchange method in an embodiment of the present invention.
  • the exchange of coins in the same service in the same chain or exchange of coins between other services in the same chain has also been described through the embodiment of FIG. 8.
  • 14 is an embodiment different from the embodiment of FIG. 8, showing a root chain 1410, a leaf chain 1 (1420), and a leaf chain 2 (1430), and user 1 of the leaf chain 1 (1420) is a leaf chain. It is assumed that a remittance request is made to user 2 of 2 (1430).
  • Step 3 may be an example of a process of transmitting a receivable response to the root chain 1410 when there is no problem after checking whether the remittance request is a receivable request in the leaf chain 2 1430.
  • Step 4 may be an example of a process in which the root chain 1410 issues a receipt to the leaf chain 1 1420 and the leaf chain 2 1430, respectively, by deducting or increasing the amount of remittance.
  • Step 4.1 may be an example of a process in which the root chain (1410) issues a receipt for deducting the amount of remittance to Leaf Chain 1 (1420), and in Step 4.2, the root chain (1410) increases the amount of remittance to Leaf Chain 2 (1430). It may be an example of the process of issuing a receipt for In each chain, management can be implemented to prevent duplicate deduction or duplicate increase.
  • the smart contract may include a root chain manager contract as described above with reference to FIG. 4, and may include a contract for each leaf chain.
  • the leaf chain may include a leaf chain manager contract and a dapp contract when a service dapp exists, and may include a leaf chain manager contract when a service dapp does not exist.
  • the root chain manager contract and the leaf chain manager contract are system contracts and can be installed automatically when the blockchain is installed. Relayers can filter eventLogs and deliver them to each chain. Each chain can be managed so that the relay cannot tamper with the data.
  • the root chain can store the public address created by the private key of each leaf chain, and the leaf chain can record the public address created by the root chain's unique private key when generating the genesis block. All the information to be transmitted by the relay can be delivered with information signed with the unique private key of the root chain.
  • the user can call a function that defines "exchange" of the dapp.
  • the DApp can call "exchange” defined in icx, and thus the'exchange function needs to be implemented in the icx class.
  • the signature of the leaf chain may include a value signed by combining from user, origin, to user, destination, value, eTxHash, and message.
  • the data authentication method according to the present embodiment may be performed by the computer device 200 implementing a node of a blockchain network.
  • the processor 220 of the computer device 200 may be implemented to execute a code of an operating system included in the memory 210 or a control instruction according to the code of at least one program.
  • the processor 220 may cause the computer device 200 to perform the steps 1510 to 1540 included in the method of FIG. 15 according to a control command provided by the code stored in the computer device 200. Can be controlled.
  • the computer device 200 may share the private key representing the chain of the blockchain network with at least one other node participating in consensus in the blockchain network.
  • the node may be one of a plurality of nodes preset to achieve consensus in the blockchain network, and at least one other node may also be included in a plurality of preset nodes to achieve consensus in the blockchain network.
  • the computer device 200 implementing one node may share a private key representing a chain of a blockchain network in which the node implemented by the computer device 200 participates with at least one other node.
  • the blockchain network may include a first leaf chain among a plurality of leaf chains in which data transmission is managed by a root chain.
  • the computer device 200 may register the generated public address in a leaf chain contract installed in association with the first leaf chain in the root chain. At this time, it is possible to verify that the signed data was sent from the first leaf chain by comparing the data signed in the root chain with the public address registered in the corresponding leaf chain contract.
  • the computer device 200 may sign data to be transmitted from the blockchain network to another blockchain network with a private key through a contract installed on the blockchain network. At this time, the block in which the signed data is recorded can be added to the chain of the blockchain network.
  • the computer device 200 may transmit the signed data to another blockchain network through a contract. At this time, it can be verified that the signed data is sent through the blockchain network through comparison between the signed data and the public address.
  • FIG. 16 is a flow chart illustrating a second example of a data authentication method according to an embodiment of the present invention.
  • the data authentication method according to the present embodiment may be performed by the computer device 200 implementing a node of a blockchain network.
  • the processor 220 of the computer device 200 may be implemented to execute a code of an operating system included in the memory 210 or a control instruction according to the code of at least one program.
  • the processor 220 may cause the computer device 200 to perform the steps 1610 to 1630 included in the method of FIG. 16 according to a control command provided by the code stored in the computer device 200. Can be controlled.
  • the computer device 200 may generate the public address of the node by using the private key of the node.
  • the node's private key can be the unique private key that the node has for consensus on the blockchain network.
  • the computer device 200 may sign data to be transmitted from the blockchain network to another blockchain network using the private key of the node. At this time, the block in which the signed data is recorded can be added to the chain of the blockchain network.
  • the blockchain network may include a root chain that manages data transmission between a plurality of leaf chains.
  • the public address generated in each of a plurality of nodes (a plurality of nodes including a node implemented by the computer device 200 in this embodiment) set in advance to achieve consensus in the blockchain network is a plurality of leaves. It can be stored in each of the chains. In this case, it is possible to verify that the signed data is sent from the root chain by comparing the public address of each of the plurality of nodes stored in the first leaf chain with the data signed in the first leaf chain that received the signed data.
  • the blockchain network may include a first leaf chain among a plurality of leaf chains in which data transmission is managed by a root chain.
  • the public address generated by each of a plurality of nodes (a plurality of nodes including a node implemented by the computer device 200 in this embodiment) preset to achieve consensus in the blockchain network is the first in the root chain. It can be registered in the leaf chain contract installed in association with the leaf chain. In this case, it is possible to verify that the signed data was sent from the first leaf chain by comparing the data signed in the root chain with the public address registered in the leaf chain contract.
  • the blockchain network may include a root chain that manages data transmission between a plurality of leaf chains.
  • a representative public generated by a combination of public addresses generated in each of a plurality of nodes (a plurality of nodes including a node implemented by the computer device 200 in this embodiment) set in advance to achieve consensus in the blockchain network
  • the address may be stored in each of a plurality of leaf chains. In this case, it is possible to verify that the signed data is sent from the root chain by comparing the signed data in the first leaf chain to which the signed data is transmitted with the representative public address stored in the first leaf chain.
  • the blockchain network may include a first leaf chain among a plurality of leaf chains in which data transmission is managed by a root chain.
  • a representative public generated by a combination of public addresses generated by each of a plurality of nodes (a plurality of nodes including a node implemented by the computer device 200 in this embodiment) set to achieve consensus in the blockchain network
  • the address may be registered in a leaf chain contract installed in association with the first leaf chain in the root chain. In this case, it is possible to verify that the signed data was sent from the first leaf chain by comparing the data signed in the root chain with the representative public address registered in the leaf chain contract.
  • FIG. 17 is a flowchart illustrating a third example of a data authentication method according to an embodiment of the present invention.
  • the data authentication method according to the present embodiment may be performed by the computer device 200 operating through a contract of a blockchain network.
  • the processor 220 of the computer device 200 may be implemented to execute a code of an operating system included in the memory 210 or a control instruction according to the code of at least one program.
  • the processor 220 may cause the computer device 200 to perform the steps 1710 to 1760 included in the method of FIG. 17 according to a control command provided by the code stored in the computer device 200. Can be controlled.
  • at least one program code may include at least a code according to a contract of a blockchain network.
  • the computer device 200 may receive the encrypted private key and the public key generated as the private key as parameters.
  • step 1720 the computer device 200 may generate a contract address using the received public key.
  • the computer device 200 may store the encrypted private key and the contract address in the database.
  • the computer device 200 may receive a signature request including data to be signed and a password for decrypting the encrypted private key as parameters.
  • the password can be defined as a secure type that is not stored in any of the blocks or logs of the blockchain network.
  • the computer device 200 may decrypt the encrypted private key through the password in response to the signature request, and may generate signed data by signing the data with the decrypted private key. At this time, a block in which the signed data is recorded may be added to the chain of the blockchain network.
  • the computer device 200 may return the generated signed data.
  • the signed data may be returned to the node that requested the signature of the data.
  • the blockchain network may include a root chain that manages data transmission between a plurality of leaf chains.
  • the computer device 200 may record the contract address in the genesis block of each of the plurality of leaf chains. In this case, it is possible to verify that the signed data is sent from the root chain by comparing the signed data in the first leaf chain receiving the signed data with the contract address recorded in the genesis block of the first leaf chain.
  • the blockchain network may include a first leaf chain among a plurality of leaf chains in which data transmission is managed by a root chain.
  • the computer device 200 may provide the contract address as a root chain so that the contract address is stored in the database of the root chain. In this case, it is possible to verify that the signed data was sent from the first leaf chain by comparing the data signed in the root chain with the contract address stored in the database of the root chain.
  • the data authentication method according to the present embodiment may be performed by the computer device 200 implementing a node of a blockchain network.
  • the processor 220 of the computer device 200 may be implemented to execute a code of an operating system included in the memory 210 or a control instruction according to the code of at least one program.
  • the processor 220 may cause the computer device 200 to perform the steps 1810 to 1860 included in the method of FIG. 18 according to a control command provided by a code stored in the computer device 200. Can be controlled.
  • the computer device 200 may encrypt and store the private key of the node of the blockchain network.
  • the node may be the first node created in the blockchain network, and signable contracts can be automatically installed in the process of installing the system contract of the blockchain network from these nodes. During this process, the node's private key can be passed to the signable contract.
  • the signable contract may encrypt and store the private key of the node transmitted during the installation process.
  • the computer device 200 may encrypt and store a password for decrypting the encrypted private key with the public key of the node.
  • the password may be generated so that the computer device 200 can decrypt the encrypted private key while encrypting the private key.
  • a value for obtaining the symmetric key or the symmetric key may be generated as a password.
  • the computer device 200 may receive a signature request including data for signing with a password and a private key as parameters from an arbitrary node of the blockchain network.
  • the arbitrary node may be a node that has received an encrypted password from the computer device 200 or another node that has received a password from the corresponding node.
  • the computer device 200 may generate signed data by decrypting the encrypted private key through the password in response to the signature request, and signing the data with the decrypted private key.
  • the computer device 200 may return the signed data.
  • the signed data may be returned to the node that requested the signature of the data.
  • the blockchain network may include a first leaf chain among a plurality of leaf chains in which data transmission is managed by a root chain.
  • the computer device 200 may provide the contract address as a root chain so that the contract address is stored in the database of the root chain.
  • the root chain can be considered an absolute trust system, as already explained.
  • the system or device described above may be implemented as a hardware component, a software component, or a combination of a hardware component and a software component.
  • the devices and components described in the embodiments are, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA). , A programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions, such as one or more general purpose computers or special purpose computers.
  • the processing device may execute an operating system (OS) and one or more software applications executed on the operating system.
  • OS operating system
  • the processing device may access, store, manipulate, process, and generate data in response to the execution of software.
  • the processing device is a plurality of processing elements and/or a plurality of types of processing elements. It can be seen that it may include.
  • the processing device may include a plurality of processors or one processor and one controller.
  • other processing configurations are possible, such as a parallel processor.
  • the software may include a computer program, code, instructions, or a combination of one or more of these, configuring the processing unit to behave as desired or processed independently or collectively. You can command the device.
  • Software and/or data may be interpreted by a processing device or to provide instructions or data to a processing device, of any type of machine, component, physical device, virtual equipment, computer storage medium or device. Can be embodyed in The software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.
  • the method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded in a computer-readable medium.
  • the computer-readable medium may include program instructions, data files, data structures, and the like alone or in combination.
  • the program instructions recorded on the medium may be specially designed and configured for the embodiment, or may be known and usable to a person skilled in computer software.
  • Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic media such as floptical disks.
  • -A hardware device specially configured to store and execute program instructions such as magneto-optical media, and ROM, RAM, flash memory, and the like.
  • Such a recording medium may be a variety of recording means or storage means in a form in which a single piece of hardware or several pieces of hardware are combined, and is not limited to a medium directly connected to a computer system, but may be distributed on a network.
  • Examples of the program instructions include not only machine language codes such as those produced by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Computing Systems (AREA)

Abstract

블록체인에서 생성된 데이터를 인증하는 방법 및 시스템을 제공한다. 본 발명의 실시예들에 있어서, 블록체인 네트워크에 참여하는 컴퓨터 장치로 구현되는 노드의 데이터 인증 방법은 상기 블록체인 네트워크의 체인을 대표하는 프라이빗 키(private key)를 상기 블록체인 네트워크에 참여하는 적어도 하나의 다른 노드와 공유하는 단계, 상기 프라이빗 키를 이용하여 상기 블록체인 네트워크의 퍼블릭 주소를 생성하는 단계, 상기 블록체인 네트워크에서 다른 블록체인 네트워크로 전달하고자 하는 데이터를 상기 블록체인 네트워크에 설치된 컨트랙트를 통해 상기 프라이빗 키로 서명하는 단계 및 상기 서명된 데이터를 상기 컨트랙트를 통해 다른 블록체인 네트워크로 전달하는 단계를 포함할 수 있다. 이때, 상기 서명된 데이터와 상기 퍼블릭 주소간의 비교를 통해 상기 서명된 데이터가 상기 블록체인 네트워크를 통해 발송된 것임이 검증될 수 있다.

Description

블록체인에서 생성된 데이터를 인증하는 방법 및 시스템
아래의 설명은 블록체인에서 생성된 데이터를 인증하는 방법 및 시스템에 관한 것이다.
블록체인(block-chain)은 전자 대장(electronic ledger)으로서, 트랜잭션들을 위한 블록들로 구성된 컴퓨터 기반의 분산형, P2P(peer-to-peer)의 시스템으로 구현된다. 각 트랜잭션(Transaction, Tx)은 블록체인 시스템 내의 참가자들 간에 디지털 자산의 제어 전송을 인코딩하는 데이터 구조이며, 적어도 하나의 입력과 적어도 하나의 출력을 포함한다. 각 블록은 이전 블록의 해시를 포함하여 해당 블록이 함께 연결되어 처음부터 블록체인에 기록된 모든 트랜잭션의 영구적인, 바꿀 수 없는(unalterable) 기록을 생성한다. 예를 들어, 한국공개특허 제10-2018-0113143호는 블록체인 기반의 사용자 정의 화폐 거래 시스템 및 그 동작 방법을 개시하고 있다. 이러한 블록체인 자체는 스케일 아웃(scale out)이 되지 않는다. 예를 들어, 블록체인 네트워크에서 블록을 생성하기 위한 노드를 추가하더라도 블록 생성을 위한 합의의 비용이 증가할 뿐, 트랜잭션에 대한 블록 생성 속도가 증가하지는 않는다.
루트 체인(Root Chain)을 기반으로 리프 체인(Leaf Chain)을 추가하는 방식으로 스케일 아웃이 가능한 블록체인에서 생성되는 데이터를 인증하는 데이터 인증 방법 및 시스템을 제공한다.
블록체인 네트워크에 참여하는 컴퓨터 장치로 구현되는 노드의 데이터 인증 방법에 있어서, 상기 컴퓨터 장치가 포함하는 적어도 하나의 프로세서에 의해, 상기 블록체인 네트워크의 체인을 대표하는 프라이빗 키(private key)를 상기 블록체인 네트워크에 참여하는 적어도 하나의 다른 노드와 공유하는 단계; 상기 적어도 하나의 프로세서에 의해, 상기 프라이빗 키를 이용하여 상기 블록체인 네트워크의 퍼블릭 주소를 생성하는 단계; 상기 적어도 하나의 프로세서에 의해, 상기 블록체인 네트워크에서 다른 블록체인 네트워크로 전달하고자 하는 데이터를 상기 블록체인 네트워크에 설치된 컨트랙트를 통해 상기 프라이빗 키로 서명하는 단계; 및 상기 적어도 하나의 프로세서에 의해, 상기 서명된 데이터를 상기 컨트랙트를 통해 다른 블록체인 네트워크로 전달하는 단계를 포함하고, 상기 서명된 데이터와 상기 퍼블릭 주소간의 비교를 통해 상기 서명된 데이터가 상기 블록체인 네트워크를 통해 발송된 것임이 검증되는 것을 특징으로 하는 데이터 인증 방법을 제공한다.
일측에 따르면, 상기 블록체인 네트워크는 복수의 리프 체인들간의 데이터 전송을 관리하는 루트 체인을 포함하고, 상기 데이터 인증 방법은, 상기 적어도 하나의 프로세서에 의해, 상기 생성된 퍼블릭 주소를 상기 복수의 리프 체인들 각각의 제네시스(genesis) 블록에 기록하는 단계를 더 포함하는 것을 특징으로 할 수 있다.
다른 측면에 따르면, 상기 서명된 데이터를 전송받은 리프 체인에서 상기 서명된 데이터와 상기 리프 체인의 제네시스 블록에 기록된 퍼블릭 주소를 비교하여 상기 서명된 데이터가 상기 루트 체인에서 발송된 것임을 검증하는 것을 특징으로 할 수 있다.
또 다른 측면에 따르면, 상기 블록체인 네트워크는 루트 체인에 의해 데이터 전송이 관리되는 복수의 리프 체인들 중 제1 리프 체인을 포함하고, 상기 데이터 인증 방법은, 상기 적어도 하나의 프로세서에 의해, 상기 생성된 퍼블릭 주소를, 상기 루트 체인에 상기 제1 리프 체인과 연관하여 설치된 리프 체인 컨트랙트에 등록하는 단계를 더 포함하는 것을 특징으로 할 수 있다.
또 다른 측면에 따르면, 상기 루트 체인에서 상기 서명된 데이터와 상기 리프 체인 컨트랙트에 등록된 퍼블릭 주소를 비교하여 상기 서명된 데이터가 상기 제1 리프 체인에서 발송된 것임을 검증하는 것을 특징으로 할 수 있다.
또 다른 측면에 따르면, 상기 노드는 상기 블록체인 네트워크에서의 합의(consensus)를 이루도록 기설정된 복수의 노드들 중 하나인 것을 특징으로 할 수 있다.
또 다른 측면에 따르면, 상기 서명된 데이터가 기록된 블록이 상기 블록체인 네트워크의 체인에 추가되는 것을 특징으로 할 수 있다.
블록체인 네트워크에 참여하는 컴퓨터 장치로 구현되는 노드의 데이터 인증 방법에 있어서, 상기 컴퓨터 장치가 포함하는 적어도 하나의 프로세서에 의해, 상기 노드의 프라이빗 키를 이용하여 상기 노드의 퍼블릭 주소를 생성하는 단계; 상기 적어도 하나의 프로세서에 의해, 상기 블록체인 네트워크에서 다른 블록체인 네트워크로 전달하고자 하는 데이터를 상기 노드의 프라이빗 키를 이용하여 서명하는 단계; 및 상기 적어도 하나의 프로세서에 의해, 상기 서명된 데이터를 상기 다른 블록체인 네트워크로 전달하는 단계를 포함하고, 상기 퍼블릭 주소를 이용하여 상기 서명된 데이터가 상기 블록체인 네트워크를 통해 발송된 것임이 검증되는 것을 특징으로 하는 데이터 인증 방법을 제공한다.
컴퓨터 장치와 결합되어 상기 방법을 컴퓨터 장치에 실행시키기 위해 컴퓨터 판독 가능한 기록매체에 저장된 컴퓨터 프로그램을 제공한다.
상기 방법을 컴퓨터 장치에 실행시키기 위한 컴퓨터 프로그램이 기록되어 있는 것을 특징으로 하는 컴퓨터 판독 가능한 기록매체를 제공한다.
블록체인 네트워크의 노드를 구현하는 컴퓨터 장치에 있어서, 상기 컴퓨터 장치에서 판독 가능한 명령을 실행하도록 구현되는 적어도 하나의 프로세서를 포함하고, 상기 적어도 하나의 프로세서에 의해, 상기 블록체인 네트워크의 체인을 대표하는 프라이빗 키(private key)를 상기 블록체인 네트워크에 참여하는 적어도 하나의 다른 노드와 공유하고, 상기 프라이빗 키를 이용하여 상기 블록체인 네트워크의 퍼블릭 주소를 생성하고, 상기 블록체인 네트워크에서 다른 블록체인 네트워크로 전달하고자 하는 데이터를 상기 블록체인 네트워크에 설치된 컨트랙트를 통해 상기 프라이빗 키로 서명하고, 상기 서명된 데이터를 상기 컨트랙트를 통해 다른 블록체인 네트워크로 전달하고, 상기 서명된 데이터와 상기 퍼블릭 주소간의 비교를 통해 상기 서명된 데이터가 상기 블록체인 네트워크를 통해 발송된 것임이 검증되는 것을 특징으로 하는 컴퓨터 장치를 제공한다.
블록체인 네트워크의 노드를 구현하는 컴퓨터 장치에 있어서, 상기 컴퓨터 장치에서 판독 가능한 명령을 실행하도록 구현되는 적어도 하나의 프로세서를 포함하고, 상기 적어도 하나의 프로세서에 의해, 상기 노드의 프라이빗 키를 이용하여 상기 노드의 퍼블릭 주소를 생성하고, 상기 블록체인 네트워크에서 다른 블록체인 네트워크로 전달하고자 하는 데이터를 상기 노드의 프라이빗 키를 이용하여 서명하고, 상기 서명된 데이터를 상기 다른 블록체인 네트워크로 전달하고, 상기 퍼블릭 주소를 이용하여 상기 서명된 데이터가 상기 블록체인 네트워크를 통해 발송된 것임이 검증되는 것을 특징으로 하는 컴퓨터 장치를 제공한다.
루트 체인(Root Chain)을 기반으로 리프 체인(Leaf Chain)을 추가하는 방식으로 스케일 아웃이 가능한 블록체인에서 생성되는 데이터를 인증하는 데이터 인증 방법 및 시스템을 제공할 수 있다.
도 1은 본 발명의 일실시예에 따른 네트워크 환경의 예를 도시한 도면이다.
도 2는 본 발명의 일실시예에 따른 컴퓨터 장치의 예를 도시한 블록도이다.
도 3은 본 발명의 일실시예에 있어서, 확장을 가능한 블록체인 네트워크의 개괄적인 구성의 예를 도시한 도면이다.
도 4는 본 발명의 일실시예에 따른 트랜잭션 처리 시스템의 세부 구성의 예를 도시한 도면이다.
도 5는 본 발명의 일실시예에 있어서, 새로운 리프 체인을 추가하는 과정의 예를 도시한 흐름도이다.
도 6은 본 발명의 일실시예에 있어서, 새로운 서비스를 추가하는 과정의 예를 도시한 흐름도이다.
도 7은 본 발명의 일실시예에 있어서, 서비스에 코인을 발행하는 과정의 예를 도시한 흐름도이다.
도 8은 본 발명의 일실시예에 있어서, 코인 교환 과정의 예를 도시한 흐름도이다.
도 9는 본 발명의 일실시예에 있어서, 각 체인간 스마트 컨트랙트를 통한 코인 교환 데이터의 흐름을 도시한 도면이다.
도 10은 본 발명의 일실시예에 있어서, 서명 가능 컨트랙트의 설치 과정의 예를 도시한 도면이다.
도 11은 본 발명의 일실시예에 있어서, 데이터를 서명하는 과정의 예를 도시한 도면이다.
도 12는 본 발명의 일실시예에 있어서, 서명 가능 컨트랙트의 설치 과정의 다른 예를 도시한 도면이다.
도 13은 본 발명의 일실시예에 있어서, 데이터를 서명하는 과정의 다른 예를 도시한 도면이다.
도 14는 본 발명의 일실시예에 있어서, 코인 교환 과정의 다른 예를 도시한 도면이다.
도 15는 본 발명의 일실시예에 있어서, 데이터 인증 방법의 제1 예를 도시한 흐름도이다.
도 16은 본 발명의 일실시예에 있어서, 데이터 인증 방법의 제2 예를 도시한 흐름도이다.
도 17은 본 발명의 일실시예에 있어서, 데이터 인증 방법의 제3 예를 도시한 흐름도이다.
도 18은 본 발명의 일실시예에 있어서, 데이터 인증 방법의 제4 예를 도시한 흐름도이다.
이하, 실시예를 첨부한 도면을 참조하여 상세히 설명한다.
본 발명의 실시예들에 따른 데이터 인증 시스템은 적어도 하나의 컴퓨터 장치에 의해 구현될 수 있다. 컴퓨터 장치에는 본 발명의 일실시예에 따른 컴퓨터 프로그램이 설치 및 구동될 수 있고, 컴퓨터 장치는 구동된 컴퓨터 프로그램의 제어에 따라 본 발명의 일실시예에 따른 데이터 인증 방법을 수행할 수 있다. 상술한 컴퓨터 프로그램은 컴퓨터 장치와 결합되어 데이터 인증 방법을 컴퓨터 장치에 실행시키기 위해 컴퓨터 판독 가능한 기록매체에 저장될 수 있다. 여기서 설명한 컴퓨터 프로그램은 독립된 하나의 프로그램 패키지의 형태를 가질 수도 있고, 독립된 하나의 프로그램 패키지의 형태가 컴퓨터 장치에 기 설치되어 운영체제나 다른 프로그램 패키지들과 연계되는 형태를 가질 수도 있다.
도 1은 본 발명의 일실시예에 따른 네트워크 환경의 예를 도시한 도면이다. 도 1의 네트워크 환경은 복수의 전자 기기들(110, 120, 130, 140), 복수의 서버들(150, 160) 및 네트워크(170)를 포함하는 예를 나타내고 있다. 이러한 도 1은 발명의 설명을 위한 일례로 전자 기기의 수나 서버의 수가 도 1과 같이 한정되는 것은 아니다. 또한, 도 1의 네트워크 환경은 본 실시예들에 적용 가능한 환경들 중 하나의 예를 설명하는 것일 뿐, 본 실시예들에 적용 가능한 환경이 도 1의 네트워크 환경으로 한정되는 것은 아니다.
복수의 전자 기기들(110, 120, 130, 140)은 컴퓨터 장치로 구현되는 고정형 단말이거나 이동형 단말일 수 있다. 복수의 전자 기기들(110, 120, 130, 140)의 예를 들면, 스마트폰(smart phone), 휴대폰, 네비게이션, 컴퓨터, 노트북, 디지털방송용 단말, PDA(Personal Digital Assistants), PMP(Portable Multimedia Player), 태블릿 PC 등이 있다. 일례로 도 1에서는 전자 기기 1(110)의 예로 스마트폰의 형상을 나타내고 있으나, 본 발명의 실시예들에서 전자 기기 1(110)은 실질적으로 무선 또는 유선 통신 방식을 이용하여 네트워크(170)를 통해 다른 전자 기기들(120, 130, 140) 및/또는 서버(150, 160)와 통신할 수 있는 다양한 물리적인 컴퓨터 장치들 중 하나를 의미할 수 있다.
통신 방식은 제한되지 않으며, 네트워크(170)가 포함할 수 있는 통신망(일례로, 이동통신망, 유선 인터넷, 무선 인터넷, 방송망)을 활용하는 통신 방식뿐만 아니라 기기들간의 근거리 무선 통신 역시 포함될 수 있다. 예를 들어, 네트워크(170)는, PAN(personal area network), LAN(local area network), CAN(campus area network), MAN(metropolitan area network), WAN(wide area network), BBN(broadband network), 인터넷 등의 네트워크 중 하나 이상의 임의의 네트워크를 포함할 수 있다. 또한, 네트워크(170)는 버스 네트워크, 스타 네트워크, 링 네트워크, 메쉬 네트워크, 스타-버스 네트워크, 트리 또는 계층적(hierarchical) 네트워크 등을 포함하는 네트워크 토폴로지 중 임의의 하나 이상을 포함할 수 있으나, 이에 제한되지 않는다.
서버(150, 160) 각각은 복수의 전자 기기들(110, 120, 130, 140)과 네트워크(170)를 통해 통신하여 명령, 코드, 파일, 컨텐츠, 서비스 등을 제공하는 컴퓨터 장치 또는 복수의 컴퓨터 장치들로 구현될 수 있다. 예를 들어, 서버(150)는 네트워크(170)를 통해 접속한 복수의 전자 기기들(110, 120, 130, 140)로 서비스(일례로, 영상통화 서비스, 금융 서비스, 결제 서비스, 소셜 네트워크 서비스, 메시징 서비스, 검색 서비스, 메일 서비스, 컨텐츠 제공 서비스 및/또는 질문 및 답변 서비스 등)를 제공하는 시스템일 수 있다.
도 2는 본 발명의 일실시예에 따른 컴퓨터 장치의 예를 도시한 블록도이다. 앞서 설명한 복수의 전자 기기들(110, 120, 130, 140) 각각이나 서버들(150, 160) 각각은 도 2를 통해 도시된 컴퓨터 장치(200)에 의해 구현될 수 있으며, 본 발명의 실시예들에 따른 방법은 이러한 컴퓨터 장치(200)에 의해 수행될 수 있다.
이때, 도 2에 도시된 바와 같이 컴퓨터 장치(200)는, 메모리(210), 프로세서(220), 통신 인터페이스(230) 그리고 입출력 인터페이스(240)를 포함할 수 있다. 메모리(210)는 컴퓨터에서 판독 가능한 기록매체로서, RAM(random access memory), ROM(read only memory) 및 디스크 드라이브와 같은 비소멸성 대용량 기록장치(permanent mass storage device)를 포함할 수 있다. 여기서 ROM과 디스크 드라이브와 같은 비소멸성 대용량 기록장치는 메모리(210)와는 구분되는 별도의 영구 저장 장치로서 컴퓨터 장치(200)에 포함될 수도 있다. 또한, 메모리(210)에는 운영체제와 적어도 하나의 프로그램 코드가 저장될 수 있다. 이러한 소프트웨어 구성요소들은 메모리(210)와는 별도의 컴퓨터에서 판독 가능한 기록매체로부터 메모리(210)로 로딩될 수 있다. 이러한 별도의 컴퓨터에서 판독 가능한 기록매체는 플로피 드라이브, 디스크, 테이프, DVD/CD-ROM 드라이브, 메모리 카드 등의 컴퓨터에서 판독 가능한 기록매체를 포함할 수 있다. 다른 실시예에서 소프트웨어 구성요소들은 컴퓨터에서 판독 가능한 기록매체가 아닌 통신 인터페이스(230)를 통해 메모리(210)에 로딩될 수도 있다. 예를 들어, 소프트웨어 구성요소들은 네트워크(170)를 통해 수신되는 파일들에 의해 설치되는 컴퓨터 프로그램에 기반하여 컴퓨터 장치(200)의 메모리(210)에 로딩될 수 있다.
프로세서(220)는 기본적인 산술, 로직 및 입출력 연산을 수행함으로써, 컴퓨터 프로그램의 명령을 처리하도록 구성될 수 있다. 명령은 메모리(210) 또는 통신 인터페이스(230)에 의해 프로세서(220)로 제공될 수 있다. 예를 들어 프로세서(220)는 메모리(210)와 같은 기록 장치에 저장된 프로그램 코드에 따라 수신되는 명령을 실행하도록 구성될 수 있다.
통신 인터페이스(230)은 네트워크(170)를 통해 컴퓨터 장치(200)가 다른 장치(일례로, 앞서 설명한 저장 장치들)와 서로 통신하기 위한 기능을 제공할 수 있다. 일례로, 컴퓨터 장치(200)의 프로세서(220)가 메모리(210)와 같은 기록 장치에 저장된 프로그램 코드에 따라 생성한 요청이나 명령, 데이터, 파일 등이 통신 인터페이스(230)의 제어에 따라 네트워크(170)를 통해 다른 장치들로 전달될 수 있다. 역으로, 다른 장치로부터의 신호나 명령, 데이터, 파일 등이 네트워크(170)를 거쳐 컴퓨터 장치(200)의 통신 인터페이스(230)를 통해 컴퓨터 장치(200)로 수신될 수 있다. 통신 인터페이스(230)를 통해 수신된 신호나 명령, 데이터 등은 프로세서(220)나 메모리(210)로 전달될 수 있고, 파일 등은 컴퓨터 장치(200)가 더 포함할 수 있는 저장 매체(상술한 영구 저장 장치)로 저장될 수 있다.
입출력 인터페이스(240)는 입출력 장치(250)와의 인터페이스를 위한 수단일 수 있다. 예를 들어, 입력 장치는 마이크, 키보드, 카메라 또는 마우스 등의 장치를, 그리고 출력 장치는 디스플레이, 스피커와 같은 장치를 포함할 수 있다. 다른 예로 입출력 인터페이스(240)는 터치스크린과 같이 입력과 출력을 위한 기능이 하나로 통합된 장치와의 인터페이스를 위한 수단일 수도 있다. 입출력 장치(250)는 컴퓨터 장치(200)와 하나의 장치로 구성될 수도 있다.
또한, 다른 실시예들에서 컴퓨터 장치(200)는 도 2의 구성요소들보다 더 적은 혹은 더 많은 구성요소들을 포함할 수도 있다. 그러나, 대부분의 종래기술적 구성요소들을 명확하게 도시할 필요성은 없다. 예를 들어, 컴퓨터 장치(200)는 상술한 입출력 장치(250) 중 적어도 일부를 포함하도록 구현되거나 또는 트랜시버(transceiver), 데이터베이스 등과 같은 다른 구성요소들을 더 포함할 수도 있다.
도 3은 본 발명의 일실시예에 있어서, 확장을 가능한 블록체인 네트워크의 개괄적인 구성의 예를 도시한 도면이다. 도 3은 루트 체인(Root Chain, 310), 리프 체인 A(Leaf Chain A, 320), 리프 체인 B(Leaf Chain B, 330) 및 릴레이어(Relayer, 340)를 포함하는 블록체인 네트워크(300)의 예를 나타내고 있다. 루트 체인(310)과 리프 체인들(320 및 330)은 복수의 컴퓨터 장치들이 연결된 네트워크를 형성할 수 있으며, 릴레이어(340)는 적어도 하나의 컴퓨터 장치에 의해 구현될 수 있다.
블록체인 네트워크(300)에서 루트 체인(310)은 절대 신뢰 시스템으로 간주될 수 있으며, 리프 체인들(320 및 330) 각각은 루트 체인(310)에 자신이 신뢰 시스템이라는 것을 증명해야 한다. 이때, 리프 체인들(320 및 330) 각각은 개별 서비스와 연계될 수 있으며, 새로운 서비스의 추가 시 새로운 리프 체인이 추가될 수도 있다. 다시 말해, 도 3의 실시예에서는 두 개의 리프 체인들(320 및 330)을 도시하고 있으나, 셋 이상의 리프 체인들을 포함할 수도 있으며, 이는 블록체인의 확장이 가능함을 의미할 수 있다. 여기서, "서비스"는 동일 또는 서로 다른 주체가 네트워크를 통해 자신의 사용자들에게 제공하는 온라인 서비스를 포함할 수 있다. 일례로, 서로 다른 복수의 은행들이 제공하는 인터넷 뱅킹 서비스들 각각에 대응하는 복수의 리프 체인들이 구성될 수 있다. 또는 서로 다른 복수의 소셜 네트워크 서비스들 각각에 대응하는 복수의 리프 체인들이 구성될 수도 있다. 리프 체인들(320 및 330) 각각은 루트 체인(310)에 블록의 해시를 기록함으로써 신뢰를 인정받아야 한다. 일례로, 머클 트리 루트 해시(merkle tree root hash)가 활용될 수 있다.
루트 체인(310)에서는 사용자들간의 코인 교환을 하지 않으며, 코인 교환은 리프 체인들(320 및 330) 각각의 내부에서 및/또는 리프 체인들(320 및 330)간에 이루어질 수 있다. 이때, 리프 체인들(320 및 330)간의 코인 교환은 릴레이어(340)를 통해 루트 체인(310)이 중재 및 관리할 수 있다. 리프 체인들(320 및 330) 각각에는 적어도 하나의 디앱(Decentralized Application, DApp)이 포함될 수 있다. 여기서, 디앱(Decentralized Application, DApp)은 백엔드 코드가 탈중앙화된 피어-투-피어 네트워크 상에서 돌아가고 (혹은 데이터 호출 및 등록을 블록체인 데이터베이스에 하고) 이를 프론트엔드에서 인터페이스로 제공해주는 어플리케이션을 말한다. 이때, 리프 체인들(320 및 330) 각각에서는 디앱의 필요에 따라 체인, 그리고 코인 교환과 상관없는 스마트 컨트랙트(smart contract)를 설치할 수 있으며, 이를 루트 체인(310)에서는 관여하지 않을 수 있다. 리프 체인들(320 및 330) 각각에서 체인들간의 코인 교환을 위한 프로토콜을 갖는 스마트 컨트랙트를 설치하고자 하는 경우에는 루트 체인(310)을 통해서 스마트 컨트랙트의 설치를 위한 허가를 받아야 한다. 루트 체인(310)의 허가를 받지 않은 스마트 컨트랙트를 이용한 체인간 코인 교환은 이루어지지 않도록 제한될 수 있다.
리프 체인들(320 및 330) 각각의 내부에서의 코인 교환은 루트 체인(310)을 거칠 필요 없이 리프 체인들(320 및 330) 각각에서 처리될 수 있으며, 처리된 내용이 포함된 모든 블록의 요약 정보(일례로, 상술한 머클 트리 루트 해시)를 루트 체인(310)에 기록할 수 있다. 반면, 리프 체인들(320 및 330)간의 코인 교환은 루트 체인(310)을 통해서 이뤄져야 하며, 리프 체인들(320 및 330) 각각의 블록과 루트 체인(310)의 블록에 코인 교환의 처리에 대한 내용이 기록되어야 한다. 이때, 리프 체인들(320 및 330)간의 코인 교환은 릴레이어(340)를 통해 이루어질 수 있다.
도 4는 본 발명의 일실시예에 따른 블록체인 네트워크의 세부 구성의 예를 도시한 도면이다. 블록체인 네트워크(300)는 도 4에 도시된 바와 같이 하나의 루트 체인(310)과 여러 리프 체인들(320 및 330) 그리고 릴레이어(340)로 구성될 수 있다.
루트 체인(310)은 루트 체인(310)을 위한 스마트 컨트랙트인 루트 체인 매니저 컨트랙트(RootChainManager Contract, 411)를 포함할 수 있으며, 블록체인 네트워크(300)가 포함하는 여러 리프 체인들(320 및 330) 각각을 위한 스마트 컨트랙트를 포함할 수 있다. 도 4의 실시예에서는 루트 체인(310)이 리프 체인 A(Leaf Chain A, 320)를 위한 스마트 컨트랙트인 리프 체인 A 컨트랙트(LeafChain A Contract, 412)와 리프 체인 B(Leaf Chain B, 330)를 위한 스마트 컨트랙트인 리프 체인 B 컨트랙트(LeafChain B Contract, 413)를 포함하는 예를 나타내고 있다.
또한, 리프 체인들(320 및 330) 각각은 디앱을 위한 스마트 컨트랙트를 포함할 수 있다. 도 4의 실시예에서는 리프 체인 A(320)가 디앱 컨트랙트(dApp Contract, 421)를, 리프 체인 B(330)가 디앱 컨트랙트(431)를 포함하는 예를 나타내고 있다. 또한, 리프 체인 A(320)는 리프 체인 A(320)를 위한 스마트 컨트랙트인 리프 체인 매니저 컨트랙트(LeafChainManager Contract, 422)를, 리프 체인 A(330)는 리프 체인 B(330)를 위한 스마트 컨트랙트인 리프 체인 매니저 컨트랙트(432)를 더 포함할 수 있다.
릴레이어(340)는 루트 체인(310)과 리프 체인들(320 및 330)의 블록 생성을 관찰하면서 루트 체인(310)과 리프 체인들(320 및 330)에 기록 및/또는 전달이 요구되는 정보를 인보크(invoke)할 수 있다. 릴레이어(340)는 프로듀서(Producer, 441), 카프카(Kafka, 442), 인터체인 컨슈머(InterChain Consumer, 443), 인터체인 페일오버(InterChain Failover, 444), 데이터베이스(Database, 445)를 포함할 수 있다.
프로듀서(441)는 루트 체인(310)을 포함하는 모든 체인의 새로 생성된 블록의 정보를 수집해서 카프카(442)에 입력할 수 있다. 카프카(442)는 일종의 큐 서버로서 수집된 정보를 큐에 저장하여 순차적으로 제공할 수 있다. 이때, 인터체인 컨슈머(443)는 각 체인별로 인보크가 요구되는 이벤트를 필터링할 수 있다. 이벤트에 따라 여러 개의 필터링이 요구될 수도 있다. 인터체인 컨슈머(443)는 각 체인에 인보크를 할 때, 시그니피케이션(signification)을 위해서 체인별로 별도의 유저를 생성하고, 유저의 권한을 스마트 컨트랙트에 기록할 수 있다.
인터체인 컨슈머(443)는 다음 (1) 내지 (7)과 같은 이벤트들을 감지할 수 있다.
(1) 리프 체인에서의 송금 요청 이벤트
(1-1) 인터체인 컨슈머(443)는 리프 체인에서의 송금 요청 이벤트를 감지하여 루트 체인으로 송금 요청 내용을 전달할 수 있다.
(2) 루트 체인에서의 송금 요청 이벤트
(2-1) 인터체인 컨슈머(443)는 루트 체인에서의 송금 요청 이벤트를 감지하여 송금 요청을 수신할 리프 체인으로 송금 요청 내용을 전달할 수 있다.
(2-2) 인터체인 컨슈머(443)는 수신하는 리프체인으로 전달 실패 시, 송금 요청을 수신할 리프 체인의 식별 정보를 포함하는 송금 실패 정보를 루트 체인으로 전달할 수 있다.
(3) 루트 체인에서의 송금 요청 실패 이벤트
(3-1) 인터체인 컨슈머(443)는 송금을 요청한 리프 체인으로 송금 실패 내용을 전달할 수 있다.
(4) 리프 체인에서의 송금 완료 이벤트
(4-1) 인터체인 컨슈머(443)는 루트 체인으로 송금 완료 내용을 전달할 수 있다.
(5) 루트 체인에서의 송금 완료 이벤트
(5-1) 인터체인 컨슈머(443)는 송금을 요청한 리프 체인으로 송금 완료 내용을 전달할 수 있다.
(6) 루트 체인에서 코인 발행 이벤트
(6-1) 인터체인 컨슈머(443)는 코인이 발행되는 리프 체인에 발행 내용을 전달할 수 있다.
(7) 리프 체인에서 블록 생성 이벤트
(7-1) 인터체인 컨슈머(443)는 루트 체인에 블록의 머클 트리 루트 해시를 전달할 수 있다.
인터체인 페일오버(444)는 (3-1), (4-1), (5-1), (6-1) 및 (7-1)이 정상적으로 전달될 수 있도록 장애극복 기능을 제공할 수 있으며, 데이터베이스(Database, 445)는 인터체인 컨슈머(443) 및 인터체인 페일오버(444)에서 수신 및/또는 전송(전달)하는 정보들을 저장하기 위해 활용될 수 있다.
도 5는 본 발명의 일실시예에 있어서, 새로운 리프 체인을 추가하는 과정의 예를 도시한 흐름도이다.
단계(510)에서 블록체인 네트워크(300)는 리프 체인을 구축할 수 있다. 예를 들어, 새로운 리프 체인은 이후 설명될 새로운 서비스를 추가하기 위해 구축될 수 있다.
단계(520)에서 블록체인 네트워크(300)는 리프 체인에 체인간 또는 컨트랙트간 코인 송금을 담당할 리프 체인 매니저 컨트랙트를 설치할 수 있다.
단계(530)에서 블록체인 네트워크(300)는 루트 체인에 해당 리프 체인을 처리할 수 있는 컨트랙트(이하 리프 체인 컨트랙트)를 설치할 수 있다.
단계(540)에서 블록체인 네트워크(300)는 설치된 루트 체인의 리프 체인 컨트랙트 주소를 루트 체인 매니저 컨트랙트에 등록할 수 있다. 이후 설명될 실시예들에 따라, 리프 체인의 서명 가능 컨트랙트(Signing Enable Contract)의 주소가 루트 체인 매니저 컨트랙트에 더 등록될 수도 있다. 또 다른 실시예에서는 리프 체인을 대표하는 퍼블릭 주소가 루트 체인 매니저 컨트랙트에 등록될 수도 있다.
단계(550)에서 블록체인 네트워크(300)는 루트 체인의 리프체인 컨트랙트에 접근 가능한 릴레이어 유저를 추가할 수 있다.
단계(560)에서 블록체인 네트워크(300)는 리프 체인의 리프 체인 매니저 컨트랙트에 접근 가능한 릴레이어 유저를 추가할 수 있다.
이때, 단계(550) 및 단계(560)의 릴레이어 유저는 동일한 유저일 수도 있고, 서로 다른 유저일 수도 있다. 리프 체인별로, 그리고 루트 체인과도 서로 다른 별도의 릴레이어 유저를 설정하여 활용하는 것이 보안상에서 유리할 수 있다. 여기서 릴레이어 유저는 블록체인 네트워크(300)가 제공하는 서비스의 계정에 대응할 수 있다.
도 6은 본 발명의 일실시예에 있어서, 새로운 서비스를 추가하는 과정의 예를 도시한 흐름도이다.
단계(610)에서 블록체인 네트워크(300)는 리프 체인에 해당 서비스의 컨트랙트를 설치할 수 있다. 설치한 컨트랙트의 주소는 해당 서비스를 구분하는 값으로 사용될 수 있다. 해당 서비스는 체인간 코인 교환 프로토콜을 갖춘 컨트랙트일 수 있다.
단계(620)에서 블록체인 네트워크(300)는 리프 체인의 리프 체인 매니저 컨트랙트에 해당 서비스에 대해 설치된 컨트랙트의 주소를 등록할 수 있다. 예를 들어, 도 5의 단계(520)에서는 리프 체인에 체인간 또는 컨트랙트간 코인 송금을 담당할 리프 체인 매니저 컨트랙트를 설치할 수 있음을 설명한 바 있다. 이러한 리프 체인 매니저 컨트랙트에 서비스를 위한 컨트랙트의 주소가 등록될 수 있다.
단계(630)에서 블록체인 네트워크(300)는 설치된 컨트랙트의 주소를 루트 체인의 루트 체인 매니저 컨트랙트에 등록할 수 있다. 이때, 설치된 컨트랙트의 주소는 루트 체인 매니저 컨트랙트의 관리자 권한을 통해 등록될 수 있다. 루트 체인 매니저 컨트랙트에 리프 체인의 서비스에 대해 설치된 컨트랙트의 주소를 루트 체인에 설치된 해당 리프 체인의 리프 체인 컨트랙트와 함께 등록하면, 루트 체인의 리프 체인 컨트랙트에도 리프 체인의 서비스에 대해 설치된 컨트랙트의 주소가 해당 리프 체인의 서비스로서 등록될 수 있다.
도 7은 본 발명의 일실시예에 있어서, 서비스에 코인을 발행하는 과정의 예를 도시한 흐름도이다.
단계(710)에서 루트 체인의 루트 체인 매니저 컨트랙트는 루트 체인에 설치된 리프 체인 컨트랙트에 등록된 서비스에 대한 컨트랙트의 주소에 대해 코인 발행을 요청할 수 있다. 예를 들어, 루트 체인의 루트 체인 매니저 컨트랙트는 루트 체인에 설치된 리프 체인 컨트랙트를 통해 코인을 발행하기 위한 서비스에 대한 컨트랙트의 주소를 통해 해당 서비스를 식별할 수 있으며, 식별된 서비스에 대해 코인 발행 이벤트를 발생시킬 수 있다.
단계(720)에서 인터체인 컨슈머는 해당 서비스에 대한 코인 발행 이벤트를 감지하여 해당 리프 체인의 리프 체인 매니저 컨트랙트에 서비스의 코인 발행을 요청할 수 있다.
단계(730)에서 리프 체인 매니저 컨트랙트는 해당 서비스를 찾아 코인을 발행할 수 있다. 이때, 코인은 해당 서비스의 컨트랙트를 설치할 때 입력한 서비스 오퍼레이터(일례로, 도 5의 단계(560)에서 추가된 릴레이어 유저)에게 발급될 수 있다.
도 8은 본 발명의 일실시예에 있어서, 코인 교환 과정의 예를 도시한 흐름도이다. 동일한 체인의 동일한 서비스에서의 코인 교환은 해당 리프 체인의 코인 교환을 위한 스마트 컨트랙트를 통해서 이루어질 수 있다. 또한, 동일한 체인의 다른 서비스들간의 코인 교환은 해당 리프 체인의 리프 체인 매니저 컨트랙트를 통해서 이루어질 수 있다. 예를 들어, 동일한 체인의 제1 서비스에서 제2 서비스로의 송금은 리프 체인 매니저 컨트랙트가 제1 서비스의 송금 요청에 따라 제2 서비스의 컨트랙트의 주소를 호출함에 의해 이루어질 수 있다. 이때, 동일한 리프 체인의 다른 서비스들간의 코인 교환 시, 코인 교환 결과가 루트 체인으로 전달될 수 있다. 이는 루트 체인이 리프 체인들의 각 서비스들이 보유한 코인의 양의 변경내용을 파악할 수 있도록 하기 위함이다. 반면, 다른 체인간의 코인 교환은 아래 단계들(810 내지 890)을 통해 이루어질 수 있다. 도 8의 단계들(810 내지 890)은 도 4를 통해 설명한 리프 체인 A(320)와 리프 체인 B(330)간의 코인 교환의 예를 설명한다.
단계(810)에서 리프 체인 A(320)는 유저 a의 리프 체인 B(330)의 유저 b에 대한 코인 교환 요청(송금 요청)을 수신할 수 있다. 이때, 리프 체인 A(320)는 유저 a의 잔고 등을 파악하여 코인 교환 요청이 정상적인 요청인 경우 리프 체인 A(320)의 블록에 기록할 수 있다. 교환 요청된 코인(송금 요청된 코인)은 리프 체인 A(320)가 포함하는 리프 체인 매니저 컨트랙트에 의해 유저 a의 잔고에서 차감될 수 있으며, 사용되지 않도록 잠금(lock)될 수 있다. 예를 들어, 리프 체인 A(320)의 리프 체인 매니저 컨트랙트는 송금 요청된 금액만큼 유저 a의 잔고와 송금 요청하는 서비스의 잔고를 확인한 후에 리프 체인 A(320)의 통화량에서 차감되는 금액이 사용되지 않도록 잠금을 설정할 수 있다. 차감된 유저 a의 금액에 대한 정보는 에스크로 컨트랙트에 기록될 수 있다. 이러한 송금의 성공에 대한 기록은 프로듀서(441)에 의해 카프카(442)에 기록될 수 있다. 송금 요청이 정상적이지 않은 경우, 리프 체인 A(320)는 송금 요청의 실패 내용을 블록에 기록할 수 있다. 또한, 리프 체인 A(320)는 송금 요청의 실패 시 이벤트를 기록하지 않음으로써 송금이 발생하지 않도록 할 수 있다.
단계(820)에서 인터체인 컨슈머(443)는 리프 체인 A(320)에서 리프 체인 B(330)로의 송금 요청 이벤트를 감지하고, 루트 체인(310)에 해당 송금 요청을 전달할 수 있다. 송금 요청 이벤트의 감지는 프로듀서(441)의 거래 수집에 의해 감지될 수 있으며, 인터체인 컨슈머(443)는 감지된 송금 요청 이벤트의 감지에 응답하여 루트 체인(310)에 해당 송금 요청을 전달할 수 있다.
단계(830)에서 루트 체인(310)은 리프 체인 A(320)에서 발급한 총 코인량을 송금 요청 정보들을 이용하여 분석함으로써 해당 송금 요청이 정상적인 요청인지 여부를 확인하고, 해당 송금 요청이 정상적인 요청인 경우 리프 체인 A(320)에서 리프 체인 B(330)로의 코인 교환 요청을 블록에 기록할 수 있다. 교환 요청은 송금하는 코인량만큼 사용되지 않도록 잠금(lock)될 수 있다. 또한, 루트 체인(310)은 해당 송금 요청이 정상적인 요청이 아닌 경우 실패 내용을 블록에 기록할 수 있다. 실패로 기록된 송금 요청은 다시 인터체인 컨슈머(443)에서 송금 실패 이벤트로 감지되어 리프 체인 A(320)로 전달될 수 있으며, 송금 실패 이벤트를 수신한 리프 체인 A(320)는 잠금된 코인을 풀어서 다시 유저 a에게 돌려줄 수 있다.
단계(840)에서 인터체인 컨슈머(443)는 루트 체인(310)에서 리프 체인 B(330)로의 송금 요청 이벤트를 감지하고, 리프 체인 B(330)로 해당 송금 요청을 전달할 수 있다. 만약, 리프 체인 B(330)가 정상 동작하지 않아서 인보크가 실패할 경우, 다시 루트 체인(310)으로 리프 체인 B(330)의 시스템 이상에 따른 전달 실패 내용을 전송할 수 있다. 실패로 기록된 요청은 다시 인터체인 컨슈머(443)에서 송금 실패 이벤트로 감지되어 리프 체인 A(320)로 전달될 수 있으며, 송금 실패 이벤트를 수신한 리프 체인 A(320)는 잠금된 코인을 풀어서 다시 유저 a에게 반환할 수 있다.
단계(850)에서 리프 체인 B(330)는 해당 송금 요청이 정상적인 요청인 경우, 유저 b에게 코인을 송금하고 리프 체인 B(330)의 전체 통화량을 송금된 코인량만큼 증가시킬 수 있다. 송금 요청이 실패하는 경우에는 실패 내용을 블록에 기록할 수 있다.
단계(860)에서 인터체인 컨슈머(443)는 리프 체인 B의 송금 완료 결과를 이벤트로 감지해서 해시와 성공 여부를 루트 체인(310)에 전달할 수 있다.
단계(870)에서 루트 체인(310)은 송금 결과를 수신하여 송금 실패와 송금 성공에 따라 처리할 수 있으며, 그 결과를 해시와 함께 블록에 기록할 수 있다. 송금이 성공한 경우, 루트 체인(310)은 잠금된 코인 송금 요청을 풀어서, 리프 체인 A(320)에서 리프 체인 B(330)로의 송금을 진행하고 각각의 통화량을 변경할 수 있다. 송금이 실패한 경우, 루트 체인(310)은 잠금된 코인 송금 요청을 풀어서 다시 리프 체인 A(320)로 돌려줄 수 있다.
단계(880)에서 인터체인 컨슈머(443)는 루트 체인(310)에서 처리한 송금 결과 이벤트를 감지해서 리프 체인 A(320)에 그 결과를 전달할 수 있다.
단계(890)에서 리프 체인 A(320)는 송금 결과를 수신하여 성공일 경우 잠금된 코인을 풀어서 리프 체인 A(320)의 전체 통화량을 조절(전체 통화량에서 송금액만큼 차감)할 수 있다. 송금이 실패한 경우, 리프 체인 A(320)는 잠금된 코인을 풀어서 다시 유저 a에게 돌려줄 수 있다. 리프 체인 A(320)는 이러한 송금 결과를 루트 체인(310)에 기록된 해시와 함께 블록에 기록할 수 있다.
도 9는 본 발명의 일실시예에 있어서, 각 체인간 스마트 컨트랙트를 통한 코인 교환 데이터의 흐름을 도시한 도면이다.
(1) 유저 a의 코인 교환 요청을 리프 체인 A(320)의 디앱 1(dApp 1, 920)이 수신하면, 디앱 1(920)은 리프 체인 매니저 컨트랙트 A(910)에 교환 요청을 할 수 있다. 리프 체인 매니저 컨트랙트 A(910)는 교환 거래 해시(eTxHash)를 생성하고, 교환 거래 해시, 송금하려는 유저 a(의 식별자)와 서비스 a(의 식별자), 송금받는 서비스 b(의 식별자)와 유저 b(의 식별자), 금액 정보(송금 금액) 및/또는 요청 시간을 기록(송금 요청 기록(에스크로(escrow) 정보)를 생성)할 수 있다. 이때 리프 체인 매니저 컨트랙트 A(910)는 디앱 1(920)의 컨트랙트의 전체 통화량과 유저 a의 보유 금액을 차감할 수 있다.
(2) 프로듀서(441)는 (1) 에서 생성된 거래를 수집할 수 있고, 인터체인 컨슈머(443)는 루트 체인(310)의 리프 체인 A 컨트랙트(412)에 송금을 요청할 수 있다.
(3) 리프 체인 A 컨트랙트(412)는 루트 체인 매니저 컨트랙트(411)를 통해서 송금 요청 정보를 루트 체인(310)에 대해 별도로 기록할 수 있다. 이때, 리프 체인 매니저 A 컨트랙트(412)가 관리하는 디앱 1(920)의 전체 통화량을 송금 금액만큼 차감할 수 있다.
(4) 프로듀서(441)는 (3)에서 생성된 거래를 수집할 수 있고, 인터체인 컨슈머(443)는 송금을 받는 서비스가 있는 리프 체인 B(330)의 리프 체인 매니저 컨트랙트 B(940)에 송금을 요청할 수 있다.
(5) 리프 체인 B(330)의 리프 체인 매니저 컨트랙트 B(940)는 송금하려는 서비스인 디앱 3(950)을 호출해서 디앱 3(950)의 컨트랙트에서 유저 b에게 송금이 이뤄지도록 할 수 있다. 이때, 디앱 3(950)의 컨트랙트는 리프 체인 B(330)의 전체 통화량도 증가시킬 수 있다.
(6) 프로듀서(441)는 (5)에서 생성된 거래를 수집할 수 있고, 인터체인 컨슈머(443)는 루트 체인(310)의 리프 체인 B 컨트랙트(413)에 송금 완료를 요청할 수 있다.
(7) 루트 체인(310)의 리프 체인 B 컨트랙트(413)는 루트 체인 매니저 컨트랙트(411)에 해당 송금 요청의 에스크로(escrow, 송금 요청 기록) 정보를 가져와서 송금 완료를 처리할 수 있다. 송금이 성공한 경우, 리프 체인 B 컨트랙트(413)가 관리하는 디앱 3(950)에서 송금 금액만큼의 리프 체인 B(330)의 전체 통화량이 증가될 수 있고, 루트 체인(310)의 루트 체인 매니저 컨트랙트(411)에서 해당 송금 요청 기록이 삭제될 수 있다. 송금이 실패한 경우, 리프 체인 A 컨트랙트(412)에 등록된 송금 요청한 서비스인 디앱 1(920)에 송금 금액만큼 리프 체인 A(320)의 전체 통화량이 다시 증가될 수 있고, 그 후에 루트 체인(310)의 루트 체인 매니저 컨트랙트(411)에서 해당 송금 요청 기록이 삭제될 수 있다.
(8) 프로듀서(441)는 (7)에서 생성된 거래를 수집할 수 있고, 인터체인 컨슈머(443)는 송금한 리프 체인 A(320)의 리프 체인 매니저 컨트랙트 A(910)에 송금 완료를 요청할 수 있다.
(9) 리프 체인 A(320)의 리프 체인 매니저 컨트랙트 A(910)는 송금 완료 정보를 수신하고 해당 교환 거래 해시가 완료됨을 기록하고 송금 요청 기록(escrow)에 있는 해당 요청을 삭제할 수 있다. 송금이 실패한 경우, 리프 체인 매니저 컨트랙트 A(910)는 송금 요청 기록(escrow)에 있는 금액을 유저 a에게 다시 반환할 수 있으며, 디앱 1(920)의 전체 통화량도 송금 금액만큼 다시 증가시킨 후에 송금 요청 기록(escrow)에서 해당 요청을 삭제할 수 있다.
실시예에 따라 릴레이어는 체인마다 존재할 수도 있다. 예를 들어, 도 4를 통해 설명한 바와 같이 하나의 루트 체인(310)과 두 개의 리프 체인들(320 및 330)이 존재하는 경우, 총 세 개의 체인들을 위한 세 개의 릴레이어들이 구성될 수도 있다. 이 경우, 루트 체인(310)의 릴레이어는 두 개의 리프 체인들(320 및 330)과의 요청, 데이터 및/또는 이벤트의 전달을 처리할 수 있으며, 두 개의 리프 체인들(320 및 330) 각각의 릴레이어는 루트 체인(310)과의 요청, 데이터 및/또는 이벤트의 전달을 처리할 수 있다. 이때, 리프 체인들을 위한 릴레이어들의 담합을 방지하기 위해, 릴레이어들 각각과 연결되는 체인은 기설정된 시간 주기(일례로, 블록 시간 주기)마다 동적으로 변경될 수 있다. 이러한 실시예에서 해시는 해시 시간 잠금 컨트랙트(Hashed timelock contract)를 통해 체인 간 이동시에 릴레이어에 의해 교환 거래가 중간에 강탈되거나 변조되지 않도록 할 수 있다. 이러한 해시 시간 잠금은 유저들이 교환 거래의 결과를 직접 확인할 수 있는 시간을 제공하기 위해 이용될 수 있다. 또한, 릴레이어의 의도치 않은 이중지불을 방지하기 위한 유니크한 식별자로서 별도의 교환 거래 식별자가 활용될 수 있다. 이러한 교환 거래 식별자는 리프 체인들간의 가치 이동이 있을 경우, 교환 거래를 유일하게 식별하여 트래킹하기 위해 활용될 수 있다.
이러한 블록체인 네트워크(300)에서 체인간에 데이터를 전달할 때, 전달하는 시스템에서 전달할 데이터를 변조할 가능성이 존재한다. 일례로, 리프 체인 A(320)에서 루트 체인(310)으로 데이터를 전달할 때, 리프 체인 A(320)에서 데이터를 변조할 가능성이 존재한다. 특히, 리프 체인들을 퍼블릭 블록체인의 형태로 확장할 수 있도록 하기 위해 리프 체인들마다 릴레이어가 구현되는 경우, 이러한 릴레이어에 대한 의존도를 줄이고 프로토콜 단에서 데이터 인증의 문제를 해결할 필요성이 있다. 이를 위해, 블록체인 네트워크(300)는 아래와 같은 다섯 가지 요구사항을 갖는다.
1. 베이스 코인(Base Coin)의 체인들간 송금이 가능해야 한다. 여기서 베이스 코인은 블록체인 네트워크(300)의 고유한 코인체계에서 사용되는 코인을 의미할 수 있다.
2. 루트 체인이 모든 체인의 베이스 코인을 관리할 수 있어야 한다. 이때, 베이스 코인의 관리는 체인들간의 베이스 코인의 송금을 포함할 수 있다.
3. 릴레이어가 데이터를 변조해서 전달하지 못하도록 해야 한다.
4. 리프 체인에서 송금 수신을 받아서 유저에게 송금은 성공했지만, 실패 메시지를 전달함에 의해 이중 지불이 발생하지 않도록 해야 한다.
5. 송금에서 베이스 코인을 수신하는 사용자의 확인 없이 빠르게 체인간 송금이 이루어져야 한다.
이러한 요구사항을 위해, 루트 체인에서는 권한을 가진 사용자를 통해 베이스 코인의 발행(mint)과 소각(burn)이 발생하도록 할 수 있다. 또는 권한이 있는 사용자들이 멀티시그-월렛(multisig-wallet)으로 확인을 받아서 베이스 코인을 발행 또는 소각시킬 수 있도록 할 수 있다. 이때, 리프 체인에서는 루트 체인에서 코인 발행 요청을 받는 경우에 발행을 실행할 수 있다. 또한, 리프 체인에서 다른 리프 체인으로 송금을 할 경우, 두 리프 체인에서는 루트 체인의 인증된 정보가 전달된 것을 확인한 후, 발행과 소각이 실행될 수 있다. 예를 들어, 베이스 코인을 송금하는 리프 체인에서는 해당 베이스 코인에 대한 소각을 실행할 수 있으며, 베이스 코인을 수신하는 리프 체인에서는 해당 베이스 코인에 대한 발행을 실행할 수 있다.
한편, 릴레이어의 데이터 변조를 막기 위해서는 전달하려는 데이터가 변조될 수 없도록 해야 한다. 이하에서는 데이터의 변조를 차단하기 위한 방법들을 설명한다.
첫 번째 방법에서는, 전달하려는 원본 데이터를 서명(signing)할 수 있다. 만약, 데이터를 전송하는 주체(from user)가 데이터를 수신하려는 체인에서 이미 알고 있는 사용자인 경우, 서명된 원본 데이터를 통해 원본 데이터의 변조 여부를 확인할 수 있다. 이를 위해, 컨트랙트는 컨트랙트 자신의 프라이빗 키(private key)를 가진 상태로 생성될 수 있으며, 프라이빗 키에 대응하는 퍼블릭 키(public key)를 공개할 수 있다. 이때, 컨트랙트에서 다른 체인에 전달이 필요한 정보들을 서명하여 이벤트로 기록할 수 있으며, 따라서 원본 데이터가 해당 컨트랙트로부터 처리되었다는 것을 증명할 수 있다. 예를 들어, 컨트랙트는 원본 데이터와 자신의 컨트랙트 주소를 컨트랙트의 프라이빗 키로 서명할 수 있다. 이 경우, 임의의 사용자는 컨트랙트의 프라이빗 키에 대응하는 퍼블릭 키(public key)를 이용하여 서명된 원본 데이터를 검증할 수 있으며, 모든 체인에서 유일하게 생성되는 해당 컨트랙트의 컨트랙트 주소를 통해 해당 컨트랙트에 의해 데이터가 전달되었음이 증명될 수 있다. 그러나, 첫 번째 방법에서 컨트랙트의 프라이빗 키는 컨트랙트의 데이터베이스에 저장되어야 하며, 블록체인 네트워크에서 데이터베이스는 공유 및 오픈되기 때문에 체인의 모든 노드들에게 프라이빗 키가 공유되며, 따라서 더 이상 프라이빗 키가 아니게 된다.
두 번째 방법에서는, 프라이빗 키를 컨트랙트에 저장하는 것이 아니라, 하나의 체인을 대표하는 프라이빗 키를 같은 체인내에서 합의(consensus)를 이루는 노드들인 C-노드들과 공유하여 체인 인증이 요구될 때 사용하게 할 수 있다. 일례로, 각 체인들은 합의를 위한 n(일례로, n은 4 내지 8) 개의 C-노드들이 프라이빗 키를 공유하여 유지할 수 있다. 사용자나 다른 컨트랙트는 해당 체인을 위한 시스템(일례로, 해당 체인에 설치된 시스템 컨트랙트)에 데이터의 서명을 요구할 수 있으며, 시스템은 요구된 데이터에 서명을 하여 서명된 데이터를 제공할 수 있다. 이때, 해당 체인의 컨트랙트는 데이터의 서명과 전달에 대한 이벤트를 기록할 수 있으며, 릴레이어를 통해 다른 체인으로 서명된 데이터를 전달할 수 있다. 예를 들어, 루트 체인에서 루트 체인의 프라이빗 키와 쌍을 이루는 퍼블릭 키를 통해 만들어지는 식별값인 퍼블릭 주소는 리프 체인의 제네시스(genesis) 블록에 기록됨에 따라 리프 체인에서 변조할 수 없게 된다. 루트 체인을 통해 프라이빗 키로 서명된 데이터는 리프 체인에서 제네시스 블록에 기록된 퍼블릭 주소와 비교함으로써 서명된 데이터가 루프 체인에서 발송된 것임을 검증할 수 있다. 이와 유사하게 리프 체인 역시 리프 체인의 프라이빗 키로 만들어지는 퍼블릭 주소를 루트 체인에 해당 리프 체인과 연관하여 설치된 리프 체인 컨트랙트에 등록할 수 있다. 이 경우, 루트 체인은 리프 체인을 통해 리프 체인의 프라이빗 키로 서명된 데이터를 해당 리프 체인 컨트랙트에 등록된 퍼블릭 주소와 비교함으로써, 서명된 데이터가 해당 리프 체인에서 발송된 것임을 검증할 수 있다. 다만, 두 번째 방법은 합의를 위한 C-node들에서 프라이빗 키를 공유할 수 있는 프라이빗 블록체인에서는 사용 가능하지만, 외부 서비스의 제공을 위해 공개되는 퍼블릭 블록체인(퍼블릭 리프 체인)에서는 사용이 불가능하다.
세 번째 방법은, 루트 체인의 모든 C-노드들 각각이 합의를 위해서 갖고 있는 고유의 프라이빗 키를 활용하는 방법이다. 일례로, 루트 체인이 8 개의 C-노드를 포함하는 경우, 8 개의 프라이빗 키들이 존재할 수 있다. 이 경우, 해당 프라이빗 키들에 의해 생성되는 루트 체인의 모든 C-노드들 각각의 퍼블릭 주소들이 모든 리프 체인들 각각에 저장될 수 있다. 이때, 루트 체인에서 생성된 것임을 확인할 필요가 있는 데이터는 루트 체인의 리더 노드가 자신의 프라이빗 키로 서명하여 블록에 기록할 수 있으며, 해당 데이터가 리프 체인으로 전달되도록 할 수 있다. 여기서, 리더 노드는 C-노드들 중 임의로 선정된 노드일 수 있으며, 필요 시 다른 C-노드들 중 하나로 변경될 수 있다. 이 경우, 리프 체인은 서명된 데이터를 리프 체인에 저장된 퍼블릭 주소와 비교함으로써 서명된 데이터가 루프 체인에서 발송된 것임을 검증할 수 있다. 앞서 설명한 바와 같이, 리프 체인은 루트 체인의 모든 C-노드들의 퍼블릭 주소를 알고 있기 때문에, 서명된 데이터를 검증할 때 얻어지는 퍼블릭 주소가 이미 알고 있는 루트 체인의 C-노드들의 퍼블릭 주소들 중 하나인지 여부를 검증함으로써, 서명된 데이터를 검증할 수 있다. 다만, 루프 체인이 포함하는 C-노드의 수가 공개되며, C-노드를 루트 체인에 추가 또는 삭제하는 등의 변경이 발생하는 경우, 모든 리프 체인 각각에 기록된 정보를 갱신해야 한다. 특히, 외부 서비스를 위해 할당된 퍼블릭 블록체인(퍼블릭 리프 체인)에 기록된 정보는 직접 갱신할 수 없기 때문에 해당 퍼블릭 블록체인에서 기록된 정보를 갱신하도록 정보를 제공(퍼블릭 주소의 갱신이 가능하도록 하기 위한 정보를 공지)해야 한다. 이와 유사하게 리프 체인의 C-노드들 역시 합의를 위해 고유의 프라이빗 키를 가질 수 있으며, 이러한 프라이빗 키가 활용될 수 있다. 이 경우, C-노드들 각각의 퍼블릭 주소들은 루트 체인에 해당 리프 체인과 연관하여 설치된 리프 체인 컨트랙트에 등록될 수 있으며, 루트 체인은 서명된 데이터를 해당 리프 체인 컨트랙트에 등록된 퍼블릭 주소와 비교함으로써, 서명된 데이터가 해당 리프 체인에서 발송된 것임을 검증할 수 있다.
네 번째 방법은, 루트 체인의 모든 C-노드에서 생성되는 퍼블릭 주소의 조합으로 만들어지는 대표 퍼블릭 주소(Common Public Address)를 모둔 리프 체인들 각각에 공유하는 방법이다. 이 경우에도 루프 체인에 C-노드를 추가 또는 삭제하는 등의 변경이 발생하는 경우, 모든 리프 체인 각각에 기록된 정보를 갱신해야 하나 리프 체인들 각각에서 공유해야 할 퍼블릭 주소를 대표 퍼블릭 주소 하나로 줄일 수 있으며, 루프 체인이 포함하는 C-노드의 수는 공개되지 않는다는 장점이 있다. 다만, 대표 퍼블릭 주소가 변경되기 때문에 변경 시에 보안을 주의해야 한다. 네 번째 방법에서는 루트 체인의 모든 C-노드의 퍼블릭 주소 각각을 모든 C-노드들 각각이 다 알고 있어야 한다. 또한, 네 번째 방법에서는 프라이빗 키가 여러 개가 있다 하더라도 하나의 퍼블릭 주소(대표 퍼블릭 주소)를 만들 수 있으며, 프라이빗 키가 하나 이상의 컨펌을 통해 암호를 풀 수 있도록 서명을 위한 알고리즘과 이를 검증하는 알고리즘을 수정한 모듈이 요구된다.
다섯 번째 방법에서는 첫 번째 방법을 활용 가능하도록 하기 위해 블록체인에 다음과 같은 기능을 추가할 수 있다. 다섯 번째 방법에서는 컨트랙트가 퍼블릭 키로 컨트랙트 주소를 생성하고, 프라이빗 키를 암호화해서 컨트랙트가 저장하도록 할 수 있다. 프라이빗 키를 알고 있으며, 프라이빗 키를 통해서 퍼블릭 키를 얻을 수 있으며, 퍼블릭 키를 통해 컨트랙트 주소를 생성할 수 있다. 이때, 서명을 위한 컨트랙트(이하, 서명 가능 컨트랙트(Signing Enable Contract))는 하나의 체인에 하나만 존재해도 무방하다. 예를 들어, 서명 가능 컨트랙트의 설치(deploy) 시 암호화된 프라이빗 키와 프라이빗 키로 생성되는 퍼블릭 키가 파라미터로서 서명 가능 컨트랙트로 전달될 수 있다. 서명 가능 컨트랙트는 수신한 퍼블릭 키로 컨트랙트 주소를 생성할 수 있다. 이때, 동일한 컨트랙트 주소가 있다면, 컨트랙트 주소의 생성은 실패할 수 있다. 암호화된 프라이빗 키는 이후 설명될 패스워드를 통해 복호화될 수 있으며, 서명 가능 컨트랙트에 의해 데이터베이스에 저장될 수 있다. 이때, 임의의 컨트랙트가 데이터를 서명하고자 하는 경우, 서명하고자 하는 데이터와 서명 가능 컨트랙트에 저장된 암호화된 프라이빗 키를 복호화할 수 있는 패스워드를 파라미터로서 서명 가능 컨트랙트에 전달할 수 있다. 이때, 블록체인에서 모든 요청(일례로, HTTPS(Hypertext Transfer Protocol Secure)를 이용한 요청)에 따른 정보들은 블록이나 로그에 기록되는 반면, 패스워드는 어디에도 저장/기록되지 말아야 한다. 따라서, 다섯 번째 방법에서는 패스워드 파라미터를 블록이나 로그 등 어디에도 저장/기록되지 않는 타입(이하 '시큐어 타입')으로 정의될 수 있다. 이러한 패스워드 파라미터는 해당 블록체인에서 지원될 수 있다. 이 경우, 서명 가능 컨트랙트는 패스워드를 통해 암호화된 프라이빗 키를 복원한 후, 복원된 프라이빗 키를 이용하여 입력된 데이터를 서명할 수 있으며, 서명한 결과(서명된 데이터)를 서명을 요청한 컨트랙트로 반환할 수 있다. 서명 가능 컨트랙트의 컨트랙트 주소는 각 리프 체인의 제네시스 블록에 기록될 수 있다. 다만, 다섯 번째 방법에서는 시스템상에서 시큐어 타입을 별도로 정의하여 활용해야 하며, 암호화된 프라이빗 키와 퍼블릭 키가 시스템 외부에서 생성되어 제공되어야 하며, 프라이빗 키가 암호화되어 전달되기 때문에 프라이빗 키를 정상적으로 생성되어 전달되는지 여부를 확인할 수 없다. 루트 체인에서 전송되는 데이터임을 리프 체인이 입증하기 위해, 리프 체인에서는 해당 데이터를 서명한 서명 가능 컨트랙트가 루트 체인에 설치된 컨트랙트인지 루트 체인에 조회하여 바로 파악할 수 있으며, 해당 서명 컨트랙트가 루트 체인에 컨트랙트에 존재하는 컨트랙트라는 것이 입증되면, 서명된 데이터가 루트 체인에서 생성 또는 처리된 데이터라는 것이 입증될 수 있다.
도 10은 본 발명의 일실시예에 있어서, 서명 가능 컨트랙트의 설치 과정의 예를 도시한 도면이다. 도 10은 서명 가능 컨트랙트(1010)가 암호화된 프라이빗 키(1020)와 퍼블릭 키(1030)를 파라미터로서 수신하고, 수신된 퍼블릭 키(1030)를 이용하여 퍼블릭 주소를 생성하여 데이터베이스(1040)에 저장하는 예를 나타내고 있다. 다시 말해, 데이터베이스(1040)에는 암호화된 프라이빗 키(1020)와 퍼블릭 키(1030), 그리고 퍼블릭 키(1030)를 이용하여 생성된 퍼블릭 주소가 저장될 수 있다.
도 11은 본 발명의 일실시예에 있어서, 데이터를 서명하는 과정의 예를 도시한 도면이다. 도 11은 서명 가능 컨트랙트(1010)가 사용자나 다른 컨트랙트(1110)로부터의 서명 요청을 수신하는 예를 나타내고 있다. 이때, 서명 요청은 서명하기 위한 데이터와 도 10에서 설명한 암호화된 프라이빗 키(1020)를 복호화하기 위한 패스워드를 포함할 수 있다. 이 경우, 서명 가능 컨트랙트(1010)는 패스워드를 이용하여 암호화된 프라이빗 키(1020)를 복호화하여 프라이빗 키를 얻을 수 있으며, 복호화된 프라이빗 키를 이용하여 파라미터로서 전달된 데이터를 서명할 수 있다. 이후, 서명 가능 컨트랙트(1010)는 서명된 데이터를 결과로서 사용자나 다른 컨트랙트(1110)로 반환할 수 있다. 여기서 사용자는 해당 블록체인의 노드에 대응할 수 있다.
여섯 번째 방법에서는 다섯 번째 방법의 서명 가능 컨트랙트가 블록체인의 시스템 컨트랙트로 자동 설치될 수 있도록 할 수 있다. 다시 말해, 블록체인의 시스템 컨트랙트가 설치될 때 서명 가능 컨트랙트도 같이 설치되도록 할 수 있다. 예를 들어, 리더 노드와 같이 시스템 컨트랙트를 최초 생성하는 노드가 프라이빗 키를 생성하여 서명 가능 컨트랙트를 설치할 수 있다. 생성된 프라이빗 키는 서명 가능 컨트랙트를 통해 암호화되어 데이터베이스에 저장될 수 있으며, 암호화된 프라이빗 키를 복호화하기 위한 패스워드는 해당 노드의 퍼블릭 키로 암호화하여 해당 노드의 로컬에 저장될 수 있다. 다른 노드는 트랜잭션을 복제하고 최신 패스워드를 아는 노드를 검색할 수 있다. 이때, 다른 노드는 검색되는 노드에 자신의 퍼블릭 키를 전달해서 퍼블릭 키로 암호화된 패스워드를 수신하여 해당 다른 노드의 로컬에 저장할 수 있다. 각 노드들은 서명을 요청할 때, 자신의 퍼블릭 키로 자신의 로컬에 저장된 암호화된 패스워드를 복호화하여 패스워드를 얻을 수 있으며, 얻어진 패스워드를 서명 요청 함수의 파라미터로서 서명 가능 컨트랙트로 전달할 수 있다. 요청은 블록체인에서 제공하는 서명 API 또는 함수를 이용하여 처리될 수 있다. 서명 가능 컨트랙트의 퍼블릭 주소는 각 리프 체인의 제네시스 블록에 기록될 수 있다. 루트 체인에서 전송되는 데이터임을 입증하기 위해서는 서명 가능 컨트랙트를 활용할 수 있다.
도 12는 본 발명의 일실시예에 있어서, 서명 가능 컨트랙트의 설치 과정의 다른 예를 도시한 도면이다. 도 12는 노드가 생성한 프라이빗 키를 서명 가능 컨트랙트(1210)가 노드의 퍼블릭 키(1220)로 암호화하여 데이터베이스(1230)에 저장하는 예를 나타내고 있다. 이때, 서명 가능 컨트랙트(1210)는 암호화된 프라이빗 키를 복호화하기 위한 패스워드를 노드의 퍼블릭 키로 암호화되어 해당 노드로 반환할 수 있다. 반환된 암호화된 패스워드는 노드의 로컬에 저장될 수 있다.
도 13은 본 발명의 일실시예에 있어서, 데이터를 서명하는 과정의 다른 예를 도시한 도면이다. 도 13은 노드(1310)가 암호화된 패스워드를 노드(1310)의 프라이빗 키로 복호화하여 패스워드를 획득한 후, 획득한 패스워드를 파라미터로 시스템(1320)에 전달하여 데이터의 서명을 요청하는 예를 나타내고 있다. 여기서 시스템(1320)은 블록체인 시스템에 대응할 수 있다. 이때, 서명하고자 하는 데이터 역시 파라미터로 함께 시스템(1320)에 전달될 수 있다. 이 경우, 시스템(1320)은 패스워드를 이용하여 서명 가능 컨트랙트(1210)로 데이터의 서명을 요청할 수 있다. 이 경우, 서명 가능 컨트랙트(1210)는 패스워드를 통해 암호화된 프라이빗 키를 복호화할 수 있으며, 복호화된 프라이빗 키를 이용하여 데이터를 서명한 후, 서명된 데이터를 반환할 수 있다. 시스템(1320)은 반환된 서명된 데이터를 노드(1310)로 전달할 수 있다.
한편, 리프 체인에서 내부에서 처리한 내용과 전달하는 내용이 다르지 않도록 해야 한다. 이를 위해, 송금을 처리한 트랜잭션의 머클 트리의 증명 해시 목록을 처리 결과와 같이 이벤트를 통해서 전달할 수 있도록 해야 한다. 만약, 감시자가 존재한다면, 머클 트리의 증명 정보까지 전달해야 할지 여부를 결정할 필요가 있다. 전달할 이벤트 정보를 컨트랙트의 프라이빗 키로 서명해서 이벤트에 기록할 수 있으며, 이 경우 해당 트랜잭션이 처리되었다는 것은 알 수 있지만, 처리 내용을 변조했는지 여부는 파악할 수 없기 때문에 감시자가 필요할 수도 있다. 이때, 감시자는 해당 블록이 존재하는지의 여부와 해당 트랜잭션이 이벤트로 전달한 데이터와 같이 송금이 성공인지, 실패인지 여부를 확인할 수 있다. 감시자에 의해서 부정이 발견되면 해당 리프 체인에는 불이익이 제공될 수 있다. 여기서 감시자는 위 기능을 실행하는 노드의 형태로 구현될 수 있다.
도 14는 본 발명의 일실시예에 있어서, 코인 교환 방법의 다른 예를 도시한 도면이다. 동일한 체인의 동일한 서비스에서의 코인 교환이나 동일한 체인의 다른 서비스들간의 코인 교환에 대해서는 도 8의 실시예를 통해서도 설명한 바 있다. 도 14는 도8의 실시예와는 다른 실시예로서, 루트 체인(1410), 리프 체인 1(1420) 및 리프 체인 2(1430)를 나타내고 있으며, 리프 체인 1(1420)의 사용자 1이 리프 체인 2(1430)의 사용자 2에게 송금을 요청한 경우를 가정한다.
과정 1은 리프 체인 1(1420)에서 송금 요청이 정상적인 요청인지 여부를 확인한 후, 문제가 없는 경우에 송금 요청에 대한 정보를 루트 체인(1410)으로 전달하는 과정의 예일 수 있다.
과정 2는 루트 체인(1410)에서 송금 요청이 정상적인 요청인지 여부를 확인한 후, 문제가 없는 경우에 리프 체인 2(1430)로 송금이 가능한지 여부에 대한 확인 요청을 보내는 과정의 예일 수 있다.
과정 3은 리프 체인 2(1430)에서 송금 요청이 수신 가능한 요청인지 확인한 후, 문제가 없는 경우에 루트 체인(1410)으로 수신가능 응답을 전송하는 과정의 예일 수 있다.
과정 4는 루트 체인(1410)이 리프 체인 1(1420) 및 리프 체인 2(1430)에 각각 송금 금액을 차감 또는 증액하는 영수증을 발행하는 과정의 예일 수 있다. 과정 4.1은 루트 체인(1410)이 리프 체인 1(1420)로 송금 금액 차감을 위한 영수증을 발행하는 과정의 예일 수 있으며, 과정 4.2는 루트 체인(1410)이 리프 체인 2(1430)로 송금 금액 증액을 위한 영수증을 발행하는 과정의 예일 수 있다. 각 체인에서는 중복 차감이나 중복 증액이 발생하지 않도록 하기 위한 관리가 이루어질 수 있다.
이하에서는 스마트 컨트랙트의 구성에 대해 설명한다.
스마트 컨트랙트는 루트 체인의 경우에는 앞서 도 4를 통해 설명한 바와 같이 루트 체인 매니저 컨트랙트를 포함할 수 있으며, 각 리프 체인들 각각을 위한 컨트랙트를 포함할 수 있다. 한편, 리프 체인은 서비스 디앱이 존재하는 경우에는 리프 체인 매니저 컨트랙트와 디앱 컨트랙트를 포함할 수 있으며, 서비스 디앱이 존재하지 않는 경우에는 리프 체인 매니저 컨트랙트를 포함할 수 있다. 루트 체인 매니저 컨트랙트와 리프 체인 매니저 컨트랙트는 시스템 컨트랙트로서 블록체인이 설치될 때 자동으로 설치될 수 있다. 릴레이어는 이벤트 로그(eventLogs)를 필터링해서 각각의 체인에 전달할 수 있다. 각 체인은 릴레이어가 데이터를 변조할 수 없도록 관리할 수 있다. 이미 설명한 바와 같이, 루트 체인은 각 리프 체인의 프라이빗 키로 만들어진 퍼블릭 주소를 저장할 수 있으며, 리프 체인은 루트 체인의 고유한 프라이빗 키로 만들어지는 퍼블릭 주소를 제네시스 블록을 생성할 때 기록할 수 있다. 릴레이어가 전달할 정보를 모두 루트 체인의 고유한 프라이빗 키로 서명한 정보도 함께 전달될 수 있도록 할 수 있다.
또한, 리프 체인에 서비스 디앱이 존재하는 경우, 사용자는 디앱의 "exchange"를 정의한 함수를 호출할 수 있다. 이때, 디앱에서는 icx에 정의된 "exchange"를 호출할 수 있으며, 이에 icx 클래스에서 'exchange 기능이 구현될 필요가 있다.
한편, 체인간 송금을 위해서 필요한 정보들은 아래와 같다.
· from user : 송금을 하는 사용자
· origin : 송금 요청한 서비스 또는 리프 체인
· to user : 송금을 받는 사용자
· destination : 송금을 받는 서비스 또는 리프 체인
· value : 송금 금액(베이스 코인)
· eTxHash : 송금 트랜잭션 해시(transaction hash)
· message : 송금 메시지
· eSignature : 데이터를 전달을 요청한 리프 체인의 서명
여기서, 리프 체인의 서명은 from user, origin, to user, destination, value, eTxHash, message를 조합해서 서명한 값을 포함할 수 있다.
도 15는 본 발명의 일실시예에 있어서, 데이터 인증 방법의 제1 예를 도시한 흐름도이다. 본 실시예에 따른 데이터 인증 방법은 블록체인 네트워크의 노드를 구현하는 컴퓨터 장치(200)에 의해 수행될 수 있다. 예를 들어, 컴퓨터 장치(200)의 프로세서(220)는 메모리(210)가 포함하는 운영체제의 코드나 적어도 하나의 프로그램의 코드에 따른 제어 명령(instruction)을 실행하도록 구현될 수 있다. 여기서, 프로세서(220)는 컴퓨터 장치(200)에 저장된 코드가 제공하는 제어 명령에 따라 컴퓨터 장치(200)가 도 15의 방법이 포함하는 단계들(1510 내지 1540)을 수행하도록 컴퓨터 장치(200)를 제어할 수 있다.
단계(1510)에서 컴퓨터 장치(200)는 블록체인 네트워크의 체인을 대표하는 프라이빗 키를 블록체인 네트워크에서 합의(consensus)에 참여하는 적어도 하나의 다른 노드와 공유할 수 있다. 이때, 노드는 블록체인 네트워크에서의 합의를 이루도록 기설정된 복수의 노드들 중 하나일 수 있으며, 적어도 하나의 다른 노드 역시 블록체인 네트워크에서의 합의를 이루도록 기설정된 복수의 노드들에 포함될 수 있다.
본 실시예에 따른 데이터 인증 방법은 앞서 설명한 두 번째 방법에서 체인을 대표하는 하나의 프라이빗 키를 해당 체인의 C-노드들이 공유하고, 이를 체인 인증에 활용하는 과정을 설명한다. 다시 말해, 하나의 노드를 구현하는 컴퓨터 장치(200)는 컴퓨터 장치(200)에 의해 구현되는 노드가 참여하는 블록체인 네트워크의 체인을 대표하는 프라이빗 키를 적어도 하나의 다른 노드와 공유할 수 있다.
단계(1520)에서 컴퓨터 장치(200)는 프라이빗 키를 이용하여 생성되는 퍼블릭 키를 이용하여 블록체인 네트워크의 퍼블릭 주소를 생성할 수 있다. 이미 설명한 바와 같이, 퍼블릭 주소는 프라이빗 키를 통해 서명된 데이터가 해당 블록체인 네트워크로부터 발송된 것임을 검증하기 위해 제공될 수 있다.
일실시예로, 블록체인 네트워크는 복수의 리프 체인들간의 데이터 전송을 관리하는 루트 체인을 포함할 수 있다. 이 경우, 컴퓨터 장치(200)는 생성된 퍼블릭 주소를 복수의 리프 체인들 각각의 제네시스(genesis) 블록에 기록할 수 있다. 이때, 서명된 데이터를 전송받은 리프 체인에서 서명된 데이터와 리프 체인의 제네시스 블록에 기록된 퍼블릭 주소를 비교하여 서명된 데이터가 루트 체인에서 발송된 것임을 검증할 수 있다.
다른 실시예로, 블록체인 네트워크는 루트 체인에 의해 데이터 전송이 관리되는 복수의 리프 체인들 중 제1 리프 체인을 포함할 수 있다. 이 경우, 컴퓨터 장치(200)는 생성된 퍼블릭 주소를, 루트 체인에 제1 리프 체인과 연관하여 설치된 리프 체인 컨트랙트에 등록할 수 있다. 이때, 루트 체인에서 서명된 데이터와 해당 리프 체인 컨트랙트에 등록된 퍼블릭 주소를 비교하여 서명된 데이터가 제1 리프 체인에서 발송된 것임을 검증할 수 있다.
단계(1530)에서 컴퓨터 장치(200)는 블록체인 네트워크에서 다른 블록체인 네트워크로 전달하고자 하는 데이터를 블록체인 네트워크에 설치된 컨트랙트를 통해 프라이빗 키로 서명할 수 있다. 이때, 서명된 데이터가 기록된 블록이 블록체인 네트워크의 체인에 추가될 수 있다.
단계(1540)에서 컴퓨터 장치(200)는 서명된 데이터를 컨트랙트를 통해 다른 블록체인 네트워크로 전달할 수 있다. 이때, 서명된 데이터와 퍼블릭 주소간의 비교를 통해 서명된 데이터가 블록체인 네트워크를 통해 발송된 것임이 검증될 수 있다.
도 16은 본 발명의 일실시예에 있어서, 데이터 인증 방법의 제2 예를 도시한 흐름도이다. 본 실시예에 따른 데이터 인증 방법은 블록체인 네트워크의 노드를 구현하는 컴퓨터 장치(200)에 의해 수행될 수 있다. 예를 들어, 컴퓨터 장치(200)의 프로세서(220)는 메모리(210)가 포함하는 운영체제의 코드나 적어도 하나의 프로그램의 코드에 따른 제어 명령(instruction)을 실행하도록 구현될 수 있다. 여기서, 프로세서(220)는 컴퓨터 장치(200)에 저장된 코드가 제공하는 제어 명령에 따라 컴퓨터 장치(200)가 도 16의 방법이 포함하는 단계들(1610 내지 1630)을 수행하도록 컴퓨터 장치(200)를 제어할 수 있다.
단계(1610)에서 컴퓨터 장치(200)는 노드의 프라이빗 키를 이용하여 노드의 퍼블릭 주소를 생성할 수 있다. 노드의 프라이빗 키는 노드가 블록체인 네트워크에서 합의를 위해 갖고 있는 고유의 프라이빗 키일 수 있다.
단계(1620)에서 컴퓨터 장치(200)는 블록체인 네트워크에서 다른 블록체인 네트워크로 전달하고자 하는 데이터를 노드의 프라이빗 키를 이용하여 서명할 수 있다. 이때, 서명된 데이터가 기록된 블록이 블록체인 네트워크의 체인에 추가될 수 있다.
단계(1630)에서 컴퓨터 장치(200)는 서명된 데이터를 다른 블록체인 네트워크로 전달할 수 있다. 이때, 상기 퍼블릭 주소를 이용하여 상기 서명된 데이터가 상기 블록체인 네트워크를 통해 발송된 것임이 검증될 수 있다.
일실시예에서, 블록체인 네트워크는 복수의 리프 체인들간의 데이터 전송을 관리하는 루트 체인을 포함할 수 있다. 이때, 블록체인 네트워크에서 합의(consensus)를 이루도록 기설정된 복수의 노드들(본 실시예에 컴퓨터 장치(200)가 구현하는 노드를 포함하는 복수의 노드들) 각각에서 생성된 퍼블릭 주소가 복수의 리프 체인들 각각에 저장될 수 있다. 이 경우, 서명된 데이터를 전송받은 제1 리프 체인에서 서명된 데이터와 제1 리프 체인에 저장된 복수의 노드들 각각의 퍼블릭 주소를 비교하여 서명된 데이터가 루트 체인에서 발송된 것임을 검증할 수 있다.
다른 실시예에서, 블록체인 네트워크는 루트 체인에 의해 데이터 전송이 관리되는 복수의 리프 체인들 중 제1 리프 체인을 포함할 수 있다. 이때, 블록체인 네트워크에서 합의를 이루도록 기설정된 복수의 노드들(본 실시예에 컴퓨터 장치(200)가 구현하는 노드를 포함하는 복수의 노드들) 각각에서 생성된 퍼블릭 주소가, 루트 체인에 제1 리프 체인과 연관하여 설치된 리프 체인 컨트랙트에 등록될 수 있다. 이 경우, 루트 체인에서 서명된 데이터와 리프 체인 컨트랙트에 등록된 퍼블릭 주소를 비교하여 서명된 데이터가 제1 리프 체인에서 발송된 것임을 검증할 수 있다.
또 다른 실시예에서, 블록체인 네트워크는 복수의 리프 체인들간의 데이터 전송을 관리하는 루트 체인을 포함할 수 있다. 이때, 블록체인 네트워크에서 합의를 이루도록 기설정된 복수의 노드들(본 실시예에 컴퓨터 장치(200)가 구현하는 노드를 포함하는 복수의 노드들) 각각에서 생성된 퍼블릭 주소들의 조합으로 생성되는 대표 퍼블릭 주소가, 복수의 리프 체인들 각각에 저장될 수 있다. 이 경우, 서명된 데이터를 전송받은 제1 리프 체인에서 서명된 데이터와 제1 리프 체인에 저장된 대표 퍼블릭 주소를 비교하여 서명된 데이터가 루트 체인에서 발송된 것임을 검증할 수 있다.
또 다른 실시예에서, 블록체인 네트워크는 루트 체인에 의해 데이터 전송이 관리되는 복수의 리프 체인들 중 제1 리프 체인을 포함할 수 있다. 이때, 블록체인 네트워크에서 합의를 이루도록 기설정된 복수의 노드들(본 실시예에 컴퓨터 장치(200)가 구현하는 노드를 포함하는 복수의 노드들) 각각에서 생성된 퍼블릭 주소의 조합으로 생성되는 대표 퍼블릭 주소가, 루트 체인에 제1 리프 체인과 연관하여 설치된 리프 체인 컨트랙트에 등록될 수 있다. 이 경우, 루트 체인에서 서명된 데이터와 리프 체인 컨트랙트에 등록된 대표 퍼블릭 주소를 비교하여 서명된 데이터가 제1 리프 체인에서 발송된 것임을 검증할 수 있다.
도 17은 본 발명의 일실시예에 있어서, 데이터 인증 방법의 제3 예를 도시한 흐름도이다. 본 실시예에 따른 데이터 인증 방법은 블록체인 네트워크의 컨트랙트를 통해 동작하는 컴퓨터 장치(200)에 의해 수행될 수 있다. 예를 들어, 컴퓨터 장치(200)의 프로세서(220)는 메모리(210)가 포함하는 운영체제의 코드나 적어도 하나의 프로그램의 코드에 따른 제어 명령(instruction)을 실행하도록 구현될 수 있다. 여기서, 프로세서(220)는 컴퓨터 장치(200)에 저장된 코드가 제공하는 제어 명령에 따라 컴퓨터 장치(200)가 도 17의 방법이 포함하는 단계들(1710 내지 1760)을 수행하도록 컴퓨터 장치(200)를 제어할 수 있다. 여기서, 적어도 하나의 프로그램 코드는 적어도 블록체인 네트워크의 컨트랙트에 따른 코드를 포함할 수 있다.
단계(1710)에서 컴퓨터 장치(200)는 암호화된 프라이빗 키와 프라이빗 키로 생성되는 퍼블릭 키를 파라미터로 수신할 수 있다.
단계(1720)에서 컴퓨터 장치(200)는 수신한 퍼블릭 키로 컨트랙트 주소를 생성할 수 있다.
단계(1730)에서 컴퓨터 장치(200)는 암호화된 프라이빗 키와 컨트랙트 주소를 데이터베이스에 저장할 수 있다.
단계(1740)에서 컴퓨터 장치(200)는 서명할 데이터와 암호화된 프라이빗 키를 복호화하기 위한 패스워드를 파라미터로 포함하는 서명 요청을 수신할 수 있다. 여기서 패스워드는 블록체인 네트워크의 블록이나 로그 중 어디에도 저장되지 않는 시큐어 타입으로 정의될 수 있다.
단계(1750)에서 컴퓨터 장치(200)는 서명 요청에 응답하여 패스워드를 통해 암호화된 프라이빗 키를 복호화하고, 복호화된 프라이빗 키로 데이터를 서명하여 서명된 데이터를 생성할 수 있다. 이때, 서명된 데이터가 기록된 블록이 상기 블록체인 네트워크의 체인에 추가될 수 있다.
단계(1760)에서 컴퓨터 장치(200)는 생성된 서명된 데이터를 반환할 수 있다. 이때, 서명된 데이터는 데이터의 서명을 요청한 노드로 반환될 수 있다.
일실시예에서 블록체인 네트워크는 복수의 리프 체인들간의 데이터 전송을 관리하는 루트 체인을 포함할 수 있다. 이때, 컴퓨터 장치(200)는 컨트랙트 주소를 복수의 리프 체인들 각각의 제네시스 블록에 기록할 수 있다. 이 경우, 서명된 데이터를 수신하는 제1 리프 체인에서 서명된 데이터와 제1 리프 체인의 제네시스 블록에 기록된 컨트랙트 주소를 비교하여 서명된 데이터가 루트 체인에서 발송된 것임을 검증할 수 있다.
다른 실시예에서 블록체인 네트워크는 루트 체인에 의해 데이터 전송이 관리되는 복수의 리프 체인들 중 제1 리프 체인을 포함할 수 있다. 이때, 컴퓨터 장치(200)는 컨트랙트 주소가 루트 체인의 데이터베이스에 저장되도록 컨트랙트 주소를 루트 체인으로 제공할 수 있다. 이 경우, 루트 체인에서 서명된 데이터와 루트 체인의 데이터베이스에 저장된 컨트랙트 주소를 비교하여 서명된 데이터가 제1 리프 체인에서 발송된 것임을 검증할 수 있다.
도 18은 본 발명의 일실시예에 있어서, 데이터 인증 방법의 제4 예를 도시한 흐름도이다. 본 실시예에 따른 데이터 인증 방법은 블록체인 네트워크의 노드를 구현하는 컴퓨터 장치(200)에 의해 수행될 수 있다. 예를 들어, 컴퓨터 장치(200)의 프로세서(220)는 메모리(210)가 포함하는 운영체제의 코드나 적어도 하나의 프로그램의 코드에 따른 제어 명령(instruction)을 실행하도록 구현될 수 있다. 여기서, 프로세서(220)는 컴퓨터 장치(200)에 저장된 코드가 제공하는 제어 명령에 따라 컴퓨터 장치(200)가 도 18의 방법이 포함하는 단계들(1810 내지 1860)을 수행하도록 컴퓨터 장치(200)를 제어할 수 있다.
단계(1810)에서 컴퓨터 장치(200)는 블록체인 네트워크의 노드의 프라이빗 키를 암호화하여 저장할 수 있다. 여기서, 노드는 블록체인 네트워크에서 최초 생성되는 노드일 수 있으며, 이러한 노드에서 블록체인 네트워크의 시스템 컨트랙트를 설치하는 과정에서 서명 가능 컨트랙트를 자동 설치할 수 있다. 이 과정에 노드의 프라이빗 키가 서명 가능 컨트랙트로 전달될 수 있다. 이때, 서명 가능 컨트랙트는 설치 과정에서 전달되는 노드의 프라이빗 키를 암호화하여 저장할 수 있다.
단계(1820)에서 컴퓨터 장치(200)는 암호화된 프라이빗 키를 복호화하기 위한 패스워드를 노드의 퍼블릭 키로 암호화하여 저장할 수 있다. 패스워드는 컴퓨터 장치(200)가 프라이빗 키를 암호화하는 과정에서 암호화된 프라이빗 키를 복호화할 수 있도록 생성될 수 있다. 일례로, 대칭키로 프라이빗 키를 암호화한 경우, 대칭키나 대칭키를 얻기 위한 값이 패스워드로 생성될 수 있다.
단계(1830)에서 컴퓨터 장치(200)는 노드의 퍼블릭 키로 암호화된 패스워드를 노드로 반환할 수 있다. 이 경우, 노드는 암호화된 패스워드를 얻을 수 있다. 이때, 암호화된 패스워드는 노드의 퍼블릭 키로 암호화되었기 때문에 노드의 프라이빗 키로 암호화된 패스워드를 복호화하여 패스워드를 얻을 수 있게 된다. 한편, 블록체인 네트워크의 다른 노드는 암호화된 패스워드를 반환받은 노드를 찾아 해당 노드로 다른 노드의 퍼블릭 키를 전송하고, 해당 노드로부터 다른 노드의 퍼블릭 키로 암호화된 패스워드를 수신하여 다른 노드에 저장할 수 있다. 이러한 과정을 통해 블록체인 네트워크의 다른 노드들도 암호화된 프라이빗 키를 복호화하기 위한 패스워드를 얻을 수 있게 된다. 반면, 프라이빗 키 자체는 암호화된 상태로 저장되기 때문에 노출되지 않을 수 있다. 한편, 패스워드는 블록체인 네트워크의 블록이나 로그 중 어디에도 저장되지 않는 시큐어 타입으로 정의될 수 있다.
단계(1840)에서 컴퓨터 장치(200)는 블록체인 네트워크의 임의의 노드로부터 패스워드 및 프라이빗 키로 서명하기 위한 데이터를 파라미터로서 포함하는 서명 요청을 수신할 수 있다. 임의의 노드는 컴퓨터 장치(200)로부터 암호화된 패스워드를 반환받은 노드이거나 또는 해당 노드로부터 패스워드를 전달받은 다른 노드일 수 있다.
단계(1850)에서 컴퓨터 장치(200)는 서명 요청에 응답하여, 패스워드를 통해 암호화된 프라이빗 키를 복호화하고, 복호화된 프라이빗 키로 데이터를 서명하여 서명된 데이터를 생성할 수 있다.
단계(1860)에서 컴퓨터 장치(200)는 서명된 데이터를 반환할 수 있다. 이때, 서명된 데이터는 데이터의 서명을 요청한 노드로 반환될 수 있다.
일실시예에서, 블록체인 네트워크는 복수의 리프 체인들간의 데이터 전송을 관리하는 루트 체인을 포함할 수 있다. 이때, 컴퓨터 장치(200)는 컨트랙트 주소를 복수의 리프 체인들 각각의 제네시스 블록에 기록할 수 있다. 이 경우, 서명된 데이터를 수신하는 제1 리프 체인에서 서명된 데이터와 제1 리프 체인의 제네시스 블록에 기록된 컨트랙트 주소를 비교하여 서명된 데이터가 루트 체인에서 발송된 것임을 검증할 수 있다.
다른 실시예에서, 블록체인 네트워크는 루트 체인에 의해 데이터 전송이 관리되는 복수의 리프 체인들 중 제1 리프 체인을 포함할 수 있다. 이때, 컴퓨터 장치(200)는 컨트랙트 주소가 루트 체인의 데이터베이스에 저장되도록 컨트랙트 주소를 루트 체인으로 제공할 수 있다. 이 경우, 루트 체인에서 서명된 데이터와 루트 체인의 데이터베이스에 저장된 컨트랙트 주소를 비교하여 서명된 데이터가 제1 리프 체인에서 발송된 것임을 검증할 수 있다. 루트 체인은 이미 설명한 바와 같이 절대 신뢰 시스템으로 간주될 수 있다.
이상에서와 같이, 본 발명의 실시예들에 따르면, 루트 체인을 기반으로 리프 체인을 추가하는 방식으로 스케일 아웃이 가능한 블록체인에서 생성되는 데이터를 인증하는 데이터 인증 방법 및 시스템을 제공할 수 있다.
이상에서 설명된 시스템 또는 장치는 하드웨어 구성요소, 소프트웨어 구성요소 또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 장치 및 구성요소는, 예를 들어, 프로세서, 콘트롤러, ALU(arithmetic logic unit), 디지털 신호 프로세서(digital signal processor), 마이크로컴퓨터, FPGA(field programmable gate array), PLU(programmable logic unit), 마이크로프로세서, 또는 명령(instruction)을 실행하고 응답할 수 있는 다른 어떠한 장치와 같이, 하나 이상의 범용 컴퓨터 또는 특수 목적 컴퓨터를 이용하여 구현될 수 있다. 처리 장치는 운영 체제(OS) 및 상기 운영 체제 상에서 수행되는 하나 이상의 소프트웨어 어플리케이션을 수행할 수 있다. 또한, 처리 장치는 소프트웨어의 실행에 응답하여, 데이터를 접근, 저장, 조작, 처리 및 생성할 수도 있다. 이해의 편의를 위하여, 처리 장치는 하나가 사용되는 것으로 설명된 경우도 있지만, 해당 기술분야에서 통상의 지식을 가진 자는, 처리 장치가 복수 개의 처리 요소(processing element) 및/또는 복수 유형의 처리 요소를 포함할 수 있음을 알 수 있다. 예를 들어, 처리 장치는 복수 개의 프로세서 또는 하나의 프로세서 및 하나의 콘트롤러를 포함할 수 있다. 또한, 병렬 프로세서(parallel processor)와 같은, 다른 처리 구성(processing configuration)도 가능하다.
소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다. 소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치에 구체화(embody)될 수 있다. 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록매체에 저장될 수 있다.
실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 통상의 기술자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 이러한 기록매체는 단일 또는 수개 하드웨어가 결합된 형태의 다양한 기록수단 또는 저장수단일 수 있으며, 어떤 컴퓨터 시스템에 직접 접속되는 매체에 한정되지 않고, 네트워크 상에 분산 존재하는 것일 수도 있다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다.
이상과 같이 실시예들이 비록 한정된 실시예와 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기의 기재로부터 다양한 수정 및 변형이 가능하다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.
그러므로, 다른 구현들, 다른 실시예들 및 청구범위와 균등한 것들도 후술하는 청구범위의 범위에 속한다.

Claims (20)

  1. 블록체인 네트워크에 참여하는 컴퓨터 장치로 구현되는 노드의 데이터 인증 방법에 있어서,
    상기 컴퓨터 장치가 포함하는 적어도 하나의 프로세서에 의해, 상기 블록체인 네트워크의 체인을 대표하는 프라이빗 키(private key)를 상기 블록체인 네트워크에 참여하는 적어도 하나의 다른 노드와 공유하는 단계;
    상기 적어도 하나의 프로세서에 의해, 상기 프라이빗 키를 이용하여 상기 블록체인 네트워크의 퍼블릭 주소를 생성하는 단계;
    상기 적어도 하나의 프로세서에 의해, 상기 블록체인 네트워크에서 다른 블록체인 네트워크로 전달하고자 하는 데이터를 상기 블록체인 네트워크에 설치된 컨트랙트를 통해 상기 프라이빗 키로 서명하는 단계; 및
    상기 적어도 하나의 프로세서에 의해, 상기 서명된 데이터를 상기 컨트랙트를 통해 다른 블록체인 네트워크로 전달하는 단계
    를 포함하고,
    상기 서명된 데이터와 상기 퍼블릭 주소간의 비교를 통해 상기 서명된 데이터가 상기 블록체인 네트워크를 통해 발송된 것임이 검증되는 것을 특징으로 하는 데이터 인증 방법.
  2. 제1항에 있어서,
    상기 블록체인 네트워크는 복수의 리프 체인들간의 데이터 전송을 관리하는 루트 체인을 포함하고,
    상기 데이터 인증 방법은,
    상기 적어도 하나의 프로세서에 의해, 상기 생성된 퍼블릭 주소를 상기 복수의 리프 체인들 각각의 제네시스(genesis) 블록에 기록하는 단계
    를 더 포함하는 것을 특징으로 하는 데이터 인증 방법.
  3. 제2항에 있어서,
    상기 서명된 데이터를 전송받은 리프 체인에서 상기 서명된 데이터와 상기 리프 체인의 제네시스 블록에 기록된 퍼블릭 주소를 비교하여 상기 서명된 데이터가 상기 루트 체인에서 발송된 것임을 검증하는 것을 특징으로 하는 데이터 인증 방법.
  4. 제1항에 있어서,
    상기 블록체인 네트워크는 루트 체인에 의해 데이터 전송이 관리되는 복수의 리프 체인들 중 제1 리프 체인을 포함하고,
    상기 데이터 인증 방법은,
    상기 적어도 하나의 프로세서에 의해, 상기 생성된 퍼블릭 주소를, 상기 루트 체인에 상기 제1 리프 체인과 연관하여 설치된 리프 체인 컨트랙트에 등록하는 단계
    를 더 포함하는 것을 특징으로 하는 데이터 인증 방법.
  5. 제4항에 있어서,
    상기 루트 체인에서 상기 서명된 데이터와 상기 리프 체인 컨트랙트에 등록된 퍼블릭 주소를 비교하여 상기 서명된 데이터가 상기 제1 리프 체인에서 발송된 것임을 검증하는 것을 특징으로 하는 데이터 인증 방법.
  6. 제1항에 있어서,
    상기 노드는 상기 블록체인 네트워크에서의 합의(consensus)를 이루도록 기설정된 복수의 노드들 중 하나인 것을 특징으로 하는 데이터 인증 방법.
  7. 제1항에 있어서,
    상기 서명된 데이터가 기록된 블록이 상기 블록체인 네트워크의 체인에 추가되는 것을 특징으로 하는 데이터 인증 방법.
  8. 블록체인 네트워크에 참여하는 컴퓨터 장치로 구현되는 노드의 데이터 인증 방법에 있어서,
    상기 컴퓨터 장치가 포함하는 적어도 하나의 프로세서에 의해, 상기 노드의 프라이빗 키를 이용하여 상기 노드의 퍼블릭 주소를 생성하는 단계;
    상기 적어도 하나의 프로세서에 의해, 상기 블록체인 네트워크에서 다른 블록체인 네트워크로 전달하고자 하는 데이터를 상기 노드의 프라이빗 키를 이용하여 서명하는 단계; 및
    상기 적어도 하나의 프로세서에 의해, 상기 서명된 데이터를 상기 다른 블록체인 네트워크로 전달하는 단계
    를 포함하고,
    상기 퍼블릭 주소를 이용하여 상기 서명된 데이터가 상기 블록체인 네트워크를 통해 발송된 것임이 검증되는 것을 특징으로 하는 데이터 인증 방법.
  9. 제8항에 있어서,
    상기 블록체인 네트워크는 복수의 리프 체인들간의 데이터 전송을 관리하는 루트 체인을 포함하고,
    상기 블록체인 네트워크에서의 상기 노드를 포함하여 합의(consensus)를 이루도록 기설정된 복수의 노드들 각각에서 생성된 퍼블릭 주소가 상기 복수의 리프 체인들 각각에 저장되는 것을 특징으로 하는 데이터 인증 방법.
  10. 제9항에 있어서,
    상기 서명된 데이터를 전송받은 제1 리프 체인에서 상기 서명된 데이터와 상기 제1 리프 체인에 저장된 상기 복수의 노드들 각각의 퍼블릭 주소를 비교하여 상기 서명된 데이터가 상기 루트 체인에서 발송된 것임을 검증하는 것을 특징으로 하는 데이터 인증 방법.
  11. 제8항에 있어서,
    상기 블록체인 네트워크는 루트 체인에 의해 데이터 전송이 관리되는 복수의 리프 체인들 중 제1 리프 체인을 포함하고,
    상기 블록체인 네트워크에서의 상기 노드를 포함하여 합의(consensus)를 이루도록 기설정된 복수의 노드들 각각에서 생성된 퍼블릭 주소가, 상기 루트 체인에 상기 제1 리프 체인과 연관하여 설치된 리프 체인 컨트랙트에 등록되는 것을 특징으로 하는 데이터 인증 방법.
  12. 제11항에 있어서,
    상기 루트 체인에서 상기 서명된 데이터와 상기 리프 체인 컨트랙트에 등록된 퍼블릭 주소를 비교하여 상기 서명된 데이터가 상기 제1 리프 체인에서 발송된 것임을 검증하는 것을 특징으로 하는 데이터 인증 방법.
  13. 제8항에 있어서,
    상기 블록체인 네트워크는 복수의 리프 체인들간의 데이터 전송을 관리하는 루트 체인을 포함하고,
    상기 블록체인 네트워크에서의 상기 노드를 포함하여 합의(consensus)를 이루도록 기설정된 복수의 노드들 각각에서 생성된 퍼블릭 주소들의 조합으로 생성되는 대표 퍼블릭 주소(Common Public Address)가, 상기 복수의 리프 체인들 각각에 저장되는 것을 특징으로 하는 데이터 인증 방법.
  14. 제13항에 있어서,
    상기 서명된 데이터를 전송받은 제1 리프 체인에서 상기 서명된 데이터와 상기 제1 리프 체인에 저장된 상기 대표 퍼블릭 주소를 비교하여 상기 서명된 데이터가 상기 루트 체인에서 발송된 것임을 검증하는 것을 특징으로 하는 데이터 인증 방법.
  15. 제8항에 있어서,
    상기 블록체인 네트워크는 루트 체인에 의해 데이터 전송이 관리되는 복수의 리프 체인들 중 제1 리프 체인을 포함하고,
    상기 블록체인 네트워크에서의 상기 노드를 포함하여 합의(consensus)를 이루도록 기설정된 복수의 노드들 각각에서 생성된 퍼블릭 주소의 조합으로 생성되는 대표 퍼블릭 주소(Common Public Address)가, 상기 루트 체인에 상기 제1 리프 체인과 연관하여 설치된 리프 체인 컨트랙트에 등록되는 것을 특징으로 하는 데이터 인증 방법.
  16. 제15항에 있어서,
    상기 루트 체인에서 상기 서명된 데이터와 상기 리프 체인 컨트랙트에 등록된 상기 대표 퍼블릭 주소를 비교하여 상기 서명된 데이터가 상기 제1 리프 체인에서 발송된 것임을 검증하는 것을 특징으로 하는 데이터 인증 방법.
  17. 제8항에 있어서,
    상기 서명된 데이터가 기록된 블록이 상기 블록체인 네트워크의 체인에 추가되는 것을 특징으로 하는 데이터 인증 방법.
  18. 컴퓨터 장치와 결합되어 제1항 내지 제17항 중 어느 한 항의 방법을 컴퓨터 장치에 실행시키기 위해 컴퓨터 판독 가능한 기록매체에 저장된 컴퓨터 프로그램.
  19. 제1항 내지 제17항 중 어느 한 항의 방법을 컴퓨터 장치에 실행시키기 위한 컴퓨터 프로그램이 기록되어 있는 것을 특징으로 하는 컴퓨터 판독 가능한 기록매체.
  20. 블록체인 네트워크의 노드를 구현하는 컴퓨터 장치에 있어서,
    상기 컴퓨터 장치에서 판독 가능한 명령을 실행하도록 구현되는 적어도 하나의 프로세서
    를 포함하고,
    상기 적어도 하나의 프로세서에 의해,
    상기 블록체인 네트워크의 체인을 대표하는 프라이빗 키(private key)를 상기 블록체인 네트워크에 참여하는 적어도 하나의 다른 노드와 공유하고,
    상기 프라이빗 키를 이용하여 상기 블록체인 네트워크의 퍼블릭 주소를 생성하고,
    상기 블록체인 네트워크에서 다른 블록체인 네트워크로 전달하고자 하는 데이터를 상기 블록체인 네트워크에 설치된 컨트랙트를 통해 상기 프라이빗 키로 서명하고,
    상기 서명된 데이터를 상기 컨트랙트를 통해 다른 블록체인 네트워크로 전달하고,
    상기 서명된 데이터와 상기 퍼블릭 주소간의 비교를 통해 상기 서명된 데이터가 상기 블록체인 네트워크를 통해 발송된 것임이 검증되는 것
    을 특징으로 하는 컴퓨터 장치.
PCT/KR2019/003001 2019-03-15 2019-03-15 블록체인에서 생성된 데이터를 인증하는 방법 및 시스템 WO2020189800A1 (ko)

Priority Applications (4)

Application Number Priority Date Filing Date Title
KR1020247001901A KR20240011890A (ko) 2019-03-15 2019-03-15 블록체인에서 생성된 데이터를 인증하는 방법 및 시스템
PCT/KR2019/003001 WO2020189800A1 (ko) 2019-03-15 2019-03-15 블록체인에서 생성된 데이터를 인증하는 방법 및 시스템
JP2021555454A JP7304963B2 (ja) 2019-03-15 2019-03-15 プログラム、データ認証方法、およびコンピュータ装置
KR1020217022073A KR102627868B1 (ko) 2019-03-15 2019-03-15 블록체인에서 생성된 데이터를 인증하는 방법 및 시스템

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/KR2019/003001 WO2020189800A1 (ko) 2019-03-15 2019-03-15 블록체인에서 생성된 데이터를 인증하는 방법 및 시스템

Publications (1)

Publication Number Publication Date
WO2020189800A1 true WO2020189800A1 (ko) 2020-09-24

Family

ID=72521014

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2019/003001 WO2020189800A1 (ko) 2019-03-15 2019-03-15 블록체인에서 생성된 데이터를 인증하는 방법 및 시스템

Country Status (3)

Country Link
JP (1) JP7304963B2 (ko)
KR (2) KR102627868B1 (ko)
WO (1) WO2020189800A1 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112865962A (zh) * 2021-01-07 2021-05-28 杭州链城数字科技有限公司 一种基于区块链的分布式标识认证方法和装置、电子设备
WO2022193068A1 (zh) * 2021-03-15 2022-09-22 深圳市艾比森光电股份有限公司 一种内容发布方法和led显示屏
CN115118435A (zh) * 2022-06-29 2022-09-27 河北工业大学 基于双层链的隐私数据保护和授权框架

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102532162B1 (ko) * 2022-10-27 2023-05-12 주식회사 풀스택 서명 기능 없는 블록체인 지갑의 소유권 인증 방법 및 이를 이용한 시스템

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050114666A1 (en) * 1999-08-06 2005-05-26 Sudia Frank W. Blocked tree authorization and status systems
US9380024B2 (en) * 2010-03-05 2016-06-28 Interdigital Patent Holdings, Inc. Method and apparatus for providing security to devices

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000124887A (ja) * 1998-10-14 2000-04-28 Fuji Xerox Co Ltd グループ単位の暗号化・復号方法および署名方法ならびに装置
JP6636058B2 (ja) * 2015-07-02 2020-01-29 ナスダック， インコーポレイテッドＮａｓｄａｑ， Ｉｎｃ． 分散トランザクションデータベースにおける出所保証のシステムおよび方法
KR101712119B1 (ko) * 2015-07-09 2017-03-03 국민대학교산학협력단 비트코인의 거래 알림 장치 및 거래 알림 방법
US10447478B2 (en) * 2016-06-06 2019-10-15 Microsoft Technology Licensing, Llc Cryptographic applications for a blockchain system
JP2020517135A (ja) * 2017-04-11 2020-06-11 エヌチェーン ホールディングス リミテッドＮｃｈａｉｎ Ｈｏｌｄｉｎｇｓ Ｌｉｍｉｔｅｄ ブロックチェーン間のセキュアな転送
KR101989450B1 (ko) * 2017-06-23 2019-09-30 홍석현 블록체인 기반의 공개 분산 데이터베이스에서 데이터에 대한 보안을 유지하는 방법 및 이를 이용한 블록체인 관리 서버
WO2019045589A1 (en) * 2017-08-31 2019-03-07 Siemens Aktiengesellschaft REAL-TIME CONTROL NETWORK BASED ON BLOCK CHAIN, REAL-TIME CONTROL SYSTEM, AND REAL-TIME CONTROL METHOD
CN108712257B (zh) * 2018-04-03 2020-04-17 阿里巴巴集团控股有限公司 跨区块链的认证方法及装置、电子设备

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050114666A1 (en) * 1999-08-06 2005-05-26 Sudia Frank W. Blocked tree authorization and status systems
US9380024B2 (en) * 2010-03-05 2016-06-28 Interdigital Patent Holdings, Inc. Method and apparatus for providing security to devices

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Core Ethereum Programming#2", 13 May 2018 (2018-05-13) *
"Plasma: An Innovative Framework to Scale Ethereum", YCEFFORT, 23 September 2018 (2018-09-23), XP055740019, Retrieved from the Internet <URL:https://www.yceffort.kr/2018/09/23/plasma-an-innovative-framework-to-scale-ethereum> [retrieved on 20191202] *
"What is a blockchain optimized for LINE and services?", THE BCHAIN, 8 November 2018 (2018-11-08), XP055740017, Retrieved from the Internet <URL:https://www.thebchain.co.kr/news/articleView.html?idxno=2361> [retrieved on 20191202] *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112865962A (zh) * 2021-01-07 2021-05-28 杭州链城数字科技有限公司 一种基于区块链的分布式标识认证方法和装置、电子设备
WO2022193068A1 (zh) * 2021-03-15 2022-09-22 深圳市艾比森光电股份有限公司 一种内容发布方法和led显示屏
CN115118435A (zh) * 2022-06-29 2022-09-27 河北工业大学 基于双层链的隐私数据保护和授权框架
CN115118435B (zh) * 2022-06-29 2024-03-22 河北工业大学 基于双层链的隐私数据保护和授权框架

Also Published As

Publication number Publication date
JP7304963B2 (ja) 2023-07-07
JP2022533301A (ja) 2022-07-22
KR102627868B1 (ko) 2024-01-23
KR20240011890A (ko) 2024-01-26
KR20210096288A (ko) 2021-08-04

Similar Documents

Publication Publication Date Title
WO2020189800A1 (ko) 블록체인에서 생성된 데이터를 인증하는 방법 및 시스템
WO2021071157A1 (en) Electronic device and method for managing blockchain address using the same
WO2020171538A1 (en) Electronic device and method for providing digital signature service of block chain using the same
WO2021010766A1 (ko) 블록 체인을 이용한 전자 인증 장치 및 그 방법
WO2017104899A1 (ko) 블록체인을 기반으로 하는 공인인증서 인증시스템 및 이를 이용한 인증방법
WO2018030707A1 (ko) 인증 시스템 및 방법과 이를 수행하기 위한 사용자 단말, 인증 서버 및 서비스 서버
WO2017022917A1 (ko) 블록체인을 기반으로 하는 공인인증서 발급시스템
WO2018008800A1 (ko) 블록체인을 기반으로 하는 공인인증서 인증시스템과 이를 이용한 블록체인을 기반으로 하는 공인인증서 인증방법
WO2020189926A1 (ko) 블록체인 네트워크를 이용하여 사용자의 아이덴티티를 관리하는 방법 및 서버, 그리고, 블록체인 네트워크 기반의 사용자 아이덴티티를 이용하여 사용자를 인증하는 방법 및 단말
WO2018151427A1 (ko) 스마트 컨트랙트 및 블록체인 데이터베이스를 사용하여 pki 기반의 인증을 통해 사용자의 로그인을 대행하는 방법 및 이를 이용한 서버
WO2017171165A1 (ko) 블록체인을 기반으로 하는 공인인증서 발급시스템과 이를 이용한 블록체인을 기반으로 하는 공인인증서 발급방법
WO2020235782A1 (ko) 분산 환경에서의 신원 인증 방법
WO2020189927A1 (ko) 블록체인 네트워크를 이용하여 사용자의 아이덴티티를 관리하는 방법 및 서버, 그리고, 블록체인 네트워크 기반의 사용자 아이덴티티를 이용하여 사용자를 인증하는 방법 및 단말
WO2018151425A1 (ko) Utxo 기반 프로토콜의 블록체인 데이터베이스를 사용하여 pki 기반의 인증을 통해 사용자의 로그인을 대행하는 방법 및 이를 이용한 서버
WO2017065389A1 (ko) 블록체인을 기반으로 하는 공인인증서 발급시스템과 이를 이용한 블록체인을 기반으로 하는 공인인증서 발급방법 및 블록체인을 기반으로 하는 공인인증서 인증시스템과 이를 이용한 블록체인을 기반으로 하는 공인인증서 인증방법
WO2020022599A1 (ko) 블록체인 네트워크 상에서 그룹키 기반의 이중 서명 트랜잭션 구조를 구성하는 노드 그룹 관리 장치 및 컴퓨팅 장치
WO2020022760A1 (ko) 시스템에 포함되는 노드들에 대하여 그룹을 운영하는 분산 네트워크 시스템
WO2020130331A1 (ko) 블록체인에서 노드들간 블록 및 전자 문서를 공유 및 검증하는 방법
WO2018124718A1 (ko) 블록체인 내의 블록별로 밸런스 데이터베이스를 관리하여 통합 포인트 서비스를 제공하는 방법 및 이를 이용한 지원 서버
WO2020209664A2 (ko) 디지털 컨텐츠의 이용 권리 증서를 유통시키는 방법, 및 상기 방법을 실행하기 위하여 매체에 저장된 컴퓨터 프로그램
WO2020141782A1 (ko) 블록체인 네트워크를 이용하여 사용자의 아이덴티티를 관리하는 방법 및 서버, 그리고, 블록체인 네트워크 기반의 사용자 아이덴티티를 이용하여 사용자를 인증하는 방법 및 단말
WO2018151426A1 (ko) Utxo 기반 프로토콜에서 머클 트리 구조를 사용하여 pki 기반의 인증을 통해 사용자의 로그인을 대행하는 방법 및 이를 이용한 서버
WO2022107949A1 (ko) 디지털 id 보관 및 연계 서비스 모델
WO2020022700A1 (ko) 디지털 키를 처리 및 인증하는 보안 요소 및 그 동작 방법
WO2023090755A1 (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: 19920500

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20217022073

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2021555454

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19920500

Country of ref document: EP

Kind code of ref document: A1