KR102572834B1 - Method and system for authenticating data generated in a blockchain using a signable contract - Google Patents

Abstract

Provides a method and system for authenticating data generated in a blockchain. In the embodiments of the present invention, a method for authenticating data of a node implemented as a computer device participating in a blockchain network provides a private key representing a chain of the blockchain network to at least one member participating in the blockchain network. Sharing with one other node, generating a public address of the blockchain network using the private key, and transferring data to be transferred from the blockchain network to another blockchain network through a contract installed in the blockchain network. Signing with the private key and transferring the signed data to another blockchain network through the 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.

Description

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

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

A block-chain is an electronic ledger, 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 transfer of control of a digital asset between participants in a blockchain system, and includes at least one input and at least one output. Each block contains a hash of the previous block, so that those blocks are chained together to create a permanent, unalterable record of all transactions recorded on the blockchain from the beginning. For example, Korea Patent Publication No. 10-2018-0113143 discloses a blockchain-based user-defined currency trading system and its operation method. These blockchains themselves do not scale out. For example, adding a node to generate a block in a blockchain network only increases the cost of consensus for generating a block, but does not increase the speed of generating a block for a transaction.

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

A data authentication method of a computer device operating through a contract of a blockchain network, wherein an encrypted private key and a public key generated with the private key are received as parameters by at least one processor included in the computer device doing; 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 signing request including data to be signed and a password for decrypting the encrypted private key as parameters; generating, by the at least one processor, 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; and returning the generated signed data by the at least one processor.

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 that manages data transfer between a plurality of leaf chains, and the method of authenticating data includes the at least one processor converting the contract address to the plurality of leaf chains. It may be characterized in that it further comprises the step of recording in each genesis block.

According to another aspect, the signed data in the first leaf chain receiving the signed data is compared with the contract address recorded in the genesis block of the first leaf chain, and 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 is performed by the at least one processor, It may be characterized by further comprising providing the contract address to the root chain so that the address is stored in the database of the root chain.

According to another aspect, it may be characterized in that the signed data in the root chain is compared with the contract address stored in the database of the root chain to verify 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, 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 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 signing request including, as parameters, data for signing with the password and the private key from any node of the blockchain network; generating, by the at least one processor, the signed data by decrypting the encrypted private key using the password and signing the data with the decrypted private key in response to the signing request; and returning the signed data by the at least one processor.

A computer program stored in a computer readable recording medium is provided in combination with a computer device to execute 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, including at least one processor implemented to execute instructions readable by the computer device, and comprising a private key encrypted by the at least one processor and a public key generated with the private key as a parameter, generating a contract address with the received public key, storing the encrypted private key and the contract address in a database, and decrypting the data to be signed and the encrypted private key Receiving a signing request including a password as a parameter, decrypting the encrypted private key using the password, signing the data with the decrypted private key to generate signed data, and generating signed data It provides a computer device characterized in that it returns.

A computer device that operates through a contract of a blockchain network, including at least one processor implemented to execute instructions readable by the computer device, and by the at least one processor, private information of a 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, and any Receives a signing request including the password and data for signing with the private key as parameters from a node, and in response to the signing request, decrypts the encrypted private key using the password, and uses the decrypted private key to decrypt the data It provides a computer device characterized in that generating signed data by signing, and returning 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 scalable 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 one embodiment of the present invention.
3 is a diagram showing an example of a general configuration of an expandable blockchain network according to an embodiment of the present invention.
4 is a diagram showing 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 showing the flow of coin exchange data through a smart contract between each chain in one embodiment of the present invention.
10 is a diagram showing 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 showing another example of a process of installing 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, an embodiment will be described in detail with reference to the accompanying drawings.

A data authentication system according to embodiments of the present invention 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 the 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 the form of an independent program package, or may have a form in which the form of an independent program package is pre-installed in a computer device and linked with an 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 , and 140 , a plurality of servers 150 and 160 , and a network 170 . 1 is an example for explanation of the invention, and the number of electronic devices or servers is not limited as shown 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 fixed terminals implemented as computer devices or mobile terminals. Examples of the plurality of electronic devices 110, 120, 130, and 140 include a smart phone, a mobile phone, a navigation device, a computer, a laptop computer, a digital broadcast terminal, a personal digital assistant (PDA), and a portable multimedia player (PMP). ), and tablet PCs. As an example, FIG. 1 shows the shape of a smartphone as an example of electronic device 1 110, but in embodiments of the present invention, electronic device 1 110 substantially uses a wireless or wired communication method to establish a network 170. It may refer to one of various physical computer devices capable of communicating with other electronic devices 120 , 130 , and 140 and/or servers 150 and 160 through the Internet.

The communication method is not limited, and short-distance wireless communication between devices as well as a communication method utilizing a communication network (eg, a mobile communication network, a wired Internet, a wireless Internet, and a broadcasting network) that the network 170 may include may also 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). , one or more arbitrary networks such as the Internet. In addition, the network 170 may include any one or more of network topologies including a bus network, a star network, a ring network, a mesh network, a star-bus network, a tree or a hierarchical network, and the like. Not limited.

Each of the servers 150 and 160 communicates with the plurality of electronic devices 110, 120, 130, and 140 through the network 170 to provide commands, codes, files, contents, services, and the like, or a computer device or a plurality of computers. It can be implemented in devices. For example, the server 150 provides a service (eg, video call service, financial service, payment service, social network service) to a plurality of electronic devices 110, 120, 130, and 140 accessed through the network 170. , messaging service, search service, mail service, content providing service, and/or question and answer service).

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

At this time, 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-perishable 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, 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 . 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, software components may be loaded into the memory 210 through the communication interface 230 rather than a computer-readable recording medium. For example, software components may be loaded into memory 210 of computer device 200 based on a computer program installed by files received over network 170 .

The processor 220 may be configured to process commands of a computer program by performing basic arithmetic, logic, and input/output operations. Instructions may be provided to processor 220 by memory 210 or communication interface 230 . For example, processor 220 may be configured to execute received instructions according to program codes stored in a recording device such as 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, a request, command, data, file, etc. generated according to a program code stored in a recording device such as the memory 210 by the processor 220 of the computer device 200 is controlled by the communication interface 230 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 . Signals, commands, data, etc. received through the communication interface 230 may be transferred to the processor 220 or the memory 210, and files, etc. may be stored as storage media that the computer device 200 may further include (described above). permanent storage).

The input/output interface 240 may be a means for interface with the input/output device 250 . For example, the input device may include devices such as a microphone, keyboard, camera, or mouse, and the output device may include devices such as a display and a speaker. As another example, the input/output interface 240 may be a means for 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 and the computer device 200 may be configured as one device.

Also, in other embodiments, computer device 200 may include fewer or more elements 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 some of the aforementioned input/output devices 250 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 blockchain network 300 including Root Chain 310, Leaf Chain A 320, Leaf Chain B 330, and Relayer 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 relayer 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 trusted 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, three or more leaf chains may be included, which may mean that the block chain can be extended. 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 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 recording the hash of the block in the root chain 310. As an example, a merkle tree root hash may be utilized.

In the root chain 310, coin exchange between users is not performed, and coin exchange may be performed within each of the leaf chains 320 and 330 and/or between the leaf chains 320 and 330. At this time, the coin exchange between the leaf chains 320 and 330 can 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 decentralized application (DApp) refers to an application whose backend code runs on a decentralized peer-to-peer network (or calls and registers data to a blockchain database) and provides it as an interface on the frontend. At this time, each of the leaf chains 320 and 330 can install a chain and a smart contract unrelated to coin exchange according to the needs of the DApp, which may not be involved in the root chain 310. In each of the leaf chains 320 and 330, if you want to install a smart contract having a protocol for coin exchange between the chains, you must obtain permission for installing the smart contract 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 going through the root chain 310, and a summary of all blocks including the processed contents. Information (eg, the aforementioned Merkle tree root hash) may be recorded in the root chain 310 . On the other hand, coin exchange between the leaf chains 320 and 330 must be performed through the root chain 310, and each block of the leaf chains 320 and 330 and the block of the root chain 310 are related to the process of coin exchange. content should be recorded. At this time, coin exchange between the leaf chains 320 and 330 may be performed through the relayer 340.

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

The root chain 310 may include a root chain manager contract (411), which is a smart contract for the root chain 310, and several leaf chains 320 and 330 included in the blockchain network 300 You can include a smart contract for each. In the embodiment of FIG. 4 , the root chain 310 is a smart contract for Leaf Chain A (Leaf Chain A, 320), Leaf Chain A Contract (412) and Leaf Chain B (Leaf Chain B, 330). It shows 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 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) has a leaf chain manager contract (422), which is a smart contract for leaf chain A (320), 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 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 may include Producer (441), Kafka (442), InterChain Consumer (443), InterChain Failover (444), and Database (Database, 445). can

The producer 441 may collect information on newly created blocks of all chains including the root chain 310 and input the information to the Kafka 442. Kafka 442, as a kind of queue server, can store collected information in a queue and provide them sequentially. At this time, the interchain consumer 443 may filter events requiring an invoke for each chain. Depending on the event, multiple filtering may be required. When 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 can detect the following events (1) to (7).

(1) Remittance request event in Leaf Chain

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

(2) Remittance request event in root chain

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

(2-2) When the interchain consumer 443 fails to deliver to the receiving leaf chain, it can deliver the remittance failure information including the identification information of the leaf chain to receive the remittance request to the root chain.

(3) Remittance request failure event in root chain

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

(4) Remittance completion event in Leaf Chain

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

(5) Remittance completion event in root chain

(5-1) The interchain consumer 443 can deliver the transfer completion information to the leaf chain that requested the transfer.

(6) Coin issuance event in root chain

(6-1) The interchain consumer 443 can deliver the issuance details to the leaf chain where the coin is issued.

(7) Block creation event in leaf chain

(7-1) The interchain consumer 443 may deliver the merkle tree root hash of the block to the root chain.

Interchain failover 444 may provide failover capability so that (3-1), (4-1), (5-1), (6-1) and (7-1) can be forwarded normally. The database 445 may be used 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, new leaf chains 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 in the leaf chain to be in charge of coin remittance between chains or between contracts.

In step 530, the blockchain network 300 may install a contract capable of processing the corresponding leaf chain (hereinafter referred to as a 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 Signing Enable Contract of the leaf chain may be further registered in the root chain manager contract. In another embodiment, a public address representing a leaf chain may be registered in the root chain manager contract.

In step 550, the blockchain network 300 may add accessible relay users to the leaf chain contract of the root chain.

In step 560, the blockchain network 300 may add accessible relay users to the leaf chain manager contract of the leaf chain.

At this time, the relay user of steps 550 and 560 may be the same user or different users. It may be advantageous in terms of security to set up and utilize separate relayer users for each leaf chain and for each root chain. Here, the relayer user may correspond to an account of a 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 service in the leaf chain. The address of the installed contract can be used as a value to identify 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 to be in charge of coin remittance between chains or between contracts can be installed in a leaf chain. The address of the contract for the 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. At this time, the address of the installed contract can be registered through the manager authority of the root chain manager contract. If the root chain manager contract registers the address of the contract installed for the leaf chain service along with the leaf chain contract of the corresponding leaf chain installed in the root chain, the address of the contract installed for the service of the leaf chain is also registered in the leaf chain contract of the root chain. It can be registered as a service of the 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 address of the contract for the service for issuing coins through the leaf chain contract installed in the root chain, and the coin issuing event for the identified service. can cause

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

In step 730, the leaf chain manager contract can issue coins by finding the corresponding service. At this time, the coin can be issued to the service operator (for example, the relayer user added in step 560 of FIG. 5) entered 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 of the same chain can be done through a smart contract for coin exchange of the leaf chain. In addition, coin exchange between other services of the same chain can be made through the leaf chain manager contract of the corresponding leaf chain. For example, remittance from the first service to the second service in the same chain can be performed by the leaf chain manager contract calling the address of the contract of the second service according to the request for remittance of the first service. At this time, when a coin is exchanged between other services of the same leaf chain, the coin exchange result can be delivered to the root chain. This is so that the root chain can grasp 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 performed through the following steps (810 to 890). 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 (transfer request) for user b of leaf chain B 330 of user a. At this time, the leaf chain A 320 may determine the user a's balance and record it in a block of the leaf chain A 320 if the coin exchange request is a normal request. The coin requested for exchange (coin requested for remittance) can be deducted from the balance of user a by the leaf chain manager contract included in leaf chain A 320, and can be locked so that it is not used. For example, the leaf chain manager contract of leaf chain A (320) checks the balance of user a and the balance of the service requesting remittance as much as the amount requested for 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 about the deducted amount of user a can 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, 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 leaf chain A 320 to leaf chain B 330 and transmit the remittance request to the root chain 310. The detection of the remittance request event can be detected by the transaction collection of the producer 441, and the interchain consumer 443 can deliver 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 leaf chain A 320 using the remittance request information to determine whether the remittance request is a normal request, and confirms that the remittance request is a normal request. If , a coin exchange request from leaf chain A (320) to leaf chain B (330) may be recorded in a block. The exchange request may be locked so that it is not used as much as the amount of coins to be transferred. In addition, the root chain 310 may record the failure details in the block when the corresponding remittance request is not a normal request. The remittance request recorded as failed can be detected as a remittance failure event in the interchain consumer 443 and forwarded to the leaf chain A 320, and the leaf chain A 320 receiving the remittance failure event returns the locked coin. You can release it and give it back 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 invoke fails because the leaf chain B 330 does not operate normally, the delivery failure due to the system failure of the leaf chain B 330 may be transmitted to the root chain 310 again. The request recorded as failed can be detected as a remittance failure event by the interchain consumer 443 and forwarded to leaf chain A 320, and the leaf chain A 320 receiving the remittance failure event unlocks the locked coin. It can be returned to user a again.

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

In step 860, the interchain consumer 443 can detect the completion result of the transfer of leaf chain B as an event and deliver the hash and success to the root chain 310.

In step 870, the root chain 310 may receive the remittance result, process it according to remittance failure and remittance success, and record the result in a block together with the hash. If the remittance is successful, the root chain 310 can release the locked coin remittance request, proceed with remittance from leaf chain A 320 to leaf chain B 330, and change the amount of each currency. If the transfer fails, the root chain 310 can release the locked coin transfer request and return it to the leaf chain A 320.

In step 880, the interchain consumer 443 can 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 receives the remittance result and, if successful, unlocks the locked coin to adjust the total currency amount of the leaf chain A 320 (deducting the total amount of currency from the remittance amount). If the remittance fails, leaf chain A 320 can release the locked coin and return it to user a. Leaf chain A (320) can record the remittance result in a block together with the hash recorded in the root chain (310).

9 is a diagram showing the flow of coin exchange data through a smart contract between each chain in one 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 request an exchange to Leaf Chain Manager Contract A (910) . The 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 transfer, service b (identifier of) receiving remittance, and user b (identifier of), amount information (transfer amount) and/or request time (create transfer request record (escrow information)). At this time, the leaf chain manager contract A (910) can subtract the total currency amount of the contract of DApp 1 (920) and the amount of user a.

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

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

(4) The producer 441 can collect the transaction generated in (3), and the interchain consumer 443 sends the transaction to the leaf chain manager contract B 940 of the leaf chain B 330 with the service for receiving remittance. You can request a remittance.

(5) Leaf chain manager contract B (940) of leaf chain B (330) can call Dapp 3 (950), which is the service to be remitted, and make the transfer to user b in the contract of Dapp 3 (950). At this time, the contract of DApp 3 (950) can also increase the total amount of currency in 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 bring the escrow (transfer request record) information of the corresponding remittance request to the root chain manager contract 411 and process the remittance completion. If the remittance is successful, the total amount of currency in Leaf Chain B (330) can be increased by the remittance amount in DApp 3 (950) managed by Leaf Chain B contract (413), and the root chain manager contract of Root Chain (310) In (411), the transfer request record may be deleted. If the remittance fails, the total amount of currency in Leaf Chain A (320) can be increased again by the remittance amount to DApp 1 (920), which is the service that requested the remittance registered in the Leaf Chain A contract (412), and then the Root Chain (310) The corresponding remittance request record can be deleted from the root chain manager contract 411 of ).

(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 corresponding request from the remittance request record (escrow). If the remittance fails, the leaf chain manager contract A (910) can return the amount in the remittance request record (escrow) to user a, and the total amount of currency in DApp 1 (920) is increased again by the remittance amount before remittance You can delete the request from the request history (escrow).

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

When data is transmitted between chains in such a blockchain network 300, there is a possibility that the data to be transmitted is tampered with in the transmission system. For example, when data is transmitted 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 relayer is implemented for each leaf chain in order to expand leaf chains in the form of a public blockchain, there is a need to reduce dependence on such a relayer 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 must be possible. Here, the base coin may mean a coin used in a unique coin system of the blockchain network 300.

2. The root chain must be able to manage the base coins of all chains. At this time, management of base coin may include transfer of base coin between chains.

3. It is necessary to prevent the relayer from falsifying and transmitting data.

4. Remittance received from the leaf chain and remittance to the user was successful, but it is necessary to prevent double payment by delivering a failure message.

5. Remittance between chains should be done quickly without confirmation of the user receiving the base coin in the remittance.

For this requirement, in the root chain, mint and burn of base coins can occur through authorized users. Alternatively, authorized users can issue or burn base coins by receiving confirmation with a multisig-wallet. At this time, in the leaf chain, issuance can be executed when a coin issuance request is received from the root chain. In addition, when transferring money from a 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 the two leaf chains. For example, a leaf chain that sends base coins can burn the base coin, and a leaf chain that receives base coins can issue the base coin.

Meanwhile, in order to prevent the relayer from tampering with data, it is necessary to ensure that data to be transmitted cannot be tampered with. Hereinafter, methods for blocking data modulation will be described.

In the first method, the original data to be delivered can be signed. If the from user who transmits 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 can be created with its own private key, and a public key corresponding to the private key can be disclosed. At this time, the contract can sign the information that needs to be delivered to other chains and record it as an event, thus proving that the original data has been processed by the contract. For example, a contract can sign original data and its own contract address with the contract's private key. In this case, any user can verify the signed original data using the public key corresponding to the private key of the contract, and can access the contract through the contract address of the contract uniquely generated in every chain. It can be proven that the data was transmitted by However, in the first method, the private key of the contract must be stored in the database of the contract, and since the database is shared and opened in the blockchain network, the private key is shared with all nodes in the chain, so it is no longer a private key. .

In the second method, instead of storing the private key in a contract, the private key representing one chain is shared with C-nodes, which are nodes that form a consensus within the same chain, and used when chain authentication is required. can do For example, in each chain, n (eg, n is 4 to 8) C-nodes for consensus can share and maintain a private key. A user or other contract can request the system for that chain (eg, a system contract installed on that chain) to sign data, and the system can sign the requested data and provide the signed data. At this time, the contract of the corresponding chain can record the event of data signing and delivery, and can deliver the signed data to another chain through the relayer. For example, the public address, which is an identification value created through the public key paired with the private key of the root chain in the root chain, cannot be tampered with in the leaf chain as it is recorded in the leaf chain's genesis block. Data signed with the private key through the root chain can be compared with the public address recorded in the genesis block in the leaf chain to verify that the signed data was sent from the loop chain. Similarly, the leaf chain can also register the public address created with the private key of the leaf chain in the leaf chain contract installed in association with the corresponding 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 private key of the leaf chain through the leaf chain with the public address registered in the corresponding leaf chain contract. However, the second method can be used in private blockchains where private keys can be shared among C-nodes for consensus, but cannot be used in public blockchains (public leaf chains) that are open to provide external services. .

The third method is to use the unique private key that each C-node in the root chain has for consensus. As an example, if the root chain contains 8 C-nodes, there may be 8 private keys. In this case, 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. At this time, the data that needs to be verified as being generated in the root chain can be recorded in a block by being signed by the leader node of the root chain with its private key, and the data can be transmitted to the leaf chain. Here, the leader node may be a node randomly selected 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 explained above, since the leaf chain knows the public addresses of all C-nodes in the root chain, the public address obtained when verifying the signed data is one of the known public addresses of the C-nodes in the root chain. By verifying whether or not, the signed data can be verified. However, the number of C-nodes included in the loop chain is disclosed, and if 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, 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 renewal of public address). information must be announced). Similarly, C-nodes in a leaf chain can also have their own private key for consensus, and this private key can be utilized. In this case, the public addresses of each of the C-nodes can be registered in the leaf chain contract installed in the root chain in relation to the leaf 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, which is created by combining public addresses generated by all C-nodes of the root chain, with all leaf chains. Even in this case, if a change occurs, such as adding or deleting a C-node to the loop chain, the information recorded in each leaf chain must be updated, but the public address to be shared by each leaf chain 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, security must be taken care of when changing it. In the fourth method, each of the public addresses of all C-nodes in the root chain must be known by all C-nodes. In addition, 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 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 a contract address with the public key, encrypt the private key, and store it in the contract. The private key is known, the public key can be obtained through the private key, and the contract address can be created through the public key. At this time, only one contract for signing (hereinafter referred to as a Signing Enable Contract) may exist in one chain. For example, when deploying a signable contract, an encrypted private key and a public key generated with the private key can be passed as parameters to the signable contract. A signable contract can generate a contract address with the received public key. At this time, if there is the same contract address, creation of the contract address may fail. The encrypted private key can be decrypted through a password that will be described later, and can be stored in a database by a signable contract. At this time, when an arbitrary contract wants to sign data, it can pass the data to be signed and a password that can decrypt the encrypted private key stored in the signable contract to the signable contract as a parameter. At this time, information according to all requests in the blockchain (for example, requests using HTTPS (Hypertext Transfer Protocol Secure)) are recorded in blocks or logs, while passwords should not be stored/recorded anywhere. Therefore, in the fifth method, the password parameter can be defined as a type that is not stored/recorded anywhere, such as a block or log (hereinafter referred to as 'secure type'). These password parameters can be supported in the corresponding blockchain. In this case, the signable contract can sign the input data using the restored private key after restoring the encrypted private key through the password, and returns the signed result (signed data) to the contract that requested signing. 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 used in the system, and the encrypted private key and public key must be generated and provided outside the system. Since the private key is encrypted and transmitted, the private key is normally generated and transmitted. Can't confirm if it does or not. 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 signing contract is a contract on the root chain. If it is proven that the contract exists in , it can be proven that the signed data is data created or processed in the root chain.

10 is a diagram showing an example of an installation process of a signable contract according to an embodiment of the present invention. 10 shows that the signable contract 1010 receives the encrypted private key 1020 and public key 1030 as parameters, uses the received public key 1030 to generate a public address, and stores it in the database 1040. shows an example. In other words, the database 1040 may store an encrypted private key 1020, a 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 a signable contract 1010 receives a signature request from a user or another contract 1110. At this time, the signing 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 obtain a private key by decrypting the encrypted private key 1020 using a password, and may sign data transmitted as a parameter using the decrypted private key. Then, the signable contract 1010 can return the signed data to the user or other contract 1110 as a result. Here, the user can correspond to the node of the blockchain.

In the sixth method, the signable contract of the fifth method can be automatically installed as a system contract of 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 can be encrypted through a signable contract and stored in a database, and the password to decrypt the encrypted private key can be encrypted with the public key of the corresponding node and stored locally in the corresponding node. Other nodes can replicate the transaction and retrieve nodes that know the latest password. At this time, the other node may transmit its own public key to the node to be searched for, receive a 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 own public key, and can 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. A signable contract can be used to prove that data is transmitted from the root chain.

12 is a diagram showing another example of a process of installing a signable contract according to an embodiment of the present invention. 12 shows an example in which a private key generated by a node is encrypted by a signature capable contract 1210 with a public key 1220 of the node and stored in a database 1230. At this time, 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 illustrates 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 signing of data. . Here, the system 1320 may correspond to a blockchain system. At this time, data to be signed may also be transmitted to the system 1320 as a parameter. In this case, the system 1320 may request signing of data with the signable contract 1210 using the password. In this case, the signable contract 1210 can decrypt the encrypted private key through the password, sign data using the decrypted private key, and then return the signed data. System 1320 may forward the returned signed data to node 1310 .

On the other hand, it is necessary to ensure that the content processed internally in the leaf chain and the content transmitted are not different. To this end, it is necessary to transmit the proof hash list of the merkle tree of the transaction that processed the remittance through an event along with the processing result. If there is an observer, it is necessary to determine whether or not proof information of the Merkle tree should be delivered. The event information to be delivered can be signed with the private key of the contract 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 transaction has been tampered with, so an observer may be required. At this time, the supervisor can check whether the corresponding block exists and whether the remittance is successful or unsuccessful, such as the data transmitted by the corresponding transaction as an event. If irregularities are discovered by the watcher, the corresponding leaf chain may be penalized. Here, the watcher can be implemented in the form of a node that executes the above functions.

14 is a diagram showing another example of a coin exchange method according to an embodiment of the present invention. Coin exchange in the same service of the same chain or coin exchange between different services of the same chain has also been described through the embodiment of FIG. 8 . 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. Assume that user 2 of 2 (1430) requests remittance.

Process 1 may be an example of a process in which leaf chain 1 (1420) checks whether the remittance request is a normal request and then transfers information about the remittance request to the root chain (1410) if there is no problem.

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

Process 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 receivable in leaf chain 2 (1430).

Process 4 may be an example of a process in which the root chain 1410 issues a receipt for deducting or increasing a remittance amount to leaf chain 1 1420 and leaf chain 2 1430, respectively. Process 4.1 may be an example of a process in which the root chain 1410 issues a receipt for deduction of the remittance amount to the leaf chain 1 (1420), and process 4.2 increases the remittance amount by the root chain 1410 to the leaf chain 2 (1430). It may be an example of a process of issuing a receipt for In each chain, management can be made to prevent overlapping deductions or overlapping increases.

The following describes the configuration of smart contracts.

In the case of the root chain, the smart contract may include the root chain manager contract as described above with reference to FIG. 4, and may include contracts for each leaf chain. Meanwhile, 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 forward them to each chain. Each chain can be managed so that relayers cannot tamper with the data. As already explained, 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 unique private key of the root chain when creating the genesis block. All information to be delivered by the relayer can be 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 that defines the "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 making the remittance

Origin: Service requested for remittance or leaf chain

to user: the user receiving the remittance

Destination: service or leaf chain receiving remittance

value: remittance amount (base coin)

eTxHash: remittance transaction hash (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 this 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 an operating system code or at least one program code included in the memory 210 . Here, the processor 220 controls the computer device 200 so that the computer device 200 performs the steps 1510 to 1540 included in the method of FIG. 15 according to a control command provided by a code stored in the computer device 200. can control.

In step 1510, the computer device 200 may share a private key representing a chain of the blockchain network with at least one other node participating in consensus in the blockchain network. At this time, 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 in which C-nodes of the corresponding chain share one private key representing the chain in the second method described above and use it for chain authentication. In other words, 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.

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

In one embodiment, a blockchain network may include a root chain that manages data transmission 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 with the public address recorded in the leaf chain's genesis block.

In another embodiment, a 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 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.

In step 1530, the computer device 200 may sign data to be transferred from a blockchain network to another blockchain network with a private key through a contract installed in 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.

In step 1540, the computer device 200 may transfer 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 this 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 an operating system code or at least one program code included in the memory 210 . Here, the processor 220 controls the computer device 200 so that the computer device 200 performs the 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 step 1610, the computer device 200 may generate a public address of the node 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 transferred 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.

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

In one embodiment, a blockchain network may include a root chain that manages data transfer between multiple leaf chains. At this time, the public address generated at each of a plurality of nodes (a plurality of nodes including a node implemented by the computer device 200 in this embodiment) preset to form a consensus in the blockchain network is a plurality of leaves. may 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 signed data in the first leaf chain that has received the signed data with the public address of each of the plurality of nodes stored in the first leaf chain.

In another embodiment, a blockchain network may include a first leaf chain of a plurality of leaf chains whose data transmission is managed by a root chain. At this time, the public address generated in each of a plurality of nodes (including a node implemented by the computer device 200 in this embodiment) preset to achieve an agreement 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.

In another embodiment, a blockchain network may include a root chain that manages data transfer between multiple leaf chains. At this time, a representative public generated by a combination of public addresses generated at 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 an agreement 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 data signed in the first leaf chain that received the signed data with the representative public address stored in the first leaf chain.

In another embodiment, a blockchain network may include a first leaf chain of a plurality of leaf chains whose data transmission is managed by a root chain. At this time, a representative public generated by a combination of public addresses generated at 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 an agreement in the blockchain network The address can 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 is 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.

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 this embodiment may be performed by the computer device 200 operating through a contract of a blockchain network. For example, the processor 220 of the computer device 200 may be implemented to execute a control instruction according to an operating system code or at least one program code included in the memory 210 . Here, the processor 220 controls the computer device 200 so that the computer device 200 performs steps 1710 to 1760 included in the method of FIG. 17 according to a control command provided by a 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 a blockchain network.

In step 1710, the computer device 200 may receive an encrypted private key and a public key generated with 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 contract address in a database.

In step 1740, the computer device 200 may receive a signing 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 step 1750, the computer device 200 may decrypt the encrypted private key through the password in response to the signing request, and sign data with the decrypted private key to generate signed data. At this time, the block in which the signed data is recorded can be added to the chain of the blockchain network.

In step 1760, the computer device 200 may return the generated signed data. At this time, the signed data may be returned to the node requesting data signature.

In one embodiment, a blockchain network may include a root chain that manages data transmission between a plurality of leaf chains. At this time, 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, a blockchain network may include a first leaf chain of a plurality of leaf chains whose data transmission is managed by a root chain. At this time, 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 data signed 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 this 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 an operating system code or at least one program code included in the memory 210 . Here, the processor 220 controls the computer device 200 so that the computer device 200 performs 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 control.

In step 1810, the computer device 200 may encrypt and store the private key of the node of the blockchain network. Here, the node may be a node initially created in the 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. During this process, the node's private key can be transferred to a signable contract. At this time, the signable contract can encrypt and store the private key of the node transmitted during the installation process.

In step 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 encrypted private key can be decrypted while the computer device 200 encrypts the private key. For example, when a private key is encrypted with a symmetric key, a symmetric key or a value for obtaining the symmetric key may be generated as a password.

In step 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 the encrypted password. At this time, since the encrypted password is encrypted with the node's public key, the password can be obtained by decrypting the encrypted password with the node's private key. On the other hand, other nodes in the blockchain network find a node that has returned an encrypted password, transmit the public key of another node to that node, receive a password encrypted with the public key of another node from that node, and store it in another node. . Through this process, other nodes in the blockchain network can 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 encrypted. On the other hand, the password can be defined as a secure type that is not stored in any block or log of the blockchain network.

In step 1840, the computer device 200 may receive a signing request including data for signing with a password and a private key as parameters from any node of the blockchain network. An arbitrary node may be a node that receives an encrypted password from the computer device 200 or another node that receives a password from the corresponding node.

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

At step 1860, the computer device 200 may return the signed data. At this time, the signed data may be returned to the node requesting data signature.

In one embodiment, a blockchain network may include a root chain that manages data transfer between multiple leaf chains. At this time, 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, a blockchain network may include a first leaf chain of a plurality of leaf chains whose data transmission is managed by a root chain. At this time, 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 data signed 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 explained.

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 a root chain.

The system or device described above may be implemented as a hardware component, a software component, or a combination of hardware components and software components. 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), microprocessor, or any other device capable of executing and responding to instructions. The processing device may run an operating system (OS) and one or more software applications running on the operating system. A processing device may also access, store, manipulate, process, and generate data in response to execution of software. For convenience of understanding, there are cases in which one processing device is used, but those skilled in the art will understand that the processing device includes a plurality of processing elements and/or a plurality of types of processing elements. It can be seen that it can include. For example, a processing device may include a plurality of processors or a processor and a controller. Other processing configurations are also possible, such as parallel processors.

Software may include a computer program, code, instructions, or a combination of one or more of the foregoing, which configures a processing device to operate as desired or processes independently or collectively. You can command the device. Software and/or data may be any tangible machine, component, physical device, virtual equipment, computer storage medium or device, intended to be interpreted by or provide instructions or data to a processing device. can be embodied in Software may be distributed on networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer readable 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 on a computer readable medium. The computer readable medium may include program instructions, data files, data structures, etc. alone or in combination. Program instructions recorded on the medium may be specially designed and configured for the embodiment or may be known and usable to those skilled in the art of 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. - includes hardware devices 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 single or various recording means or storage means in the form of a combination of several hardware, and may be distributed on a network without being limited to a medium directly connected to a certain computer system. Examples of program instructions include high-level language codes that can be executed by a computer using an interpreter, as well as machine language codes such as those produced by a compiler.

Mode for Carrying Out the Invention

As described above, although the embodiments have been described with limited examples and drawings, those skilled in the art can make various modifications and variations from the above description. For example, the described techniques may be performed in an order different from the method described, and/or components of the described system, structure, device, circuit, etc. may be combined or combined in a different form than the method described, or other components may be used. Or even if it is replaced or substituted by equivalents, appropriate results can be achieved.

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

Claims (20)

A 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 with 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 signing request including data to be signed and a password for decrypting the encrypted private key as parameters;
generating, by the at least one processor, 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; 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 transmission between a plurality of leaf chains,
The data authentication method,
Recording, by the at least one processor, the contract address in the genesis block of each of the plurality of leaf chains.
Data authentication method characterized in that it further comprises. According to claim 3,
In the first leaf chain receiving the signed data, the signed data is compared with the contract address recorded in the genesis block of the first leaf chain to verify that the signed data was 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 in which data transmission is managed by a root chain,
The data authentication method,
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. According to 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 the database of the root chain. According to claim 1,
Data authentication method, characterized in that the block in which the signed data is recorded is added to the chain of the blockchain network. A data authentication method of a computer device operating through a contract of a blockchain network,
Encrypting and storing the private key of the node of the blockchain network by at least one processor included in the computer device;
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 signing request including, as parameters, data for signing with the password and the private key from any node of the blockchain network;
generating, by the at least one processor, the signed data by decrypting the encrypted private key using the password and signing the data with the decrypted private key in response to the signing request; and
returning, by the at least one processor, the signed data;
Data authentication method comprising a. According to claim 8,
The node is a node first created in the blockchain network, and a signable contract is installed 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. According to 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. According to claim 8,
The blockchain network includes a root chain that manages data transmission between a plurality of leaf chains,
The data authentication method,
Recording, by the at least one processor, a contract address generated using the public key of the node in the genesis block of each of the plurality of leaf chains.
Data authentication method characterized in that it further comprises. According to claim 11,
In the first leaf chain receiving the signed data, the signed data is compared with the contract address recorded in the genesis block of the first leaf chain to verify that the signed data was sent from the root chain. data authentication method. According to claim 8,
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,
Providing, by the at least one processor, the contract address generated using the public key of the node to the root chain so that the contract address is stored in the database of the root chain.
Data authentication method characterized in that it further comprises. According to 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 the database of the root chain. According to claim 8,
Another node of the blockchain network finds a node that has returned the encrypted password, transmits the public key of the other node to the node, receives a password encrypted with the public key of the other node from the node, and transmits the password to the other node. Data authentication method, characterized in that for storing. According to claim 8,
Renewing a password for decrypting the private key periodically or upon request from an administrator
Data authentication method further comprising a. A computer program stored in a computer readable recording medium to be combined with a computer device to execute the method of any one of claims 1 to 16 on the computer device. A computer readable recording medium characterized in that a computer program for executing the method of any one of claims 1 to 16 is recorded on a computer device. In a computer device that operates 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,
Receives an encrypted private key and a public key generated with the private key as parameters,
Create a contract address with the received public key,
Store the encrypted private key and the contract address in a database,
Receiving a signing 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
Characterized by a computer device. In a computer device that operates 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,
Encrypting and storing the private key of the node of the blockchain network,
Encrypting and storing a 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 signing request including data for signing with the password and the private key as parameters from any node of the blockchain network;
In response to the signing request, the encrypted private key is decrypted using the password, and the data is signed with the decrypted private key to generate signed data;
returning the signed data
Characterized by a computer device.

Images