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

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

Info

Publication number
WO2020258846A1
WO2020258846A1 PCT/CN2020/071367 CN2020071367W WO2020258846A1 WO 2020258846 A1 WO2020258846 A1 WO 2020258846A1 CN 2020071367 W CN2020071367 W CN 2020071367W WO 2020258846 A1 WO2020258846 A1 WO 2020258846A1
Authority
WO
WIPO (PCT)
Prior art keywords
blockchain
message
data
account
sending
Prior art date
Application number
PCT/CN2020/071367
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,949 priority Critical patent/US11251966B2/en
Publication of WO2020258846A1 publication Critical patent/WO2020258846A1/zh
Priority to US17/235,706 priority patent/US11343103B2/en

Links

Images

Classifications

    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • 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
    • 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.
  • the embodiments of this specification aim to provide a more effective scheme for sending certifiable messages across chains to solve the deficiencies in the prior art.
  • one aspect of this specification provides a method for sending an authenticated message across chains.
  • the cross-chain sending is sending from the first account of the first blockchain to the outside of the chain.
  • the relay terminal is connected, the method is executed by the first blockchain, and includes:
  • first data includes a verifiable message
  • verifiable message includes at least the following fields that satisfy a predetermined protocol: Sending blockchain ID, sending account, receiving object information and message content, where the sending blockchain ID and sending account fields correspond to the following field values: first blockchain ID, first account; and
  • the first data and the first location information are provided to the relay terminal for providing the attestable message to the receiving object, wherein the first location information indicates that the first data is in the first The location in the blockchain, where the relay terminal is connected to the system where the receiving object is located.
  • 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: receiving object information 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 attestable message further includes a protocol version number field and a reserved field.
  • the attestable message further includes a type field, which is used to indicate the usage scenario type of the attestable message.
  • the type is any of the following types: message type, remote procedure call type, publish/subscribe type.
  • the certifiable message further includes a sequence number field, which is used to indicate the current sending sequence number when the first account sends the certifiable message to the same recipient multiple times.
  • the first account is a contract account of the second smart contract.
  • the relay terminal is further connected to the second blockchain, and the receiving object information field includes a receiving blockchain identification field and a receiving account field, which are respectively connected with the second blockchain identification and the second blockchain identification field. Corresponds to the second account in the blockchain.
  • Another aspect of this specification provides a method for transferring certifiable messages across chains.
  • the method is executed by a relay terminal connected to a first blockchain, wherein the first blockchain is pre-stored There is consensus first data, wherein, the first data includes an certifiable message, and the certifiable message includes at least the following fields that satisfy a predetermined protocol: sending block chain identification, sending account, receiving object information and message Content, wherein the sending block chain identification and sending account fields respectively correspond to the following field values: the first block chain identification and the first account, the method includes:
  • the first data and the first location information are sent to the system where the receiving object is located, wherein the relay terminal is connected to the system.
  • 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 cross-chain reception of certifiable messages.
  • the cross-chain reception is received by at least one object in a second system from other blockchains.
  • the second system uses the relay
  • the terminal synchronizes at least one second data respectively related to at least one other block chain, wherein the at least one other block chain includes the first block chain, and the method is executed by the second block chain and includes:
  • the first data and the first location information are received from the relay terminal, where the first data includes a certifiable message, and the certifiable message includes at least the following fields satisfying a predetermined protocol: sending block chain identification, Sending account, receiving object information, and message content, where the sending blockchain identifier and sending account fields correspond to the following field values: first blockchain identifier, first account, and the first location information indicates the first The position of the data in the sending blockchain, and the receiving object information field corresponds to the second system identifier and the at least one object;
  • the certifiable message is provided to the at least one object.
  • 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 system is a second blockchain
  • the at least one object is a second account in the second blockchain
  • the second account is a contract account of a third smart contract.
  • Providing the verifiable message by the second account includes providing the verifiable message to the second account by invoking a third smart contract with the verifiable message as an incoming parameter.
  • Another aspect of this specification provides a method for transferring certifiable messages across chains.
  • the method is executed by a relay terminal connected to a first blockchain, wherein the first blockchain is pre-stored There is consensus first data, wherein, the first data includes an certifiable message, and the certifiable message includes at least the following fields that satisfy a predetermined protocol: sending block chain identification, sending account, receiving object information and message Content, where the sending block chain identification and sending account fields respectively correspond to the following field values: the first block chain identification, the first account, and the relay terminal synchronizes with each block chain corresponding to its connection Second data, the method includes:
  • the verifiable message and its digital signature are sent to the system where the receiver is located, wherein the relay terminal is connected to the system.
  • Another aspect of this specification provides a method for cross-chain reception of certifiable messages.
  • the cross-chain reception is received by at least one object in a second system from another blockchain, and the second system is connected to a relay terminal, The relay terminal is also connected to the first blockchain, and the public key of the relay terminal is pre-stored in the second blockchain.
  • the method executed by the second system includes:
  • the verifiable message includes at least the following fields satisfying a predetermined protocol: sending a blockchain identifier, Sending account, receiving object information, and message content, where the sending block chain identifier and sending account field correspond to the following field values: the first blockchain identifier, the first account, the receiving object information field and the second The system identifier corresponds to the at least one object;
  • the certifiable message is provided to the at least one object.
  • Another aspect of this specification provides a device for sending certifiable messages across chains.
  • the cross-chain sending is sent from the first account of the first blockchain to the outside of the chain, and the first blockchain is connected to the relay end.
  • the device deployed on the first blockchain includes:
  • the deposit unit is configured to deposit the consensus first data into the first blockchain through the first account, wherein the first data includes a verifiable message, and the verifiable message includes at least Meet the following fields of the predetermined agreement: sending blockchain ID, sending account, receiving object information and message content, where the sending blockchain ID and sending account fields correspond to the following field values: first blockchain ID, first Account; and
  • a providing unit configured to provide the first data and first location information to the relay terminal for providing the attestable message to the receiving object, wherein the first location information indicates The position of the first data in the first blockchain, and the relay terminal is connected to the system where the receiving object is located.
  • 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 calling the first smart contract, at least the following parameters are passed to the first smart contract: receiving object information and message content.
  • Another aspect of this specification provides a device for transferring certifiable messages across chains.
  • the device is deployed at a relay end, and the relay end is connected to a first blockchain, wherein the first blockchain is pre-stored There is consensus first data, wherein, the first data includes an certifiable message, and the certifiable message includes at least the following fields that satisfy a predetermined protocol: sending block chain identification, sending account, receiving object information and message The content, wherein the sending block chain identification and sending account fields respectively correspond to the following field values: the first block chain identification, the first account, and the device includes:
  • An acquiring unit configured to acquire 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 system where the receiving object is located based on the receiving object information in the certifiable message, wherein the relay terminal is connected to the system.
  • 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 a device for cross-chain reception of certifiable messages.
  • the cross-chain reception is received by at least one object in a second system from other blockchains.
  • the second system uses the relay
  • the terminal synchronizes with at least one second data respectively related to at least one other blockchain, where the at least one other blockchain includes the first blockchain, and the device deployed in the second system 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, and the certifiable message includes at least the following fields satisfying a predetermined protocol: Sending blockchain identification, sending account, receiving object information and message content, where the sending blockchain identification and sending account fields correspond to the following field values: first blockchain identification, first account, and the first location Information indicates the position of the first data in the sending blockchain, and the receiving object information field corresponds to the second system identifier and the at least one object;
  • 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 provide the certifiable message to the at least one object based on the received object information in the certifiable 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 system is a second blockchain
  • the at least one object is a second account in the second blockchain
  • the second account is a contract account of a third smart contract
  • the providing unit is further configured to provide the certifiable message to the second account by invoking a third smart contract with the certifiable message as an incoming parameter.
  • the device for transferring certifiable messages across chains.
  • the device is deployed at a relay end, and the relay end is connected to a first blockchain, wherein the first blockchain is pre-stored There is consensus first data, wherein, the first data includes an certifiable message, and the certifiable message includes at least the following fields that satisfy a predetermined protocol: sending block chain identification, sending account, receiving object information and message Content, where the sending block chain identification and sending account fields respectively correspond to the following field values: the first block chain identification, the first account, and the relay terminal synchronizes with each block chain corresponding to its connection Second data, the device includes:
  • a first acquiring unit configured to acquire 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 is configured to acquire second data related to the first blockchain based on the first blockchain identifier in the attestable 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 system where the recipient is located based on the recipient information in the verifiable message, wherein the relay terminal is connected to the system.
  • Another aspect of this specification provides a device for cross-chain reception of certifiable messages.
  • the cross-chain reception is received by at least one object in a second system from another blockchain, and the second system is connected to a relay end,
  • the relay terminal is also connected to the first blockchain, the public key of the relay terminal is pre-stored in the second blockchain, and the device is deployed in the second system, including:
  • the receiving unit is configured to receive a verifiable message from the relay terminal and a digital signature of the verifiable message by the relay terminal, wherein the verifiable message includes at least the following fields satisfying a predetermined protocol: Sending blockchain identification, sending account, receiving object information and message content, where the sending blockchain identification and sending account fields correspond to the following field values: first blockchain identification, first account;
  • a verification unit configured to verify the digital signature using the public key of the relay terminal
  • the providing unit is configured to provide the certifiable message to the at least one object based on the received object information in the certifiable 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
  • Fig. 2 shows 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 method for cross-chain transfer of certifiable messages according to an embodiment of this specification
  • Fig. 5 shows a method for receiving certifiable messages across chains according to an embodiment of this specification
  • Fig. 6 shows a method for transferring certifiable messages across chains according to an embodiment of this specification
  • Fig. 7 shows a method for receiving certifiable messages across chains according to an embodiment of this specification
  • FIG. 8 shows a sequence diagram of sending an authenticated message from the first account of the first blockchain to the second account of the second blockchain
  • FIG. 9 shows an apparatus 900 for sending an authenticated message across chains according to an embodiment of the present specification
  • FIG. 10 shows an apparatus 1000 for transferring certifiable messages across chains according to an embodiment of the present specification
  • FIG. 11 shows a cross-chain device 1100 for receiving authenticated messages according to an embodiment of this specification
  • FIG. 12 shows an apparatus 1200 for transferring certifiable messages across chains according to an embodiment of the present specification
  • FIG. 13 shows an apparatus 1300 for receiving an authenticated 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.
  • account A in the first blockchain wants to send information to 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 method for sending an authenticated message across chains according to an embodiment of the present specification.
  • the cross-chain sending is sending from the first account of the first blockchain to the outside of the chain.
  • the relay terminal is connected, the method is executed by the first blockchain, and includes:
  • Step S202 Depositing the consensus first data into the first blockchain through the first account, where the first data includes a verifiable message, and the verifiable message includes at least a The following fields: sending blockchain ID, sending account, recipient information and message content, where the sending blockchain ID and sending account fields correspond to the following field values: first blockchain ID, first account; and
  • Step S204 Provide the first data and the first location information to the relay terminal, so as to provide the attestable message to the receiving object, wherein the first location information indicates the first data At the position in the first blockchain, the relay terminal is connected to the system where the receiving object is located.
  • the receiving object is, for example, the second account in the second blockchain, and the system where the receiving object is located is the second blockchain.
  • the second system is not limited to another blockchain, and it may also be an off-chain channel, an off-chain application, etc., for example.
  • the recipient is not limited to one account, and it may also be a group, for example, and the group may include multiple accounts.
  • the first block chain and the second block chain can be any block chain, such as the Bitcoin chain, the Ethereum chain, etc., which transmit information through a verifiable message with a uniform format. Therefore, the embodiment of this specification is for the block The chain type and specific application scenarios are not particularly limited.
  • 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.
  • step S202 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 includes at least meeting a predetermined protocol
  • the receiving object information is also different accordingly.
  • the receiving object information may include the chain identifier of the other blockchain, the group identifier of the group, or may also include each group in the group.
  • the receiving object information may include the identification of the off-chain channel, the identification of the object, and so on.
  • the receiving object is the second account in the second blockchain, so that the receiving object information includes the receiving blockchain identifier (ie, the second blockchain) and the receiving account (ie, the first 2. Account), the following will take this situation as an example for detailed description.
  • 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 data, wherein the first account passes at least the following parameters to the first smart contract when invoking the first smart contract: receiving object information (ie, the second blockchain identifier and the 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 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 And the message content.
  • the deposit function obtains its account (ie the first account) from the second smart contract that made the call, and passes in the first account, the preset chain identifier of the first blockchain, and when it is called
  • the parameters ie, the second blockchain ID, the second account, and the message content
  • a verifiable message in a predetermined format (ie, a predetermined protocol), and output as a function result, so that the 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 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. In a block of the blockchain, for example, the receipt can be found by using the contract identifier of the first smart contract as a predetermined mark. In one embodiment, 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. It can be understood that in the case where 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.
  • the verifiable message includes at least the following fields that satisfy the predetermined agreement: sending chain identification (i.e., the first blockchain identification), sending account (i.e., the contract account of the second smart contract), and receiving chain identification (i.e., the second zone) Blockchain identification), receiving account (that is, the contract account of the third smart contract, that is, the second account), and message content (for example, the incoming parameters of the third smart contract).
  • sending chain identification i.e., the first blockchain identification
  • sending account i.e., the contract account of the second smart contract
  • receiving chain identification i.e., the second zone
  • Blockchain identification i.e., the second zone
  • the attestable message further includes a protocol version number field and a reserved field.
  • the specific version of the protocol is determined by the protocol version number field.
  • the reserved field is a reserved empty field.
  • the attestable message may further include a type field, which is used to indicate the usage scenario type of the attestable message, so that different message contents in different scenarios can be distinguished by the type field. 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 scene type is, for example, any of the following types: message type, remote procedure call type, publish/subscribe type, transfer type, etc.
  • the certifiable message further includes a sequence number field, which is used to indicate the current sending sequence number when the first account sends the certifiable message to, for example, 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 to the first smart contract as input parameters when the account calls the first smart contract, so that the first smart contract Based on these input parameters, the save function can output an authenticated message containing the values of these fields.
  • 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 attestable message to the receiving object, wherein the first location information indicates the first The position of the data in the first blockchain, and the relay terminal is connected to the system where the receiving object is located.
  • the first data may be provided to the relay terminal through different methods.
  • the relay terminal itself is a node in the first blockchain and the second blockchain, so that the relay terminal can store locally
  • the first data is acquired from the data (such as block, state tree) and the first location data is acquired at the same time.
  • the first location information indicates the location of the first data in the blockchain, for example, when the first data is In the case of a receipt, the first location information includes the number of the block 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. Therefore, 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, for example, the second blockchain This process will be described in detail below.
  • Fig. 4 shows a method for transferring certifiable messages across chains according to an embodiment of the present specification.
  • the method is executed by a relay end connected to a first blockchain, wherein the first zone
  • the consensus first data is pre-stored in the block chain, where the first data includes a verifiable message, and the verifiable message includes at least the following fields that satisfy a predetermined protocol: send block chain identifier, send account, receive Object information and message content, where the sending blockchain identifier and sending account fields correspond to the following field values: first blockchain identifier and first account respectively.
  • the method includes:
  • Step S402 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 S404 Send the first data and the first location information to the system where the recipient is located based on the recipient information in the certifiable message, wherein the relay terminal is connected to the system.
  • the above-mentioned consensus first data is stored in the first blockchain, so that the method can be executed.
  • the 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, for example, the second block.
  • the transfer end between the chains that is, it does not verify the data, it is only used for the transfer of the data, and is not responsible for the authenticity and integrity of the data.
  • 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 transfer information across the chain.
  • the corresponding receipt will include the first smart contract.
  • the account of the contract through the account based on the first smart contract, the receipt can be found from the block as the first data, and the block ID of the receipt can be determined, the receipt number of the receipt in the block, etc. 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 S404 the first data and the first location information are sent to the system where the recipient is located based on the recipient information in the certifiable message, where the relay terminal is connected to the system.
  • the relay terminal after the relay terminal obtains the first data and the first location information, for example, the first data is the above Invoking the receipt of the first smart contract, the relay terminal finds a specific log from the receipt through the first smart contract account or the predetermined subject of the log, and obtains an authenticateable message from the data field of the specific log. Based on a predetermined protocol, it can be determined that the "second block chain 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 second block chain.
  • 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. 5 shows a method for cross-chain receiving certifiable messages according to an embodiment of the present specification.
  • the cross-chain reception is received by at least one object in the second system from other blockchains.
  • the relay terminal synchronizes at least one second data respectively related to at least one other blockchain, where the at least one other blockchain includes the first blockchain, and the method is executed by the second system, include:
  • Step S502 Receive first data and first location information from the relay terminal, where the first data includes a verifiable message, and the verifiable message includes at least the following fields that satisfy a predetermined protocol: sending block Chain identification, sending account, receiving object information and message content, where the sending block chain identification and sending account fields respectively correspond to the following field values: the first blockchain identification, the first account, and the first location information indicates The position of the first data in the sending blockchain, and the receiving object information field corresponds to the second system identifier and the at least one object;
  • Step S504 Obtain second data related to the first blockchain based on the first blockchain identifier in the verifiable message
  • Step S506 verifying the verifiable message based on the second data related to the first blockchain, the first data, and the first location information;
  • Step S508 based on the received object information in the attestable message, provide the at least one object with the attestable message.
  • the method shown in FIG. 5 corresponds to the relay end in the method shown in FIG. 4. After the method shown in FIG. 4 is performed, the method shown in FIG. 5 can be started.
  • the receiving object in the case where the receiving object is the second account in the second blockchain, the receiving object information field includes a receiving blockchain identification field and a receiving account field.
  • 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 in the case of verification through a simple payment verification (spv) method, 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 S502 first data and first location information are received from the relay terminal, where the first data includes an certifiable message, and the certifiable message includes at least the following fields satisfying a predetermined protocol: Sending blockchain identification, sending account, receiving object information and message content, where the sending blockchain identification and sending account fields correspond to the following field values: first blockchain identification, first account, and the first location
  • the information indicates the position of the first data in the sending blockchain, and the receiving object information field corresponds to the second system identifier and the at least one object.
  • 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 S504-S508.
  • step S504 based on the first blockchain identifier in the attestable message, second data related to the first blockchain is acquired.
  • the verifiable message includes the first blockchain identifier. Therefore, after receiving the first data, the first zone can be obtained from the sending blockchain identifier field in the verifiable message in the first data. Block chain identification, so as to obtain the second data related to the first block chain locally.
  • step S506 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, 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 obtained separately.
  • the Merkel tree path associated with a receipt is verified by a simple payment verification method (spv verification method): the first receipt comes from the first block in the first blockchain, wherein the Merkel tree The 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 log shown in FIG. 3.
  • 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. In this case, based on the sending field of the first log, it can be verified that the first account is the account that sent the verifiable message.
  • step S508 the at least one object is provided with the attestable message based on the received object information in the attestable message.
  • the second smart contract in the first blockchain calls the first smart contract to the second account.
  • the third smart contract in the block chain transmits information to call 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 information 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. 6 shows a method for transferring certifiable messages across chains according to an embodiment of the present specification.
  • the method is executed by a relay terminal, and the relay terminal is connected to a first blockchain, wherein the first zone
  • the consensus first data is pre-stored in the block chain, where the first data includes a verifiable message, and the verifiable message includes at least the following fields that satisfy a predetermined protocol: send block chain identifier, send account, receive Object information and message content, where the sending blockchain identifier and sending account fields correspond to the following field values: the first blockchain identifier, the first account, and the relay terminal synchronizes with each area corresponding to its connection.
  • the method includes:
  • Step S602 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 S604 Obtain second data related to the first blockchain based on the first blockchain identifier in the verifiable message
  • Step S606 verify the verifiable message based on the first data, the second data related to the first blockchain, and the first location information;
  • Step S608 in the case of passing the verification, digitally sign the verifiable message
  • Step S610 based on the recipient information in the certifiable message, send the certifiable message and its digital signature to the system where the recipient is located, wherein the relay terminal is connected to the system.
  • 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 S602 and step S610 in the method refer to the above description of steps S402 and S404, and for steps S604 and S606, refer to the above description of steps S504 and S506, which will not be repeated here.
  • Fig. 7 shows a method for cross-chain receiving certifiable messages according to an embodiment of this specification.
  • the cross-chain reception is received by at least one object in the second system from other blockchains.
  • the relay end is connected, the relay end is also connected to the first block chain, and the public key of the relay end is pre-stored in the second block chain.
  • the method is executed by the second system and includes:
  • Step S702 receiving a verifiable message from the relay terminal and a digital signature of the verifiable message by the relay terminal, wherein the verifiable message includes at least the following fields satisfying a predetermined protocol: sending block Chain identification, sending account, receiving object information and message content, where the sending blockchain identification and sending account fields correspond to the following field values: first blockchain identification, first account, and the receiving object information field
  • the second system identifier corresponds to the at least one object;
  • Step S704 using the public key of the relay terminal to verify the digital signature
  • Step S706 Based on the received object information in the attestable message, the at least one object is provided with the attestable message.
  • the method shown in FIG. 7 corresponds to the relay terminal in the method shown in FIG. 6. After the method shown in FIG. 6 is performed, the method shown in FIG. 7 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 5, the first data is received from the relay end, and only the authenticable message needs to be received. For step S706, reference may be made to the above description of step S508, which will not be repeated here.
  • FIG. 8 shows a sequence diagram of sending an authenticateable message from the first account of the first blockchain to the second account of the second blockchain.
  • the first account deposits the first data including the AM message into the first blockchain.
  • the first blockchain uses the first data and its content in the first block.
  • the position information in the chain is provided to the relay end.
  • the relay terminal then sends the acquired first data and first location information to the second blockchain.
  • the second blockchain may verify the first data based on the SPV verification method, and after verification, provide the AM message included in the first data to the second account.
  • the relay terminal in this sequence diagram corresponds to the relay terminal in FIG. 4 and FIG. 5, and those skilled in the art can similarly obtain the sequence diagram using the relay terminal in FIG. 6 and FIG. 7.
  • FIG. 9 shows a device 900 for sending an authenticated message across chains according to an embodiment of the present specification.
  • the cross-chain sending is sending from the first account of the first blockchain to outside the chain.
  • the first blockchain Connected to the relay end, and the device is deployed on the first blockchain, including:
  • the depositing unit 91 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 is at least It includes the following fields that satisfy the predetermined agreement: sending blockchain ID, sending account, receiving object information and message content, where the sending blockchain ID and sending account fields correspond to the following field values: the first blockchain ID, the first An account; and
  • the providing unit 92 is configured to provide the first data and first location information to the relay terminal for providing the certifiable message to the receiving object, wherein the first location information Indicate the position of the first data in the first blockchain, and the relay terminal is connected to the system where the receiving object is located.
  • the deposit unit 91 is further configured to deposit the first data into the first blockchain by invoking a first smart contract from the first account, wherein the first account When calling the first smart contract, at least the following parameters are passed to the first smart contract: receiving object information and message content.
  • FIG. 10 shows an apparatus 1000 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 a first blockchain, wherein the first
  • the consensus first data is pre-stored in the blockchain, where the first data includes a verifiable message, and the verifiable message includes at least the following fields that satisfy a predetermined protocol: sending blockchain identification, sending account, Receiving object information and message content, wherein the sending blockchain identifier and sending account fields correspond to the following field values: first blockchain identifier and first account, respectively, the device includes:
  • the obtaining unit 101 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 102 is configured to send the first data and the first location information to the system where the receiving object is located based on the receiving object information in the certifiable message, wherein the relay terminal is connected to the system .
  • 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. 11 shows an apparatus 1100 for receiving a verifiable message across chains according to an embodiment of the present specification.
  • the cross-chain reception is received by at least one object in the second system from other blockchains.
  • At least one second data respectively related to at least one other blockchain is synchronized through the relay terminal, wherein the at least one other blockchain includes the first blockchain, and the device is deployed in the second system ,include:
  • the receiving unit 111 is configured to receive first data and first location information from the relay terminal, wherein the first data includes an certifiable message, and the certifiable message includes at least the following fields satisfying a predetermined protocol : Sending blockchain identification, sending account, receiving object information and message content, where the sending blockchain identification and sending account fields correspond to the following field values: first blockchain identification, first account, the first Location information indicates the location of the first data in the sending blockchain, and the receiving object information field corresponds to the second system identifier and the at least one object;
  • the acquiring unit 112 is configured to acquire second data related to the first blockchain based on the first blockchain identifier in the verifiable message;
  • the verification unit 113 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 114 is configured to provide the at least one object with the certifiable message based on the received object information in the certifiable 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 113 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 verifiable message is located in the first log in the first receipt, and the verification unit 113 is further configured to verify that the first account is based on the sending field of the first log The account that sent the verifiable message.
  • the second system is a second blockchain
  • the at least one object is a second account in the second blockchain
  • the second account is a contract account of a third smart contract
  • the providing unit 114 is further configured to provide the certifiable message to the second account by invoking a third smart contract with the certifiable message as an incoming parameter.
  • 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 a first blockchain, wherein the first The consensus first data is pre-stored in the blockchain, where the first data includes a verifiable message, and the verifiable message includes at least the following fields that satisfy a predetermined protocol: sending blockchain identification, sending account, Receive object information and message content, where the sending blockchain identifier and sending account fields correspond to the following field values: the first blockchain identifier, the first account, and the relay terminal synchronizes each corresponding to its connection
  • the device includes:
  • the first 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 second acquiring unit 122 is configured to acquire second data related to the first blockchain based on the first blockchain identifier in the verifiable message;
  • the verification unit 123 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 124 is configured to digitally sign the verifiable message when the verification is passed.
  • the sending unit 125 is configured to send the certifiable message and its digital signature to the system where the recipient is located based on the recipient information in the certifiable message, wherein the relay terminal is connected to the system .
  • FIG. 13 shows an apparatus 1300 for receiving a verifiable message across chains according to an embodiment of this specification.
  • the cross-chain reception is received by at least one object in a second system from other blockchains, and the second system is connected with
  • the relay terminal is connected, the relay terminal is also connected with the first blockchain, the public key of the relay terminal is pre-stored in the second blockchain, and the device deployed in the second system includes:
  • the receiving unit 131 is configured to receive an certifiable message from the relay terminal and a digital signature of the certifiable message by the relay terminal, wherein the certifiable message includes at least the following fields satisfying a predetermined protocol : Sending blockchain ID, sending account, receiving object information and message content, where the sending blockchain ID and sending account fields correspond to the following field values: first blockchain ID, first account, and receiving object The information field corresponds to the second system identifier and the at least one object;
  • the verification unit 132 is configured to use the public key of the relay terminal to verify the digital signature
  • the providing unit 133 is configured to provide the certifiable message to the at least one object based on the received object information in the certifiable 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示出根据本说明书实施例的一种跨链发送可认证消息的装置900；
图10示出根据本说明书实施例的一种跨链中转可认证消息的装置1000；
图11示出根据本说明书实施例的一种跨链接收可认证消息的装置1100；
图12示出根据本说明书实施例的一种跨链中转可认证消息的装置1200；
图13示出根据本说明书实施例的一种跨链接收可认证消息的装置1300。
具体实施方式
下面将结合附图描述本说明书实施例。
图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”字段中即第二智能合约希望发出的可认证消息。其中，所述可认证消息至少包括满足预定协议的以下字段：发送链标识(即第一区块链标识)、发送账户(即第二智能合约的合约账户)、接收链标识(即第二区块链标识)、接收账户(即第三智能合约的合约账户，即第二账户)及消息内容(例如第三智能合约的传入参数)。
其中，上述预定协议可以根据具体场景的需要进行设定，在此不特定限定。在一个实施例中，所述可认证消息中还包括协议版本号字段和预留字段。在所述协议可具有多个版本的情况中，通过该协议版本号字段确定该协议的具体版本。所述预留字段为预留的空字段。在一个实施例中，所述可认证消息中还可以包括类型字段，用于指示该可认 证消息的使用场景类型，从而可通过类型字段区分开不同场景下不同的消息内容。例如，针对不同的使用场景(即可认证消息中的不同的类型)，所述消息内容字段中可对应于不同的内容、具有不同的格式等。所述场景类型例如为以下任一类型：消息类型、远程过程调用类型、发布/订阅类型、转账类型等等。在一个实施例中，所述可认证消息中还包括序号字段，用于在所述第一账户向例如第二账户多次发送可认证消息的情况中表示当前发送序号。所述协议版本号字段、预留字段、类型字段、序号字段等各自对应的字段值可类似地由账户调用第一智能合约时作为输入参数传给第一智能合约，从而使得第一智能合约中的存入函数可基于这些输入参数输出包含这些字段值的可认证消息。
虽然上文中以第二智能合约调用第一智能合约为例描述了向第一区块链中存入经共识的收据的过程，本说明书实施例不限于此，例如，第一账户为用户账户，其可通过向其它任一账户发送交易，从而实现向区块链中存入第一数据的过程，该第一数据例如还可以为区块中的交易数据，例如，可在该交易的数据字段中预置预定标志，以标识该交易为用于跨链发送信息的交易，并且该交易的数据字段中包括上述可认证消息。从而，在第一账户发出该交易之后，该交易在共识验证之后被存入区块中。在后续过程中，可通过预定标志查找到该交易数据，并从该交易数据中获取可认证消息。
在步骤S204，将所述第一数据和第一位置信息提供给所述中继端，以用于将所述可认证消息提供给所述接收对象，其中，所述第一位置信息指示第一数据在第一区块链中的位置，所述中继端与所述接收对象所在系统连接。
如上文所述，在本说明书实施例中，可使用不同的中继端，根据中继端的不同的实现方式，可通过不同的方法将第一数据提供给中继端。例如，在接收对象为第二区块链中的第二账户的情况中，该中继端本身为第一区块链和第二区块链中的节点，从而中继端可从本地存储的数据(如区块、状态树)中获取所述第一数据，并同时获取第一位置数据，所述第一位置信息指示第一数据在区块链中的位置，例如，在第一数据为收据的情况中，所述第一位置信息包括收据所在区块编号、以及收据在该区块中的编号等。例如，该中继端为与第一区块链和第二区块链都连接的中转装置，从而，第一区块链的任一节点可根据中继端的请求从本地获取该第一数据及其位置信息，并将其发送给该中继端。中继端在获取该第一数据及其位置信息之后，将根据其自身的形式的不同，执行不同的步骤，以用于将第一数据中的可认证消息提供给例如第二区块链中的第二账户，该过程将在下文详细描述。
图4示出根据本说明书实施例的一种跨链中转可认证消息的方法，所述方法由 中继端执行，所述中继端与第一区块链连接，其中，所述第一区块链中预存有经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息中至少包括满足预定协议的以下字段：发送区块链标识、发送账户、接收对象信息及消息内容，其中，发送区块链标识、发送账户字段分别对应于以下字段值：第一区块链标识、第一账户，所述方法包括：
步骤S402，从所述第一区块链获取所述第一数据和第一位置信息，所述第一位置信息指示第一数据在第一区块链中的位置；以及
步骤S404，基于所述可认证消息中的接收对象信息，将所述第一数据和所述第一位置信息发送给接收对象所在系统，其中，所述中继端与该系统连接。
在第一区块链中进行图2所示方法之后，在所述第一区块链中存入了上述经共识的第一数据，从而可执行该方法。
该方法由中继端执行，根据中继端的具体实现方式不同，中继端中执行的方法步骤也相应地不同，在该方法中，中继端为第一区块链与例如第二区块链之间的中转端，即，其不进行对数据的验证，仅用于数据的中转，并且不对数据的真实性、完整性负责。
在步骤S402，从所述第一区块链获取所述第一数据和第一位置信息，所述第一位置信息指示第一数据在第一区块链中的位置。在一个实施例中，所述第一数据带有预定标志地被存入区块链中，该预定标志用于对该类用于跨链发送的数据的查找。例如，该预定标志为第一智能合约的账户，其它合约账户在希望跨链传送信息时调用该第一智能合约，在调用该第一智能合约之后，在相应的收据中将包括该第一智能合约的账户，从而通过基于该第一智能合约的账户可从区块中查找该收据作为第一数据，并可确定该收据所在的区块标识、该收据在该区块中的收据编号等一起作为第一位置信息。中继端例如可向任一节点订阅区块中具有第一智能合约的账户的收据，从而可从该节点接收所述第一数据和所述第一位置信息。如上文所述，在第一数据为特定数据的情况中，可在特定数据库或存储器中获取所述第一数据及其存储位置。
在步骤S404，基于所述可认证消息中的接收对象信息，将所述第一数据和所述第一位置信息发送给接收对象所在系统，其中，所述中继端与该系统连接。
如上文所述，在所述接收对象为第二区块链中的第二账户的情况中，中继端在获取所述第一数据和第一位置信息之后，例如，该第一数据为上述调用第一智能合约的收据，中继端通过该第一智能合约账户或者日志的预定主题从该收据中找到特定日志， 并从该特定日志的数据字段中获取可认证消息。基于预定协议，可确定该可认证消息中的“第二区块链标识”即为将要接收该可认证消息的链标识，从而可将该第一数据和第一位置信息发送给第二区块链。可以理解，该中继端可能连接了不止两个区块链，例如可能还连接了第三区块链、第四区块链等，因此，该中继端在获取该第一数据和第一位置信息之后，基于其中的第二区块链标识进行数据的发送，也即基于接收链标识对接收链的寻址过程。
图5示出根据本说明书实施例的一种跨链接收可认证消息的方法，所述跨链接收为由第二系统中的至少一个对象从其它区块链接收，所述第二系统中通过所述中继端同步有与至少一个其它区块链分别相关的至少一个第二数据，其中，所述至少一个其它区块链中包括第一区块链，所述方法由第二系统执行，包括：
步骤S502，从所述中继端接收第一数据和第一位置信息，其中，所述第一数据中包括可认证消息，所述可认证消息中至少包括满足预定协议的以下字段：发送区块链标识、发送账户、接收对象信息及消息内容，其中，发送区块链标识、发送账户字段分别对应于以下字段值：第一区块链标识、第一账户，所述第一位置信息指示所述第一数据在所述发送区块链中的位置，所述接收对象信息字段与所述第二系统标识和所述至少一个对象相对应；
步骤S504，基于所述可认证消息中的第一区块链标识，获取与所述第一区块链相关的第二数据；
步骤S506，基于所述与第一区块链相关的第二数据、所述第一数据和所述第一位置信息，对所述可认证消息进行验证；以及
步骤S508，基于所述可认证消息中的接收对象信息，向所述至少一个对象提供所述可认证消息。
图5所示方法与图4所示方法中的中继端相对应，在进行图4所示方法之后，可开始图5所示方法。如上文所述，在所述接收对象为第二区块链中的第二账户的情况中，所述接收对象信息字段包括接收区块链标识字段和接收账户字段。在第二区块链中，例如在多个验证节点进行对可认证消息的验证，该验证节点中通过中继端同步有与其它各个区块链分别相关的各个第二数据，该第二数据用于进行对可认证消息的验证。根据具体的不同验证方式，所述验证节点各不相同，该第二数据也相应地不同，例如在通过简单支付验证(spv)方法进行验证的情况中，所述验证节点为spv节点，该第二数据为 相应链中各个区块的区块头。
首先，在步骤S502，从所述中继端接收第一数据和第一位置信息，其中，所述第一数据中包括可认证消息，所述可认证消息中至少包括满足预定协议的以下字段：发送区块链标识、发送账户、接收对象信息及消息内容，其中，发送区块链标识、发送账户字段分别对应于以下字段值：第一区块链标识、第一账户，所述第一位置信息指示所述第一数据在所述发送区块链中的位置，所述接收对象信息字段与所述第二系统标识和所述至少一个对象相对应。
所述第一数据如上文所述，例如为通过中继端从第一区块链的区块中获取的具有预定标志的收据。中继端在从第一区块链中获取该收据及其位置之后即可中转给第二区块链，从而使得第二区块链中的各个节点获取该收据及其位置，从而使得第二区块链中的记账节点或验证节点等进行下述步骤S504-S508。
在步骤S504，基于所述可认证消息中的第一区块链标识，获取与所述第一区块链相关的第二数据。
如上文所述，所述可认证消息中包括第一区块链标识，因此，在接收第一数据之后，可从第一数据中的可认证消息中的发送区块链标识字段获取第一区块链标识，从而从本地获取与第一区块链相关的第二数据。
在步骤S506，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证。
在一个实施例中，所述第一数据为第一区块链的第一区块中的第一收据，所述第一位置信息包括第一区块的区块编号和第一收据在第一区块中的收据编号，所述与第一区块链相关的第二数据为第一区块链中的各个区块的区块头，其中，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证包括，基于所述第一收据、各个区块的区块头和另外获取的第一区块中的与第一收据相关联的默克尔树路径，通过简单支付验证方法(spv验证方法)验证：所述第一收据来自于第一区块链中的第一区块，其中，所述默克尔树路径基于所述第一位置信息获取。该spv验证方法包括以下具体步骤：
计算该第一收据的收据哈希值；
根据上述默克尔树路径，计算该默克尔树的根哈希值；
将计算的根哈希值与第一区块的区块头中的收据树根哈希值进行比较，以确定 该第一收据是否在第一区块中。
在一个实施例中，所述spv验证还可以包括，在确定第一收据在第一区块中之后，根据第一区块的所处位置，验证该区块的区块头是否包含在已知最长链中，以确定该第一区块是否经过共识。在一个实施例中，所述区块链标识与区块链中创世块的头哈希值相对应，所述spv验证还可以包括，通过第一区块的区块头中的头哈希值和父哈希值及各个区块的区块头，验证该区块链的创世块的头哈希值是否对应于第一区块链的链标识。
在一个实施例中，参考上文对图3的描述，所述第一收据通过由第二智能合约调用第一智能合约而自动生成的包括图3所示日志的收据，在该情况下，该第一收据可自身证明，可认证消息中的第一账户即为发送该消息的账户。
在一个实施例中，所述第一收据由用户账户(即第一账户)发送交易而存入区块链中，所述可认证消息由用户填入交易数据中，在生成第一收据之后，所述可认证消息位于所述第一收据中的第一日志中，在该情况中，可基于所述第一日志的发送字段，验证所述第一账户为发送所述可认证消息的账户。
在步骤S508，基于所述可认证消息中的接收对象信息，向所述至少一个对象提供所述可认证消息。
如上文所述，在所述接收对象为第二区块链中的第二账户的情况中，在一个实施例中，第一区块链中的第二智能合约通过调用第一智能合约向第二区块链中的第三智能合约传递信息，以进行对第三智能合约的调用。在该情况中，第二账户即为第三智能合约的合约账户，该可认证消息中例如为第三智能合约传入参数。从而，向所述第二账户提供所述可认证消息包括，通过以所述可认证消息为传入参数调用第三智能合约，向第二账户提供所述可认证消息。第三智能合约在经调用之后，基于该可认证消息中的信息执行具体的业务过程。可以理解，所述第二账户不限于为智能合约账户，例如，其也可以为用户账户，在该情况中，可通过区块链中常用方法(例如发送交易的方法)由验证节点向该用户账户提供所述可认证消息。
图6示出根据本说明书实施例的一种跨链中转可认证消息的方法，所述方法由中继端执行，所述中继端与第一区块链连接，其中，所述第一区块链中预存有经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息中至少包括满足预定协议的以下字段：发送区块链标识、发送账户、接收对象信息及消息内容，其中，发 送区块链标识、发送账户字段分别对应于以下字段值：第一区块链标识、第一账户，所述中继端同步有分别对应于其连接的各个区块链的各个第二数据，所述方法包括：
步骤S602，从所述第一区块链获取所述第一数据和第一位置信息，所述第一位置信息指示第一数据在第一区块链中的位置；
步骤S604，基于所述可认证消息中的第一区块链标识，获取与所述第一区块链相关的第二数据；
步骤S606，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证；
步骤S608，在验证通过的情况中，对所述可认证消息进行数字签名；以及
步骤S610，基于所述可认证消息中的接收对象信息，将所述可认证消息及其数字签名发送给所述接收对象所在系统，其中，所述中继端与所述系统连接。
在该方法中，中继端为可信节点，或者可以为验证区块链，其可在从第一区块链获取第一数据之后，在本地进行验证，并在验证通过之后进行数字签名，并发送给第二区块链，从而第二区块链可通过中继端的数字签名进行对第一数据的验证，从而简化了第二区块链的验证过程。该方法中的步骤S602和步骤S610可参考上文中对步骤S402和S404的描述，步骤S604和S606可参考上文中对步骤S504和S506的描述，在此不再赘述。
图7示出根据本说明书实施例的一种跨链接收可认证消息的方法，所述跨链接收为由第二系统中的至少一个对象从其它区块链接收，所述第二系统与中继端连接，所述中继端还与第一区块链连接，所述第二区块链中预先存储有所述中继端的公钥，所述方法由第二系统执行，包括：
步骤S702，从所述中继端接收可认证消息、及所述中继端对所述可认证消息的数字签名，其中，所述可认证消息中至少包括满足预定协议的以下字段：发送区块链标识、发送账户、接收对象信息及消息内容，其中，发送区块链标识、发送账户字段分别对应于以下字段值：第一区块链标识、第一账户，所述接收对象信息字段与所述第二系统标识和所述至少一个对象相对应；
步骤S704，使用所述中继端的公钥对所述数字签名进行验证；以及
步骤S706，基于所述可认证消息中的接收对象信息，向所述至少一个对象提供 所述可认证消息。
图7所示方法与图6所示方法中的中继端相对应，在进行图6所示方法之后，可开始图7所示方法。该方法可由第二区块链中任一节点或客户端执行，该节点(或客户端)本地只需要保存中继端的公钥，即可以进行对可认证消息的验证，因此，不需要如图5所示方案，从中继端接收第一数据，而仅需要接收可认证消息。其中，步骤S706可参考上文对步骤S508的描述，在此不再赘述。
图8示出从第一区块链的第一账户向第二区块链的第二账户发送可认证消息的时序图。首先，在第一区块链中，由第一账户向第一区块链中存入包括AM消息的第一数据，之后，第一区块链将该第一数据及其在第一区块链中的位置信息提供给中继端。中继端然后将获取的第一数据和第一位置信息发送给第二区块链。第二区块链在获取第一数据及其位置信息之后，可基于SPV验证方法对该第一数据进行验证，并在验证之后，将该第一数据中包括的AM消息提供给第二账户。该时序图中的中继端对应于图4和图5中的中继端，本领域技术人员可以类似地获取使用图6和图7中的中继端的时序图。
图9示出根据本说明书实施例的一种跨链发送可认证消息的装置900，所述跨链发送为从第一区块链的第一账户向链外发送，所述第一区块链与中继端连接，所述装置部署在所述第一区块链，包括：
存入单元91，配置为，通过所述第一账户向第一区块链中存入经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息中至少包括满足预定协议的以下字段：发送区块链标识、发送账户、接收对象信息及消息内容，其中，发送区块链标识、发送账户字段分别对应于以下字段值：第一区块链标识、第一账户；以及
提供单元92，配置为，将所述第一数据和第一位置信息提供给所述中继端，以用于将所述可认证消息提供给所述接收对象，其中，所述第一位置信息指示第一数据在第一区块链中的位置，所述中继端与所述接收对象所在系统连接。
在一个实施例中，所述存入单元91还配置为，通过由所述第一账户调用第一智能合约向第一区块链中存入所述第一数据，其中，所述第一账户在调用第一智能合约时向第一智能合约传入至少以下参数：接收对象信息及消息内容。
图10示出根据本说明书实施例的一种跨链中转可认证消息的装置1000，所述装置部署在中继端，所述中继端与第一区块链连接，其中，所述第一区块链中预存有经共 识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息中至少包括满足预定协议的以下字段：发送区块链标识、发送账户、接收对象信息及消息内容，其中，发送区块链标识、发送账户字段分别对应于以下字段值：第一区块链标识、第一账户，所述装置包括：
获取单元101，配置为，从所述第一区块链获取所述第一数据和第一位置信息，所述第一位置信息指示第一数据在第一区块链中的位置；以及
发送单元102，配置为，基于所述可认证消息中的接收对象信息，将所述第一数据和所述第一位置信息发送给接收对象所在系统，其中，所述中继端与该系统连接。
在一个实施例中，所述第一数据被标注有预定标志，其中，所述获取单元还配置为，基于所述预定标志从所述第一区块链获取所述第一数据和第一位置信息。
图11示出根据本说明书实施例的一种跨链接收可认证消息的装置1100，所述跨链接收为由第二系统中的至少一个对象从其它区块链接收，所述第二系统中通过所述中继端同步有与至少一个其它区块链分别相关的至少一个第二数据，其中，所述至少一个其它区块链中包括第一区块链，所述装置部署在第二系统，包括：
接收单元111，配置为，从所述中继端接收第一数据和第一位置信息，其中，所述第一数据中包括可认证消息，所述可认证消息中至少包括满足预定协议的以下字段：发送区块链标识、发送账户、接收对象信息及消息内容，其中，发送区块链标识、发送账户字段分别对应于以下字段值：第一区块链标识、第一账户，所述第一位置信息指示所述第一数据在所述发送区块链中的位置，所述接收对象信息字段与所述第二系统标识和所述至少一个对象相对应；
获取单元112，配置为，基于所述可认证消息中的第一区块链标识，获取与所述第一区块链相关的第二数据；
验证单元113，配置为，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证；以及
提供单元114，配置为，基于所述可认证消息中的接收对象信息，向所述至少一个对象提供所述可认证消息。
在一个实施例中，所述第一数据为第一区块链的第一区块中的第一收据，所述第一位置信息包括第一区块的区块编号和第一收据在第一区块中的收据编号，所述与第一区块链相关的第二数据为第一区块链中的各个区块的区块头，其中，所述验证单元113 还配置为，基于所述第一收据、所述各个区块的区块头和第一区块中的与第一收据相关联的默克尔树路径，通过简单支付验证方法验证：所述第一收据来自于第一区块链中的第一区块，其中，所述默克尔树路径基于所述第一位置信息获取。
在一个实施例中，所述可认证消息位于所述第一收据中的第一日志中，所述验证单元113还配置为，基于所述第一日志的发送字段，验证所述第一账户为发送所述可认证消息的账户。
在一个实施例中，所述第二系统为第二区块链，所述至少一个对象为第二区块链中的第二账户，所述第二账户为第三智能合约的合约账户，所述提供单元114还配置为，通过以所述可认证消息为传入参数调用第三智能合约，向第二账户提供所述可认证消息。
图12示出根据本说明书实施例的一种跨链中转可认证消息的装置1200，所述装置部署在中继端，所述中继端与第一区块链连接，其中，所述第一区块链中预存有经共识的第一数据，其中，所述第一数据中包括可认证消息，所述可认证消息中至少包括满足预定协议的以下字段：发送区块链标识、发送账户、接收对象信息及消息内容，其中，发送区块链标识、发送账户字段分别对应于以下字段值：第一区块链标识、第一账户，所述中继端同步有分别对应于其连接的各个区块链的各个第二数据，所述装置包括：
第一获取单元121，配置为，从所述第一区块链获取所述第一数据和第一位置信息，所述第一位置信息指示第一数据在第一区块链中的位置；
第二获取单元122，配置为，基于所述可认证消息中的第一区块链标识，获取与所述第一区块链相关的第二数据；
验证单元123，配置为，基于所述第一数据、与所述第一区块链相关的第二数据以及所述第一位置信息，对所述可认证消息进行验证；
签名单元124，配置为，在验证通过的情况中，对所述可认证消息进行数字签名；以及
发送单元125，配置为，基于所述可认证消息中的接收对象信息，将所述可认证消息及其数字签名发送给所述接收对象所在系统，其中，所述中继端与所述系统连接。
图13示出根据本说明书实施例的一种跨链接收可认证消息的装置1300，所述跨链接收为由第二系统中的至少一个对象从其它区块链接收，所述第二系统与中继端连接，所述中继端还与第一区块链连接，所述第二区块链中预先存储有所述中继端的公钥，所 述装置部署在第二系统，包括：
接收单元131，配置为，从所述中继端接收可认证消息、及所述中继端对所述可认证消息的数字签名，其中，所述可认证消息中至少包括满足预定协议的以下字段：发送区块链标识、发送账户、接收对象信息及消息内容，其中，发送区块链标识、发送账户字段分别对应于以下字段值：第一区块链标识、第一账户，所述接收对象信息字段与所述第二系统标识和所述至少一个对象相对应；
验证单元132，配置为，使用所述中继端的公钥对所述数字签名进行验证；以及
提供单元133，配置为，基于所述可认证消息中的接收对象信息，向所述至少一个对象提供所述可认证消息。
本说明书另一方面提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行上述任一项方法。
本说明书另一方面提供一种计算设备，包括存储器和处理器，其特征在于，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现上述任一项方法。
根据本说明书实施例的跨链方案抽象区块链互操作模型，设计一种可认证消息，使得区块链发出的消息可以被其他链认证：消息来自于哪条链，且由链上的哪个身份实体(账号/合约)发出。使得基于此可认证消息，允许进行跨链应用(合约)编程，使开发者更轻易地开发出各种跨链业务、应用，并且该可认证消息保留较高的扩展性，支持叠加协议栈，使各种跨链互操作技术、应用场景都能标准化，另外，该可认证消息可以被异构平台实现，使得区块链仅实现一种跨链适配升级，可以接入多种跨链平台、连接多条链。
需要理解，本文中的“第一”，“第二”等描述，仅仅为了描述的简单而对相似概念进行区分，并不具有其他限定作用。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序 来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
本领域普通技术人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执轨道，取决于技术方案的特定应用和设计约束条件。本领域普通技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执轨道的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (42)

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

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/786,949 US11251966B2 (en) 2019-06-28 2020-02-10 Sending cross-chain authenticatable messages
US17/235,706 US11343103B2 (en) 2019-06-28 2021-04-20 Sending cross-chain authenticatable messages

Applications Claiming Priority (2)

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

Related Child Applications (1)

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

Publications (1)

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

Family

ID=68408842

Family Applications (1)

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

Country Status (3)

Country Link
CN (2) CN112615871B (zh)
TW (1) TWI738208B (zh)
WO (1) WO2020258846A1 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113886487A (zh) * 2021-08-30 2022-01-04 西安电子科技大学 一种消息传递方法、系统、介质、设备及移动终端
CN114331447A (zh) * 2022-03-15 2022-04-12 北京溪塔科技有限公司 一种跨链消息提交方法及装置
CN114499872A (zh) * 2021-12-24 2022-05-13 山东浪潮工业互联网产业股份有限公司 一种基于工业互联网的星火链跨链方法及设备
WO2022205957A1 (zh) * 2021-03-30 2022-10-06 蚂蚁区块链科技(上海)有限公司 一种基于中继设备跨链中转消息的方法和装置
CN116827957A (zh) * 2023-08-30 2023-09-29 腾讯科技（深圳）有限公司 基于多区块链的信息处理方法、装置、设备以及介质

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
CN112615871B (zh) * 2019-06-28 2023-08-22 创新先进技术有限公司 一种跨链发送可认证消息的方法和装置
CN112118292A (zh) * 2020-08-13 2020-12-22 北京新盛云佳科技有限公司 用于跨链通信的方法、装置、网络节点和存储介质
CN114422159A (zh) * 2020-10-13 2022-04-29 北京金山云网络技术有限公司 一种基于区块链的数据处理方法及装置
CN112270005B (zh) * 2020-10-28 2022-04-26 支付宝(杭州)信息技术有限公司 一种数据传输方法和系统
CN112446785B (zh) * 2020-11-06 2023-09-22 杭州趣链科技有限公司 跨链交易方法、系统、装置、设备和存储介质
CN112804358B (zh) * 2021-03-30 2021-07-23 支付宝(杭州)信息技术有限公司 一种基于中继设备网络跨链中转数据的方法和装置
CN112804359B (zh) * 2021-03-30 2021-07-06 支付宝(杭州)信息技术有限公司 提供跨链消息的方法和装置
CN112734432B (zh) * 2021-03-30 2021-07-23 支付宝(杭州)信息技术有限公司 跨链数据处理方法和装置

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170352027A1 (en) * 2016-06-07 2017-12-07 Cornell University Authenticated data feed for blockchains
CN108683630A (zh) * 2018-04-03 2018-10-19 阿里巴巴集团控股有限公司 跨区块链的认证方法及装置、电子设备
CN109035012A (zh) * 2018-06-11 2018-12-18 西安纸贵互联网科技有限公司 一种区块链系统的跨链处理方法和计算机可读存储介质
CN109146677A (zh) * 2017-06-14 2019-01-04 深圳区块链金融服务有限公司 并行构建区块链视图的方法、计算机系统和可读存储介质
US20190081793A1 (en) * 2017-09-12 2019-03-14 Kadena, LLC Parallel-chain architecture for blockchain systems
CN109600367A (zh) * 2018-12-07 2019-04-09 众安信息技术服务有限公司 用于实现跨链消息处理的方法以及设备
CN110430162A (zh) * 2019-06-28 2019-11-08 阿里巴巴集团控股有限公司 一种跨链发送可认证消息的方法和装置

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11182851B2 (en) * 2016-10-20 2021-11-23 International Business Machines Corporation Inter-ledger messaging in a blockchain
CN106533696B (zh) * 2016-11-18 2019-10-01 江苏通付盾科技有限公司 基于区块链的身份认证方法、认证服务器及用户终端
CN107301536B (zh) * 2017-06-12 2019-07-12 腾讯科技（深圳）有限公司 资源转移方法及装置
CN107257340B (zh) * 2017-06-19 2019-10-01 阿里巴巴集团控股有限公司 一种认证方法、基于区块链的认证数据处理方法及设备
CN107424073A (zh) * 2017-07-17 2017-12-01 杭州复杂美科技有限公司 一种跨链数字债权交易的方法
US11146380B2 (en) * 2017-08-03 2021-10-12 Parity Technologies Ltd. Methods and systems for a heterogeneous multi-chain framework
CN108269190A (zh) * 2018-01-17 2018-07-10 深圳四方精创资讯股份有限公司 基于跨链中继平台的跨链方法及其系统
CN108389129B (zh) * 2018-02-27 2020-12-04 创新先进技术有限公司 基于区块链的交易执行方法及装置、电子设备
TWI663865B (zh) * 2018-07-09 2019-06-21 現代財富控股有限公司 基於跨鏈架構的身分識別管理系統及其方法
CN109063016A (zh) * 2018-07-11 2018-12-21 物数（上海）信息科技有限公司 区块链数据储存方法、装置、电子设备、存储介质
CN109784881A (zh) * 2018-12-29 2019-05-21 广州蓝石信息技术有限公司 基于去中心化网关的通用跨链支付方案

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170352027A1 (en) * 2016-06-07 2017-12-07 Cornell University Authenticated data feed for blockchains
CN109146677A (zh) * 2017-06-14 2019-01-04 深圳区块链金融服务有限公司 并行构建区块链视图的方法、计算机系统和可读存储介质
US20190081793A1 (en) * 2017-09-12 2019-03-14 Kadena, LLC Parallel-chain architecture for blockchain systems
CN108683630A (zh) * 2018-04-03 2018-10-19 阿里巴巴集团控股有限公司 跨区块链的认证方法及装置、电子设备
CN109035012A (zh) * 2018-06-11 2018-12-18 西安纸贵互联网科技有限公司 一种区块链系统的跨链处理方法和计算机可读存储介质
CN109600367A (zh) * 2018-12-07 2019-04-09 众安信息技术服务有限公司 用于实现跨链消息处理的方法以及设备
CN110430162A (zh) * 2019-06-28 2019-11-08 阿里巴巴集团控股有限公司 一种跨链发送可认证消息的方法和装置

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022205957A1 (zh) * 2021-03-30 2022-10-06 蚂蚁区块链科技(上海)有限公司 一种基于中继设备跨链中转消息的方法和装置
CN113886487A (zh) * 2021-08-30 2022-01-04 西安电子科技大学 一种消息传递方法、系统、介质、设备及移动终端
CN113886487B (zh) * 2021-08-30 2024-04-09 西安电子科技大学 一种消息传递方法、系统、介质、设备及移动终端
CN114499872A (zh) * 2021-12-24 2022-05-13 山东浪潮工业互联网产业股份有限公司 一种基于工业互联网的星火链跨链方法及设备
CN114331447A (zh) * 2022-03-15 2022-04-12 北京溪塔科技有限公司 一种跨链消息提交方法及装置
CN116827957A (zh) * 2023-08-30 2023-09-29 腾讯科技（深圳）有限公司 基于多区块链的信息处理方法、装置、设备以及介质
CN116827957B (zh) * 2023-08-30 2023-11-07 腾讯科技（深圳）有限公司 基于多区块链的信息处理方法、装置、设备以及介质

Also Published As

Publication number Publication date
CN110430162B (zh) 2020-11-24
CN110430162A (zh) 2019-11-08
TWI738208B (zh) 2021-09-01
CN112615871B (zh) 2023-08-22
TW202101332A (zh) 2021-01-01
CN112615871A (zh) 2021-04-06

Similar Documents

Publication Publication Date Title
WO2020258846A1 (zh) 一种跨链发送可认证消息的方法和装置
WO2020258850A1 (zh) 一种跨链发送可认证消息的方法和装置
WO2020258848A1 (zh) 一种跨链发送资源的方法和装置
US11343103B2 (en) Sending cross-chain authenticatable messages
CN107993149B (zh) 账户信息管理方法、系统以及可读存储介质
US11336451B2 (en) Cross-blockchain resource transmission
WO2020258847A1 (zh) 基于处理模块跨链发送可认证消息的方法和装置
US10924281B2 (en) Method and apparatus for inter-blockchain transmission of authenticable message
CN110839029B (zh) 一种微服务注册方法和装置
US20220269670A1 (en) Data processing method and apparatus, computer device, and storage medium
WO2020258849A1 (zh) 一种跨链发送可认证消息的方法和装置
US20230325833A1 (en) Blockchain-based data processing method and apparatus, device, storage medium, and program product
CN117633903A (zh) 基于区块链网络的数据处理方法、相关设备及产品
CN117522398A (zh) 区块链数据处理方法、装置及设备、介质、程序产品
CN115834591A (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: 20831457

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: 20831457

Country of ref document: EP

Kind code of ref document: A1