Authenticated cross-subnet communication

Abstract

Various aspects of the technologies described herein relate to systems, methods, and machine-readable media for cross-chain communication on a blockchain platform. Various aspects may include accepting a first transaction, comprising a message and a message payload, on a first blockchain. The aspects may also include verifying a message on the first blockchain by signing the message using the signing keys of one or more validators in a first set of validators on the first blockchain. The aspects may also include generating an aggregate signature based on the signing keys of one or more validators in a first set of validators. The aspects may also include submitting a second transaction, comprising a message and an aggregate signature, on a second blockchain. The aspects may also include verifying the second transaction on the second blockchain based on a shared registry.

Description

Technical Field

[0001] Cross - reference to Related Applications This disclosure is related to and claims priority from U.S. Provisional Patent Application No. 63 / 455,919, filed on March 30, 2023, by Michael Edmond Kaplan et.al., entitled "AUTHENTICATED CROSS - CHAIN COMMUNICATION", the content of which is hereby incorporated by reference in its entirety for all purposes.

[0002] This disclosure generally relates to cross - chain or cross - subnet communication within a blockchain network. More specifically, this disclosure relates to enabling efficient cross - subnet messaging in a way that does not require trust in any additional participants other than subnet validators.

Background Art

[0003] Conventional blockchain technology includes a growing list of records called blocks that are linked to each other. A blockchain network includes nodes such as validator nodes that participate in consensus. Validator nodes can verify, vote, stake, and / or maintain the record of transactions of the blockchain network and store a copy of the blockchain. Validators are also responsible for generating and / or proposing blocks for addition to the blockchain network. Validators can participate in a consensus voting protocol for the implementation of blockchain deployment or construction on a subnet. A subnet is a dynamic set of validators that collaborate to achieve consensus on the state of a set of blockchains. Each blockchain is verified by exactly one subnet. However, a subnet can verify multiple blockchains.

Summary of the Invention

[0004] This disclosure provides a system and method for sending messages between blockchains, each verified by its own set of validators, using a messaging protocol. According to embodiments, a computer implementation method for cross-chain communication in a blockchain platform is provided. The method includes accepting a first transaction in a first blockchain, comprising a message and a message payload. The method also includes verifying a message in the first blockchain by signing the message using the signing keys of one or more validators in a first set of validators in the first blockchain. The method also includes generating an aggregate signature based on the signing keys of one or more validators in a first set of validators. The method also includes submitting a second transaction on a second blockchain, comprising a message and an aggregate signature. The method also includes verifying the second transaction in the second blockchain based on a shared registry.

[0005] According to the embodiment, a system is provided, including a processor and memory, the memory including instructions stored therein, which, when executed by the processor, cause the processor to implement a method for cross-chain communication on a blockchain platform. The method includes accepting a first transaction in a first blockchain, including a message and a message payload, the payload indicating a destination blockchain in a second blockchain and a destination address in the second blockchain. The method also includes verifying a message in the first blockchain by signing the message using the signing keys of one or more validators in a first set of validators in the first blockchain. The method also includes generating an aggregate signature based on the signing keys of one or more validators in a first set of validators. The method also includes submitting a second transaction on the second blockchain, the second transaction including a message and an aggregate signature. The method also includes verifying the second transaction in the second blockchain based on a shared registry.

[0006] According to the embodiment, a non-temporary computer-readable storage medium is provided which contains instructions (e.g., a sequence of stored instructions), and when the instructions are executed by a processor, the processor causes the processor to implement a method for communication between blockchains on a blockchain platform. The method includes accepting a first transaction in a first blockchain, which includes a message and a message payload. The method also includes verifying a message in the first blockchain by signing the message using the signing keys of one or more validators in a first set of validators in the first blockchain. The method also includes generating an aggregate signature based on the signing keys of one or more validators in the first set of validators. The method also includes submitting a second transaction on a second blockchain, which includes a message and an aggregate signature based on the message payload. The method also includes accepting a second transaction in the second blockchain. The method also includes verifying the second transaction based on the aggregate signature and a shared registry.

[0007] These and other embodiments will become apparent to those skilled in the art from the following. [Brief explanation of the drawing]

[0008] To provide further understanding, the accompanying drawings, which are included and incorporated herein and constitute part of this specification, illustrate the disclosed embodiments and, together with the specification, help to illustrate the principles of the disclosed embodiments. The drawings are as follows:

[0009] [Figure 1] This is a block diagram of a device operating environment that can implement the embodiments of this disclosure. [Figure 2] This block diagram illustrates the details of the devices used in the architecture of Figure 1 in several embodiments. [Figure 3]This is an exemplary system flow diagram illustrating a mode of cross-subnet communication in a blockchain network, according to certain embodiments of this disclosure. [Figure 4] This block diagram illustrates a system configured for cross-chain communication using one or more implementations. [Figure 5] This is an exemplary flowchart for cross-subnet communication according to a particular aspect of the present disclosure. [Figure 6] This is a block diagram illustrating an exemplary computer system capable of implementing aspects of the subject technology.

[0010] In one or more implementations, not all components depicted in each figure are necessarily required, and one or more implementations may include additional components not shown in the figures. Variations may be made in the arrangement and type of components without departing from the scope of this disclosure. Additional components, different components, or fewer components may be used within the scope of the disclosure. [Modes for carrying out the invention]

[0011] The following detailed description includes many specific details in order to provide a complete understanding of the disclosure. However, it will be apparent to those skilled in the art that embodiments of the disclosure can be practiced without some of these specific details. In other examples, well-known structures and techniques are not shown in detail so as not to obscure the disclosure.

[0012] The detailed descriptions provided below illustrate various configurations of the subject art and are not intended to represent only the configurations in which the subject art can be practiced. The detailed descriptions include specific details for the purpose of providing a complete understanding of the subject art. Therefore, dimensions may be provided in relation to certain embodiments as non-limiting examples. However, it will be apparent to those skilled in the art that the subject art can be practiced without these specific details. In some examples, well-known structures and components are shown in block diagrams to avoid obscuring the concepts of the subject art.

[0013] General Overview Blockchain platforms, such as smart contracts, may require a consensus protocol as a fundamental building block for constructing decentralized systems. For example, a blockchain platform may include multiple blockchains, such as a component exchange blockchain for creating and trading digital smart assets, a metadata blockchain for coordinating validators and tracking and creating subnets, and a contract blockchain for creating smart contracts. As used herein, a subnet or subnetwork comprises a dynamic set of nodes (e.g., one or more validators) seeking to achieve consensus on the state of a set of blockchains, where one blockchain is validated by one subnet, but one subnet can validate multiple blockchains. Nodes can participate in validating multiple subnets and may be subject to the requirements of the blockchains within those subnets for reasons such as security, licensing, and hardware.

[0014] A blockchain validated by a validator may be a blockchain network (or platform) with application-level logic defined by multiple virtual machines (VMs) that enable a more decentralized network. Specifically, a blockchain may be an instance of a VM that specifies the blockchain's state, state transition functions, transactions, and application programming interfaces (APIs) for user interaction. The VM enables the execution of smart contracts and decentralized applications on the blockchain, provides a secure and deterministic environment for code execution, and enables interoperability between blockchains or cross-chain communications. While subnets can validate different blockchains, different blockchains cannot communicate with each other between subnets without an intermediary. Therefore, cross-subnet communication is necessary, allowing one subnet to communicate, for example, the state of blockchains within that subnet to another subnet in a secure manner without an intermediary.

[0015] Embodiments disclosed herein provide a solution to the above-mentioned computer technology-based problem, namely, cross-subnet communication within a blockchain network following a messaging protocol. The disclosed subject technology improves the functionality of the computer itself by enabling the exchange of messages (of any type) and data between different subnets based on subnet validators. This improves security while reducing verification costs and transaction speed. According to the embodiments, messages including, but not limited to, states, transactions, or events occurring on the blockchain of a first subnet can be sent to a second subnet. The second subnet can verify messages originating from the first subnet without requiring a trusted intermediary (e.g., a bridge validator) responsible for verifying messages being transferred between different blockchains.

[0016] The disclosed subject technologies further provide improvements to the technological field by facilitating communication between blockchain networks (e.g., within the primary network of the blockchain network) and subnets on various chains, enabling the transfer of data and value across different chains, and creating a dynamic, enhanced, and interconnected ecosystem. A blockchain network can facilitate communication between any subnets corresponding to any validated dataset registered in the blockchain network's registry. That is, information (e.g., messages, blocks, assets, arbitrary function calls, etc.) can be sent between blockchains and / or even between subnets that do not have the same validated dataset.

[0017] The embodiments are not limited to subnet implementations, but can be implemented, for example, within any two blockchains or VMs, or between blockchains or VMs. The message protocol may use a standardized message format for any message across all VMs (e.g., message 302). Part of the message format may include an arbitrary payload. In some implementations, VMs may choose to implement the message protocol and define their own payload formats and message processing.

[0018] For two subnets to effectively interoperate using a messaging protocol, they must know each other's expected payload format. Therefore, the payload format may be registered, for example, on the primary network, or similarly, on the primary network's chain (e.g., the blockchain network's platform chain (P-chain)). The blockchain network may include a shared registry of validator sets for all subnets. Each validator is associated with a Boneh-Lynn-Shacham (BLS) key. The primary network (of the blockchain network) can coordinate validators and create subnets. The primary network can maintain a registry of validators and their associated BLS keys. That is, all subnet validators are registered on the primary network and known to all nodes in the larger blockchain network. Thus, a subnet validator can verify that a message has been signed by the stake threshold of another subnet without needing to know anything else about the state of the other subnet.

[0019] Using BLS keys, any subnet can verify and send messages originating from another subnet within the blockchain network. Verification is achieved by leveraging a cryptographic signature scheme (which allows users to verify that the signer is authentic) and agreement between validators in both subnets participating in the transfer / communication based on a shared registry. The agreement between subnets stipulates that validators in the subnets communicating agree on who will verify each chain. Subnets within the blockchain network can interoperate using aggregate signatures from the subnets participating in the communication as the signature scheme for verifying messages between subnets.

[0020] In some embodiments, the signatures of message signature validators are aggregated into a single signature that is delivered to the destination subnet as transaction data. In some embodiments, a relay (a type of node that opts in to perform signature aggregation) aggregates the signatures and then broadcasts them to the destination subnet (i.e., how the message is delivered from the first subnet to the second subnet). In some embodiments, any relay may serve any subnet. In some embodiments, a subnet specifies which relays are allowed to deliver a particular message. By specifying a closed set of relays, the relays in the closed set can perform additional validation checks before delivering messages and drop messages that do not meet certain criteria. Thus, a closed set of relays can act as an additional layer of security to ensure that harmful messages (e.g., messages with harmful effects such as cyberattacks on funds) are stopped before they have any consequences.

[0021] When the destination subnet receives a message, the destination subnet looks up the public keys of the validators of the source subnet from the shared registry and uses them to verify the signature before executing (or broadcasting) the message. Therefore, the messaging protocol functions as an authenticated cross-network messaging protocol that utilizes a distributed validator certificate registry on the primary network. This improves security and reduces the size and verification cost of verifying messages, providing a scalable open solution for cross-subnet communication, for example, by eliminating the need for bridge validators to support specific chains. In some embodiments, the messaging protocol can function as a platform and provide a constructible structure on which users can incorporate services. In non-limiting examples, users of subnets within a blockchain network can develop cross-chain applications (such as bridges, cross-chain swaps, smart contract support, governance / cross-chain governance, etc.) via the platform.

[0022] As used herein, the term "blockchain" generally refers to an open, distributed public ledger that includes a growing list of records linked using cryptography. By design, a blockchain is resistant to data changes. A blockchain can include an auditable database that provides a distributed replicated ledger of cryptographically authenticated artifacts, where it is very difficult to tamper with the contents of the artifacts without detection, and thus the probability that the contents are a true copy of the intended contents is very high, and the contents are open for inspection via a suitable query interface.

[0023] As used herein, the term "block" generally refers to a record maintained within a blockchain. For example, each block can include the cryptographic hash of the previous block, a timestamp, and transaction data that can generally be represented as a Merkle tree root hash.

[0024] As used herein, the term "subnet" or "subnetwork" generally refers to a dynamic set of validators that collaborate to achieve consensus on the state of a set of blockchains. For example, each blockchain is verified by exactly one subnet. A subnet can verify any number of blockchains. A validator node can be a member of any number of subnets. A subnet can manage its own membership and can require that its constituent validators have certain properties.

[0025] As used herein, the term "primary network" generally refers to a special subnet that verifies an embedded blockchain. A member of a subnet can be a member of the primary network. In some embodiments, a subject that is a member of the primary network stakes (e.g., acquires or "buys") one or more tokens from the primary network. As a result, a blockchain validator can verify the embedded blockchain on the primary network and can have staked primary network tokens.

[0026] In some embodiments, subnets enable the creation of heterogeneous networks of blockchains that can communicate with one another. In embodiments disclosed herein, multiple validators supporting different blockchains can interact with one another. Accordingly, the system disclosed herein coordinates subnet interactions by learning the truthful source of blockchain states (validator data sets) and the interactions of blockchain states. In addition, the system provides incentives to subnets to make validators economically sustainable.

[0027] Both forks and subnets support diverse underlying virtual machines (VMs) and their participants, but subnets enable interoperability of different types of virtual machines from the main network (e.g., the primary network). Forks, on the other hand, divide the network into separate historical versions of the main network, making it impossible to maintain and communicate using the codebase. Thus, in some embodiments, forking is temporal, while subnets are spatial.

[0028] Embodiments disclosed herein include subnets to facilitate the operation and management of customized blockchains by reducing development time from years to just weeks. Subnets also provide performance isolation so that performance impacts on one subnet cannot affect others unless the subnets are communicating with each other. Subnets also enable creators, miners, or administrators (e.g., users) to restrict, manage, and assign validators.

[0029] In some embodiments, a customized blockchain may include a VM marketplace having subnets serviced by unique VM modules that allow users to create feature sets tailored to specific needs. For example, a gaming application within the VM marketplace might have a different VM module than a financial application.

[0030] Exemplary Architecture Figure 1 is a block diagram of a device operating environment that can implement aspects of the present disclosure. Figure 1 illustrates an exemplary network architecture 100 for providing a blockchain platform (e.g., a blockchain network implementation / deployment platform) for block management and message transfer, according to several embodiments. Blockchains in a blockchain network are validated by groups of nodes (i.e., the state of its blockchain is maintained by groups of nodes). Groups of nodes are called subnets. Thus, a blockchain platform includes subnets having corresponding validator sets. The network architecture 100 includes a shared registry of validators, which consists of validator sets from all subnets. A blockchain can be a linear chain of blocks of the same dimensions, e.g., the same height, size, length, etc. Blocks in a blockchain may contain or store data or organized information (e.g., records of information), e.g., the cryptographic hash, timestamp, and transaction data of the previous block. The network architecture 100 of Figure 1 includes one or more participants 110 and one or more participants 130, which are communicably connected via a network 150. The blockchain architecture of Network Architecture 100 can be a decentralized database that maintains a continuously growing list of records ordered as blocks. The blockchain architecture can implement a messaging protocol based on a shared registry of validators. The messaging protocol is designed to facilitate seamless communication between different chains, enable the transfer of data and values ​​across different subnets, and thereby enhance the interoperability of the blockchain network.

[0031] Participant 130 may include Participant 110, just as Participant 110 is a peer. For example, Participant 130 may include a cloud server or a group of cloud servers. In some implementations, Participant 130 may not be a cloud-based server (i.e., it may be implemented outside a cloud computing environment) or may be partially cloud-based. For example, Participant 110 may include any one of the following: a laptop computer, a desktop computer, or a mobile device such as a smartphone, palm device, or tablet device. For example, Participant 110 may be a client of a blockchain platform for creating, expanding, or otherwise modifying a customized blockchain network and / or private or public subnets. For example, Participant 110 may function as a validator. For example, Participant 110 may be a virtual machine (VM) forming a node in a blockchain network architecture 100. As a node, Participant 110 may run software to validate block and transaction data for an existing blockchain, store and validate data, and respond to network requests for data. A VM can be a computer that runs on the blockchain and allows smart contracts from multiple sources to interact with each other. Participant 110 sends a message or issues a transaction at a time requested by participant 130, via a module of participant 130, etc. The message can be validated by validators on the blockchain network.

[0032] Network 150 may include wired networks (e.g., via optical fiber or copper wire, telephone lines, etc.) or wireless networks (e.g., cellular networks, radio frequency (RF) networks, Wi-Fi, Bluetooth, etc.). Participant 110 may be any one of the following: mobile devices, laptops, desktops, tablet (e.g., palm or pad) devices, televisions, display devices, etc. Participant 110 may be controlled by a user as a set of validator nodes for making tandem decisions, such as to facilitate the operation or design of the blockchain implementation of the blockchain platform. Multiple participants 110 may have access to the blockchain platform hosted by participant 130 via online or offline connections such as wireless, wired, ad-hoc, mobile, or satellite connections. Each participant 130 may be a computing device, such as one or more desktop computers or part of a cloud computing server, including a panel mounted on a rack. The panel may include a processing board, and also a switchboard, router, and other network devices.

[0033] Furthermore, a feature of the blockchain network architecture 100 is that it can improve cross-subnet communication by reducing the processing load / cost associated with verifying messages using third-party validators. According to the embodiment, cross-subnet messaging can be improved by making transactions faster, more efficient, and more secure, and by providing reliable native communication between subnets and different blockchains within those subnets.

[0034] Participant 130 can store data from existing blockchains in a database 152 using a peer-to-peer (P2P) and / or distributed ledger scheme. Database 152 may store relevant information regarding rules for implementing, for example, a shared registry, execution and verification logic, and / or messaging protocols. In particular, participant 130 may work in conjunction to autonomously manage a decentralized database of existing blockchains via a P2P network and participant 130's distributed timestamp server. Participant 130 may be configured to implement multiple chains of the blockchain network architecture 100. For example, participant 130 may implement multiple chains of the blockchain network architecture 100, such as an asset blockchain (e.g., for creating new assets, asset exchanges, and cross-subnet transfers), a metadata blockchain (e.g., for validator coordination, tracking active subnets, and creating new subnets), and a smart contract blockchain (e.g., for creating smart contracts and applications requiring overall ordering). Multiple chains or embedded layers of the blockchain can be validated by the primary network of the blockchain network architecture 100, which includes all existing subnets. The primary network may maintain a shared registry of all validators in the subnet. Each validator is associated with a BLS key that is also registered in the primary network.

[0035] Figure 2 is a block diagram of an exemplary computing network 200 of an exemplary blockchain platform for authenticated cross-subnet communication using a messaging protocol. The exemplary computing network 200 may implement a messaging protocol for any subnet or chain within the platform, enabling both cross-chain and cross-subnet communication as well. Figure 2 illustrates participants (out of one or more participants 110) and servers (out of one or more participants 130) of the exemplary computing network 200 for use in the network architecture of Figure 1, according to several embodiments. The blockchain platform of the exemplary computing network 200 may include a blockchain represented by one or more participants 110 and multiple platform blockchains, validated and secured by a primary subnet (e.g., the primary network) and represented by one or more participants 130. The blockchain may be validated by a set of validators. A subnet may refer to a dynamic set of validators of one or more participants 110 working together to achieve consensus on the state of a set of blockchains within the platform.

[0036] One or more participant subnets 110 / 130 may be used to implement a message protocol according to one or more embodiments. For example, a message protocol can be used to send and validate messages from another subnet in the network. Each of the one or more participants 110 and one or more participants 130 may access each other and other devices within the network 150 via corresponding communication modules 210a-210b. In a non-limiting example, participant 110 may attempt to send a message to participant 130. Participant 130 may refer to another participant (not shown), such as the primary platform chain, to look up the signing key of participant 110's validator. Each of the communication modules 210a-210b may include radio hardware and software such as an RF antenna, analog circuitry, digital-to-analog conversion circuitry, and digital signal processing circuitry. The specific participants 110 and 130 depicted in Figures 1 and 2 may each include processors 205a-205b and memories 220a-220b, respectively. The memories 220a and 220b, the processors 205a and 205b, and the communication modules 210a and 210b are collectively referred to below as “memory 220,” “processor 205,” and “communication module 210.” The processor 205a of participant 110 may be used to operate participant 110, such as by executing applications and their functions rendered on participant 110. In some embodiments, participant 110 / participant 130 may act as a blockchain validator, such as by verifying transactions on an existing blockchain. Participant 110 may receive rewards (e.g., cryptocurrency) in exchange for verifying transactions or by participating in and staking network tokens of a blockchain platform. Participant 110 may be part of a set or list of validators, which may include one or more other validators of participant 110.

[0037] In general, participants 110 and 130 include a computing device comprising at least a memory 220 for storing instructions and a processor 205 configured to execute instructions for at least partially performing one or more steps as described in one or more embodiments. For example, the memory 220a of participant 110 may be used to perform functions associated with a blockchain platform hosted by participant 130, such as acting as a validator node or VM for maintaining the integrity of existing blockchains, relays, and / or other entities. Participant 110 may be one of several validators (or nodes) that can be organized into a small list of validators for randomly sampling proposers of the next block to be added to an existing blockchain. A list of validators for a subnet can be drawn by participant 130 from a given blockchain platform chain.

[0038] The settings of participant 110 can be defined via user / operator input, such as via an input device 230b. Participant 110 can implement message control as described herein based on information stored in application information 222. Data and files associated with application information 222 may be stored in data file 224 (or, for example, database 152). Participant 110 may be used by users of the blockchain platform for performing message transfer, exchanging transactions, blockchain verification, block proposal, and other blockchain functions, such as via a graphical user interface (GUI) or display for users of participant 110. For example, participant 110 may be coupled to at least one input device 230a and output device 232 accessible by the user (e.g., for user input and output perceptible to the user). Input device 230a may include a mouse, keyboard, pointer, stylus, touchscreen display, microphone, speech recognition software, GUI, etc. Output device 232 may include a display (e.g., the same touchscreen display as the input device), speaker, alarm, etc.

[0039] Memory 220b may include a message protocol 226 and a verification 228. The message protocol 226 may include instructions for creating and broadcasting messages. The verification 228 may store instructions for verifying messages in accordance with the message protocol 226.

[0040] The above description relates to certain functions performed by the processor 205a of participant 110 and other certain functions performed by the processor 205b of participant 130, but all functions described herein can be performed by participant 110 and / or participant 130 in several other alternative divisions of labor. That is, the processor 205 may perform more or fewer functions than those described above. In some embodiments, some or part of participant 110 may be co-located with participant 130, that is, participant 130 may be located remotely from participant 110, or both participant 110 and participant 130 may be part of the same, larger computing system, network, or architecture. It is also understood that participant 110 may contain verification information in its memory 220a, and participant 130 may contain application information and data files in its memory 220b so that they have a parallel structure.

[0041] The techniques described herein may be implemented as a method performed by a physical computing device, as one or more non-temporary computer-readable storage media that store instructions causing the method to be performed when executed by a computing device, or as a physical computing device specially configured with a combination of hardware and software that causes the method to be performed.

[0042] Figure 3 is an exemplary system flow diagram 300 illustrating aspects of cross-subnet communication in a blockchain network according to several embodiments. System flow diagram 300 illustrates message transactions between subnet 310 and subnet 320 (e.g., a first and a second subnet). Subnet 310 may represent a single blockchain validated by a set of validators or a set of chains. Subnet 320 may represent a single blockchain validated by a set of validators or a set of chains. Subnets 310 and 320 may be validated by different sets of validators. According to embodiments, the cross-subnet communication described herein allows the passage of any data message so that any subnet in the blockchain network can send any type of message to any other subnet.

[0043] As described, blockchain network 340 is a customized blockchain and may include one or more network layers, such as primary network 330. Primary network 330 may be responsible for coordinating and maintaining validators and subnets within blockchain network 340. Each blockchain in blockchain network 340 is validated by only one subnet, while a subnet can validate many blockchains.

[0044] Figure 3 illustrates two subnets (i.e., subnet 310 and subnet 320), but embodiments are not limited to these and may include multiple subnets validating multiple blockchains. A subnet refers to a set of validators (or nodes) registered in a shared registry on the primary network. A node may be a member of one or more subnets. Validators who wish to validate chains that support cross-chain communication enter the validator dataset. This allows validators to become participants who cooperate with other validators to achieve a consensus on the state of the chain. The shared registry defines which nodes belong to which subnets (i.e., which nodes validate which one or more subnets). Thus, all validator and subnet associations are known to all nodes in the blockchain network 340. In some embodiments, the shared registry may be on a designated chain on the primary network 340.

[0045] Each validator is assigned a corresponding signing key (e.g., a BLS key). In some implementations, signing key registration is initiated by each validator. For example, when a validator is created, added to the validator dataset, and / or registered with the primary network, a signing key is generated, assigned to the validator, and registered with the primary network. Therefore, non-validator nodes do not generate signatures. For the purposes of this example, subnets 310 and 320 do not share a set of validators, but belong to the same blockchain network 340. In some implementations, subnets 310 and 320 may share one or more validators or sets of validators. In some implementations, the signing keys are stored in a shared key registry on the chain of the primary network 340. The shared key registry may be the same as or different from the shared registry that stores the validator dataset of blockchain network 340.

[0046] Message 302 is created and sent in subnet 310. Messages can be issued by a user. Creating a message may involve generating a corresponding unique message ID. The message ID may be a monotonic counter of a given destination subnet. This counter is incremented by 1 each time a message is submitted to and / or broadcast to a given destination subnet ID. Message 302 may include, but is not limited to, the message ID, destination chain ID, destination subnet ID, source subnet ID, payload, payload length, validator bit vector, validator bit vector length, destination address corresponding to the destination chain in the destination subnet, fee contract address corresponding to the token used to pay the fee for sending the message, fee amount, required gas limits (i.e., a value sufficient to be provided when executing the message on the destination and delivering the message on the destination), and a set of relay addresses corresponding to relays authorized to deliver the message, etc. The block representing message 302 is accepted and committed as a block. Subsequently, one or more validators in the set of validators in subnet 310 sign message 302 using their signing keys.

[0047] Message 302 may contain arbitrary bytes and any format. In some implementations, the contents of message 302 are converted to conform to a standardized message format. The standardized message format and its implementation may be defined by the subnet and / or VM. In some implementations, the set of relay addresses includes an empty array indicating that any relay (validator or non-validator) can deliver the message. In some embodiments, a hash of the message (and other metadata) is stored in a key-value database that maps, for example, the destination subnet ID and message ID to the message hash. The message hash may be held within the VM state (e.g., state try) and later used to verify the correctness of the message contents during node state synchronization.

[0048] In some embodiments, the message database may be communicatively linked to the accepted block database. Values ​​stored in the message database may not be made available within the VM (i.e., message values ​​cannot be read from within a transaction). Strict consistency of the message database across all validators is not required, as it does not need to process new transactions and does not affect the state of the blockchain. The message database may be limited in size over time through an automatic pruning mechanism that cleans up messages already received by the destination subnet. The VM state synchronization mechanism may also consider the message database by having a synchronized node query peer for messages to populate the message database after the synchronization of the current state of the subnet / chain is complete. As described, the source subnet includes a message ID that is assumed to exist and a message hash. When synchronizing, a node can verify that the peer has given it the correct message data by computing its hash and checking it against the message hash in the VM state. In some implementations, validator nodes generate a public signature for the message after storing the message in the message database.

[0049] According to one embodiment, all validators in the set of validators in subnet 310 are willing to sign the message, but not all validators are required to sign the message in order to validate it. The signed block can be added to the blockchain, creating an immutable and transparent record of a first transaction, including the data and message payload of message 302 created in subnet 310. The message payload may conform to a standardized payload format across all subnets and / or VM communications. In some embodiments, each subnet has the ability to customize and format the payload to meet its own standards and requirements.

[0050] Once a message is accepted, message 302 (corresponding to the first transaction) is issued. The event indicates that a successful message has been submitted and stored in the message database. The token fee amount (hereinafter referred to as the "message fee") may be transferred to the source address before the event is issued. The source subnet (e.g., subnet 310) tracks the fee asset type and transaction fee for each unique message ID (e.g., in the subnet VM state) and surfaces these values. A user may use only a single fee asset type to pay for a given message, as specified by the fee contract address of the initial call to send a cross-subnet message (i.e., message 302). A user may add to the initial fee amount later, but cannot change the asset type.

[0051] The relay 304 receives message 302 and queries the validators on subnet 310 for their signing keys to identify the signatures of the validators that signed (i.e., validated) message 302. The identified signing keys corresponding to the validators of message 302 are combined to construct an aggregate signature. The validator signatures generated using the signing keys may be of length L. The signing keys are constructed so that two or more signatures generated using the signing key can be aggregated into a signature of the same length L. Aggregating signatures compresses the data into a smaller form without losing any information, and ensures that even in that aggregated form, the validators of the signed message 302 can be identified through the aggregated signature. That is, the aggregate signature indicates which validator signed message 302.

[0052] In some embodiments, when a relay constructs an aggregated signature, the relay tracks which validator signature to use by creating a bit vector in canonical order of source subnet validators, where the index of the validator whose signature was used is set to 1 and all other bits are set to 0. The canonical order is defined by ascending validator start times, followed by node IDs (to ensure uniqueness). The bit vector may be ordered by start time to make it more robust to changes in the validator set. The bit vector may be padded with trailing zeros. Padding the bit vector with undefined zeros does not affect the correctness of the bit vector if new validators are added after the aggregated signature and bit vector have been created.

[0053] In some embodiments, the caching mechanism is implemented by a relay to reduce the cost of constructing the aggregated public key. The caching mechanism can track the aggregated public key of a given validator bit vector as long as there are no changes to the validator public key or validator dataset on the primary network using the cache. Each validator node can maintain a cache for its subnet and update / invalidate the cache entry whenever a change is identified in the validator dataset on the primary network. In some implementations, a change identified in the validator dataset on the primary network triggers an update to the corresponding aggregated key in the cache. In some implementations, a small group of aggregated keys is generally cached, and a subgroup is selected that is all represented in the validator bit vector.

[0054] In some implementations, one or more validators may be offline. In this case, signatures are reaggregated, individual signatures for a given message ID are queried, and offline nodes are allowed to generate signing keys as needed. Signing keys may not be persistent and are therefore cached to optimize queries for recently generated signatures.

[0055] The relay 304 creates transaction 306, which includes the aggregate signature and message 302, and sends this transaction to subnet 320. In some implementations, transaction 306 includes a bit vector identifying the validators who participated in generating the aggregate signature, and other metadata. Transaction 306 may include at least a portion of the message payload to be sent to subnet 320 (e.g., including any binary large object of bytes). In some implementations, the payload is a user-specified payload. In a non-limiting example, the payload may indicate the message (e.g., the raw message as byte input, message length, etc.), the sender, and the destination (e.g., a chain or subnet) for the message (or transaction). Transaction 306 may specify the amount of the message fee for delivering the payload to its destination (e.g., subnet 320). In a non-limiting example, the message fee may correspond to a maximum value or a range of how much the user is willing to pay for the transaction to be delivered to that destination.

[0056] According to some embodiments, in order to create a valid aggregate signature, relay 304 must accumulate enough signatures to represent the stake threshold ratio of the source subnet (e.g., subnet 310). Transaction 306 is then created to include a valid aggregate signature and is forwarded to the destination subnet (e.g., subnet 320) based on the fact that the stake threshold ratio is met. According to some embodiments, for an aggregate signature to be considered valid, only one relay needs to successfully aggregate signatures, and only the stake ratio of the source subnet needs to be represented in the aggregate signature. In some implementations, the threshold signature scheme may be implemented when the subnet uses an asynchronous distributed key generation phase and then registers its threshold key in a shared key registry. Other cryptographic signature schemes understood by those skilled in the art may be used. In some implementations, a relay may not have enough signatures to represent a sufficient ratio of the source subnet stake. In this case, an automatic retry mechanism may be activated that allows the relay to query its peers for those signatures.

[0057] According to one embodiment, the stake threshold may be set by the validator of the destination subnet as a security parameter for message verification. The threshold of a given destination subnet may be publicly known, and the relay may be configured to include the minimum number of signatures in the aggregate to reach that threshold in order to minimize transaction fees (for example, more signatures in the aggregate signature may incur higher transaction fees). The subnet (or VM) requires any amount of gas to perform message forwarding and / or transactions.

[0058] In some embodiments, the relay 304 delivering message 302 is responsible for prepaying the gas fee (or transaction fee) on the destination subnet (or chain), but receives the fee amount paid by the transaction on subnet 310 on the source chain. In embodiments, the relay implementation allows for configuring which fee assets each relay is willing to accept, and may not relay messages for which fees are paid with other asset types. This implementation also allows checking whether the delivery of a given message is beneficial by comparing the value of the fee amount with the value of the transaction fee prepaid on the destination subnet (or chain).

[0059] The relay 304 may not know exactly how much gas might be required before attempting to execute a message. This could lead to a denial-of-service (DOS) vector, in which case the relay may not provide sufficient gas for message execution and therefore pay the transaction fee but not be entitled to recover the message reward paid as a fee on the source subnet (or chain). To prevent this, the sender (e.g., source subnet or chain) may specify the required gas limit within the message payload. For example, message 302 on subnet 310 may specify the amount of gas (i.e., transaction fee) that will be used for message 302 to be delivered in order to ensure successful delivery. Relay 304 must provide at least this amount of gas that should be available to relay the message to subnet 320. As long as this requirement is met by the relay, the message is marked as "received" and the relay is entitled to pay the fee amount on the source subnet (or chain). In some implementations, when a relay delivers a message and aggregate signature to the destination subnet, the relay may specify the address to which it wishes to receive the reward paid on the source subnet by the sender of the transaction.

[0060] Transaction 306 submitted from relay 304 to subnet 320 may be called the second transaction (the first transaction corresponds to message 302 sent from subnet 310 and received by relay 304). The second transaction may include, for example, one or more of message 302, the payload, and the aggregated signature. In some implementations, relay 304 is configured to generate signing keys, broadcast them, aggregate them, and embed them in the signed transaction (e.g., the second transaction).

[0061] In the example in Figure 3, the relay 304 is configured to query validators and aggregate signatures, but embodiments are not limited thereto. According to embodiments, the message protocol may include a broadcast mechanism that enables any entity or node (off-chain) within the blockchain network 340 to act as a message replay and, based on the fact that a block corresponding to message 302 has been accepted on subnet 310, to query the validators on subnet 310 for their signing keys and subsequently aggregate signatures. In non-limiting examples, via the broadcast mechanism, one subnet may expose information (about on-chain state, network, and / or VM state) to any other chain that wishes to consume that information. In non-limiting examples, once a transaction has been accepted on a subnet where a set of validators validates the message, that set of validators may make their public signing keys public to any entity to facilitate the transmission of the corresponding message. An entity may listen for new blocks in the blockchain network and scan blocks for valid events corresponding to a first transaction originating from the subnet.

[0062] In some embodiments, entities on the blockchain network 340 may be incentivized to relay messages in the form of a transaction fee paid by the message sender (as shown in the message 302 metadata). In non-limiting examples, the fee amount may be specified per message and paid by the message sender when the message is first submitted. In non-limiting examples, the fee may be locked on the source subnet until it receives the received information returned from the destination subnet to be paid to the relay. In non-limiting examples, a gas fee proportional to the message length may be charged to prevent the message from being a DoS vector. In non-limiting examples, a fee for gas may be charged based on the number of validators identified in the bit vector to incentivize the relay to select the smallest possible number of validators that still represent the required stake threshold ratio. If the offered fee amount is insufficient to incentivize any relay, other entities have the ability to add to the fee amount for a given pending message. In some embodiments, entities may not be required to participate in message relaying or may not be incentivized to do so. Therefore, entities may use node resources instead. To prevent validators from effectively opting out of generating individual signatures, other validators monitor their participants and bench peers that are not properly participating. In a non-restrictive example, if a node generates an invalid signature for a given message, its peers can identify the Byzantine behavior and bench the node for a period of time. Validators may also be configured to identify whether one of their peers did not generate a signature to sign a message when it was created, and bench them in this case as well.

[0063] In a non-restrictive example, a user in a user interface (UI) may act as a relay by sending a transaction on the source chain, waiting for the transaction to be accepted, querying the validator on the source chain, generating an aggregate signature, and then broadcasting the transaction with the message and aggregate signature on the destination chain. This instance of relaying messages may need to send multiple transactions, one on the source chain and another on the destination chain. In a non-restrictive example, a node may communicate a message to the destination chain / subnet, for example, via gossip. In a non-restrictive example, a message forwarding request may be logged on a primary network 330, which is centrally available to all subnets within the blockchain network 340.

[0064] In embodiments, an entity (such as relay 304) may include an opt-in / opt-out configuration. The opt-in / opt-out configuration may include the location of a key file used to sign transactions on the destination subnet, as well as a URL for the destination subnet API used to broadcast transactions. In a non-restrictive example, if the opting node is running the destination subnet, the URL could be a localhost endpoint; otherwise, the URL could be a third-party API provider. When a node that has opted in to be a relay starts up, a message is printed out clarifying that the account on the destination subnet must have a balance of native tokens sufficient to cover the transaction fees for relaying messages and signatures. As described, a message sender (e.g., subnet 310) can specify a set of relays (i.e., a set of relay addresses) that are permitted to deliver a given message. If no set of relays is specified (e.g., the set of relay address arrays is empty), any relay is permitted to deliver the message. This feature allows for validation of custom relays for specific message types. In a non-limiting example, a closed set of relays could perform checks to verify that delivering bridged messages would underestimate the bridge, drop such messages, and not trigger an alarm if this occurs. This allows for the incorporation of an additional security layer, which is highly beneficial for high-value applications that can be built on top of the message protocol. Subnet 320 receives, accepts, and validates transaction 306. Subnet 320 validates transaction 306 and forwards the message to its destination address. Transaction 306 is validated by determining whether subnet 310's stake threshold ratio is included in the aggregate signature by referencing primary network 330. For example, the destination subnet could verify that at least a certain percentage of the source subnet's stake signed the message.Verifying transaction 306 also ensures that the transaction has not been processed previously. Subnet 320 verifies the aggregate signature by looking up the validator set of subnet 310 at a specified block height in the primary network and comparing the aggregate signature with the public key in the primary network. Thus, the transaction is verified based on the aggregate signature.

[0065] Validating transactions in the destination subnet also provides replay protection for messages by using a unique message ID for each received message. All nodes must perform this validation against the height of the primary network to ensure deterministic execution of transactions. If the message passes validation, the destination subnet parses the message and its payload. The payload may be parsed according to the subnet's (or VM's) standardized payload format. The destination subnet then checks whether it has already executed a given message ID from a given source subnet ID. If it has, an error occurs and it is returned early; otherwise, it marks the message ID as received and passes the message to the destination address. Marking the message as received first, for example, before passing it to the destination chain, prevents re-entry attacks where the destination address makes recursive callbacks to the clearinghouse.

[0066] In some embodiments, if subnet 320 (or destination chain) returns any error (e.g., a gas shortage error), the message payload may be stored in the receiver precompiled state of the destination subnet so that it can be retried by someone (e.g., another relay) in another transaction with a higher gas limit, activating the retry mechanism. By retrying the execution of the message, it becomes possible to recover a message that was delivered to the destination but failed due to a gas limit set low by the sender. The entity retrying the execution first looks up a given message payload previously stored in the precompiled state and then attempts to deliver the message again in the same amount provided by the caller. If the call is successful, the payload is removed from the precompiled state so that it is executed only once. If an initial call to receive a cross-subnet message (i.e., message 302) necessitates storing the message payload in the precompiled state, the destination subnet (or VM) may charge a gas fee proportional to the payload length. When calculating whether a given message delivery is beneficial, the relay must consider this possible fee amount.

[0067] In some implementations, the shared registry is located near the tip of the primary network to reduce the cost of looking up validators. In a non-restrictive example, a VM may validate a message against a canonical primary network block height provided by the Proposer VM for a given block in a subnet. This block height value is guaranteed to be the same across all subnet validators in a given block in the subnet and represents the most recently accepted block in the primary network across all validators (although individual validators may accept the next block before other validators, this value is accepted network-wide). If an aggregated signature becomes outdated due to a new primary network block before it is accepted on the destination chain, the relay 304 can refresh the signature itself, as long as it still has a signature that represents the required weight of the stake threshold.

[0068] In a non-restrictive example, the stake threshold may be a state where validators representing at least 80% of the members of subnet 310 have signed based on the aggregate signature received in transaction 306. Since the shared registry shows the validators for any given subnet, subnet 320 can leverage the primary network 330 to determine and prove (to any entity in the network) that a given message has been signed by a specific percentage of the validators in subnet 310. In this way, the validators in the destination subnet have an unforgeable proof and can authenticate that the message was indeed signed by the set of validators in the source subnet. This confirms that the payload was indeed sent by the source subnet and does not need to know anything else about the state of other networks.

[0069] According to one embodiment, a destination subnet (e.g., subnet 320) may track a relay reward address on the source subnet that incurs a fee for each successfully delivered message ID. In a non-limiting example, the (original) destination subnet may then go to send a message back to this same (original) source subnet, where the original destination subnet looks up the message ID received from the original source subnet and the relay reward address for each message. This information may be included in the payload format and can serve as an acknowledgment from the original destination subnet that a given message was successfully delivered. This requires maintaining a mapping of message IDs and relay reward addresses in an iterable manner. Tuples corresponding to this mapping may be maintained in array storage.

[0070] To close the loop, the original destination subnet pays a previously stored fee by looking up the relay reward address specified in the message payload of a given message ID previously sent, when it receives a message with the received information. Thus, the relay is rewarded for delivering the message to the given destination subnet when the destination subnet next sends the message back to the original source subnet. The maximum batch size of the number of received messages that can be included in a single message may be limited. For example, if a message flow between two subnets receives more messages than one subnet sends, exceeding the maximum batch size, the relay (or anyone in the blockchain network) may start sending empty messages back to the destination subnet so that the received messages can be processed. While the embodiments describe cross-subnet communication, the embodiments are not limited to communication between subnets. Aspects of the embodiments may be implemented, for example, to facilitate communication between subnets and the primary network, cross-chain communication, etc.

[0071] According to some embodiments, in order to send a message between a subnet and a chain, the primary network validator may not need to create a signature / signing key to prove the occurrence of a given event, because all subnet validators can also verify the state of the chain within the blockchain network. Instead, the subnet validator checks its local node to verify the occurrence of the event.

[0072] According to some embodiments, a smart contract may be deployed on a chain to send a message from a designated chain (e.g., a contract chain (C-chain) of a blockchain network) to a subnet. The smart contract may take arbitrary bytes as a message, assign a unique, monotonically increasing ID to the message for a given destination subnet, and store the hash of the message in the contract state. The smart contract may also transfer a given fee amount to its control and track the message's fee information. When a new message is successfully submitted, the smart contract also emits an event. Nodes opting in to relay messages from the chain to the subnet poll for new message events emitted by the smart contract and submit these messages directly to the destination subnet in the transaction.

[0073] Since a signing key is not required, the transaction does not require an aggregate signature for the subnet to verify. Therefore, when the destination subnet receives the message from the chain, the transaction can be verified by fetching the message hash stored in the chain state and verifying that the provided unsigned message yields the same hash. After verification of the message hash, the execution of the message received on the destination subnet from the chain will be the same as a message received from any other subnet. Thus, sending a message from the chain to a subnet involves providing replay protection, storing the relay reward address, and storing the payload in the subnet state when an error is identified.

[0074] In some embodiments, a transaction may include a transaction type indicating whether the message is from a subnet and whether the message is from a chain. The transaction type may be included in the message as metadata, preventing lookback costs during bootstrapping. During bootstrapping, the node does not need to verify the aggregate signature because it knows whether the accepted block contained an aggregate signature, and the accepted block must be valid at the time the block is validated / accepted by the blockchain network. For example, if a validator attempts to build a block containing a first transaction type, it must first verify that all messages contained in the block are valid by verifying their aggregate signature. If any of the messages are invalid, the transaction is dropped from the blockchain memory pool. If any of the messages contained within the first transaction type are invalid, the block is considered invalid. Similarly, a second transaction type may include an array of message IDs to import from the sending chain and the serialization of the complete unsigned message for each transaction. To validate a transaction, the node looks up a hash of a given message ID from the current chain state and verifies that the hash matches the hash of the provided unsigned message. If the hashes do not match, the transaction is considered invalid and dropped from the blockchain memory pool.

[0075] In some embodiments, the message protocol may include an update function. In a non-limiting example, when tokens are moved from a second subnet to any other third subnet, the second or third subnet sends a cross-subnet message back to the native chain indicating an accounting update (for example, moving X locked tokens to the third subnet and sending another message about the transfer to the third subnet). Even after the account balance is updated, the tokens remain locked on the native chain, and the native chain may automatically send the next message to the third subnet to complete the transfer.

[0076] Figure 4 is a block diagram illustrating an exemplary computer system 400 that can implement an embodiment of the technology in question. System 400 may be configured for cross-chain (or subnet) communication using a messaging protocol according to a particular embodiment of the present disclosure. System 400 may be or include a blockchain system / platform for managing blockchains, each of which may be a linear chain of blocks such that each block has a parent block. In some implementations, system 400 may include one or more computing platforms 402. Computing platform 402 may correspond to a server component of the blockchain platform, which may be similar to or identical to participant 130 in Figure 1, and include a client computing device of participant 110 in Figure 1, and include a processor 205 in Figure 2. For example, computing platform 402 may be configured to perform blockchain pre-compilation to generate, verify, and deliver messages from a source blockchain to a destination blockchain. Similarly, blockchain pre-compilation may be applied, for example, to messages between subnets and chains and / or two subnets (e.g., subnets 310 and 320 in Figure 3).

[0077] Computing platform 402 can be configured to implement a messaging protocol that enables the transfer of messages from client computing devices. Computing platform 402 may represent a blockchain platform (e.g., blockchain network 340). In some embodiments, computing platform 402 corresponds to a blockchain that creates messages or a blockchain that receives messages. In some embodiments, computing platform 402 corresponds to a VM that sends messages to a chain, VM, and / or subnet. Computing platform 402 may be configured to communicate with one or more remote platforms 404 according to a client / server architecture, a peer-to-peer architecture, and / or other architecture. Remote platforms 404 may be configured to communicate with other remote platforms via computing platform 402 and / or according to a client / server architecture, a peer-to-peer architecture, and / or other architecture. As an example, remote platform 404 may include a relay that determines which set of validator nodes are used to sign messages. Remote platform 404 may be configured to trigger an output of system 400 on a client device of remote platform 404 with enabled access (e.g., based on analysis by computing platform 402) according to stored data. Any external blockchain platform built upon the platform / metadata chain of computing platform 402, which is dependent on the primary blockchain, can also realize the benefits of a messaging protocol. In this way, the platform chain, the primary network, and other entities of the blockchain platform can communicate with computing platform 402.The computing platform 402, the external resource 424, and the remote platform 404 may communicate with each other and / or be mutually accessible via the network 150.

[0078] The computing platform 402 may consist of machine-readable instructions 406. The machine-readable instructions 406 may be executed by the computing platform to implement one or more instruction modules. An instruction module may include a computer program module. An implemented instruction module may include one or more of the following: a message generation module 408, an acceptance module 410, a first verification module 412, an aggregation module 414, a transaction module 416, a second verification module 418, and / or other instruction modules.

[0079] The message generation module 408 is configured to generate a message in a first blockchain that is attempting to send a message to a second blockchain. Both the first and second blockchains are part of a blockchain platform that includes multiple blockchains. In some implementations, the message is generated in the first subnet to be delivered to the second subnet (or chain). The second blockchain may include one or more destination blockchains or subnets. According to some embodiments, a given message can be delivered to its destination only once. In some embodiments, the first blockchain specifies that a message may be delivered to one or more destination blockchains (for example, to notify any destination chains that wish to receive the message about a value updated on the source chain). Each blockchain (i.e., the first blockchain and one or more second blockchains) is validated by its own set of validators (or nodes) called subnets. The validators of the first blockchain may be called the first set of validators, and the validators of the second blockchain may be called the second set of validators.

[0080] According to the embodiment, a message may include a message ID that functions as a counter for a given destination chain, blockchain, and / or subnet. The message ID can be used to ensure that a message is processed and delivered only once on the destination chain, even if the same message is sent multiple times by a source chain (e.g., on a first blockchain) to a destination chain (e.g., on a second blockchain). A source chain may submit the same message multiple times, for example, if it believes that it encountered an error and that the message failed to be processed on the destination chain. A message can be submitted multiple times to the destination chain, but the message is processed and delivered only once. Submissions following the delivery of a message are rejected and do not result in multiple deliveries. This prevents source chains from sending messages erroneously and destination chains from receiving multiple transactions erroneously.

[0081] The acceptance module 410 is configured to accept a first transaction containing a message as a confirmed block in the first blockchain. The first transaction may include message content and a message payload. The message payload contains metadata describing the message. In a non-limiting example, the payload may identify a second blockchain as the destination of the message. In a non-limiting example, the message (or message payload) on the source chain may specify the amount of gas (i.e., transaction fee) required to ensure the successful delivery of the message to the destination.

[0082] The first verification module 412 is configured to perform the message verification process on the first blockchain. The verification process may include signing the message using a signing key in the first set of validators on the first blockchain. The validators on the first blockchain confirm that the first transaction is accepted and that one or more of the validators sign the message using the signing key. The first set of validators is stored in a shared registry between blockchains on the blockchain platform. The shared registry defines which validators belong to which blockchain. The shared registry may be maintained on a distributed ledger (e.g., the primary network or primary chain of the blockchain platform) that is known to both the first and second blockchains. The signing key is configured before the transaction. The shared registry may include a key registry for storing and tracking validator signing keys. The signing key may be retrieved from the key registry for the verification process. In some implementations, the signing key is stored in a separate database or a shared key registry. The verified message is then broadcast to peers on the blockchain platform.

[0083] The aggregation module 414 is configured to perform the aggregation process and generate an aggregate signature based on the signing keys of one or more validators that signed the message. In some embodiments, entities on the blockchain platform that have opted in to signature aggregation (e.g., relays, nodes, UIs, etc.) listen to broadcasted (verified) messages, take the messages, and identify which nodes participated in message verification. Based on the identified nodes, an aggregate signature is generated that represents all the signing keys of the validators in the first set of validators that signed the message. The aggregate signature may be the same length as any individual signature generated using any of the signing keys. In some embodiments, entities on the blockchain platform are incentivized to relay messages using fees paid in a first transaction on the first blockchain (e.g., message fees).

[0084] In some embodiments, one or more validators in a first set of validators signing a message must satisfy at least a threshold stake ratio of the first set of validators. That is, not all validators in the first set of validators must sign a message to send to its destination. When a sufficient number of signatures have accumulated to satisfy the threshold stake ratio, an aggregate signature can be generated. In some implementations, the threshold stake ratio is set by validators on a second blockchain as a security parameter for message verification. The threshold of the destination blockchain may be publicly known. In some implementations, the message relay entity must pay a higher transaction fee the more signatures are included in the aggregate signature. Therefore, to reach that threshold and minimize costs, the message relay entity would like to include a minimum number of signatures in the aggregate signature.

[0085] According to some embodiments, when a block is accepted on the originating blockchain, an event containing a message to be relayed to a corresponding destination may be triggered. An off-chain entity within the blockchain platform scans for outgoing events and selects a message to replay, based at least on the message payload. In a non-limiting example, after the first blockchain accepts the message, the entity selects a first transaction and generates an aggregate signature.

[0086] According to one embodiment, the aggregation process may include querying a first set of validators and, based on the query, identifying one or more validators in the first set of validators that signed a message from a first transaction. The aggregation module 414 may further be configured to generate a bit vector in canonical order of the first set of validators, where elements corresponding to the index of validators that signed the message are set to 1 and elements corresponding to the index of validators that did not sign the message are set to 0.

[0087] Transaction module 416 is configured to generate a second transaction, which includes at least a message and an aggregate signature. The second transaction is a signed transaction created based on the aggregate signature and submitted onto the second blockchain. The aggregate signature may be embedded in the second transaction. In some embodiments, the second transaction includes a bit vector that identifies which validators participated in signing the first transaction and / or other metadata. In non-limiting examples, the entity that selects the first transaction and generates the aggregate signature is further configured to submit the second transaction to the second blockchain. According to embodiments, system 400 is further configured to accept the second transaction on the second blockchain and proceed with the verification of the second transaction.

[0088] The second verification module 418 is configured to perform a verification process for a second transaction in the second blockchain by utilizing a shared registry. The verification process in the second blockchain may include identifying one or more validators in the first set of validators that signed the message, based on the aggregate signature. Then, by referring to the shared registry, it can be determined whether the stake threshold ratio of the first set of validators is included in the aggregate signature.

[0089] According to one embodiment, the system 400 is further configured to deliver the message contained in the verified second transaction to its corresponding destination. The message can only be delivered to the destination once. The destination may include, for example, a second blockchain, a chain on the second blockchain, or an application on the second blockchain. In some embodiments, the message payload may specify a destination address. According to another embodiment, the system 400 is further configured to deliver the second transaction to the destination address based on a successful verification process.

[0090] In some implementations, the computing platform 402, the remote platform 404, and / or external resources 424 may be operationally linked via one or more electronic communication links. For example, such electronic communication links may be established at least in part via a network 150, such as the Internet and / or other networks. This is not intended to limit the scope of the disclosure, and it will be understood that the scope of this disclosure includes implementations in which the computing platform 402, the remote platform 404, and / or external resources 424 may be operationally linked via several other communication media.

[0091] A given remote platform 404 may include a client computing device which may include one or more processors, each configured to run a computer program module. The computer program module may be configured to enable an expert or user associated with the given remote platform 404 to interface with system 400 and / or external resources 424, and / or to provide the remote platform 404 with other functions arising herein. As a non-limiting example, a given remote platform 404 and / or a given computing platform 402 may include one or more of the following: a server, a desktop computer, a laptop computer, a handheld computer, a tablet computing platform, a netbook, a smartphone, a game console, and / or other computing platforms. External resources 424 may include information sources outside of system 400, external entities participating in system 400, and / or other resources. For example, external resources 424 may include externally designed blockchain elements and / or applications designed by third parties. In some implementations, some or all of the functions arising herein from external resources 424 may be provided by resources included in system 400.

[0092] Computing platform 402 may include electronic storage 426, a processor such as processor 205, and / or other components. Computing platform 402 may include communication lines or ports that enable the exchange of information with a network and / or other computing platforms. The illustrative solution of computing platform 402 in Figure 4 is not intended to limit it. Computing platform 402 may include a plurality of hardware, software, and / or firmware components that work together to provide computing platform 402 with the functions arising herein. For example, computing platform 402 may be implemented by a cloud of computing platforms working together as computing platform 402.

[0093] The electronic storage 426 may include non-temporary storage media for electronically storing information. The electronic storage media of the electronic storage 426 may include, for example, one or both of the system storage provided integrally (i.e., substantially inremovable) with removable storage that is removablely connectable to the computing platform 402 and / or the computing platform 402 via a port (e.g., a USB port, a FireWire port, etc.) or a drive (e.g., a disk drive, etc.). The electronic storage 426 may include one or more of the following: optically readable storage media (e.g., optical discs, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drives, floppy drives, etc.), charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drives, etc.), and / or other electronically readable storage media. The electronic storage 426 may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and / or other virtual storage resources). The electronic storage 426 may store software algorithms, information determined by the processor 205, information received from the computing platform 402, information received from the remote platform 404, and / or other information that enables the computing platform 402 to function as described herein.

[0094] The processor 430 may be configured to provide information processing capabilities in the computing platform 402. Therefore, the processor 430 may include one or more of the following: a digital processor, an analog processor, digital circuits designed to process information, analog circuits designed to process information, a state machine, and / or other mechanisms for electronically processing information. Although the processor 430 is shown as a single entity in Figure 4, this is for illustrative purposes only. In some implementations, the processor 430 may include multiple processing units. These processing units may be physically located within the same device, or the processor 430 may represent the processing capabilities of multiple devices working together. The processor 430 may be configured to run modules 408, 410, 412, 414, 416, and / or 418, and / or other modules. The processor 430 may be configured to run modules 408, 410, 412, 414, 416, and / or 418, and / or other modules, by software; hardware; firmware; any combination of software, hardware, and / or firmware; and / or other mechanisms for configuring processing power on the processor 430. As used herein, the term “module” may mean any component or set of components that perform a function attributable to the module. This may include one or more physical processors in which processor-readable instructions, circuitry, hardware, storage media, or any other components are executed.

[0095] While modules 408, 410, 412, 414, 416, and / or 418 are illustrated in Figure 4 as being implemented within a single processing unit, it should be understood that in an implementation where the processor 430 includes multiple processing units, one or more of modules 408, 410, 412, 414, 416, and / or 418 may be implemented remotely from other modules. The descriptions of the functions provided by the different modules 408, 410, 412, 414, 416, and / or 418 described below are for illustrative purposes only and are not intended to limit the functions of any of modules 408, 410, 412, 414, 416, and / or 418, as they may provide more or fewer functions than those described. For example, one or more of modules 408, 410, 412, 414, 416, and / or 418 may be excluded, and some or all of their functions may be provided by other modules among modules 408, 410, 412, 414, 416, and / or 418. As another example, processor 430 may be configured to run one or more additional modules that can perform some or all of the following functions that belong to one of modules 408, 410, 412, 414, 416, and / or 418.

[0096] The techniques described herein may be implemented as a method performed by a physical computing device, as one or more non-temporary computer-readable storage media that store instructions causing the method to be performed when executed by a computing device, or as a physical computing device specially configured with a combination of hardware and software that causes the method to be performed.

[0097] Figure 5 illustrates an exemplary flowchart (e.g., process 500) for cross-chain communication according to a particular aspect of the present disclosure. For illustrative purposes, the steps of the exemplary process 500 are described herein as occurring sequentially or linearly. However, multiple instances of the exemplary process 500 may occur in parallel, overlapping in time, occurring nearly simultaneously, or in an order different from the order illustrated in process 500. In addition, the blocks of the exemplary process 500 do not have to be performed in the order shown, and / or one or more blocks of the exemplary process 500 may not be performed.

[0098] In step 502, process 500 may include accepting a first transaction in the first blockchain, which includes a message and a message payload. According to one embodiment, the message payload may include metadata such as the first blockchain, the destination blockchain, and a transaction fee. In step 504, process 500 may include verifying the message in the first blockchain by signing the message using the signing keys of one or more validators in a first set of validators in the first blockchain. According to one embodiment, once the number of validators in the first set of validators is met, the first transaction is issued by the first blockchain and broadcast to the blockchain network.

[0099] In step 506, an aggregate signature is generated based on the signing keys of one or more validators in the first set of validators. The signing keys of the first set of validators are stored in a shared registry. The shared registry may be maintained on a distributed ledger (e.g., the primary network or primary chain of a blockchain platform) that is known to both the first and second blockchains. The aggregate signature may be the same length as any individual signature generated using any of the signing keys. In some implementations, a relay queries the first set of validators to identify which validators signed the messages contained in the first transaction. In step 508, the second transaction is submitted onto the second blockchain. The second transaction may include a message, a message payload, and an aggregate signature. According to one embodiment, generating an aggregate signature may involve generating a bit vector in canonical order of the first set of validators. In the bit vector, elements corresponding to the indices of validators that signed the message are set to 1, and elements corresponding to the indices of validators that did not sign the message are set to 0.

[0100] In step 510, the second transaction is verified on the second blockchain based on the shared registry. According to the embodiment, one or more validators in the first set of validators are identified by referencing the aggregate signature. Once the validators to sign are identified, it is verified whether the aggregate signature contains the stake threshold ratio of the first set of validators.

[0101] The techniques described herein (e.g., process 500) may be implemented as a method performed by a physical computing device, or as one or more non-temporary computer-readable storage media that store instructions causing the method to be performed when performed by a computing device, or as a physical computing device specially configured with a combination of hardware and software that causes the method to be performed.

[0102] In some implementations, one or more operational blocks in Figure 5 may be executed by a processor circuit that executes instructions stored in a memory circuit, client device, remote server, or database, which are connected in a way that allows communication over a network (e.g., processor 205, memory 220, participant 110, participant 130, database 152, and network 150).

[0103] Figure 5 shows an exemplary block of process 500, but in some implementations, process 500 may include additional blocks, fewer blocks, different blocks, or blocks in a different arrangement than those depicted in Figure 5.

[0104] Hardware Overview Figure 6 is a block diagram illustrating an exemplary computer system 600 in which an embodiment of the technology in question may be implemented. In a particular embodiment, the computer system 600 may be implemented using hardware, or a combination of software and hardware, either as a dedicated server, integrated into another entity, or distributed across multiple entities.

[0105] The computer system 600 (e.g., a server and / or participant) includes a bus 608 or other communication mechanism for transmitting information and a processor 602 coupled to the bus 608 for processing information. For example, the computer system 600 may be implemented by one or more processors 602. Each of the one or more processors 602 may be a general-purpose microprocessor, microcontroller, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), programmable logic device (PLD), controller, state machine, gated logic, discrete hardware component, or any other suitable entity capable of performing computation or other operations on information.

[0106] In addition to the hardware, the computer system 600 may include code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or one or more combinations thereof, stored in the accompanying memory 604, such as code that creates an execution environment for the computer program in question, for example, random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable PROM (EPROM), registers, hard disks, removable disks, CD-ROMs, DVDs, or any other suitable storage devices coupled to the bus 608 for storing information and instructions executed by the processor 602. The processor 602 and memory 604 may be supplemented by or incorporated into special-purpose logic circuits.

[0107] Instructions may be stored in memory 604 and implemented in one or more modules of computer program instructions, i.e., one or more computer program products, i.e., one or more modules of computer program instructions, which are encoded on a computer-readable medium for execution by the computer system 600 or for controlling the operation of the computer system 600, in accordance with any method well known to those skilled in the art, including but not limited to computer languages ​​such as data-oriented languages ​​(e.g., SQL, dBase), system languages ​​(e.g., C, Objective-C, C++, Assembly), architecture languages ​​(e.g., Java, .NET), and application languages ​​(e.g., PHP, Ruby, Perl, Python). Instructions can also be implemented in computer languages ​​such as array languages, aspect-oriented languages, assembly languages, authoring languages, command-line interface languages, compiled languages, concurrent languages, curly brace languages, data flow languages, data structure languages, declarative languages, esoteric languages, extended languages, fourth-generation languages, functional languages, interactive mode languages, interpreted languages, iterative languages, list-based languages, little languages, logic-based languages, machine languages, macro languages, metaprogramming languages, multi-paradigm languages, numerical analysis, non-English-based languages, object-oriented class-based languages, object-oriented prototype-based languages, offside rule languages, procedural languages, reflexive languages, rule-based languages, scripting languages, stack-based languages, synchronous languages, syntactic processing languages, visual languages, Worth languages, and XML-based languages. Memory 604 can also be used to store temporary variables or other intermediate information during the execution of instructions performed by processor 602.

[0108] Computer programs as considered herein do not necessarily correspond to files in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., a file storing one or more modules, subprograms, or portions of code). Computer programs may be deployed to run on one or more computers located at one site or distributed across multiple sites and interconnected by a communication network. The processes and logical flows described herein may be implemented by one or more programmable processors that execute one or more computer programs to perform their functions by manipulating input data and producing outputs.

[0109] The computer system 600 further includes a data storage device 606, such as a magnetic disk or optical disk, coupled to a bus 608 for storing information and instructions. The computer system 600 may be coupled to various devices via an input / output module 610. The input / output module 610 can be any input / output module. An exemplary input / output module 610 includes a data port, such as a USB port. The input / output module 610 is configured to connect to a communication module 612. An exemplary communication module 612 includes a networking interface card, such as an Ethernet card and a modem. In certain embodiments, the input / output module 610 is configured to connect to multiple devices, such as an input device 614 and / or an output device 616. An exemplary input device 614 includes a keyboard and a pointing device, such as a mouse or trackball, through which a user can provide input to the computer system 600. Other types of input devices can also be used to provide user interaction, such as a tactile input device, a visual input device, a voice input device, or a brain-computer interface device. For example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and user input may be received in any form, including acoustic, voice, tactile, or electroencephalogram (EEG) input. An exemplary output device 616 includes a display device such as an LCD (liquid crystal display) monitor for displaying information to the user.

[0110] According to one aspect of the present disclosure, the system described above can be implemented using a computer system 600 in response to a processor 602 executing one or more sequences of one or more instructions contained in memory 604. Such instructions may be read into memory 604 from another machine-readable medium, such as a data storage device 606. Upon executing the sequence of instructions contained in main memory 604, the processor 602 performs the process steps described herein. One or more processors in a multiprocessing configuration may also be used to execute the sequence of instructions contained in memory 604. In alternative embodiments, hard-wired circuits may be used instead of or in combination with software instructions to implement various aspects of the present disclosure. Thus, aspects of the present disclosure are not limited to any specific combination of hardware circuits and software.

[0111] Various embodiments of the subject matter described herein can be implemented in a computing system that includes, for example, backend components such as data servers, middleware components such as application servers, or frontend components such as client computers having a graphical user interface or a web browser, and a user can interact with the implementation of the subject matter described herein through the graphical user interface or a web browser, or with any combination of one or more such backend, middleware, or frontend components. The components of the system can be interconnected by any form or medium of digital data communication, such as a communication network. The communication network may include, for example, one or more of LANs, WANs, and the Internet. Furthermore, the communication network may include, but is not limited to, one or more of the following network topologies, such as bus networks, star networks, ring networks, mesh networks, starbus networks, tree or hierarchical networks. The communication module may be, for example, a modem or an Ethernet card.

[0112] The computer system 600 may include a client and a server. The client and server are generally remote from each other and typically interact through a communication network. The client-server relationship is established by computer programs running on each computer that have a client-server relationship with each other. The computer system 600 may be, for example, a desktop computer, a laptop computer, or a tablet computer, for example. The computer system 600 may also be embedded in another device, for example, a mobile phone, a PDA, a mobile audio player, a Global Positioning System (GPS) receiver, a video game console, and / or a television set-top box, for example.

[0113] The terms “machine-readable storage medium” or “computer-readable medium” as used herein refer to any medium or medium involved in providing instructions to processor 602 for execution. Such mediums can take many forms, including but are not limited to non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks such as data storage device 606. Volatile media include dynamic memory such as memory 604. Transmission media include coaxial cables, copper wires, and optical fibers, including wires that constitute bus 608. Common forms of machine-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tapes, any other magnetic media, CD-ROMs, DVDs, any other optical media, punch cards, paper tapes, any other physical media having a pattern of holes, RAM, PROMs, EPROMs, FLASH EPROMs, any other memory chips or cartridges, or any other media that a computer can read. A machine-readable memory medium can be a machine-readable memory device, a machine-readable memory substrate, a memory device, a composition of a substance that affects machine-readable propagated signals, or a combination of one or more of these.

[0114] The techniques described herein may be implemented as a method performed by a physical computing device, as one or more non-temporary computer-readable storage media that store instructions causing the method to be performed when executed by a computing device, or as a physical computing device specially configured with a combination of hardware and software that causes the method to be performed.

[0115] The phrase “at least one of” preceding a set of items, accompanied by the terms “and” or “or” to separate any of the items, when used herein, qualifies the list as a whole, rather than each member of the list (i.e., each item). The phrase “at least one of” does not require the selection of at least one item; rather, the phrase allows for meanings including at least one of any one of the items, and / or at least one of any combination of items, and / or at least one of each of the items. For example, the phrases “at least one of A, B, or C” or “at least one of A, B, or C” refer to A only, B only, or C only, any combination of A, B, and C, and / or at least one of each of A, B, and C, respectively.

[0116] To the extent that terms such as “include” and “have” are used in the description or claims, such terms are intended to be inclusive in the same manner as the term “comprise” is interpreted as “comprise” when used as a transitional term in a claim. The term “exemplary” is used herein to mean “serving as an example, case, or illustration.” No embodiment described herein as “exemplary” should necessarily be construed as being preferable or advantageous to any other embodiment.

[0117] References to elements in the singular form are intended to mean "one or more" rather than "one and only one" unless specifically stated otherwise. All structural and functional equivalents to the elements of the various configurations described throughout this disclosure, whether known to those skilled in the art or later known, are expressly incorporated herein by reference and are intended to be encompassed by the subject art. Furthermore, nothing disclosed herein is intended to be for the public only, whether such disclosure is expressly enumerated in the above specification.

[0118] While this specification contains many details, these should not be interpreted as limitations on the scope of claims, but rather as descriptions of specific implementations of the subject matter. Certain features described herein in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may be implemented separately in multiple embodiments or in any preferred partial combination. Furthermore, features described above as acting in a particular combination and initially claimed as such, may, in some cases, be removed from the claimed combination, and the claimed combination may be subject to a partial combination or a variation of a partial combination.

[0119] While the subject matter of this specification has been described in terms of specific embodiments, other embodiments are implementable and fall within the scope of the following claims. For example, although the operations are depicted in a specific order in the drawings, this should not be understood as meaning that such operations must be performed in a specific order or sequence shown, or that all illustrated operations must be performed in order to achieve a desired result. The actions enumerated in the claims can be performed in a different order and still achieve the desired result. As an example, the processes depicted in the accompanying drawings do not necessarily require a specific order or sequence shown to achieve a desired result. In certain circumstances, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the embodiments described above should not be understood as meaning that such separation is necessary in all embodiments, and the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products. Other variations fall within the scope of the following claims.

[0120] In this specification, it should be understood that the original applicant will determine which technologies to use and / or commercialize, and what is best for the technology, its players, and users, based on the usefulness and relevance of the technologies in the ever-evolving field. Accordingly, the systems and methods described herein may not yet be used by the original applicant, and / or may not be used, and / or commercialized in the future. It should also be understood that the implementation and use of the systems and methods described herein will be carried out by the original applicant, if any, in accordance with its privacy policy. These policies are intended to respect and prioritize the privacy of players and are intended to meet or exceed the governmental and legal requirements of the respective jurisdictions. To the extent that such implementation or use of these systems and methods enables or requires the processing of users' personal information, such processing will be carried out in accordance with (i) the privacy policy outlined herein, (ii) an effective legal mechanism including, but not limited to, providing appropriate notice, or, where necessary, obtaining the consent of the respective user, and (iii) the privacy settings or preferences of the player or user. Furthermore, the original applicant should understand that, if implemented or used by other entities, the systems and methods described herein are intended to comply with privacy policies and practices consistent with their purpose of respecting the privacy of players and users.

Claims

1. A computer implementation method for cross-chain communication in a blockchain platform, wherein the method is Accepting a first transaction in the first blockchain, which includes a message and a message payload, In the first blockchain, the message is verified by signing it using the signing keys of one or more validators in the first set of validators of the first blockchain. A collective signature is generated based on the signing keys of one or more validators in the first set of validators. Submitting a second transaction on a second blockchain, the second transaction including the message and the aggregated signature, A computer implementation method comprising verifying the second transaction in the second blockchain based on a shared registry.

2. The computer implementation method according to claim 1, further comprising generating the message in the first blockchain, wherein the message payload identifies the second blockchain as the destination of the message.

3. The computer implementation method according to claim 1, wherein one or more validators in the first set of validators satisfy at least the threshold stake ratio of the first set of validators.

4. The computer implementation method according to claim 1, wherein the signing key of the first set of validators is stored in a distributed ledger known to both the first blockchain and the second blockchain.

5. Querying the aforementioned first set of validators, The computer implementation method according to claim 1, further comprising identifying one or more validators in the first set of validators that signed the message from the first transaction based on the query.

6. The computer implementation method according to claim 1, wherein the aggregated signature is of the same length as the signatures generated using any individual signing keys.

7. Generating aggregate signatures The computer implementation method according to claim 1, further comprising generating a bit vector in the canonical order of the first set of validators, wherein an element corresponding to the index of a validator that signed the message is set to 1, and an element corresponding to the index of a validator that did not sign the message is set to 0.

8. In the second blockchain, based on the aggregate signature, one or more validators in the set of first validators are identified, The computer implementation method according to claim 1, further comprising verifying that the stake threshold ratio of the first set of validators is included in the aggregate signature by referring to the shared registry.

9. Based on the acceptance of the first transaction by the first blockchain, an event is issued, Scanning events issued on the blockchain platform by entities of the blockchain platform, wherein the events include the message to be relayed to a corresponding destination. The computer implementation method according to claim 1, further comprising selecting the first transaction based at least on the message payload by the entity.

10. The computer implementation method according to claim 9, wherein the entity is incentivized to relay messages when using the fees paid in the first transaction on the first blockchain.

11. The computer implementation method according to claim 1, further comprising delivering the message to a destination, wherein the message is delivered to the destination only once, and the destination includes the second blockchain or an application on the second blockchain.

12. The computer implementation method according to claim 1, wherein the message on the first blockchain specifies the fee required to successfully deliver the message to a corresponding destination on the second blockchain.

13. A system for cross-chain communication on a blockchain platform, One or more processors, A memory comprising, wherein the memory includes instructions stored therein, and when an instruction is executed by one or more processors, the one or more processors, Accepting a first transaction in the first blockchain, which includes a message and a message payload, In the first blockchain, the message is verified by signing it using the signing keys of one or more validators in the first set of validators of the first blockchain. A collective signature is generated based on the signing keys of one or more validators in the first set of validators. Submitting a second transaction on a second blockchain, the second transaction including the message and the aggregated signature, A system that performs verification of the second transaction in the second blockchain based on a shared registry.

14. The system according to claim 13, wherein when the instruction is executed by one or more processors, the one or more processors cause the first blockchain to generate the message, and the message payload identifies the second blockchain as the destination of the message.

15. The system according to claim 13, wherein one or more validators in the first set of validators satisfy at least the threshold stake ratio of the first set of validators.

16. The system according to claim 13, wherein the signing keys of the first set of validators are stored in a distributed ledger known to both the first blockchain and the second blockchain.

17. When the instruction is executed by one or more processors, the one or more processors: Querying the aforementioned first set of validators, The system according to claim 13, wherein, based on the query, it is made to identify one or more validators in the first set of validators that signed the message from the first transaction.

18. The system according to claim 13, wherein the aggregated signature is of the same length as the signatures generated using any individual signing keys.

19. When the instruction is executed by one or more processors, the one or more processors: The system according to claim 13, wherein a bit vector is generated in the normal order of the first set of validators, and the element corresponding to the index of the validator that signed the message is set to 1, and the element corresponding to the index of the validator that did not sign the message is set to 0.

20. When the instruction is executed by one or more processors, the one or more processors: In the second blockchain, based on the aggregate signature, one or more validators in the set of first validators are identified, The system according to claim 13, which performs the following: verifying that the stake threshold ratio of the first set of validators is included in the aggregate signature by referring to the shared registry.

21. The system further includes a stored sequence of instructions, and when the sequence of instructions is executed by one or more processors, the system instructs the one or more processors to: Based on the acceptance of the first transaction by the first blockchain, an event is issued, Scanning events issued on the blockchain platform by entities of the blockchain platform, wherein the events include the message to be relayed to a corresponding destination. The system according to claim 13, wherein the entity is instructed to select the first transaction based at least on the message payload, and the entity is incentivized to relay the message on the first blockchain using the fees paid in the first transaction.

22. A non-temporary computer-readable storage medium, wherein the non-temporary computer-readable storage medium includes instructions stored therein, and when the instructions are executed by one or more processors, the one or more processors are caused to perform an operation for cross-chain communication in a blockchain platform, and the operation is Accepting a first transaction in the first blockchain, which includes a message and a message payload, In the first blockchain, the message is verified by signing it using the signing keys of one or more validators in the first set of validators of the first blockchain. A collective signature is generated based on the signing keys of one or more validators in the first set of validators. Submitting a second transaction on a second blockchain, the second transaction comprising the message and the aggregate signature based on the message payload, In the aforementioned second blockchain, accepting the aforementioned second transaction and A non-temporary computer-readable storage medium, comprising verifying the second transaction based on the aggregated signature and shared registry.

Images