Method and system for transmitting message between different blockchains

Abstract

The present invention provides a method for transmitting a message between different blockchains and a system using same, the method comprising: a first step in which a first blockchain system receives a message transmission request signal from a user system; a second step in which the first blockchain system transmits a message verification request signal to a verification system; a third step in which the verification system verifies a block; a fourth step in which the verification system transmits a block information storage request signal to a second blockchain system, and the second blockchain system stores block header information; a fifth step in which the first blockchain system transmits a message occurrence notification signal to a relay system; a sixth step in which the relay system generates message information and transmits the message information to the second blockchain system; a seventh step in which the second blockchain system verifies the message; and an eighth step in which the second blockchain system transmits the message to a recipient's address.

Description

Method and system for transmitting messages between different blockchains

[0001] The present invention relates to a method and system for transmitting messages between different blockchains, and more specifically, to provide a method and system capable of accurately and safely transmitting messages between different heterogeneous blockchain systems.

[0002] As is well known, the blockchain system has the advantage of preventing falsification of transaction history by allowing multiple nodes to share and store transaction history in a distributed ledger without the intervention of a central server.

[0003] Recent blockchain systems, such as Ethereum, Bitcoin, and Arbirtrum, represent a significant number of systems, and since each of these blockchain systems operates independently of one another, technology is needed to connect different types of blockchain systems.

[0004] [Prior Art Literature]

[0005] Republic of Korea Patent No. 10-2530967 (Published on May 15, 2023)

[0006] The purpose of the present invention is to provide a method and system capable of accurately and safely transmitting messages in different heterogeneous blockchain systems.

[0007] In addition, the present invention has another purpose of providing a decentralized trustless bridge between heterogeneous blockchain systems by verifying messages through independently operated verification systems and relay systems.

[0008] According to one aspect of the present invention, a first blockchain system receives a message transmission request signal requesting transmission of a message to a second blockchain system from a user system coupled to the first blockchain system; a second step in which the first blockchain system transmits a message verification request signal to a verification system; a third step in which the verification system verifies a block corresponding to the message verification request signal based on the message verification request signal; a fourth step in which, when block verification is successful, the verification system transmits a block information storage request signal to a second blockchain system, and the second blockchain system stores block header information corresponding to the block information storage request signal; a fifth step in which the first blockchain system transmits a message occurrence notification signal to a relay system; a sixth step in which the relay system generates message information based on the message occurrence notification signal and transmits the message information to the second blockchain system; a seventh step in which the second blockchain system verifies the message based on the message information received in the sixth step and the block header information stored in the fourth step; And if the verification of the message is successful, the second blockchain system provides a method for transmitting a message between different blockchains, including an eighth step of transmitting a message corresponding to the message information to an address of a recipient coupled to the second blockchain system.

[0009] Here, the message transmission request signal of the first step may include an identifier (ID) of the second blockchain system, which is the target blockchain system to which the message is to be transmitted, a final receiving address in the second blockchain system to which the message is to be transmitted, and message data to be transmitted.

[0010] In addition, the message verification request signal of the second step may include message verification request information, and the message verification request information may include an identifier (ID) of a second blockchain system that is a target blockchain system to which the message is to be transmitted, a block number in the first blockchain system where the message is generated, information indicating the entity that generated the message, information indicating the entity that transmitted the message, a final receiving address of a recipient to whom the message is to be transmitted in the second blockchain system, and message data to be transmitted.

[0011] In addition, the verification system may include a verification master unit and a plurality of verification nodes, and the third step may include a step 3-1 in which the verification master unit generates transaction signature data based on the message verification request information; a step 3-2 in which the verification master unit transmits the message verification request information to the plurality of verification nodes and receives transaction signature data from the plurality of verification nodes; and a step 3-3 in which the verification master unit verifies a block based on the transaction signature data.

[0012] In addition, the step 3-1 may include a step in which the verification master unit confirms the block number in which the message was generated from the message verification request information, requests block information corresponding to the confirmed block number to the first blockchain system that transmitted the corresponding message verification request signal, and receives the block information from the first blockchain system; a step in which the verification master unit extracts block header information from the received block information; and a step in which the verification master unit generates transaction signature data that transmits the extracted block header information to a second blockchain system so that the second blockchain system can store it, and the step 3-2 may include a step in which each of the plurality of verification nodes confirms the block number in which the message included in the message verification request information was generated, requests block information corresponding to the confirmed block number to the first blockchain system that transmitted the corresponding message verification request signal, and receives the block information from the first blockchain system; a step in which each of the plurality of verification nodes extracts block header information from the received block information; and a step in which each of the plurality of verification nodes generates transaction signature data that transmits the extracted block header information to the second blockchain system so that the second blockchain system can store it, and transmits the transaction signature data to the verification master unit.

[0013] Additionally, the block header information may include block hash information, which is a hash value of the block, and Rishitz hash information, which is a hash value of event log record data proving the execution results of all transactions of the block.

[0014] In addition, in the above step 3-3, the verification master unit can determine that the verification is successful if more than half of the transaction signature data transmitted from the plurality of verification nodes and the transaction signature data generated by the verification master unit match.

[0015] In addition, in the fourth step, if the verification is successful, the verification master unit can transmit a block information storage request signal including the transaction signature data it has generated and the transaction signature data transmitted from multiple verification nodes to the second blockchain system.

[0016] In addition, the fourth step may allow the second blockchain system to execute a transaction by transaction signature data included in the block information storage request signal, extract block header information by the execution result, and store the extracted block header information.

[0017] Additionally, the block header information may include block hash information and Rishitz hash information.

[0018] In addition, the message occurrence notification signal of the fifth step may include message verification request information, and the message verification request information may include an identifier (ID) of a second blockchain system that is a target blockchain system to which the message is to be transmitted, a block number in the first blockchain system where the message is generated, information indicating the entity that generated the message, information indicating the entity that transmitted the message, a final receiving address of a recipient to whom the message is to be transmitted in the second blockchain system, and message data to be transmitted.

[0019] In addition, the sixth step may include a step in which the relay system confirms the block number in which the message was generated from the message verification request information, requests block information corresponding to the confirmed block number from the first blockchain system, and receives the block information from the first blockchain system; and a step in which the relay system generates message information based on the received block information and transmits the generated message information to the second blockchain system.

[0020] In addition, the message information includes message data and validation information for validating the validity of a block including the message, and the validation information may include block hash information of a block in which the message occurred and information related to the lisits of a transaction including the message.

[0021] In addition, the validation information may include an identifier of the first blockchain system transmitting the message, a block hash of a block in which the message occurred in the first blockchain system, a hash encoding information encoding the hash of a transaction including the message, hash order information encoding the order in which the hash occurred, stack information encoding all hashes of a block including the message, and message order information in which the message occurred.

[0022] In addition, the seventh step may include a seventh step in which the second blockchain system verifies the message based on the message information received in the sixth step and the block header information stored in the fourth step; a seventh step in which the second blockchain system determines whether the Lisitz hash extracted from the validation information is included in the block header information stored in the fourth step; and a seventh step in which the second blockchain system reassembles the Lisitz hash using Lisitz encoding information and Lisitz order information included in the validation information and determines whether the reassembled Lisitz hash matches the Lisitz hash extracted in the seventh step.

[0023] In addition, the step 7-1 can generate a Lisitz hash by decoding the stack information included in the validation information.

[0024] According to another aspect of the present invention, a message transmission system between different blockchains is provided, including: a first blockchain system, when a message transmission request signal requesting transmission of a message from a user system to a second blockchain system is received, transmits a message verification request signal to a verification system and transmits a message occurrence notification signal to a relay system; a verification system, which verifies a block corresponding to the message verification request signal received from the first blockchain system and, if the block verification is successful, transmits a block information storage request signal to the second blockchain system; a relay system, which generates message information based on the message occurrence notification signal received from the first blockchain system and transmits the message information to the second blockchain system; and a second blockchain system, which stores block header information corresponding to the block information storage request signal received from the verification system, verifies the message based on the message information received from the relay system and the stored block header information, and, if the message verification is successful, transmits a message corresponding to the message information to an address of a recipient coupled to the second blockchain system.

[0025] According to the present invention, an object is to provide a method for accurately and safely transmitting messages in different heterogeneous blockchain systems.

[0026] In addition, according to the present invention, since messages are verified through independently operated verification systems and relay systems, a decentralized trustless bridge can be provided between heterogeneous blockchain systems.

[0027] In addition, according to the present invention, since only the dApp endpoint needs to be expanded regardless of the type of blockchain system, expansion is easy and universality can be provided.

[0028] In addition, according to the present invention, since the verification system and relay system are operated independently from the blockchain system, security can be increased and customization can be performed according to the characteristics of the blockchain system.

[0029] FIG. 1 is a diagram showing the overall environment and connection relationship in which a message transmission method between different blockchains according to one embodiment of the present invention is performed.

[0030] FIG. 2 is a flowchart illustrating a method for transmitting messages between different blockchains according to one embodiment of the present invention.

[0031] Figure 3 illustrates an example of message verification request information.

[0032] Figure 4 shows an example of the structure of a verification system (300).

[0033] Figure 5 shows an example of validation information.

[0034] Hereinafter, an embodiment of the present invention will be described in detail with reference to the attached drawings.

[0035] FIG. 1 is a drawing showing the overall configuration and connection relationship of a message transmission system (1000) that performs a message transmission method between different blockchains according to one embodiment of the present invention.

[0036] Referring to FIG. 1, a message transmission system (1000) between different blockchains includes a first blockchain system (100), a second blockchain system (200), a verification system (300), and a relay system (400).

[0037] In this specification, the first blockchain system (100) and the second blockchain system (200) are defined as different heterogeneous blockchain systems.

[0038] For example, the first blockchain system (100) may be an Ethereum-based blockchain system, and the second blockchain system (200) may be an Arbitrum-based blockchain system.

[0039] Hereinafter, the first blockchain system (100) is defined as a source blockchain system that transmits a message, and the second blockchain system (200) is defined as a destination blockchain system that receives a message from the first blockchain system (100).

[0040] Referring to FIG. 1, the first blockchain system (100) and the second blockchain system (200) are coupled with a verification system (300) and a relay system (400), and in conjunction with these, messages are transmitted from the first blockchain system (100) to the second blockchain system (200).

[0041] Here, the verification system (300) and the relay system (400) are off-chain entities, not on-chain entities that are directly coupled with the first blockchain system (100) and the second blockchain system (200).

[0042] Additionally, the verification system (300) and the relay system (400) are independent entities that operate separately from each other and do not transmit or receive information between each other.

[0043] Additionally, in the present invention, “message” means all types of information that can be transmitted and received between blockchain systems (100, 200).

[0044] The first blockchain system (100) includes a message communication unit (110), a block header storage unit (120), and a validity verification unit (130).

[0045] The second blockchain system (200) also includes a message communication unit (210), a block header storage unit (220), and a validity verification unit (230).

[0046] Here, the message communication unit (110, 210), block header storage unit (120, 220), and validation unit (130, 230) are on-chain entities provided in the form of smart contracts in each blockchain system (100, 200).

[0047] As is well known, a smart contract is a code that can be executed on a blockchain system such as Ethereum, and as this is well known in the art, a detailed description thereof will be omitted.

[0048] Hereinafter, a method of transmitting messages between different blockchains under such a configuration is described with reference to FIG. 2 and below.

[0049] FIG. 2 is a flowchart illustrating a method for transmitting messages between different blockchains according to one embodiment of the present invention.

[0050] Referring to FIG. 2, first, the message communication unit (110) of the first blockchain system (100) receives a message transmission request signal requesting transmission of a message from a user system (not shown) to the second blockchain system (200) (S100).

[0051] Here, the user system that transmitted the message transmission request signal is coupled with the first blockchain system (100), and the message transmission request signal may include an identifier (ID) of the target blockchain system to which the message is to be transmitted, i.e., the second blockchain system (200), the final receiving address in the second blockchain system (200) to which the message is to be transmitted, and the message data to be transmitted.

[0052] The user system may be a terminal such as a computer or a smartphone, and transmits a message transmission request signal to a Dapp Contract, which is a smart contract pre-distributed to the first blockchain system (100), through a Dapp interface, and the Dapp Contract may transmit the received message transmission request signal to a message communication unit (110).

[0053] The message communication unit (110) that receives the message transmission request signal transmits a message verification request signal to the verification system (300) based on the message transmission request signal.

[0054] Here, the message verification request signal includes message verification request information.

[0055] Figure 3 illustrates an example of message verification request information.

[0056] As shown in Fig. 3, message verification request information can be configured as a double tuple structure in the form of (destChainId, (block.number, tx.origin, msg.sender, destAddressBytes, destData)).

[0057] Here, destChainId is the identifier (ID) of the target blockchain system to which the message is to be transmitted, i.e., the second blockchain system (200), and block.number means the block number in the first blockchain system (100) where the message was generated.

[0058] Additionally, tx.origin is information indicating the entity that generated the message, which may be the account information that initially generated the message. This may be, for example, the user's EoA (externally owned account).

[0059] Additionally, msg.sender is information indicating the entity that sent the message, and may be account information that sent the message to the verification system (300). This may be EoA or CA (Contract Account).

[0060] Additionally, destAddressBytes represents the final receiving address of the recipient in the second blockchain system (200) to which the message is to be delivered, and destData represents the message data to be transmitted.

[0061] The verification system (300) that receives this message verification request signal verifies the block corresponding to the message verification request signal (S120).

[0062] The verification system (300) determines which block among the blocks stored in the first blockchain system (100) is to be verified based on the message verification request information included in the message verification request signal, performs verification on the block, and if the verification is successful, determines which target blockchain system the verification result is to be stored in, and transmits a block information storage request signal to the corresponding blockchain system, i.e., the second blockchain system (200) (S130).

[0063] Figure 4 shows an example of the structure of a verification system (300).

[0064] Referring to FIG. 4, the verification system (300) includes a verification master unit (310) and a plurality of verification nodes (321, 322, ...32n).

[0065] As described above, the verification system (300) is an off-chain entity separate from the first and second blockchain systems (100, 200) and can be implemented as its own blockchain system. In this case, the verification master unit (310) and multiple verification nodes (321, 322, ...32n) can be implemented as smart contracts within the blockchain system.

[0066] The verification master unit (310) extracts block header information based on message verification request information included in the message verification request signal and generates transaction signature data.

[0067] In addition, message verification request information is transmitted to multiple verification nodes (321, 322, ...32n) and transaction signature data is received from multiple verification nodes (321, 322, ...32n), and then blocks are verified based on these.

[0068] Additionally, if block verification is successful, the verification master unit (310) generates a block information storage request signal and transmits it to the second blockchain system (200).

[0069] The verification master unit (310) can operate as follows.

[0070] First, the verification master unit (310) verifies the identifier (ID) (destChainId) of the second blockchain system (200), which is the target blockchain system to which the message included in the message verification request information will be transmitted. This is to identify the target blockchain system (200) to which block header information will be transmitted in the future.

[0071] Next, the verification master unit (310) verifies the block number (block.number) in which the message included in the message verification request information occurred, requests block information corresponding to the confirmed block number from the first blockchain system (100) that transmitted the message verification request signal, and receives the block information from the first blockchain system (100).

[0072] The verification master unit (310) extracts block header information from the received block information.

[0073] Here, the block header information may include block hash information and Rishitz hash information.

[0074] The blockHash information is the hash value of the block, and the receiptsHash information is the hash value of the event log data that proves the results of all transactions executed in the block. Using these receipts hashes, all events occurring in a block can be verified, allowing the authenticity of the block being verified to be verified.

[0075] And, the verification master unit (310) transmits the extracted block header information to the second blockchain system (200) and generates transaction signature data so that it can be stored in the second blockchain system (200).

[0076] Meanwhile, the verification master unit (310) transmits message verification request information to multiple verification nodes (321, 322, ...32n).

[0077] Multiple verification nodes (321, 322, ...32n) perform the same operation as the verification master unit (310) described above based on the received message verification request information.

[0078] That is, each of the plurality of verification nodes (321, 322, ...32n) checks the block number (block.number) in which the corresponding message included in the message verification request information occurred, requests block information corresponding to the confirmed block number from the first blockchain system (100) that transmitted the corresponding message verification request signal, and receives the block information from the first blockchain system (100).

[0079] Additionally, each of the plurality of verification nodes (321, 322, ...32n) extracts block header information from the received block information.

[0080] And, each of the plurality of verification nodes (321, 322, ...32n) generates transaction signature data and transmits it to the verification master unit (310) so that the extracted block header information can be transmitted to the second blockchain system (200) for storage.

[0081] In addition, the verification master unit (310) verifies the block based on transaction signature data transmitted from multiple verification nodes (321, 322, ...32n) and transaction signature data generated by itself. This can be implemented as a multi-sig wallet, for example, in which verification is deemed successful if more than half of the nodes agree using the "K of N" consensus method.

[0082] This means that if K or more agreements are reached among N verification nodes, verification is considered successful, where N is the number of verification nodes, and K is a preset integer, which can be an integer greater than or equal to a majority of N.

[0083] If verification is determined to be successful, the verification master unit (310) transmits a block information storage request signal including the transaction signature data it has generated and the transaction signature data transmitted from multiple verification nodes (321, 322, ...32n) to the second blockchain system (200) (S130).

[0084] The block information storage request signal can be transmitted in the form of a transaction for execution of a smart contract in the block header storage unit (220) of the second blockchain system (200).

[0085] Referring again to FIG. 2, the second blockchain system (200) receives a block information storage request signal from the verification system (300) and stores block header information corresponding to the block information storage request signal (S140).

[0086] The block information storage request signal transmitted by the verification system (300) is transmitted to the block header storage unit (220) of the second blockchain system (200), and the block header storage unit (220) of the second blockchain system (200) stores the block header information based on the received block information storage request signal.

[0087] Here, the block header information is information that is extracted as a result of executing a transaction by the transaction signature data included in the block information storage request signal described above, and may include block hash information and Richitz hash information as described above.

[0088] Meanwhile, the block header storage unit (220) may store the block hash information and the Rishitz hash information as block header information when more than half of the extracted block header information matches.

[0089] Meanwhile, the message communication unit (110) of the first blockchain system (100) transmits a message occurrence notification signal to the relay system (400) (S150).

[0090] Here, the message occurrence notification signal may include message verification request information as described above.

[0091] The relay system (400) that receives the message occurrence notification signal generates message information based on the message occurrence notification signal and transmits the message information to the second blockchain system (200) (S160).

[0092] The relay system (400) verifies the block number (block.number) in which the message was generated based on the message verification request information included in the message generation notification signal, requests block information corresponding to the block number verified by the first blockchain system (100), and receives the block information from the first blockchain system (100).

[0093] Then, the relay system (400) generates message information based on the received block information and transmits the generated message information to the second blockchain system (200) (S160).

[0094] Here, message information can be transmitted in the form of a transaction that calls a function for executing a smart contract in the validation unit (230) of the second blockchain system (200).

[0095] The message information includes message data and validation information for validating the block containing the message.

[0096] Validation information is information used to verify validity in the second blockchain system (200) that received the message information, and may include, for example, block hash information of the block in which the message occurred and information related to the lisits of the transaction including the message.

[0097] Figure 5 shows an example of validation information.

[0098] Referring to FIG. 5, the validation information may include an identifier (srcChainId) of the first blockchain system (100) transmitting the message, a block hash (blockHash) of the block in which the message occurred in the first blockchain system (100), receipt encoding information (rlpReceipt) that RLP-encodes receipts of transactions including the message, receipt order information (rlpIndex) that RLP-encodes the order in which the receipts occurred, stack information (rlpStack) that RLP-encodes all receipts of the block including the message, and message order information (logIndexes) in which the message occurred.

[0099] Here, the RLS sequence information (rlpIndex) indicates the sequence number of the RLS in which the message occurred, and the message sequence information (logIndexes) indicates the sequence number of a specific message to be delivered within the RLS. There may be one or more of these.

[0100] The message information transmitted by the relay system (400) is transmitted to the validity verification unit (230) of the second blockchain system (200).

[0101] The validation unit (230) verifies the message (S170) based on the message information received from the relay system (400) and the block header information stored in the previous step (S140).

[0102] This can be done in a two-step process:

[0103] First, as a first step, the validation unit (230) determines whether the Lisitz hash extracted from the validation information included in the message information received in step (S150) is included in the block header information stored in the block header register (220).

[0104] Here, the generation of the Rishitz hash can be accomplished by decoding the stack information (rlpStack) included in the validation information.

[0105] At this point, decoding stack information to generate a Lisitz hash can be done using, for example, a Merkle Patricia tree. As noted, the hash generated by a Merkle Patricia tree is 32 bytes, and the Merkle Patricia tree internally generates a 32-byte key using keecak256.

[0106] The coincidence that the Lisitz hash generated by the Merkle Patricia Tree and the hash stored in the block header storage (220) coincide with each other can be considered to be equal to the hash collision probability of keccak256, which is practically impossible in a blockchain system, and therefore the Lisitz hash can be verified using this Merkle Patricia Tree.

[0107] If the Resitz hash extracted by the validation information included in the message information received through this method is stored as block header information in the block header storage unit (220), the verification is determined to be successful, and if it is not stored, the verification is determined to not be successful.

[0108] Since receipts contain messages, the presence of a receipt containing a message implies a request to transmit the message. Conversely, the absence of a receipt implies that no message transmission request was made. Therefore, the fact that the receipt hash is stored as block header information in the block header storage (220) implies that the message was actually generated.

[0109] Next, as a second step, the validation unit (230) performs a second verification of the message by determining whether the Lisitz hash has been manipulated.

[0110] To this end, the validation unit (230) reassembles the Rishitz hash using the Rishitz encoding information (rlpReceipt) and Rishitz order information (rlpIndex) included in the validation information, and determines whether the reassembled Rishitz hash matches the Rishitz hash extracted in the first step. If it matches, it determines that the message has not been manipulated, and completes the final verification of the message.

[0111] If the message is successfully verified through this process, the second blockchain system (200) transmits a message corresponding to the message information to the address of the recipient connected to the second blockchain system (200) (S180).

[0112] That is, if the verification is successful, the validity verification unit (230) of the second blockchain system (200) transmits a message transmission request signal including message data included in the message information to the message communication unit (210), and the message communication unit (210) transmits the message to the address of the recipient coupled to the second blockchain system (200) (S180).

[0113] In the above, the present invention has been described with reference to preferred embodiments of the present invention, but the present invention is not limited to the above embodiments, and various modifications and variations are of course possible within the scope of the present invention.

[0114] [Explanation of symbols]

[0115] 1000... A messaging system for transmitting messages between different blockchains.

[0116] 100...The first blockchain system

[0117] 200...Second Blockchain System

[0118] 300... Verification System

[0119] 400...relay system

[0120] 110,210...Message Communication Department

[0121] 120,220...block header storage

[0122] 130,230...Validation Department

[0123] 310... Verification Master Department

[0124] 321, 322, ...32n...multiple verification nodes

Claims

1. A first step in which a first blockchain system receives a message transmission request signal requesting transmission of a message to a second blockchain system from a user system coupled to the first blockchain system; A second step in which the first blockchain system transmits a message verification request signal to the verification system; A third step in which the verification system verifies a block corresponding to the message verification request signal based on the message verification request signal; A fourth step in which, if block verification is successful, the verification system transmits a block information storage request signal to a second blockchain system, and the second blockchain system stores block header information corresponding to the block information storage request signal; A fifth step in which the first blockchain system transmits a message occurrence notification signal to a relay system; A sixth step in which the relay system generates message information based on the message occurrence notification signal and transmits the message information to a second blockchain system; A seventh step in which the second blockchain system verifies the message based on the message information received in the sixth step and the block header information stored in the fourth step; and If the verification of the above message is successful, the eighth step of the second blockchain system transmitting a message corresponding to the message information to the address of the recipient connected to the second blockchain system A method for transmitting messages between different blockchains, including:

2. In claim 1, A method for transmitting messages between different blockchains, characterized in that the message transmission request signal of the first step includes an identifier (ID) of a second blockchain system, which is a target blockchain system to which a message is to be transmitted, a final receiving address in the second blockchain system to which the message is to be transmitted, and message data to be transmitted.

3. In claim 1, The message verification request signal of the second step includes message verification request information, A method for transmitting messages between different blockchains, characterized in that the message verification request information includes an identifier (ID) of a second blockchain system, which is a blockchain system to which the message is to be transmitted, a block number in the first blockchain system where the message was generated, information indicating the entity that generated the message, information indicating the entity that transmitted the message, the final receiving address of the recipient to whom the message is to be transmitted in the second blockchain system, and message data to be transmitted.

4. In claim 1, The above verification system includes a verification master unit and multiple verification nodes, The third step above is, Step 3-1, in which the verification master unit generates transaction signature data based on the message verification request information; Step 3-2, in which the verification master unit transmits the message verification request information to the plurality of verification nodes and receives transaction signature data from the plurality of verification nodes; and Step 3-3 where the verification master verifies the block based on the transaction signature data. A method for transmitting messages between different blockchains, characterized by including:

5. In claim 4, Step 3-1 above, A step in which the verification master unit confirms the block number in which the message was generated from the message verification request information, requests block information corresponding to the confirmed block number to the first blockchain system that transmitted the message verification request signal, and receives the block information from the first blockchain system; A step in which the verification master unit extracts block header information from the received block information; and A step for generating transaction signature data that allows the verification master unit to transmit the extracted block header information to a second blockchain system and store it in the second blockchain system. Including, Step 3-2 above, A step in which each of the plurality of verification nodes checks the block number in which the corresponding message included in the message verification request information occurred, requests block information corresponding to the confirmed block number to the first blockchain system that transmitted the corresponding message verification request signal, and receives block information from the first blockchain system; A step in which each of the plurality of verification nodes extracts block header information from the received block information; and A step of generating transaction signature data so that each of the plurality of verification nodes can transmit and store the extracted block header information to the second blockchain system and transmitting the data to the verification master unit. A method for transmitting messages between different blockchains, characterized by including:

6. In claim 5, A method for transmitting messages between different blockchains, characterized in that the block header information includes block hash information, which is a hash value of the corresponding block, and Rishitz hash information, which is a hash value of event log record data proving the execution results of all transactions of the corresponding block.

7. In claim 6, Step 3-3 above is, A method for transmitting messages between different blockchains, characterized in that the verification master determines that verification is successful when more than half of the transaction signature data transmitted from the plurality of verification nodes and the transaction signature data generated by the verification master match.

8. In claim 7, The fourth step above is, A method for transmitting messages between different blockchains, characterized in that, if verification is successful, the verification master unit transmits a block information storage request signal including the transaction signature data it has generated and the transaction signature data transmitted from multiple verification nodes to the second blockchain system.

9. In claim 8, The fourth step above is, A method for transmitting messages between different blockchains, characterized in that the second blockchain system executes a transaction by transaction signature data included in the block information storage request signal, extracts block header information by the execution result, and stores the extracted block header information.

10. In claim 9, A method for transmitting messages between different blockchains, characterized in that the block header information includes block hash information and Rishitz hash information.

11. In claim 1, The message occurrence notification signal of the above 5th step includes message verification request information, A method for transmitting messages between different blockchains, characterized in that the message verification request information includes an identifier (ID) of a second blockchain system, which is a blockchain system to which the message is to be transmitted, a block number in the first blockchain system where the message was generated, information indicating the entity that generated the message, information indicating the entity that transmitted the message, the final receiving address of the recipient to whom the message is to be transmitted in the second blockchain system, and message data to be transmitted.

12. In claim 11, The above 6th step is, A step in which the relay system verifies the block number in which the message was generated from the message verification request information, requests block information corresponding to the verified block number from the first blockchain system, and receives block information from the first blockchain system; and A step in which the relay system generates message information based on the received block information and transmits the generated message information to the second blockchain system. A method for transmitting messages between different blockchains, characterized by including:

13. In claim 12, The above message information includes message data and validation information for validating the block containing the message, A method for transmitting messages between different blockchains, characterized in that the above validation information includes block hash information of the block where the message occurred and information related to the lisits of the transaction including the message.

14. In claim 13, A method for transmitting messages between different blockchains, characterized in that the validation information includes an identifier of the first blockchain system transmitting the message, a block hash of a block in which the message occurred in the first blockchain system, ricochet encoding information encoding ricochets of transactions including the message, ricochet order information encoding the order in which the ricochets occurred, stack information encoding all ricochets of a block including the message, and message order information in which the message occurred.

15. In claim 14, The above 7th step is, A seventh step in which the second blockchain system verifies the message based on the message information received in the sixth step and the block header information stored in the fourth step; and Step 7-1, in which the second blockchain system determines whether the Rishitz hash extracted from the validation information is included in the block header information stored in the fourth step; and Step 7-2, in which the second blockchain system reassembles the Lishitz hash using the Lishitz encoding information and Lishitz order information included in the validation information, and determines whether the reassembled Lishitz hash matches the Lishitz hash extracted in step 7-1. A method for transmitting messages between different blockchains, characterized by including:

16. In claim 15, A method for transmitting messages between different blockchains, characterized in that the step 7-1 above generates a Lisitz hash by decoding the stack information included in the validation information.

17. A first blockchain system that, when receiving a message transmission request signal requesting transmission of a message from a user system to a second blockchain system, transmits a message verification request signal to a verification system and transmits a message occurrence notification signal to a relay system; A verification system that verifies a block corresponding to a message verification request signal received from the first blockchain system, and, if block verification is successful, transmits a block information storage request signal to a second blockchain system; A relay system that generates message information based on a message occurrence notification signal received from the first blockchain system and transmits the message information to a second blockchain system; and A second blockchain system that stores block header information corresponding to a block information storage request signal received from the verification system, verifies the message based on the message information received from the relay system and the stored block header information, and, if the message verification is successful, transmits a message corresponding to the message information to the address of a recipient coupled to the second blockchain system. A messaging system between different blockchains, including .

Images