KR102627868B1 - Method and system for authenticating data generated in blockchain - Google Patents

Abstract

Provides a method and system for authenticating data generated in blockchain. In embodiments of the present invention, the data authentication method of a node implemented by a computer device participating in the blockchain network is to send a private key representing the chain of the blockchain network to at least one participating in the blockchain network. Sharing with one other node, generating a public address of the blockchain network using the private key, sending data to be transferred from the blockchain network to another blockchain network using a contract installed in the blockchain network. It may include signing with the private key and transmitting the signed data to another blockchain network through the contract. At this time, it can be verified that the signed data was sent through the blockchain network through comparison between the signed data and the public address.

Description

Method and system for authenticating data generated in blockchain

The explanation below relates to the method and system for authenticating data generated in blockchain.

Blockchain 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 transfer of control of digital assets between participants within a blockchain system and includes at least one input and at least one output. Each block contains the hash of the previous block, so the blocks are linked together to create a permanent, unalterable record of every transaction recorded on the blockchain in the first place. For example, Korea Patent Publication No. 10-2018-0113143 discloses a blockchain-based custom currency transaction system and its operation method. This blockchain itself does not scale out. For example, adding nodes to generate blocks in a blockchain network only increases the cost of consensus for block creation and does not increase the block generation speed for transactions.

It provides a data authentication method and system that authenticates data generated in a scalable blockchain by adding a leaf chain based on the root chain.

In the data authentication method of a node implemented by a computer device participating in a blockchain network, a private key representing a chain of the blockchain network is entered into the block by at least one processor included in the computer device. sharing with at least one other node participating in the chain network; generating, by the at least one processor, a public address of the blockchain network using the private key; Signing, by the at least one processor, data to be transferred from the blockchain network to another blockchain network with the private key through a contract installed in the blockchain network; and transmitting, by the at least one processor, the signed data to another blockchain network through the contract, wherein the signed data is transmitted to the blockchain through comparison between the signed data and the public address. Provides a data authentication method characterized in that it is verified that it has been sent over a network.

According to one side, the blockchain network includes a root chain that manages data transmission between a plurality of leaf chains, and the data authentication method includes sending the generated public address to the plurality of leaf chains by the at least one processor. It may further include the step of recording in the genesis block of each chain.

According to another aspect, the leaf chain that received the signed data compares the signed data with a public address recorded in the genesis block of the leaf chain to verify that the signed data was sent from the root chain. You can do this.

According to another aspect, the blockchain network includes a first leaf chain among a plurality of leaf chains whose data transmission is managed by a root chain, and the data authentication method is generated by the at least one processor. It may further include the step of registering the public address in the root chain with a leaf chain contract installed in association with the first leaf chain.

According to another aspect, the signed data in the root chain may be compared with a public address registered in the leaf chain contract to verify that the signed data was sent from the first leaf chain.

According to another aspect, the node may be characterized as one of a plurality of nodes preset to achieve consensus in the blockchain network.

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 node implemented by a computer device participating in a blockchain network, comprising: generating a public address of the node using the private key of the node by at least one processor included in the computer device; Signing, by the at least one processor, data to be transferred from the blockchain network to another blockchain network using the private key of the node; and transmitting, by the at least one processor, the signed data to the other blockchain network, wherein the public address is used to verify that the signed data was sent through the blockchain network. Provides a data authentication method characterized by:

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

A computer-readable recording medium is provided, characterized in that a computer program for executing the above method on a computer device is recorded thereon.

A computer device implementing a node of a blockchain network, comprising at least one processor configured to execute instructions readable by the computer device, wherein the at least one processor represents a chain of the blockchain network. Share a private key with at least one other node participating in the blockchain network, use the private key to generate a public address for the blockchain network, and transfer from the blockchain network to another blockchain network. Sign the data to be transmitted with the private key through a contract installed in the blockchain network, transmit the signed data to another blockchain network through the contract, and compare the signed data with the public address to A computer device is provided that verifies that signed data was sent through the blockchain network.

A computer device implementing a node of a blockchain network, comprising at least one processor configured to execute instructions readable by the computer device, wherein the at least one processor uses a private key of the node to Generate a public address of a node, sign data to be transmitted from the blockchain network to another blockchain network using the private key of the node, transmit the signed data to the other blockchain network, and transfer the public address to the other blockchain network. A computer device is provided, wherein it is verified using an address that the signed data was sent through the blockchain network.

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

1 is a diagram illustrating an example of a network environment according to an embodiment of the present invention.
Figure 2 is a block diagram showing an example of a computer device according to an embodiment of the present invention.
Figure 3 is a diagram showing an example of the general configuration of an expandable blockchain network in one embodiment of the present invention.
Figure 4 is a diagram showing an example of the detailed configuration of a transaction processing system according to an embodiment of the present invention.
Figure 5 is a flowchart showing an example of a process for adding a new leaf chain, according to an embodiment of the present invention.
Figure 6 is a flowchart showing an example of a process for adding a new service, according to an embodiment of the present invention.
Figure 7 is a flowchart showing an example of a process for issuing coins to a service in one embodiment of the present invention.
Figure 8 is a flowchart showing an example of a coin exchange process in one embodiment of the present invention.
Figure 9 is a diagram showing the flow of coin exchange data through a smart contract between each chain in an embodiment of the present invention.
Figure 10 is a diagram illustrating an example of the installation process of a signable contract in one embodiment of the present invention.
Figure 11 is a diagram illustrating an example of a process for signing data according to an embodiment of the present invention.
Figure 12 is a diagram illustrating another example of the installation process of a signable contract according to an embodiment of the present invention.
Figure 13 is a diagram illustrating another example of a process for signing data, according to an embodiment of the present invention.
Figure 14 is a diagram showing another example of a coin exchange process in one embodiment of the present invention.
Figure 15 is a flowchart showing a first example of a data authentication method in one embodiment of the present invention.
Figure 16 is a flowchart showing a second example of a data authentication method in one embodiment of the present invention.
Figure 17 is a flowchart showing a third example of a data authentication method in one embodiment of the present invention.
Figure 18 is a flowchart showing a fourth example of a data authentication method in one 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 can be combined with a computer device and stored in a computer-readable recording medium to execute the data authentication method on the computer device. The computer program described here may be in the form of an independent program package, or may be pre-installed on a computer device and linked to 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 in 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. Figure 1 is an example for explaining the invention, and the number of electronic devices or servers is not limited as in Figure 1. In addition, the network environment in FIG. 1 only explains one example of environments applicable to the present embodiments, and the environment applicable to the present embodiments is not limited to the network environment in FIG. 1.

The plurality of electronic devices 110, 120, 130, and 140 may be fixed terminals or mobile terminals implemented as computer devices. Examples of the plurality of electronic devices 110, 120, 130, and 140 include smart phones, mobile phones, navigation devices, computers, laptops, digital broadcasting terminals, PDAs (Personal Digital Assistants), and PMPs (Portable Multimedia Players). ), tablet PC, etc. For example, in Figure 1, the shape of a smartphone is shown as an example of electronic device 1 (110). However, in embodiments of the present invention, electronic device 1 (110) actually connects 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, 160.

The communication method is not limited, and may include not only a communication method utilizing a communication network that the network 170 may include (for example, a mobile communication network, wired Internet, wireless Internet, and a broadcast network), but also short-range wireless communication between devices. 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). , may include one or more arbitrary networks such as the Internet. Additionally, the network 170 may include any one or more of network topologies including a bus network, star network, ring network, mesh network, star-bus network, tree or hierarchical network, etc. Not limited.

Each of the servers 150 and 160 is a computer device or a plurality of computers that communicate with a plurality of electronic devices 110, 120, 130, 140 and a network 170 to provide commands, codes, files, content, services, etc. It can be implemented with devices. For example, the server 150 provides services (e.g., video call service, financial service, payment service, social network service) to a plurality of electronic devices 110, 120, 130, and 140 connected through the network 170. , messaging service, search service, mail service, content provision service, and/or question and answer service, etc.).

Figure 2 is a block diagram showing an example of a computer device according to an embodiment of the present invention. Each of the plurality of electronic devices 110, 120, 130, and 140 described above or each of the servers 150 and 160 may be implemented by the computer device 200 shown in FIG. 2, an embodiment of the present invention. The method according to these may be performed by this 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 non-permanent mass storage device such as random access memory (RAM), read only memory (ROM), and a disk drive. Here, non-perishable large-capacity recording devices such as ROM and disk drives may be included in the computer device 200 as a separate permanent storage device that is distinct from the memory 210. Additionally, an operating system and at least one program code may be stored in the memory 210. These software components may be loaded into the memory 210 from a computer-readable recording medium separate from the memory 210. Such separate computer-readable recording media may include computer-readable recording media such as floppy drives, disks, tapes, DVD/CD-ROM drives, and memory cards. 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 computer programs installed by files received over network 170.

The processor 220 may be configured to process instructions of a computer program by performing basic arithmetic, logic, and input/output operations. Commands may be provided to the processor 220 by the memory 210 or the communication interface 230. For example, processor 220 may be configured to execute received instructions according to program code 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, 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 memory 210 is transmitted to the network ( 170) and can be transmitted to other devices. Conversely, signals, commands, data, files, etc. from other devices may be received by the computer device 200 through the communication interface 230 of the computer device 200 via the network 170. Signals, commands, data, etc. received through the communication interface 230 may be transmitted to the processor 220 or memory 210, and files, etc. may be stored in a storage medium (as described above) that the computer device 200 may further include. It can be stored as a permanent storage device).

The input/output interface 240 may be a means for interfacing with the input/output device 250. For example, input devices may include devices such as a microphone, keyboard, camera, or mouse, and output devices may include devices such as displays and speakers. As another example, the input/output interface 240 may be a means for interfacing with a device that integrates input and output functions, such as a touch screen. The input/output device 250 may be configured as a single device with the computer device 200.

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

Figure 3 is a diagram showing an example of the general configuration of an expandable blockchain network in one embodiment of the present invention. Figure 3 shows a blockchain network 300 including Root Chain (310), Leaf Chain A (320), Leaf Chain B (330), and Relayer (340). It shows an example. 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 trust system. At this time, each of the leaf chains 320 and 330 may be linked to an individual service, and a new leaf chain may be added when a new service is added. In other words, the embodiment of FIG. 3 shows two leaf chains 320 and 330, but it may include three or more leaf chains, which may mean that the blockchain can be expanded. Here, “service” may include online services provided by the same or different entities to their users through a network. For example, multiple leaf chains may be configured corresponding to each of the Internet banking services provided by multiple different banks. Alternatively, a plurality of leaf chains may be configured corresponding to each of a plurality of different social network services. 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 can occur within each of the leaf chains 320 and 330 and/or between the leaf chains 320 and 330. At this time, coin exchange between 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 in 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 smart contract unrelated to the chain and coin exchange depending on the needs of the DApp, and the root chain (310) may not be involved in this. If you wish to install a smart contract with a protocol for exchanging coins between the leaf chains (320 and 330), you must obtain permission to install the smart contract through the root chain (310). Coin exchange between chains using smart contracts without permission from the root chain 310 may be restricted.

Coin exchange within each of the leaf chains 320 and 330 can be processed in each of the leaf chains 320 and 330 without having to go through the root chain 310, and a summary of all blocks containing the processed content Information (for example, the Merkle tree root hash described above) may be recorded in the root chain 310. On the other hand, coin exchange between leaf chains (320 and 330) must be done through the root chain 310, and the processing of coin exchange is required in each block of the leaf chains (320 and 330) and the block of the root chain (310). The contents must be recorded. At this time, coin exchange between leaf chains 320 and 330 may be performed through the relay 340.

Figure 4 is a diagram showing an example of the 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 (RootChainManager 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. A smart contract for each can be included. In the embodiment of Figure 4, the root chain 310 uses LeafChain A Contract (412), which is a smart contract for Leaf Chain A (320), and Leaf Chain B (330). It shows an example including LeafChain B Contract (413), a smart contract for this purpose.

Additionally, each of the leaf chains 320 and 330 may include a smart contract for a dApp. The embodiment of Figure 4 shows an example in which leaf chain A (320) includes a dApp contract (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) has a smart contract for Leaf Chain B (330). It may further include a leaf chain manager contract 432.

The relayer 340 observes the block creation of the root chain 310 and the leaf chains 320 and 330 and records and/or transmits information required to the root chain 310 and the leaf chains 320 and 330. You can invoke . Relayer 340 may include Producer (441), Kafka (442), InterChain Consumer (443), InterChain Failover (444), and Database (445). You can.

The producer 441 can collect information on newly created blocks of all chains including the root chain 310 and input it to Kafka 442. Kafka 442 is a type of queue server that can store collected information in a queue and provide it sequentially. At this time, the interchain consumer 443 can filter events that require invoking for each chain. Depending on the event, multiple filtering may be required. When invoking each chain, the interchain consumer 443 can create a separate user for each chain for signification and record the user's permissions 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 a remittance request event in the leaf chain and transmit the remittance request content to the root chain.

(2) Remittance request event in the root chain

(2-1) The interchain consumer 443 can detect a remittance request event in the root chain and transmit the content of 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 can 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 in the root chain

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

(4) Remittance completion event in Leaf Chain

(4-1) The interchain consumer 443 can transmit the transfer completion information to the root chain.

(5) Remittance completion event in the root chain

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

(6) Coin issuance event in root chain

(6-1) The interchain consumer 443 can transmit 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 can 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 transmitted normally. The database 445 can be used to store information received and/or transmitted (delivered) by the interchain consumer 443 and the interchain failover 444.

Figure 5 is a flow chart illustrating an example of a process for 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 explained later.

In step 520, the blockchain network 300 may install a leaf chain manager contract in the leaf chain to be responsible for inter-chain or inter-contract coin transfer.

In step 530, the blockchain network 300 may install a contract (hereinafter referred to as a leaf chain contract) capable of processing the corresponding leaf chain 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 a leaf chain may be registered in the root chain manager contract.

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

In step 560, the blockchain network 300 can add a relay user who can access the leaf chain manager contract of the leaf chain.

At this time, 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 separate relay users for each leaf chain and the root chain. Here, relay users can respond to accounts for services provided by the blockchain network 300.

Figure 6 is a flowchart showing an example of a process for adding a new service, according to an embodiment of the present invention.

In step 610, the blockchain network 300 may install the contract for the corresponding service on 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 interchain 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 explained that a leaf chain manager contract that will be responsible for inter-chain or inter-contract coin transfer can be installed in the 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 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 address of the contract installed for the service of the leaf chain will also be registered in the leaf chain contract of the root chain. It can be registered as a service of the corresponding leaf chain.

Figure 7 is a flowchart showing an example of a process for issuing coins to a service in one 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 on the root chain. For example, the root chain manager contract on the root chain can identify the service through the address of the contract for the service to issue coins through the leaf chain contract installed on the root chain, and send a coin issuance event for the identified service. can occur.

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

In step 730, the leaf chain manager contract can find the corresponding service and issue coins. At this time, the coin may be issued to the service operator (for example, the relay user added in step 560 of FIG. 5) entered when installing the contract for the corresponding service.

Figure 8 is a flowchart showing an example of a coin exchange process in one 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 corresponding leaf chain. Additionally, coin exchange between other services on the same chain can be done through the leaf chain manager contract of the corresponding leaf chain. For example, remittance from a first service to a second service in the same chain can be accomplished by the leaf chain manager contract calling the address of the contract of the second service according to the remittance request of the first service. At this time, when exchanging coins between other services of the same leaf chain, the coin exchange result can be transmitted to the root chain. This is to allow the root chain to identify changes in the amount of coins held by each service in the leaf chains. On the other hand, coin exchange between different chains can be accomplished through the steps 810 to 890 below. Steps 810 to 890 of FIG. 8 explain 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) from User A. At this time, Leaf Chain A (320) can determine the balance of User A and record it in the block of Leaf Chain A (320) if the coin exchange request is a normal request. Coins requested to be exchanged (coins requested to be transferred) may be deducted from User A's balance by the Leaf Chain Manager Contract included in Leaf Chain A (320) and may be locked so as not to be used. For example, after the Leaf Chain Manager Contract of Leaf Chain A (320) checks the balance of User A and the balance of the service requesting the transfer, 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 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, Leaf Chain A (320) can record the failure of the remittance request in a block. Additionally, Leaf Chain A (320) can prevent a 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 corresponding remittance request to the root chain (310). Detection of a transfer request event may be detected by transaction collection of the producer 441, and the interchain consumer 443 may forward the transfer request to the root chain 310 in response to the detection of the detected transfer request event. .

In step 830, the root chain 310 analyzes the total amount of coins issued by leaf chain A (320) using the transfer request information to determine whether the transfer request is a normal request, and determines whether the transfer request is a normal request. In this case, a coin exchange request from Leaf Chain A (320) to Leaf Chain B (330) can be recorded in the block. Exchange requests can be locked so that they cannot be used equal to the amount of coins being transferred. Additionally, the root chain 310 may record failure information in a block if the transfer request is not a normal request. A remittance request recorded as a failure can be detected again as a remittance failure event by the interchain consumer (443) and transmitted to Leaf Chain A (320), and Leaf Chain A (320), which has received the remittance failure event, can transfer the locked coins. 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 leaf chain B (330) and transmit the corresponding remittance request to leaf chain B (330). If the invoke fails because leaf chain B (330) does not operate normally, the delivery failure details due to a system error in leaf chain B (330) can be transmitted back to the root chain 310. The request recorded as a failure can be detected as a remittance failure event by the interchain consumer (443) and transmitted to Leaf Chain A (320), and Leaf Chain A (320), which has received the remittance failure event, unlocks the locked coins. It can be returned back to user a.

In step 850, if the transfer request is a normal request, Leaf Chain B (330) can transfer coins to User B and increase the total currency volume of Leaf Chain B (330) by the amount of coins sent. If a remittance request fails, the failure can be recorded in the block.

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

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

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

In step 890, Leaf Chain A (320) receives the remittance result and, if successful, releases the locked coins and can adjust the total currency amount of Leaf Chain A (320) (deduct the remittance amount from the total currency amount). If the transfer fails, Leaf Chain A (320) can unlock the locked coin and return it to user a. Leaf chain A (320) can record this remittance result in a block along with the hash recorded in the root chain (310).

Figure 9 is a diagram showing the flow of coin exchange data through a smart contract between each chain in an embodiment of the present invention.

(1) When user a’s coin exchange request is received by dApp 1 (dApp 1, 920) of leaf chain A (320), dApp 1 (920) can request an exchange to leaf chain manager contract A (910). . Leaf Chain Manager Contract A (910) generates the exchange transaction hash (eTxHash), the exchange transaction hash, user a (identifier) and service a (identifier) to send money, service b (identifier) to receive money and user b. (identifier of), amount information (transfer amount), and/or request time may be recorded (creating a transfer request record (escrow information)). At this time, Leaf Chain Manager Contract A (910) can subtract the total currency amount of the contract of DApp 1 (920) and the amount held by User A.

(2) The producer 441 can collect the transaction created in (1), and the interchain consumer 443 can request a transfer 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 currency volume of DApp 1 (920) managed by Leaf Chain Manager A Contract (412) can be deducted by the amount of the remittance.

(4) The producer (441) can collect the transaction created in (3), and the interchain consumer (443) can send it to the leaf chain manager contract B (940) of leaf chain B (330), which has a service for receiving remittances. You can request a remittance.

(5) Leaf Chain Manager Contract B (940) of Leaf Chain B (330) can call DApp 3 (950), the service for which the money is to be sent, and allow the money to be transferred from the contract of DApp 3 (950) to User B. At this time, the contract of DApp 3 (950) can also increase the total currency volume of Leaf Chain B (330).

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

(7) The leaf chain B contract 413 of the root chain 310 can process the completion of the remittance by obtaining the escrow (remittance request record) information of the corresponding remittance request from the root chain manager contract 411. If the transfer is successful, the total currency volume of Leaf Chain B (330) can be increased by the amount of the transfer in DApp 3 (950) managed by Leaf Chain B Contract (413), and the Root Chain Manager Contract of Root Chain (310) The remittance request record may be deleted at (411). If the remittance fails, the total currency volume of Leaf Chain A (320) may be increased again by the amount sent to DApp 1 (920), the service that requested the remittance registered in the Leaf Chain A contract (412), and then the root chain (310) )'s root chain manager contract 411, the remittance request record may be deleted.

(8) The producer (441) can collect the transaction created in (7), and the interchain consumer (443) requests the leaf chain manager contract A (910) of the leaf chain A (320) that sent the money to complete the transfer. You can.

(9) Leaf Chain Manager Contract A (910) of Leaf Chain A (320) may receive transfer completion information, record that the exchange transaction hash is completed, and delete the request in the transfer request record (escrow). If the transfer fails, Leaf Chain Manager Contract A (910) can return the amount in the transfer request record (escrow) back to User A, and the total currency volume of DApp 1 (920) is also increased again by the amount of the transfer before the transfer is made. You can delete the request from the request history (escrow).

Depending on the embodiment, relayers may exist for each chain. For example, when there is one root chain 310 and two leaf chains 320 and 330 as described with reference to FIG. 4, three relays for a total of three chains may be configured. In this case, the relayer of the root chain 310 can handle 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 delivery of requests, data and/or events to and from the root chain 310. At this time, in order to prevent collusion of relayers for leaf chains, the 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 hash timelock contract. This hash time lock can be used to provide time for users to directly check the results of exchange transactions. Additionally, a separate exchange transaction identifier can be used as a unique identifier to prevent unintentional double payments by relayers. This exchange transaction identifier can be used to uniquely identify and track exchange transactions when there is a transfer of value between leaf chains.

When transmitting data between chains in this blockchain network 300, there is a possibility that the data to be transmitted may be tampered with in the transmitting system. For example, when transferring data from leaf chain A (320) to the root chain (310), there is a possibility that data may be tampered with in leaf chain A (320). In particular, if a relayer is implemented for each leaf chain to enable leaf chains to expand into a public blockchain, there is a need to reduce dependence on such relayers 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 Base Coin chains must be possible. Here, the base coin may refer to a coin used in the 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 the base coin may include transferring the base coin between chains.

3. The relayer must be prevented from altering and transmitting data.

4. It is necessary to prevent double payments from occurring by receiving a remittance from the Leaf Chain and sending a message to the user that the remittance was successful but failed.

5. Inter-chain transfers must be made quickly without confirmation from the user receiving the base coin.

To meet these requirements, the root chain can allow mint and burn of base coins to occur through authorized users. Alternatively, authorized users can receive confirmation through a multisig-wallet to issue or burn base coins. At this time, the leaf chain can issue coins when it receives a request for coin issuance from the root chain. Additionally, when transferring money from one leaf chain to another, issuing and burning can be performed after both leaf chains confirm that the authenticated information of the root chain has been delivered. For example, the Leaf Chain sending the base coin can burn the base coin, and the Leaf Chain receiving the base coin can issue the base coin.

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

In the first method, you can sign the original data you want to convey. If the subject transmitting the data (from user) is a user already known in the chain from which the data is to be received, it is possible to check whether the original data has been tampered with through the signed original data. For this purpose, a contract can be created with its own private key, and the public key corresponding to the private key can be made public. At this time, information that needs to be transmitted from the contract to another chain can be signed and recorded as an event, thereby proving that the original data was processed from the contract. For example, a contract can sign the original data and its 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 can access the contract through the contract address of the contract, which is uniquely generated in all chains. It can be proven that data has been transmitted. However, in the first method, the contract's private key must be stored in the contract's database, and since the database is shared and open in the blockchain network, the private key is shared with all nodes in the chain and is therefore no longer a private key. .

In the second method, rather than storing the private key in the contract, the private key representing one chain is shared with C-nodes, which are nodes that achieve consensus within the same chain, and is used when chain authentication is required. You can do it. For example, each chain can maintain n (for example, n is 4 to 8) C-nodes sharing a private key for consensus. A user or another contract can request the system for the chain (e.g., a system contract installed on the 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 events regarding the signing and delivery of data, and can transmit signed data to another chain through a relayer. For example, in the root chain, the public address, which is an identification value created through a public key paired with the private key of the root chain, cannot be tampered with in the leaf chain as it is recorded in the genesis block of the leaf chain. Data signed with a 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 the public address created with the leaf chain's private key in a leaf chain contract installed in association with the leaf chain on 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 private keys can be shared among C-nodes for consensus, but 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. For 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 can be stored in each of all leaf chains. At this time, data that needs to be confirmed to have been created in the root chain can be recorded in a block by being signed by the root chain's leader node with its own private key, and the data can be transmitted to the leaf chain. Here, the leader node may be a randomly selected node among C-nodes, and may be changed to one of other C-nodes when 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 earlier, since the leaf chain knows the public addresses of all C-nodes in the root chain, whether the public address obtained when verifying signed data is one of the public addresses of the C-nodes in the root chain that it already knows. 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 changes such as adding or deleting a C-node to the root chain occur, 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 updating of public addresses) information must be announced). Similarly, C-nodes in the leaf chain can also have their own private keys for consensus, and these private keys 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 association with the corresponding leaf chain, and the root chain compares the signed data with the public address registered in the corresponding leaf chain contract. , it can be verified that the signed data was sent from the corresponding leaf chain.

The fourth method is to share the representative public address (Common Public Address), which is created by combining the public addresses generated from all C-nodes of the root chain, to each of the leaf chains. Even in this case, if a change such as adding or deleting a C-node occurs in the loop chain, the information recorded in each leaf chain must be updated, but the public address that must be shared in each leaf chain must be 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 changes, you must be careful about security when changing it. In the fourth method, each public address of every C-node in the root chain must be known to each C-node. 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 signature are used so that the private key can decrypt through one or more confirmations. A modified module is required.

In the fifth method, the following functions can be added to the blockchain to enable the first method. In the fifth method, the contract can create a contract address with the public key, encrypt the private key, and have the contract store it. You know the private key, you can obtain the public key through the private key, and you can create the contract address through the public key. At this time, only one contract for signing (hereinafter referred to as Signing Enable Contract) may exist in one chain. For example, when deploying a signable contract, the encrypted private key and the public key generated with the private key can be passed as parameters to the signable contract. A contract that can be signed can create a contract address using the received public key. At this time, if there is an identical contract address, the creation of the contract address may fail. The encrypted private key can be decrypted using a password, which will be explained later, and stored in the database by a signable contract. At this time, if a contract wants to sign data, the data to be signed and a password that can decrypt the encrypted private key stored in the signable contract can be passed as parameters to the signable contract. At this time, while information from all requests in the blockchain (for example, requests using HTTPS (Hypertext Transfer Protocol Secure)) are recorded in blocks or logs, 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 in blocks or logs (hereinafter referred to as 'secure type'). These password parameters may be supported in the corresponding blockchain. In this case, the signing contract can restore the encrypted private key using the password, then use the restored private key to sign the entered data, and return the signed result (signed data) to the contract that requested the signature. can do. The contract address of a signable contract can be recorded in the genesis block of each leaf chain. 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. Since the private key is encrypted and delivered, the private key must be generated and delivered normally. I can't check whether it works or not. In order for the leaf chain to prove that the data is transmitted from the root chain, the leaf chain can immediately check the root chain to see if the signing contract that signed the data is a contract installed in the root chain, and the signing contract is a contract in the root chain. Once 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.

Figure 10 is a diagram illustrating an example of the installation process of a signable contract in one embodiment of the present invention. Figure 10 shows that a signable contract 1010 receives an encrypted private key 1020 and a public key 1030 as parameters, generates a public address using the received public key 1030, and stores it in the database 1040. It shows an example. In other words, the database 1040 may store the encrypted private key 1020, the public key 1030, and the public address generated using the public key 1030.

Figure 11 is a diagram illustrating an example of a process for signing data according to an embodiment of the present invention. Figure 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 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 can obtain a private key by decrypting the encrypted private key 1020 using a password, and can use the decrypted private key to sign data delivered as a parameter. Thereafter, the signable contract 1010 may return the signed data as a result to the user or another contract 1110. Here, users can correspond to the nodes of the corresponding blockchain.

In the sixth method, the signable contract of the fifth method can be automatically installed as a blockchain system contract. In other words, when a blockchain system contract is installed, a 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 signing contract. The generated private key can be encrypted through a signing contract and stored in the database, and the password to decrypt the encrypted private key can be encrypted with the public key of the node and stored locally in the node. Other nodes can replicate the transaction and search for the node that knows the latest password. At this time, the other node can deliver its public key to the node being searched, receive the password encrypted with the public key, and store it locally in the other node. When requesting a signature, each node can obtain a password by decrypting the encrypted password stored locally with its public key, and can transmit the obtained password to the signing contract as a parameter of the signature request function. Requests can be processed using the signature API or function provided by the blockchain. The public address of a signable contract can be recorded in the genesis block of each leaf chain. To prove that data is transmitted from the root chain, a signable contract can be used.

Figure 12 is a diagram illustrating another example of the installation process of a signable contract according to an embodiment of the present invention. Figure 12 shows an example in which the signable contract 1210 encrypts the private key generated by the node with the node's public key 1220 and stores it in the database 1230. At this time, the signable contract 1210 can encrypt the password for decrypting the encrypted private key with the node's public key and return it to the corresponding node. The returned encrypted password can be stored locally on the node.

Figure 13 is a diagram illustrating another example of a process for signing data, according to an embodiment of the present invention. Figure 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, then transmits the obtained password as a parameter to the system 1320 to request signing of the data. . Here, the system 1320 may correspond to a blockchain system. At this time, the data to be signed may also be transmitted to the system 1320 as a parameter. In this case, the system 1320 may request the signable contract 1210 to sign data using a password. In this case, the signable contract 1210 can decrypt the encrypted private key using a 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.

Meanwhile, in the leaf chain, it must be ensured that the content processed internally and the content delivered are not different. To achieve this, the list of Merkle tree proof hashes of the transaction that processed the remittance must be transmitted through an event along with the processing result. If a watcher exists, it is necessary to decide whether to transmit the proof information of the Merkle tree. 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 processing content has been tampered with, so a monitor may be needed. At this time, the monitor can check whether the block exists and whether the transfer was successful or failed, as shown by the data transmitted by the transaction as an event. If fraud is discovered by a monitor, a penalty may be provided to the relevant leaf chain. Here, the watcher can be implemented in the form of a node that executes the above functions.

Figure 14 is a diagram showing another example of a coin exchange method in one embodiment of the present invention. Coin exchange in the same service on the same chain or between other services on the same chain has also been explained through the embodiment of FIG. 8. Figure 14 shows a root chain 1410, leaf chain 1 (1420), and leaf chain 2 (1430) as an embodiment different from the embodiment of Figure 8, and user 1 of leaf chain 1 (1420) is the leaf chain. Assume that a remittance request is made to user 2 at 2 (1430).

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, if there is no problem, transmits information about the remittance request to the root chain (1410).

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

Process 3 may be an example of a process in which the leaf chain 2 (1430) checks whether the remittance request is a receivable request and, if there is no problem, transmits a receivable response to the root chain (1410).

Process 4 may be an example of a process in which the root chain 1410 issues a receipt deducting or increasing the 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 to deduct the remittance amount to leaf chain 1 (1420), and process 4.2 may be an example of the process in which the root chain (1410) increases the remittance amount to leaf chain 2 (1430). This may be an example of the process of issuing a receipt for. In each chain, management can be carried out to prevent duplicate deductions or duplicate increases from occurring.

Below, the composition of the smart contract is explained.

In the case of the root chain, the smart contract may include a root chain manager contract as previously described with reference to FIG. 4, and may include a contract for each leaf chain. Meanwhile, Leaf Chain may include a Leaf Chain Manager Contract and a DApp Contract if a Service DApp exists, and may include a Leaf Chain Manager Contract if a Service DApp does not exist. The root chain manager contract and leaf chain manager contract are system contracts and can be installed automatically when the blockchain is installed. Relayers can filter eventlogs and deliver them to each chain. Each chain can be managed so that relayers cannot tamper with the data. 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. All information to be delivered by the relayer can be signed with the root chain's unique private key.

Additionally, 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: User making the remittance

· origin: service or leaf chain for which remittance was requested

· to user: User receiving the remittance

· destination: service or leaf chain that receives remittance

· value: remittance amount (base coin)

· eTxHash: Remittance transaction hash

· message: remittance message

· eSignature: 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.

Figure 15 is a flowchart showing a first example of a data authentication method in one embodiment of the present invention. The data authentication method according to this embodiment may be performed by a computer device 200 that implements a node of a blockchain network. For example, the processor 220 of the computer device 200 may be implemented to execute control instructions according to the code of an operating system or at least one program included in the memory 210. Here, the processor 220 causes the computer device 200 to perform steps 1510 to 1540 included in the method of FIG. 15 according to control instructions provided by code stored in the computer device 200. can be controlled.

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. 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 explains the process of sharing one private key representing the chain among the C-nodes of the chain and using it for chain authentication in the second method described above. In other words, the computer device 200 implementing one node may share a 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 using a public key generated using the private key. As already explained, a public address can be provided to verify that data signed via a private key originated from the corresponding blockchain network.

In one embodiment, a blockchain network may include a root chain that manages data transmission between multiple leaf chains. In this case, the computer device 200 may record the generated public address in the 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 from the leaf chain that received the signed data with the public address recorded in the genesis block of the leaf chain.

In another embodiment, a 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 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 can sign data to be transferred from one 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 transmit the signed data to another blockchain network through a contract. At this time, it can be verified that the signed data was sent through the blockchain network through comparison between the signed data and the public address.

Figure 16 is a flowchart showing a second example of a data authentication method in one embodiment of the present invention. The data authentication method according to this embodiment may be performed by a computer device 200 that implements a node of a blockchain network. For example, the processor 220 of the computer device 200 may be implemented to execute control instructions according to the code of an operating system or at least one program included in the memory 210. Here, the processor 220 causes the computer device 200 to perform steps 1610 to 1630 included in the method of FIG. 16 according to control instructions provided by code stored in the computer device 200. can be controlled.

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

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

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

In one embodiment, a blockchain network may include a root chain that manages data transmission between multiple leaf chains. At this time, the public address generated from each of a plurality of nodes (a plurality of nodes including nodes implemented by the computer device 200 in this embodiment) preset to achieve consensus in the blockchain network is distributed to a plurality of leaves. It can be stored in each chain. In this case, it is possible to verify that the signed data was sent from the root chain by comparing the signed data from the first leaf chain that received the signed data and the public addresses 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 among a plurality of leaf chains whose data transmission is managed by a root chain. At this time, the public address generated from each of a plurality of nodes (a plurality of nodes including nodes implemented by the computer device 200 in this embodiment) preset to achieve consensus in the blockchain network is the first address in the root chain. It can be registered in the Leaf Chain contract installed in connection 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 and the public address registered in the leaf chain contract.

In another embodiment, a blockchain network may include a root chain that manages data transmission between multiple leaf chains. At this time, a representative public generated by a combination of public addresses generated from each of a plurality of nodes (a plurality of nodes including nodes implemented by the computer device 200 in this embodiment) preset to achieve consensus in the blockchain network The address may be stored in each of multiple 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 from 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 among 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 from each of a plurality of nodes (a plurality of nodes including nodes implemented by the computer device 200 in this embodiment) preset to achieve consensus in the blockchain network The address may be registered in a leaf chain contract installed in association with the first leaf chain on the root chain. In this case, it is possible to verify that the signed data was sent from the first leaf chain by comparing the data signed in the root chain with the representative public address registered in the leaf chain contract.

Figure 17 is a flowchart showing a third example of a data authentication method in one embodiment of the present invention. The data authentication method according to this embodiment can be performed by the computer device 200 operating through a contract in a blockchain network. For example, the processor 220 of the computer device 200 may be implemented to execute control instructions according to the code of an operating system or at least one program included in the memory 210. Here, the processor 220 causes the computer device 200 to perform steps 1710 to 1760 included in the method of FIG. 17 according to control instructions provided by code stored in the computer device 200. can be controlled. Here, at least one program code may include at least a code according to a contract of the blockchain network.

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

In step 1720, the computer device 200 may generate a contract address using 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 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 of the blocks or logs of the blockchain network.

In step 1750, the computer device 200 may decrypt the encrypted private key using a password in response to the signature request, and sign the data with the decrypted private key to generate signed data. At this time, a block in which signed data is recorded may 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 can be returned to the node that requested the signature of the data.

In one embodiment, a blockchain network may include a root chain that manages data transmission 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 among 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 root chain database. 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 root chain's database.

Figure 18 is a flowchart showing a fourth example of a data authentication method in one embodiment of the present invention. The data authentication method according to this embodiment may be performed by a computer device 200 that implements a node of a blockchain network. For example, the processor 220 of the computer device 200 may be implemented to execute control instructions according to the code of an operating system or at least one program included in the memory 210. Here, the processor 220 causes the computer device 200 to perform steps 1810 to 1860 included in the method of FIG. 18 according to control instructions provided by code stored in the computer device 200. can be controlled.

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 the first node created in the blockchain network, and a signable contract can be automatically installed in the process of installing the system contract of the blockchain network at these nodes. During this process, the node's private key can be transferred to the signing contract. At this time, the signable contract can encrypt and store the private key of the node delivered 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 node's public key. 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 the value for obtaining the symmetric key may be created as a password.

In step 1830, the computer device 200 may return the password encrypted with the node's public key 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. Meanwhile, other nodes in the blockchain network can find the node that returned the encrypted password, send the other node's public key to that node, and receive the password encrypted with the other node's public key from that node and store it in the other node. . Through this process, other nodes in the blockchain network can also obtain the 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. Meanwhile, passwords can be defined as a secure type that is not stored anywhere in 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 private key as parameters from any node of the blockchain network. Any node may be a node that receives the encrypted password returned from the computer device 200, or may be another node that receives the password from the corresponding node.

In step 1850, the computer device 200 may respond to the signature request, decrypt the encrypted private key using a password, and sign the data with the decrypted private key to generate signed data.

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

In one embodiment, a blockchain network may include a root chain that manages data transmission 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 among 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 root chain database. 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 root chain's database. The root chain can be considered 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 scalable blockchain by adding a leaf chain based on the root chain.

The system or device described above may be implemented with hardware components, software components, or a combination of hardware components and software components. For example, devices and components described in 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), etc. , may be implemented using one or more general-purpose or special-purpose computers, such as a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. Additionally, a processing device may access, store, manipulate, process, and generate data in response to the execution of software. For ease of understanding, a single processing device may be described as being used; however, those skilled in the art will understand that a processing device includes multiple processing elements and/or multiple types of processing elements. It can be seen that it may include. For example, a processing device may include a plurality of processors or one processor and one controller. Additionally, other processing configurations, such as parallel processors, are possible.

Software may include a computer program, code, instructions, or a combination of one or more of these, which may configure a processing unit to operate as desired, or may be processed independently or collectively. You can command the device. Software and/or data may be used on any type of machine, component, physical device, virtual equipment, computer storage medium or device to be interpreted by or to provide instructions or data to a processing device. It can be embodied in . Software may be distributed over networked computer systems and stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., singly or in combination. Program instructions recorded on the medium may be specially designed and configured for the embodiment or may be known and usable by 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 optical media (magneto-optical media) and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, etc. These recording media may be a variety of recording or storage means in the form of a single or several pieces of hardware combined, and are not limited to media directly connected to any computer system and may be distributed over a network. Examples of program instructions include machine language code, such as that produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc.

Forms for practicing the invention

As described above, although the embodiments have been described with limited examples and drawings, various modifications and variations can be made by 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 components of the described system, structure, device, circuit, etc. are combined or combined in a different form than the described method, or other components are used. Alternatively, appropriate results may be achieved even if substituted or substituted by an equivalent.

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

Claims (20)

In the data authentication method of a node implemented by a computer device participating in a blockchain network,
sharing, by at least one processor included in the computer device, a private key representing a chain of the blockchain network with at least one other node participating in the blockchain network;
generating, by the at least one processor, a public address of the blockchain network using the private key;
Signing, by the at least one processor, data to be transferred from the blockchain network to another blockchain network with the private key through a contract installed in the blockchain network; and
Transferring, by the at least one processor, the signed data to another blockchain network through the contract.
Including,
A data authentication method, characterized in that it is verified that the signed data was sent through the blockchain network through comparison between the signed data and the public address. According to paragraph 1,
The blockchain network includes a root chain that manages data transmission between a plurality of leaf chains,
The data authentication method is,
Recording the generated public address in a genesis block of each of the plurality of leaf chains, by the at least one processor.
A data authentication method further comprising: According to paragraph 2,
A data authentication method comprising verifying 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 a public address recorded in the genesis block of the leaf chain. . According to paragraph 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,
Registering, by the at least one processor, the generated public address in a leaf chain contract installed in association with the first leaf chain in the root chain.
A data authentication method further comprising: According to paragraph 4,
A data authentication method, characterized in that it verifies that the signed data was sent from the first leaf chain by comparing the signed data in the root chain with a public address registered in the leaf chain contract. According to paragraph 1,
A data authentication method, wherein the node is one of a plurality of nodes preset to achieve consensus in the blockchain network. According to paragraph 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. delete delete delete delete delete delete delete delete delete delete 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 7. A computer-readable recording medium, characterized in that a computer program for executing the method of any one of claims 1 to 7 on a computer device is recorded thereon. In a computer device implementing a node of a blockchain network,
At least one processor implemented to execute readable instructions on the computer device
Including,
By the at least one processor,
Share a private key representing the chain of the blockchain network with at least one other node participating in the blockchain network,
Generate a public address of the blockchain network using the private key,
Sign the data you want to transfer from the blockchain network to another blockchain network with the private key through a contract installed in the blockchain network,
Transfer the signed data to another blockchain network through the contract,
Verifying that the signed data was sent through the blockchain network through comparison between the signed data and the public address
A computer device characterized by a.

Images