KR20210096287A - Method and system for authenticating data generated on a blockchain using a signable contract - Google Patents

Abstract

A method and system for authenticating data generated on a blockchain are provided. In the embodiments of the present invention, the data authentication method of a node implemented by a computer device participating in a blockchain network includes at least a private key representing a chain of the blockchain network to participate in the blockchain network. Sharing with one other node, generating a public address of the blockchain network using the private key, and transferring data from the blockchain network to another blockchain network to a contract installed in the blockchain network It may include signing with the private key through the method and transmitting the signed data to another blockchain network through the contract. In this case, it can be verified that the signed data is transmitted through the blockchain network through comparison between the signed data and the public address.

Description

Method and system for authenticating data generated on a blockchain using a signable contract

The description below relates to a method and system for authenticating data generated on a blockchain using a signable contract.

A block-chain is an electronic ledger, implemented as a computer-based decentralized, 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 a 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. For example, Korean Patent Application Laid-Open No. 10-2018-0113143 discloses a blockchain-based user-defined currency transaction system and an operating method thereof. These blockchains themselves do not scale out. For example, in a blockchain network, adding a node to generate a block only increases the cost of consensus for block generation, but does not increase the block generation speed for a transaction.

Provides a data authentication method and system for authenticating data generated on a scale-out blockchain by adding a leaf chain based on the root chain.

In the data authentication method of a computer device operating through a contract of a block chain network, an encrypted private key and a public key generated by the private key by at least one processor included in the computer device are received as parameters to do; generating, by the at least one processor, a contract address with the received public key; storing, by the at least one processor, the encrypted private key and the contract address in a database; 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, by the at least one processor, the generated signed data.

According to one side, the password may be characterized in that it is defined as a secure type that is not stored in any of the blocks or logs of the blockchain network.

According to another aspect, the blockchain network includes a root chain managing data transmission between a plurality of leaf chains, and the data authentication method includes, by the at least one processor, the contract address to the plurality of leaf chains. The method may further include writing to each of the genesis blocks.

According to another aspect, by comparing the signed data with the contract address recorded in the genesis block of the first leaf chain in the first leaf chain receiving the signed data, the signed data is sent from the root chain. It can be characterized by verifying that it is.

According to another aspect, 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 includes: by the at least one processor, the contract The method may further include providing the contract address to the root chain so that the address is stored in a database of the root chain.

According to another aspect, by comparing the signed data in the root chain with the contract address stored in the database of the root chain, it may be characterized in that it is verified that the signed data is sent from the first leaf chain. .

According to another aspect, the block in which the signed data is recorded may be added to the chain of the blockchain network.

A data authentication method of a computer device operating through a contract of a blockchain network, the method comprising: encrypting and storing, by at least one processor included in the computer device, a private key of a node of the blockchain network; encrypting and storing, by the at least one processor, a password for decrypting the encrypted private key with the public key of the node; returning, by the at least one processor, a 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 as parameters from any node of the blockchain network; 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, by the at least one processor, the signed data.

Provided is a computer program stored in a computer-readable recording medium in combination with a computer device to execute the method on the computer device.

It provides a computer-readable recording medium in which 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 instructions readable by the computer device, and a private key encrypted by the at least one processor and a public key generated with the private key as parameters, generate a contract address with the received public key, store the encrypted private key and the contract address in a database, and decrypt the data to be signed and the encrypted private key receiving a signature request including a password for It provides a computer device characterized in that it returns.

A computer device operating through a contract of a blockchain network, comprising at least one processor implemented to execute instructions readable by the computer device, and by the at least one processor, Encrypt and store the key, encrypt and store the password for decrypting the encrypted private key with the public key of the node, return the password encrypted with the public key of the node to the node, and receive a signature request from a node including the password and data for signing with the private key as parameters, and in response to the signature request, decrypt the encrypted private key through the password, and the data with the decrypted private key to generate signed data, and to return the signed data.

By adding a leaf chain based on the root chain, it is possible to provide a data authentication method and system for authenticating data generated in a scale-out blockchain.

1 is a diagram illustrating an example of a network environment according to an embodiment of the present invention.
2 is a block diagram illustrating an example of a computer device according to an embodiment of the present invention.
3 is a diagram illustrating an example of a general configuration of a scalable blockchain network according to an embodiment of the present invention.
4 is a diagram illustrating an example of a detailed configuration of a transaction processing system according to an embodiment of the present invention.
5 is a flowchart illustrating an example of a process of adding a new leaf chain according to an embodiment of the present invention.
6 is a flowchart illustrating an example of a process of adding a new service according to an embodiment of the present invention.
7 is a flowchart illustrating an example of a process of issuing a coin to a service according to an embodiment of the present invention.
8 is a flowchart illustrating an example of a coin exchange process according to an embodiment of the present invention.
9 is a diagram illustrating a flow of coin exchange data through a smart contract between each chain according to an embodiment of the present invention.
10 is a diagram illustrating an example of an installation process of a signable contract according to an embodiment of the present invention.
11 is a diagram illustrating an example of a process of signing data according to an embodiment of the present invention.
12 is a diagram illustrating another example of an installation process of a signable contract according to an embodiment of the present invention.
13 is a diagram illustrating another example of a process of signing data according to an embodiment of the present invention.
14 is a diagram illustrating 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 flowchart 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.
18 is a flowchart illustrating a fourth example of a data authentication method according to an embodiment of the present invention.

Best mode for carrying out the invention

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings.

The data authentication system according to embodiments of the present invention may be implemented by at least one computer device. The computer program according to an embodiment of the present invention may be installed and driven in the computer device, and the computer device may perform the data authentication method according to an embodiment of the present invention under the control of the driven computer program. The above-described computer program may be stored in a computer-readable recording medium in order to be combined with a computer device and execute the data authentication method in the computer device. The computer program described herein may have the form of one independent program package, or the form of one independent program package may be pre-installed in the computer device and linked with the operating system or other program packages.

1 is a diagram illustrating 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 , 140 , a plurality of servers 150 , 160 , and a network 170 . FIG. 1 is an example for explaining the invention, and the number of electronic devices or the number of servers is not limited as in FIG. 1 . In addition, the network environment of FIG. 1 only describes one example of environments applicable to the present embodiments, and the environment applicable to the present 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 a smart phone, a mobile phone, a navigation device, a computer, a notebook computer, a digital broadcasting terminal, a personal digital assistant (PDA), and a portable multimedia player (PMP). ), and tablet PCs. As an example, although the shape of a smartphone is shown as an example of the electronic device 1110 in FIG. 1 , in the embodiments of the present invention, the electronic device 1110 substantially communicates with the network 170 using a wireless or wired communication method. It may refer to one of various physical computer devices capable of communicating with other electronic devices 120 , 130 , 140 and/or servers 150 and 160 through the communication system.

The communication method is not limited, and not only a communication method using a communication network (eg, a mobile communication network, a wired Internet, a wireless Internet, a broadcasting network) that the network 170 may include, but also short-range wireless communication between devices may be included. For example, the network 170 may include 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). , the Internet, and the like. In addition, 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 communicates with the plurality of electronic devices 110 , 120 , 130 , 140 and the network 170 through a computer device or a plurality of computers that provide commands, codes, files, contents, services, etc. It can be implemented in devices. For example, the server 150 provides a service (eg, a video call service, a financial service, a payment service, a social network service) to the plurality of electronic devices 110 , 120 , 130 , 140 accessed through the network 170 . , a messaging service, a search service, a mail service, a content providing service, and/or a question and answer service).

2 is a block diagram illustrating an example of a computer device according to an embodiment of the present invention. Each of the aforementioned plurality of electronic devices 110 , 120 , 130 , 140 or each of the servers 150 , 160 may be implemented by the computer device 200 illustrated in FIG. 2 , according to an embodiment of the present invention The method according to the above may be performed by such a computer device 200 .

In this case, as shown in FIG. 2 , 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 random access memory (RAM), a read only memory (ROM), and a permanent mass storage device such as a disk drive. Here, a non-volatile mass storage device such as a ROM and a disk drive may be included in the computer device 200 as a separate permanent storage device distinct from the memory 210 . Also, the memory 210 may store an operating system and at least one program code. These software components may be loaded into the memory 210 from a computer-readable recording medium separate from the memory 210 . The separate computer-readable recording medium may include a computer-readable recording medium such as a floppy drive, a disk, a tape, a DVD/CD-ROM drive, and a memory card. In another embodiment, the software components may be loaded into the memory 210 through the communication interface 230 instead of a computer-readable recording medium. For example, the 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. The instructions 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 received instruction 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, the storage devices described above) through the network 170 . For example, a request, command, data, file, 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 is transmitted to the network ( 170) 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 . A signal, command, or data received through the communication interface 230 may be transferred to the processor 220 or the memory 210 , and the file may be a storage medium (described above) that the computer device 200 may further include. persistent storage).

The input/output interface 240 may be a means for an interface with the input/output device 250 . For example, the input device may include a device such as a microphone, keyboard, camera, or mouse, and the output device may include a device such as a display or speaker. As another example, the input/output interface 240 may be a means for an interface with a device in which functions for input and output are integrated into one, such as a touch screen. The input/output device 250 may be configured as one device with the computer device 200 .

Also, in other embodiments, the computer device 200 may include fewer or more components than those of FIG. 2 . However, there is no need to clearly show most of the prior art components. For example, the computer device 200 may be implemented to include at least a portion of the above-described input/output device 250 or may further include other components such as a transceiver and a database.

3 is a diagram illustrating an example of a general configuration of a scalable blockchain network according to an embodiment of the present invention. 3 is a block chain network 300 including Root Chain 310, Leaf Chain A 320, Leaf Chain B 330, and Relay 340. 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.

In the blockchain network 300, the root chain 310 can 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. In this case, each of the leaf chains 320 and 330 may be associated with an individual service, and a new leaf chain may be added when a new service is added. In other words, although the embodiment of FIG. 3 shows two leaf chains 320 and 330 , it may include three or more leaf chains, which may mean that the block chain can be expanded. Here, "service" may include online services provided by the same or different entities to their users through a network. For example, a plurality of leaf chains corresponding to each of the Internet banking services provided by a plurality of different banks may be configured. Alternatively, 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 the hash of the block to the root chain 310 . As an example, a merkle tree root hash may be utilized.

The root chain 310 does not exchange coins between users, and coin exchange may be performed within each of the leaf chains 320 and 330 and/or between the leaf chains 320 and 330 . In this case, the coin exchange between the leaf chains 320 and 330 may be mediated and managed by the root chain 310 through the relayer 340 . Each of the leaf chains 320 and 330 may include at least one decentralized application (DApp). Here, a DApp (Decentralized Application, DApp) refers to an application in which the backend code runs on a decentralized peer-to-peer network (or performs data calls and registrations in a blockchain database) and provides it as an interface at the frontend. At this time, in each of the leaf chains 320 and 330 , a smart contract that is irrelevant to the chain and coin exchange may be installed according to the needs of the DApp, and this may not be involved in the root chain 310 . In the case of installing a smart contract having a protocol for coin exchange between chains in each of the leaf chains 320 and 330 , permission for the installation of the smart contract must be obtained through the root chain 310 . Inter-chain coin exchange using a smart contract that is not authorized by the root chain 310 may be restricted so that it does not occur.

Coin exchange inside 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 (eg, the Merkle tree root hash described above) may be recorded in the root chain 310 . On the other hand, coin exchange between the leaf chains 320 and 330 must be made through the root chain 310, and each block of the leaf chains 320 and 330 and the block of the root chain 310 for the processing of coin exchange. content should be recorded. In this case, coin exchange between the leaf chains 320 and 330 may be performed through the relayer 340 .

4 is a diagram illustrating an example of a detailed configuration of a block chain network according to an embodiment of the present invention. The blockchain network 300 may be composed of one root chain 310, several leaf chains 320 and 330, and a relayer 340 as shown in FIG.

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 a smart contract for each. In the embodiment of Figure 4, the root chain 310 is a smart contract for the leaf chain A (Leaf Chain A, 320), the leaf chain A contract (LeafChain A Contract, 412) and the leaf chain B (Leaf Chain B, 330) An example including the LeafChain B Contract (413), which is a smart contract for

In addition, each of the leaf chains 320 and 330 may include a smart contract for a DApp. 4 shows an example in which leaf chain A 320 includes a dApp contract 421 and leaf chain B 330 includes a dApp contract 431 . In addition, leaf chain A (320) is a smart contract for leaf chain A (320), a leaf chain manager contract (LeafChainManager Contract, 422), and leaf chain A (330) is a smart contract for leaf chain B (330). It may further include a leaf chain manager contract 432 .

The relayer 340 observes the block generation of the root chain 310 and the leaf chains 320 and 330, and information required to be recorded and/or transmitted to the root chain 310 and the leaf chains 320 and 330. can be invoked. Relayer 340 includes a producer (Producer, 441), Kafka (Kafka, 442), an interchain consumer (InterChain Consumer, 443), an interchain failover (InterChain Failover, 444), and a database (Database, 445). can

The producer 441 may collect information on newly created blocks of all chains including the root chain 310 and input it to Kafka 442 . Kafka 442 is a kind of queue server, it can store the collected information in a queue and provide it sequentially. In this case, the inter-chain consumer 443 may filter events requiring an invocation for each chain. Multiple filtering may be required depending on the event. The interchain consumer 443 may create a separate user for each chain for signification when invoking each chain, and record the user's authority in the smart contract.

The interchain consumer 443 may detect the following events (1) to (7).

(1) Remittance request event on leaf chain

(1-1) The interchain consumer 443 may detect a remittance request event in the leaf chain and transmit the remittance request to the root chain.

(2) Remittance request event on the root chain

(2-1) The interchain consumer 443 may detect a remittance request event in the root chain and transmit the remittance request to the leaf chain that will receive the remittance request.

(2-2) When delivery to the receiving leaf chain fails, the interchain consumer 443 may transmit remittance failure information including identification information of the leaf chain that will receive the remittance request to the root chain.

(3) Remittance request failure event on the root chain

(3-1) The interchain consumer 443 may deliver the remittance failure content to the leaf chain that requested the remittance.

(4) Remittance completion event on leaf chain

(4-1) The interchain consumer 443 may deliver the remittance completion content to the root chain.

(5) Remittance completion event on the root chain

(5-1) The interchain consumer 443 may deliver the remittance completion content to the leaf chain that requested the remittance.

(6) Coin issuance event on the root chain

(6-1) The interchain consumer 443 may transmit the issuance content to the leaf chain where the coin is issued.

(7) Block creation event on leaf chain

(7-1) The interchain consumer 443 may transmit 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. In addition, the database 445 may be utilized to store information received and/or transmitted (transmitted) by the interchain consumer 443 and the interchain failover 444 .

5 is a flowchart illustrating an example of a process of adding a new leaf chain according to an embodiment of the present invention.

In step 510, the blockchain network 300 may build a leaf chain. For example, a new leaf chain can be built to add new services, which will be described later.

In step 520, the blockchain network 300 may install a leaf chain manager contract that will be responsible for remittance of coins between chains or between contracts in the leaf chain.

In step 530, the blockchain network 300 may install a contract that can process the corresponding leaf chain (hereinafter referred to as the leaf chain contract) in the root chain.

In step 540, the blockchain network 300 may register the leaf chain contract address of the installed root chain in the root chain manager contract. According to embodiments to be described later, the address of the leaf chain's Signing Enable Contract may be further registered in the root chain manager contract. In another embodiment, a public address representing the leaf chain may be registered in the root chain manager contract.

In step 550, the blockchain network 300 may add a relay user who can access the leaf chain contract of the root chain.

In step 560, the blockchain network 300 may add a relay user with access to the leaf chain manager contract of the leaf chain.

In this case, the relay users in steps 550 and 560 may be the same user or different users. It may be advantageous in terms of security to set up and use a separate relayer user for each leaf chain and also from the root chain. Here, the relay user may correspond to an account of the service provided by the blockchain network 300 .

6 is a flowchart illustrating an example of a process of adding a new service according to an embodiment of the present invention.

In step 610, the blockchain network 300 may install a contract of the corresponding service in the leaf chain. The address of the installed contract can be used as a value to distinguish the service. The service may be a contract with an inter-chain coin exchange protocol.

In step 620, 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. For example, in step 520 of FIG. 5 , it has been described that a leaf chain manager contract that will be responsible for inter-chain or inter-contract coin remittance can be installed in the leaf chain. The address of the contract for service can be registered in this leaf chain manager contract.

In step 630, the blockchain network 300 may register the address of the installed contract in the root chain manager contract of the root chain. In this case, the address of the installed contract may be registered through the administrator authority of the root chain manager contract. If you register the address of the contract installed for the service of the leaf chain in the root chain manager contract together with the leaf chain contract of the corresponding leaf chain installed in the root chain, the leaf chain contract of the root chain also contains the address of the contract installed for the service of the leaf chain. It can be registered as a service of the corresponding leaf chain.

7 is a flowchart illustrating an example of a process of issuing a coin to a service according to an embodiment of the present invention.

In step 710, 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. For example, the root chain manager contract of the root chain can identify that service through the contract's address for the service for issuing coins through the leaf chain contract installed on the root chain, and the coin issuance event for the identified service. can cause

In step 720, the interchain consumer may detect a coin issuance event for the corresponding service and request coin issuance of the service from the leaf chain manager contract of the corresponding leaf chain.

In step 730, the leaf chain manager contract may find a corresponding service and issue a coin. In this case, the coin may be issued to the service operator (eg, the relay user added in step 560 of FIG. 5 ) input when installing the contract of the corresponding service.

8 is a flowchart illustrating an example of a coin exchange process according to 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. In addition, coin exchange between other services on the same chain can be made through the leaf chain manager contract of the corresponding leaf chain. For example, remittance from a first service to a second service on the same chain may be made by a leaf chain manager contract calling the address of a contract of the second service according to a request for remittance of the first service. At this time, when coins are exchanged between other services of the same leaf chain, the result of the coin exchange may be transmitted to the root chain. This is so that the root chain can identify changes in the amount of coins held by each service of the leaf chains. On the other hand, coin exchange between different chains can be made through the steps 810 to 890 below. Steps 810 to 890 of FIG. 8 describe an example of coin exchange between leaf chain A 320 and leaf chain B 330 described with reference to FIG. 4 .

In step 810 , 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 user a, and if the coin exchange request is a normal request, it may be recorded in the block of the leaf chain A 320 . The exchange-requested coin (the remittance-requested coin) may be deducted from the user a's balance by the leaf chain manager contract included in the leaf chain A 320, and may be locked so as not to be used. For example, the leaf chain manager contract of leaf chain A 320 checks the balance of user a by the amount requested for remittance and the balance of the service requesting remittance, and then the amount deducted from the currency amount of leaf chain A 320 is not used. You can set a lock to prevent it. Information on the deducted amount of user a may be recorded in the escrow contract. A record of the success of this remittance may be recorded in Kafka 442 by the 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 a remittance request fails.

In step 820 , 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 transaction collection of the producer 441, and the interchain consumer 443 may transmit the remittance request to the root chain 310 in response to the detection of the detected remittance request event. .

In step 830, the root chain 310 analyzes the total amount of coins issued by the leaf chain A 320 using the remittance request information to determine whether the remittance request is a normal request, and determines whether the remittance request is a normal request. In the case of , a coin exchange request from leaf chain A 320 to leaf chain B 330 may be recorded in a block. The exchange request can be locked so that it is not used as much as the amount of coins to be transferred. Also, when the request for remittance is not a normal request, the root chain 310 may record the failure content in the block. The remittance request recorded as a failure is again detected as a remittance failure event by the interchain consumer 443 and may be 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 to user a.

In step 840 , the interchain consumer 443 may detect a remittance request event from the root chain 310 to the leaf chain B 330 , and transmit the remittance request to the leaf chain B 330 . If the request fails because the leaf chain B 330 does not operate normally, the transmission failure content due to the system abnormality of the leaf chain B 330 may be transmitted to the root chain 310 again. The request recorded as a failure is again detected as a remittance failure event by the interchain consumer 443 and can be transmitted to the leaf chain A 320, and the leaf chain A 320 receiving the remittance failure event releases the locked coin. It can be returned back to user a.

In step 850 , if the corresponding remittance request is a normal request, the leaf chain B 330 may remit a coin to the user b and increase the total currency amount of the leaf chain B 330 by the amount of the remitted coins. If the remittance request fails, the failure can be recorded in the block.

In step 860 , the interchain consumer 443 may detect the result of the remittance completion of the leaf chain B as an event and transmit the hash and success or failure to the root chain 310 .

In step 870 , the root chain 310 may receive the remittance result, process it according to the remittance failure and the remittance success, and record the result in a block together with a hash. If the remittance is successful, the root chain 310 may release the locked coin remittance request to 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 .

In step 880, the interchain consumer 443 may detect the remittance result event processed by the root chain 310 and deliver the result to the leaf chain A 320 .

In step 890 , the leaf chain A 320 may receive the remittance result and, if successful, release the locked coin to adjust the total currency amount of the leaf chain A 320 (deduct the remittance amount from the total currency amount). If the remittance fails, the leaf chain A 320 may release the locked coin and return it to the user a. The leaf chain A 320 may record the remittance result in a block along with the hash recorded in the root chain 310 .

9 is a diagram illustrating a flow of coin exchange data through a smart contract between each chain according to an embodiment of the present invention.

(1) When DApp 1 (dApp 1, 920) of leaf chain A 320 receives user a's coin exchange request, dApp 1 920 can make an exchange request to leaf chain manager contract A 910 . Leaf chain manager contract A 910 generates an exchange transaction hash (eTxHash), exchange transaction hash, user a (identifier of) and service a (identifier of) to send money, service b (identifier of) and user b (identifier of), amount information (transfer amount), and/or request time can be recorded (remittance request record (escrow information) is created). In this case, the leaf chain manager contract A 910 may deduct the total currency amount of the contract of the dapp 1 920 and the holding amount of the user a.

(2) The producer 441 may collect the transactions generated in (1), and the interchain consumer 443 may request a remittance from the leaf chain A contract 412 of the root chain 310 .

(3) The leaf chain A contract 412 may separately record remittance request information for the root chain 310 through the root chain manager contract 411 . In this case, the total currency amount of the DApp 1 920 managed by the leaf chain manager A contract 412 may be deducted by the remittance amount.

(4) The producer 441 can collect the transactions created in (3), and the interchain consumer 443 connects to the leaf chain manager contract B 940 of the leaf chain B 330 with the service that receives the remittance. You can request a remittance.

(5) The leaf chain manager contract B 940 of the leaf chain B 330 may call DApp 3 950 , which is a service to be remitted, so that the remittance is made to the user b from the contract of the DApp 3 950 . At this time, the contract of the DApp 3 950 may also increase the total currency of the leaf chain B 330 .

(6) The producer 441 may collect the transaction generated in (5), and the interchain consumer 443 may request the leaf chain B contract 413 of the root chain 310 to complete the remittance.

(7) The leaf chain B contract 413 of the root chain 310 can process the remittance completion by bringing the escrow (remittance request record) information of the corresponding remittance request to the root chain manager contract 411 . If the remittance is successful, the total currency amount of the leaf chain B 330 may be increased by the amount of remittance in the dapp 3 950 managed by the leaf chain B contract 413, and the root chain manager contract of the root chain 310 In (411), the remittance request record may be deleted. If the remittance fails, the total amount of money in leaf chain A 320 may be increased again by the amount of remittance to DApp 1 920, which is the service that requested remittance registered in the leaf chain A contract 412, and after that, the root chain 310 ) of the root chain manager contract 411, the corresponding remittance request record may be deleted.

(8) The producer 441 can collect the transaction generated in (7), and the interchain consumer 443 requests the leaf chain manager contract A 910 of the leaf chain A 320 to complete the remittance. can

(9) The leaf chain manager contract A 910 of the leaf chain A 320 may receive the remittance completion information, record that the exchange transaction hash is complete, and delete the request in the remittance request record (escrow). If the remittance fails, the leaf chain manager contract A 910 may return the amount in the remittance request record (escrow) back to the user a, and the total currency amount of the DApp 1 920 also increases by the remittance amount, and then remits the remittance. You can delete the request from the request history (escrow).

According to an embodiment, a relayer may exist for each chain. For example, when one root chain 310 and two leaf chains 320 and 330 exist as described with reference to FIG. 4 , three relayers for a total of three chains may be configured. In this case, the relayer of the root chain 310 may process the transfer of requests, data, and/or events to and from the two leaf chains 320 and 330 , and each of the two leaf chains 320 and 330 . The relayer may handle the transfer of requests, data and/or events to and from the root chain 310 . In this case, in order to prevent collusion of relayers for leaf chains, a chain connected to each relayer may be dynamically changed every preset time period (eg, block time period). In this embodiment, the hash can prevent exchange transactions from being stolen or tampered with by relayers when moving between chains through a hashed timelock contract. This hash time lock can be used to provide time for users to directly check the result of an exchange transaction. In addition, a separate exchange transaction identifier may be used as a unique identifier to prevent unintentional double-spending by relayers. This exchange transaction identifier can be used to uniquely identify and track an exchange transaction when there is a value movement between leaf chains.

When data is transmitted between chains in such a block chain network 300, there is a possibility of tampering with the data to be transmitted in the transmitting system. As an example, when passing data from leaf chain A 320 to root chain 310 , there is a possibility of tampering with data in leaf chain A 320 . In particular, when a relay language is implemented for each leaf chain in order to be able to expand the leaf chains in the form of a public block chain, it is necessary to reduce the dependence on such relay language and solve the problem of data authentication at the protocol level. To this end, the blockchain network 300 has the following five requirements.

1. Remittance between chains of Base Coin should be possible. Here, the base coin may mean a coin used in a unique coin system of the block chain network 300 .

2. The root chain must be able to manage the base coins of all chains. In this case, the management of the base coin may include remittance of the base coin between chains.

3. It must prevent relayers from tampering with data.

4. After receiving the remittance from the leaf chain, the remittance succeeded to the user, but a double payment should not occur by delivering a failure message.

5. In remittance, inter-chain remittance should be made quickly without confirmation of the user receiving the base coin.

For this requirement, in the root chain, the mint and burn of the base coin can occur through an authorized user. Alternatively, authorized users can be verified with a multisig-wallet to issue or burn Base Coin. At this time, in the leaf chain, the issuance can be executed when a coin issuance request is received from the root chain. Also, when remittance from one leaf chain to another leaf 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, the leaf chain that sends the base coin can burn the base coin, and the leaf chain that receives the base coin can issue the base coin.

On the other hand, in order to prevent data tampering of the relayer, it is necessary to prevent the data to be transmitted from being tampered with. Hereinafter, methods for blocking data tampering will be described.

In the first method, the original data to be transmitted can be signed. If the subject (from user) transmitting the data is a user already known in the chain to receive the data, it is possible to check whether the original data has been tampered with through the signed original data. To this end, a contract may be created with the contract's own private key, and a public key corresponding to the private key may be disclosed. At this time, information that needs to be transmitted to other chains in the contract can be signed and recorded as an event, thus proving that the original data was processed from the contract. For example, a contract can sign the original data and its own contract address with the contract's private key. In this case, any user can verify the original signed data using the public key corresponding to the private key of the contract, and the contract address of the contract that is uniquely created in all chains is used to access the contract. It can be verified that the data was transmitted by However, in the first method, the contract's private key has to be stored in the contract's database, and since the database is shared and opened in the blockchain network, the private key is shared among all nodes in the chain, so it is no longer a private key. .

In the second method, instead of storing the private key in the contract, the private key representing one chain is shared with C-nodes, which are nodes that reach consensus within the same chain, and used when chain authentication is required. can do it As an example, each chain can maintain a shared private key by n (eg, n is 4 to 8) C-nodes for consensus. A user or other contract may request the system for the chain (eg, a system contract installed on the chain) to sign the data, and the system may provide the signed data by signing the requested data. At this time, the contract on the corresponding chain can record the event for data signing and delivery, and can deliver the signed data to another chain through a relayer. For example, a public address, an identification value created through a public key paired with the root chain's private key in the root chain, is recorded in the leaf chain's genesis block and cannot be tampered with in the leaf chain. Data signed with the private key through the root chain can be verified that the signed data was sent from the loop chain by comparing it with the public address recorded in the genesis block on the leaf chain. Similarly, a leaf chain can also register a public address created with the leaf chain's private key to a leaf chain contract installed in association with the leaf chain in the root chain. In this case, the root chain can verify that the signed data was 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. However, the second method can be used in a private blockchain where the private key can be shared among 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 utilize the unique private key that each C-node in the root chain has for consensus. As an example, if the root chain includes 8 C-nodes, there may be 8 private keys. In this case, the public addresses of all C-nodes of the root chain generated by the corresponding private keys may be stored in each of all leaf chains. At this time, the data that needs to be verified as being generated in the root chain can be recorded in the block by the leader node of the root chain signed with their private key, and the data can be delivered to the leaf chain. Here, the leader node may be a node arbitrarily selected from among C-nodes, and may be changed to one of other C-nodes if necessary. In this case, 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 described above, since the leaf chain knows the public addresses of all C-nodes in the root chain, whether the public address obtained when verifying the signed data is one of the public addresses of the C-nodes in the root chain that it already knows By verifying whether the data is signed, the signed data can be verified. However, the number of C-nodes included in the loop chain is disclosed, and when a change occurs, such as adding or deleting a C-node to the root chain, the information recorded in each leaf chain must be updated. In particular, the 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 the public address). information for this purpose) should be announced. Similarly, C-nodes in the leaf chain may have their own private key for consensus, and this private key may be utilized. In this case, 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 verify that the signed data was sent from the corresponding leaf chain.

The fourth method is to share a common public address created by a combination of public addresses generated by all C-nodes of the root chain to each of the leaf chains. Even in this case, if there is a change such as adding or deleting a C-node to the loop chain, the information recorded in each of the leaf chains must be updated, but the public address to be shared in 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, you must be careful about security when changing it. In the fourth method, each of all C-nodes must know each of the public addresses of all C-nodes in the root chain. Also, in the fourth method, even if there are multiple private keys, one public address (representative public address) can be created, and an algorithm for signing and an algorithm for verifying the private key can be developed so that the private key can be decrypted through one or more confirmations. A modified module is required.

In the fifth method, the following functions can be added to the blockchain to make the first method usable. In the fifth method, the contract can generate the contract address with the 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 the contract address through the public key. In this case, only one contract for signing (hereinafter, a Signing Enable Contract) may exist in one chain. For example, when the signable contract is installed (deployment), the encrypted private key and the public key generated with the private key may be delivered to the signable contract as parameters. A signable contract can generate a contract address with the public key it receives. At this time, if there is the same contract address, generation of the contract address may fail. The encrypted private key may be decrypted using a password to be described later, and may be stored in a database by a signable contract. At this time, when any contract wants to sign data, the data to be signed and the password for decrypting the encrypted private key stored in the signable contract can be delivered to the signable contract as parameters. At this time, information according to all requests in the block chain (for example, requests using HTTPS (Hypertext Transfer Protocol Secure)) are recorded in blocks or logs, whereas passwords should not be stored/recorded anywhere. Therefore, in the fifth method, the password parameter may be defined as a type that is not stored/recorded anywhere, such as a block or log (hereinafter, 'secure type'). These password parameters can be supported by the corresponding blockchain. In this case, the signable contract can restore the encrypted private key through the password, and then use the restored private key to sign the input 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. However, in the fifth method, 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. It is not possible to ascertain whether In order for the leaf chain to prove that the data is transmitted from the root chain, the leaf chain can immediately determine whether the signable contract that signed the data is a contract installed on the root chain by querying the root chain, and the corresponding signing contract is the contract on the root chain. If it is proven that the contract exists in

10 is a diagram illustrating an example of an installation process of 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, and generates a public address using the received public key 1030 and stores it in the database 1040. an example is shown. In other words, the database 1040 may store the encrypted private key 1020 , the public key 1030 , and a public address generated 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 . In this case, the signature request may include data for signing and a password for decrypting the encrypted private key 1020 described in FIG. 10 . In this case, the signable contract 1010 may decrypt the encrypted private key 1020 using the password to obtain the 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 other contract 1110 as a result. Here, the user can correspond to the node of the corresponding blockchain.

In the sixth method, the signable contract of the fifth method can be automatically installed as a system contract on the blockchain. In other words, when the system contract of the blockchain is installed, the signable contract can also be installed. For example, a node that initially creates a system contract, 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 a password for decrypting the encrypted private key may be encrypted with the public key of the corresponding node and stored locally in the corresponding node. Other nodes can replicate the transaction and search for a node that knows the latest password. At this time, the other node may transmit its public key to the node to be searched, receive the password encrypted with the public key, and store it locally in the other node. When each node requests a signature, it can obtain a password by decrypting its locally stored encrypted password with its public key, and can transmit 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 utilized to prove that data is being transmitted on the root chain.

12 is a diagram illustrating another example of an installation process of 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. In this case, the signable contract 1210 may return the password for decrypting the encrypted private key to the node after being encrypted with the public key of the node. The returned encrypted password may 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. . Here, the system 1320 may correspond to a blockchain system. In this case, data to be signed may also be transmitted to the system 1320 as parameters. In this case, the system 1320 may request the signature of the data to the signable contract 1210 using the password. In this case, the signable contract 1210 may decrypt the encrypted private key through the password, and may return the signed data after signing the data using the decrypted private key. System 1320 may pass the returned signed data to node 1310 .

On the other hand, it is necessary to ensure that the contents processed inside the leaf chain and the contents delivered are not different. For this purpose, the proof hash list of the Merkle tree of the transaction that processed the remittance must be delivered through the event as the processing result. If there is a watcher, it is necessary to decide whether or not to pass the proof information of the Merkle tree. The event information to be transmitted can be signed with the contract's private key and recorded in the event. In this case, it is known that the transaction has been processed, but it is not possible to determine whether the processing has been tampered with, so a watcher may be required. At this time, the monitor can check whether the corresponding block exists and whether the remittance was successful or failed, such as data transmitted by the transaction as an event. If fraud is detected by the watcher, a penalty may be provided to the corresponding leaf chain. Here, the monitor may be implemented in the form of a node that executes the above function.

14 is a diagram illustrating another example of a coin exchange method according to an embodiment of the present invention. Coin exchange in the same service on the same chain or coin exchange between other services on the same chain has been described in the embodiment of FIG. 8 as well. Fig. 14 shows a root chain 1410, leaf chain 1 1420, and leaf chain 2 1430 as an embodiment different from the embodiment of Fig. 8, and user 1 of leaf chain 1 1420 is a leaf chain. It is assumed that a remittance request is made to user 2 of 2 ( 1430 ).

Process 1 may be an example of a process of transferring information about a remittance request to the root chain 1410 if there is no problem after checking whether the remittance request is a normal request in the leaf chain 1 1420 .

Process 2 may be an example of a process in which the root chain 1410 checks whether a remittance request is a normal request, and then sends a confirmation request as to whether remittance is possible to the leaf chain 2 1430 if there is no problem.

Step 3 may be an example of a process of transmitting a receivable response to the root chain 1410 if there is no problem after checking whether the remittance request is a receivable request in the leaf chain 2 1430 .

Process 4 may be an example of a process in which the root chain 1410 issues a receipt for subtracting or increasing the remittance amount to leaf chain 1 1420 and leaf chain 2 1430, respectively. Process 4.1 may be an example of the process in which the root chain 1410 issues a receipt for deducting the remittance amount to the leaf chain 1 1420, and the process 4.2 is the root chain 1410 increasing the remittance amount to the leaf chain 2 1430 It may be an example of the process of issuing a receipt for In each chain, management can be done to prevent duplicate deductions or duplicate increments from occurring.

Hereinafter, the configuration of the smart contract will be described.

In the case of a root chain, 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 of the leaf chains. On the other hand, 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 leaf chain manager contract are system contracts that can be installed automatically when the blockchain is installed. Relayers can filter eventLogs and forward them to each chain. Each chain can manage data so that relayers cannot tamper with it. As already explained, the root chain can store the public address created with the private key of each leaf chain, and the leaf chain can record the public address created with the root chain's unique private key when generating the genesis block. It is possible to ensure that all information to be transmitted by the relayer can be transmitted along with information signed with the unique private key of the root chain.

In addition, if a service dApp exists in the leaf chain, the user can call the function defined "exchange" of the dapp. At this time, the DApp can call "exchange" defined in icx, so the 'exchange function needs to be implemented in the icx class.

Meanwhile, the information required for inter-chain remittance is as follows.

· from user: The user who makes the remittance

origin: service or leaf chain requested for remittance

· to user: the user receiving the remittance

destination: service receiving remittance or leaf chain

· value: remittance amount (base coin)

· eTxHash: remittance transaction hash

· message : remittance message

eSignature: The signature of the leaf chain that requested data delivery

Here, the signature of the leaf chain may include a value signed by combining from user, origin, to user, destination, value, eTxHash, and message.

15 is a flowchart illustrating a first 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. For example, the processor 220 of the computer device 200 may be implemented to execute a control instruction according to a code of an operating system included in the memory 210 or a code of at least one program. Here, the processor 220 causes 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 control

In step 1510, 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. In this case, 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 the plurality of nodes preset to achieve consensus in the blockchain network.

The data authentication method according to this embodiment describes a process of sharing one private key representing a chain in the second method described above among C-nodes of the corresponding chain and using this for chain authentication. In other words, the computer device 200 implementing one node may share the private key representing the chain of the blockchain network in which the node implemented by the computer device 200 participates with at least one other node.

In step 1520, the computer device 200 may generate a public address of the blockchain network by using the public key generated using the private key. As already explained, the public address can be provided to verify that the data signed with the private key is sent from the corresponding blockchain network.

In one embodiment, the blockchain network may include a root chain that manages data transfer between a plurality of leaf chains. In this case, the computer device 200 may record the generated public address in a genesis block of each of the 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 and the public address recorded in the leaf chain's genesis block.

In another embodiment, 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. In this case, the computer device 200 may register the generated public address in the 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 signed data in the root chain with the public address registered in the corresponding leaf chain contract.

In step 1530, the computer device 200 may sign data to be transmitted from the block chain network to another block chain network with a private key through a contract installed in the block chain network. At this time, the block in which the signed data is recorded can be added to the chain of the blockchain network.

In step 1540, 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.

16 is a flowchart 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. For example, the processor 220 of the computer device 200 may be implemented to execute a control instruction according to a code of an operating system included in the memory 210 or a code of at least one program. Here, the processor 220 causes the computer device 200 to perform steps 1610 to 1630 included in the method of FIG. 16 according to a control command provided by a code stored in the computer device 200 . can control

In operation 1610, the computer device 200 may generate a public address of the node by using the private key of the node. A node's private key can be a unique private key that the node has for consensus in the blockchain network.

In step 1620, the computer device 200 may sign data to be transmitted from the block chain network to another block chain 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.

In step 1630, the computer device 200 may transmit the signed data to another blockchain network. In this case, it can be verified that the signed data is sent through the blockchain network using the public address.

In one embodiment, the blockchain network may include a root chain that manages data transfer between a plurality of leaf chains. At this time, 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) preset 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 was sent from the root chain by comparing the signed data in the first leaf chain to which the signed data was transmitted and the public addresses of each of the plurality of nodes stored in the first leaf chain.

In another embodiment, the blockchain network may include a first leaf chain among a plurality of leaf chains whose data transmission is managed by a root chain. At this time, a 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) 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 signed data in the root chain with the public address registered in the leaf chain contract.

In another embodiment, the blockchain network may include a root chain that manages data transfer between a plurality of leaf chains. At this time, a representative public address 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 to achieve consensus in the blockchain network An address may be stored in each of a plurality of leaf chains. In this case, it is possible to verify that the signed data was sent from the root chain by comparing the signed data in the first leaf chain to which the signed data was transmitted and the representative public address stored in the first leaf chain.

In another embodiment, the blockchain network may include a first leaf chain among a plurality of leaf chains whose data transmission is managed by a root chain. At this time, a representative public address 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 to achieve consensus in the blockchain network The address may be registered in the 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 signed data in the root chain with the representative public address registered in the leaf chain contract.

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 block chain network. For example, the processor 220 of the computer device 200 may be implemented to execute a control instruction according to a code of an operating system included in the memory 210 or a code of at least one program. Here, the processor 220 causes 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 control Here, the at least one program code may include at least a code according to a contract of the blockchain network.

In operation 1710, the computer device 200 may receive the encrypted private key and the public key generated from the private key as parameters.

In step 1720, the computer device 200 may generate a contract address with the received public key.

In step 1730, the computer device 200 may store the encrypted private key and the contract address in a database.

In operation 1740, 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. Here, the password can be defined as a secure type that is not stored in any block or log of the blockchain network.

In operation 1750, 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, the block in which the signed data is recorded may be added to the chain of the blockchain network.

In operation 1760, the computer device 200 may return the generated signed data. In this case, the signed data may be returned to the node that requested the signature of the data.

In one embodiment, the blockchain network may include a root chain that manages data transfer between a plurality of leaf chains. In this case, 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 was 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.

In another embodiment, the blockchain network may include a first leaf chain among a plurality of leaf chains whose data transmission is managed by a root chain. In this case, the computer device 200 may provide the contract address to the 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 signed data in the root chain with the contract address stored in the database of the root chain.

18 is a flowchart illustrating a fourth 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. For example, the processor 220 of the computer device 200 may be implemented to execute a control instruction according to a code of an operating system included in the memory 210 or a code of at least one program. Here, the processor 220 causes 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 the code stored in the computer device 200 . can control

In step 1810, the computer device 200 may encrypt and store the private key of the node of the blockchain network. Here, a node may be a node that is initially created in a blockchain network, and a signable contract may be automatically installed in the process of installing the system contract of the blockchain network in such a node. In this process, the node's private key can be delivered to the signable contract. In this case, the signable contract may encrypt and store the private key of the node delivered during the installation process.

In operation 1820, 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 in the process of encrypting the private key. For example, when the private key is encrypted with a symmetric key, the symmetric key or a value for obtaining the symmetric key may be generated as a password.

In operation 1830, the computer device 200 may return a password encrypted with the public key of the node to the node. In this case, the node can obtain an encrypted password. At this time, since the encrypted password is encrypted with the public key of the node, the password can be obtained by decrypting the encrypted password with the private key of the node. On the other hand, other nodes in the blockchain network can find the node that has returned the encrypted password, send the public key of the other node to the node, receive the password encrypted with the public key of the other node from the node, and store it in the other node. . Through this process, other nodes in the blockchain network will also be able to obtain a password to decrypt the encrypted private key. On the other hand, the private key itself may not be exposed because it is stored in an encrypted state. On the other hand, a password can be defined as a secure type that is not stored in any of the blocks or logs of the blockchain network.

In step 1840, the computer device 200 may receive a signature request including data for signing with a password and a private key as parameters from any 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.

In operation 1850, in response to the signature request, the computer device 200 may decrypt the encrypted private key through the password, and may generate signed data by signing the data with the decrypted private key.

In step 1860, the computer device 200 may return the signed data. In this case, the signed data may be returned to the node that requested the signature of the data.

In one embodiment, the blockchain network may include a root chain that manages data transfer between a plurality of leaf chains. In this case, 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 was 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.

In another embodiment, the blockchain network may include a first leaf chain among a plurality of leaf chains whose data transmission is managed by a root chain. In this case, the computer device 200 may provide the contract address to the 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 signed data in the root chain with the contract address stored in the database of the root chain. The root chain can be considered as an absolute trust system, as already described.

As described above, according to embodiments of the present invention, it is possible to provide a data authentication method and system for authenticating data generated in a scale-out blockchain by adding a leaf chain based on the root chain.

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. For example, devices and components described in the embodiments may include, 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, may be implemented using one or more general purpose or special purpose computers. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to execution of the software. For convenience of understanding, although one processing device is sometimes described as being used, one of ordinary skill in the art will recognize that the processing device includes a plurality of processing elements and/or a plurality of types of processing elements. It can be seen that can include For example, the processing device may include a plurality of processors or one processor and one controller. Other processing configurations are also possible, such as parallel processors.

The software may comprise a computer program, code, instructions, or a combination of one or more thereof, which configures a processing device to operate as desired or is independently or collectively processed You can command the device. The software and/or data may be any kind of machine, component, physical device, virtual equipment, computer storage medium or apparatus, to be interpreted by or to provide instructions or data to the processing device. may be embodied in The software may be distributed over networked computer systems, and stored or executed in a distributed manner. Software and data may be stored in 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, etc. 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 available to those skilled in the art of computer software. Examples of the computer-readable recording medium 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 floppy disks. - includes magneto-optical media, and hardware devices specially configured to store and carry out program instructions, such as ROM, RAM, flash memory, and the like. Such a recording medium may be various recording means or storage means in the form of a single or a combination of several hardware, and is not limited to a medium directly connected to any computer system, and may exist distributed on a network. Examples of program instructions include not only machine language codes such as those generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like.

Modes for carrying out the invention

As described above, although the embodiments have been described with reference to the limited embodiments and drawings, various modifications and variations are possible for those skilled in the art from the above description. For example, the described techniques are performed in a different order than the described method, and/or the described components of the system, structure, apparatus, circuit, etc. are combined or combined in a different form than the described method, or other components Or substituted or substituted by equivalents may achieve an appropriate result.

Therefore, other implementations, other embodiments, and equivalents to the claims are also within the scope of the following claims.

Claims (20)

In the data authentication method of a computer device operating through a contract of a blockchain network,
receiving an encrypted private key and a public key generated from the private key as parameters by at least one processor included in the computer device;
generating, by the at least one processor, a contract address with the received public key;
storing, by the at least one processor, the encrypted private key and the contract address in a database;
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, by the at least one processor, the generated signed data;
Data authentication method comprising a. According to claim 1,
The data authentication method, characterized in that the password is defined as a secure type that is not stored in any of the blocks or logs of the blockchain network. According to claim 1,
The blockchain network includes a root chain that manages data transfer between a plurality of leaf chains,
The data authentication method is
writing, by the at least one processor, the contract address in a genesis block of each of the plurality of leaf chains;
Data authentication method, characterized in that it further comprises. 4. The method of claim 3,
Comparing the signed data with the contract address recorded in the genesis block of the first leaf chain in the first leaf chain receiving the signed data, verifying that the signed data is sent from the root chain data authentication method. According to claim 1,
The blockchain network includes a first leaf chain among a plurality of leaf chains whose data transmission is managed by a root chain,
The data authentication method is
providing, by the at least one processor, the contract address to the root chain so that the contract address is stored in a database of the root chain;
Data authentication method, characterized in that it further comprises. 6. The method of claim 5,
and verifying that the signed data is sent from the first leaf chain by comparing the signed data in the root chain with the contract address stored in a database of the root chain. According to claim 1,
A data authentication method, characterized in that the block in which the signed data is recorded is added to the chain of the blockchain network. In the data authentication method of a computer device operating through a contract of a blockchain network,
encrypting and storing, by at least one processor included in the computer device, the private key of the node of the blockchain network;
encrypting and storing, by the at least one processor, a password for decrypting the encrypted private key with the public key of the node;
returning, by the at least one processor, a 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 as parameters from any node of the blockchain network;
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, by the at least one processor, the signed data;
Data authentication method comprising a. 9. The method of claim 8,
The node is the first node created in the blockchain network, and installs a signable contract in the process of installing the system contract of the blockchain network,
The data authentication method is characterized in that the data authentication method is performed by a computer device operating through the signable contract. 9. The method of claim 8,
The data authentication method, characterized in that the password is defined as a secure type that is not stored in any of the blocks or logs of the blockchain network. 9. The method of claim 8,
The blockchain network includes a root chain that manages data transfer between a plurality of leaf chains,
The data authentication method is
writing, by the at least one processor, the contract address in a genesis block of each of the plurality of leaf chains;
Data authentication method, characterized in that it further comprises. 12. The method of claim 11,
Comparing the signed data with the contract address recorded in the genesis block of the first leaf chain in the first leaf chain receiving the signed data, verifying that the signed data is sent from the root chain data authentication method. 9. The method of claim 8,
The blockchain network includes a first leaf chain among a plurality of leaf chains whose data transmission is managed by a root chain,
The data authentication method is
providing, by the at least one processor, the contract address to the root chain so that the contract address is stored in a database of the root chain;
Data authentication method, characterized in that it further comprises. 14. The method of claim 13,
and verifying that the signed data is sent from the first leaf chain by comparing the signed data in the root chain with the contract address stored in a database of the root chain. 9. The method of claim 8,
The other node of the blockchain network finds the node to which the encrypted password is returned, transmits the public key of the other node to the node, receives the password encrypted with the public key of the other node from the node, and sends the password to the other node. Data authentication method, characterized in that the storage. 9. The method of claim 8,
Renewing a password for decrypting the private key periodically or according to a request from an administrator;
A data authentication method further comprising a. A computer program stored in a computer-readable recording medium in combination with a computer device to cause the computer device to execute the method of any one of claims 1 to 16. 17. A computer-readable recording medium, characterized in that a computer program for executing the method of any one of claims 1 to 16 in a computer device is recorded. In a computer device operating through a contract of a blockchain network,
at least one processor implemented to execute instructions readable by the computer device
including,
by the at least one processor,
Receive an encrypted private key and a public key generated with the private key as parameters,
Create a contract address with the received public key,
Storing the encrypted private key and the contract address in a database,
receiving a signature request including data to be signed and a password for decrypting the encrypted private key as parameters;
Decrypting the encrypted private key using the password and signing the data with the decrypted private key to generate signed data,
returning the generated signed data
A computer device characterized by a. In a computer device operating through a contract of a blockchain network,
at least one processor implemented to execute instructions readable by the computer device
including,
by the at least one processor,
Encrypt and store the private key of the node of the blockchain network,
encrypting and storing the password for decrypting the encrypted private key with the public key of the node;
returning a password encrypted with the public key of the node to the node;
receiving a signature request from any node of the blockchain network including data for signing with the password and the private key as parameters;
decrypting the encrypted private key through the password in response to the signing request, and signing the data with the decrypted private key to generate signed data;
returning the signed data
A computer device characterized by a.

Images