WO2020258850A1 - 一种跨链发送可认证消息的方法和装置 - Google Patents

一种跨链发送可认证消息的方法和装置 Download PDF

Info

Publication number
WO2020258850A1
WO2020258850A1 PCT/CN2020/071574 CN2020071574W WO2020258850A1 WO 2020258850 A1 WO2020258850 A1 WO 2020258850A1 CN 2020071574 W CN2020071574 W CN 2020071574W WO 2020258850 A1 WO2020258850 A1 WO 2020258850A1
Authority
WO
WIPO (PCT)
Prior art keywords
blockchain
account
data
message
field
Prior art date
Application number
PCT/CN2020/071574
Other languages
English (en)
French (fr)
Inventor
邱鸿霖
Original Assignee
创新先进技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 创新先进技术有限公司 filed Critical 创新先进技术有限公司
Priority to US16/786,437 priority Critical patent/US11336465B2/en
Publication of WO2020258850A1 publication Critical patent/WO2020258850A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1059—Inter-group management mechanisms, e.g. splitting, merging or interconnection of groups
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the embodiments of the present specification relate to the field of blockchain technology, and more specifically, to a method and device for sending verifiable messages across chains.
  • Blockchain technology also known as distributed ledger technology, is a decentralized distributed database technology, which is characterized by decentralization, openness and transparency, immutability, and trustworthiness. Each piece of data in the blockchain will be broadcast to the blockchain nodes of the entire network, and each full node has a full amount of consistent data.
  • many different types of chains have emerged, which are used in the fields of finance, health care, supply chain, asset management, and traceability.
  • most of the applications on the chain encrypted currency or smart contracts
  • cannot cross the boundaries of the current chain and cannot cooperate with other chains to realize the circulation of value, which limits the space for blockchain to play. How to make different types of chains cooperate to realize value circulation has become the direction of exploration.
  • a variety of cross-chain technologies have emerged. However, each cross-chain technology has its own unique design and different scenarios. For cross-chain under different scenarios, one chain may need to access multiple cross-chain platforms.
  • one aspect of this specification provides a method for sending an authenticated message across chains.
  • the cross-chain sending is sending from a first account of a first blockchain to other blockchains.
  • the first block is connected to the relay end, the relay end is also connected to at least one other blockchain, the at least one other blockchain includes a second blockchain, and the method is executed by the first blockchain ,include:
  • the first data includes a verifiable message, the verifiable message satisfies a predetermined protocol stack, and the predetermined protocol stack Including the first to third layer protocols from the outside to the inside, where the first layer protocol includes the sending block chain identification field and the second layer protocol, the second layer protocol includes the sending account field and the third layer protocol, the third layer protocol It includes a receiving blockchain identification field, a receiving account field, and a message content field.
  • the sending blockchain identification, sending account, receiving blockchain identification, and receiving account fields correspond to the following field values: first blockchain identification, The first account, the second blockchain identifier, and the second account; and
  • the first data and the first location information are provided to the relay terminal for providing the verifiable message to the second account in the second blockchain, wherein the first A location information indicates the location of the first data in the first blockchain.
  • depositing the consensus first data into the first blockchain through the first account includes depositing the first data into the first blockchain by invoking the first smart contract from the first account In the first data, the first account passes at least the following parameters to the first smart contract when invoking the first smart contract: a second blockchain identifier, a second account, and message content.
  • the first data is marked with a predetermined mark.
  • the first data is a receipt
  • the receipt includes a log generated after the execution of the first smart contract, and the data field of the log is the attestable message.
  • the log is marked with a predetermined subject, and the predetermined mark is the predetermined subject.
  • the predetermined mark is an account identification of the first smart contract.
  • the first layer protocol further includes a protocol version number field and a reserved field.
  • the second layer protocol further includes a type field, which is used to indicate the usage scenario type of the authenticated message.
  • the type is any of the following types: message type, remote procedure call type, publish/subscribe type.
  • the third layer protocol further includes a sequence number field, which is used to indicate the current sending sequence number when the first account sends an authenticateable message to the second account multiple times.
  • the first account is a contract account of the second smart contract.
  • Another aspect of this specification provides a method for cross-chain transfer of certifiable messages.
  • the method is executed by a relay end connected to at least two blockchains, and the at least two blockchains include The first block chain and the second block chain, wherein the first block chain pre-stores consensus first data, wherein the first data includes a verifiable message, and the verifiable message satisfies A predetermined protocol stack, the predetermined protocol stack includes the first to third layer protocols from the outside to the inside, wherein the first layer protocol includes a sending block chain identification field and a second layer protocol, and the second layer protocol includes a sending account field and The third layer protocol, the third layer protocol includes receiving block chain identification field, receiving account field and message content field.
  • sending block chain identification, sending account, receiving block chain identification, and receiving account fields correspond to the following fields respectively Value: the first blockchain identifier, the first account, the second blockchain identifier, and the second account.
  • the method is executed by the relay terminal and includes:
  • the first data and the first location information are sent to the second blockchain.
  • the first data is marked with a predetermined mark
  • obtaining the first data and the first location information from the first blockchain includes: The blockchain obtains the first data and the first location information.
  • Another aspect of this specification provides a method for receiving verifiable messages across chains.
  • the cross-chain reception is received from other blockchains by a second account of a second blockchain.
  • the second blockchain and relay Terminal connection the second block chain synchronizes at least one second data related to at least one other block chain through the relay terminal, wherein the at least one other block chain includes the first zone Block chain, the method is executed by the second block chain, including:
  • the first data and the first location information are received from the relay terminal, wherein the first data includes an certifiable message, the certifiable message satisfies a predetermined protocol stack, and the predetermined protocol stack includes the first data from the outside to the inside.
  • the first to third layer protocols where the first layer protocol includes the sending block chain identification field and the second layer protocol, the second layer protocol includes the sending account field and the third layer protocol, and the third layer protocol includes the receiving block chain identification field Field, receiving account field, and message content field, where the sending blockchain ID, sending account, receiving blockchain ID, and receiving account fields correspond to the following field values: first blockchain ID, first account, second A blockchain identifier, a second account, and the first location information indicates the location of the first data in the first blockchain;
  • the verifiable message is provided to the second account.
  • the first data is the first receipt in the first block of the first blockchain
  • the first location information includes the block number of the first block and the first receipt in the first block.
  • the receipt number in the block, the second data related to the first block chain is the block header of each block in the first block chain, wherein, based on the first data, and the first block
  • the second data related to the block chain and the first location information, verifying the verifiable message includes, based on the first receipt, the block header of each block, and the first block in the first block.
  • the Merkel tree path associated with the receipt is verified by a simple payment verification method: the first receipt comes from the first block in the first blockchain, and the Merkel tree path is based on the first Location information acquisition.
  • verifying the verifiable message may further include verifying that the first account is the account that sent the verifiable message based on the sending field of the first log.
  • the second account is a contract account of a third smart contract
  • providing the verifiable message to the second account includes invoking the third smart contract by using the verifiable message as an incoming parameter , To provide the verifiable message to the second account.
  • Another aspect of this specification provides a method for cross-chain transfer of certifiable messages.
  • the method is executed by a relay end connected to at least two blockchains, and the at least two blockchains include The first block chain and the second block chain, wherein the first block chain pre-stores consensus first data, wherein the first data includes a verifiable message, and the verifiable message satisfies A predetermined protocol stack, the predetermined protocol stack includes the first to third layer protocols from the outside to the inside, wherein the first layer protocol includes a sending block chain identification field and a second layer protocol, and the second layer protocol includes a sending account field and The third layer protocol, the third layer protocol includes receiving block chain identification field, receiving account field and message content field.
  • sending block chain identification, sending account, receiving block chain identification, and receiving account fields correspond to the following fields respectively Value: the first block chain identifier, the first account, the second block chain identifier, the second account, the relay terminal synchronizes each second data related to each block chain, and the method includes:
  • the verifiable message and its digital signature are sent to the second blockchain.
  • Another aspect of this specification provides a method for receiving verifiable messages across chains.
  • the cross-chain reception is received from other blockchains by a second account of a second blockchain.
  • the second blockchain and relay The relay end is also connected to at least one other block chain, the at least one other block chain includes a first block chain, and the second block chain prestores the relay end’s
  • the public key, the method is executed by the second blockchain includes:
  • the verifiable message satisfies a predetermined protocol stack
  • the predetermined protocol stack includes the first to the inner
  • the third layer protocol where the first layer protocol includes the sending block chain identification field and the second layer protocol, the second layer protocol includes the sending account field and the third layer protocol, and the third layer protocol includes the receiving block chain identification field,
  • the receiving account field and the message content field where the sending blockchain ID, sending account, receiving blockchain ID, and receiving account fields correspond to the following field values: first blockchain ID, first account, second block Chain ID, second account;
  • the verifiable message is provided to the second account.
  • Another aspect of this specification provides a device for sending an authenticated message across chains.
  • the cross-chain sending is sending from the first account of the first blockchain to other blockchains.
  • the first blockchain and the relay The relay terminal is also connected to at least one other block chain, the at least one other block chain includes a second block chain, and the device deployed on the first block chain includes:
  • the depositing unit is configured to deposit consensus first data into the first blockchain through the first account, wherein the first data includes a verifiable message, and the verifiable message satisfies a predetermined protocol Stack, the predetermined protocol stack includes first to third layer protocols from the outside to the inside, wherein the first layer protocol includes the sending block chain identification field and the second layer protocol, and the second layer protocol includes the sending account field and the third layer. Layer protocol, the third layer protocol includes receiving block chain identification field, receiving account field and message content field. Among them, sending block chain identification, sending account, receiving block chain identification, and receiving account fields respectively correspond to the following field values: The first blockchain identifier, the first account, the second blockchain identifier, and the second account; and
  • a providing unit configured to provide the first data and first location information to the relay terminal, so as to provide the verifiable message to the second account in the second blockchain , Wherein the first location information indicates the location of the first data in the first blockchain.
  • the depositing unit is further configured to deposit the first data into the first blockchain by invoking a first smart contract by the first account, wherein the first account is in When the first smart contract is called, at least the following parameters are passed to the first smart contract: the second blockchain identifier, the second account, and the message content.
  • the device for transferring certifiable messages across chains.
  • the device is deployed at a relay end, and the relay end is connected to at least two blockchains.
  • the at least two blockchains include The first block chain and the second block chain, wherein the first block chain pre-stores consensus first data, wherein the first data includes a verifiable message, and the verifiable message satisfies
  • a predetermined protocol stack includes the first to third layer protocols from the outside to the inside, wherein the first layer protocol includes a sending block chain identification field and a second layer protocol, and the second layer protocol includes a sending account field and The third layer protocol, the third layer protocol includes receiving block chain identification field, receiving account field and message content field.
  • sending block chain identification, sending account, receiving block chain identification, and receiving account fields correspond to the following fields respectively Value: the first block chain identifier, the first account, the second block chain identifier, the second account, the device includes:
  • the searching unit is configured to obtain the first data and first location information from the first blockchain, where the first location information indicates the location of the first data in the first blockchain;
  • the sending unit is configured to send the first data and the first location information to the second blockchain based on the second blockchain identifier in the attestable message.
  • the first data is marked with a predetermined mark
  • the acquiring unit is further configured to acquire the first data and the first location from the first blockchain based on the predetermined mark information.
  • Another aspect of this specification provides an apparatus for receiving verifiable messages across chains.
  • the cross-chain reception is received from other blockchains by a second account of a second blockchain.
  • Terminal connection the second block chain synchronizes at least one second data related to at least one other block chain through the relay terminal, wherein the at least one other block chain includes the first zone
  • the block chain, where the device is deployed on the second block chain includes:
  • the receiving unit is configured to receive first data and first location information from the relay terminal, wherein the first data includes an certifiable message, the certifiable message satisfies a predetermined protocol stack, and the predetermined protocol stack Including the first to third layer protocols from the outside to the inside, where the first layer protocol includes the sending block chain identification field and the second layer protocol, the second layer protocol includes the sending account field and the third layer protocol, the third layer protocol It includes a receiving blockchain identification field, a receiving account field, and a message content field.
  • the sending blockchain identification, sending account, receiving blockchain identification, and receiving account fields correspond to the following field values: first blockchain identification, A first account, a second blockchain identifier, and a second account, where the first location information indicates the location of the first data in the first blockchain;
  • An acquiring unit configured to acquire second data related to the first blockchain based on the first blockchain identifier in the verifiable message
  • a verification unit configured to verify the attestable message based on the first data, second data related to the first blockchain, and the first location information;
  • the providing unit is configured to, after the verification is passed, provide the verifiable message to the second account based on the second account in the verifiable message.
  • the first data is the first receipt in the first block of the first blockchain
  • the first location information includes the block number of the first block and the first receipt in the first block.
  • the receipt number in the block, the second data related to the first block chain is the block header of each block in the first block chain
  • the verification unit is further configured to be based on the first block chain.
  • the receipt, the block header of each block, and the Merkel tree path in the first block associated with the first receipt are verified by a simple payment verification method: the first receipt comes from the first blockchain The first block of, wherein the Merkel tree path is obtained based on the first location information.
  • the verifiable message is located in the first log in the first receipt, and the verification unit is further configured to, based on the sending field of the first log, verify that the first account is sending The account of the verifiable message.
  • the second account is a contract account of a third smart contract
  • the providing unit is further configured to provide the second account by invoking the third smart contract with the verifiable message as an incoming parameter The certifiable message.
  • the device for transferring certifiable messages across chains.
  • the device is deployed at a relay end, and the relay end is connected to at least two blockchains.
  • the at least two blockchains include The first block chain and the second block chain, wherein the first block chain pre-stores consensus first data, wherein the first data includes a verifiable message, and the verifiable message satisfies
  • a predetermined protocol stack includes the first to third layer protocols from the outside to the inside, wherein the first layer protocol includes a sending block chain identification field and a second layer protocol, and the second layer protocol includes a sending account field and The third layer protocol, the third layer protocol includes receiving block chain identification field, receiving account field and message content field.
  • sending block chain identification, sending account, receiving block chain identification, and receiving account fields correspond to the following fields respectively Value: the first block chain identifier, the first account, the second block chain identifier, the second account, the relay terminal synchronizes each second data related to each block chain, and the device includes:
  • the searching unit is configured to obtain the first data and first location information from the first blockchain, where the first location information indicates the location of the first data in the first blockchain;
  • An acquiring unit configured to acquire second data related to the first blockchain based on the first blockchain identifier in the verifiable message
  • a verification unit configured to verify the verifiable message based on the first data, second data related to the first blockchain, and the first location information;
  • the signature unit is configured to digitally sign the verifiable message when the verification is passed.
  • the sending unit is configured to send the verifiable message and its digital signature to the second blockchain based on the second blockchain identifier in the verifiable message.
  • Another aspect of this specification provides an apparatus for receiving verifiable messages across chains.
  • the cross-chain reception is received from other blockchains by a second account of a second blockchain.
  • the relay end is also connected to at least one other block chain, the at least one other block chain includes a first block chain, and the second block chain prestores the relay end’s
  • the public key, the device is deployed on the second blockchain includes:
  • the receiving unit is configured to receive a verifiable message from the relay terminal and the digital signature of the relay terminal on the verifiable message, the verifiable message satisfies a predetermined protocol stack, and the predetermined protocol stack includes The first to third layer protocols from outside to inward, where the first layer protocol includes the sending block chain identification field and the second layer protocol, the second layer protocol includes the sending account field and the third layer protocol, and the third layer protocol includes the receiving Blockchain identification field, receiving account field, and message content field, where the sending blockchain identification, sending account, receiving blockchain identification, and receiving account fields correspond to the following field values: first blockchain identification, first Account, second blockchain identification, second account;
  • a verification unit configured to verify the digital signature using the public key of the relay terminal
  • the providing unit is configured to, after the verification is passed, provide the verifiable message to the second account based on the second account in the verifiable message.
  • Another aspect of this specification provides a computer-readable storage medium on which a computer program is stored.
  • the computer program is executed in a computer, the computer is caused to execute any of the above methods.
  • Another aspect of this specification provides a computing device including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, any one of the above methods is implemented.
  • the blockchain interoperability model is abstracted, and a verifiable message is designed so that the message sent by the blockchain can be verified by other chains: which chain the message comes from and which chain on the chain Issued by the identity entity (account/contract).
  • identity entity an entity that issues the message sent by the blockchain.
  • contract cross-chain application programming is allowed, so that developers can more easily develop various cross-chain services and applications.
  • Figure 1 shows a schematic diagram of a cross-chain system according to an embodiment of this specification
  • Figure 2 shows a flow chart of a method for sending an authenticated message across chains according to an embodiment of this specification
  • Figure 3 shows a schematic diagram of a log generated after executing the first smart contract
  • Figure 4 shows a schematic diagram of a predetermined protocol stack according to an embodiment of the present specification
  • Figure 5 shows a schematic form of a certifiable message
  • Fig. 6 shows a schematic diagram of a protocol stack with high applicability according to an embodiment of the present specification
  • Figure 7 shows a flow chart of a method for cross-chain transfer of certifiable messages according to an embodiment of this specification
  • Fig. 8 shows a flow chart of a method for receiving certifiable messages across chains according to an embodiment of this specification
  • Figure 9 shows a flow chart of a method for cross-chain transfer of certifiable messages according to an embodiment of this specification
  • Fig. 10 shows a flow chart of a method for receiving certifiable messages across chains according to an embodiment of this specification
  • FIG. 11 shows an apparatus 1100 for sending an authenticated message across chains according to an embodiment of the present specification
  • FIG. 12 shows an apparatus 1200 for transferring certifiable messages across chains according to an embodiment of the present specification
  • FIG. 13 shows a cross-chain device 1300 for receiving certifiable messages according to an embodiment of this specification
  • FIG. 14 shows an apparatus 1400 for transferring certifiable messages across chains according to an embodiment of this specification
  • FIG. 15 shows an apparatus 1500 for receiving an authenticateable message across chains according to an embodiment of the present specification.
  • Fig. 1 shows a schematic diagram of a cross-chain system according to an embodiment of the present specification.
  • the cross-chain system includes a first block chain 11, a relay terminal 12 and a second block chain 13.
  • the first blockchain 11 includes account A, for example, and the second blockchain 13 includes account B, for example.
  • the account A and account B may be user accounts or contract accounts.
  • the account A in the first blockchain wants to send information to the account B in the second blockchain, it can be sent in the form of an authenticated message (AM message).
  • the verifiable message is included in the consensus first data (data 1) stored in the blockchain in Account A.
  • the second block chain 13 may include, for example, multiple simple payment verification (spv) nodes, which locally obtain the second data (data 2) in the first block chain 11 in advance, and the data 2 is used to verify the data 1.
  • the spv node can obtain the first data (data 1) and its location information (location 1) through the relay end 12 between the first block chain 11 and the second block chain 13, and use data 2 to Data 1 is verified, and the AM message in data 1 is provided to account B after the verification is passed. Therefore, account B can perform service processing based on the AM message.
  • the relay terminal after the relay terminal obtains data 1, it can verify and digitally sign data 1 according to the pre-obtained data 2 in the first block chain, and send it to the second block chain.
  • the second block chain can be based on The public key of the relay chain verifies the digital signature, thereby verifying the data 1.
  • Figure 2 shows a flow chart of a method for sending an authenticated message across chains according to an embodiment of this specification.
  • the cross-chain sending is sending from a first account of a first blockchain to other blockchains.
  • the block chain is connected to the relay end, and the relay end is also connected to at least one other block chain.
  • the at least one other block chain includes a second block chain.
  • the method is controlled by the first block chain.
  • Chain execution including:
  • Step S202 Depositing consensus first data into the first blockchain through the first account, where the first data includes a verifiable message, and the verifiable message satisfies a predetermined protocol stack.
  • the predetermined protocol stack includes the first to third layer protocols from the outside to the inside.
  • the first layer protocol includes the sending block chain identification field and the second layer protocol
  • the second layer protocol includes the sending account field and the third layer protocol.
  • the three-layer protocol includes a receiving block chain identification field, a receiving account field, and a message content field.
  • the sending block chain identification, sending account, receiving block chain identification, and receiving account fields correspond to the following field values: Chain ID, first account, second blockchain ID, second account; and
  • Step S204 Provide the first data and the first location information to the relay terminal, so as to provide the verifiable message to the second account in the second blockchain, where The first location information indicates the location of the first data in the first blockchain.
  • the first block chain and the second block chain can be any block chain, such as Bitcoin chain, Ethereum chain, etc., which transmit information through verifiable messages in a unified format. Therefore, The embodiments of this specification have no particular limitations on the type and specific application scenarios of the blockchain.
  • the relay end is a middleware connected between the first block chain and the second block chain.
  • the relay end can have multiple forms.
  • the relay end can be both the first block chain and the second block chain.
  • Nodes in the second blockchain that is, the relay end has accounts in both the first blockchain and the second blockchain; or the relay end is connected to the first blockchain and the second blockchain
  • the relay device that is connected to both is not responsible for verifying data, but is only used to relay data; or the relay end is a trusted node, which verifies the data after receiving the data from the first blockchain, and after the verification is passed
  • the data is then sent to the second blockchain; or the relay end can also be a verification blockchain, which sends to the second blockchain after consensus verification of the data received from the first blockchain.
  • the consensus first data is stored in the first blockchain through the first account, wherein the first data includes a verifiable message, and the verifiable message satisfies a predetermined protocol stack.
  • the predetermined protocol stack includes first to third layer protocols from the outside to the inside, wherein the first layer protocol includes a sending block chain identification field and a second layer protocol, and the second layer protocol includes a sending account field and a third layer protocol,
  • the third layer protocol includes a receiving block chain identification field, a receiving account field, and a message content field.
  • the sending block chain identification, sending account, receiving block chain identification, and receiving account fields correspond to the following field values: Block chain identification, first account, second block chain identification, second account.
  • the first account may be a user account, or may also be a contract account.
  • the first data can be any data in the blockchain, such as transactions, receipts, state tree status, smart contract memory, relational databases, etc., and these data are stored in the blockchain through the consensus of each node. Therefore, it is consistent at each node and verifiable.
  • consensus data can be stored in the blockchain by sending transactions in the blockchain, and the process will not be described in detail here.
  • depositing the consensus first data into the first blockchain through the first account includes depositing the first data into the first blockchain by invoking the first smart contract from the first account
  • the first account passes at least the following parameters to the first smart contract when invoking the first smart contract: a second blockchain identifier, a second account, and message content.
  • the first account is a contract account of the second smart contract, which, for example, transfers parameters to the third smart contract in the second blockchain by invoking the first smart contract, so as to implement cross-chain calling The purpose of the third smart contract.
  • the first smart contract is a specific smart contract used to store the first data in the first blockchain to transfer verifiable messages across the chain.
  • the contract for sending information ie, the second smart contract.
  • the contract for sending information ie, the second smart contract.
  • the receiving chain identifier that is, the second blockchain identifier
  • the receiving account identifier that is, the second account
  • the message content need to be passed in.
  • the incoming parameters of the save function are the incoming parameters of the first smart contract, that is, the second blockchain identifier, the second account
  • the deposit function obtains its account (ie, the first account) from the second smart contract that made the call, and transfers the first account, the preset chain identification of the first blockchain, and when it is called.
  • the input parameters that is, the second blockchain identifier, the second account, and the message content
  • a predetermined format that is, a predetermined protocol stack
  • the output function result is stored in the corresponding log.
  • the log is included in the transaction receipt of the transaction corresponding to the call, and the transaction receipt is stored in the block in the first blockchain through the node consensus verification in the first blockchain. That is, in this embodiment, the first data is the receipt in the blockchain, and the specific log in the receipt includes the certifiable message.
  • the receipt can be found by using the contract identifier of the first smart contract as a predetermined mark.
  • a specific subject (name) is also set as a predetermined mark in the log, so as to be used for subsequent searches of the receipt and the log.
  • the first data is a receipt
  • a predetermined mark needs to be marked on the first data for later search.
  • the first data is not limited to receipts, for example, it can be data stored in the memory of the smart contract, can be data stored in a relational database, etc. In this case, there will be no need to mark a predetermined mark , And the first data can be obtained directly in a specific database (or memory).
  • a log as shown in FIG. 3 is generated, which shows a schematic diagram of the log generated after the first smart contract is executed.
  • the log (Log) has a predetermined topic (Topic), for example, the topic can be preset as "AM” to indicate that the log is a log for sending AM messages outside the chain.
  • the log includes the "To" field, the "From” field and the "Data” field.
  • the "To” field corresponds to the account of the called contract, that is, the account of the first smart contract
  • the "From” field corresponds to the account of the contract that initiated the call, that is, the account of the second smart contract (ie the first account)
  • the "Data” field is the verifiable message that the second smart contract wants to send.
  • Fig. 4 shows a schematic diagram of a predetermined protocol stack according to an embodiment of the present specification.
  • the first layer protocol includes the sending block chain identification field (S_C_ID) and the second layer protocol; the middle layer in the figure is the first layer protocol.
  • the second layer protocol, the second layer protocol includes the sending account field (S_A_id) and the third layer protocol; the uppermost layer in the figure is the third layer protocol, and the third layer protocol includes the receiving blockchain identification field (R_C_ID), Receive account field (R_A_id) and message content field.
  • R_C_ID receiving blockchain identification field
  • Receive account field R_A_id
  • the verifiable message is a message sent from the first account in the first blockchain to the second account in the second blockchain, assuming that the chain identifier of the first blockchain is ID1 , The first account is id1, the chain identifier of the second blockchain is ID2, and the second account is id2.
  • Fig. 5 shows a schematic form of an authenticateable message.
  • the first layer protocol includes ID1 and the second layer protocol
  • the second layer protocol includes id1 and the third layer protocol
  • the third layer protocol includes ID2, id2 and message content.
  • the protocol stack is designed based on the authentication process of verifiable messages.
  • the first layer protocol and the second layer protocol correspond to the authentication process of the sending chain and the sending account, respectively, and the third layer protocol corresponds to the specific communication process and business processing process.
  • the authentication process and communication process will be described in detail below.
  • the first layer protocol also includes a protocol version number field and a reserved field.
  • the reserved field is an empty field.
  • the second layer protocol further includes a type field, which is used to indicate the usage scenario type of the authenticated message. So that various usage scenarios can superimpose the use of the protocol stack. For example, for different usage scenarios (that is, different types of authentication messages), the message content field may correspond to different contents, have different formats, and so on.
  • the type is any of the following types: message type, remote procedure call type, publish/subscribe type, and so on.
  • the third layer protocol also includes a sequence number field, which is used to indicate the current sending sequence number when the first account sends an authenticateable message to the second account multiple times.
  • the corresponding field values of the protocol version number field, reserved field, type field, serial number field, etc. can be similarly passed into the first smart contract as input parameters by the first account when calling the first smart contract, so that the first The deposit function in the smart contract can output a verifiable message containing these field values based on these input parameters.
  • Fig. 6 shows a schematic diagram of a protocol stack with high applicability according to an embodiment of the present specification.
  • the first layer protocol of the protocol stack also includes a version number field and a reserved field
  • the second layer protocol of the protocol stack also includes a type field
  • the third layer protocol of the protocol stack also includes a sequence number field.
  • the protocol stack is upgradeable and extensible, can be used in a variety of scenarios, and can communicate multiple times, so it has high applicability.
  • the first account is a user account. It can send a transaction to any other account to realize the process of storing the first data in the blockchain.
  • the first data can also be transaction data in the block, for example, in the data field of the transaction.
  • a predetermined mark is preset in the, to identify the transaction as a transaction for sending information across chains, and the data field of the transaction includes the above-mentioned certifiable message.
  • the transaction is stored in the block after consensus verification.
  • the transaction data can be found through a predetermined mark, and a verifiable message can be obtained from the transaction data.
  • step S204 the first data and the first location information are provided to the relay terminal for providing the verifiable message to the second account in the second blockchain, where ,
  • the first location information indicates the location of the first data in the first blockchain.
  • the first data may be provided to the relay terminal through different methods.
  • the relay end itself is a node in the first block chain and the second block chain, so that the relay end can obtain the first data from locally stored data (such as blocks, state trees), and At the same time, first location data is acquired.
  • the first location information indicates the location of the first data in the blockchain.
  • the first location information includes the block number where the receipt is located, And the number of the receipt in the block, etc.
  • the relay end is a relay device connected to both the first block chain and the second block chain.
  • any node of the first block chain can obtain the first data and data locally according to the request of the relay end. And send it to the relay terminal. After the relay terminal obtains the first data and its location information, it will perform different steps according to its own form to provide the verifiable message in the first data to the second blockchain.
  • the second account the process will be described in detail below.
  • Fig. 7 shows a flow chart of a method for cross-chain transfer of certifiable messages according to an embodiment of the present specification.
  • the method is executed by a relay end connected to at least two blockchains.
  • a block chain includes a first block chain and a second block chain, wherein the first block chain has pre-stored consensus first data, wherein the first data includes a verifiable message,
  • the attestable message satisfies a predetermined protocol stack, and the predetermined protocol stack includes the first to third layer protocols from the outside to the inside, wherein the first layer protocol includes a sending blockchain identification field and a second layer protocol, and the second layer
  • the protocol includes the sending account field and the third layer protocol.
  • the third layer protocol includes receiving block chain identification field, receiving account field and message content field. Among them, sending block chain identification, sending account, receiving block chain identification, receiving account The fields respectively correspond to the following field values: the first blockchain identifier, the first account, the second blockchain identifier, and the second account.
  • the method
  • Step S702 Obtain the first data and first location information from the first blockchain, where the first location information indicates the location of the first data in the first blockchain;
  • Step S704 Send the first data and the first location information to the second blockchain based on the second blockchain identifier in the verifiable message.
  • the above-mentioned consensus first data is stored in the first blockchain, so that the method can be executed.
  • This method is executed by the relay end.
  • the method steps executed in the relay end are correspondingly different.
  • the relay end is the first block chain and the second block chain.
  • the transfer end between the data that is, it does not verify the data, it is only used for the transfer of data, and is not responsible for the authenticity and integrity of the data.
  • step S702 the first data and first location information are obtained from the first blockchain, where the first location information indicates the location of the first data in the first blockchain.
  • the first data is stored in the blockchain with a predetermined mark, and the predetermined mark is used for searching the data for cross-chain transmission.
  • the predetermined mark is the account of the first smart contract, and other contract accounts call the first smart contract when they want to transmit information across the chain.
  • the account of the first smart contract will be included in the corresponding receipt, so that the receipt can be found in the block as the first data through the account based on the first smart contract, and it can be determined
  • the block identifier where the receipt is located, the receipt number of the receipt in the block, etc. are used as the first location information.
  • the relay terminal may subscribe to any node the receipt of the account with the first smart contract in the block, so as to receive the first data and the first location information from the node.
  • the first data is specific data
  • the first data and its storage location can be acquired in a specific database or memory.
  • step S704 based on the second blockchain identifier in the attestable message, the first data and the first location information are sent to the second blockchain.
  • the relay terminal After the relay terminal obtains the first data and the first location information, for example, the first data is the receipt for invoking the first smart contract, and the relay terminal obtains the first smart contract account or the predetermined subject of the log from the Find a specific log in the receipt, and obtain an certifiable message from the data field of the specific log. Based on the predetermined protocol stack, it can be determined that the "second blockchain identifier" in the verifiable message is the chain identifier that will receive the verifiable message, so that the first data and the first location information can be sent to the first 2.
  • Blockchain It can be understood that the relay terminal may be connected to more than two blockchains, for example, the third blockchain and the fourth blockchain may also be connected. Therefore, the relay terminal is acquiring the first data and the first After the location information, the data is sent based on the second blockchain identification, that is, the addressing process of the receiving chain based on the receiving chain identification.
  • Fig. 8 shows a flow chart of a method for cross-chain receiving verifiable messages according to an embodiment of the present specification.
  • the cross-chain reception is received by a second account of a second blockchain from another blockchain, and the second
  • the block chain is connected to the relay end, and at least one second data respectively related to at least one other block chain is synchronized in the second block chain through the relay end, wherein the at least one other block
  • the chain includes the first blockchain, and the method is executed by the second blockchain, including:
  • Step S802 Receive first data and first location information from the relay terminal, where the first data includes an certifiable message, the certifiable message satisfies a predetermined protocol stack, and the predetermined protocol stack includes The first to third layer protocols within, wherein the first layer protocol includes the sending block chain identification field and the second layer protocol, the second layer protocol includes the sending account field and the third layer protocol, and the third layer protocol includes the receiving area Blockchain identification field, receiving account field, and message content field, where the sending blockchain identification, sending account, receiving blockchain identification, and receiving account fields respectively correspond to the following field values: first blockchain identification, first account , A second blockchain identifier, a second account, and the first location information indicates the location of the first data in the first blockchain;
  • Step S804 Obtain second data related to the first blockchain based on the first blockchain identifier in the verifiable message
  • Step S806 verify the verifiable message based on the first data, the second data related to the first blockchain, and the first location information;
  • Step S808 after the verification is passed, based on the second account in the verifiable message, provide the verifiable message to the second account.
  • the method shown in FIG. 8 corresponds to the relay terminal in the method shown in FIG. 7. After the method shown in FIG. 7 is performed, the method shown in FIG. 8 can be started.
  • the second blockchain for example, verification of certifiable messages is performed on multiple verification nodes.
  • the verification node synchronizes each second data related to each other blockchain through the relay terminal.
  • the second data It is used to verify the authenticated message.
  • the verification nodes are different, and the second data is correspondingly different.
  • the verification node is an spv node, and the second data
  • the second data is the block header of each block in the corresponding chain.
  • step S802 first data and first location information are received from the relay terminal, where the first data includes an certifiable message, the certifiable message satisfies a predetermined protocol stack, and the predetermined protocol stack Including the first to third layer protocols from the outside to the inside, where the first layer protocol includes the sending block chain identification field and the second layer protocol, the second layer protocol includes the sending account field and the third layer protocol, the third layer protocol It includes a receiving blockchain identification field, a receiving account field, and a message content field.
  • the sending blockchain identification, sending account, receiving blockchain identification, and receiving account fields correspond to the following field values: first blockchain identification, A first account, a second blockchain identifier, and a second account, and the first location information indicates the location of the first data in the first blockchain.
  • the first data is as described above, for example, a receipt with a predetermined mark obtained from a block of the first blockchain through a relay terminal.
  • the relay terminal can transfer the receipt and its location from the first blockchain to the second blockchain, so that each node in the second blockchain can obtain the receipt and its location, so that the second The accounting node or verification node in the blockchain performs the following steps S804-S808.
  • Step S804 Obtain second data related to the first blockchain based on the first blockchain identifier in the verifiable message.
  • the protocol stack shown in FIG. 4 is a layered protocol stack based on the authentication process, and the first layer protocol is used for the authentication process of the transmission chain identification. Therefore, firstly, the second data corresponding to the first blockchain can be obtained from each second data stored locally based on the sending chain identifier in the first layer protocol (that is, the first blockchain identifier). Due to the hierarchical design of the protocol stack, in the process of this step, only the sending chain identification field of the first layer protocol can be read, instead of reading the specific layer 2 protocol included in the first layer protocol. content.
  • step S806 the verifiable message is verified based on the first data, the second data related to the first blockchain, and the first location information.
  • the first data is the first receipt in the first block of the first blockchain
  • the first location information includes the block number of the first block and the first receipt in the first block.
  • the receipt number in the block, and the second data related to the first block chain is the block header of each block in the first block chain.
  • the verification of the sending chain identification includes, based on the first receipt, the block header of each block, and the Merkel tree path associated with the first receipt in the additionally obtained first block, through simple payment verification Method (spv verification method) verification: the first receipt comes from the first block in the first blockchain, and the Merkel tree path is obtained based on the first location information.
  • the spv verification method includes the following specific steps:
  • the calculated root hash value is compared with the receipt tree root hash value in the block header of the first block to determine whether the first receipt is in the first block.
  • the spv verification may further include, after determining that the first receipt is in the first block, according to the location of the first block, verifying whether the block header of the block is included in the known most In the long chain, to determine whether the first block has passed consensus.
  • the blockchain identifier corresponds to the hash value of the header of the genesis block in the blockchain, and the spv verification may further include passing the header hash value in the header of the first block Together with the parent hash value and the block header of each block, verify whether the header hash value of the genesis block of the blockchain corresponds to the chain identifier of the first blockchain.
  • the first receipt is automatically generated by the second smart contract invoking the first smart contract and includes the receipt of the log shown in FIG. 4.
  • the The first receipt may prove itself, and the first account in the certifiable message is the account that sent the message.
  • the first receipt is sent by the user account (i.e. the first account) to send the transaction and stored in the blockchain, and the verifiable message is filled in the transaction data by the user.
  • the verifiable message is located in the first log in the first receipt.
  • the verification also includes verification of the sending account in the second layer protocol in the verifiable message. Specifically, it may be based on The sending field of the first log verifies that the first account is an account that sends the certifiable message.
  • step S808 after the verification is passed, based on the second account in the verifiable message, the verifiable message is provided to the second account.
  • the second smart contract in the first blockchain transfers information to the third smart contract in the second blockchain by invoking the first smart contract, so as to perform a comparison to the third smart contract.
  • the second account is the contract account of the third smart contract
  • the verifiable message includes, for example, the third smart contract incoming parameters.
  • providing the certifiable message to the second account includes providing the certifiable message to the second account by invoking a third smart contract with the certifiable message as an incoming parameter.
  • the third smart contract executes a specific business process based on the third layer protocol in the verifiable message.
  • the second account is not limited to a smart contract account.
  • it can also be a user account.
  • the verification node can send a transaction to the user through a common method in the blockchain (such as a method of sending a transaction).
  • the account provides the verifiable message.
  • Fig. 9 shows a flow chart of a method for cross-chain transfer of certifiable messages according to an embodiment of the present specification.
  • the method is executed by a relay end connected to at least two blockchains.
  • a block chain includes a first block chain and a second block chain, wherein the first block chain has pre-stored consensus first data, wherein the first data includes a verifiable message,
  • the attestable message satisfies a predetermined protocol stack, and the predetermined protocol stack includes the first to third layer protocols from the outside to the inside, wherein the first layer protocol includes a sending blockchain identification field and a second layer protocol, and the second layer
  • the protocol includes the sending account field and the third layer protocol.
  • the third layer protocol includes receiving block chain identification field, receiving account field and message content field.
  • sending block chain identification, sending account, receiving block chain identification, receiving account The fields respectively correspond to the following field values: the first block chain identifier, the first account, the second block chain identifier, and the second account.
  • the relay terminal synchronizes each second data related to each block chain, The method includes:
  • Step S902 Obtain the first data and first location information from the first blockchain, where the first location information indicates the location of the first data in the first blockchain;
  • Step S904 Obtain second data related to the first blockchain based on the first blockchain identifier in the verifiable message
  • Step S906 verify the verifiable message based on the first data, the second data related to the first blockchain, and the first location information;
  • Step S908 in the case of passing the verification, digitally sign the verifiable message
  • Step S910 based on the second blockchain identifier in the verifiable message, send the verifiable message and its digital signature to the second blockchain.
  • the relay end is a trusted node, or can be a verification blockchain, which can perform verification locally after obtaining the first data from the first blockchain, and perform a digital signature after the verification is passed, And send it to the second blockchain, so that the second blockchain can verify the first data through the digital signature of the relay end, thereby simplifying the verification process of the second blockchain.
  • steps S902 and step S910 in the method refer to the above description of steps S702 and S704, and for steps S904 and S906, refer to the above description of steps S804 and S806, which will not be repeated here.
  • Figure 10 shows a flow chart of a method for cross-chain receiving certifiable messages according to an embodiment of this specification.
  • the cross-chain reception is received by a second account of a second blockchain from another blockchain, and the second
  • the block chain is connected to the relay end, and the relay end is also connected to at least one other block chain.
  • the at least one other block chain includes a first block chain, and the second block chain is pre-stored There is the public key of the relay end, and the method is executed by the second blockchain, including:
  • Step S1002 receiving a verifiable message from the relay terminal and the digital signature of the relay terminal on the verifiable message, the verifiable message satisfies a predetermined protocol stack, and the predetermined protocol stack includes The first to third layer protocols, where the first layer protocol includes the sending block chain identification field and the second layer protocol, the second layer protocol includes the sending account field and the third layer protocol, and the third layer protocol includes the receiving block chain The identification field, the receiving account field, and the message content field, where the sending blockchain identification, sending account, receiving blockchain identification, and receiving account fields correspond to the following field values: first blockchain identification, first account, and first 2. Blockchain identification and second account;
  • Step S1004 using the public key of the relay terminal to verify the digital signature
  • Step S1006 After the verification is passed, based on the second account in the verifiable message, the verifiable message is provided to the second account.
  • the method shown in FIG. 10 corresponds to the relay terminal in the method shown in FIG. 9. After the method shown in FIG. 9 is performed, the method shown in FIG. 10 can be started. This method can be executed by any node or client in the second blockchain. The node (or client) only needs to save the public key of the relay terminal locally, that is, it can verify the certifiable message. Therefore, there is no need to In the scheme shown in 8, the first data is received from the relay end, and only the authenticable message needs to be received. For step S1006, reference may be made to the description of step S808 above, which will not be repeated here.
  • FIG. 11 shows an apparatus 1100 for sending an authenticated message across chains according to an embodiment of the present specification.
  • the cross-chain sending is sending from a first account of a first blockchain to other blockchains.
  • the first area The block chain is connected to the relay end, the relay end is also connected to at least one other block chain, the at least one other block chain includes a second block chain, and the device is deployed in the first block Chain, including:
  • the depositing unit 111 is configured to deposit consensus first data into the first blockchain through the first account, wherein the first data includes a verifiable message, and the verifiable message satisfies a predetermined Protocol stack, the predetermined protocol stack includes first to third layer protocols from the outside to the inside, wherein the first layer protocol includes the sending block chain identification field and the second layer protocol, and the second layer protocol includes the sending account field and the third layer.
  • the third layer protocol includes receiving block chain identification field, receiving account field and message content field.
  • sending block chain identification, sending account, receiving block chain identification, and receiving account fields respectively correspond to the following field values : The first blockchain identifier, the first account, the second blockchain identifier, and the second account; and
  • the providing unit 112 is configured to provide the first data and first location information to the relay terminal, so as to provide the attestable message to the second block chain.
  • the deposit unit 1101 is further configured to deposit the first data in the first blockchain by invoking a first smart contract from the first account, wherein the first account When the first smart contract is called, at least the following parameters are passed to the first smart contract: the second blockchain identifier, the second account, and the message content.
  • Fig. 12 shows an apparatus 1200 for transferring certifiable messages across chains according to an embodiment of the present specification.
  • the apparatus is deployed at a relay end, and the relay end is connected to at least two blockchains.
  • the block chain includes a first block chain and a second block chain, wherein the first block chain has pre-stored consensus first data, wherein the first data includes a verifiable message, so
  • the certifiable message satisfies a predetermined protocol stack, and the predetermined protocol stack includes the first to third layer protocols from the outside to the inside, wherein the first layer protocol includes a sending block chain identification field and a second layer protocol, and the second layer protocol Including the sending account field and the third layer protocol.
  • the third layer protocol includes receiving block chain identification field, receiving account field and message content field.
  • sending block chain identification, sending account, receiving block chain identification, receiving account field Corresponding to the following field values respectively: a first blockchain identifier, a first account, a second blockchain identifier, and a second account
  • the obtaining unit 121 is configured to obtain the first data and first location information from the first blockchain, where the first location information indicates the location of the first data in the first blockchain;
  • the sending unit 122 is configured to send the first data and the first location information to the second blockchain based on the second blockchain identifier in the verifiable message.
  • the first data is marked with a predetermined mark
  • the acquiring unit is further configured to acquire the first data and the first location from the first blockchain based on the predetermined mark information.
  • FIG. 13 shows an apparatus 1300 for receiving verifiable messages across chains according to an embodiment of the present specification.
  • the cross-chain reception is received by a second account of a second blockchain from other blockchains.
  • the second area The block chain is connected to the relay end, and at least one second data respectively related to at least one other block chain is synchronized in the second block chain through the relay end, wherein the at least one other block chain
  • the device includes the first blockchain, and the device is deployed on the second blockchain, including:
  • the receiving unit 131 is configured to receive first data and first location information from the relay terminal, wherein the first data includes an certifiable message, the certifiable message satisfies a predetermined protocol stack, and the predetermined protocol
  • the stack includes the first to third layer protocols from the outside to the inside.
  • the first layer protocol includes the sending block chain identification field and the second layer protocol.
  • the second layer protocol includes the sending account field and the third layer protocol.
  • the third layer The protocol includes a receiving block chain identification field, a receiving account field, and a message content field.
  • the sending block chain identification, sending account, receiving block chain identification, and receiving account fields correspond to the following field values: first block chain identification , A first account, a second blockchain identifier, and a second account, where the first location information indicates the location of the first data in the first blockchain;
  • the acquiring unit 132 is configured to acquire second data related to the first blockchain based on the first blockchain identifier in the verifiable message;
  • the verification unit 133 is configured to verify the attestable message based on the first data, the second data related to the first blockchain, and the first location information;
  • the providing unit 134 is configured to, after the verification is passed, provide the verifiable message to the second account based on the second account in the verifiable message.
  • the first data is the first receipt in the first block of the first blockchain
  • the first location information includes the block number of the first block and the first receipt in the first block.
  • the receipt number in the block, the second data related to the first block chain is the block header of each block in the first block chain
  • the verification unit 133 is further configured to, based on the first block chain A receipt, the block header of each block, and the Merkel tree path associated with the first receipt in the first block are verified by a simple payment verification method: the first receipt comes from the first blockchain The first block in, wherein the Merkel tree path is obtained based on the first location information.
  • the certifiable message is located in the first log in the first receipt, and the verification unit 133 is further configured to, based on the sending field of the first log, It is verified that the first account is an account that sends the certifiable message.
  • the second account is a contract account of a third smart contract
  • the providing unit 134 is further configured to call the third smart contract with the verifiable message as an incoming parameter to send the second account Provide the attestable message.
  • FIG. 14 shows an apparatus 1400 for transferring certifiable messages across chains according to an embodiment of the present specification.
  • the apparatus is deployed at a relay end, and the relay end is connected to at least two blockchains.
  • the block chain includes a first block chain and a second block chain, wherein the first block chain has pre-stored consensus first data, wherein the first data includes a verifiable message, so
  • the certifiable message satisfies a predetermined protocol stack, and the predetermined protocol stack includes the first to third layer protocols from the outside to the inside, wherein the first layer protocol includes a sending block chain identification field and a second layer protocol, and the second layer protocol Including the sending account field and the third layer protocol.
  • the third layer protocol includes receiving block chain identification field, receiving account field and message content field.
  • sending block chain identification, sending account, receiving block chain identification, receiving account field Correspond to the following field values respectively: the first blockchain identifier, the first account, the second blockchain identifier, and the second account.
  • the relay terminal synchronizes each second data related to each blockchain, so The device includes:
  • the first obtaining unit 141 is configured to obtain the first data and first location information from the first blockchain, where the first location information indicates the location of the first data in the first blockchain;
  • the second acquiring unit 142 is configured to acquire second data related to the first blockchain based on the first blockchain identifier in the attestable message;
  • the verification unit 143 is configured to verify the verifiable message based on the first data, second data related to the first blockchain, and the first location information;
  • the signature unit 144 is configured to digitally sign the verifiable message when the verification is passed.
  • the sending unit 145 is configured to send the verifiable message and its digital signature to the second blockchain based on the second block chain identifier in the verifiable message.
  • FIG. 15 shows an apparatus 1500 for receiving verifiable messages across chains according to an embodiment of the present specification.
  • the cross-chain reception is received by a second account of a second blockchain from other blockchains.
  • the second area The block chain is connected to the relay end, the relay end is also connected to at least one other block chain, the at least one other block chain includes a first block chain, and the second block chain is pre-stored
  • the public key of the relay end, where the device is deployed on the second blockchain includes:
  • the receiving unit 151 is configured to receive a verifiable message from the relay terminal and a digital signature of the verifiable message by the relay terminal, where the verifiable message satisfies a predetermined protocol stack, and the predetermined protocol stack includes The first to third layer protocols from the outside to the inside, where the first layer protocol includes the sending block chain identification field and the second layer protocol, the second layer protocol includes the sending account field and the third layer protocol, and the third layer protocol includes The receiving block chain identification field, the receiving account field, and the message content field, where the sending block chain identification, sending account, receiving block chain identification, and receiving account fields correspond to the following field values: the first block chain identification, the first One account, the second blockchain identifier, and the second account;
  • the verification unit 152 is configured to use the public key of the relay terminal to verify the digital signature
  • the providing unit 153 is configured to, after the verification is passed, provide the verifiable message to the second account based on the second account in the verifiable message.
  • Another aspect of this specification provides a computer-readable storage medium on which a computer program is stored.
  • the computer program is executed in a computer, the computer is caused to execute any of the above methods.
  • Another aspect of this specification provides a computing device including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, any one of the above methods is implemented.
  • the blockchain interoperability model is abstracted, and a verifiable message is designed so that the message sent by the blockchain can be verified by other chains: which chain the message comes from and which chain on the chain Issued by the identity entity (account/contract).
  • identity entity identity entity
  • cross-chain application (contract) programming is allowed, so that developers can more easily develop various cross-chain services and applications, and the verifiable message retains high scalability and supports overlay protocol stacks. All kinds of cross-chain interoperability technologies and application scenarios can be standardized.
  • the certifiable message can be realized by heterogeneous platforms, so that the blockchain can only realize a cross-chain adaptation and upgrade, and can access multiple cross-chain platforms , Connect multiple chains.
  • the steps of the method or algorithm described in the embodiments disclosed in this document can be implemented by hardware, a software module executed by a processor, or a combination of the two.
  • the software module can be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, or all areas in the technical field. Any other known storage medium.

Abstract

本说明书实施例提供了一种跨链发送可认证消息的方法和装置，所述跨链发送为从第一区块链的第一账户向其它区块链发送，所述第一区块链与中继端连接，所述中继端还与至少一个其它区块链连接，所述至少一个其它区块链中包括第二区块链，所述方法由所述第一区块链执行，包括：通过所述第一账户向第一区块链中存入经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，并且，所述第一数据被标注有预定标志；以及将所述第一数据和第一位置信息提供给所述中继端，以用于将所述可认证消息提供给所述第二区块链中的所述第二账户，其中，所述第一位置信息指示第一数据在第一区块链中的位置。

Description

一种跨链发送可认证消息的方法和装置 技术领域
本说明书实施例涉及区块链技术领域，更具体地，涉及一种跨链发送可认证消息的方法和装置。
背景技术
区块链技术也被称之为分布式账本技术，是一种去中心化的分布式数据库技术，其特点是去中心化、公开透明、不可篡改、可信任。区块链的每笔数据，都会广播到全网的区块链节点，每个全节点都有全量的、一致的数据。随着区块链技术的火热，出现了许多不同类型的链，应用在金融、健康医疗、供应链、资产管理和溯源等领域。然而大部分链上应用(加密货币或者智能合约)都无法跨越当前链的边界，不能与其他链协同合作实现价值的流通，从而限制了区块链的发挥空间。如何能让不同类型的链协同合作实现价值的流通成了探索的方向。目前已出现多种跨链技术，然而，每种跨链技术都有自己独特设计，应对的场景也各不相同，针对不同场景下的跨链，一条链可能需要接入多种跨链平台。
因此，需要一种更有效的跨链传递信息的方案。
发明内容
本说明书实施例旨在提供一种更有效的跨链传递信息的方案，以解决现有技术中的不足。
为实现上述目的，本说明书一个方面提供一种跨链发送可认证消息的方法，所述跨链发送为从第一区块链的第一账户向其它区块链发送，所述第一区块链与中继端连接，所述中继端还与至少一个其它区块链连接，所述至少一个其它区块链中包括第二区块链，所述方法由所述第一区块链执行，包括：
通过所述第一账户向第一区块链中存入经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字 段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户；以及
将所述第一数据和第一位置信息提供给所述中继端，以用于将所述可认证消息提供给所述第二区块链中的所述第二账户，其中，所述第一位置信息指示第一数据在第一区块链中的位置。
在一个实施例中，通过所述第一账户向第一区块链中存入经共识的第一数据包括，通过由所述第一账户调用第一智能合约向第一区块链中存入所述第一数据，其中，所述第一账户在调用第一智能合约时向第一智能合约传入至少以下参数：第二区块链标识、第二账户及消息内容。
在一个实施例中，所述第一数据被标注有预定标志。
在一个实施例中，所述第一数据为收据，所述收据中包括在执行所述第一智能合约之后生成的日志，所述日志的数据字段为所述可认证消息。
在一个实施例中，所述日志被标注有预定主题，所述预定标志为所述预定主题。
在一个实施例中，所述预定标志为所述第一智能合约的账户标识。
在一个实施例中，所述第一层协议中还包括协议版本号字段和预留字段。
在一个实施例中，所述第二层协议中还包括类型字段，用于指示该可认证消息的使用场景类型。
在一个实施例中，所述类型为以下任一类型：消息类型、远程过程调用类型、发布/订阅类型。
在一个实施例中，所述第三层协议中还包括序号字段，用于在所述第一账户向所述第二账户多次发送可认证消息的情况中表示当前发送序号。
在一个实施例中，所述第一账户为第二智能合约的合约账户。
本说明书另一方面提供一种跨链中转可认证消息的方法，所述方法由中继端执行，所述中继端与至少两个区块链连接，所述至少两个区块链中包括第一区块链和第二区块链，其中，所述第一区块链中预存有经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括 发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述方法由中继端执行，包括：
从所述第一区块链获取所述第一数据和第一位置信息，所述第一位置信息指示第一数据在第一区块链中的位置；以及
基于所述可认证消息中的第二区块链标识，将所述第一数据和所述第一位置信息发送给所述第二区块链。
在一个实施例中，所述第一数据被标注有预定标志，其中，从所述第一区块链获取所述第一数据和第一位置信息包括，基于所述预定标志从所述第一区块链获取所述第一数据和第一位置信息。
本说明书另一方面提供一种跨链接收可认证消息的方法，所述跨链接收为由第二区块链的第二账户从其它区块链接收，所述第二区块链与中继端连接，所述第二区块链中通过所述中继端同步有与至少一个其它区块链分别相关的至少一个第二数据，其中，所述至少一个其它区块链中包括第一区块链，所述方法由第二区块链执行，包括：
从所述中继端接收第一数据和第一位置信息，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述第一位置信息指示所述第一数据在所述第一区块链中的位置；
基于所述可认证消息中的第一区块链标识，获取与所述第一区块链相关的第二数据；
基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证；以及
在验证通过之后，基于所述可认证消息中的第二账户，向所述第二账户提供所述可认证消息。
在一个实施例中，所述第一数据为第一区块链的第一区块中的第一收据，所述第一位置信息包括第一区块的区块编号和第一收据在第一区块中的收据编号，所述与第一区 块链相关的第二数据为第一区块链中的各个区块的区块头，其中，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证包括，基于所述第一收据、所述各个区块的区块头和第一区块中的与第一收据相关联的默克尔树路径，通过简单支付验证方法验证：所述第一收据来自于第一区块链中的第一区块，其中，所述默克尔树路径基于所述第一位置信息获取。
在一个实施例中，所述可认证消息位于所述第一收据中的第一日志中，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证还包括，基于所述第一日志的发送字段，验证所述第一账户为发送所述可认证消息的账户。
在一个实施例中，所述第二账户为第三智能合约的合约账户，向所述第二账户提供所述可认证消息包括，通过以所述可认证消息为传入参数调用第三智能合约，向第二账户提供所述可认证消息。
本说明书另一方面提供一种跨链中转可认证消息的方法，所述方法由中继端执行，所述中继端与至少两个区块链连接，所述至少两个区块链中包括第一区块链和第二区块链，其中，所述第一区块链中预存有经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述中继端同步有与各个区块链分别相关的各个第二数据，所述方法包括：
从所述第一区块链获取所述第一数据和第一位置信息，所述第一位置信息指示第一数据在第一区块链中的位置；
基于所述可认证消息中的第一区块链标识，获取与所述第一区块链相关的第二数据；
基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证；
在验证通过的情况中，对所述可认证消息进行数字签名；以及
基于所述可认证消息中的第二区块链标识，将所述可认证消息及其数字签名发送给所述第二区块链。
本说明书另一方面提供一种跨链接收可认证消息的方法，所述跨链接收为由第二区块链的第二账户从其它区块链接收，所述第二区块链与中继端连接，所述中继端还与至少一个其它区块链连接，所述至少一个其它区块链中包括第一区块链，所述第二区块链中预先存储有所述中继端的公钥，所述方法由第二区块链执行，包括：
从所述中继端接收可认证消息、及所述中继端对所述可认证消息的数字签名，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户；
使用所述中继端的公钥对所述数字签名进行验证；以及
在验证通过之后，基于所述可认证消息中的第二账户，向所述第二账户提供所述可认证消息。
本说明书另一方面提供一种跨链发送可认证消息的装置，所述跨链发送为从第一区块链的第一账户向其它区块链发送，所述第一区块链与中继端连接，所述中继端还与至少一个其它区块链连接，所述至少一个其它区块链中包括第二区块链，所述装置部署在所述第一区块链，包括：
存入单元，配置为，通过所述第一账户向第一区块链中存入经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户；以及
提供单元，配置为，将所述第一数据和第一位置信息提供给所述中继端，以用于将所述可认证消息提供给所述第二区块链中的所述第二账户，其中，所述第一位置信息指示第一数据在第一区块链中的位置。
在一个实施例中，所述存入单元还配置为，通过由所述第一账户调用第一智能合约向第一区块链中存入所述第一数据，其中，所述第一账户在调用第一智能合约时向第一 智能合约传入至少以下参数：第二区块链标识、第二账户及消息内容。
本说明书另一方面提供一种跨链中转可认证消息的装置，所述装置部署在中继端，所述中继端与至少两个区块链连接，所述至少两个区块链中包括第一区块链和第二区块链，其中，所述第一区块链中预存有经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述装置包括：
查找单元，配置为，从所述第一区块链获取所述第一数据和第一位置信息，所述第一位置信息指示第一数据在第一区块链中的位置；以及
发送单元，配置为，基于所述可认证消息中的第二区块链标识，将所述第一数据和所述第一位置信息发送给所述第二区块链。
在一个实施例中，所述第一数据被标注有预定标志，其中，所述获取单元还配置为，基于所述预定标志从所述第一区块链获取所述第一数据和第一位置信息。
本说明书另一方面提供一种跨链接收可认证消息的装置，所述跨链接收为由第二区块链的第二账户从其它区块链接收，所述第二区块链与中继端连接，所述第二区块链中通过所述中继端同步有与至少一个其它区块链分别相关的至少一个第二数据，其中，所述至少一个其它区块链中包括第一区块链，所述装置部署在第二区块链，包括：
接收单元，配置为，从所述中继端接收第一数据和第一位置信息，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述第一位置信息指示所述第一数据在所述第一区块链中的位置；
获取单元，配置为，基于所述可认证消息中的第一区块链标识，获取与所述第一区块链相关的第二数据；
验证单元，配置为，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证；以及
提供单元，配置为，在验证通过之后，基于所述可认证消息中的第二账户，向所述第二账户提供所述可认证消息。
在一个实施例中，所述第一数据为第一区块链的第一区块中的第一收据，所述第一位置信息包括第一区块的区块编号和第一收据在第一区块中的收据编号，所述与第一区块链相关的第二数据为第一区块链中的各个区块的区块头，其中，所述验证单元还配置为，基于所述第一收据、所述各个区块的区块头和第一区块中的与第一收据相关联的默克尔树路径，通过简单支付验证方法验证：所述第一收据来自于第一区块链中的第一区块，其中，所述默克尔树路径基于所述第一位置信息获取。
在一个实施例中，所述可认证消息位于所述第一收据中的第一日志中，所述验证单元还配置为，基于所述第一日志的发送字段，验证所述第一账户为发送所述可认证消息的账户。
在一个实施例中，所述第二账户为第三智能合约的合约账户，所述提供单元还配置为，通过以所述可认证消息为传入参数调用第三智能合约，向第二账户提供所述可认证消息。
本说明书另一方面提供一种跨链中转可认证消息的装置，所述装置部署在中继端，所述中继端与至少两个区块链连接，所述至少两个区块链中包括第一区块链和第二区块链，其中，所述第一区块链中预存有经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述中继端同步有与各个区块链分别相关的各个第二数据，所述装置包括：
查找单元，配置为，从所述第一区块链获取所述第一数据和第一位置信息，所述第一位置信息指示第一数据在第一区块链中的位置；
获取单元，配置为，基于所述可认证消息中的第一区块链标识，获取与所述第一区块链相关的第二数据；
验证单元，配置为，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证；
签名单元，配置为，在验证通过的情况中，对所述可认证消息进行数字签名；以及
发送单元，配置为，基于所述可认证消息中的第二区块链标识，将所述可认证消息及其数字签名发送给所述第二区块链。
本说明书另一方面提供一种跨链接收可认证消息的装置，所述跨链接收为由第二区块链的第二账户从其它区块链接收，所述第二区块链与中继端连接，所述中继端还与至少一个其它区块链连接，所述至少一个其它区块链中包括第一区块链，所述第二区块链中预先存储有所述中继端的公钥，所述装置部署在第二区块链，包括：
接收单元，配置为，从所述中继端接收可认证消息、及所述中继端对所述可认证消息的数字签名，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户；
验证单元，配置为，使用所述中继端的公钥对所述数字签名进行验证；以及
提供单元，配置为，在验证通过之后，基于所述可认证消息中的第二账户，向所述第二账户提供所述可认证消息。
本说明书另一方面提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行上述任一项方法。
本说明书另一方面提供一种计算设备，包括存储器和处理器，其特征在于，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现上述任一项方法。
根据本说明书实施例的跨链方案抽象区块链互操作模型，设计一种可认证消息，使得区块链发出的消息可以被其他链认证：消息来自于哪条链，且由链上的哪个身份实体(账号/合约)发出。使得基于此可认证消息，允许进行跨链应用(合约)编程，使开发者更轻易地开发出各种跨链业务、应用。
附图说明
通过结合附图描述本说明书实施例，可以使得本说明书实施例更加清楚：
图1示出根据本说明书实施例的跨链系统的示意图；
图2示出根据本说明书实施例的一种跨链发送可认证消息的方法流程图；
图3示出了在执行第一智能合约之后生成的日志的示意图；
图4示出根据本说明书实施例的预定协议栈的示意图；
图5示出了可认证消息的示意形式；
图6示出根据本说明书实施例的高适用性的协议栈的示意图；
图7示出根据本说明书实施例的一种跨链中转可认证消息的方法流程图；
图8示出根据本说明书实施例的一种跨链接收可认证消息的方法流程图；
图9示出根据本说明书实施例的一种跨链中转可认证消息的方法流程图；
图10示出根据本说明书实施例的一种跨链接收可认证消息的方法流程图；
图11示出根据本说明书实施例的一种跨链发送可认证消息的装置1100；
图12示出根据本说明书实施例的一种跨链中转可认证消息的装置1200；
图13示出根据本说明书实施例的一种跨链接收可认证消息的装置1300；
图14示出根据本说明书实施例的一种跨链中转可认证消息的装置1400；
图15示出根据本说明书实施例的一种跨链接收可认证消息的装置1500。
具体实施方式
下面将结合附图描述本说明书实施例。
图1示出根据本说明书实施例的跨链系统的示意图。如图1所示，所述跨链系统包括第一区块链11、中继端12和第二区块链13。第一区块链11中例如包括账户A，第二区块链13中例如包括账户B，所述账户A和账户B可以为用户账户，或者也可以为合约账户。当第一区块链中的账户A希望向第二区块链中的账户B发送信息时，其可通过可认证消息(AM消息)的形式进行发送。该可认证消息被包括在账户A存入区块链的经共识的第一数据(数据1)中。第二区块链13中可包括例如多个简单支付验证(spv) 节点，该节点本地预先获取有第一区块链11中的第二数据(数据2)，数据2用于验证数据1。该spv节点可通过第一区块链11与第二区块链13之间的中继端12的中转获取第一数据(数据1)及其位置信息(位置1)，并使用数据2对该数据1进行验证，并在验证通过之后将数据1中的AM消息提供给账户B。从而账户B可基于该AM消息进行业务处理。
可以理解，上述参考图1的描述只是示意性的，而不是用于限制本说明书实施例。例如，中继端在获取数据1之后，可根据预先获取的第一区块链中的数据2对数据1进行验证并数字签名，并发送给第二区块链，第二区块链可基于中继链的公钥验证数字签名，从而验证所述数据1。下面具体描述上述过程。
图2示出根据本说明书实施例的一种跨链发送可认证消息的方法流程图，所述跨链发送为从第一区块链的第一账户向其它区块链发送，所述第一区块链与中继端连接，所述中继端还与至少一个其它区块链连接，所述至少一个其它区块链中包括第二区块链，所述方法由所述第一区块链执行，包括：
步骤S202，通过所述第一账户向第一区块链中存入经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户；以及
步骤S204，将所述第一数据和第一位置信息提供给所述中继端，以用于将所述可认证消息提供给所述第二区块链中的所述第二账户，其中，所述第一位置信息指示第一数据在第一区块链中的位置。
在本说明书实施例中，第一区块链和第二区块链可以为任意区块链，如比特币链、以太坊链等等，其通过具有统一格式的可认证消息传递信息，因此，本说明书实施例对于区块链的类型、具体的应用场景没有特别限定。所述中继端为连接在第一区块链和第二区块链之间的中间件，该中继端可以具有多种形式，例如，该中继端可以同为第一区块链和第二区块链中的节点，即，该中继端同时具有第一区块链和第二区块链中的账户；或者该中继端为与第一区块链和第二区块链都连接的中转装置，其不负责验证数据，仅用于中转数据；或者该中继端为可信节点，其在从第一区块链接收数据之后，对该数据 进行验证，并在验证通过之后将数据发送给第二区块链；或者该中继端还可以为验证区块链，其在对从第一区块链接收的数据进行共识验证之后发送给第二区块链。
在步骤S202，通过所述第一账户向第一区块链中存入经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户。
其中，第一账户可以为用户账户，或者也可以为合约账户。所述第一数据可以为区块链中的交易、收据、状态树状态、智能合约存储器、关系型数据库等中的任一数据，这些数据都是经过各个节点的共识存入区块链中，因此其在各个节点是一致的，并且是可验证的。本领域技术人员已知，在区块链中可通过发送交易而在区块链中存入上述经共识的数据，在此不再详述该过程。
在一个实施例中，通过所述第一账户向第一区块链中存入经共识的第一数据包括，通过由所述第一账户调用第一智能合约向第一区块链中存入所述第一数据，其中，所述第一账户在调用第一智能合约时向第一智能合约传入至少以下参数：第二区块链标识、第二账户及消息内容。在一个实施例中，所述第一账户为第二智能合约的合约账户，其例如通过调用第一智能合约，而向第二区块链中的第三智能合约传递参数，以实现跨链调用第三智能合约的目的。第一智能合约为用于向第一区块链中存入第一数据以跨链传递可认证消息的特定智能合约，其例如可供用于发送信息的合约(即第二智能合约)调用，在调用时，需要至少传入接收链标识(即第二区块链标识)、接收账户标识(即第二账户)和消息内容。
第一智能合约在执行时，其例如包括存入函数“Save()”，该存入函数的传入参数即为第一智能合约的传入参数，即第二区块链标识、第二账户及消息内容等，另外，该存入函数从发出调用的第二智能合约获取其账户(即第一账户)，将第一账户、预置的第一区块链的链标识以及在调用时传入的参数(即第二区块链标识、第二账户及消息内容)以预定格式(即预定协议栈)组合成可认证消息，并作为函数结果输出。
所述输出的函数结果被存入相应的日志中。该日志被包括在与该次调用对应的交易的交易收据中，该交易收据通过第一区块链中的节点共识验证被存入第一区块链中的区 块中。也就是说，在该实施例中，所述第一数据即为区块链中的收据，该收据中的特定日志中包括了所述可认证消息。在区块链的区块中，例如可通过第一智能合约的合约标识作为预定标志查找到该收据。在一个实施例中，所述日志中还设定特定主题(名称)作为预定标志，从而以用于后续对该收据和该日志的查找。可以理解，在第一数据为收据的情况中，需要对该第一数据标志预定标志，以用于后期的查找。然而，第一数据不限于为收据，例如，其可以为存入智能合约的存储器中的数据，可以为存入关系型数据库中的数据等等，在该情况中，将不需要标注有预定标志，而可以直接在特定数据库(或存储器)中获取该第一数据。
在通过第二智能合约对第一智能合约的调用从而执行第一智能合约之后，例如将生成如图3所示的日志，图3示出了在执行第一智能合约之后生成的日志的示意图。如图3所示，该日志(Log)具有预定主题(Topic)，例如该主题可以预设为“AM”，以用于指示该日志是用于对链外发送AM消息的日志。在该日志中包括“To”字段，“From”字段和“Data”字段。其中，“To”字段对应于被调用合约的账户，也即第一智能合约的账户，“From”字段对应于发起调用的合约的账户，也即第二智能合约的账户(即第一账户)，“Data”字段中即第二智能合约希望发出的可认证消息。
其中，所述可认证消息满足预定协议栈。图4示出根据本说明书实施例的预定协议栈的示意图。如图4所示，图中最下层为根据本说明书实施例的第一层协议，该第一层协议中包括发送区块链标识字段(S_C_ID)和第二层协议；图中中间层为第二层协议，该第二层协议中包括发送账户字段(S_A_id)和第三层协议；图中最上层为第三层协议，该第三层协议中包括接收区块链标识字段(R_C_ID)、接收账户字段(R_A_id)和消息内容字段。可以理解，发送账户应为发送区块链中的账户，接收账户应为接收区块链中的账户。
例如，如上文所述，所述可认证消息为从第一区块链中的第一账户发送给第二区块链中的第二账户的消息，假设第一区块链的链标识为ID1，第一账户为id1，第二区块链的链标识为ID2，第二账户为id2，则，图5示出了可认证消息的示意形式。如图5所示，根据图4所示的协议栈，第一层协议包括ID1和第二层协议，第二层协议包括id1和第三层协议，第三层协议包括ID2、id2和消息内容。
该协议栈基于可认证消息的认证过程设计，其中第一层协议和第二层协议分别对应于对发送链和发送账户的认证过程，第三层协议对应于具体的通信过程和业务处理过程。该认证过程和通信过程将在下文详细描述。通过这样设计协议栈，可使得在接收 到可认证消息之后，对其分层验证并在验证通过之后获取消息内容并进行具体业务处理，因此，每层协议都具有其特定的认证语义，以便于分层认证的过程。
在一个实施例中，第一层协议中还包括协议版本号字段和预留字段。以允许对该协议栈进行升级和扩展。其中，所述预留字段为空字段。
在一个实施例中，第二层协议中还包括类型字段，用于指示该可认证消息的使用场景类型。从而使得各个使用场景可叠加使用该协议栈。例如，针对不同的使用场景(即可认证消息中的不同的类型)，所述消息内容字段中可对应于不同的内容、具有不同的格式等。所述类型为以下任一类型：消息类型、远程过程调用类型、发布/订阅类型，等等。
所述第三层协议中还包括序号字段，用于在所述第一账户向所述第二账户多次发送可认证消息的情况中表示当前发送序号。
所述协议版本号字段、预留字段、类型字段、序号字段等各自对应的字段值可类似地由第一账户在调用第一智能合约时作为输入参数传入第一智能合约，从而使得第一智能合约中的存入函数可基于这些输入参数输出包含这些字段值的可认证消息。
图6示出根据本说明书实施例的高适用性的协议栈的示意图。如图6所示，相比于图4所示的协议栈，该协议栈的第一层协议中还包括版本号字段和预留字段，该协议栈的第二层协议中还包括类型字段，该协议栈的第三层协议中还包括序号字段。如上文所述，该协议栈可升级、可扩展，可用于多种场景类型，可进行多次通信，因此具有高适用性。
虽然上文中以第二智能合约调用第一智能合约为例描述了向第一区块链中存入经共识的收据的过程，本说明书实施例不限于此，例如，第一账户为用户账户，其可通过向其它任一账户发送交易，从而实现向区块链中存入第一数据的过程，该第一数据例如还可以为区块中的交易数据，例如，可在该交易的数据字段中预置预定标志，以标识该交易为用于跨链发送信息的交易，并且该交易的数据字段中包括上述可认证消息。从而，在第一账户发出该交易之后，该交易在共识验证之后被存入区块中。在后续过程中，可通过预定标志查找到该交易数据，并从该交易数据中获取可认证消息。
在步骤S204，将所述第一数据和第一位置信息提供给所述中继端，以用于将所述可认证消息提供给所述第二区块链中的所述第二账户，其中，所述第一位置信息指示第一数据在第一区块链中的位置。
如上文所述，在本说明书实施例中，可使用不同的中继端，根据中继端的不同的实现方式，可通过不同的方法将第一数据提供给中继端。例如，该中继端本身为第一区块链和第二区块链中的节点，从而中继端可从本地存储的数据(如区块、状态树)中获取所述第一数据，并同时获取第一位置数据，所述第一位置信息指示第一数据在区块链中的位置，例如，在第一数据为收据的情况中，所述第一位置信息包括收据所在区块编号、以及收据在该区块中的编号等。例如，该中继端为与第一区块链和第二区块链都连接的中转装置，从而，第一区块链的任一节点可根据中继端的请求从本地获取该第一数据及其位置信息，并将其发送给中继端。中继端在获取该第一数据及其位置信息之后，将根据其自身的形式的不同，执行不同的步骤，以用于将第一数据中的可认证消息提供给第二区块链中的第二账户，该过程将在下文详细描述。
图7示出根据本说明书实施例的一种跨链中转可认证消息的方法流程图，所述方法由中继端执行，所述中继端与至少两个区块链连接，所述至少两个区块链中包括第一区块链和第二区块链，其中，所述第一区块链中预存有经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述方法包括：
步骤S702，从所述第一区块链获取所述第一数据和第一位置信息，所述第一位置信息指示第一数据在第一区块链中的位置；以及
步骤S704，基于所述可认证消息中的第二区块链标识，将所述第一数据和所述第一位置信息发送给所述第二区块链。
在第一区块链中进行图2所示方法之后，在所述第一区块链中存入了上述经共识的第一数据，从而可执行该方法。
该方法由中继端执行，根据中继端的具体实现方式不同，中继端中执行的方法步骤也相应地不同，在该方法中，中继端为第一区块链与第二区块链之间的中转端，即，其不进行对数据的验证，仅用于数据的中转，并且不对数据的真实性、完整性负责。
在步骤S702，从所述第一区块链获取所述第一数据和第一位置信息，所述第一 位置信息指示第一数据在第一区块链中的位置。
在一个实施例中，所述第一数据带有预定标志地被存入区块链中，该预定标志用于对该类用于跨链发送的数据的查找。例如，该预定标志为第一智能合约的账户，其它合约账户在希望跨链传送信息时调用该第一智能合约。在调用该第一智能合约之后，在相应的收据中将包括该第一智能合约的账户，从而通过基于该第一智能合约的账户可从区块中查找该收据作为第一数据，并可确定该收据所在的区块标识、该收据在该区块中的收据编号等一起作为第一位置信息。中继端例如可向任一节点订阅区块中具有第一智能合约的账户的收据，从而可从该节点接收所述第一数据和所述第一位置信息。如上文所述，在第一数据为特定数据的情况中，可在特定数据库或存储器中获取所述第一数据及其存储位置。
在步骤S704，基于所述可认证消息中的第二区块链标识，将所述第一数据和所述第一位置信息发送给所述第二区块链。
中继端在获取所述第一数据和第一位置信息之后，例如，该第一数据为上述调用第一智能合约的收据，中继端通过该第一智能合约账户或者日志的预定主题从该收据中找到特定日志，并从该特定日志的数据字段中获取可认证消息。基于所述预定协议栈，可确定该可认证消息中的“第二区块链标识”即为将要接收该可认证消息的链标识，从而可将该第一数据和第一位置信息发送给第二区块链。可以理解，该中继端可能连接了不止两个区块链，例如可能还连接了第三区块链、第四区块链等，因此，该中继端在获取该第一数据和第一位置信息之后，基于其中的第二区块链标识进行数据的发送，也即基于接收链标识对接收链的寻址过程。
图8示出根据本说明书实施例的一种跨链接收可认证消息的方法流程图，所述跨链接收为由第二区块链的第二账户从其它区块链接收，所述第二区块链与中继端连接，所述第二区块链中通过所述中继端同步有与至少一个其它区块链分别相关的至少一个第二数据，其中，所述至少一个其它区块链中包括第一区块链，所述方法由第二区块链执行，包括：
步骤S802，从所述中继端接收第一数据和第一位置信息，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户 字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述第一位置信息指示所述第一数据在所述第一区块链中的位置；
步骤S804，基于所述可认证消息中的第一区块链标识，获取与所述第一区块链相关的第二数据；
步骤S806，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证；以及
步骤S808，在验证通过之后，基于所述可认证消息中的第二账户，向所述第二账户提供所述可认证消息。
图8所示方法与图7所示方法中的中继端相对应，在进行图7所示方法之后，可开始图8所示方法。在第二区块链中，例如在多个验证节点进行对可认证消息的验证，该验证节点中通过中继端同步有与其它各个区块链分别相关的各个第二数据，该第二数据用于进行对可认证消息的验证。根据具体的不同验证方式，所述验证节点各不相同，该第二数据也相应地不同，例如在通过简单支付验证(spv)方法进行验证的情况中，所述验证节点为spv节点，该第二数据为相应链中各个区块的区块头。
首先，在步骤S802，从所述中继端接收第一数据和第一位置信息，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述第一位置信息指示所述第一数据在所述第一区块链中的位置。
所述第一数据如上文所述，例如为通过中继端从第一区块链的区块中获取的具有预定标志的收据。中继端在从第一区块链中获取该收据及其位置之后即可中转给第二区块链，从而使得第二区块链中的各个节点获取该收据及其位置，从而使得第二区块链中的记账节点或验证节点等进行下述步骤S804-S808。
步骤S804，基于所述可认证消息中的第一区块链标识，获取与所述第一区块链相关的第二数据。
如上文所述，图4所示协议栈为基于认证过程的分层协议栈，所述第一层协议即用于对发送链标识的认证过程。因此，首先可基于第一层协议中的发送链标识(即第 一区块链标识)，在本地存储的各个第二数据中获取与第一区块链对应的第二数据。由于该协议栈的分层设计，使得在进行该步骤的过程中，仅读取第一层协议的发送链标识字段即可，而不用读取第一层协议中包括的第二层协议的具体内容。
在步骤S806，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证。
在一个实施例中，所述第一数据为第一区块链的第一区块中的第一收据，所述第一位置信息包括第一区块的区块编号和第一收据在第一区块中的收据编号，所述与第一区块链相关的第二数据为第一区块链中的各个区块的区块头。其中，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证首先包括对可认证消息中第一层协议的发送链标识的验证。所述对发送链标识的验证包括，基于所述第一收据、各个区块的区块头和另外获取的第一区块中的与第一收据相关联的默克尔树路径，通过简单支付验证方法(spv验证方法)验证：所述第一收据来自于第一区块链中的第一区块，其中，所述默克尔树路径基于所述第一位置信息获取。该spv验证方法包括以下具体步骤：
计算该第一收据的收据哈希值；
根据上述默克尔树路径，计算该默克尔树的根哈希值；
将计算的根哈希值与第一区块的区块头中的收据树根哈希值进行比较，以确定该第一收据是否在第一区块中。
在一个实施例中，所述spv验证还可以包括，在确定第一收据在第一区块中之后，根据第一区块的所处位置，验证该区块的区块头是否包含在已知最长链中，以确定该第一区块是否经过共识。在一个实施例中，所述区块链标识与区块链中创世块的头哈希值相对应，所述spv验证还可以包括，通过第一区块的区块头中的头哈希值和父哈希值及各个区块的区块头，验证该区块链的创世块的头哈希值是否对应于第一区块链的链标识。
在一个实施例中，参考上文对图4的描述，所述第一收据通过由第二智能合约调用第一智能合约而自动生成的包括图4所示日志的收据，在该情况下，该第一收据可自身证明，可认证消息中的第一账户即为发送该消息的账户。
在一个实施例中，所述第一收据由用户账户(即第一账户)发送交易而存入区块链中，所述可认证消息由用户填入交易数据中，在生成第一收据之后，所述可认证消 息位于所述第一收据中的第一日志中，在该情况中，所述验证还包括对可认证消息中第二层协议中的发送账户的验证，具体是，可基于所述第一日志的发送字段，验证所述第一账户为发送所述可认证消息的账户。
在步骤S808，在验证通过之后，基于所述可认证消息中的第二账户，向所述第二账户提供所述可认证消息。
在一个实施例中，如上文所述，第一区块链中的第二智能合约通过调用第一智能合约向第二区块链中的第三智能合约传递信息，以进行对第三智能合约的调用。在该情况中，第二账户即为第三智能合约的合约账户，该可认证消息中例如为第三智能合约传入参数。从而，向所述第二账户提供所述可认证消息包括，通过以所述可认证消息为传入参数调用第三智能合约，向第二账户提供所述可认证消息。第三智能合约在经调用之后，基于该可认证消息中的第三层协议执行具体的业务过程。可以理解，所述第二账户不限于为智能合约账户，例如，其也可以为用户账户，在该情况中，可通过区块链中常用方法(例如发送交易的方法)由验证节点向该用户账户提供所述可认证消息。
图9示出根据本说明书实施例的一种跨链中转可认证消息的方法流程图，所述方法由中继端执行，所述中继端与至少两个区块链连接，所述至少两个区块链中包括第一区块链和第二区块链，其中，所述第一区块链中预存有经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述中继端同步有与各个区块链分别相关的各个第二数据，所述方法包括：
步骤S902，从所述第一区块链获取所述第一数据和第一位置信息，所述第一位置信息指示第一数据在第一区块链中的位置；
步骤S904，基于所述可认证消息中的第一区块链标识，获取与所述第一区块链相关的第二数据；
步骤S906，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证；
步骤S908，在验证通过的情况中，对所述可认证消息进行数字签名；
步骤S910，基于所述可认证消息中的第二区块链标识，将所述可认证消息及其数字签名发送给所述第二区块链。
在该方法中，中继端为可信节点，或者可以为验证区块链，其可在从第一区块链获取第一数据之后，在本地进行验证，并在验证通过之后进行数字签名，并发送给第二区块链，从而第二区块链可通过中继端的数字签名进行对第一数据的验证，从而简化了第二区块链的验证过程。该方法中的步骤S902和步骤S910可参考上文中对步骤S702和S704的描述，步骤S904和S906可参考上文中对步骤S804和S806的描述，在此不再赘述。
图10示出根据本说明书实施例的一种跨链接收可认证消息的方法流程图，所述跨链接收为由第二区块链的第二账户从其它区块链接收，所述第二区块链与中继端连接，所述中继端还与至少一个其它区块链连接，所述至少一个其它区块链中包括第一区块链，所述第二区块链中预先存储有所述中继端的公钥，所述方法由第二区块链执行，包括：
步骤S1002，从所述中继端接收可认证消息、及所述中继端对所述可认证消息的数字签名，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户；
步骤S1004，使用所述中继端的公钥对所述数字签名进行验证；以及
步骤S1006，在验证通过之后，基于所述可认证消息中的第二账户，向所述第二账户提供所述可认证消息。
图10所示方法与图9所示方法中的中继端相对应，在进行图9所示方法之后，可开始图10所示方法。该方法可由第二区块链中任一节点或客户端执行，该节点(或客户端)本地只需要保存中继端的公钥，即可以进行对可认证消息的验证，因此，不需要如图8所示方案，从中继端接收第一数据，而仅需要接收可认证消息。其中，步骤S1006可参考上文对步骤S808的描述，在此不再赘述。
图11示出根据本说明书实施例的一种跨链发送可认证消息的装置1100，所述跨链发送为从第一区块链的第一账户向其它区块链发送，所述第一区块链与中继端连接，所述中继端还与至少一个其它区块链连接，所述至少一个其它区块链中包括第二区块链， 所述装置部署在所述第一区块链，包括：
存入单元111，配置为，通过所述第一账户向第一区块链中存入经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户；以及
提供单元112，配置为，将所述第一数据和第一位置信息提供给所述中继端，以用于将所述可认证消息提供给所述第二区块链中的所述第二账户，其中，所述第一位置信息指示第一数据在第一区块链中的位置。
在一个实施例中，所述存入单元1101还配置为，通过由所述第一账户调用第一智能合约向第一区块链中存入所述第一数据，其中，所述第一账户在调用第一智能合约时向第一智能合约传入至少以下参数：第二区块链标识、第二账户及消息内容。
图12示出根据本说明书实施例的一种跨链中转可认证消息的装置1200，所述装置部署在中继端，所述中继端与至少两个区块链连接，所述至少两个区块链中包括第一区块链和第二区块链，其中，所述第一区块链中预存有经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述装置包括：
获取单元121，配置为，从所述第一区块链获取所述第一数据和第一位置信息，所述第一位置信息指示第一数据在第一区块链中的位置；以及
发送单元122，配置为，基于所述可认证消息中的第二区块链标识，将所述第一数据和所述第一位置信息发送给所述第二区块链。
在一个实施例中，所述第一数据被标注有预定标志，其中，所述获取单元还配置为，基于所述预定标志从所述第一区块链获取所述第一数据和第一位置信息。
图13示出根据本说明书实施例的一种跨链接收可认证消息的装置1300，所述跨链接收为由第二区块链的第二账户从其它区块链接收，所述第二区块链与中继端连接，所述第二区块链中通过所述中继端同步有与至少一个其它区块链分别相关的至少一个第二数据，其中，所述至少一个其它区块链中包括第一区块链，所述装置部署在第二区块链，包括：
接收单元131，配置为，从所述中继端接收第一数据和第一位置信息，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述第一位置信息指示所述第一数据在所述第一区块链中的位置；
获取单元132，配置为，基于所述可认证消息中的第一区块链标识，获取与所述第一区块链相关的第二数据；
验证单元133，配置为，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证；以及
提供单元134，配置为，在验证通过之后，基于所述可认证消息中的第二账户，向所述第二账户提供所述可认证消息。
在一个实施例中，所述第一数据为第一区块链的第一区块中的第一收据，所述第一位置信息包括第一区块的区块编号和第一收据在第一区块中的收据编号，所述与第一区块链相关的第二数据为第一区块链中的各个区块的区块头，其中，所述验证单元133还配置为，基于所述第一收据、所述各个区块的区块头和第一区块中的与第一收据相关联的默克尔树路径，通过简单支付验证方法验证：所述第一收据来自于第一区块链中的第一区块，其中，所述默克尔树路径基于所述第一位置信息获取。
在一个实施例中，在生成第一收据之后，所述可认证消息位于所述第一收据中的第一日志中，所述验证单元133还配置为，基于所述第一日志的发送字段，验证所述第一账户为发送所述可认证消息的账户。
在一个实施例中，所述第二账户为第三智能合约的合约账户，所述提供单元134还配置为，通过以所述可认证消息为传入参数调用第三智能合约，向第二账户提供所述 可认证消息。
图14示出根据本说明书实施例的一种跨链中转可认证消息的装置1400，所述装置部署在中继端，所述中继端与至少两个区块链连接，所述至少两个区块链中包括第一区块链和第二区块链，其中，所述第一区块链中预存有经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述中继端同步有与各个区块链分别相关的各个第二数据，所述装置包括：
第一获取单元141，配置为，从所述第一区块链获取所述第一数据和第一位置信息，所述第一位置信息指示第一数据在第一区块链中的位置；
第二获取单元142，配置为，基于所述可认证消息中的第一区块链标识，获取与所述第一区块链相关的第二数据；
验证单元143，配置为，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证；
签名单元144，配置为，在验证通过的情况中，对所述可认证消息进行数字签名；以及
发送单元145，配置为，基于所述可认证消息中的第二区块链标识，将所述可认证消息及其数字签名发送给所述第二区块链。
图15示出根据本说明书实施例的一种跨链接收可认证消息的装置1500，所述跨链接收为由第二区块链的第二账户从其它区块链接收，所述第二区块链与中继端连接，所述中继端还与至少一个其它区块链连接，所述至少一个其它区块链中包括第一区块链，所述第二区块链中预先存储有所述中继端的公钥，所述装置部署在第二区块链，包括：
接收单元151，配置为，从所述中继端接收可认证消息、及所述中继端对所述可认证消息的数字签名，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账 户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户；
验证单元152，配置为，使用所述中继端的公钥对所述数字签名进行验证；以及
提供单元153，配置为，在验证通过之后，基于所述可认证消息中的第二账户，向所述第二账户提供所述可认证消息。
本说明书另一方面提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行上述任一项方法。
本说明书另一方面提供一种计算设备，包括存储器和处理器，其特征在于，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现上述任一项方法。
根据本说明书实施例的跨链方案抽象区块链互操作模型，设计一种可认证消息，使得区块链发出的消息可以被其他链认证：消息来自于哪条链，且由链上的哪个身份实体(账号/合约)发出。使得基于此可认证消息，允许进行跨链应用(合约)编程，使开发者更轻易地开发出各种跨链业务、应用，并且该可认证消息保留较高的扩展性，支持叠加协议栈，使各种跨链互操作技术、应用场景都能标准化，另外，该可认证消息可以被异构平台实现，使得区块链仅实现一种跨链适配升级，可以接入多种跨链平台、连接多条链。
需要理解，本文中的“第一”，“第二”等描述，仅仅为了描述的简单而对相似概念进行区分，并不具有其他限定作用。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
本领域普通技术人员应该还可以进一步意识到，结合本文中所公开的实施例描 述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执轨道，取决于技术方案的特定应用和设计约束条件。本领域普通技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执轨道的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (40)

  1. 一种跨链发送可认证消息的方法，所述跨链发送为从第一区块链的第一账户向其它区块链发送，所述第一区块链与中继端连接，所述中继端还与至少一个其它区块链连接，所述至少一个其它区块链中包括第二区块链，所述方法由所述第一区块链执行，包括：
    通过所述第一账户向第一区块链中存入经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户；以及
    将所述第一数据和第一位置信息提供给所述中继端，以用于将所述可认证消息提供给所述第二区块链中的所述第二账户，其中，所述第一位置信息指示第一数据在第一区块链中的位置。
  2. 根据权利要求1所述的方法，其中，通过所述第一账户向第一区块链中存入经共识的第一数据包括，通过由所述第一账户调用第一智能合约向第一区块链中存入所述第一数据，其中，所述第一账户在调用第一智能合约时向第一智能合约传入至少以下参数：第二区块链标识、第二账户及消息内容。
  3. 根据权利要求2所述的方法，其中，所述第一数据被标注有预定标志。
  4. 根据权利要求3所述的方法，其中，所述第一数据为收据，所述收据中包括在执行所述第一智能合约之后生成的日志，所述日志的数据字段为所述可认证消息。
  5. 根据权利要求4所述的方法，其中，所述日志被标注有预定主题，所述预定标志为所述预定主题。
  6. 根据权利要求4所述的方法，所述预定标志为所述第一智能合约的账户标识。
  7. 根据权利要求1所述的方法，其中，所述第一层协议中还包括协议版本号字段和预留字段。
  8. 根据权利要求1所述的方法，其中，所述第二层协议中还包括类型字段，用于指示该可认证消息的使用场景类型。
  9. 根据权利要求8所述的方法，其中，所述类型为以下任一类型：消息类型、远程过程调用类型、发布/订阅类型。
  10. 根据权利要求1所述的方法，其中，所述第三层协议中还包括序号字段，用于在所述第一账户向所述第二账户多次发送可认证消息的情况中表示当前发送序号。
  11. 根据权利要求1所述的方法，其中，所述第一账户为第二智能合约的合约账户。
  12. 一种跨链中转可认证消息的方法，所述方法由中继端执行，所述中继端与至少两个区块链连接，所述至少两个区块链中包括第一区块链和第二区块链，其中，所述第一区块链中预存有经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述方法包括：
    从所述第一区块链获取所述第一数据和第一位置信息，所述第一位置信息指示第一数据在第一区块链中的位置；以及
    基于所述可认证消息中的第二区块链标识，将所述第一数据和所述第一位置信息发送给所述第二区块链。
  13. 根据权利要求12所述的方法，其中，所述第一数据被标注有预定标志，其中，从所述第一区块链获取所述第一数据和第一位置信息包括，基于所述预定标志从所述第一区块链获取所述第一数据和第一位置信息。
  14. 一种跨链接收可认证消息的方法，所述跨链接收为由第二区块链的第二账户从其它区块链接收，所述第二区块链与中继端连接，所述第二区块链中通过所述中继端同步有与至少一个其它区块链分别相关的至少一个第二数据，其中，所述至少一个其它区块链中包括第一区块链，所述方法由第二区块链执行，包括：
    从所述中继端接收第一数据和第一位置信息，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述第一位置信息指示所述第一数据在所述第一区块链中的位置；
    基于所述可认证消息中的第一区块链标识，获取与所述第一区块链相关的第二数据；
    基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对 所述可认证消息进行验证；以及
    在验证通过之后，基于所述可认证消息中的第二账户，向所述第二账户提供所述可认证消息。
  15. 根据权利要求14所述的方法，其中，所述第一数据为第一区块链的第一区块中的第一收据，所述第一位置信息包括第一区块的区块编号和第一收据在第一区块中的收据编号，所述与第一区块链相关的第二数据为第一区块链中的各个区块的区块头，其中，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证包括，基于所述第一收据、所述各个区块的区块头和第一区块中的与第一收据相关联的默克尔树路径，通过简单支付验证方法验证：所述第一收据来自于第一区块链中的第一区块，其中，所述默克尔树路径基于所述第一位置信息获取。
  16. 根据权利要求15所述的方法，所述可认证消息位于所述第一收据中的第一日志中，其中，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证还包括，基于所述第一日志的发送字段，验证所述第一账户为发送所述可认证消息的账户。
  17. 根据权利要求14所述的方法，其中，所述第二账户为第三智能合约的合约账户，向所述第二账户提供所述可认证消息包括，通过以所述可认证消息为传入参数调用第三智能合约，向第二账户提供所述可认证消息。
  18. 一种跨链中转可认证消息的方法，所述方法由中继端执行，所述中继端与至少两个区块链连接，所述至少两个区块链中包括第一区块链和第二区块链，其中，所述第一区块链中预存有经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述中继端同步有与各个区块链分别相关的各个第二数据，所述方法包括：
    从所述第一区块链获取所述第一数据和第一位置信息，所述第一位置信息指示第一数据在第一区块链中的位置；
    基于所述可认证消息中的第一区块链标识，获取与所述第一区块链相关的第二数据；
    基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证；
    在验证通过的情况中，对所述可认证消息进行数字签名；以及
    基于所述可认证消息中的第二区块链标识，将所述可认证消息及其数字签名发送给所述第二区块链。
  19. 一种跨链接收可认证消息的方法，所述跨链接收为由第二区块链的第二账户从其它区块链接收，所述第二区块链与中继端连接，所述中继端还与至少一个其它区块链连接，所述至少一个其它区块链中包括第一区块链，所述第二区块链中预先存储有所述中继端的公钥，所述方法由第二区块链执行，包括：
    从所述中继端接收可认证消息、及所述中继端对所述可认证消息的数字签名，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户；
    使用所述中继端的公钥对所述数字签名进行验证；以及
    在验证通过之后，基于所述可认证消息中的第二账户，向所述第二账户提供所述可认证消息。
  20. 一种跨链发送可认证消息的装置，所述跨链发送为从第一区块链的第一账户向其它区块链发送，所述第一区块链与中继端连接，所述中继端还与至少一个其它区块链连接，所述至少一个其它区块链中包括第二区块链，所述装置部署在所述第一区块链，包括：
    存入单元，配置为，通过所述第一账户向第一区块链中存入经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户；以及
    提供单元，配置为，将所述第一数据和第一位置信息提供给所述中继端，以用于将所述可认证消息提供给所述第二区块链中的所述第二账户，其中，所述第一位置信息指示第一数据在第一区块链中的位置。
  21. 根据权利要求20所述的装置，其中，所述存入单元还配置为，通过由所述第一 账户调用第一智能合约向第一区块链中存入所述第一数据，其中，所述第一账户在调用第一智能合约时向第一智能合约传入至少以下参数：第二区块链标识、第二账户及消息内容。
  22. 根据权利要求21所述的装置，其中，所述第一数据被标注有预定标志。
  23. 根据权利要求22所述的装置，其中，所述第一数据为收据，所述收据中包括在执行所述第一智能合约之后生成的日志，所述日志的数据字段为所述可认证消息。
  24. 根据权利要求23所述的装置，其中，所述日志被标注有预定主题，所述预定标志为所述预定主题。
  25. 根据权利要求23所述的装置，所述预定标志为所述第一智能合约的账户标识。
  26. 根据权利要求20所述的装置，其中，所述第一层协议中还包括协议版本号字段和预留字段。
  27. 根据权利要求20所述的装置，其中，所述第二层协议中还包括类型字段，用于指示该可认证消息的使用场景类型。
  28. 根据权利要求27所述的装置，其中，所述类型为以下任一类型：消息类型、远程过程调用类型、发布/订阅类型。
  29. 根据权利要求20所述的装置，其中，所述第三层协议中还包括序号字段，用于在所述第一账户向所述第二账户多次发送可认证消息的情况中表示当前发送序号。
  30. 根据权利要求20所述的装置，其中，所述第一账户为第二智能合约的合约账户。
  31. 一种跨链中转可认证消息的装置，所述装置部署在中继端，所述中继端与至少两个区块链连接，所述至少两个区块链中包括第一区块链和第二区块链，其中，所述第一区块链中预存有经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述装置包括：
    获取单元，配置为，从所述第一区块链获取所述第一数据和第一位置信息，所述第一位置信息指示第一数据在第一区块链中的位置；以及
    发送单元，配置为，基于所述可认证消息中的第二区块链标识，将所述第一数据和所述第一位置信息发送给所述第二区块链。
  32. 根据权利要求31所述的装置，其中，所述第一数据被标注有预定标志，其中， 所述获取单元还配置为，基于所述预定标志从所述第一区块链获取所述第一数据和第一位置信息。
  33. 一种跨链接收可认证消息的装置，所述跨链接收为由第二区块链的第二账户从其它区块链接收，所述第二区块链与中继端连接，所述第二区块链中通过所述中继端同步有与至少一个其它区块链分别相关的至少一个第二数据，其中，所述至少一个其它区块链中包括第一区块链，所述装置部署在第二区块链，包括：
    接收单元，配置为，从所述中继端接收第一数据和第一位置信息，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述第一位置信息指示所述第一数据在所述第一区块链中的位置；
    获取单元，配置为，基于所述可认证消息中的第一区块链标识，获取与所述第一区块链相关的第二数据；
    验证单元，配置为，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证；以及
    提供单元，配置为，在验证通过之后，基于所述可认证消息中的第二账户，向所述第二账户提供所述可认证消息。
  34. 根据权利要求33所述的装置，其中，所述第一数据为第一区块链的第一区块中的第一收据，所述第一位置信息包括第一区块的区块编号和第一收据在第一区块中的收据编号，所述与第一区块链相关的第二数据为第一区块链中的各个区块的区块头，其中，所述验证单元还配置为，基于所述第一收据、所述各个区块的区块头和第一区块中的与第一收据相关联的默克尔树路径，通过简单支付验证方法验证：所述第一收据来自于第一区块链中的第一区块，其中，所述默克尔树路径基于所述第一位置信息获取。
  35. 根据权利要求34所述的装置，所述可认证消息位于所述第一收据中的第一日志中，其中，所述验证单元还配置为，基于所述第一日志的发送字段，验证所述第一账户为发送所述可认证消息的账户。
  36. 根据权利要求33所述的装置，其中，所述第二账户为第三智能合约的合约账户，所述提供单元还配置为，通过以所述可认证消息为传入参数调用第三智能合约，向第二账户提供所述可认证消息。
  37. 一种跨链中转可认证消息的装置，所述装置部署在中继端，所述中继端与至少两个区块链连接，所述至少两个区块链中包括第一区块链和第二区块链，其中，所述第一区块链中预存有经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户，所述中继端同步有与各个区块链分别相关的各个第二数据，所述装置包括：
    第一获取单元，配置为，从所述第一区块链获取所述第一数据和第一位置信息，所述第一位置信息指示第一数据在第一区块链中的位置；
    第二获取单元，配置为，基于所述可认证消息中的第一区块链标识，获取与所述第一区块链相关的第二数据；
    验证单元，配置为，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证；
    签名单元，配置为，在验证通过的情况中，对所述可认证消息进行数字签名；以及
    发送单元，配置为，基于所述可认证消息中的第二区块链标识，将所述可认证消息及其数字签名发送给所述第二区块链。
  38. 一种跨链接收可认证消息的装置，所述跨链接收为由第二区块链的第二账户从其它区块链接收，所述第二区块链与中继端连接，所述中继端还与至少一个其它区块链连接，所述至少一个其它区块链中包括第一区块链，所述第二区块链中预先存储有所述中继端的公钥，所述装置部署在第二区块链，包括：
    接收单元，配置为，从所述中继端接收可认证消息、及所述中继端对所述可认证消息的数字签名，所述可认证消息满足预定协议栈，所述预定协议栈包括由外向内的第一至第三层协议，其中，第一层协议包括发送区块链标识字段和第二层协议，第二层协议包括发送账户字段和第三层协议，第三层协议包括接收区块链标识字段、接收账户字段和消息内容字段，其中，发送区块链标识、发送账户、接收区块链标识、接收账户字段分别对应于以下字段值：第一区块链标识、第一账户、第二区块链标识、第二账户；
    验证单元，配置为，使用所述中继端的公钥对所述数字签名进行验证；以及
    提供单元，配置为，在验证通过之后，基于所述可认证消息中的第二账户，向所述第二账户提供所述可认证消息。
  39. 一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行权利要求1-19中任一项的所述的方法。
  40. 一种计算设备，包括存储器和处理器，其特征在于，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现权利要求1-19中任一项所述的方法。
PCT/CN2020/071574 2019-06-28 2020-01-11 一种跨链发送可认证消息的方法和装置 WO2020258850A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/786,437 US11336465B2 (en) 2019-06-28 2020-02-10 Sending cross-chain authenticatable messages

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910579567.1A CN110311790B (zh) 2019-06-28 2019-06-28 一种跨链发送可认证消息的方法和装置
CN201910579567.1 2019-06-28

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/786,437 Continuation US11336465B2 (en) 2019-06-28 2020-02-10 Sending cross-chain authenticatable messages

Publications (1)

Publication Number Publication Date
WO2020258850A1 true WO2020258850A1 (zh) 2020-12-30

Family

ID=68078462

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/071574 WO2020258850A1 (zh) 2019-06-28 2020-01-11 一种跨链发送可认证消息的方法和装置

Country Status (4)

Country Link
US (1) US11336465B2 (zh)
CN (2) CN110311790B (zh)
TW (1) TWI733328B (zh)
WO (1) WO2020258850A1 (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11138602B2 (en) 2020-02-03 2021-10-05 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable guarantees
US11182788B2 (en) 2020-02-03 2021-11-23 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable guarantees
US11200570B2 (en) 2020-02-03 2021-12-14 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable guarantees
US11201742B2 (en) 2020-02-03 2021-12-14 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable guarantees
US11212104B2 (en) 2020-02-03 2021-12-28 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable guarantees
US11216807B2 (en) 2020-02-03 2022-01-04 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable guarantees
CN114553884A (zh) * 2022-01-24 2022-05-27 中国科学院计算技术研究所 一种基于按需建域的区块链跨链交互方法及系统

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SG11201903478WA (en) * 2018-11-16 2019-05-30 Alibaba Group Holding Ltd A domain name management scheme for cross-chain interactions in blockchain systems
US11151276B1 (en) * 2019-04-15 2021-10-19 Trend Micro Incorporated Systems and methods for data certificate notarization utilizing bridging from private blockchain to public blockchain
CN110311790B (zh) * 2019-06-28 2020-07-28 阿里巴巴集团控股有限公司 一种跨链发送可认证消息的方法和装置
US11251966B2 (en) 2019-06-28 2022-02-15 Advanced New Technologies Co., Ltd. Sending cross-chain authenticatable messages
US11356282B2 (en) 2019-06-28 2022-06-07 Advanced New Technologies Co., Ltd. Sending cross-chain authenticatable messages
CN111431903B (zh) * 2020-03-25 2022-08-09 北京新创智链科技有限公司 一种跨链中继方法、装置以及计算机可读存储介质
CN112182096A (zh) * 2020-04-02 2021-01-05 支付宝(杭州)信息技术有限公司 跨链数据订阅方法及装置
US11184395B1 (en) * 2020-05-13 2021-11-23 International Business Machines Corporation Cross-network identity provisioning
CN111769957B (zh) * 2020-09-02 2020-12-15 百度在线网络技术（北京）有限公司 区块链跨链查询方法、装置、设备和存储介质
CN112804357B (zh) * 2021-03-30 2021-08-06 支付宝(杭州)信息技术有限公司 一种基于中继设备网络跨链读取数据的方法和装置
CN112804066A (zh) * 2021-03-30 2021-05-14 支付宝(杭州)信息技术有限公司 一种基于中继设备跨链中转消息的方法和装置
CN113676546A (zh) * 2021-03-30 2021-11-19 支付宝(杭州)信息技术有限公司 一种基于中继设备网络跨链中转数据的方法和装置
US11902426B2 (en) * 2021-06-26 2024-02-13 Ceremorphic, Inc. Efficient storage of blockchain in embedded device
CN114465830B (zh) * 2022-04-14 2022-06-24 北京理工大学 一种跨链数据加密方法、装置、设备和存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160330034A1 (en) * 2015-05-07 2016-11-10 Blockstream Corporation Transferring ledger assets between blockchains via pegged sidechains
CN108683630A (zh) * 2018-04-03 2018-10-19 阿里巴巴集团控股有限公司 跨区块链的认证方法及装置、电子设备
CN108712257A (zh) * 2018-04-03 2018-10-26 阿里巴巴集团控股有限公司 跨区块链的认证方法及装置、电子设备
CN110311790A (zh) * 2019-06-28 2019-10-08 阿里巴巴集团控股有限公司 一种跨链发送可认证消息的方法和装置
CN110430235A (zh) * 2019-06-28 2019-11-08 阿里巴巴集团控股有限公司 基于处理模块跨链发送可认证消息的方法和装置
CN110443704A (zh) * 2019-06-28 2019-11-12 阿里巴巴集团控股有限公司 一种跨链发送资源的方法和装置

Family Cites Families (84)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015200511A1 (en) * 2014-06-24 2015-12-30 Virsec Systems, Inc. System and methods for automated detection of input and output validation and resource management vulnerability
KR20180115293A (ko) * 2016-02-23 2018-10-22 엔체인 홀딩스 리미티드 블록체인상의 개체의 안전한 전송을 위한 방법 및 시스템
CN117151853A (zh) * 2016-04-11 2023-12-01 区块链控股有限公司 用于区块链上的安全点对点通信的方法
US11829998B2 (en) 2016-06-07 2023-11-28 Cornell University Authenticated data feed for blockchains
US11182851B2 (en) * 2016-10-20 2021-11-23 International Business Machines Corporation Inter-ledger messaging in a blockchain
US20180137507A1 (en) * 2016-11-14 2018-05-17 International Business Machines Corporation Performing verification on the blockchain for non-blockchain transactions
TW201822088A (zh) 2016-12-01 2018-06-16 碩網資訊股份有限公司 使用區塊鏈技術之跨國交易系統及其方法
WO2018120121A1 (zh) * 2016-12-30 2018-07-05 深圳前海达闼云端智能科技有限公司 区块链权限控制方法、装置及节点设备
US10102265B1 (en) * 2017-04-12 2018-10-16 Vijay K. Madisetti Method and system for tuning blockchain scalability for fast and low-cost payment and transaction processing
US10255342B2 (en) * 2017-04-12 2019-04-09 Vijay K. Madisetti Method and system for tuning blockchain scalability, decentralization, and security for fast and low-cost payment and transaction processing
US10419209B1 (en) * 2017-04-26 2019-09-17 Wells Fargo Bank, N.A. Parallel assurance of blockchain signatures
WO2018214165A1 (zh) * 2017-05-26 2018-11-29 深圳前海达闼云端智能科技有限公司 通信方法、装置、系统、电子设备及计算机可读存储介质
US11394559B2 (en) * 2017-06-02 2022-07-19 Visa International Service Association Methods and systems for ownership verification using blockchain
CN107231299A (zh) * 2017-06-07 2017-10-03 众安信息技术服务有限公司 一种链路由及实现区块链跨链通信的系统
CN107301536B (zh) * 2017-06-12 2019-07-12 腾讯科技（深圳）有限公司 资源转移方法及装置
CN109146677B (zh) 2017-06-14 2021-07-23 深圳区块链金融服务有限公司 并行构建区块链视图的方法、计算机系统和可读存储介质
CN109150943B (zh) * 2017-06-27 2022-03-29 华为技术有限公司 信息的传输方法、装置和系统
US10944546B2 (en) * 2017-07-07 2021-03-09 Microsoft Technology Licensing, Llc Blockchain object interface
US10783733B2 (en) 2017-07-11 2020-09-22 Panasonic Intellectual Property Corporation Of America Electronic voting system and control method
CN107424073A (zh) 2017-07-17 2017-12-01 杭州复杂美科技有限公司 一种跨链数字债权交易的方法
US10735202B2 (en) * 2017-07-24 2020-08-04 International Business Machines Corporation Anonymous consent and data sharing on a blockchain
US11146380B2 (en) 2017-08-03 2021-10-12 Parity Technologies Ltd. Methods and systems for a heterogeneous multi-chain framework
US10938567B2 (en) 2017-09-12 2021-03-02 Kadena Llc Parallel-chain architecture for blockchain systems
US20190228409A1 (en) * 2017-09-13 2019-07-25 Vijay Madisetti Transaction Pools Using Smart Contracts and Blockchains
US10460283B2 (en) * 2017-09-13 2019-10-29 Vijay Madisetti Smart contract optimization for multiparty service or product ordering system
WO2019060567A1 (en) 2017-09-20 2019-03-28 Swoop Ip Holdings Llc AUTHENTICATION BASED ON AN ELECTRONIC MAIL FOR OPENING ACCOUNT SESSION, CREATING ACCOUNT AND SECURITY FOR TRANSACTIONS WITHOUT PASSWORD
US11121870B2 (en) * 2017-10-12 2021-09-14 Mastercard International Incorporated Method and system for interacting public and private blockchains with controlled participation
US11463241B2 (en) 2017-10-20 2022-10-04 Hewlett Packard Enterprise Development Lp Transmitting or receiving blockchain information
US11165862B2 (en) * 2017-10-24 2021-11-02 0Chain, LLC Systems and methods of blockchain platform for distributed applications
US10868865B2 (en) 2017-11-20 2020-12-15 Moshe Shadmon System and apparatus to manage data using a peer-to-peer network and the blockchain
CN108009811B (zh) 2017-11-30 2021-06-04 中国人民解放军国防科技大学 一种面向云际计算环境价值交换的跨链通信方法
US20190311357A1 (en) * 2018-04-04 2019-10-10 Vijay Madisetti Method and System for Exchange of Value or Tokens Between Blockchain Networks
US10853772B2 (en) * 2018-04-04 2020-12-01 Vijay K. Madisetti Method and system for exchange of value or tokens between blockchain networks
US20190188657A1 (en) 2017-12-19 2019-06-20 Mastercard International Incorporated Method and system for outside guarantees for a blockchain transaction
EP3503012A1 (en) * 2017-12-20 2019-06-26 Accenture Global Solutions Limited Analytics engine for multiple blockchain nodes
CN108573016A (zh) * 2017-12-25 2018-09-25 北京金山云网络技术有限公司 一种数据一致性检查方法、装置、设备和存储介质
US11551212B2 (en) * 2018-01-10 2023-01-10 Rajeev Malhotra Methods and systems for management of a blockchain-based computer-enabled networked ecosystem
CN108269190A (zh) 2018-01-17 2018-07-10 深圳四方精创资讯股份有限公司 基于跨链中继平台的跨链方法及其系统
US10298585B1 (en) * 2018-01-26 2019-05-21 Accenture Global Solutions Limited Blockchain interoperability
CN108418795B (zh) * 2018-01-30 2019-05-28 百度在线网络技术（北京）有限公司 跨区块链的数据访问方法、装置、系统及计算机可读介质
EP3522088B1 (en) 2018-02-05 2022-03-16 Nokia Technologies Oy Securing blockchain access through a gateway
CN108389129B (zh) 2018-02-27 2020-12-04 创新先进技术有限公司 基于区块链的交易执行方法及装置、电子设备
US10878429B2 (en) 2018-03-28 2020-12-29 Konstantinos Bakalis Systems and methods for using codes and images within a blockchain
CA3038757A1 (en) * 2018-04-02 2019-10-02 Royal Bank Of Canada System and method for cryptographic transactions
CN108629583A (zh) 2018-04-16 2018-10-09 上海分赋信息科技有限公司 基于分布式技术实现数字资产在映射链上的映射系统及相应方法
US11563557B2 (en) * 2018-04-24 2023-01-24 International Business Machines Corporation Document transfer processing for blockchains
US20190385156A1 (en) * 2018-04-27 2019-12-19 Bing Liu Decentralized Crypto Token Swap Platform on Mobile Device Apps
US11030217B2 (en) * 2018-05-01 2021-06-08 International Business Machines Corporation Blockchain implementing cross-chain transactions
US11194837B2 (en) * 2018-05-01 2021-12-07 International Business Machines Corporation Blockchain implementing cross-chain transactions
US11481761B2 (en) * 2018-06-03 2022-10-25 VVOW Company Limited Peer-to-peer cryptocurrency and crypto asset trading platform
CN108810137B (zh) 2018-06-11 2021-10-01 西安纸贵互联网科技有限公司 一种联盟区块链系统
CN109035012B (zh) 2018-06-11 2020-11-17 西安纸贵互联网科技有限公司 一种区块链系统的跨链处理方法和计算机可读存储介质
EP3582521A1 (de) 2018-06-14 2019-12-18 Siemens Aktiengesellschaft Vorrichtung und verfahren zum einrichtung und/oder bereitstellen einer arbeitsumgebung, insbesondere eingesetzt in einer maschinen economy umgebung
DK3584654T3 (da) 2018-06-19 2020-08-10 Siemens Ag Hierarkisk fordelt ledger
CN112639737A (zh) 2018-07-09 2021-04-09 瑞典爱立信有限公司 用于在云提供商联盟中使用智能合同和区块链来管理云服务的方法和设备
TWI663865B (zh) 2018-07-09 2019-06-21 現代財富控股有限公司 基於跨鏈架構的身分識別管理系統及其方法
CN109063016A (zh) 2018-07-11 2018-12-21 物数（上海）信息科技有限公司 区块链数据储存方法、装置、电子设备、存储介质
US20200036514A1 (en) * 2018-07-27 2020-01-30 TNT Blockchain Inc. Data recording and retrieval using an operational token
US11356443B2 (en) * 2018-07-30 2022-06-07 Hewlett Packard Enterprise Development Lp Systems and methods for associating a user claim proven using a distributed ledger identity with a centralized identity of the user
CN109102261A (zh) * 2018-08-02 2018-12-28 刘卓 基于赛博钞票的去中心化、安全、省电的加密货币
CA3109435A1 (en) 2018-08-24 2020-02-27 Iq Universe Inc. Provenance and illicit product control system
CN109325762B (zh) 2018-08-30 2020-07-10 杭州复杂美科技有限公司 平行链跨链交易方法、设备和存储介质
US11789933B2 (en) * 2018-09-06 2023-10-17 Docusign, Inc. System and method for a hybrid contract execution environment
US10841213B2 (en) * 2018-10-15 2020-11-17 Moac Blockchain Tech Inc Apparatus and method for communication between chains in a decentralized system
CN110009334B (zh) * 2018-11-07 2020-04-28 阿里巴巴集团控股有限公司 一种构建梅克尔树、简单支付验证方法及装置
CN110011800B (zh) * 2018-11-07 2020-04-14 阿里巴巴集团控股有限公司 一种区块链数据读取方法及装置
CN110046517B (zh) * 2018-11-07 2020-05-05 阿里巴巴集团控股有限公司 一种对写入区块链的交易进行隐匿的方法及装置
CN110008686B (zh) * 2018-11-16 2020-12-04 创新先进技术有限公司 跨区块链的数据处理方法、装置、客户端、区块链系统
SG11201903478WA (en) 2018-11-16 2019-05-30 Alibaba Group Holding Ltd A domain name management scheme for cross-chain interactions in blockchain systems
CN109600367A (zh) 2018-12-07 2019-04-09 众安信息技术服务有限公司 用于实现跨链消息处理的方法以及设备
CN109379381B (zh) * 2018-12-07 2021-06-15 深圳市智税链科技有限公司 区块链系统的数据管理方法、装置、介质及电子设备
CN109815657B (zh) 2018-12-14 2022-10-28 深圳壹账通智能科技有限公司 基于联盟链的身份认证方法、装置、计算机可读存储介质及终端设备
CN109784881A (zh) 2018-12-29 2019-05-21 广州蓝石信息技术有限公司 基于去中心化网关的通用跨链支付方案
US20200242595A1 (en) 2019-01-30 2020-07-30 Salesforce.Com, Inc. Systems, methods, and apparatuses utilizing a blended blockchain ledger in a cloud service to address local storage
US11563561B2 (en) 2019-01-31 2023-01-24 Megachain Inc. Systems and methods for linkage data elements
CN109889382B (zh) * 2019-02-20 2020-07-21 中国互联网络信息中心 一种基于区块链混合共识的域名信息维护系统
US10901983B2 (en) * 2019-03-01 2021-01-26 Wanchain Ltd. System and method for universal blockchain interoperability
CN109933629B (zh) * 2019-03-15 2021-07-30 腾讯科技（深圳）有限公司 数据同步方法、装置、计算机设备以及可读存储介质
US11055277B2 (en) * 2019-04-04 2021-07-06 Advanced New Technologies Co., Ltd. Integrity verification method, apparatus, and system and device for data in a blockchain-type ledger
US20200327616A1 (en) 2019-04-10 2020-10-15 Blockadoc, LLC Partially private and verifiable data exchange
US11360946B2 (en) 2019-05-17 2022-06-14 International Business Machines Corporation Tracking data transfers
CN110430162B (zh) 2019-06-28 2020-11-24 创新先进技术有限公司 一种跨链发送可认证消息的方法和装置
US11356282B2 (en) 2019-06-28 2022-06-07 Advanced New Technologies Co., Ltd. Sending cross-chain authenticatable messages
US11251966B2 (en) 2019-06-28 2022-02-15 Advanced New Technologies Co., Ltd. Sending cross-chain authenticatable messages

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160330034A1 (en) * 2015-05-07 2016-11-10 Blockstream Corporation Transferring ledger assets between blockchains via pegged sidechains
CN108683630A (zh) * 2018-04-03 2018-10-19 阿里巴巴集团控股有限公司 跨区块链的认证方法及装置、电子设备
CN108712257A (zh) * 2018-04-03 2018-10-26 阿里巴巴集团控股有限公司 跨区块链的认证方法及装置、电子设备
CN110311790A (zh) * 2019-06-28 2019-10-08 阿里巴巴集团控股有限公司 一种跨链发送可认证消息的方法和装置
CN110430235A (zh) * 2019-06-28 2019-11-08 阿里巴巴集团控股有限公司 基于处理模块跨链发送可认证消息的方法和装置
CN110443704A (zh) * 2019-06-28 2019-11-12 阿里巴巴集团控股有限公司 一种跨链发送资源的方法和装置

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11138602B2 (en) 2020-02-03 2021-10-05 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable guarantees
US11182788B2 (en) 2020-02-03 2021-11-23 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable guarantees
US11200570B2 (en) 2020-02-03 2021-12-14 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable guarantees
US11201742B2 (en) 2020-02-03 2021-12-14 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable guarantees
US11212104B2 (en) 2020-02-03 2021-12-28 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable guarantees
US11216807B2 (en) 2020-02-03 2022-01-04 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable guarantees
US11580539B2 (en) 2020-02-03 2023-02-14 Alipay (Hangzhou) Information Technology Co., Ltd. Blockchain-based trustable guarantees
CN114553884A (zh) * 2022-01-24 2022-05-27 中国科学院计算技术研究所 一种基于按需建域的区块链跨链交互方法及系统

Also Published As

Publication number Publication date
TW202101439A (zh) 2021-01-01
CN112003703A (zh) 2020-11-27
US11336465B2 (en) 2022-05-17
US20210036857A1 (en) 2021-02-04
CN110311790B (zh) 2020-07-28
CN110311790A (zh) 2019-10-08
CN112003703B (zh) 2023-08-22
TWI733328B (zh) 2021-07-11

Similar Documents

Publication Publication Date Title
WO2020258850A1 (zh) 一种跨链发送可认证消息的方法和装置
WO2020258848A1 (zh) 一种跨链发送资源的方法和装置
WO2020258846A1 (zh) 一种跨链发送可认证消息的方法和装置
WO2020258847A1 (zh) 基于处理模块跨链发送可认证消息的方法和装置
US10938565B2 (en) Method and apparatus for inter-blockchain transmission of authenticable message
US11336451B2 (en) Cross-blockchain resource transmission
US11343103B2 (en) Sending cross-chain authenticatable messages
CN111163129B (zh) 一种基于跨链网络的资源处理方法及装置
US20190190719A1 (en) Primary and secondary blockchain device
CN110009494B (zh) 一种监控区块链中的交易内容的方法及装置
CN112005264A (zh) 实施跨链事务的区块链
US20220269670A1 (en) Data processing method and apparatus, computer device, and storage medium
WO2020258849A1 (zh) 一种跨链发送可认证消息的方法和装置
CN112862612B (zh) 一种跨链发送资源的方法和装置
CN117633903A (zh) 基于区块链网络的数据处理方法、相关设备及产品
CN117495559A (zh) 一种交易处理方法、装置、设备及存储介质
CN117896130A (zh) 一种工业互联网数据访问控制方法、装置、设备及介质
CN117395005A (zh) 基于区块链的身份认证系统、方法及计算机设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20833557

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20833557

Country of ref document: EP

Kind code of ref document: A1