Method for providing interoperability between heterogeneous blockchains, and device therefor

Abstract

A method for providing interoperability between blockchains by a blockchain-linked relay server, according to an embodiment of the present invention, comprises the steps of: determining an asset type corresponding to the interoperability between blockchains; and processing one or more transactions corresponding to the interoperability according to the asset type.

Description

Method for providing interoperability between heterogeneous blockchains and device therefor

[0001] The present invention relates to blockchain technology, and more particularly to technology that provides interoperability between heterogeneous blockchains.

[0002] Blockchain is a mechanism that allows all nodes to share a consistent transaction ledger, even in a distributed system environment where trust is limited. A prime example is Bitcoin.

[0003] Furthermore, smart contracts are programmable contracts that, beyond simply transacting assets like coins, ensure that all nodes in a distributed system environment perform transactions in the same order. A representative open source project in this regard is Ethereum.

[0004] Blockchains can be broadly divided into public blockchains, private blockchains, and consortium blockchains, and among blockchains, there are various types of blockchains that use different consensus algorithms.

[0005] As blockchain-related services become increasingly complex and diverse, there are cases where interoperability between heterogeneous blockchains is required.

[0006] Korean Patent No. 10-2221328 discloses a technology that provides a low-complexity, high-scalability cross-chain network between different, mutually isolated blockchains.

[0007] However, the technology disclosed in Korean Patent No. 10-2221328 focuses on providing a cross-chain network between two different blockchains, and is difficult to apply to environments where interoperability for a wider variety of heterogeneous blockchains must be provided.

[0008] Therefore, there is an urgent need for new technologies capable of providing interoperability between various heterogeneous blockchains.

[0009] The purpose of the present invention is to provide interoperability between heterogeneous blockchains having different characteristics.

[0010] Additionally, it is an object of the present invention to efficiently provide interoperability between public / private / consortium blockchains or between blockchains using different consensus algorithms.

[0011] Additionally, it is an object of the present invention to provide efficient interoperability between blockchains based on the type of operation, such as exchange or transfer, and / or the type of transaction, such as WW (Write / Write) or RW (Read / Write).

[0012] A method for providing interoperability between blockchains, wherein a blockchain-linked relay server provides interoperability between blockchains to achieve the above-described purpose, comprises the steps of: determining an asset type corresponding to the interoperability between the blockchains; and processing one or more transactions corresponding to the interoperability according to the asset type.

[0013] At this time, the asset type may be determined based on whether the asset corresponding to the interconnection includes a coin / token.

[0014] At this time, the asset type can be determined based on whether the asset corresponding to the interconnection contains a message.

[0015] At this time, the asset type may be selected from a group including a first type in which the asset corresponding to the interconnection includes a message and does not include a coin / token, a second type in which the asset corresponding to the interconnection includes a coin / token and does not include a message, and a third type in which the asset corresponding to the interconnection includes both a message and a coin / token.

[0016] At this time, the above blockchains may include off-chain.

[0017] At this time, transaction processing corresponding to the first type may be performed based on a blockchain linkage directionality check process based on a blockchain linkage directionality; and a linkage consensus algorithm directionality check process based on a linkage consensus algorithm directionality.

[0018] At this time, the direction of the blockchain linkage can be determined based on whether the source corresponding to the linkage is a private blockchain (and / or consortium blockchain). In other words, a private blockchain can include a consortium blockchain or a public blockchain, even if the operating entity is clear.

[0019] At this time, the direction of the interconnection consensus algorithm may be determined in a forward direction when the number of consensus nodes of the blockchain consensus body corresponding to the source is greater than the number of consensus nodes of the blockchain consensus body corresponding to the destination of the interconnection, and may be determined in a reverse direction when the number of consensus nodes of the blockchain consensus body corresponding to the source is less than the number of consensus nodes of the blockchain consensus body corresponding to the destination of the interconnection.

[0020] At this time, transaction processing corresponding to the first type may generate an unprocessable message if the direction of the interconnection consensus algorithm is reversed when the source corresponding to the interconnection is a private blockchain.

[0021] At this time, the step of processing one or more transactions may be performed based on a task type check process based on a task type corresponding to the mutual linkage; and, if the task type is transfer, a transaction type check process based on a transaction type corresponding to the mutual linkage.

[0022] At this time, the above task type check process can be performed depending on whether the task type is transfer or exchange.

[0023] At this time, the transaction type check process can be performed depending on whether the transaction type is WW (Write / Write) or RW (Read / Write).

[0024] In addition, a device for providing interoperability between blockchains according to one embodiment of the present invention includes one or more processors; and an execution memory storing at least one program executed by the one or more processors.

[0025] At this time, the at least one program determines an asset type corresponding to the interconnection between blockchains, and processes one or more transactions corresponding to the interconnection according to the asset type.

[0026] At this time, the asset type may be selected from a group including a first type in which the asset corresponding to the interconnection includes a message and does not include a coin / token, a second type in which the asset corresponding to the interconnection includes a coin / token and does not include a message, and a third type in which the asset corresponding to the interconnection includes both a message and a coin / token.

[0027] At this time, transaction processing corresponding to the first type may be performed based on a blockchain linkage directionality check process based on a blockchain linkage directionality; and a linkage consensus algorithm directionality check process based on a linkage consensus algorithm directionality.

[0028] According to the present invention, interoperability between heterogeneous blockchains having different characteristics can be provided.

[0029] Additionally, the present invention can efficiently provide interoperability between public / private blockchains or between blockchains using different consensus algorithms.

[0030] Additionally, the present invention can efficiently provide interoperability between blockchains based on the type of operation, such as exchange or transfer, and / or the type of transaction, such as WW or RW.

[0031] FIG. 1 is a block diagram illustrating a blockchain interconnection system according to one embodiment of the present invention.

[0032] Figure 2 is a diagram showing the software layer structure of the blockchain interconnection system illustrated in Figure 1.

[0033] Figure 3 is a diagram showing the software processing flow of the blockchain interconnection system illustrated in Figure 1.

[0034] FIG. 4 is a diagram illustrating an online blockchain data source authentication process according to one embodiment of the present invention.

[0035] FIG. 5 is a block diagram illustrating an example of a device for providing interoperability between heterogeneous blockchains according to one embodiment of the present invention.

[0036] FIG. 6 is a flowchart illustrating a method for providing interoperability between heterogeneous blockchains according to one embodiment of the present invention.

[0037] Figure 7 is a flowchart illustrating an example of a transaction processing step for each asset type illustrated in Figure 6.

[0038] FIG. 8 is an operational flowchart showing an example of the first type of transaction processing step illustrated in FIG. 7.

[0039] FIG. 9 is an operational flowchart showing an example of the second type of transaction processing step illustrated in FIG. 7.

[0040] Figure 10 is an operational flow diagram showing an example of the third type of transaction processing step illustrated in Figure 7.

[0041] Figure 11 is a drawing showing a specialized structure according to one embodiment of the present invention.

[0042] Figure 12 is a block diagram showing a computer system configuration according to one embodiment of the present invention.

[0043] The advantages and features of the present invention, and the methods for achieving them, will become clearer with reference to the embodiments described in detail below together with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but may be implemented in various different forms. These embodiments are provided only to ensure that the disclosure of the present invention is complete and to fully inform those skilled in the art of the scope of the invention, and the present invention is defined only by the scope of the claims. Like reference numerals designate like elements throughout the specification.

[0044] Although "first" or "second" are used to describe various components, these components are not limited by such terms. Such terms may only be used to distinguish one component from another. Accordingly, a first component referred to below may also be a second component within the technical scope of the present invention.

[0045] The terminology used herein is for the purpose of describing embodiments and is not intended to limit the present invention. In this specification, the singular also includes the plural unless specifically stated otherwise. As used herein, the terms "comprises" or "comprising" imply that a stated component or step does not exclude the presence or addition of one or more other components or steps.

[0046] Unless otherwise defined, all terms used herein are to be interpreted as having a meaning commonly understood by those of ordinary skill in the technical field to which the present invention pertains. Furthermore, terms defined in commonly used dictionaries are not to be interpreted ideally or excessively unless explicitly and specifically defined otherwise.

[0047] Hereinafter, embodiments of the present invention will be described in detail with reference to the attached drawings. When describing with reference to the drawings, identical or corresponding components are given the same drawing reference numerals, and redundant descriptions thereof will be omitted.

[0048] FIG. 1 is a block diagram illustrating a blockchain interoperability system according to one embodiment of the present invention.

[0049] Referring to FIG. 1, a blockchain interconnection system according to an embodiment of the present invention includes different blockchain systems (110, 120, 130, 140) and a blockchain linkage relay server (160). In this case, the blockchain system (110) may include a blockchain linkage server (111), the blockchain system (120) may include a blockchain linkage server (121), the blockchain system (130) may include a blockchain linkage server (131), and the blockchain system (140) may include a blockchain linkage server (141).

[0050] Although not explicitly shown in FIG. 1, the blockchain systems (110, 120, 130, 140) may also include off-chain systems.

[0051] At this time, the blockchain linkage servers (111, 121, 131, 141) each perform the role of a gateway (GW) and can only provide a connection with the blockchain linkage relay server (160) without the need to provide individual interconnection between the blockchain systems (110, 120, 130, 140). In this way, by establishing a connection for blockchain interconnection through the blockchain linkage relay server (160), the blockchain systems (110, 120, 130, 140) do not need to establish individual connections with other blockchain systems, thereby providing more efficient blockchain interconnection.

[0052] Blockchain-linked servers (111, 112, 131, 141) can be operated with each of the linked modules installed, and each of the blockchain-linked servers (111, 112, 131, 141) can be a node corresponding to each of the blockchain systems (110, 120, 130, 140).

[0053] The blockchain interoperability system illustrated in Figure 1 may provide dApp-based interoperability, and in particular, may operate based on a blockchain agnostic protocol.

[0054] Figure 2 is a diagram showing the software layer structure of the blockchain interconnection system illustrated in Figure 1.

[0055] Referring to Figure 2, it can be seen that a blockchain connection layer exists above the blockchain service layer, and a blockchain application layer exists above that.

[0056] The blockchain application layer can provide identity verification, electronic document authenticity verification, or financial transaction functions, while the blockchain service layer corresponds to blockchain systems.

[0057] The blockchain linkage layer corresponds to a blockchain linkage server that includes a blockchain linkage relay server and a blockchain linkage module, and can be connected to blockchain systems through blockchain connectors.

[0058] Figure 3 is a diagram showing the software processing flow of the blockchain interconnection system illustrated in Figure 1.

[0059] Referring to FIG. 3, it can be seen that a blockchain linkage relay request from a client corresponding to service #n is provided to a blockchain linkage relay server through a blockchain linkage module of a blockchain linkage server corresponding to blockchain network #n, and a result of blockchain linkage relay processing of the blockchain linkage relay server is provided to a client corresponding to service #ⓝ through a blockchain linkage module of a blockchain linkage server corresponding to blockchain network #ⓝ.

[0060] In this way, efficient interoperability between heterogeneous blockchains can be provided through a blockchain-linked relay server.

[0061] FIG. 4 is a diagram illustrating an online blockchain data source authentication process according to one embodiment of the present invention.

[0062] Referring to FIG. 4, in an online blockchain data source authentication process according to an embodiment of the present invention, first, a sender client device and a receiver client device can register their devices with a data source authentication management server in advance and receive a data source authentication key online.

[0063] At this time, the data source authentication management server may correspond to a blockchain data source authentication device.

[0064] The sender client device can request device authentication from the data source authentication server using a pre-issued authentication key before transmitting data.

[0065] At this time, the sender client device can request device authentication and encryption key issuance by providing device information to the data source authentication server.

[0066] At this time, if device authentication is successful, the data source authentication server can use the authentication result to generate an encryption key and issue the encryption key to the sender client device.

[0067] The sender client device can retrieve data from blockchain system A and encrypt the data using an encryption key algorithm based on the issued encryption key and random number.

[0068] At this time, the sender client device can generate additional verification data using a preset data collection cycle from blockchain system A depending on the importance of the data.

[0069] At this time, the importance of the data may correspond to the data collection cycle.

[0070] For example, depending on the importance of the data, important types of data may have frequent data collection cycles, while unimportant types of data may have infrequent data collection cycles.

[0071] At this time, the sender client device can encrypt the data collected from blockchain system A and additional verification data.

[0072] At this time, additional verification data may include contextual awareness data for various contextual attributes such as identity, location, activity, and time.

[0073] At this time, the additional verification data may include at least one of identification information of the sender client device, location information, information about blockchain system A, operation (measurement and status, etc.) information, and time information.

[0074] At this time, the sender client device can generate a data source authentication value for the data retrieved from blockchain system A, and transmit the data source authentication value and encrypted data to the recipient.

[0075] At this time, the data source authentication value may correspond to a data integrity checksum (DIC).

[0076] The recipient client device can receive data source authentication values ​​and encrypted data.

[0077] When a recipient client device receives encrypted data, it can request the data source authentication server to verify the authentication of the sender client device and provide the authentication result (encryption key).

[0078] At this time, the recipient client device can decrypt the encrypted data using an encryption key algorithm based on the issued encryption key and random number.

[0079] At this time, the recipient client device can request the data source authentication server to verify the data source authentication value and additional verification data.

[0080] If the verification is successful, the data source authentication server can reply with the verification result to the recipient client device.

[0081] At this time, if the received verification result is successful, the recipient client device can register the decrypted data in blockchain system B, and if the verification fails, the decrypted data can be discarded.

[0082] At this time, the data source authentication server can verify the decrypted data based on at least one of the identification information of the sender client device, location information, information about blockchain system A, operation (measurement and status, etc.) information, and time information included in the additional verification data.

[0083] At this time, the data source authentication server can check the importance of the data from the collection cycle of the data included in the additional verification data, and check the authentication validity period based on the importance of the data.

[0084] At this time, the data source authentication server can verify the data based on whether the current point in time at which the data included in the additional verification data was collected corresponds to the authentication validity period.

[0085] That is, the data source authentication server includes an authentication management unit and a data source verification unit.

[0086] The authentication management unit receives device authentication requests from sender client devices and receiver client devices, performs device authentication based on device information and an authentication key, and, if the device authentication is successful, issues an encryption key to the sender client devices and receiver client devices that requested the device authentication.

[0087] The data source verification unit can receive a request from the recipient client device to verify the data source authentication value for data transmitted by the sender client device to the recipient client device, and transmit the verification result to the recipient client device.

[0088] Through the process illustrated in Figure 4, it can be seen that data from blockchain system A can be safely transmitted to blockchain system B.

[0089] FIG. 5 is a block diagram illustrating an example of a device for providing interoperability between heterogeneous blockchains according to one embodiment of the present invention.

[0090] Referring to FIG. 5, it can be seen that interoperability between Hyperledger Besu, Hyperledger Fabric, and Bitcoin is provided by a blockchain linkage relay server (160). Here, Hyperledger Besu, Hyperledger Fabric, or Bitcoin are merely examples of heterogeneous blockchains.

[0091] At this time, the contact nodes (510, 520, 530) may correspond to the blockchain-linked servers illustrated in FIG. 1. At this time, message transmission / reception between the blockchain-linked relay server (160) and the contact nodes (510, 520, 530) may be based on a standard API. Subsequently, message transmission / reception between the contact nodes (510, 520, 530) and each blockchain system may be based on a dedicated protocol for each blockchain platform.

[0092] As illustrated in FIG. 5, the blockchain-linked relay server (160) can exchange service transactions with DApps.

[0093] Although not explicitly shown in FIG. 5, heterogeneous blockchain systems may also include off-chain systems.

[0094] FIG. 6 is a flowchart illustrating a method for providing interoperability between heterogeneous blockchains according to one embodiment of the present invention.

[0095] Referring to FIG. 6, a method for providing interoperability between heterogeneous blockchains according to one embodiment of the present invention verifies linked blockchain information (S610).

[0096] At this time, the linked blockchain information may be information of the blockchain(s) that are the target of the interconnection, or may be information registered in the system or collected from the target blockchain by a separate program.

[0097] At this time, the linked blockchain information can be stored in an information storage corresponding to the off-chain database.

[0098] At this time, the linked blockchain information may include access authority information for the blockchains.

[0099] In addition, a method for providing interoperability between heterogeneous blockchains according to one embodiment of the present invention determines an asset type corresponding to interoperability between blockchains (S620).

[0100] At this time, the asset type may be determined based on whether the asset contains a coin / token or a message (message or data). At this time, the asset type may be determined based on whether the asset corresponding to the above-mentioned interconnection contains a coin / token. At this time, the asset type may be determined based on whether the asset corresponding to the above-mentioned interconnection contains a message. If the asset contains a message, it may be checked whether it is a large message.

[0101] At this point, the message may be data other than tokens or coins. Large amounts of data may be too large to store on the blockchain, and may be stored in an off-chain database.

[0102] At this time, coins are issued on the mainnet and may primarily be issued on public blockchains, while tokens can also be issued on apps and may be issued on public or private blockchains. However, the present invention does not strictly distinguish between coins and tokens, and the two terms may be used interchangeably.

[0103] In addition, a method for providing interoperability between heterogeneous blockchains according to one embodiment of the present invention processes one or more transactions corresponding to the interoperability according to the asset type (S630).

[0104] Each step illustrated in FIG. 6 may be performed in the order illustrated in FIG. 6, in the reverse order, or simultaneously.

[0105] Each step illustrated in FIG. 6 may be performed by the blockchain linkage relay server illustrated in FIG. 1 or the device providing interoperability between heterogeneous blockchains illustrated in FIG. 12.

[0106] Although not explicitly shown in FIG. 6, a method for providing interoperability between heterogeneous blockchains according to an embodiment of the present invention may further include a step of receiving a message and parsing the received message before step (S610).

[0107] Figure 7 is an operation flow diagram showing an example of a transaction processing step (S630) by asset type illustrated in Figure 6.

[0108] Referring to Figure 7, the transaction processing step by asset type classifies the asset type (S710).

[0109] As mentioned above, the asset type can be determined based on whether the asset contains a coin / token or a message (message or data). In this case, the asset type can be determined based on whether the asset corresponding to the interconnection contains a coin / token. In this case, the asset type can be determined based on whether the asset corresponding to the interconnection contains a message. If the asset contains a message, it can be checked whether it is a large message.

[0110] As a result of the judgment in step (S710), if the asset type corresponds to a message only (only message), transaction processing of the first type is performed (S720).

[0111] As a result of the judgment in step (S710), if the asset type corresponds to only coin / token, the second type of transaction processing is performed (S730).

[0112] As a result of the judgment in step (S710), if the asset type corresponds to the message and coin / token linkage, the third type of transaction processing is performed (S740).

[0113] That is, the asset type may be selected from a group including a first type in which the asset corresponding to the interconnection includes a message and does not include a coin / token, a second type in which the asset corresponding to the interconnection includes a coin / token and does not include a message, and a third type in which the asset corresponding to the interconnection includes both a message and a coin / token.

[0114] FIG. 8 is an operational flowchart showing an example of the first type of transaction processing step (S720) illustrated in FIG. 7.

[0115] Referring to Fig. 8, the first type of transaction processing step first determines whether the message is a large message (S810).

[0116] That is, step (S810) can determine whether the transaction corresponding to the interconnection corresponds to a message (data) of a size that can be stored on the blockchain. If the data is too large, it cannot be stored on the blockchain and may be stored in a separate off-chain database. In other words, the block size stored on the blockchain is small (for example, Bitcoin generates blocks every 10 minutes, 1 MB), there is a limit to the transaction size that can be stored in a block, and data that cannot be stored in a blockchain block may be stored off-chain.

[0117] If it is determined as a large message at step (S810), the first type of transaction processing step checks the blockchain linkage direction (S820).

[0118] As will be described later, the direction of blockchain linkage may correspond to whether the transaction is from a public blockchain to a public blockchain, from a public blockchain to a private blockchain, from a private blockchain to a public blockchain, or from a private blockchain to a private blockchain.

[0119] As a result of the judgment in step (S810), if it is determined to be a large message, the first type of transaction processing step reports at least one of the source or destination as off-chain and checks whether the source is off-chain (S812).

[0120] That is, in the present invention, off-chain can be treated as a type of blockchain.

[0121] At this time, the source may refer to the side sending the transaction, and the destination may refer to the side receiving the transaction.

[0122] As a result of the judgment in step (S812), if the source is off-chain, the first type of transaction processing step is regarded as a message (data) transmission from off-chain to the blockchain, and the same process as non-large-capacity message processing is performed.

[0123] As a result of the judgment in step (S812), if the source is not off-chain and the destination is off-chain, the first type of transaction processing step is reported as a message (data) transmission from the blockchain to the off-chain and the transaction type is checked in step (S890).

[0124] At this time, if the result of the judgment in step (S812) is determined to be a message transmission from the blockchain to the off-chain, it can be operated assuming that the task type described later is a transfer.

[0125] If the message is not large or corresponds to processing of a large message from off-chain to blockchain, the first type of transaction processing step checks the blockchain linkage direction (S820).

[0126] At this time, the direction of blockchain linkage may correspond to whether the transaction is from a public blockchain to a public blockchain, from a public blockchain to a private blockchain, from a private blockchain to a public blockchain, or from a private blockchain to a private blockchain.

[0127] At this time, the direction of blockchain interoperability can be determined based on whether the source corresponding to the above interoperability is a private blockchain.

[0128] If, as a result of the judgment in step (S820), the source corresponding to the above interconnection is determined to be not a private blockchain, the first type of transaction processing step immediately checks the operation type (S850).

[0129] That is, if the source corresponding to the interconnection is determined to be a public blockchain as a result of the judgment in step (S820), the first type of transaction processing step does not need to perform a check for forced processing and a check for the direction of the interconnection consensus algorithm.

[0130] As a result of the judgment in step (S820), if the source corresponding to the above interconnection is determined to be a private blockchain, the first type of transaction processing step checks whether forced processing is required (S830).

[0131] Whether to force processing can be determined based on specifically defined data, unlike typical linkage behavior, such as allowing processing of specific transactions on a blockchain-linked relay server. For example, while transaction processing is generally not permitted when the linkage consensus algorithm direction is reversed, if the forced processing decision is specifically registered as permitted, the transaction may be processed even if the linkage consensus algorithm direction is reversed.

[0132] If the result of the judgment in step (S830) determines that the transaction is subject to forced processing, the first type of transaction processing step checks the operation type directly without checking the direction of the linked consensus algorithm (S850).

[0133] If the transaction is not determined to be subject to forced processing as a result of the judgment in step (S830), the first type of transaction processing step checks the direction of the linked consensus algorithm (S840).

[0134] At this time, the direction of the linked consensus algorithm may be determined by technical priority. That is, transactions moving from a consensus algorithm with a higher technical priority (e.g., a complex consensus algorithm or a large number of consensus nodes) to a consensus algorithm with a lower technical priority (e.g., a simple consensus algorithm or a small number of consensus nodes) may be permitted (forward), while transactions moving in the opposite direction (reverse) may be disallowed.

[0135] For example, in the case of transaction processing corresponding to an exchange, the forward direction may be processable but the reverse direction may not be processable. For example, in the case of transaction processing corresponding to a transfer, the forward direction may be processable but the reverse direction may not be processable.

[0136] At this time, for off-chain transactions, a consensus algorithm may not exist and they may be processed with the lowest technical priority. In other words, off-chain transactions may be processed using the simplest consensus algorithm. At this time, tasks may only be processed if the off-chain transaction is public or if the policy check is set to mandatory.

[0137] For example, the direction of the interconnection consensus algorithm may be determined in a forward direction when the number of consensus nodes of the blockchain consensus body corresponding to the source is greater than the number of consensus nodes of the blockchain consensus body corresponding to the destination of the interconnection, and may be determined in a reverse direction when the number of consensus nodes of the blockchain consensus body corresponding to the source is less than the number of consensus nodes of the blockchain consensus body corresponding to the destination of the interconnection.

[0138] If the direction of the linked consensus algorithm is determined to be reversed as a result of the judgment in step (S840), the first type of transaction processing step generates a non-processing message (S842).

[0139] If the direction of the linked consensus algorithm is determined to be forward as a result of the judgment in step (S840), the first type of transaction processing step checks the work type (S850).

[0140] At this time, the task type check process may be performed depending on whether the task type is transfer or exchange. At this time, if the task type is exchange, only WW can exist as the transaction type, and if the task type is transfer, the transaction type can be either RW or WW.

[0141] In this case, a transfer may correspond to the transfer of assets from a source to a destination, and an exchange may correspond to the exchange of assets between a source and a destination. However, even if assets such as data or coins / tokens appear to be transferred unilaterally, if state information such as processing results are stored on the source side, the actual operation type may be an exchange rather than a transfer.

[0142] As a result of the judgment in step (S850), if the work type corresponds to exchange, message exchange processing is performed (S860).

[0143] For example, message exchange processing could be performed by storing data on a first blockchain corresponding to the source, hashing information corresponding to the exchange, and then storing the data on a second blockchain corresponding to the destination.

[0144] As a result of the judgment in step (S850), if the work type corresponds to transmission, the first type of transaction processing step checks the transaction type (S890).

[0145] At this time, the transaction type can be WW (Write / Write) or RW (Read / Write). WW indicates that a write is performed on the first blockchain and a write is also performed on the second blockchain. RW indicates that a read is performed on the first blockchain and a write is performed on the second blockchain.

[0146] If the transaction type is RW as a result of the judgment in step (S890), the first type of transaction processing step performs message RW transmission processing (S892).

[0147] For example, the message RW transmission process could be performed by looking up data on the first blockchain, hashing the information, and then storing the data on the second blockchain.

[0148] If the transaction type is WW as a result of the judgment in step (S890), a step similar to the message exchange processing corresponding to step (S860) may be performed.

[0149] Depending on the embodiment, in addition to the transaction types shown in FIG. 8, there may be additional transaction types such as RR or WR.

[0150] In particular, for WW, consistency handling needs to be provided, and consistency management can be performed through state information management.

[0151] FIG. 9 is an operational flowchart showing an example of the second type of transaction processing step (S730) illustrated in FIG. 7.

[0152] Referring to Fig. 9, the second type of transaction processing step checks the task type (S910).

[0153] At this time, the task type check process may be performed depending on whether the task type is transfer or exchange. At this time, if the task type is exchange, only WW can exist as the transaction type, and if the task type is transfer, the transaction type can be either RW or WW.

[0154] In this case, a transfer may correspond to the transfer of assets from a source to a destination, and an exchange may correspond to the exchange of assets between a source and a destination. However, even if assets such as data or coins / tokens appear to be transferred unilaterally, if state information such as processing results are stored on the source side, the actual operation type may be an exchange rather than a transfer.

[0155] As a result of the judgment in step (S910), if the task type corresponds to transmission, coin / token transmission processing is performed (S930).

[0156] For example, coin / token transfer processing may be performed on a first blockchain followed by coin / token processing on a second blockchain.

[0157] As a result of the judgment in step (S910), if the work type corresponds to an exchange, the second type of transaction processing step checks the exchange type (S920).

[0158] The second type of transaction processing step, if the task type is determined to be an exchange in step (S910), there is no data correlation between blockchains and the exchange is generally considered to be between public blockchains. In this case, the exchange is likely to be primarily between NFTs or between NFTs and coins.

[0159] If the exchange type is determined as an exchange between NFTs as a result of the judgment in step (S920), the second type of transaction processing step performs exchange processing between NFTs (S923).

[0160] For example, an exchange process between NFTs can be performed in the following order: checking exchange rate information, transferring ownership of the first blockchain, and then transferring ownership of the second blockchain.

[0161] If the exchange type is determined to be an NFT-to-coin exchange as a result of the judgment in step (S920), the second type of transaction processing step performs an NFT-to-coin exchange processing (S925).

[0162] For example, the exchange process between NFT coins can be performed in the following order: checking the coin balance, transferring token ownership, and performing coin payment.

[0163] FIG. 10 is an operation flow diagram showing an example of the third type of transaction processing step (S740) illustrated in FIG. 7.

[0164] Referring to Fig. 10, the third type of transaction processing step checks the operation type (S1010).

[0165] At this time, the task type check process may be performed depending on whether the task type is transfer or exchange. At this time, if the task type is exchange, only WW can exist as the transaction type, and if the task type is transfer, the transaction type can be either RW or WW.

[0166] In this case, a transfer may correspond to the transfer of assets from a source to a destination, and an exchange may correspond to the exchange of assets between a source and a destination. However, even if assets such as data or coins / tokens appear to be transferred unilaterally, if state information such as processing results are stored on the source side, the actual operation type may be an exchange rather than a transfer.

[0167] As a result of the judgment in step (S1010), if the task type corresponds to an exchange, message and coin / token linkage exchange processing is performed (S1030).

[0168] For example, processing messages and coin / token link exchanges can be accomplished by locking tokens on the first blockchain, processing messages on the second blockchain, unlocking and processing tokens on the first blockchain if the transaction is successful, and rolling back if the transaction fails.

[0169] As a result of the judgment in step (S1010), if the task type corresponds to transmission, the third type of transaction processing step checks the transaction type (S1020).

[0170] At this time, the transaction type can be WW (Write / Write) or RW (Read / Write). WW indicates that a write is performed on the first blockchain and a write is also performed on the second blockchain. RW indicates that a read is performed on the first blockchain and a write is performed on the second blockchain.

[0171] If the transaction type is RW as a result of the judgment in step (S1020), the third type of transaction processing step performs message and coin / token linked RW transmission processing (S1023).

[0172] For example, message and coin / token linking RW transfer processing could be performed in the following order: message processing on the first blockchain, and if successful, token storage on the second blockchain.

[0173] If the transaction type is WW as a result of the judgment in step (S1020), the third type of transaction processing step performs message and coin / token linked WW transmission processing (S1025).

[0174] For example, message and coin / token linked WW transfer processing can be performed by storing the message on the first blockchain, processing the token on the second blockchain if successful, and updating the message status information on the first blockchain if successful.

[0175] Depending on the embodiment, in addition to the transaction types shown in FIG. 10, there may be additional transaction types such as RR or WR.

[0176] In particular, for WW, consistency handling needs to be provided, and consistency management can be performed through state information management.

[0177] Although not explicitly shown in FIG. 10, the third type of transaction processing step may operate differently depending on whether the link is from a message to a token / coin or from a token / coin to a message.

[0178] For example, the process illustrated in FIG. 10 may be applied to linking from a message to a token / coin, and in the case of linking from a token / coin to a message, a step similar to step S1025 of FIG. 10 may be performed, as only a transmission corresponding to WW exists.

[0179] In some embodiments, the third type of transaction processing step illustrated in FIG. 10 may ensure data consistency by processing messages first and then tokens / coins thereafter.

[0180] FIG. 11 is a drawing showing a specialized structure (request) according to one embodiment of the present invention.

[0181] Referring to Figure 11, it can be seen that transaction processing requests can be made to multiple blockchain platforms via an array structure. Transaction processing can be performed asynchronously, and after a request, a response can only be returned indicating whether the request has been received.

[0182] The processing results can be provided in an event-based manner, and the response can return the transaction ID of each blockchain.

[0183] Figure 12 is a block diagram showing a computer system configuration according to one embodiment of the present invention.

[0184] A blockchain-linked relay server according to an embodiment or a device providing interoperability between blockchains or a device illustrated in FIG. 5 may be implemented in a computer system (1200) such as a computer-readable recording medium.

[0185] The computer system (1200) may include one or more processors (1210), memory (1230), user interface input devices (1240), user interface output devices (1250), and storage (1260) that communicate with each other via a bus (1220). In addition, the computer system (1200) may further include a network interface (1270) connected to a network (1280). The processor (1210) may be a central processing unit or a semiconductor device that executes programs or processing instructions stored in the memory (1230) or storage (1260). The memory (1230) and storage (1260) may be storage media that include at least one of a volatile medium, a nonvolatile medium, a removable medium, a non-removable medium, a communication medium, or an information transmission medium. For example, the memory (1230) may include a ROM (1231) or a RAM (1232).

[0186] At this time, at least one program can be recorded in the memory (1230).

[0187] At this time, the processor (1210) can execute the program. At this time, the program determines an asset type corresponding to the interconnection between blockchains, and processes one or more transactions corresponding to the interconnection according to the asset type.

[0188] At this time, the asset type may be selected from a group including a first type in which the asset corresponding to the interconnection includes a message and does not include a coin / token, a second type in which the asset corresponding to the interconnection includes a coin / token and does not include a message, and a third type in which the asset corresponding to the interconnection includes both a message and a coin / token.

[0189] At this time, transaction processing corresponding to the first type may be performed based on a blockchain linkage directionality check process based on a blockchain linkage directionality; and a linkage consensus algorithm directionality check process based on a linkage consensus algorithm directionality.

[0190]

[0191] As described above, the method and device for providing interoperability between blockchains according to the present invention are not limited to the configuration and method of the embodiments described above, but rather, the embodiments may be configured by selectively combining all or part of each embodiment so that various modifications can be made.

Claims

1. In a method where a blockchain linkage relay server provides interoperability between blockchains, A step of determining an asset type corresponding to the interconnection between the above blockchains; and A step of processing one or more transactions corresponding to the above interconnection according to the above asset type. A method for providing interoperability between blockchains, including:

2. In claim 1, The above asset types are A method for providing interoperability between blockchains, wherein the asset corresponding to the above interoperability is determined based on whether it includes a coin / token.

3. In claim 2, The above asset types are A method for providing interoperability between blockchains, wherein the method is determined based on whether an asset corresponding to said interoperability contains a message.

4. In claim 1, The above asset types are A first type of asset corresponding to the above interconnection contains a message and does not contain a coin / token; A second type in which the asset corresponding to the above interconnection contains coins / tokens and does not contain messages, and The asset corresponding to the above interconnection is selected from the group including a third type that includes both messages and coins / tokens, A method for providing interoperability between blockchains.

5. In claim 1, The above blockchains include offchain, A method for providing interoperability between blockchains.

6. In claim 4, Transaction processing corresponding to the above first type is Blockchain linkage direction check process based on blockchain linkage direction; and Based on the directionality of the linked consensus algorithm, the linked consensus algorithm directionality check process is performed. A method for providing interoperability between blockchains.

7. In claim 6, The above blockchain linkage direction is Based on whether the source corresponding to the above interconnection is a private blockchain, A method for providing interoperability between blockchains.

8. In claim 7, The direction of the above linked consensus algorithm is If the number of consensus nodes of the blockchain consensus corresponding to the above source is greater than the number of consensus nodes of the blockchain consensus corresponding to the destination of the above interconnection, it is determined in the forward direction. If the number of consensus nodes of the blockchain consensus corresponding to the above source is less than the number of consensus nodes of the blockchain consensus corresponding to the destination of the above interconnection, it is determined in the reverse direction. A method for providing interoperability between blockchains.

9. In claim 8, Transaction processing corresponding to the above first type is If the source corresponding to the above interconnection is a private blockchain If the direction of the above-mentioned link consensus algorithm is reversed, a message that cannot be processed is generated. A method for providing interoperability between blockchains.

10. In claim 4, The steps for processing one or more of the above transactions are: A task type check process based on the task type corresponding to the above mutual linkage; and If the above operation type is transfer, it is performed and is performed based on a transaction type check process based on a transaction type corresponding to the above interconnection. A method for providing interoperability between blockchains.

11. In claim 10, The above task type check process is Depending on whether the above operation type is transfer or exchange, A method for providing interoperability between blockchains.

12. In claim 11, The above transaction type check process is Depending on whether the above transaction type is WW (Write / Write) or RW (Read / Write), A method for providing interoperability between blockchains.

13. One or more processors; and comprising an execution memory storing at least one program executed by said one or more processors; At least one of the above programs A device providing interoperability between blockchains, which determines an asset type corresponding to the interoperability between blockchains and processes one or more transactions corresponding to the interoperability according to the asset type.

14. In claim 13, The above asset types are A first type of asset corresponding to the above interconnection contains a message and does not contain a coin / token; A second type in which the asset corresponding to the above interconnection contains coins / tokens and does not contain messages, and The asset corresponding to the above interconnection is selected from the group including a third type that includes both messages and coins / tokens, A device that provides interoperability between blockchains.

15. In claim 14, Transaction processing corresponding to the above first type is Blockchain linkage direction check process based on blockchain linkage direction; and Based on the directionality of the linked consensus algorithm, the linked consensus algorithm directionality check process is performed. A device that provides interoperability between blockchains.

Images