JP7254954B2 - Methods and systems for authenticating blockchain-generated data - Google Patents

Description

The following description relates to methods and systems for authenticating blockchain-generated data utilizing signable contracts.

Blockchain is an electronic ledger that is realized by a computer-based distributed peer-to-peer (P2P) system composed of blocks for transactions. Each transaction (Transaction: Tx) is a data structure that encodes the controlled transmission of digital assets to participants in the blockchain system and includes at least one input and at least one output. Each block contains the hash of the previous block, and the blocks are concatenated to create a permanent, immutable record of all transactions recorded on the blockchain from the beginning. For example, Korean Patent Publication No. 10-2018-0113143 discloses a blockchain-based user-defined monetary transaction system and method of operation thereof. Such blockchains themselves cannot scale out. For example, adding nodes to generate blocks in a blockchain network only increases the consensus cost for block generation, but does not increase the speed of block generation for transactions.

A data authentication method and system for authenticating data generated in a scalable block chain by adding a leaf chain based on a root chain.

A method of data authentication for a computing device operating according to a blockchain network contract, the step of receiving as parameters an encrypted private key and a public key generated by the private key by at least one processor included in said computing 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 a processor, a signature request including, as parameters, data to be signed and a password for decrypting the encrypted private key; responding to the signature request by the at least one processor; generating signed data by decrypting the decrypted private key and signing the data with the decrypted private key; and converting the generated signed data by the at least one processor. A data authentication method is provided, characterized by including the step of returning.

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

According to another aspect, the blockchain network includes a root chain that manages data transmission between a plurality of leaf chains, and wherein the data authentication method includes transmitting the contract address to the plurality of leaf chains by the at least one processor. It may further include recording in each genesis block.

According to yet another aspect, the signed data is compared with a contract address recorded in a genesis block of the first leaf-chain at a first leaf-chain that receives the signed data. It may be characterized by verifying that the received data was sent from the root chain.

According to yet another aspect, the blockchain network includes a first leaf chain of a plurality of leaf chains whose data transmission is managed by a root chain, and wherein the data authentication method comprises, by the at least one processor, the The method may further include providing the contract address to the root chain so that the contract address is stored in a database of the root chain.

According to yet another aspect, the signed data is dispatched 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. It may be characterized by verifying that the

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

A method of data authentication for a computing device operating by a contract of a blockchain network, the step of encrypting and storing, by at least one processor included in the computing device, a private key of a node of the blockchain network; encrypting and storing, by a processor, a password for decrypting the encrypted private key with the public key of the node; returning to a node, receiving, by the at least one processor, a signature request including data for signing with the password and the private key as parameters from any node of the blockchain network; the at least one processor. generating signed data by responding to the signing request, decrypting the encrypted private key with the password, and signing the data with the decrypted private key, and at least A data authentication method is provided, comprising the step of returning the signed data by one processor.

A computer program stored in a computer readable recording medium is provided for coupling with a computer device to cause the computer device to perform the method.

A computer-readable recording medium is provided, characterized by recording a computer program for causing a computer device to execute the method.

A computing device operating according to a blockchain network contract, the computing device comprising at least one processor implemented to execute instructions readable by the computing device, the at least one processor having an encrypted private key. and a private key as a parameter, generates a contract address with the received public key, stores the encrypted private key and the contract address in a database, and stores the data to be signed and the encryption receiving a signature request including a password for decrypting the encrypted private key as a parameter, decrypting the encrypted private key using the password, and signing the data with the decrypted private key. to generate signed data and return the generated signed data.

A computing device operating according to a contract of a blockchain network, comprising at least one processor implemented to execute instructions readable by said computing device, said at least one processor causing a node of said blockchain network to: encrypting and storing a private key of, encrypting and storing a password for decrypting said encrypted private key with said node's public key, and encrypting said node's public key with said password encrypted with said node to receive a signature request containing data to be signed by the password and the private key as parameters from any node of the blockchain network; respond to the signature request; A computer device is provided that decrypts a private key, signs the data with the decrypted private key to generate signed data, and returns the signed data.

By adding leaf chains 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 showing an example of a network environment in one embodiment of the present invention; FIG. 1 is a block diagram illustrating an example of a computing device, in accordance with one embodiment of the present invention; FIG. 1 is a diagram showing an example of a general configuration of a scalable blockchain network in one embodiment of the present invention; FIG. 1 is a diagram showing an example of detailed configuration of a transaction processing system in one embodiment of the present invention; FIG. FIG. 4 is a flow chart showing an example process of adding a new leaf chain in one embodiment of the present invention; FIG. FIG. 4 is a flow chart showing an example of the process of adding a new service in one embodiment of the present invention; FIG. 4 is a flow chart showing an example of the process of issuing coins to a service in one embodiment of the present invention; 4 is a flow chart showing an example of a coin exchange process in one embodiment of the present invention; FIG. 4 is a diagram showing the flow of coin exchange data by smart contracts between chains in one embodiment of the present invention. FIG. 4 is a diagram showing an example of a signable contract installation process in an embodiment of the present invention; FIG. 4 illustrates an example process of signing data in an embodiment of the present invention; FIG. 10 is a diagram showing another example of the process of installing a signable contract in an embodiment of the present invention; FIG. 10 is a diagram showing another example of the process of signing data in one embodiment of the present invention; FIG. 10 is a diagram showing another example of the coin exchange process in one embodiment of the present invention; 4 is a flow chart showing a first example of a data authentication method in one embodiment of the present invention; 4 is a flow chart showing a second example of a data authentication method in one embodiment of the present invention; 3 is a flow chart showing a third example of a data authentication method in one embodiment of the present invention; FIG. 11 is a flow chart showing a fourth example of a data authentication method in one embodiment of the present invention; FIG.

Embodiments will be described in detail below with reference to the accompanying drawings.

A data authentication system according to embodiments of the present invention may be implemented by at least one computing device. A computer program according to an embodiment of the present invention may be installed and executed in a computer device, and the computer device executes a data authentication method according to an embodiment of the present invention under control of the executed computer program. You can The computer program described above may be recorded in a computer-readable recording medium in order to combine with a computer device and cause the computer device to execute the data authentication method. The computer program described here may be in the form of one independent program package, or in the form of one independent program package pre-installed in a computer device and linked with an operating system or other program package. may be

FIG. 1 is a diagram showing an example of a network environment in one embodiment of the present invention. The network environment of FIG. 1 illustrates an example including multiple electronic devices 110 , 120 , 130 , 140 , multiple servers 150 , 160 , and a network 170 . Such FIG. 1 is merely an example for explaining the invention, and the number of electronic devices and the number of servers are not limited as in FIG. Also, the network environment in FIG. 1 is merely an example of the environment applicable to this embodiment, and the environment applicable to this embodiment is not limited to the network environment in FIG. .

The plurality of electronic devices 110, 120, 130, 140 may be fixed terminals or mobile terminals implemented by computing devices. Examples of the plurality of electronic devices 110, 120, 130, and 140 include smartphones, mobile phones, navigation systems, PCs (personal computers), notebook PCs, digital broadcasting terminals, PDAs (Personal Digital Assistants), and PMPs (Portable Multimedia Players). ), tablets, etc. As an example, FIG. 1 shows a smartphone as an example of the electronic device 1 (110). It may refer to one of a variety of physical computing devices capable of communicating with other electronic devices 120 , 130 , 140 and/or servers 150 , 160 via network 170 .

The communication method is not limited, and not only the communication method using the communication network that can be included in the network 170 (eg, mobile communication network, wired Internet, wireless Internet, broadcasting network), but also the short distance between devices. Wireless communication may be included. For example, the network 170 includes a PAN (personal area network), a LAN (local area network), a CAN (campus area network), a MAN (metropolitan area network), a WAN (wide area network), a BBN (broadband network), and the Internet. Any one or more of the networks may be included. Additionally, network 170 may include any one or more of network topologies including, but not limited to, bus networks, star networks, ring networks, mesh networks, star-bus networks, tree or hierarchical networks, and the like. will not be

Each of servers 150, 160 is implemented by one or more computing devices that communicate with a plurality of electronic devices 110, 120, 130, 140 over network 170 to provide instructions, code, files, content, services, etc. good. For example, the server 150 provides services (eg, video call service, financial service, payment service, social network service, messaging service, search service, mail service, content providing service, and/or question and answer service).

FIG. 2 is a block diagram illustrating an example computing device, in accordance with one embodiment of the present invention. Each of the plurality of electronic devices 110, 120, 130, 140 and each of the servers 150, 160 described above may be implemented by the computer device 200 shown in FIG. It may be implemented by device 200 .

At this time, as shown in FIG. 2, computing device 200 may include memory 210 , processor 220 , communication interface 230 , and input/output interface 240 . The memory 210 is a computer-readable storage medium and may include random access memory (RAM), read only memory (ROM), and permanent mass storage devices such as disk drives. Here, a permanent mass storage device such as a ROM or disk drive may be included in computer device 200 as a separate permanent storage device separate from memory 210 . Also stored in memory 210 may be an operating system and at least one program code. Such software components may be loaded into memory 210 from a computer-readable medium separate from memory 210 . Such other computer-readable recording media may include computer-readable recording media such as floppy drives, disks, tapes, DVD/CD-ROM drives, memory cards, and the like. In other embodiments, software components may be loaded into memory 210 through communication interface 230 that is not a computer-readable medium. For example, software components may be loaded into memory 210 of computing device 200 based on computer programs installed by files received over network 170 .

Processor 220 may be configured to process computer program instructions 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 code stored in a storage device, such as memory 210 .

The communication module 230 may provide a function for the computer device 200 to communicate with other electronic devices (for example, the recording device described above) via the network 170 . As an example, processor 220 of computing device 200 can transmit requests, commands, data, files, etc. generated according to program code recorded in a recording device such as memory 210 to other devices via network 170 under the control of communication interface 230 . device. Conversely, signals, instructions, data, files, etc. from other devices may be received by computing device 200 through communication interface 230 of computing device 200 over network 170 . Signals, instructions, data, etc. received through the communication interface 230 may be transmitted to the processor 220 and the memory 210, and files may be stored in a recording medium (the permanent recording device described above) that the computing device 200 may further include. may be recorded.

Input/output interface 240 may be a means for interfacing with input/output device 250 . For example, input devices may include devices such as microphones, keyboards, cameras, or mice, and output devices may include devices such as displays, speakers, and the like. As another example, input/output interface 240 may be a means for interfacing with a device that integrates functionality for input and output, such as a touch screen. Input/output device 250 may be one device with computing device 200 .

Also, in other embodiments, computing device 200 may include fewer or more components than the components of FIG. However, most prior art components need not be explicitly shown in the figures. For example, computing device 200 may be implemented to include at least some of the input/output devices 250 described above, and may also include other components such as transceivers, databases, and the like.

FIG. 3 is a diagram showing an example of a general configuration of a scalable blockchain network in one embodiment of the present invention. FIG. 3 shows an example blockchain network 300 including Root Chain 310, Leaf Chain A 320, Leaf Chain B 330, and Relayer 340. . Root chain 310 and leaf chains 320 and 330 may form a network in which multiple computer devices are connected, and relay 340 may be implemented by at least one computer device.

In blockchain network 300, root chain 310 may be viewed as an absolute trust system, and each leaf chain 320 and 330 must prove to root chain 310 that it is a trust system. Each leaf chain 320 and 330 may then be associated with a separate service, and new leaf chains may be added as new services are added. In other words, although the embodiment of FIG. 3 shows two leaf chains 320 and 330, it may include more than two leaf chains, which means that expansion of the blockchain is possible. good. Here, "services" may include online services provided by the same or different entities to their users via networks. As an example, a plurality of leaf chains corresponding to Internet banking services provided by different banks may be configured. Alternatively, multiple leaf chains corresponding to multiple different social network services may be configured. Each leaf chain 320 and 330 must be endorsed for trust by recording the block's hash on the root chain 310 . As an example, a merkle tree root hash may be utilized.

Root chain 310 does not exchange coins between users, and coin exchanges may occur within each leaf chain 320 and 330 and/or between leaf chains 320 and 330 . At this time, coin exchange between leaf chains 320 and 330 may be arbitrated and managed by root chain 310 via relay 340 . Each leaf chain 320 and 330 may include at least one DApp (Decentralized Application). Here, DApp (Decentralized Application) is executed on a P2P (peer-to-peer) network where backend code is distributed (or data is called or registered in a blockchain database), and this is front It means an application provided as an interface at the end. At this time, each leaf chain 320 and 330 may set up a smart contract unrelated to the chain or coin exchange according to the needs of the DApp, which the root chain 310 is not involved in. In order to install a smart contract with a protocol for inter-chain coin exchange on each of the leaf chains 320 and 330, permission to install the smart contract must be obtained from the root chain 310. Coin exchange may be restricted between chains using smart contracts for which permission has not been obtained from the root chain 310 .

Coin exchanges within each leaf chain 320 and 330 may be processed in each leaf chain 320 and 330 without having to go through the root chain 310, and summary information of all blocks containing processed content (as an example, the Merkle tree root hash discussed above) may be recorded in the root chain 310 . On the other hand, the coin exchange between the leaf chains 320 and 330 must go through the root chain 310, and the contents of the coin exchange process must be recorded in the blocks of the leaf chains 320 and 330 and the block of the root chain 310, respectively. must. At this time, coin exchange between leaf chains 320 and 330 may be done via relay 340 .

FIG. 4 is a diagram showing a detailed configuration example of a blockchain network in one embodiment of the present invention. Blockchain network 300 may consist of one root chain 310, multiple leaf chains 320 and 330, and a relay 340, as shown in FIG.

The root chain 310 may include a Root Chain Manager Contract 411, which is a smart contract for the root chain 310, and a smart contract for each of the multiple leaf chains 320 and 330 that the blockchain network 300 includes. may contain In the embodiment of FIG. 4, the root chain 310 includes a Leaf Chain A Contract 412, which is a smart contract for Leaf Chain A 320, and a Leaf Chain B 330. It shows an example that includes Leaf Chain B Contract 413, which is a smart contract for .

Also, each of the leaf chains 320 and 330 may contain smart contracts for DApps. The embodiment of FIG. 4 shows an example in which leaf chain A 320 includes DApp Contract 421 and leaf chain B 330 includes DApp Contract 431 . Leaf Chain A 320 may also include a Leaf Chain Manager Contract 422, which is a smart contract for Leaf Chain A 320, and Leaf Chain B 330, which is a smart contract for Leaf Chain B 330. A manager contract 432 may also be included.

Relayer 340 may recall information recorded and/or required to be transmitted in root chain 310 and leaf chains 320 and 330 while observing block generation of root chain 310 and leaf chains 320 and 330. . Relayer 340 may include Producer 441 , Kafka 442 , InterChain Consumer 443 , InterChain Failover 444 , and Database 445 .

Producer 441 may collect and input to Kafka 442 information for newly created blocks for all chains, including root chain 310 . Kafka 442 is a type of queue server that may store the collected information in a queue and provide it in sequence. At this time, the inter-chain consumer 443 may filter events that require invocation on a chain-by-chain basis. Multiple filtering may be requested by an event. The interchain consumer 443 may create a separate user for each chain for signing and record the user's authority in a smart contract when making calls to each chain.

The interchain consumer 443 may sense events such as the following (1) to (7).

(1) Remittance Request Event in Leaf Chain (1-1) The inter-chain consumer 443 may detect a remittance request event in the leaf chain and transmit the remittance request content to the root chain.

(2) Remittance Request Event on Root Chain (2-1) The inter-chain consumer 443 may sense a remittance request event on the root chain and transmit the content of the remittance request to the leaf chain that receives the remittance request.

(2-2) The interchain consumer 443 may transmit remittance failure information including the identification information of the leaf chain that receives the remittance request to the root chain when transmission to the receiving leaf chain fails.

(3) Remittance request failure event in the root chain (3-1) The interchain consumer 443 may transmit remittance failure details to the leaf chain that requested the remittance.

(4) Remittance Completion Event in Leaf Chain (4-1) The interchain consumer 443 may transmit remittance completion content to the root chain.

(5) Remittance Completion Event in Root Chain (5-1) The interchain consumer 443 may transmit remittance completion details to the leaf chain that requested the remittance.

(6) Coin Issuance Event on Root Chain (6-1) The interchain consumer 443 may transmit the issuance details to the leaf chain where the coin is to be issued.

(7) Block generation event on leaf chain (7-1) Interchain consumer 443 may convey the Merkle tree root hash of the block to the root chain.

Inter-chain failover 444 provides fault overcoming functionality so that (3-1), (4-1), (5-1), (6-1), and (7-1) are successfully propagated database 445 may be utilized to store information that is received and/or transmitted at interchain consumer 443 and interchain failover 444 .

FIG. 5 is a flowchart illustrating an example process of adding a new leaf chain in one embodiment of the present invention.

At step 510, the blockchain network 300 may build a leaf chain. For example, new leaf chains may be built to add new services as described below.

At step 520, the blockchain network 300 may install a leaf chain manager contract on the leaf chain, responsible for inter-chain or inter-contract coin transfers.

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

At step 540, the blockchain network 300 may register the address of the leaf chain contract of the installed root chain with the root chain manager contract. In the embodiments described below, the address of the leaf chain's signable contract may additionally be registered with the root chain manager contract. In still other embodiments, a public address representing the leaf chain may be registered with the root chain manager contract.

At step 550, the blockchain network 300 may add relay users with access to the leaf chain contract of the root chain.

At step 560, the blockchain network 300 may add relay users with access to the leafchain manager contract of the leafchain.

At this time, the relay users in steps 550 and 560 may be the same user or different users. It may be advantageous for security to set and utilize individual relay users that are different for each leaf chain and even for the root chain. Here, relay users may correspond to accounts of services provided by the blockchain network 300 .

FIG. 6 is a flowchart illustrating an example process of adding a new service in one embodiment of the invention.

At step 610, the blockchain network 300 may install a corresponding service contract on the leaf chain. The address of the installed contract may be used as a value for distinguishing the corresponding service. The service in question may be a contract with an inter-chain coin exchange protocol.

At step 620, the blockchain network 300 may register the address of the contract established for the service in the leafchain manager contract of the leafchain. For example, step 520 of FIG. 5 described setting up a leaf chain manager contract on the leaf chain, which is responsible for coin transfers between chains or contracts. Addresses of contracts for services may be registered in such leaf chain manager contracts.

At step 630, the blockchain network 300 may register the address of the installed contract with the root chain manager contract of the root chain. At this time, the address of the installed contract may be registered by the administrator authority of the root chain manager contract. If the address of the contract set for the leaf chain service is registered in the root chain manager contract together with the leaf chain contract of the corresponding leaf chain set in the root chain, the leaf chain contract of the root chain also has the leaf chain service. The address of the contract established for may be registered as a service on the corresponding leafchain.

FIG. 7 is a flow chart showing an example of the process of issuing coins for services in one embodiment of the present invention.

At step 710, the root chain manager contract of the root chain may request coin issuance to the address of the contract for services registered in the leaf chain contract installed in the root chain. For example, the root chain manager contract of the root chain may identify the corresponding service by the address of the contract for the service for issuing coins by the leaf chain contract installed in the root chain, and the coin for the identified service. A publish event may be generated.

At step 720, the interchain consumer may sense a coining event for the corresponding service and request coining for the service from the leafchain manager contract of the corresponding leafchain.

At step 730, the Leaf Chain Manager contract may search for the appropriate service and issue coins. At this time, coins may be issued to the service operator (for example, the relay user added in step 560 of FIG. 5) entered when setting up the contract for the corresponding service.

FIG. 8 is a flow chart showing an example of a coin exchange process in one embodiment of the present invention. Coin exchanges in the same service on the same chain may be done by a smart contract for coin exchange on the corresponding leaf chain. Also, exchange of coins between different services on the same chain may be done by the leaf chain manager contract of the corresponding leaf chain. For example, remittance from a first service to a second service on the same chain may be made by the leaf chain manager contract calling the address of the second service contract according to the remittance request of the first service. At this time, when coins are exchanged between different services of the same leaf chain, the coin exchange result may be transmitted to the root chain. This is so that the root chain can grasp changes in the amount of coins held by each service on the leaf chain. On the other hand, the exchange of coins between different chains may be done by following steps 810-890. Steps 810-890 of FIG. 8 illustrate and illustrate the coin exchange between leaf chain A 320 and leaf chain B 330 described with reference to FIG.

At step 810, Leaf Chain A 320 may receive a coin exchange request (remittance request) from User a to User b of Leaf Chain B 330. At this time, the leaf chain A320 may grasp the balance of the user a and record it in the block of the leaf chain A320 if the coin exchange request is normal. The exchange-requested coin (remittance-requested coin) may be deducted from user a's balance by the leaf chain manager contract included in leaf chain A 320, and may be locked from use. For example, the leaf chain manager contract of the leaf chain A320 confirms the balance of the user a and the balance of the service requesting the remittance by the amount requested for remittance, and then locks the amount deducted from the currency amount of the leaf chain A320 so that it is not used. can be set. Information about the deducted usera amount may be recorded in an escrow contract. A record of such a successful transfer may be recorded in Kafka 442 by producer 441 . If the remittance request is not normal, the leaf chain A320 may record the details of the failure of the remittance request in a block. Also, Leaf Chain A 320 may prevent remittance from occurring by not recording an event when a remittance request fails.

In step 820 , the interchain consumer 443 may detect a remittance request event from the leaf chain A 320 to the leaf chain B 330 and transmit the corresponding remittance request to the root chain 310 . The detection of a remittance request event may be sensed by the transaction collection of the producer 441, and the interchain consumer 443 may transmit the corresponding remittance request to the root chain 310 in response to sensing the sensed remittance request event.

In step 830, the root chain 310 analyzes the total amount of coins issued by the leaf chain A 320 using the remittance request information to check whether the corresponding remittance request is normal. If the remittance request is a normal request, a coin exchange request from the leaf chain A320 to the leaf chain B330 may be recorded in the block. A redemption request may be locked from being used for the amount of coins to be transferred. In addition, the root chain 310 may record failure details in a block when the corresponding remittance request is not a normal request. A remittance request recorded as a failure may be detected again as a remittance failure event by the interchain consumer 443 and transmitted to the leaf chain A320, and the leaf chain A320 receiving the remittance failure event unlocks the locked coins. It may be returned to user a again.

In step 840, the interchain consumer 443 may detect a remittance request event from the root chain 310 to the leaf chain B330 and transmit the corresponding remittance request to the leaf chain B330. If the leaf chain B330 does not operate normally and the call fails, the contents of the transmission failure due to the system failure of the leaf chain B330 may be sent to the root chain 310 again. A request recorded as a failure may be detected again as a remittance failure event by the interchain consumer 443 and transmitted to the leaf chain A320. You may return it to user a.

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

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

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

At stage 880, interchain consumer 443 may sense the remittance result event processed by root chain 310 and communicate the result to leaf chain A 320.

At step 890, the leaf chain A320 receives the remittance result, and if successful, may release the locked coins and adjust the total currency amount of the leaf chain A320 (subtract the remittance amount from the total currency amount). . If the remittance fails, Leaf Chain A 320 may unlock the locked coin and return it to user a. Leaf Chain A 320 may record such remittance results in a block together with the hash recorded in Root Chain 310 .

FIG. 9 is a diagram showing the flow of coin exchange data by smart contracts between chains in one embodiment of the present invention.

(1) When the DApp1 (920) of the leaf chain A320 receives the coin exchange request of the user a, the DApp1 (920) may make an exchange request to the leaf chain manager contract A910. The leaf chain manager contract A 910 generates an exchange transaction hash (eTxHash), exchange transaction hash, user a (identifier of) trying to send money and service a (identifier of), service b (identifier of) receiving money transfer and user b (identifier of), amount information (remittance amount), and/or request time (generate remittance request record (escrow information)). At this time, the leaf chain manager contract A 910 may subtract the holding amount of user a from the total currency amount of the contract of DApp1 (920).

(2) Producer 441 may collect the transaction generated in (1), and Interchain Consumer 443 may request remittance from Leaf Chain A contract 412 of Root Chain 310 .

(3) Leaf chain A contract 412 may individually record remittance request information to root chain 310 by root chain manager contract 411 . At this time, the total currency amount of DApp1 (920) managed by the leaf chain manager A contract 412 may be subtracted by the remittance amount.

(4) Producer 441 may collect the transactions generated in (3), and Interchain Consumer 443 may request remittances to Leaf Chain Manager Contract B940 of Leaf Chain B330, which has services to receive remittances.

(5) Leaf chain manager contract B 940 of leaf chain B 330 may call DApp3 (950), which is the service to be remitted, and remit to user b from the contract of DApp3 (950). At this time, the contract of DApp3 (950) may also increase the total currency amount of Leaf Chain B330.

(6) Producer 441 may collect the transaction generated in (5), and Interchain Consumer 443 may request Leaf Chain B contract 413 of Root Chain 310 to complete remittance.

(7) The leaf chain B contract 413 of the root chain 310 may import the escrow (remittance request record) information of the corresponding remittance request to the root chain manager contract 411 to process the remittance completion. If the remittance is successful, the DApp 3950 managed by the leaf chain B contract 413 may increase the total currency amount of the leaf chain B 330 by the remittance amount, and the corresponding remittance request record is deleted from the root chain manager contract 411 of the root chain 310. may be If the remittance fails, DApp1 (920), which is the remittance requesting service registered in the leaf chain A contract 412, may increase the total currency amount of the leaf chain A 320 again by the remittance amount, and then the root chain 310 , the corresponding remittance request record may be deleted from the root chain manager contract 411 of .

(8) The producer 441 may collect the transaction generated in (7), and the interchain consumer 443 may request the remittance completion to the leaf chain manager contract A910 of the remitted leaf chain A320.

(9) Leaf Chain Manager Contract A 910 of Leaf Chain A 320 may receive the remittance completion information, record that the corresponding exchange transaction hash is completed, and delete the corresponding request in the remittance request record. If the remittance fails, Leaf Chain Manager Contract A 910 may return the amount in the remittance request record to User A again, and increase the total currency amount of DApp1 (920) by the remittance amount again, and then send the remittance request. You may delete the request from your records.

Depending on the embodiment, a relay may exist for each chain. For example, as described with reference to FIG. 4, if there is one root chain 310 and two leaf chains 320 and 330, three relay layers for a total of three chains may be configured. In this case, the relays of root chain 310 may handle the communication of requests, data, and/or events to and from two leaf chains 320 and 330, and the relays of each of the two leaf chains 320 and 330 are connected to root chain 310. may process the communication of requests, data, and/or events with At this time, in order to prevent collusion of relayers for leaf chains, the chains connected to each relayer may be dynamically changed for each preset time period (eg, block time period). In such an embodiment, the hash may prevent the exchange transaction from being intercepted or modulated in the middle by the relayer as it travels between chains due to the hash time lock contract. Such hashed time locks may be utilized to provide a time period during which the user can directly confirm the outcome of the exchange transaction. Also, the individual exchange transaction identifier may be leveraged as a unique identifier to prevent unintentional duplicate payments by the relayer. Such exchange transaction identifiers may be leveraged to uniquely identify and track exchange transactions when there is value movement between leaf chains.

When transmitting data between chains in the blockchain network 300, the transmitting system may modulate the transmitted data. As an example, the possibility exists to modulate data in leaf chain A 320 when communicating data from leaf chain A 320 to root chain 310 . In particular, if a relay is implemented for each leaf chain to ensure that the leaf chain is in the form of a public blockchain, it is necessary to reduce the dependence on such relays and solve the problem of data authentication at the protocol end. . To this end, the blockchain network 300 has the following five requirements.

1. It must be possible to transfer base coins between chains. Here, the base coin may mean a coin used in a unique coin system of the blockchain network 300.

2. The root chain must manage the base coin of all chains. At this time, base coin management may include base coin transfers between chains.

3. The relayer must modulate the data so that it cannot be transmitted.

4. Although remittance was received from the leaf chain and the remittance to the user was successful, duplicate payments should not occur by transmitting a failure message.

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

Due to such requirements, the root chain may allow base coin mints and burns to occur by authorized users. Alternatively, an authorized user may be verified by the multisig wallet to have the base coin minted or burned. At this time, the leaf chain may issue coins when the root chain receives a coin issue request. Also, when transferring money from one leaf chain to another leaf chain, minting and burning may be performed after confirming that the authenticated information of the root chain has been transmitted between the two leaf chains. For example, a leaf chain that sends base coins may burn the corresponding base coins, and a leaf chain that receives base coins may mint the corresponding base coins.

On the other hand, in order to prevent relay layer data modulation, data to be transmitted must not be modulated. A method for blocking data modulation will be described below.

In the first method, the original data to be transmitted may be signed. If the data from user is a known user in the chain from which the data is intended to be received, the modulation state of the original data may be verified based on the signed original data. To this end, a contract may be created with its own private key and may publish a public key corresponding to the private key. At this time, information that needs to be transmitted from the contract to another chain may be signed and recorded as an event, thus proving that the original data has been processed from the corresponding contract. For example, a contract may sign the original data and its contract address with the contract's private key. In this case, any user may verify the signed original data using the public key corresponding to the private key of the contract, and the contract address of the contract, which is uniquely generated on all chains, It may be proved that the data was transmitted by the contract of However, in the first method, the contract private key must be stored in the contract database, and the database is shared and open in the blockchain network, so that all nodes in the chain share the private key, Therefore, it is no longer a private key.

In the second method, instead of storing the private key in the contract, the private key representing one chain is shared with the C-nodes, which are consensus nodes in the same chain, and chain authentication is required. It may be made available at times. As an example, each chain may maintain a private key shared by n (in one example, n is 4-8) C-nodes for consensus. A user or other contract may request data to be signed by the system for that chain (for example, a system contract installed on that chain), and the system will sign the requested data and You may provide the data At this time, the contract of the corresponding chain may record the event of data signing and delivery, and may deliver the signed data to another chain through the relay layer. For example, a public address, which is an identification value generated by a public key paired with a private key of the root chain in the root chain, is recorded in the genesis block of the leaf chain, so that it cannot be modulated in the leaf chain. Data signed by the root chain with a private key can be compared with the public address recorded in the genesis block on the leaf chain to verify that the signed data originated from the root chain. . Similarly, a leafchain may also register a public address generated by the leafchain's private key with a leafchain contract established in association with that leafchain on the rootchain. In this case, the root chain compares the data signed by the leaf chain with the private key of the leaf chain and the public address registered in the corresponding leaf chain contract, and the signed data is sent from the corresponding leaf chain. It may be verified that the However, the second method can be used with private blockchains where private keys can be shared by C-nodes for consensus, but public blockchains exposed for the provision of external services (public leaf chains). chain) cannot be used.

A third method is to leverage a unique private key that every C-node in the root chain has for consensus purposes. As an example, if the root chain contains 8 Cnodes, there may be 8 private keys. In this case, the public addresses of all C-nodes of the root chain generated by that private key may be stored in each of the leaf chains. At this time, the data that needs to be verified as being generated in the root chain can be signed by the root chain leader node with its own private key and recorded in the block, and the corresponding data is transferred to the leaf chain. It may be transmitted. Here, the leader node may be a node arbitrarily selected from among the C-nodes, and may be changed to one of other C-nodes if necessary. In this case, the LeafChain can verify that the signed data was sent from the RootChain by comparing the signed data with the public address stored in the LeafChain. As mentioned above, the leaf chain knows the public addresses of all C nodes of the root chain, so the public address obtained when verifying the signed data is the known public address of the C nodes of the root chain. The signed data may be verified by verifying that it is one of them. However, if the number of C-nodes included in the root chain is disclosed and changes such as addition or deletion of C-nodes to the root chain occur, the information recorded in each leaf chain must be updated. In particular, since the information recorded in the public blockchain (public leaf chain) allocated for external services cannot be directly updated, information is provided to update the information recorded in the relevant public blockchain. (Publicize information to enable updating of public addresses). Similarly, leaf-chain C-nodes may also have unique private keys for consensus, and such private keys may be leveraged. In this case, the public address of each C node may be registered in a leaf chain contract established in relation to the corresponding leaf chain in the root chain, and the root chain is registered in the corresponding leaf chain contract with the signed data. By comparing the signed public address, it may be verified that the signed data originated from the relevant leaf chain.

A fourth method is to share a representative public address (Common Public Address) generated by combining public addresses generated by all C nodes of the root chain to all leaf chains. Even in this case, if a change such as adding or deleting a C node occurs in the root chain, the information recorded in each leaf chain must be updated, but must be shared by each leaf chain. It has the advantage that the number of public addresses that do not need to be shared can be reduced to one representative public address, and the number of C-nodes included in the root chain is not disclosed. However, since the representative public address will be changed, security must be taken care of when changing. In the fourth method, every C-node must know every public address of every C-node in the root chain. In the fourth method, even if there are multiple private keys, one public address (representative public address) can be generated, and the encryption can be decrypted by confirming one or more private keys. As such, a module is required that modifies the algorithm for signing and the algorithm for verifying it.

In the fifth method, the following functions are added to the blockchain to enable the first method to be used. In a fifth method, the contract may generate the contract address with the public key and encrypt the private key for storage by the contract. The private key is known, the private key allows the public key to be obtained, and the public key allows the contract address to be generated. At this time, there is no problem even if only one contract for signing (hereinafter referred to as a signable contract) exists in one chain. For example, when establishing a signable contract, an encrypted private key and a public key generated from the private key may be passed as parameters to the signable contract. A signable contract may generate a contract address with a received public key. At this time, if the same contract address exists, the contract address generation fails. The encrypted private key may be decrypted by a password described below and stored in a database by a signable contract. At this time, when an arbitrary 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 are passed to the signable contract as parameters. you can At this time, information from all requests in the blockchain (for example, requests using HTTPS (Hypertext Transfer Protocol Secure)) is recorded in blocks or logs, but passwords should not be saved/recorded anywhere. Therefore, in a fifth method, password parameters may be defined as types that are not stored/recorded anywhere, such as blocks or logs (hereinafter "secure types"). Such password parameters may be backed by the corresponding blockchain. In this case, the signable contract may, after restoring the password-encrypted private key, sign the input data using the restored private key, and return the signed result (signed data). You may return it to the contract that requested the signature. The contract address of the signable contract may be recorded in the genesis block of each leaf chain. However, in the fifth method, secure types must be defined and leveraged separately on the system, encrypted private and public keys must be generated and provided outside the system, Since the private key is encrypted and transmitted, it is not possible to verify whether the private key was successfully generated and transmitted. In order for the leaf chain to prove that the data is sent from the root chain, the leaf chain asks the root chain whether the signable contract that signed the data is the contract installed in the root chain. It can be grasped immediately, and if it is proved that the corresponding signing contract is a contract that exists in the contract in the root chain, it is proved that the signed data is the data generated or processed in the root chain. Become so.

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

FIG. 11 is a diagram illustrating an example process of signing data in one embodiment of the present invention. FIG. 11 shows an example of a signable contract 1010 receiving signature requests from users or other contracts 1110 . At this time, the signature request may include the data for signing and the password for decrypting the encrypted private key 1020 described in FIG. In this case, the signable contract 1010 may use the password to decrypt the encrypted private key 1020 to obtain the private key, and use the decrypted private key to sign the data conveyed as parameters. you can The signable contract 1010 may then return the signed data to the user or other contract 1110 as a result. Here, the user may correspond to the corresponding blockchain node.

In the sixth method, the signable contract of the fifth method may be automatically installed by the blockchain's system contract. In other words, when the blockchain system contract is installed, the signable contract may also be installed. For example, the node that first generates the system contract, such as the leader node, may generate the private key and install the signable contract. The generated private key may be encrypted by a signable contract and stored in a database, and the password for decrypting the encrypted private key is encrypted by the node's public key and stored in the node's public key. May be stored locally. Other nodes may copy the transaction and search for nodes that know the latest password. At this time, other nodes may transmit their public key to the node to be searched, receive the password encrypted by the public key, and store it locally in the corresponding other node. Each node, when requesting a signature, may obtain the password by decrypting its locally stored encrypted password with its own public key, and signs the resulting password as a parameter of the signature request function. It may be transmitted to a possible contract. Requests may be processed using a signature API or function provided by the blockchain. The public address of the signable contract may be recorded in the genesis block of each leaf chain. A signable contract may be leveraged to prove that data is sent from the root chain.

FIG. 12 is a diagram showing another example of the process of installing a signable contract in one embodiment of the present invention. FIG. 12 shows an example where a signable contract 1210 encrypts a node-generated private key with the node's public key 1220 and stores it in database 1230 . At this time, the signable contract 1210 may encrypt a 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 may be stored locally on the node.

FIG. 13 is a diagram showing another example of the process of signing data in one embodiment of the present invention. FIG. 13 shows an example in which the node 1310 obtains the password by decrypting the encrypted password using the private key of the node 1310, and then transmits the obtained password as a parameter to the system 1320 to request data signature. there is Here, 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 the data using the password. In this case, signable contract 1210 may decrypt the password-encrypted private key, sign data using the decrypted private key, and then return the signed data. System 1320 may communicate the returned signed data to node 1310 .

On the other hand, the leaf chain must ensure that the internally processed content and the transmitted content do not differ. For this purpose, the proof hash list of the Merkle tree of the transaction that processed the remittance must be transmitted as an event along with the processing result. If there is a watcher, we need to decide whether to propagate the Merkle tree credentials. The event information to be transmitted may be signed with the private key of the contract and recorded in the event. , may require a watcher. At this point, the observer may check whether the block exists and whether the transfer succeeded or failed, along with the data that the transaction conveyed as an event. A penalty may be provided to the leaf chain in question if fraud is discovered by the patrol. Here, the watchers may be implemented in the form of nodes that perform the functions described above.

FIG. 14 is a diagram showing another example of the coin exchange method in one embodiment of the present invention. Coin exchange in the same service of the same chain and coin exchange between different services in the same chain are as described with reference to the embodiment of FIG. FIG. 14 shows a different embodiment than that of FIG. 8, showing root chain 1410, leaf chain 1 (1420), and leaf chain 2 (1430), where user 1 of leaf chain 1 (1420) requests a remittance to User 2 of Leaf Chain 2 (1430).

Process 1 is an example of a process in which leaf chain 1 (1420) confirms whether the remittance request is normal, and then transmits information on the remittance request to root chain 1410 if there is no problem.

Process 2 is a process of confirming whether the remittance request is normal in the root chain 1410 and, if there is no problem, transmitting a confirmation request regarding whether remittance is possible to the leaf chain 2 (1430). For example.

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

Process 4 is an example of a process in which the root chain 1410 issues receipts to each of the leaf chains 1 (1420) and 2 (1430) to deduct or increase the remittance amount. Process 4.1 is an example of a process in which the root chain 1410 issues a receipt for deducting the remittance amount to the leaf chain 1 (1420), and process 4.2 is an example of the process in which the root chain 1410 issues a receipt to the leaf chain 2 (1430). This is an example of the process of issuing a receipt for increasing the remittance amount. Each chain may be managed so that duplicate deductions and duplicate increases do not occur.

The configuration of the smart contract is described below.

Smart contracts may include, in the case of the root chain, a root chain manager contract, as described with reference to FIG. 4, and may include a contract for each leaf chain. On the other hand, a leafchain may contain a leafchain manager contract and a DApp contract if a service DApp is present, or a leafchain manager contract if a service DApp is not present. The root chain manager contract and the leaf chain manager contract are system contracts and may be automatically installed when the blockchain is installed. Relayers may filter event logs and propagate them to their respective chains. Each chain may manage so that relayers cannot modulate the data. As mentioned above, the root chain may store the public address generated by each leaf chain's private key, and the leaf chains store the public address generated by the root chain's unique private key in the genesis block. You may record when All information conveyed by relayers may be conveyed together with information signed by the unique private key of the root chain.

Also, if a service DApp exists in the leaf chain, the user may call a function that defines the "exchange" of the DApp. At this time, the DApp may call the 'exchange' defined in icx, and the 'exchange' function should be implemented in the icx class.

On the other hand, the information required for inter-chain remittance is as follows.

・from user: user who sends money ・origin: service or leafchain that requested money transfer ・to user: user that receives money transfer ・destination: service or leafchain that receives money money ・value: money transfer amount (base coin)
・eTxHash: remittance transaction hash ・message: remittance message ・eSignature: signature of leaf chain requesting data transfer Here, the signature of the leaf chain is a combination of from user, origin, to user, destination, value, eTxHash, and message. may contain a value signed by

FIG. 15 is a flow chart showing a first example of a data authentication method in one embodiment of the invention. The data authentication method according to this embodiment may be executed by the computer device 200 that implements a node of the blockchain network. For example, processor 220 of computing device 200 may be implemented to execute control instructions according to the code of an operating system and the code of at least one program contained in memory 210 . Here, processor 220 may control computing device 200 such that computing device 200 performs steps 1510-1540 included in the method of FIG. 15 according to control instructions provided by code recorded in computing device 200. .

At step 1510, the computing device 200 may share the private key representing the chain of the blockchain network with at least one other node participating in the consensus on the blockchain network. At this time, the node may be one of a plurality of nodes preset to make consensus on the blockchain network, and at least one other node may also make consensus on the blockchain network. may be included in a plurality of nodes preset to .

The data authentication method according to the present embodiment is the second method described above, and the process of sharing one private key representing the chain with the C nodes of the corresponding chain and using it for chain authentication will be described. In other words, a computing device 200 implementing one node may share with at least one other node a private key representative of the chain of blockchain networks in which the node implemented by computing device 200 participates.

At step 1520, the computing device 200 may generate a public address for the blockchain network using the public key generated using the private key. As noted above, the public address may be provided to verify that data signed by the private key originated from the blockchain network in question.

As 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, by comparing the signed data in the leaf chain where the signed data was sent and the public address recorded in the genesis block of the leaf chain, it is possible to confirm that the signed data was sent from the root chain. You can verify that there is

As another embodiment, the blockchain network may include a first leaf chain of multiple leaf chains whose data transmission is managed by a root chain. In this case, the computing device 200 may register the generated public address with the leaf chain contract installed in the root chain in association with the first leaf chain. At this time, by comparing the data signed in the root chain with the public address registered in the corresponding leaf chain contract, it is verified that the signed data was sent from the first leaf chain. good.

At step 1530, the computing device 200 may sign data to be transmitted from the blockchain network to another blockchain network with a private key according to a contract installed in the blockchain network. At this time, a block containing the signed data may be added to the chain of the blockchain network.

At step 1540, computing device 200 may communicate the signed data to other blockchain networks by way of the contract. A comparison of the signed data with the public address may then verify that the signed data originated from the blockchain network.

FIG. 16 is a flow chart showing a second example of a data authentication method in one embodiment of the invention. The data authentication method according to this embodiment may be executed by the computer device 200 that implements a node of the blockchain network. For example, processor 220 of computing device 200 may be implemented to execute control instructions according to the code of an operating system and the code of at least one program contained in memory 210 . Here, processor 220 may control computing device 200 such that computing device 200 performs steps 1610-1630 included in the method of FIG. 16 according to control instructions provided by code recorded in computing device 200. .

At step 1610, computing device 200 may generate the node's public address using the node's private key. A node's private key may be a unique private key that the node has for consensus on the blockchain network.

At step 1620, the computing device 200 may use the node's private key to sign data to be transmitted from the blockchain network to another blockchain network. At this time, a block containing the signed data may be added to the chain of the blockchain network.

At step 1630, computing device 200 may communicate the signed data to other blockchain networks. The public address may then be used to verify that the signed data originated from the blockchain network.

In one embodiment, a blockchain network may include a root chain that manages data transmission between multiple leaf chains. At this time, the public addresses generated by each of the plurality of nodes (the plurality of nodes including the node realized by the computer device 200 according to the present embodiment) set in advance so as to make an agreement in the blockchain network are the plurality of leaf chains. may be stored separately. In this case, by comparing the signed data in the first leaf chain where the signed data was sent and the public addresses of each of the multiple nodes stored in the first leaf chain, the signed data is identified as the root chain. You may verify that it was shipped from

In other embodiments, a blockchain network may include a first leaf chain of multiple leaf chains with data transmission managed by a root chain. At this time, the public addresses generated by each of the plurality of nodes (the plurality of nodes including the node realized by the computer device 200 according to the present embodiment) set in advance so as to make an agreement in the blockchain network are attached to the root chain. It may be registered with a leaf chain contract established in association with the first leaf chain. In this case, it may be verified 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 still other embodiments, a blockchain network may include a root chain that manages data transmission between multiple leaf chains. At this time, a combination of public addresses generated by each of a plurality of nodes (a plurality of nodes including the node realized by the computer device 200 according to the present embodiment) set in advance so as to make an agreement in the blockchain network. A representative public address may be stored in each of the multiple leaf chains. In this case, the signed data was sent from the root chain by comparing the signed data on the first leaf chain where the signed data was sent and the representative public address stored on the first leaf chain. You can verify that it is

In still other embodiments, a blockchain network may include a first leaf chain of multiple leaf chains whose data transmission is managed by a root chain. At this time, a combination of public addresses generated by each of a plurality of nodes (a plurality of nodes including the node realized by the computer device 200 according to the present embodiment) set in advance so as to make an agreement in the blockchain network. A representative public address may be registered with a leaf chain contract established in association with a first leaf chain on the root chain that handles intermediation between the root chain and leaf chains. In this case, by comparing the data signed in the root chain with the representative public address registered in the corresponding leaf chain contract, it is verified that the signed data was sent from the first leaf chain. you can

FIG. 17 is a flow chart showing a third example of a data authentication method in one embodiment of the invention. The data authentication method according to the present embodiment may be performed by the computer device 200 operating according to the contract of the blockchain network. For example, processor 220 of computing device 200 may be implemented to execute control instructions according to the code of an operating system and the code of at least one program contained in memory 210 . Here, processor 220 may control computing device 200 such that computing device 200 performs steps 1710-1760 included in the method of FIG. 17 according to control instructions provided by code recorded in computing device 200. . Here, the at least one program code may comprise at least code according to a blockchain network contract.

At step 1710, computing device 200 may receive as parameters an encrypted private key and a public key generated from the private key.

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

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

At step 1740, the computing device 200 may receive a signature request including as parameters the data to be signed and a password for decrypting the encrypted private key. Here, the password may be defined as a secure type that is not stored in blocks of the blockchain network or in any logs.

At step 1750, the computing device 200 may generate signed data by decrypting the password-encrypted private key in response to the signature request and signing the data with the decrypted private key. At this time, a block in which the signed data is recorded may be added to the chain of the blockchain network.

At step 1760, computing device 200 may return the generated signed data. At this time, the signed data may be returned to the node that requested the signing 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, the signed data is sent from the root chain by comparing the signed data in the first leaf chain that receives the signed data with the contract address recorded in the genesis block of the first leaf chain. It may be verified that the

In other embodiments, a blockchain network may include a first leaf chain of multiple leaf chains with data transmission managed by a root chain. At this time, computing device 200 may provide the contract address to the root chain so that the contract address is stored in the root chain's database. In this case, it may be verified that the signed data originated from the first leaf chain by comparing the signed data on the root chain with the contract address stored in the root chain's database. .

FIG. 18 is a flow chart showing a fourth example of the data authentication method in one embodiment of the present invention. The data authentication method according to this embodiment may be executed by the computer device 200 that implements a node of the blockchain network. For example, processor 220 of computing device 200 may be implemented to execute control instructions according to the code of an operating system and the code of at least one program contained in memory 210 . Here, processor 220 may control computing device 200 such that computing device 200 performs steps 1810-1860 included in the method of FIG. 18 according to control instructions provided by code recorded in computing device 200. .

At step 1810, the computing device 200 may encrypt and store the private keys of the nodes of the blockchain network. Here, the node may be a node that is first generated in the blockchain network, and the 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 may be communicated to the signable contract. At this time, the signable contract may encrypt and store the private key of the node transferred during the installation process.

At step 1820, the computing 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 computing device 200 can decrypt the encrypted private key in the process of encrypting the private key. As an example, if the private key is encrypted with a symmetric key, the password may generate the symmetric key and the value to obtain the symmetric key.

At step 1830, the computing device 200 may return to the node the password encrypted by the node's public key. In this case, the node may obtain an encrypted password. At this time, since the encrypted password is encrypted with the public key of the node, it is possible to obtain the password by decrypting the encrypted password with the private key of the node. On the other hand, other nodes in the blockchain network search for the node where the encrypted password has been returned, send the public key of the other node to the corresponding node, and the public key of the other node from the corresponding node An encrypted password may be received and stored in another node. Through this process, other nodes in the blockchain network will also be able to obtain the password to decrypt the encrypted private key. On the other hand, the private key itself does not have to be displayed because it is stored in an encrypted state. A password, on the other hand, may be defined as a secure type that is not stored in blocks of the blockchain network or in any logs.

At step 1840, the computing device 200 may receive a signing request containing as parameters data for signing with a password and a private key from any node of the blockchain network. The arbitrary node may be a node to which the encrypted password is returned from the computer device 200 or another node to which the password is transmitted from the corresponding node.

At step 1850, the computing device 200 may generate signed data by decrypting the password-encrypted private key in response to the signature request and signing the data with the decrypted private key.

At step 1860, computing device 200 may return the signed data. At this time, the signed data may be returned to the node that requested the signing 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, the signed data is sent from the root chain by comparing the signed data in the first leaf chain that receives the signed data with the contract address recorded in the genesis block of the first leaf chain. It may be verified that the

In other embodiments, a blockchain network may include a first leaf chain of multiple leaf chains with data transmission managed by a root chain. At this time, computing device 200 may provide the contract address to the root chain so that the contract address is stored in the root chain's database. In this case, it may be verified that the signed data originated from the first leaf chain by comparing the signed data on the root chain with the contract address stored in the root chain's database. . A root chain may be viewed as an absolute trust system, as described above.

As described above, the embodiments of the present invention provide a data authentication method and system for authenticating data generated in a scalable blockchain by adding leaf chains based on the root chain. be able to.

The systems or devices described above may be realized by hardware components, software components, or a combination of hardware and software components. For example, the devices and components described in the embodiments may include, for example, processors, controllers, ALUs (arithmetic logic units), digital signal processors, microcomputers, FPGAs (field programmable gate arrays), PLUs (programmable logic units), microcontrollers, It may be implemented using one or more general purpose or special purpose computers, such as a processor or various devices capable of executing instructions and responding to instructions. The processing unit may run an operating system (OS) and one or more software applications that run on the OS. The processor may also access, record, manipulate, process, and generate data in response to executing software. For convenience of understanding, one processing device may be described as being used, but those skilled in the art will appreciate that the processing device may include multiple processing elements and/or multiple types of processing elements. You can understand. For example, a processing unit may include multiple processors or a processor and a controller. Other processing configurations are also possible, such as parallel processors.

Software may include computer programs, code, instructions, or a combination of one or more of these, to configure a processor to operate at its discretion or to independently or collectively instruct a processor. You can Software and/or data may be embodied in any kind of machine, component, physical device, virtual device, computer storage medium or device to be interpreted on or to provide instructions or data to a processing device. may be changed. The software may be stored and executed in a distributed fashion over computer systems linked by a network. Software and data may be recorded on one or more computer-readable recording media.

The method according to the embodiments may be embodied in the form of program instructions executable by various computer means and recorded on a computer-readable medium. The computer-readable media may include program instructions, data files, data structures, etc. singly or in combination. The program instructions recorded on the media may be those specially designed and constructed for an embodiment, or they may be of the kind known and available to those of skill in the computer software arts. 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 magneto-optical media such as floptical disks. , and hardware devices specially configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Such a recording medium may be a variety of recording means or storage means in the form of a single or multiple hardware combination, and should not be limited to media directly connected to a computer system, and may be used over a network. It may exist dispersedly. Examples of program instructions include high-level language code that is executed by a computer, such as using an interpreter, as well as machine language code, such as that generated by a compiler.

As described above, the embodiments have been described based on the limited embodiments and drawings, but those skilled in the art will be able to make various modifications and variations based on the above description. For example, the techniques described may be performed in a different order than in the manner described and/or components such as systems, structures, devices, circuits, etc. described may be performed in a manner different from the manner described. Appropriate results may be achieved when combined or combined, opposed or substituted by other elements or equivalents.
Accordingly, different embodiments that are equivalent to the claims should still fall within the scope of the appended claims.

Claims (20)

A data authentication method for a computer device operating by a blockchain network contract, comprising:
receiving, as parameters, an encrypted private key and a public key generated from the private key by at least one processor of said computing device;
generating, by the at least one processor, a contract address with the received public key;
storing, by the at least one processor, the encrypted private key and the contract address in a database;
receiving, by the at least one processor, a signature request including as parameters data to be signed and a password for decrypting the encrypted private key;
generating signed data by the at least one processor in response to the signature request, decrypting the encrypted private key with the password, and signing the data with the decrypted private key; and returning, by the at least one processor, the generated signed data. The data authentication method according to claim 1, characterized in that said password is defined as a secure type that is not stored in any block or in any log of said blockchain network. the blockchain network includes a root chain that manages data transmission between multiple leaf chains;
The data authentication method includes:
3. The method of claim 1 or 2, further comprising recording, by the at least one processor, the contract address in a genesis block of each of the plurality of leaf chains. A first leaf chain that receives the signed data compares the signed data with a contract address recorded in a genesis block of the first leaf chain to determine whether the signed data is removed from the root chain. 4. A data authentication method according to claim 3, characterized by verifying that it was shipped. The blockchain network includes a first leaf chain of a plurality of leaf chains whose data transmission is managed by a root chain;
The data authentication method includes:
5. The step of 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. The data authentication method according to item 1. verifying that the signed data was sent from the first leaf chain by comparing the signed data in the root chain with the contract address stored in the database of the root chain; 6. The data authentication method according to claim 5, characterized in that: The data authentication method according to any one of claims 1 to 6, 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 for a computer device operating by a blockchain network contract, comprising:
encrypting and storing private keys of nodes of the blockchain network by at least one processor included in the computing device;
encrypting and storing, by the at least one processor, a password for decrypting the encrypted private key in the node's public key;
returning, by the at least one processor, to the node a password encrypted with the node's public key;
receiving, by the at least one processor, a signature request including data for signing with the password and the private key as parameters from any node of the blockchain network;
generating signed data by the at least one processor in response to the signature request, decrypting the encrypted private key with the password, and signing the data with the decrypted private key; and returning, by the at least one processor, the signed data. The node installs a signable contract in the process of installing a system contract of the blockchain network as the first node generated in the blockchain network;
9. The data authentication method of claim 8, wherein said data authentication method is performed by a computing device operating with said signable contract. 10. A data authentication method according to claim 8 or 9, characterized in that said password is defined as a secure type that is not stored in any block or in any log of said blockchain network. the blockchain network includes a root chain that manages data transmission between multiple leaf chains;
The data authentication method includes:
The data authentication method according to any one of claims 8 to 10, further comprising: recording a contract address in a genesis block of each of said plurality of leaf chains by said at least one processor. A first leaf chain that receives the signed data compares the signed data with a contract address recorded in a genesis block of the first leaf chain to determine whether the signed data is removed from the root chain. 12. A data authentication method according to claim 11, characterized by verifying that it was shipped. The blockchain network includes a first leaf chain of a plurality of leaf chains whose data transmission is managed by a root chain;
The data authentication method includes:
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 described in Section 3.1. verifying that the signed data was sent from the first leaf chain by comparing the signed data in the root chain with the contract address stored in the database of the root chain; 14. The data authentication method according to claim 13, characterized in that: Another node in the blockchain network searches for a node to which the encrypted password has been returned, transmits the public key of the other node to the node, and uses the public key of the other node from the node. 15. The data authentication method according to any one of claims 8 to 14, wherein an encrypted password is received and stored in said other node. The data authentication method according to any one of claims 8 to 15, further comprising: updating a password for decrypting the private key periodically or at the request of an administrator. A computer program for causing a computer device to perform the method according to any one of claims 1-16. A computer-readable recording medium, characterized in that a computer program for causing a computer device to execute the method according to any one of claims 1 to 16 is recorded. A computer device that operates according to a blockchain network contract,
at least one processor implemented to execute instructions readable by said computing device;
by the at least one processor;
receives as parameters an encrypted private key and a public key generated by the private key,
generating a contract address with the received public key;
store the encrypted private key and the contract address in a database;
receiving a signature request including as parameters data to be signed and a password for decrypting the encrypted private key;
decrypting the encrypted private key using the password and signing the data with the decrypted private key to generate signed data;
A computer device that returns the generated signed data. A computer device that operates according to a blockchain network contract,
at least one processor implemented to execute instructions readable by said computing device;
by the at least one processor;
encrypting and storing private keys of nodes of said blockchain network;
encrypting and storing a password for decrypting the encrypted private key with the public key of the node;
returning to the node a password encrypted by the node's public key;
receiving from any node of the blockchain network a signing request containing as parameters data to be signed by the password and the private key;
generating signed data by, in response to the signature request, decrypting the encrypted private key with the password and signing the data with the decrypted private key;
A computer device that returns the signed data.

Images