WO2020189801A1 - Procédé et système d'authentification de données générées dans une chaîne de blocs à l'aide d'un contrat pouvant être signé - Google Patents

Procédé et système d'authentification de données générées dans une chaîne de blocs à l'aide d'un contrat pouvant être signé Download PDF

Info

Publication number
WO2020189801A1
WO2020189801A1 PCT/KR2019/003002 KR2019003002W WO2020189801A1 WO 2020189801 A1 WO2020189801 A1 WO 2020189801A1 KR 2019003002 W KR2019003002 W KR 2019003002W WO 2020189801 A1 WO2020189801 A1 WO 2020189801A1
Authority
WO
WIPO (PCT)
Prior art keywords
chain
data
contract
leaf
private key
Prior art date
Application number
PCT/KR2019/003002
Other languages
English (en)
Korean (ko)
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 JP2021554654A priority Critical patent/JP7254954B2/ja
Priority to PCT/KR2019/003002 priority patent/WO2020189801A1/fr
Priority to KR1020217022071A priority patent/KR102572834B1/ko
Publication of WO2020189801A1 publication Critical patent/WO2020189801A1/fr

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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1087—Peer-to-peer [P2P] networks using cross-functional networking aspects
    • H04L67/1089—Hierarchical topologies
    • 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/083—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) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833—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) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • H04L9/0836—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) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key using tree structure or hierarchical structure
    • 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/085—Secret sharing or secret splitting, e.g. threshold schemes
    • 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/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • 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/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • 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/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 using a signable contract.
  • 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 computer device operating through a contract of a blockchain network wherein an encrypted private key and a public key generated as a private key are received as parameters by at least one processor included in the computer device.
  • the step of doing Generating, by the at least one processor, a contract address using the received public key; Storing the encrypted private key and the contract address in a database by the at least one processor; Receiving, by the at least one processor, a signature request including data to be signed and a password for decrypting the encrypted private key as parameters; Decrypting, by the at least one processor, the encrypted private key through the password in response to the signature request, and signing the data with the decrypted private key to generate signed data; And returning the generated signed data by the at least one processor.
  • the password may be defined as a secure type that is not stored in either block or log of the blockchain 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 contract address as the plurality of leaf chains. It may be characterized in that it further comprises the step of writing to each of the genesis block.
  • the signed data is sent from the root chain. It can be characterized by verifying that it is.
  • the blockchain network includes a first leaf chain among a plurality of leaf chains in which data transmission is managed by a root chain
  • the data authentication method includes, by the at least one processor, the contract It may further include providing the contract address to the root chain so that the address is stored in the database of 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.
  • the block in which the signed data is recorded may be added to the chain of the blockchain network.
  • a method for authenticating data of a computer device operating through a contract of a blockchain network comprising: encrypting and storing a private key of a node of the blockchain network by at least one processor included in the computer device; Encrypting, by the at least one processor, a password for decrypting the encrypted private key with the public key of the node and storing it; Returning, by the at least one processor, the password encrypted with the public key of the node to the node; Receiving, by the at least one processor, a signature request including data for signing with the password and the private key from any node of the blockchain network as parameters; Decrypting the encrypted private key through the password in response to the signing request by the at least one processor, and signing the data with the decrypted private key to generate signed data; And returning the signed data by the at least one processor.
  • a computer program stored on a computer-readable recording medium for executing the method on the computer device.
  • 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 operating through a contract of a blockchain network comprising at least one processor implemented to execute an instruction readable by the computer device, and an encrypted private key by the at least one processor And a public key generated as a private key as a parameter, a contract address is generated with the received public key, the encrypted private key and the contract address are stored in a database, and the data to be signed and the encrypted private key are decrypted Receives a signature request including a password to be used as a parameter, decrypts the encrypted private key using the password and signs the data with the decrypted private key to generate signed data, and the generated signed data It provides a computer device, characterized in that to return.
  • a computer device operating through a contract of a blockchain network comprising at least one processor implemented to execute an instruction readable by the computer device, and wherein the at least one processor allows the private node of the blockchain network
  • the key is encrypted and stored
  • the password for decrypting the encrypted private key is encrypted and stored with the public key of the node
  • the password encrypted with the public key of the node is returned to the node
  • the block chain network Receiving a signature request including the password and data for signing with the private key from a node as parameters, in response to the signing request, decrypts the encrypted private key through the password, and decrypts the data with the decrypted private key It provides a computer device, characterized in that for generating signed data by signing and returning the signed data.
  • 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. 6 is a flowchart illustrating an example of a process of adding a new service 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.
  • Each of the servers 150 and 160 is a computer device or a plurality of computers that communicates with a plurality of electronic devices 110, 120, 130, and 140 through a network 170 to provide commands, codes, files, contents, services, etc. It can be implemented with devices.
  • the server 150 serves as a plurality of electronic devices 110, 120, 130, and 140 connected through the network 170 (for example, video call service, financial service, payment service, social network service). , A messaging service, a search service, a mail service, a content providing service, and/or a question and answer service, etc.).
  • 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 input/output interface 240 may be a means for an interface with the input/output device 250.
  • the input device may include a device such as a microphone, keyboard, camera, or mouse
  • the output device may include a device such as a display and a speaker.
  • the input/output interface 240 may be a means for interfacing with a device in which input and output functions are integrated into one, such as a touch screen.
  • the input/output device 250 may be configured with the computer device 200 and one device.
  • 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.
  • 3 is a diagram showing an example of a general configuration of an expandable blockchain network according to an embodiment of the present invention.
  • 3 is a block chain network 300 including a root chain 310, a leaf chain A 320, a leaf chain B 330 and a relay 340 It shows an example of.
  • the root chain 310 and the leaf chains 320 and 330 may form a network in which a plurality of computer devices are connected, and the relay 340 may be implemented by at least one computer device.
  • 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 blockchain network 300 may be composed of one root chain 310, several leaf chains 320 and 330, and a relay 340 as shown in FIG. 4.
  • 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 leaf chain manager contract in the leaf chain, which is responsible for remittance of coins between chains or between contracts.
  • 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.
  • Leaf chain manager contract A 910 of leaf chain A 320 may receive remittance completion information, record the completion of the exchange transaction hash, and delete the request in the remittance request record (escrow). If the remittance is unsuccessful, the leaf chain manager contract A (910) can return the amount in the remittance request record (escrow) back to user a, and the total amount of money in DApp 1 (920) is increased again by the remittance amount before remittance You can delete the request from the request record (escrow).
  • 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.
  • the root chain must be able to manage the base coins of all chains. At this time, the management of the base coin may include remittance of the base coin between chains.
  • 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 private key representing one chain is shared with C-nodes, which are consensus nodes in the same chain, and used when chain authentication is required. I can do it.
  • each chain can maintain a private key shared by n (for example, n is 4 to 8) C-nodes for consensus.
  • a user or other contract can request the system for the chain (for example, a system contract installed in the chain) to sign data, and the system can provide the signed data by signing the requested data.
  • the contract of the chain can record events for signing and delivering data, and can deliver the signed data to another chain through a relay.
  • 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.
  • information recorded in the public blockchain (public leaf chain) allocated for external services cannot be directly updated, so information is provided to update the information recorded in the public blockchain (to enable the update of public addresses).
  • the C-nodes of the leaf chain can also have their own private keys for consensus, and these private keys can be utilized.
  • the public addresses of each of the C-nodes can be registered in the leaf chain contract installed in association with the leaf chain in the root chain, and the root chain compares the signed data with the public address registered in the leaf chain contract. , It can be verified that the signed data is sent from the leaf chain.
  • 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 contract can create a contract address with a public key and encrypt the private key so that the contract can store it. You know the private key, you can get the public key through the private key, and you can create a contract address through the public key. At this time, it is okay to have only one contract for signing (hereinafter, Signing Enable Contract) in one chain. For example, when a signable contract is deployed, an encrypted private key and a public key generated as a private key may be transmitted to the signable contract as parameters. Signable contracts can create a contract address with the received public key. At this time, if there is the same contract address, the creation of the contract address may fail.
  • Signing Enable Contract for signing
  • Signable contracts can create a contract address with the received public key. At this time, if there is the same contract address, the creation of the contract address may fail.
  • 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 signable contract can restore the private key encrypted with the password, then use the restored private key to sign the entered data, and return the signed result (signed data) to the contract that requested the signature. can do.
  • the contract address of a signable contract can be recorded in the genesis block of each leaf chain.
  • the secure type must be separately defined and utilized in the system, and the encrypted private key and public key must be generated and provided outside the system, and the private key is normally generated and delivered because the private key is encrypted and transmitted. Can't confirm whether it is.
  • 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.
  • 12 is a diagram illustrating another example of a process of installing a signable contract according to an embodiment of the present invention.
  • 12 shows an example in which the private key generated by the node is encrypted by the signable contract 1210 with the public key 1220 of the node and stored in the database 1230.
  • the signable contract 1210 may encrypt the password for decrypting the encrypted private key with the public key of the node and return it to the corresponding node.
  • the returned encrypted password can be stored locally on the node.
  • 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 1 may be an example of a process in which the leaf chain 1 1420 checks whether the remittance request is a normal request, and then transmits information on the remittance request to the root chain 1410 when there is no problem.
  • Step 2 may be an example of a process in which the root chain 1410 checks whether the remittance request is a normal request, and if there is no problem, sends a request to confirm whether remittance is possible to the leaf chain 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 computer device 200 may generate a public address of the blockchain network by using the public key generated using the private key.
  • the public address can be provided to verify that the data signed with the private key was sent from the corresponding blockchain network.
  • 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 generated public address in a genesis block of each of a plurality of leaf chains. At this time, it is possible to verify that the signed data was sent from the root chain by comparing the signed data in the leaf chain that received the signed data with the public address recorded in the genesis block of the 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 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 computer device 200 may transfer the signed data to another blockchain network. In this case, it may be verified that the signed data is sent through the blockchain network using the public address.
  • 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 return the password encrypted with the node's public key to the node.
  • the node can obtain an encrypted password.
  • the encrypted password is encrypted with the node's public key
  • other nodes of the blockchain network can find the node that has returned the encrypted password, transmit the public key of the other node to the node, and receive the password encrypted with the public key of the other node from the node and store it in the other node.
  • other nodes of the blockchain network can also obtain a password to decrypt the encrypted private key.
  • the private key itself is stored in an encrypted state, it may not be exposed.
  • passwords 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 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 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.
  • 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.

Abstract

L'invention concerne un procédé et un système d'authentification de données générées dans une chaîne de blocs. Dans des modes de réalisation de la présente invention, un procédé d'authentification de données d'un noeud mis en oeuvre par un dispositif informatique participant à un réseau à chaîne de blocs peut comprendre les étapes consistant à: partager une clé privée représentant une chaîne du réseau à chaîne de blocs avec au moins un autre noeud participant au réseau à chaîne de blocs; générer une adresse publique du réseau à chaîne de blocs à l'aide de la clé privée; signer, avec la clé privée par l'intermédiaire d'un contrat installé dans le réseau à chaîne de blocs, des données à transmettre du réseau à chaîne de blocs à un autre réseau à chaîne de blocs; et transmettre les données signées à l'autre réseau à chaîne de blocs par l'intermédiaire du contrat. Ensuite, par une comparaison entre les données signées et l'adresse publique, les données signées peuvent être vérifiées comme ayant été transmises par le réseau à chaîne de blocs.
PCT/KR2019/003002 2019-03-15 2019-03-15 Procédé et système d'authentification de données générées dans une chaîne de blocs à l'aide d'un contrat pouvant être signé WO2020189801A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2021554654A JP7254954B2 (ja) 2019-03-15 2019-03-15 ブロックチェーンで生成されたデータを認証する方法およびシステム
PCT/KR2019/003002 WO2020189801A1 (fr) 2019-03-15 2019-03-15 Procédé et système d'authentification de données générées dans une chaîne de blocs à l'aide d'un contrat pouvant être signé
KR1020217022071A KR102572834B1 (ko) 2019-03-15 2019-03-15 서명 가능 컨트랙트를 이용하여 블록체인에서 생성된 데이터를 인증하는 방법 및 시스템

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/KR2019/003002 WO2020189801A1 (fr) 2019-03-15 2019-03-15 Procédé et système d'authentification de données générées dans une chaîne de blocs à l'aide d'un contrat pouvant être signé

Publications (1)

Publication Number Publication Date
WO2020189801A1 true WO2020189801A1 (fr) 2020-09-24

Family

ID=72519256

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2019/003002 WO2020189801A1 (fr) 2019-03-15 2019-03-15 Procédé et système d'authentification de données générées dans une chaîne de blocs à l'aide d'un contrat pouvant être signé

Country Status (3)

Country Link
JP (1) JP7254954B2 (fr)
KR (1) KR102572834B1 (fr)
WO (1) WO2020189801A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114422159A (zh) * 2020-10-13 2022-04-29 北京金山云网络技术有限公司 一种基于区块链的数据处理方法及装置

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 (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017104899A1 (fr) * 2015-12-16 2017-06-22 (주)코인플러그 Système d'authentification de certificat sur la base d'une chaîne de blocs et procédé d'authentification l'utilisant
WO2017119564A1 (fr) * 2016-01-05 2017-07-13 (주)코인플러그 Système et procédé de transmission d'informations sécurisées pour une authentification d'identité personnelle
WO2018008800A1 (fr) * 2016-07-04 2018-01-11 (주)코인플러그 Système d'authentification de certificat accrédité basé sur une chaîne de blocs, et procédé d'authentification de certificat accrédité basé sur une chaîne de blocs, utilisant ce système
KR101903620B1 (ko) * 2017-06-23 2018-10-02 홍석현 블록체인 기반 분산 네트워크에서 피어의 신원을 확인하는 방법 및 이를 이용한 서버

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120294445A1 (en) * 2011-05-16 2012-11-22 Microsoft Corporation Credential storage structure with encrypted password
US9602508B1 (en) * 2013-12-26 2017-03-21 Lookout, Inc. System and method for performing an action based upon two-party authorization
US10461940B2 (en) * 2017-03-10 2019-10-29 Fmr Llc Secure firmware transaction signing platform apparatuses, methods and systems
US10447478B2 (en) * 2016-06-06 2019-10-15 Microsoft Technology Licensing, Llc Cryptographic applications for a blockchain system
US10713731B2 (en) * 2016-07-22 2020-07-14 Nec Corporation Method for secure ledger distribution and computer system using secure distributed ledger technology
GB201706132D0 (en) * 2017-04-18 2017-05-31 Nchain Holdings Ltd Computer-implemented system and method

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017104899A1 (fr) * 2015-12-16 2017-06-22 (주)코인플러그 Système d'authentification de certificat sur la base d'une chaîne de blocs et procédé d'authentification l'utilisant
WO2017119564A1 (fr) * 2016-01-05 2017-07-13 (주)코인플러그 Système et procédé de transmission d'informations sécurisées pour une authentification d'identité personnelle
WO2018008800A1 (fr) * 2016-07-04 2018-01-11 (주)코인플러그 Système d'authentification de certificat accrédité basé sur une chaîne de blocs, et procédé d'authentification de certificat accrédité basé sur une chaîne de blocs, utilisant ce système
KR101903620B1 (ko) * 2017-06-23 2018-10-02 홍석현 블록체인 기반 분산 네트워크에서 피어의 신원을 확인하는 방법 및 이를 이용한 서버

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"KOREA INSTITUTE OF FINANCE Understanding of Blockchain", KOREA VIEWS.CONS, 5 March 2017 (2017-03-05), pages 1 - 3, Retrieved from the Internet <URL:https://choonsik.blogspot.com/p/blog-page.html> [retrieved on 20191202] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114422159A (zh) * 2020-10-13 2022-04-29 北京金山云网络技术有限公司 一种基于区块链的数据处理方法及装置

Also Published As

Publication number Publication date
JP7254954B2 (ja) 2023-04-10
KR20210096287A (ko) 2021-08-04
KR102572834B1 (ko) 2023-08-30
JP2022531642A (ja) 2022-07-08

Similar Documents

Publication Publication Date Title
WO2020189800A1 (fr) Procédé et système d&#39;authentification de données générées dans une chaîne de blocs
WO2021071157A1 (fr) Dispositif électronique et procédé de gestion d&#39;adresse de chaîne de blocs au moyen dudit dispositif
WO2017104899A1 (fr) Système d&#39;authentification de certificat sur la base d&#39;une chaîne de blocs et procédé d&#39;authentification l&#39;utilisant
WO2020171538A1 (fr) Dispositif électronique et procédé de fourniture de service de signature numérique de chaîne de blocs utilisant ce dernier
WO2018030707A1 (fr) Système et procédé d&#39;authentification, et équipement d&#39;utilisateur, serveur d&#39;authentification, et serveur de service pour exécuter ledit procédé
WO2020189926A1 (fr) Procédé et serveur permettant de gérer une identité d&#39;utilisateur en utilisant un réseau à chaîne de blocs, et procédé et terminal d&#39;authentification d&#39;utilisateur utilisant l&#39;identité d&#39;utilisateur basée sur un réseau à chaîne de blocs
WO2017022917A1 (fr) Système d&#39;émission de certificat basé sur une chaîne de blocs
WO2018151427A1 (fr) Procédé de remplacement d&#39;ouverture de session d&#39;utilisateur par l&#39;intermédiaire d&#39;une authentification basée sur pki à l&#39;aide de contrat intelligent et de base de données de chaîne de blocs, et serveur l&#39;utilisant
WO2021010766A1 (fr) Dispositif et procédé d&#39;authentification électronique faisant appel à une chaîne de blocs
WO2018008800A1 (fr) Système d&#39;authentification de certificat accrédité basé sur une chaîne de blocs, et procédé d&#39;authentification de certificat accrédité basé sur une chaîne de blocs, utilisant ce système
WO2017171165A1 (fr) Système d&#39;émission de certificat public en fonction d&#39;une chaîne de blocs et procédé d&#39;émission de certificat public en fonction d&#39;une chaîne de blocs utilisant ledit système
WO2020189927A1 (fr) Procédé et serveur de gestion de l&#39;identité d&#39;un utilisateur à l&#39;aide d&#39;un réseau de chaîne de blocs, et procédé et terminal d&#39;authentification d&#39;utilisateur à l&#39;aide d&#39;une identité d&#39;utilisateur sur la base d&#39;un réseau de chaîne de blocs
WO2018151425A1 (fr) Procédé de prise en main d&#39;une session d&#39;utilisateur par le biais d&#39;une authentification basée sur pki à l&#39;aide d&#39;une base de données blockchain de protocole basé sur utxo, et serveur l&#39;utilisant
WO2020022599A1 (fr) Dispositif de gestion de groupe de nœuds, et dispositif informatique pour configurer une structure de transaction à double signature basée sur une clé de groupe dans un réseau de chaînes de blocs
WO2020022760A1 (fr) Système de réseau distribué pour groupe fonctionnel pour des noeuds contenus dans un système
WO2014069777A1 (fr) Commande de transit pour des données
WO2018124718A1 (fr) Procédé de fourniture de service de point intégré par gestion d&#39;une base de données de solde pour chaque bloc d&#39;une chaîne de blocs et serveur l&#39;utilisant
WO2020141782A1 (fr) Procédé et serveur de gestion d&#39;identité d&#39;utilisateur à l&#39;aide d&#39;un réseau à chaîne de blocs, et procédé et terminal d&#39;authentification d&#39;utilisateur à l&#39;aide d&#39;une identité d&#39;utilisateur basée sur un réseau à chaîne de blocs
WO2018124716A1 (fr) Procédé pour fournir un service de point intégré en utilisant une arborescence merkle dans un protocole basé sur utxo, et serveur d&#39;appui l&#39;utilisant
WO2018151426A1 (fr) Procédé de prise en main d&#39;une session d&#39;utilisateur par le biais d&#39;une authentification basée sur pki à l&#39;aide d&#39;une structure arborescente de merkle dans un protocole basé sur utxo et serveur l&#39;utilisant
WO2020209664A2 (fr) Procédé de distribution de certificat de droit d&#39;utilisation de contenu numérique, et programme informatique stocké dans un support afin de mettre en oeuvre le procédé
WO2023090755A1 (fr) Système de contrôle d&#39;accès au réseau d&#39;instance de virtualisation, et procédé associé
WO2020189801A1 (fr) Procédé et système d&#39;authentification de données générées dans une chaîne de blocs à l&#39;aide d&#39;un contrat pouvant être signé
WO2020022700A1 (fr) Élément de sécurité de traitement et d&#39;authentification de clé numérique et procédé de fonctionnement associé
WO2022107971A1 (fr) Procédé de logistique et système de logistique à base de plateforme de chaîne de blocs de confidentialité

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: 19919987

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20217022071

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2021554654

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: 19919987

Country of ref document: EP

Kind code of ref document: A1