WO2024164550A1 - 区块链数据处理方法、装置、设备及存储介质 - Google Patents

区块链数据处理方法、装置、设备及存储介质 Download PDF

Info

Publication number
WO2024164550A1
WO2024164550A1 PCT/CN2023/124925 CN2023124925W WO2024164550A1 WO 2024164550 A1 WO2024164550 A1 WO 2024164550A1 CN 2023124925 W CN2023124925 W CN 2023124925W WO 2024164550 A1 WO2024164550 A1 WO 2024164550A1
Authority
WO
WIPO (PCT)
Prior art keywords
target
blockchain
node device
data
block
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/CN2023/124925
Other languages
English (en)
French (fr)
Inventor
朱耿良
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
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 Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to EP23920742.6A priority Critical patent/EP4560981A4/en
Publication of WO2024164550A1 publication Critical patent/WO2024164550A1/zh
Priority to US19/051,589 priority patent/US20250184316A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

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/12—Applying verification of the received information
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • 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/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/26—Special purpose or proprietary protocols or architectures
    • 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Definitions

  • the present application relates to the field of blockchain technology, and in particular to blockchain data processing methods, devices, equipment and storage media.
  • Blockchain technology is a new distributed infrastructure and computing method that uses block chain data structures to verify and store data, uses distributed node consensus algorithms to generate and update data, uses cryptography to ensure the security of data transmission and access, and uses smart contracts composed of automated script codes to program and operate data.
  • blockchain is a decentralized distributed ledger.
  • a blockchain data processing method, apparatus, device, and storage medium are provided.
  • an embodiment of the present application provides a blockchain data processing method, which is executed by a first node device maintaining a first blockchain in a blockchain network, including:
  • the target data packet is sent to the target relay server associated with the second node device, and the encapsulated block header is sent to the target oracle server associated with the second node device, the target relay server is used to send the target data packet to the second node device, the target oracle server is used to send the encapsulated block header to the second node device, and the second node device is used to process the target transaction data in the target data packet when the target transaction data is verified according to the data verification rules on the second blockchain, the encapsulated block header and the transaction verification information in the target data packet, and the data verification rules are associated with the cross-chain communication protocol.
  • the present application provides a blockchain data processing method, which is executed by a second node device maintaining a second blockchain in a blockchain network, including:
  • the target data packet When receiving a target data packet sent by a target relay server and an encapsulated block header sent by a target oracle server, the target data packet is parsed to obtain target transaction data and transaction verification information of the target transaction data in the target data packet; the target data packet is sent by a first node device maintaining the first blockchain to the target relay server, and the encapsulated block header is sent by the first node device to the target oracle server.
  • the target data packet is obtained by encapsulating the target transaction data and the transaction verification information of the target transaction data based on a message encapsulation format adapted to a second blockchain maintained by the second node device.
  • the target transaction data is transaction data in a target block of the first blockchain, and the encapsulated block header is obtained by encapsulating the block header of the target block based on the message encapsulation format;
  • the message encapsulation format is selected from a cross-chain communication protocol on the first blockchain, and the first node device and the second node device communicate in accordance with the cross-chain communication protocol;
  • the target transaction data is verified according to the encapsulated block header and the transaction verification information to obtain a verification result, wherein the data verification rules are associated with the cross-chain communication protocol;
  • the target transaction data in the target data packet is processed.
  • an embodiment of the present application provides a blockchain data processing device, including:
  • a selection module is used to select a message encapsulation format adapted to a second blockchain from a cross-chain communication protocol on a first blockchain, wherein the first blockchain is maintained by a first node device in a blockchain network, and the second blockchain is maintained by a second node device in the blockchain network, and the first node device and the second node device communicate in accordance with the cross-chain communication protocol;
  • an encapsulation module configured to determine a target block where the target transaction data associated with the second node device is located, encapsulate the target transaction data and the transaction verification information of the target transaction data in the target block on the first blockchain according to a message encapsulation format adapted to the second blockchain to obtain a target data packet, and encapsulate a block header of the target block according to a message encapsulation format adapted to the second blockchain to obtain an encapsulated block header;
  • a sending module is used to send the target data packet to a target relay server associated with the second node device, and to send the encapsulated block header to a target oracle server associated with the second node device, wherein the target relay server is used to send the target data packet to the second node device, and the target oracle server is used to send the encapsulated block header to the second node device, and the second node device is used to process the target transaction data in the target data packet when the target transaction data is verified according to the data verification rules on the second blockchain, the encapsulated block header and the transaction verification information in the target data packet, and the data verification rules are associated with the cross-chain communication protocol to send the target data packet to the target relay server associated with the second node device.
  • the embodiment of the present application provides a blockchain data processing device, including:
  • a parsing module configured to parse the target data packet, and obtain the target transaction data and the transaction verification information of the target transaction data in the target data packet when receiving the target data packet sent by the target relay server to the second node device and receiving the encapsulated block header sent by the target oracle server to the second node device;
  • the target data packet is sent by the first node device maintaining the first blockchain to the target relay server, the encapsulated block header is sent by the first node device to the target oracle server, the target data packet is obtained by encapsulating the target transaction data and the transaction verification information of the target transaction data based on the message encapsulation format adapted to the second blockchain maintained by the second node device,
  • the target transaction data is the transaction data in the target block of the first blockchain, and the encapsulated block header is obtained by encapsulating the block header of the target block based on the message encapsulation format;
  • the message encapsulation format is selected from the cross-chain communication protocol on the first blockchain, and the first node
  • a data verification module configured to verify the target transaction data according to the encapsulated block header and the transaction verification information according to the data verification rules on the second blockchain to obtain a verification result, wherein the data verification rules are associated with the cross-chain communication protocol;
  • the transaction processing module is used to process the target transaction data in the target data packet when the verification result indicates that the target transaction data has passed the verification.
  • an embodiment of the present application provides a computer device, comprising: a processor and a memory, wherein the memory stores computer-readable instructions, and the processor is used to execute the computer-readable instructions so that the computer device executes the method of any method embodiment of the present application.
  • an embodiment of the present application provides a computer-readable storage medium, in which computer-readable instructions are stored.
  • the computer-readable instructions are loaded and executed by a processor so that the processor executes the method of any method embodiment of the present application.
  • an embodiment of the present application provides a computer program product, including computer-readable instructions, which are stored in a computer-readable storage medium, and the computer-readable instructions are read and executed by a processor so that the processor performs the method of any method embodiment of the present application.
  • FIG1 is a schematic diagram of a blockchain structure provided in an embodiment of the present application.
  • FIG2 is a schematic diagram of a block generation provided in an embodiment of the present application.
  • FIG3 is a schematic diagram of a blockchain network hierarchical structure provided in an embodiment of the present application.
  • FIG4 is a schematic diagram of a structure of a blockchain network applied to electronic bills provided in an embodiment of the present application.
  • FIG5 is a schematic diagram of a scenario for cross-chain data interaction provided by an embodiment of the present application.
  • FIG6 is a flowchart of a blockchain data processing method provided in an embodiment of the present application.
  • FIG7 is a schematic diagram of a cross-chain communication provided in an embodiment of the present application.
  • FIG8 is a flowchart of a blockchain data processing method provided in an embodiment of the present application.
  • FIG9 is a schematic diagram of an application of cross-chain communication provided in an embodiment of the present application.
  • FIG10 is a schematic diagram of the structure of a blockchain data processing device provided in an embodiment of the present application.
  • FIG11 is a schematic diagram of the structure of a blockchain data processing device provided in an embodiment of the present application.
  • FIG. 12 is a schematic diagram of a computer device provided in an embodiment of the present application.
  • Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc.
  • Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block.
  • Blockchain can include the underlying blockchain platform, platform product service layer, and application service layer.
  • a blockchain is composed of multiple blocks, see Figure 1, which is a schematic diagram of a blockchain structure provided by an embodiment of the present application. As shown in Figure 1, a blockchain is composed of multiple blocks, and the genesis block includes a block header and a block body.
  • the block header stores input information feature values, version numbers, timestamps, and difficulty values
  • the block body stores input information
  • the next block of the genesis block uses the genesis block as a parent block, and the next block also includes a block header and a block body.
  • the block header stores input information feature values of the current block, block header feature values, version numbers, timestamps, and difficulty values of the parent block, and so on, so that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, thereby ensuring the security of the input information in the block.
  • FIG. 2 is a schematic diagram of a block generation provided by an embodiment of the present application.
  • the node verifies the input information. After completing the verification, the input information is stored in the memory pool and the hash tree used to record the input information is updated. After that, the update timestamp is updated to the time when the input information is received, and different random numbers are tried, and the characteristic value calculation is performed multiple times, so that the calculated characteristic value can satisfy the following formula (1): SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x)) ⁇ TARGET (1)
  • SHA256 in formula (1) is the eigenvalue algorithm used to calculate the eigenvalue; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header eigenvalue of the parent block of the current block; merkle_root is the eigenvalue of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, It is a fixed value within a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the characteristic value threshold, which can be determined according to nbits.
  • the information can be stored accordingly, the block header and block body can be generated, and the current block can be obtained. Subsequently, the blockchain can broadcast the newly generated current block to other nodes in the data sharing system where it is located. Each node in the data sharing system stores the same blockchain, and other nodes verify the current block and add the current block to the blockchain stored after the verification is completed.
  • the device feature information of the node device can be input into the device validity verification model.
  • the device validity verification model verifies the validity of the node device based on the risk control rules in the cross-chain communication protocol, and inputs the validity verification result.
  • the validity verification result is used to indicate whether the node device is valid.
  • the device validity verification model is stored on the blockchain, which can improve the efficiency of determining the validity of the node device.
  • FIG 3 is a schematic diagram of a blockchain network hierarchical structure provided in an embodiment of the present application.
  • the blockchain network hierarchical structure in the embodiment of the present application can be a blockchain network 1W shown in Figure 3, and the complete blockchain business system corresponding to the blockchain network 1W can be composed of the business network shown in Figure 3, the core consensus network, and the routing proxy network where the proxy node 10D is located.
  • the embodiment of the present application takes the proxy node 10D as an example, and the proxy node 10D can be used to isolate the business network and the core consensus network.
  • the proxy node 10D can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms, which are not limited here.
  • the proxy node 10D can layer the peer-to-peer (P2P) network to form a layered structure such as "business network-core consensus network", which can improve the confidentiality and security of data on the blockchain.
  • P2P peer-to-peer
  • the blockchain node system corresponding to the business network may include one or more blockchain nodes, and the number of nodes in the blockchain node system corresponding to the business network will not be limited here.
  • the blockchain node system corresponding to the business network may specifically include node 110a, node 110b, node 110c, ..., node 110n.
  • the blockchain node in the business network in the embodiment of the present application may be referred to as a business node, which does not need to participate in the bookkeeping consensus and is mainly used to execute the transaction business to obtain the transaction data associated with the transaction business.
  • the business node here can be a full node containing a complete blockchain database, or a lightweight node storing part of the data in the blockchain database, which will not be limited here.
  • the business node in the embodiment of the present application can be a lightweight node (Simplified Payment Verification, referred to as SPV) as an example.
  • SPV Simple Payment Verification
  • the business node does not need to store complete transaction data, but obtains block header data and partially authorized visible block data (for example, transactions associated with the business node itself) from the core consensus network shown in FIG3 through the proxy node 10D.
  • the blockchain node system corresponding to the core consensus network shown in Figure 3 may also include one or more blockchain nodes, and the number of nodes in the blockchain node system corresponding to the core consensus network will not be limited here.
  • the blockchain node system corresponding to the core consensus network may specifically include node 120a, node 120b, node 120c, ..., node 120m.
  • the embodiment of the present application may refer to the node in the core consensus network as a consensus node (i.e., an accounting node), and the consensus node may run a blockchain consensus protocol.
  • the embodiment of the present application may collectively refer to the proxy nodes, business nodes and consensus nodes as blockchain nodes in the blockchain network 1W.
  • the blockchain node may be a server connected to the blockchain network 1W, or a user terminal connected to the blockchain network 1W, and the specific form of the blockchain node is not limited here.
  • the business network and the core consensus network shown in Figure 3 can be in different network environments. For example, generally speaking, the business nodes are deployed in the business network in the public network, and the consensus nodes running the blockchain consensus protocol are deployed in the private core consensus network, and the two can interact through the routing boundary.
  • FIG4 is a block chain network structure diagram for electronic bills provided in an embodiment of the present application.
  • the blockchain network can record the transaction data generated during the entire circulation process of the electronic bills.
  • the blockchain network includes a business network 41, a core consensus network 42, and a routing agent network 43.
  • the circulation process of electronic bills includes the application of electronic bills, the issuance of electronic bills, the reimbursement of electronic bills, and the tax declaration of electronic bills.
  • the issuance of electronic bills is also called the generation of electronic bills.
  • the business network 41 includes a management agency private network 411 that provides relevant services for the management agency, and also includes a public cloud 412 that provides relevant services for the billing party, the reimbursement party, and the tax declaration party, and also includes a private cloud 413 that provides electronic bill storage services for consumers.
  • the management agency private network 411 includes computer equipment used by the management agency involved in the electronic bill, including a management agency terminal 4111, and the management terminal can access the management agency private network 411.
  • the public cloud 412 includes computer equipment used by the invoicing party, expense reimbursement party and tax payer involved in the electronic invoice, including the invoicing party terminal 4121, the reimbursement party terminal 4122 and the tax payer terminal 4123, wherein the invoicing party may be an invoicing service provider, the reimbursement party may be a reimbursement service provider, and the enterprise terminal may access the public cloud 412.
  • the private cloud 413 includes computer equipment used by users involved in the electronic invoice, including a payment terminal 4131 for payment, an electronic invoice circulation terminal 4132 for temporarily storing electronic invoices for users, and some enterprise-specific terminals 4133, and the consumer terminal may access the private cloud 413.
  • the computer equipment in the management agency private network 411, the public cloud 412 and the private cloud 413 may all be used as business nodes to send data uplink requests or data query requests for electronic invoices to the consensus network 43 through the routing layer 42.
  • any routing node in the routing layer 42 includes functional modules that provide authentication services 421, certificate cache 422, routing services 423, and P2P services 424.
  • the authentication service 421 is used to authenticate the business nodes in the business network 41
  • the certificate cache 422 is used to cache the identity certificates of each node
  • the routing service 423 is used to achieve network isolation between the business network 41 and the consensus network 43
  • the P2P service 424 is used to allocate tasks between routing nodes with idempotence, forming a peer-to-peer (P2P) network between routing nodes.
  • the P2P protocol is an application layer protocol that runs on the Transmission Control Protocol (TCP) protocol.
  • the consensus network 43 includes multiple consensus branch networks, such as blockchain network 1 431, blockchain network 2 432 and blockchain network 3 433, etc.
  • Each consensus branch network includes multiple consensus nodes (i.e., consensus node devices), and multiple consensus nodes in each consensus branch network maintain the blockchain corresponding to the consensus branch network, such as the multiple formula nodes included in blockchain network 1 431 are used to maintain blockchain 1 corresponding to blockchain network 1 431.
  • the functions of different blockchains in the consensus network 43 are different. For example, some blockchains are used to record transaction information related to electronic bills belonging to a certain bill number segment, and some blockchains are used to record transaction information related to red-out electronic bills. Among them, red-out means that the originally issued electronic bill is wrong or needs to be corrected, and the invoice is reissued to adjust the account.
  • the red-out electronic bill can be an electronic bill that has a red-out event.
  • the blockchain to be recorded can be determined according to the authority of the business node, and then recorded by the consensus branch network that maintains the blockchain.
  • Consensus nodes can usually be computer devices used by administrative agencies in various regions.
  • the consensus node in each consensus branch network includes a permission contract, which stores the flow logic of the entire life cycle of the electronic bill, such as the bill status of the electronic bill, the flow process, the access rights of the data, the conditions for applying for electronic bills, the conditions for issuing electronic bills, etc.
  • the consensus node also includes a cache and a data block, which can provide support for the chaining and query of transaction information.
  • this solution can realize cross-chain data transactions between different blockchains, such as cross-chain data transactions between different blockchains in the business network shown in Figure 4, or cross-chain data transactions between blockchains in the business network and blockchains in the formula network, or cross-chain data transactions between different blockchains in the formula network.
  • the first blockchain network to which the first blockchain in the embodiment of the present application belongs can be the same as the second blockchain network to which the second blockchain belongs, that is, the present application can realize cross-chain communication between different blockchains in the same blockchain network.
  • the first blockchain and the second blockchain are both blockchains in the above-mentioned consensus network 43, such as the first blockchain can be blockchain one, and the second blockchain can be blockchain two.
  • the blockchain network to which the first blockchain in the implementation of the present application belongs can be different from the blockchain network to which the second blockchain belongs, that is, the present application can realize cross-chain communication between different blockchains in different blockchain networks.
  • the first blockchain network to which the first blockchain belongs is business network 41
  • the second blockchain The second blockchain network is consensus network 43.
  • node devices in the blockchain network involved in the embodiments of the present application can be mobile phones, tablet computers, laptops, PDAs, mobile Internet devices (MID, mobile internet device), vehicles, roadside equipment, aircraft, wearable devices, such as smart watches, smart bracelets, pedometers and other smart devices with data processing functions, and the device type corresponding to each node device may be the same or different.
  • the embodiment of the present application can use blockchain one in the consensus network 43 shown in Figure 4 as the first blockchain, and blockchain two in the consensus network 43 shown in Figure 4 as the second blockchain.
  • the first node device can be any consensus node in blockchain one shown in Figure 4, and the second node device can be any consensus node in blockchain two shown in Figure 4.
  • the first node device can select a message encapsulation format that is compatible with the second blockchain from the cross-chain communication protocol on the first blockchain.
  • the cross-chain communication protocol includes the rules that need to be followed when conducting cross-chain transactions (such as cross-chain data transmission) between each node device. In other words, the cross-chain communication protocol needs to be satisfied between the node devices before cross-chain transactions can be conducted.
  • the target transaction data specifically refers to the transaction data that needs to be synchronized to the second node device.
  • the first node device is a node device for maintaining the first blockchain, that is, the first node device can obtain the transaction data required to be recorded by the first blockchain, generate a new block according to the transaction data required to be recorded by the first blockchain, and the first node device can add its newly generated block to the first blockchain.
  • the second node device is a node device for maintaining the second blockchain, that is, the second node device can obtain the transaction data required to be recorded by the second blockchain, generate a new block according to the transaction data required to be recorded by the second blockchain, and the second node device can add its newly generated block to the second blockchain. Both the first node device and the second node device meet the cross-chain communication protocol.
  • the message encapsulation format adapted to the second blockchain can include the data transaction structure, encoding mode, verification mode, and encryption mode used by the second blockchain. Since the data processing specifications on different blockchains are different, the cross-chain data (such as target transaction data, transaction verification information, and block header) that needs to be sent to the second blockchain can be encapsulated according to the message encapsulation format adapted to the second blockchain. In this way, the second node device can successfully parse the cross-chain data sent by the first node device.
  • the first node device may encapsulate the target transaction data and the transaction verification information of the target transaction data in the target block on the first blockchain according to the message encapsulation format to obtain a target data packet, and encapsulate the block header of the target block according to the message encapsulation format to obtain an encapsulated block header.
  • the target transaction data is transaction data specified by business requirements or a certain request.
  • the target block is a block recording the target transaction data.
  • the target data packet is a data packet obtained by encapsulating the target transaction data and the transaction verification information of the target transaction data.
  • the target transaction data is associated with the second node device, such as the target transaction data is the cross-chain data that the first node device corresponding to the first blockchain needs to send to the second node device, or the target transaction data can be the cross-chain data requested by the second node device corresponding to the second blockchain to the first node device.
  • the first node device can send a target data packet to a target relay server associated with the second node device, and send a target oracle server associated with the encapsulated block header to the second node device.
  • the target relay server is used to send the target data packet to the second node device, and the target oracle server is used to send the encapsulated block header to the second node device.
  • the target relay server and the target oracle server are both independent entities outside the blockchain.
  • the target relay server and the target oracle server outside the blockchain forward the target data packet and the encapsulated block header respectively.
  • this solution can achieve decentralization while also forming an open cross-chain ecosystem and improving the security of cross-chain data transmission.
  • the second node device can verify the target transaction data according to the data verification rules on the second blockchain, the encapsulated block header, and the transaction verification information in the target data packet.
  • the target transaction data in the target data packet is processed.
  • the data verification rules on the second blockchain are associated with the cross-chain communication protocol, that is, the data verification rules on the second blockchain can refer to those agreed in the cross-chain communication protocol.
  • the target oracle server and the relay server transmit the block header and the target data packet in a streaming manner.
  • this scheme only transmits the block header corresponding to the target transaction data, which can reduce the verification cost and thus reduce the cost of cross-chain transactions.
  • the trustless and effective transmission of any cross-chain data can be guaranteed.
  • the target transaction data is only verified based on the encapsulated block header and transaction verification information. The storage space on the second blockchain is consumed only when it is really needed (such as when the target transaction data is verified), which greatly saves the storage cost and storage fee on the chain.
  • Figure 5 is a schematic diagram of a scenario for cross-chain data interaction provided by an embodiment of the present application.
  • the first blockchain network 500 in the embodiment of the present application can be the above-mentioned core consensus network
  • the second blockchain network 510 in the embodiment of the present application can also be the above-mentioned core consensus network
  • the first blockchain 502 in the embodiment of the present application can be the blockchain one 431 in the above-mentioned core consensus network
  • the second blockchain 512 in the embodiment of the present application can be the blockchain two 432 in the above-mentioned core consensus network.
  • the first node device 501 in the embodiment of the present application can be a consensus node with a block-generating function and maintaining blockchain one 431 in the above-mentioned core consensus network, and the first node device 501 can be any one of the consensus nodes for maintaining blockchain one 431 shown in Figure 4 above.
  • the second node device 511 in the embodiment of the present application can be a consensus node with a block-generating function and maintaining blockchain two 432 in the above-mentioned core consensus network, and the second node device 511 can be any one of the consensus nodes for maintaining blockchain two 432 shown in Figure 4 above.
  • the first node device 501 and the second node device 511 both meet the cross-chain communication protocol, so that cross-chain data transactions can be implemented between the first node device 501 maintaining the first blockchain 502 and the second node device 511 maintaining the second blockchain 512.
  • the first node device 501 and the second node device 511 are different node devices maintaining different blockchains, such as the first node device 501 can be the management terminal in FIG. 4 above, and the second node device 511 can be the enterprise terminal in FIG. 4 above.
  • the business node in the business network can execute the transaction business with the target transaction data associated with the second node device 511, and then generate a transaction for broadcasting to the core consensus network (i.e., a transaction to be broadcasted) according to the transaction execution result of the transaction business.
  • the transaction business here can be a cross-chain data synchronization business, a cross-chain data transfer business, and the like, and the target transaction data can refer to the cross-chain transaction data between the first node device 501 and the second node device 511 (such as the cross-chain synchronization data that the first node device 501 needs to synchronize to the second node device 511, or the cross-chain transfer data between the first node device 501 and the second node device 511).
  • the target transaction data can be (account 1 in the first blockchain 502, account 2 in the second blockchain 512, 20), where account 1 represents a resource transfer-out account, account 2 represents a resource transfer-in account, 20 represents the amount of resources to be transferred, account 1 is an account in the first blockchain 502, and account 2 is an account in the second blockchain 512.
  • the first node device 501 when it receives the transaction to be broadcast sent by the business node through the proxy node, it can verify the received transaction to be broadcast. When the verification is successful, the received transaction to be broadcast is stored in the node transaction pool of the first node device 501, and a block corresponding to the target transaction data is generated. Further, the first node device 501 can send the block corresponding to the target transaction data to other node devices that maintain the first blockchain 502. When other node devices that maintain the first blockchain 502 successfully reach consensus on the block corresponding to the target transaction data, the first node device 501 can add the block corresponding to the target transaction data to the first blockchain 502 to obtain the target block 5021.
  • the first node device 501 can select a message encapsulation format adapted to the second blockchain 512 corresponding to the second node device 511 from the cross-chain communication protocol on the first blockchain, and the message encapsulation format may include the data transaction structure, encoding mode, verification mode, and encryption mode used by the second blockchain. Since the data processing specifications on different blockchains are different, the cross-chain data (such as target transaction data, transaction verification information, and block header) to be sent to the second blockchain 512 can be encapsulated according to the message encapsulation format adapted to the second blockchain 512, so that the second node device 511 can successfully parse the cross-chain data sent by the first node device 501.
  • the cross-chain data such as target transaction data, transaction verification information, and block header
  • the message encapsulation format adapted to the blockchain maintained by the corresponding node device can be added to the cross-chain communication protocol, so that data on different blockchains can be traded across chains.
  • the first node device 501 can obtain the target transaction data in the target block 5021 and the transaction verification information about the target transaction data, which is used to verify whether the target transaction data is in the first node device.
  • the first node device 501 can encapsulate the target transaction data and transaction verification information in the target block 5021 according to the message encapsulation format adapted to the second blockchain 512 to obtain the target data packet.
  • the first node device 501 can encapsulate the block header of the target block 5021 according to the message encapsulation format adapted to the second blockchain 512 to obtain the encapsulated block header.
  • the first node device 501 can send the target data packet to the target relay server 520, and send the encapsulated block header to the target oracle server.
  • the first node device 501 can also send the blockchain identifier of the second blockchain 512, so that the target relay server 520 can forward the target data packet to the second node device 511 that maintains the second blockchain 512 according to the blockchain identifier of the second blockchain 512.
  • the first node device 501 can also send the blockchain identifier of the second blockchain 512, so that the target oracle server 530 can forward the encapsulated block header to the second node device 511 that maintains the second blockchain 512 according to the blockchain identifier of the second blockchain 512.
  • the target relay server 520 and the target oracle server 530 are independent entities outside the blockchain. When the target relay server 520 receives the target data packet, it can automatically forward the target data packet to the second node device 511. When the target oracle server 530 receives the encapsulated block header, it can automatically forward the encapsulated block header to the second node device 511.
  • the second node device 511 can obtain the data verification rules on the second blockchain 512, which can be the verification rules agreed upon in the cross-chain communication protocol.
  • the second node device 511 can verify the target transaction data in the target data packet according to the data verification rules, the encapsulated block header and the transaction verification information in the target data packet, and obtain the verification result. If the verification result indicates that the target transaction data has been verified, the target transaction data is processed.
  • the transaction verification information may refer to the Merkle path corresponding to the target block
  • the second node device 511 may perform a hash algorithm on the target transaction data to obtain a hash value to be verified, and perform a hash algorithm on the hash value to be verified according to the Merkle path corresponding to the target block to obtain a tree root hash value to be verified.
  • the second node device 511 may obtain the Merkle tree hash value from the encapsulated block header, and the data verification rules on the second blockchain may include verification rules for the Merkle path.
  • the verification rules for the Merkle path are used to indicate that when the Merkle tree root hash value in the encapsulated block header is the same as the tree root hash value to be verified obtained based on the Merkle path, it is determined that the target transaction data verification has passed, and when the Merkle tree root hash value in the encapsulated block header is different from the tree root hash value to be verified obtained based on the Merkle path, it is determined that the target transaction data verification has not passed.
  • the second node device 511 determines that the Merkle root hash value in the encapsulated block header is the same as the root hash value to be verified, a verification result is generated to indicate that the target transaction data verification has passed; if the second node device 511 determines that the Merkle root hash value in the encapsulated block header is not the same as the root hash value to be verified, a verification result is generated to indicate that the target transaction data verification has not passed.
  • the target oracle server 530 and the relay server 520 transmit the encapsulated block header and the target data packet in a streaming manner.
  • this scheme only transmits the block header corresponding to the target transaction data, which can reduce the verification cost and thus reduce the cost of cross-chain transactions.
  • the target oracle server 530 and the relay server 520 transmit the data used to verify the target transaction data (i.e., the encapsulated block header and transaction verification information), which can improve the security of cross-chain data transmission.
  • the trustless and effective transmission of any cross-chain data can be guaranteed.
  • the target transaction data is only verified according to the encapsulated block header and transaction verification information, and the storage space on the second blockchain is consumed when it is really needed (such as when the target transaction data is verified). While ensuring security, the storage cost and storage fee on the chain are greatly saved.
  • Figure 6 is a flowchart of a blockchain data processing method provided by an embodiment of the present application.
  • the method can be executed by a first node device maintaining a first blockchain in a blockchain network.
  • the blockchain network can refer to the core consensus network mentioned above, or the business network mentioned above, or other blockchain networks.
  • the present application embodiment does not limit this.
  • the first node device can be a server connected to the blockchain network, or a user terminal connected to the blockchain network.
  • the first node device can refer to a server maintaining the first blockchain. Any node device in the node device of the block chain, the specific form of the first node device is not limited here.
  • the method may at least include but is not limited to the following steps:
  • the second blockchain is maintained by the second node device in the blockchain network, and the first node device and the second node device communicate according to the cross-chain communication protocol.
  • the first node device can select a message encapsulation format that is compatible with the second blockchain from the cross-chain communication protocol on the first blockchain.
  • the first node device is a node device that maintains the first blockchain.
  • the blocks on the first blockchain can be generated and added by the first node device.
  • the second node device is a node device that maintains the second blockchain.
  • the blocks on the second blockchain can be generated and added by the second node device.
  • both the first node device and the second node device satisfy the cross-chain communication protocol.
  • both the first node device and the second node device need to agree to the cross-chain communication protocol, and both the first node device and the second node device need to perform cross-chain transactions in accordance with the cross-chain communication protocol.
  • the cross-chain communication protocol records the operations that need to be performed and the rules that need to be followed when different blockchains conduct cross-chain transactions.
  • the message encapsulation format adapted to the second blockchain refers to the message encapsulation format applicable to the second blockchain.
  • the message encapsulation format complies with the data processing specification of the second blockchain. Messages encapsulated using the message encapsulation format can be correctly identified and processed at the nodes of the second blockchain.
  • the message encapsulation format complies with the cross-chain communication protocol.
  • the message encapsulation format adapted to the second blockchain can be pre-configured, and an association relationship between the blockchain identifier of the second blockchain and the message encapsulation format is established, so that the message encapsulation format adapted to the second blockchain can be determined based on the association relationship using the blockchain identifier of the second blockchain.
  • the message encapsulation format adapted to the second blockchain may include the data transaction structure, encoding mode, verification mode, encryption mode, etc. used in the second blockchain. Since the data processing specifications on different blockchains are different, the cross-chain data (such as target transaction data, transaction verification information, and block header) to be sent to the second blockchain can be encapsulated according to the message encapsulation format adapted to the second blockchain, so that the second node device can successfully parse the cross-chain data sent by the first node device.
  • the cross-chain data such as target transaction data, transaction verification information, and block header
  • the target smart contract on the first blockchain can be called to execute the transaction business corresponding to the target transaction data according to the transaction type of the target transaction data.
  • the target transaction data associated with the second node device can refer to the cross-chain transaction data between the first node device and the second node device (such as the cross-chain synchronization data that the first node device needs to synchronize to the second node device, or the cross-chain asset transfer data between the first node device and the second node device), wherein the cross-chain asset transfer data can be used for cross-chain transfer of virtual assets such as game coins, game diamonds, and electronic bills.
  • the target smart contract on the first blockchain is a contract that matches the transaction type of the target transaction data.
  • the transaction type of the target transaction data is a digital collection transaction
  • the target smart contract on the first blockchain can refer to a digital collection contract.
  • the target transaction data can be (account 1 in the first blockchain 502, account 2 in the second blockchain 512, 20), account 1 represents the resource transfer-out account, account 2 represents the resource transfer-in account, 20 represents the amount of resources to be transferred, account 1 is an account in the first blockchain 502, and account 2 is an account in the second blockchain 512.
  • the first node device calls the target business contract to execute the transaction business corresponding to the target transaction data, generates a target block about the target transaction data, and adds the target block corresponding to the target transaction data to the first blockchain.
  • the target transaction data is (account 1 in the first blockchain 502, account 2 in the second blockchain 512, 20)
  • the first node device can execute a transaction in which the account 1 of the first blockchain is deducted with a quantity of 20 resource data, and generates a target block corresponding to the target transaction data, and stores the target block corresponding to the target transaction data on the first blockchain.
  • the first node device can send the target transaction data to the second node device based on the cross-chain communication protocol on the first blockchain and the message encapsulation format adapted to the second blockchain.
  • the first blockchain includes a sub-ledger smart contract (SpvContract) generated based on the cross-chain communication protocol.
  • Selecting a message encapsulation format adapted to the second blockchain from a cross-chain communication protocol on the first blockchain includes: obtaining a blockchain identifier of the second blockchain; obtaining an adapter library set from a sub-ledger smart contract on the first blockchain, and determining a target adapter library associated with the second blockchain from the adapter library set according to the blockchain identifier of the second blockchain; and obtaining a message encapsulation format adapted to the second blockchain corresponding to the second node device from the target adapter library.
  • the sub-ledger smart contract on the first blockchain is used to implement cross-chain transactions between the first blockchain and other blockchains. It is an interface of the cross-chain communication protocol for the smart contract interface of the node devices corresponding to different blockchains to interact.
  • the specific method for the first node device to determine the message encapsulation format adapted to the second blockchain may include: obtaining the blockchain identifier of the second blockchain; obtaining an adapter library set from the sub-ledger smart contract on the first blockchain, and determining the target adapter library associated with the second blockchain from the adapter library set according to the blockchain identifier of the second blockchain; obtaining the message encapsulation format adapted to the second blockchain corresponding to the second node device from the target adapter library.
  • the first node device can obtain the blockchain identifier of the second blockchain, obtain the adapter library set from the sub-ledger smart contract on the first blockchain, and determine the target adapter library associated with the second blockchain from the adapter library set according to the blockchain identifier of the second blockchain.
  • the adapter library set included in the sub-ledger smart contract on the first blockchain includes adapter libraries associated with multiple blockchains, that is, one blockchain corresponds to one adapter library, and the adapter library includes the message encapsulation format of the corresponding blockchain, which helps to coordinate the interaction between the sub-ledger smart contracts on any two blockchains.
  • the adapter library Through the adapter library, data compatible with the corresponding blockchain can be constructed, and the encoding and decoding of smart contract information written in different blockchain standards can be processed.
  • the first node device can encapsulate the target transaction data that needs to be sent to the second node device into data that can be parsed by the second node device through the adapter library associated with the second blockchain, so that the second node device can parse and process the target transaction data sent by the first node device.
  • the adapter library set included in the sub-ledger smart contract on the first blockchain can be stored in the adapter library module (i.e., the auxiliary sub-ledger smart contract) of the sub-ledger smart contract on the first blockchain, and the adapter library in the adapter library module of the sub-ledger smart contract on the first blockchain is used to establish a compatible connection calculation with the corresponding blockchain to achieve cross-chain interaction with the node device maintaining the corresponding chain.
  • the first node device can add a new adapter library in the adapter library module of the sub-ledger smart contract on the first blockchain to support the new blockchain.
  • the node devices maintaining the first blockchain can store copies of all adapter libraries in the sub-ledger smart contract on the first blockchain, or can store copies of all adapter libraries. It can be understood that after adding a new adapter library in the adapter library module of the sub-ledger smart contract on the first blockchain, the first node device can perform cross-chain transactions with the corresponding new blockchain through the newly added adapter library. The first node device can obtain the message encapsulation format adapted to the second blockchain corresponding to the second node from the target adapter library. In this way, modularization can allow multiple adapter libraries to be inserted into the smart contract stack to ensure the ease of use of cross-chain transactions. At the same time, the adapter library can also be used to parse and verify the cross-chain data sent by the corresponding blockchain.
  • the specific content of adding a new adapter library to the adapter library set included in the sub-ledger smart contract on the first blockchain may include: when a cross-chain communication request sent by a third node device corresponding to a third blockchain is received, the validity of the third node device is verified according to the risk control rules and the cross-chain communication request in the cross-chain communication protocol to obtain a validity verification result; when the validity verification result indicates that the third node device is valid, a message encapsulation format adapted to the third blockchain is obtained; an adapter library associated with the third blockchain is generated according to the message encapsulation format adapted to the third blockchain; and the adapter library associated with the third blockchain is added to the adapter library set included in the sub-ledger smart contract on the first blockchain.
  • the risk control rules in the cross-chain communication protocol can be obtained, and the risk control rules in the cross-chain communication protocol stipulate the conditions for the validity of the node device.
  • the risk control rules in the cross-chain communication protocol stipulate that when the credit of the node device is greater than the target credit threshold, and the real name is verified, and a secure link is used (that is, relevant data transaction security measures are adopted), the node device is determined to be valid.
  • the node device can set the corresponding risk control rules according to needs.
  • the third node device needs to meet the cross-chain communication protocol, that is, the third node device needs to agree to the cross-chain communication protocol, and conduct cross-chain transactions with node devices corresponding to other blockchains in accordance with the cross-chain communication protocol. Furthermore, the third node device can generate a cross-chain communication request for cross-chain transactions to the first node device according to the cross-chain communication protocol, and the cross-chain communication request carries a method for verifying the third node device.
  • the device characteristic information of the validity of the third-node device such as the credibility of the third-node device, whether the third-node device has performed real-name authentication, and whether the third-node device uses security information of a secure link.
  • the validity of the third node device can be verified according to the risk control rules and the cross-chain communication request in the cross-chain communication protocol.
  • the risk control rules in the cross-chain communication protocol stipulate that the node device is valid only when the credit is greater than the target credit threshold, then the first node device can obtain the credit of the third node device from the cross-chain communication request. If the credit of the third node device is greater than the target credit threshold, the third node device is determined to be valid; if the credit of the third node device is less than or equal to the target credit threshold, the third node device is determined to be invalid.
  • the risk control rules in the cross-chain communication protocol stipulate that the node device is valid only when the real-name is required and the secure link is used, then the first node device can obtain the real-name information and security information about the third node device carried by the cross-chain communication request. If the third node device is real-named and uses a secure link, the third node device is determined to be valid; if the third node device is not real-named and does not use a secure link, the third node device is determined to be invalid.
  • the first node device can call the device validity verification model stored on the first blockchain, input the device feature information of the first node device into the device validity verification model on the first blockchain, and predict the validity of the third node device according to the risk control rules in the cross-chain communication protocol through the device validity verification model to obtain the validity prediction result of the third node device.
  • the validity prediction result of the third node device includes that the third node device is valid, or that the third node device is not valid. In this way, the validity of the third node device is predicted by the device validity verification model, which can improve the determination efficiency of the validity prediction of the third node device.
  • a message encapsulation format adapted to the third block is obtained. Specifically, when the third node device sends a cross-chain communication request to the first node device, the message encapsulation format adapted to the third node device is added to the cross-chain communication request, and the first node device can detect whether the cross-chain communication request sent by the third node device carries a message encapsulation format adapted to the third node device.
  • an adaptation library associated with the third blockchain is generated according to the message encapsulation format adapted to the third blockchain; if the cross-chain communication request sent by the third node device does not carry a message encapsulation format adapted to the third node device, the first node device sends a request to the third node device for obtaining the message encapsulation format adapted to the third node device, so as to obtain the message encapsulation format adapted to the third node device.
  • the first node device can add the adapter library associated with the third blockchain to the adapter library set included in the sub-ledger smart contract on the first blockchain, so that cross-chain transactions can be implemented between the first node device on the first blockchain and node devices on more blockchains.
  • S102 determine the target block where the target transaction data associated with the second node device is located, encapsulate the target transaction data and the transaction verification information of the target transaction data in the target block on the first blockchain according to the message encapsulation format adapted to the second blockchain to obtain a target data packet, and encapsulate the block header of the target block according to the message encapsulation format adapted to the second blockchain to obtain an encapsulated block header.
  • the first node device may obtain a blockchain identifier of a target block according to business needs or requests, and the blockchain identifier is used to identify the target block where the target transaction data associated with the second node device is located; further, the first power-saving device may determine the target block where the target transaction data associated with the second node device is located based on the blockchain identifier.
  • the first node device may determine the target transaction data associated with the second node device according to business needs or requests, and then locate the target block where the target transaction data is located.
  • a target block where target transaction data associated with a second node device is located is determined, and according to a message encapsulation format adapted to the second blockchain, the target transaction data and the transaction verification information of the target transaction data in the target block on the first blockchain are encapsulated to obtain a target data packet, and a block header of the target block is encapsulated according to the message encapsulation format adapted to the second blockchain to obtain an encapsulated block header, including: obtaining the target transaction data from the block body of the target block, encapsulating the target transaction data according to the transaction data encapsulation format in the message encapsulation format adapted to the second blockchain, and obtaining the encapsulated target transaction data; obtaining the transaction verification information of the target transaction data from the block header of the target block, and encapsulating the transaction data according to the transaction verification encapsulation format in the message encapsulation format adapted to the second blockchain.
  • the verification information is encapsulated to obtain encapsulated transaction verification information; the encapsulated target transaction data and the encapsulated transaction verification information are combined to obtain a target data packet; and the block header of the target block is encapsulated according to the block header encapsulation format in the message encapsulation format adapted to the second blockchain to obtain an encapsulated block header.
  • the first node device can obtain the target transaction data from the block body of the target block, and the target transaction data is associated with the second node device, that is, the target transaction data is the cross-chain data between the first node device and the second node device (such as the cross-chain synchronization data that the first node device needs to synchronize to the second node device, or the cross-chain transfer assets that the first node device needs to transfer to the second node device, etc.).
  • the message encapsulation format adapted to the second blockchain may include the transaction data encapsulation format regarding the target transaction data, the transaction verification encapsulation format regarding the transaction verification information, and the block header encapsulation format regarding the block header.
  • the first node device can encapsulate the target transaction data in the target block on the first blockchain according to the transaction data encapsulation format in the message encapsulation format adapted to the second blockchain, and obtain the encapsulated target transaction data.
  • the transaction data encapsulation format may include the transaction structure, transaction protocol, transaction encryption mode, and encoding mode of the transaction data in the first blockchain.
  • the transaction data encapsulation format indicates that the transaction structure is (resource transfer-out account, resource transfer-in account, amount of resources to be transferred), and the first node device needs to encapsulate the target transaction data according to the transaction data encapsulation format, such as (account 1 on the first blockchain, account 2 on the second blockchain, 20).
  • the first node device can also obtain the transaction verification information of the target transaction data from the block header of the target block, and the transaction verification information is used to verify whether the first node device has executed the transaction business corresponding to the target transaction data, that is, whether there is a transaction corresponding to the target transaction data on the first blockchain (such as whether there is a target block corresponding to the target transaction data).
  • the transaction verification information may include the Merkel path corresponding to the target block, the block address or the block information corresponding to the target block, and the block information of the target block may include the parent block hash value of the target block or the information in the block header of the target block.
  • the first node device can obtain the transaction verification encapsulation format from the message encapsulation format adapted to the second blockchain, encapsulate the transaction verification information, and obtain the encapsulated transaction verification information.
  • the transaction verification encapsulation format may include the verification information type about the transaction verification information (such as the Merkel path, the hash value of the parent block header or the block address, etc.), the information encryption mode and the information encoding mode, etc.
  • the first node device can combine the encapsulated target transaction data and the encapsulated transaction verification information to obtain the target data packet.
  • the first node device may obtain the block header corresponding to the target block from the target block of the first blockchain, and encapsulate the block header of the target block according to the block header encapsulation format included in the message encapsulation format adapted to the second blockchain to obtain an encapsulated block header.
  • the block header encapsulation format may include the block structure (such as information features, generation timestamp, version number, etc.) of the block header, the block encryption mode, and the block encoding mode, etc.
  • the first blockchain includes a sub-ledger smart contract generated based on the cross-chain communication protocol, that is, a sub-ledger smart contract written according to the data processing specification of the first blockchain and the cross-chain communication protocol.
  • the sub-ledger smart contract on the first blockchain is stored in each node device that maintains the first blockchain.
  • the sub-ledger smart contract on the first blockchain is automatically called to encapsulate the cross-chain data that needs to be transmitted, and transmit the encapsulated cross-chain data.
  • a target data packet is sent to a target relay server associated with the second node device, and an encapsulated block header is sent to a target oracle server associated with the second node device, the target relay server is used to send the target data packet to the second node device, the target oracle server is used to send the encapsulated block header to the second node device, and the second node device is used to process the target transaction data in the target data packet when the target transaction data is verified according to the data verification rules on the second blockchain, the encapsulated block header and the transaction verification information in the target data packet, and the data verification rules are associated with the cross-chain communication protocol.
  • the first node device sends a target data packet to a target relay server associated with the second node device, and sends an encapsulated block header to a target oracle server associated with the second node device.
  • the target relay server and the target oracle server are both independent entities outside the blockchain. In this way, the target relay server and the target oracle server outside the blockchain forward the target data packet and the encapsulated block header respectively.
  • this solution can achieve decentralization while also forming an open cross-chain ecosystem and improving the security of cross-chain data transmission.
  • the target relay server and the target oracle server are used.
  • the target data packet and encapsulated block header are sent through two channels respectively, which can improve the security of the transmission of the target data packet and the encapsulated block header and avoid the risk of single point attack. For example, when the target relay server is attacked and the target data packet is tampered with, after the second node device receives the encapsulated block header of the target oracle server and the tampered target data packet sent by the target relay server, the target transaction data verification will not pass because the encapsulated block header and the tampered transaction verification information or target transaction data do not match.
  • the target relay server is used to send the target data packet to the second node device, and the target oracle server is used to send the encapsulated block header to the second node device.
  • the second node device is used to process the target transaction data in the target data packet when the target transaction data is verified according to the data verification rules on the second blockchain, the encapsulated block header and the transaction verification information in the target data packet.
  • the data verification rules are associated with the cross-chain communication protocol, that is, the data verification rules are the verification rules for transaction data specified in the cross-chain communication protocol. Processing the target transaction data in the target data packet is to process the target transaction data according to normal business logic, such as transfer, accounting, etc.
  • the relay server is a server for forwarding data packets
  • the target relay server is a server for forwarding target data packets.
  • the oracle server is a server for forwarding encapsulated block headers.
  • the oracle in the oracle server may refer to the data required for the oracle server to provide the transaction data.
  • the target oracle server is a server for forwarding the encapsulated block header related to the target block, and the target oracle server can provide the data required for verifying the target transaction data.
  • the sub-ledger smart contract on the first blockchain may include a first dialogue module, a first verification module, a first network module, and a first adapter library module.
  • the first dialogue module is used to receive the cross-chain data (such as target transaction data, transaction verification information, and block header) that the first node device needs to transmit to the second node device through the cross-chain communication protocol.
  • the first node device can call the sub-ledger smart contract on the first blockchain, write the target transaction data into the first dialogue module, and write the blockchain identifier of the first blockchain and the blockchain identifier of the second blockchain at the same time.
  • the first dialogue module can encapsulate the target transaction data using the target adapter library adapted to the second blockchain to obtain the encapsulated target transaction data. Further, the first dialogue module can send the encapsulated target transaction data to the verification module. At the same time, the first dialogue module can encapsulate the transaction verification information of the target transaction data using the target adapter library adapted to the second blockchain to obtain the encapsulated transaction verification information, and send the encapsulated transaction verification information to the verification module. The first verification module can combine the encapsulated target transaction data and the encapsulated transaction verification information to obtain the target data packet. Furthermore, the first verification module may use the target data packet to notify the first network module that the block header of the target block needs to be sent to the second node device. At the same time, the first verification module may also use the target data packet to notify the target relay server to obtain the target data packet from the first blockchain.
  • the first network module can notify the target oracle server to obtain the block header of the target block from the first blockchain.
  • the target oracle server can send a request to obtain the block header of the target block to the first node device.
  • the first node device can call the first dialogue module to use the target adaptation library adapted to the second blockchain to encapsulate the block header of the target block to obtain an encapsulated block header.
  • the first dialogue module can send the encapsulated block header to the first network module, and the first network module sends the encapsulated block header to the target oracle server.
  • after the target relay server obtains the target data packet it can store the target data packet outside the chain.
  • the target relay server sends the target data packet to the second node device.
  • the target oracle server obtains the encapsulated block header, it can store the encapsulated block header outside the chain.
  • the target oracle server sends the encapsulated block header to the second node device.
  • a specific method in which the first node device sends a target data packet to a target relay server associated with the second node device may include: determining a candidate relay server associated with the second node device from a set of candidate relay servers; determining a target relay server from the candidate relay servers associated with the second node device; obtaining a first interface protocol of the target relay server, calling a sub-ledger smart contract on the first blockchain, and sending the target data packet to the target relay server according to the first interface protocol of the target relay server.
  • the first node device may obtain a candidate relay server associated with the second node device from the candidate relay server set.
  • the candidate relay server associated with the second node device may be a relay server trusted by the second node device. Or a relay server that establishes a communication connection with the second node device.
  • the first node device can determine the target relay server from the candidate relay server associated with the second node device, obtain the first interface protocol of the target relay server, call the sub-ledger smart contract on the first blockchain, and send the target data packet to the target relay server according to the first interface protocol of the target relay server.
  • node devices i.e., third parties
  • the first node device and the second node device can become relay servers after qualification review and interface adaptation, and the first node device or the second node device can select a trusted relay server on demand.
  • different blockchains can adaptively select trusted relay servers.
  • the rules for qualification review can be agreed upon in the cross-chain communication protocol, such as when the node device credit is higher than the preset credit threshold, and real-name is performed, and the availability of the service provided is higher than the target availability, and a secure link and other conditions are used, then it is determined that the node device meets the qualifications to become a relay server.
  • interface adaptation means that all relay servers communicate according to a unified interface protocol and are configured with respect to a data forwarding interface, so that a node device can use the data forwarding interface in the relay server to forward a target data packet to a corresponding node device.
  • calling a sub-ledger smart contract on the first blockchain and sending a target data packet to a target relay server according to a first interface protocol of the target relay server includes: calling a sub-ledger smart contract on the first blockchain and obtaining a first data communication mode and a first communication data format in the first interface protocol; generating a first data forwarding request carrying a target data packet and a blockchain identifier of a second blockchain according to the first communication data format; sending the first data forwarding request to a target relay server through the first data communication mode, the target relay server being used to obtain the blockchain identifier of the second blockchain carried in the first data forwarding request, and forwarding the target data packet to a second node device maintaining the second blockchain according to the blockchain identifier of the second blockchain.
  • the first node device can call the sub-ledger smart contract on the first blockchain to obtain the first data communication format and the first data communication mode in the first interface protocol.
  • the first data communication format can refer to the data format that the target relay server can parse, such as (original address, destination address, data to be forwarded).
  • the first data communication mode can refer to any one of Http (i.e., Http is a network transmission protocol)/TCP (i.e., a connection-oriented, reliable, byte stream-based transport layer communication protocol)/UDP (i.e., a method for sending encapsulated data packets without establishing a connection).
  • the first node device can generate a first data forwarding request carrying the target data packet and the blockchain identifier of the second blockchain according to the first communication data format. Furthermore, the first node device can send the first data forwarding request to the target relay server through the first data communication mode, and the target relay server can forward the target data packet to the second node device that maintains the second blockchain according to the blockchain identifier of the second blockchain carried in the first data forwarding request.
  • the specific content of the first node device determining the target relay server from the candidate relay servers associated with the second node device may include: if the number of candidate relay servers associated with the second node device is one, then determining the candidate relay server associated with the second node device as the target relay server. If the number of candidate relay servers associated with the second node device is at least two, then obtaining the credits corresponding to the at least two candidate relay servers respectively, and determining the candidate relay server with the largest credit among the at least two candidate relay servers as the target relay server.
  • the first node device may obtain the number of candidate relay servers associated with the second node device, detect whether the number of candidate relay servers associated with the second node device is greater than 1, and if the number of candidate relay servers associated with the second node device is equal to 1, the first node device may directly determine the candidate relay server associated with the second node device as the target relay server. If the number of candidate relay servers associated with the second node device is at least two, the first node device may determine the target relay server from at least two candidate relay servers. Specifically, the first node device may obtain the credits corresponding to at least two relay servers, and determine the candidate relay server with the maximum credit among at least two candidate relay servers as the target relay server.
  • the first node device may obtain the feature information corresponding to at least two candidate relay servers, and the feature information may include information such as credit, availability of services provided, and security. Further, the first node device may generate a device score corresponding to the candidate relay server according to the feature information corresponding to each candidate relay server, and determine the candidate relay server with the highest device score among at least two candidate relay servers as the target relay server. In this way, the first node device can select a target relay server that it trusts, thereby improving the security of data forwarding.
  • the specific manner in which the first node device sends the encapsulated block header to the target oracle server associated with the second node device may include: determining a candidate oracle server associated with the second node device from the set of candidate oracle servers; The target oracle server is determined according to the candidate oracle server associated with the second node device, the second interface protocol of the target oracle server is obtained, the sub-ledger smart contract on the first blockchain is called, and the encapsulated block header is sent to the target oracle server according to the second interface protocol of the target oracle server.
  • the first node device can obtain a candidate oracle server associated with the second node device from the candidate oracle server set, and the candidate oracle server associated with the second node device can be a oracle server trusted by the second node device, or a oracle server that establishes a communication connection with the second node device. Further, the first node device can determine the target oracle server according to the candidate oracle server associated with the second node device, and obtain the second interface protocol of the target oracle server, call the sub-ledger smart contract on the first blockchain, and send the encapsulated block header to the target oracle server according to the second interface protocol of the target oracle server.
  • node devices i.e., third parties
  • the first node device or the second node device can select a trusted oracle server on demand.
  • different blockchains can adaptively select trusted oracle servers.
  • the rules for qualification review can be agreed upon in the cross-chain communication protocol. For example, when the node device credit is higher than the device credit threshold, and real-name is performed, and the availability of the service provided is higher than the target availability, and a secure link is used, etc., it is determined that the node device meets the qualifications to become a oracle server.
  • the device credit threshold may be the same as or different from the preset credit threshold required when becoming a relay server.
  • Interface adaptation means that all oracle servers communicate according to a unified interface protocol and configure a data forwarding interface, so that the node device can use the data forwarding interface in the oracle server to forward the encapsulated block header to the corresponding node device.
  • the first node device calls the sub-ledger smart contract on the first blockchain, and according to the second interface protocol of the target oracle server, the specific method of sending the encapsulated block header to the target oracle server may include: calling the sub-ledger smart contract on the first blockchain, obtaining the second data communication method and the second communication data format of the second interface protocol. According to the second communication data format, a second data forwarding request carrying the encapsulated block header and the blockchain identifier of the second blockchain is generated.
  • the second data forwarding request is sent to the target oracle server through the second data communication method; the target oracle server is used to forward the encapsulated block header to the second node device that maintains the second blockchain according to the blockchain identifier of the second blockchain carried in the second data forwarding request.
  • the first node device can call the sub-ledger smart contract on the first blockchain to obtain the second data communication format and the second data communication mode in the second interface protocol.
  • the second data communication format can refer to the data format that the target oracle server can parse, such as (original address, destination address, data to be forwarded).
  • the second data communication mode can refer to any one of Http (i.e., Http is a network transmission protocol)/TCP (i.e., a connection-oriented, reliable, byte stream-based transport layer communication protocol)/UDP (i.e., a method for sending encapsulated data packets without establishing a connection).
  • the first node device can generate a second data forwarding request carrying the encapsulated block header and the blockchain identifier of the second blockchain according to the second communication data format. Furthermore, the first node device can send the second data forwarding request to the target oracle server through the second data communication mode, and the target oracle server can forward the encapsulated block header to the second node device that maintains the second blockchain according to the blockchain identifier of the second blockchain carried in the second data forwarding request.
  • the specific content of the first node device determining the target oracle server according to the candidate oracle server associated with the second node device may include: if the number of candidate oracle servers associated with the second node device is one, then the candidate oracle server associated with the second node device is determined as the target oracle server. If the number of candidate oracle servers associated with the second node device is at least two, then the credits corresponding to the at least two candidate oracle servers are obtained, and the candidate oracle server with the largest credit among the at least two candidate oracle servers is determined as the target oracle server.
  • the first node device can obtain the number of candidate oracle servers associated with the second node device, and detect whether the number of candidate oracle servers associated with the second node device is greater than 1. If the number of candidate oracle servers associated with the second node device is equal to 1, the first node device can directly determine the candidate oracle server associated with the second node device as the target oracle server. If the number of candidate oracle servers associated with the second node device is at least two, the first node device can determine the target oracle server from at least two candidate oracle servers.
  • the first node device can obtain the credit corresponding to at least two oracle servers respectively, and determine the candidate oracle server with the maximum credit among at least two candidate oracle servers as the target oracle server.
  • the first node device can obtain the characteristic information corresponding to at least two candidate oracle servers respectively, and the characteristic information may include information such as credit, availability of services provided, and security.
  • the first node device can generate a device score for the corresponding candidate oracle server based on the characteristic information corresponding to each candidate oracle server, and determine the candidate oracle server with the highest device score among at least two candidate oracle servers as the target oracle server. In this way, the first node device can select a target oracle server that it trusts, which can improve the security of data forwarding.
  • the target oracle server is used to send the encapsulated block header to the second node device when the number of blocks is greater than the target number threshold; the number of blocks is the number of blocks on the first blockchain whose generation timestamp is later than the generation timestamp of the target block. It is understandable that after obtaining the encapsulated block header corresponding to the target block on the first blockchain, the target oracle server can store the encapsulated block header outside the blockchain (such as the target oracle server locally). At the same time, the target oracle server can obtain the number of blocks corresponding to the blocks on the first blockchain whose generation timestamp is later than the generation timestamp of the target block, that is, obtain the number of block confirmations corresponding to the target block.
  • the number of block confirmations corresponding to the target block is increased by one.
  • the target oracle server determines that the block data is greater than the target data threshold, it means that the target block has reached finality on the first blockchain, and the target oracle server can send the encapsulated block header to the second node device.
  • the target block reaches finality on the first blockchain, which means that the target block cannot be revoked or changed.
  • the encapsulated block header is sent to the second node device only when the target block reaches finality on the first blockchain, which can ensure the successful execution of the cross-chain transaction.
  • the target relay server is used to send the target data packet to the second node device when the target transaction data in the target data packet is verified according to the block header of the target block on the first blockchain. It is understandable that after the target relay server obtains the target data packet, the target data packet can be stored outside the blockchain (such as the target relay server locally). At the same time, the target relay server can verify the target transaction data according to the block header of the target block on the first blockchain, that is, verify whether the first node device executes the transaction business corresponding to the target transaction data.
  • the target relay server can send the target data packet to the second node device; if the target transaction data is not verified, the target relay server can determine the target data packet as an invalid message and eliminate the invalid message to prevent attacks.
  • invalid messages from the same source i.e., the same node device
  • malicious behavior reports will be made to reduce the credit of the corresponding node device.
  • the second node device can parse the target data packet to obtain the target transaction data and transaction verification information. Further, the second node device can verify the target transaction data, that is, verify whether the first node device successfully executes the transaction business corresponding to the target transaction data. Specifically, the second node device can verify the target transaction data based on the encapsulated block header and the transaction verification information, wherein the encapsulated block header includes relevant information of the target block, such as the characteristic value of the target transaction data (such as the Merkle tree root hash value), the block generation timestamp, the parent block hash value, etc.
  • the second blockchain includes a sub-ledger smart contract generated based on the cross-chain communication protocol.
  • the second node device After the second node device receives the target data packet and the encapsulated block header, it can call the sub-ledger smart contract on the second blockchain to verify the target transaction data.
  • Figure 7 is a schematic diagram of a cross-chain communication provided by an embodiment of the present application.
  • the first blockchain includes a sub-ledger smart contract generated based on the cross-chain communication protocol
  • the second blockchain includes a sub-ledger smart contract generated based on the cross-chain communication protocol.
  • the first node device that maintains the first blockchain receives the target transaction data, it can call the target smart contract on the first blockchain (such as the application contract that executes the target transaction data) according to the transaction type of the target transaction data to execute the transaction business corresponding to the target transaction data.
  • the first node device can generate a target block about the target transaction data and add the target block to the first blockchain.
  • the first node device can call the sub-ledger smart contract on the first blockchain when calling the target smart contract on the first blockchain to execute the transaction business corresponding to the target transaction data, and encapsulate the cross-chain data that needs to be sent to the second node device (such as the target transaction data, the transaction verification information of the target transaction data, and the block header of the target block), and seal the target transaction data and the transaction verification information of the target transaction data.
  • the target data packet obtained by encapsulation is sent to the target relay server (the target relay server may be determined by the first node device from the candidate relay server).
  • the first node device may call the sub-ledger smart contract on the first blockchain, and send the encapsulated block header obtained by encapsulating the block header of the target block to the target oracle server (the target oracle server may be determined by the first node device from the candidate oracle server).
  • the target oracle server may be determined by the first node device from the candidate oracle server.
  • the target oracle server can obtain the number of blocks on the first blockchain whose generation timestamp is later than the generation timestamp of the target block, and send the encapsulated block header to the second node device when the number of blocks is greater than the target number threshold. That is, when the target oracle server determines that the target block has reached finality on the first blockchain, it sends the encapsulated block header to the second node device.
  • the target relay server can determine that the target transaction data in the target data packet is verified according to the block header of the target block on the first blockchain, and then send the target data packet to the second node device.
  • the target relay server and the target oracle server are both independent entities outside the blockchain.
  • the first node device will synchronize the target transaction data and other data associated with the second node device to the second node device. There is no need to synchronize all the data on the first blockchain to the second node device, so as to reduce the data transmission cost and greatly save the storage cost and storage fee on the chain.
  • the sub-ledger smart contract on the second blockchain can be called to verify the target transaction data according to the data verification rules on the second blockchain and the transaction verification information in the encapsulated block header and the target data packet.
  • the sub-ledger smart contract on the second blockchain is called to send the target transaction data to the target smart contract on the second blockchain to execute the transaction business corresponding to the target transaction data.
  • the target smart contract on the second blockchain is determined based on the transaction type of the target transaction data. In this way, the on-chain verification of the target transaction data can be achieved, the target transaction data can be prevented from being tampered with, the security of the target transaction data can be improved, and the security and efficiency of cross-chain communication can be improved.
  • a general cross-chain communication architecture is provided, and the cross-chain communication architecture formulates a cross-chain communication protocol, which includes data encapsulation formats adapted to multiple blockchains, and access conditions (i.e., risk control rules) for node devices corresponding to blockchains to join cross-chain communication, etc.
  • the cross-chain communication architecture includes a oracle server and a relay server for implementing cross-chain communication.
  • the first node device corresponding to the first blockchain and the second node device corresponding to the second blockchain both meet the cross-chain communication protocol, that is, the first node device and the second node device both meet the access conditions for cross-chain communication in the cross-chain communication protocol, which is conducive to ensuring the security of cross-chain communication.
  • the first node device can select a data encapsulation format adapted to the second blockchain from the cross-chain communication protocol on the first blockchain, encapsulate the target transaction data and the transaction verification information of the target transaction data in the target block on the first blockchain, obtain the target data packet, and encapsulate the block header of the target block according to the message encapsulation format adapted to the second blockchain to obtain the encapsulated block header.
  • This is conducive to the second node device being able to successfully parse the target data packet and the encapsulated block header, and realize the interconnection between the first node device and the second node device, that is, realize the interconnection between the first blockchain and the second blockchain, that is, realize cross-chain communication.
  • the first node device can send the target data packet and the encapsulated block header in two independent ways, that is, send the target data packet to the target relay server associated with the second node device in the cross-chain communication architecture, send the encapsulated block header to the target oracle server associated with the second node device in the cross-chain communication architecture, and send the target data packet to the second node device by the relay server, and send the encapsulated block header to the second node device by the target oracle server.
  • the target relay server and the target oracle server are both independent entities outside the blockchain.
  • the first node device synchronizes the target transaction data and other data associated with the second node device to the second node device, and does not need to synchronize all the data on the first blockchain to the second node device, so as to reduce the data transmission cost and greatly save the storage cost and storage fee on the chain.
  • the second node device After the second node device obtains the target data packet and the encapsulated block header, the second node device processes the target transaction data in the target data packet only when the target transaction data is verified according to the data verification rules on the second blockchain, the encapsulated block header and the transaction verification information in the target data packet, so as to realize the on-chain verification of the target transaction data, avoid the target transaction data from being tampered with, improve the security of the target transaction data, and improve the security and efficiency of cross-chain communication.
  • Figure 8 is a flow chart of a blockchain data processing method provided in an embodiment of the present application.
  • the method can be executed by a second node device that maintains a second blockchain in a blockchain network.
  • the blockchain network can refer to the core consensus network mentioned above, or the business network mentioned above, or other blockchain networks.
  • the embodiment of the present application is not limited here.
  • the second node device can be a server connected to the blockchain network, or a user terminal connected to the blockchain network.
  • the second point device can refer to any node device in the node device that maintains the second blockchain.
  • the specific form of the second node device is not limited here.
  • the method may at least include, but is not limited to, the following steps:
  • the target data packet is parsed to obtain the target transaction data in the target data packet and the transaction verification information of the target transaction data.
  • the target data packet is sent from the first node device maintaining the first blockchain to the target relay server, the encapsulated block header is sent from the first node device to the target oracle server, the target data packet is obtained by encapsulating the target transaction data and the transaction verification information of the target transaction data based on the message encapsulation format adapted to the second blockchain maintained by the second node device, the target transaction data is the transaction data in the target block of the first blockchain, the encapsulated block header is obtained by encapsulating the block header of the target block based on the message encapsulation format; the message encapsulation format is selected from the cross-chain communication protocol on the first blockchain, and the first node device and the second node device communicate in accordance with the cross-chain communication protocol.
  • the message encapsulation format is selected from the cross-chain communication protocol on the first blockchain, and the first node device and the second node device communicate in accordance with the cross-chain communication protocol.
  • the target transaction data is verified according to the encapsulated block header and the transaction verification information to obtain a verification result.
  • the second node device obtains the data verification rule on the second blockchain, and the data verification rule is associated with the cross-chain communication protocol.
  • the data verification rule can be a verification rule for transaction data (such as target transaction data) agreed in the cross-chain communication protocol.
  • the first node device can verify the target transaction data according to the encapsulated block header and the transaction verification information to obtain a verification result, which includes that the target transaction data verification is passed, or that the target transaction data verification is not passed.
  • the transaction verification information may include the Merkel path corresponding to the target block, the block information of the target block (such as the generation timestamp, block address, block version number, etc.), and the parent block hash value corresponding to the target block.
  • the data verification rules may include verification rules on the Merkel path, verification rules on the parent block hash value, and verification rules on block information.
  • the second blockchain includes a sub-ledger smart contract generated based on the cross-chain communication protocol
  • the transaction verification information includes a Merkle path associated with the target block
  • the data verification rules on the second blockchain include verification rules about the Merkle path.
  • the specific method for the second node device to verify the target transaction data according to the encapsulated block header and the transaction verification information may include: calling the sub-ledger smart contract on the second blockchain, performing a hash algorithm on the target transaction data to obtain a hash value to be verified, performing a hash operation on the hash value to be verified according to the Merkle path, and obtaining a tree root hash value to be verified. Obtain the Merkle tree root hash value from the encapsulated block header.
  • the consistency check result indicates that the Merkle root hash value in the encapsulated block header is the same as the root hash value to be verified, a verification result indicating that the target transaction data verification has passed is generated; if the consistency check result indicates that the Merkle root hash value in the encapsulated block header is different from the root hash value to be verified, a verification result indicating that the target transaction data verification has failed is generated.
  • the Merkle tree also known as the hash binary tree, is a method for efficiently summarizing and verifying the integrity of large data sets.
  • the Merkle tree is a data structure of a transaction data structure, including a Merkle path from the transaction data to the tree root.
  • the Merkle tree is generated by combining leaf nodes in pairs. Therefore, the root hash value can be obtained according to the Merkle path from the target transaction data to the tree root.
  • the second node device can call the sub-ledger smart contract on the second blockchain, perform a hash algorithm on the target transaction data, obtain a hash value to be verified, and perform a hash operation on the hash value to be verified according to the Merkle path to obtain a tree root hash value to be verified.
  • the verification rule for the Merkle path is used to indicate that when the Merkle tree root hash value in the encapsulated block header is the same as the tree root hash value to be verified, it is determined that the target transaction data verification has passed; when the Merkle tree root hash value in the encapsulated block header is different from the tree root hash value to be verified, it is determined that the target transaction data verification has not passed.
  • the second node device can obtain the Merkle tree root hash value from the encapsulated block header according to the verification rule for the Merkle path. If the Merkle tree root hash value in the encapsulated block header is the same as the tree root hash value to be verified, a verification result indicating that the target transaction data verification has passed is generated. If the Merkle tree root hash value in the encapsulated block header is different from the root hash value to be verified, a verification result is generated indicating that the target transaction data verification has failed.
  • the transaction verification information includes the target block hash value of the parent block of the target block
  • the data verification rule on the second blockchain includes a verification rule for the target block hash value of the parent block of the target block.
  • the specific method for the second node device to verify the target transaction data according to the encapsulated block header and the transaction verification information may include: calling the sub-ledger smart contract on the second blockchain, obtaining the block hash value of the parent block of the target block from the encapsulated block header as the parent block hash value to be verified. Perform consistency comparison on the parent block hash value to be verified and the target parent block hash value to obtain a second comparison result, and generate a verification result indicating whether the target transaction data has passed the verification according to the second comparison result.
  • the verification rule for the target parent block hash value indicates that when the target parent block hash value in the encapsulated block header is the same as the parent block hash value to be verified in the encapsulated block header, it is determined that the target transaction data has passed the verification; when the target parent block hash value in the encapsulated block header is different from the parent block hash value to be verified in the encapsulated block header, it is determined that the target transaction data has not passed the verification.
  • the second node device if the hash value of the parent block to be verified and the hash value of the target parent block are the same, the second node device generates a verification result indicating that the target transaction data has been verified; if the hash value of the parent block to be verified and the hash value of the target parent block are not the same, the second node device generates a verification result indicating that the target transaction data has been verified.
  • the second node device can call the target smart contract on the second blockchain to process the target transaction data in the target data packet.
  • the target smart contract on the second blockchain is associated with the target transaction data. It can be understood that the target smart contract on the second blockchain is determined based on the transaction type of the target transaction data. If the transaction type of the target transaction data is a digital collection transaction, the target smart contract on the second blockchain can refer to a digital collection contract.
  • the second blockchain includes a sub-ledger smart contract generated based on the cross-chain communication protocol
  • the sub-ledger smart contract on the second blockchain includes a second dialogue module, a second verification module, a second network module, and a second adapter library module.
  • the second dialogue module can be used to encapsulate cross-chain data
  • the second verification module is used to verify transaction data
  • the second network module is used for communication
  • the second adapter library module is used to store the adapter library associated with the blockchain.
  • the target oracle server can send the encapsulated block header to the second network module
  • the second network module can forward the encapsulated block header to the second verification module.
  • the target relay server can send the target data packet to the second verification module.
  • the second verification module can verify the target transaction data according to the encapsulated block header and the transaction verification information according to the data verification rules on the second blockchain.
  • the second verification module can send the target transaction data to the second dialogue module, and the second dialogue module can send the target transaction data to the target smart contract on the second blockchain according to the contract address of the target smart contract, and call the target smart contract on the second blockchain to process the target transaction data.
  • the target transaction data is (account 1 in the first blockchain 502, account 2 in the second blockchain 512, 20), account 1 represents the resource transfer-out account, account 2 represents the resource transfer-in account, 20 represents the amount of resources to be transferred, account 1 is an account in the first blockchain 502, and account 2 is an account in the second blockchain 512.
  • the first node device can call the smart contract on the first blockchain regarding asset transactions, execute the transaction indicated by the target transaction data, in which the account 1 of the first blockchain is deducted 20 resource data, and generate a target block corresponding to the target transaction data, and store the target block corresponding to the target transaction data on the first blockchain. Furthermore, the first node device can call the sub-contractor on the first blockchain.
  • the ledger smart contract sends the target data packet containing the target transaction data and transaction verification information to the second node device through the target relay server.
  • the first node device can call the sub-ledger smart contract on the first blockchain and send the encapsulated block header corresponding to the target block to the second node device through the target oracle server.
  • the second node device can verify the target transaction data according to the encapsulated block header and transaction verification information through the sub-ledger smart contract on the second blockchain. When the target transaction data is verified, the second node device can call the smart contract for asset transactions on the second blockchain to execute the transaction of adding 20 resource data to the account 2 of the second blockchain indicated by the target transaction data.
  • FIG. 9 is an application schematic diagram of a cross-chain communication provided by an embodiment of the present application.
  • the first node device 90A can call the target smart contract in the first blockchain to execute the transaction business corresponding to the target transaction data.
  • the target smart contract on the first blockchain is determined based on the transaction type of the target transaction data.
  • the first node device 90A can generate a target block 911A for the transaction business corresponding to the target transaction data, and add the target block 911A to the first blockchain 91A.
  • the first node device can call the sub-ledger smart contract 82A on the first blockchain, which is based on the contract writing specification on the first blockchain 91A and the cross-chain communication protocol.
  • the sub-ledger smart contract 82A includes a first dialogue module, a first verification module, a first network module, and a first adapter library module.
  • the first node device 90A selects a message encapsulation format adapted to the second blockchain corresponding to the second node device 90D from the first adapter library module through the first dialogue module in the sub-ledger smart contract 82A.
  • the first dialogue module can encapsulate the target transaction data and the target transaction data in the target block 911A using a message encapsulation format adapted to the second blockchain to obtain a target data packet, and encapsulate the block header of the target block 911A using a message encapsulation format adapted to the second blockchain to obtain an encapsulated block header.
  • the first dialogue module may send the target data packet to the first verification module, and the first verification module may send a notification of obtaining the target data packet to the target relay server 90B to notify the target relay server to obtain the target data packet from the first node device 90A.
  • the target relay server 90B may obtain the target data packet from the first node device 90A.
  • the target relay server 90B may verify the target transaction data according to the block header of the target block 911A on the first blockchain, and after determining that the target transaction data has been verified, forward the target data packet to the second node device 90D.
  • the first verification module can send the blockchain identifier of the second blockchain to the first network module, and the first network module can send a request to obtain the encapsulated block header to the target oracle server 90C based on the blockchain identifier of the second blockchain.
  • the acquisition request carries the block identifier of the target block 911A.
  • the acquisition request is used to instruct the target oracle server 90C to obtain the encapsulated block header from the first node device 90A, and instruct the target oracle server 90C to forward the encapsulated block header to the second node device 90D.
  • the target oracle server 90C can obtain the encapsulated block header from the first node device based on the block identifier of the target block. After obtaining the encapsulated block header corresponding to the target block 911A on the first blockchain, the target oracle server 90C can store the encapsulated block header outside the blockchain (such as the target oracle server 90C locally). At the same time, the target oracle server 90C can obtain the number of blocks corresponding to the blocks whose generation timestamps on the first blockchain 91A are later than the generation timestamps of the target blocks.
  • the target oracle server 90C determines that the block data is greater than the target data threshold, it means that the target block 911A has reached finality on the first blockchain, and the target oracle server 90C can send the encapsulated block header to the second node device 90D.
  • the second blockchain includes a sub-ledger smart contract 91D based on the contract writing specification on the second blockchain and the cross-chain communication protocol, and the sub-ledger smart contract 91D includes a second dialogue module, a second verification module, a second network module, and a second adapter library module.
  • the target relay server 90B can forward the target data packet to the second network module, and the target oracle server can forward the encapsulated block header to the second verification module.
  • the second network module can forward the encapsulated block header to the second verification module, and the second verification module can obtain the data verification rules on the second blockchain, and verify the target transaction data according to the encapsulated block header and the transaction verification information to obtain the verification result. If the target transaction data is verified, the second verification module can forward the target transaction data to the second dialogue module, and the second dialogue module can forward the target transaction data to the target smart contract on the second blockchain.
  • the target smart contract on the second blockchain is associated with the target transaction data. It can be understood that the target smart contract on the second blockchain is determined based on the transaction type of the target transaction data. If the transaction type of the target transaction data is a digital collection transaction, the target smart contract on the second blockchain can refer to the digital collection contract.
  • the second node device only processes the target transaction data in the target data packet when the target transaction data is verified according to the data verification rules on the second blockchain, the encapsulated block header and the transaction verification information in the target data packet, so as to realize the on-chain verification of the target transaction data, avoid the target transaction data from being tampered with, improve the security of the target transaction data, and improve the security and efficiency of cross-chain communication.
  • a general cross-chain communication architecture is provided, and the cross-chain communication architecture formulates a cross-chain communication protocol, which includes data encapsulation formats adapted to multiple blockchains, and access conditions (i.e., risk control rules) for node devices corresponding to blockchains to join cross-chain communication, etc.
  • the cross-chain communication architecture includes a oracle server and a relay server for implementing cross-chain communication.
  • the first node device corresponding to the first blockchain and the second node device corresponding to the second blockchain both meet the cross-chain communication protocol, that is, the first node device and the second node device both meet the access conditions for cross-chain communication in the cross-chain communication protocol, which is conducive to ensuring the security of cross-chain communication.
  • the first node device can select a data encapsulation format adapted to the second blockchain from the cross-chain communication protocol on the first blockchain, encapsulate the target transaction data and the transaction verification information of the target transaction data in the target block on the first blockchain, obtain the target data packet, and encapsulate the block header of the target block according to the message encapsulation format adapted to the second blockchain to obtain the encapsulated block header.
  • This is conducive to the second node device being able to successfully parse the target data packet and the encapsulated block header, and realize the interconnection between the first node device and the second node device, that is, realize the interconnection between the first blockchain and the second blockchain, that is, realize cross-chain communication.
  • the first node device can send the target data packet and the encapsulated block header in two independent ways, that is, send the target data packet to the target relay server associated with the second node device in the cross-chain communication architecture, send the encapsulated block header to the target oracle server associated with the second node device in the cross-chain communication architecture, send the target data packet to the second node device by the relay server, and send the encapsulated block header to the second node device by the target oracle server.
  • the target relay server and the target oracle server are both independent entities outside the blockchain.
  • the risk of single-point forwarding being attacked can be avoided by forwarding the target data packet and the encapsulated block header respectively by two independent entities outside the blockchain, thereby improving the security of cross-chain communication.
  • the trustless and effective transmission of any cross-chain data can be guaranteed, thereby improving the security of cross-chain data transmission.
  • the first node device synchronizes the target transaction data and other data associated with the second node device to the second node device, and does not need to synchronize all data on the first blockchain to the second node device, so as to reduce the data transmission cost and greatly save the storage cost and storage fee on the chain.
  • the second node device After the second node device obtains the target data packet and the encapsulated block header, the second node device processes the target transaction data in the target data packet only when the target transaction data is verified according to the data verification rules on the second blockchain, the encapsulated block header and the transaction verification information in the target data packet, so as to realize the on-chain verification of the target transaction data, avoid the target transaction data from being tampered with, improve the security of the target transaction data, and improve the security and efficiency of cross-chain communication.
  • the target transaction data is verified according to the data verification rules on the second blockchain, the encapsulated block header and the transaction verification information in the target data packet, and the on-chain storage is consumed only when it is really needed, which greatly saves the on-chain storage cost and fees.
  • the blockchain data processing device 1 can be a computer-readable instruction (including program code) running in a computer device.
  • the blockchain data processing device 1 is an application software; the blockchain data processing device 1 can be used to execute the corresponding steps in the method provided in the embodiment of the present application.
  • the blockchain data processing device 1 can be a first node device for maintaining a first blockchain.
  • the blockchain data processing device 1 may include: a selection module 11, a packaging module 12, a sending module 13, a device verification module 14, an acquisition module 15, a generation module 16, and an addition module 17.
  • a selection module 11 is used to select a message encapsulation format adapted to the second blockchain from a cross-chain communication protocol on the first blockchain, the first blockchain is maintained by a first node device in the blockchain network, the second blockchain is maintained by a second node device in the blockchain network, and the first node device and the second node device communicate in accordance with the cross-chain communication protocol;
  • the encapsulation module 12 is used to determine the target block where the target transaction data associated with the second node device is located, encapsulate the target transaction data and the transaction verification information of the target transaction data in the target block on the first blockchain according to the message encapsulation format adapted to the second blockchain to obtain a target data packet, and encapsulate the block header of the target block according to the message encapsulation format adapted to the second blockchain to obtain an encapsulated block header;
  • the sending module 13 is used to send a target data packet to a target relay server associated with the second node device, and to send an encapsulated block header to a target oracle server associated with the second node device.
  • the target relay server is used to send a target data packet to the second node device.
  • the target oracle server is used to send an encapsulated block header to the second node device.
  • the second node device is used to process the target transaction data in the target data packet when the target transaction data is verified according to the data verification rules on the second blockchain, the encapsulated block header and the transaction verification information in the target data packet.
  • the data verification rules are associated with the cross-chain communication protocol to send the target data packet to the target relay server associated with the second node device.
  • the first blockchain includes a sub-ledger smart contract generated based on the cross-chain communication protocol;
  • the selection module 11 includes: a first acquisition unit 1101, used to obtain the blockchain identifier of the second blockchain; a first determination unit 1102, used to obtain an adaptation library set from the sub-ledger smart contract on the first blockchain, and determine the target adaptation library associated with the second blockchain from the adaptation library set according to the blockchain identifier of the second blockchain; a second acquisition unit 1103, used to obtain a message encapsulation format adapted to the second blockchain corresponding to the second node device from the target adaptation library.
  • the blockchain data processing device 1 also includes: a device verification module 14, which is used to verify the validity of the third node device according to the risk control rules and the cross-chain communication request in the cross-chain communication protocol when a cross-chain communication request is received from the third node device corresponding to the third blockchain, and obtain a validity verification result; an acquisition module 15, which is used to obtain a message encapsulation format adapted to the third blockchain when the validity verification result indicates that the third node device is valid; a generation module 16, which is used to generate an adaptation library associated with the third blockchain according to the message encapsulation format adapted to the third blockchain; an adding module 17, which is used to add the adaptation library associated with the third blockchain to the adaptation library set included in the sub-ledger smart contract on the first blockchain.
  • a device verification module 14 which is used to verify the validity of the third node device according to the risk control rules and the cross-chain communication request in the cross-chain communication protocol when a cross-chain communication request is received from the third node device corresponding to the third blockchain, and obtain
  • the encapsulation module 12 includes: a first encapsulation unit 1201, which is used to obtain target transaction data from the block body of the target block, and encapsulate the target transaction data according to the transaction data encapsulation format in the message encapsulation format adapted to the second blockchain to obtain encapsulated target transaction data; a second encapsulation unit 1202, which is used to obtain transaction verification information of the target transaction data from the block header of the target block, and encapsulate the transaction verification information according to the transaction verification encapsulation format in the message encapsulation format adapted to the second blockchain to obtain encapsulated transaction verification information; a combination unit 1203, which is used to combine the encapsulated target transaction data and the encapsulated transaction verification information to obtain a target data packet;
  • the third encapsulation unit 1204 is used to encapsulate the block header of the target block according to the block header encapsulation format in the message encapsulation format adapted to the second blockchain to obtain an encapsulated block header.
  • the sending module 13 includes: a second determining unit 1301, used to determine a candidate relay server associated with the second node device from the candidate relay server set; a third determining unit 1302, used to determine a target relay server from the candidate relay servers associated with the second node device;
  • the first sending unit 1303 is used to obtain the first interface protocol of the target relay server, call the sub-ledger smart contract on the first blockchain, and send the target data packet to the target relay server according to the first interface protocol of the target relay server.
  • the first sending unit 1303 is specifically used to: call the sub-ledger smart contract on the first blockchain, obtain the first data communication mode and the first communication data format in the first interface protocol; generate a first data forwarding request carrying the target data packet and the blockchain identifier of the second blockchain according to the first communication data format; send the first data forwarding request to the target relay server through the first data communication mode, the target relay server is used to obtain the blockchain identifier of the second blockchain carried in the first data forwarding request, and forward the target data packet to the second node device maintaining the second blockchain according to the blockchain identifier of the second blockchain.
  • the third determining unit 1302 is specifically configured to: when the candidate relay service associated with the second node device If the number of relay servers is one, the candidate relay server associated with the second node device is determined as the target relay server.
  • the third determination unit 1302 is used to obtain the credits corresponding to at least two candidate relay servers respectively when the number of candidate relay servers associated with the second node device is at least two, and determine the candidate relay server with the maximum credit among the at least two candidate relay servers as the target relay server.
  • the sending module 13 also includes: a fourth determination unit 1304, used to determine the candidate oracle server associated with the second node device from the candidate oracle server set; a fifth determination unit 1305, used to determine the target oracle server based on the candidate oracle server associated with the second node device; a second sending unit 1306, used to obtain the second interface protocol of the target oracle server, call the sub-ledger smart contract on the first blockchain, and send the encapsulated block header to the target oracle server according to the second interface protocol of the target oracle server.
  • the second sending unit 1306 is specifically used to: call the sub-ledger smart contract on the first blockchain to obtain the second data communication mode and the second communication data format of the second interface protocol; generate a second data forwarding request carrying the encapsulated block header and the blockchain identifier of the second blockchain according to the second communication data format; send the second data forwarding request to the target oracle server through the second data communication mode; the target oracle server is used to forward the encapsulated block header to the second node device maintaining the second blockchain according to the blockchain identifier of the second blockchain carried in the second data forwarding request.
  • the target oracle server is used to send the encapsulated block header to the second node device when the number of blocks is greater than the target number threshold; the number of blocks is the number corresponding to the blocks on the first blockchain whose generation timestamp is later than the generation timestamp of the target block.
  • the target relay server is used to send the target data packet to the second node device when it is determined that the target transaction data in the target data packet has been verified according to the block header of the target block on the first blockchain.
  • the various modules in the blockchain data processing device 1 shown in Figure 10 can be separately or completely combined into one or several units to constitute, or one (some) of the units can be further divided into multiple functionally smaller sub-units, which can achieve the same operation without affecting the realization of the technical effects of the embodiments of the present application.
  • the above modules are divided based on logical functions.
  • the functions of a module can also be implemented by multiple units, or the functions of multiple modules can be implemented by one unit.
  • the video data processing device may also include other units.
  • these functions can also be implemented with the assistance of other units, and can be implemented by the collaboration of multiple units.
  • a general cross-chain communication architecture is provided, and the cross-chain communication architecture formulates a cross-chain communication protocol, which includes data encapsulation formats adapted to multiple blockchains, and access conditions (i.e., risk control rules) for node devices corresponding to blockchains to join cross-chain communication, etc.
  • the cross-chain communication architecture includes a oracle server and a relay server for implementing cross-chain communication.
  • the first node device corresponding to the first blockchain and the second node device corresponding to the second blockchain both meet the cross-chain communication protocol, that is, the first node device and the second node device both meet the access conditions for cross-chain communication in the cross-chain communication protocol, which is conducive to ensuring the security of cross-chain communication.
  • the first node device can select a data encapsulation format adapted to the second blockchain from the cross-chain communication protocol on the first blockchain, encapsulate the target transaction data and the transaction verification information of the target transaction data in the target block on the first blockchain, obtain the target data packet, and encapsulate the block header of the target block according to the message encapsulation format adapted to the second blockchain to obtain the encapsulated block header.
  • This is conducive to the second node device being able to successfully parse the target data packet and the encapsulated block header, and realize the interconnection between the first node device and the second node device, that is, realize the interconnection between the first blockchain and the second blockchain, that is, realize cross-chain communication.
  • the first node device can send the target data packet and the encapsulated block header in two independent ways, that is, send the target data packet to the target relay server associated with the second node device in the cross-chain communication architecture, send the encapsulated block header to the target oracle server associated with the second node device in the cross-chain communication architecture, and the relay server sends the target data packet to the second node device, and the target oracle server sends the encapsulated block header to the second node device.
  • the target relay server and the target oracle server are both independent entities outside the blockchain.
  • the first node device synchronizes the target transaction data and other data associated with the second node device to the second node device, and there is no need to synchronize all data on the first blockchain to the second node device, so as to reduce the data transmission cost and greatly save the storage cost and storage fee on the chain.
  • the second node device After the second node device obtains the target data packet and the encapsulated block header, the second node device processes the target transaction data in the target data packet only when the target transaction data is verified according to the data verification rules on the second blockchain, the encapsulated block header and the transaction verification information in the target data packet, so as to realize the on-chain verification of the target transaction data, avoid the target transaction data from being tampered with, improve the security of the target transaction data, and improve the security and efficiency of cross-chain communication.
  • the target transaction data is verified according to the data verification rules on the second blockchain, the encapsulated block header and the transaction verification information in the target data packet, and the on-chain storage is consumed only when it is really needed, which greatly saves the on-chain storage cost and fee.
  • the processing of the target transaction data may be normal business processing of the target transaction data according to business logic.
  • the blockchain data processing device 2 can be a computer-readable instruction (including program code) running in a computer device.
  • the blockchain data processing device 2 is an application software; the blockchain data processing device 2 can be used to execute the corresponding steps in the method provided in the embodiment of the present application.
  • the blockchain data processing device 2 can be a second node device for maintaining a second blockchain.
  • the blockchain data processing device 2 may include: a parsing module 21, a data verification module 22, and a transaction processing module 23.
  • the parsing module 21 is used for parsing the target data packet to obtain the target transaction data and the transaction verification information of the target transaction data in the target data packet when receiving the target data packet sent by the target relay server to the second node device and receiving the encapsulated block header sent by the target oracle server to the second node device;
  • the target data packet is sent by the first node device maintaining the first blockchain to the target relay server, the encapsulated block header is sent by the first node device to the target oracle server, the target data packet is obtained by encapsulating the target transaction data and the transaction verification information of the target transaction data based on the message encapsulation format adapted to the second blockchain maintained by the second node device,
  • the target transaction data is the transaction data in the target block of the first blockchain, and the encapsulated block header is obtained by encapsulating the block header of the target block based on the message encapsulation format;
  • the message encapsulation format is selected from the cross-chain communication protocol on the first blockchain, and the first no
  • a data verification module 22 is used to verify the target transaction data according to the encapsulated block header and the transaction verification information according to the data verification rules on the second blockchain to obtain a verification result, and the data verification rules are associated with the cross-chain communication protocol;
  • the transaction processing module 23 is configured to process the target transaction data in the target data packet when the verification result indicates that the target transaction data has passed the verification.
  • the second blockchain includes a sub-ledger smart contract generated based on the cross-chain communication protocol, the transaction verification information includes a Merkle path associated with the target block, and the data verification rules on the second blockchain include verification rules for the Merkle path;
  • the data verification module 22 includes: a hash operation unit 2201, which is used to call the sub-ledger smart contract on the second blockchain, perform a hash algorithm on the target transaction data, obtain a hash value to be verified, and perform a hash operation on the hash value to be verified according to the Merkle path to obtain a root hash value to be verified; a third acquisition unit 2202, which is used to obtain the Merkle root hash value from the encapsulated block header; a generation unit 2203, which is used to obtain a consistency check result between the Merkle root hash value and the root hash value to be verified, and generate a verification result indicating whether the target transaction data has passed the verification based on the consistency check result.
  • a hash operation unit 2201 which is used to call the sub-ledger smart contract on the second blockchain, perform a hash algorithm on the target transaction data, obtain a hash value to be verified, and perform a hash operation on the hash value to be verified according to the Merkle path to obtain a root hash
  • the generation unit 2203 includes: a first generation unit 22031, which is used to generate a verification result indicating that the target transaction data verification has passed if the consistency check result indicates that the Merkle root hash value in the encapsulated block header is the same as the root hash value to be verified; a second generation unit 22032, which is used to generate a verification result indicating that the target transaction data verification has not passed if the consistency check result indicates that the Merkle root hash value in the encapsulated block header is different from the root hash value to be verified.
  • the second blockchain includes a sub-ledger smart contract generated based on the cross-chain communication protocol, the transaction verification information includes a target parent block hash value of a parent block of the target block, and the data verification rules on the second blockchain include verification rules for the target parent block hash value;
  • the data verification module 22 includes: a fourth acquisition unit 2205, which is used to call the sub-ledger smart contract on the second blockchain, and obtain the block hash value of the parent block of the target block from the encapsulated block header as the parent block hash value to be verified; a generation module 2206, which is used to obtain the consistency check result of the parent block hash value to be verified and the target parent block hash value, and generate a verification result indicating whether the target transaction data has passed the verification according to the consistency check result.
  • a fourth acquisition unit 2205 which is used to call the sub-ledger smart contract on the second blockchain, and obtain the block hash value of the parent block of the target block from the encapsulated block header as the parent block hash value to be verified
  • a generation module 2206 which is used to obtain the consistency check result of the parent block hash value to be verified and the target parent block hash value, and generate a verification result indicating whether the target transaction data has passed the verification according to the consistency check result.
  • the generation module 2206 includes: a third generation unit 22061, which is used to generate a verification result indicating that the target transaction data has been verified if the consistency check result indicates that the hash value of the parent block to be verified is the same as the hash value of the target parent block;
  • the fourth generating unit 2207 is used to generate a verification result indicating that the target transaction data verification has failed if the consistency check result indicates that the hash value of the parent block to be verified is different from the hash value of the target parent block.
  • the various modules in the blockchain data processing device 2 shown in Figure 11 can be separately or completely combined into one or several units to constitute, or one (some) of the units can be further divided into multiple functionally smaller sub-units, which can achieve the same operation without affecting the realization of the technical effects of the embodiments of the present application.
  • the above modules are divided based on logical functions.
  • the functions of a module can also be implemented by multiple units, or the functions of multiple modules can be implemented by one unit.
  • the video data processing device may also include other units.
  • these functions can also be implemented with the assistance of other units, and can be implemented by the collaboration of multiple units.
  • a general cross-chain communication architecture is provided, and the cross-chain communication architecture formulates a cross-chain communication protocol, which includes data encapsulation formats adapted to multiple blockchains, and access conditions (i.e., risk control rules) for node devices corresponding to blockchains to join cross-chain communication, etc.
  • the cross-chain communication architecture includes a oracle server and a relay server for implementing cross-chain communication.
  • the first node device corresponding to the first blockchain and the second node device corresponding to the second blockchain both meet the cross-chain communication protocol, that is, the first node device and the second node device both meet the access conditions for cross-chain communication in the cross-chain communication protocol, which is conducive to ensuring the security of cross-chain communication.
  • the first node device can select a data encapsulation format adapted to the second blockchain from the cross-chain communication protocol on the first blockchain, encapsulate the target transaction data and the transaction verification information of the target transaction data in the target block on the first blockchain, obtain the target data packet, and encapsulate the block header of the target block according to the message encapsulation format adapted to the second blockchain to obtain the encapsulated block header.
  • This is conducive to the second node device being able to successfully parse the target data packet and the encapsulated block header, and realize the interconnection between the first node device and the second node device, that is, realize the interconnection between the first blockchain and the second blockchain, that is, realize cross-chain communication.
  • the first node device can send the target data packet and the encapsulated block header in two independent ways, that is, send the target data packet to the target relay server associated with the second node device in the cross-chain communication architecture, send the encapsulated block header to the target oracle server associated with the second node device in the cross-chain communication architecture, send the target data packet to the second node device by the relay server, and send the encapsulated block header to the second node device by the target oracle server.
  • the target relay server and the target oracle server are both independent entities outside the blockchain.
  • the risk of single-point forwarding being attacked can be avoided by forwarding the target data packet and the encapsulated block header respectively by two independent entities outside the blockchain, thereby improving the security of cross-chain communication.
  • the trustless and effective transmission of any cross-chain data can be guaranteed, thereby improving the security of cross-chain data transmission.
  • the first node device synchronizes the target transaction data and other data associated with the second node device to the second node device, and does not need to synchronize all data on the first blockchain to the second node device, so as to reduce the data transmission cost and greatly save the storage cost and storage fee on the chain.
  • the second node device After the second node device obtains the target data packet and the encapsulated block header, the second node device processes the target transaction data in the target data packet only when the target transaction data is verified according to the data verification rules on the second blockchain, the encapsulated block header and the transaction verification information in the target data packet, so as to realize the on-chain verification of the target transaction data, avoid the target transaction data from being tampered with, improve the security of the target transaction data, and improve the security and efficiency of cross-chain communication.
  • the target transaction data is verified according to the data verification rules on the second blockchain, the encapsulated block header and the transaction verification information in the target data packet, and the on-chain storage is consumed only when it is really needed, which greatly saves the on-chain storage cost and fees.
  • FIG12 is a schematic diagram of a computer device provided in an embodiment of the present application.
  • the computer device 3000 may be the consensus node 220A in the embodiment corresponding to FIG. 3 , and the computer device 3000 may include: at least one processor 3001, such as a CPU, at least one network interface 3004, a user interface 3003, a memory 3005, and at least one communication bus 3002.
  • the communication bus 3002 is used to realize the connection and communication between these components.
  • the user interface 3003 may include a display screen (Display), a keyboard (Keyboard), and the network interface 3004 may optionally include a standard wired interface, a wireless interface (such as a WI-FI interface).
  • the memory 3005 may be a high-speed RAM memory, or a non-volatile memory (non-volatile memory), such as at least one disk memory.
  • the storage 3005 may also be optionally at least one storage device located away from the aforementioned processor 3001.
  • the memory 3005 as a computer storage medium may include an operating system, a network communication module, a user interface module, and a device control application.
  • the network interface 3004 is mainly used for the second node device to communicate with the target relay server and the target oracle server over the network;
  • the user interface 3003 is mainly used to provide an input interface for the user; and the processor 3001 can be used to call the device control application stored in the memory 3005.
  • the computer device 3000 described in the embodiment of the present application can execute the description of the blockchain data processing method in the embodiment corresponding to FIG. 6 or FIG. 8 above, and can also execute the description of the blockchain data processing device 1 in the embodiment corresponding to FIG. 10 above or the blockchain data processing device 2 in the embodiment corresponding to FIG. 11, which will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated.
  • the embodiment of the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores the computer-readable instructions executed by the blockchain data processing device 1 or the blockchain data processing device 2 mentioned above, and the computer-readable instructions include program instructions.
  • the processor executes the program instructions, it can execute the description of the blockchain data processing method in the embodiment corresponding to Figure 6 or Figure 8 above, so it will not be repeated here.
  • the description of the beneficial effects of using the same method will not be repeated.
  • the program instructions can be deployed to be executed on a computing device, or on multiple computing devices located at one location, or on multiple computing devices distributed at multiple locations and interconnected by a communication network.
  • Multiple computing devices distributed at multiple locations and interconnected by a communication network can constitute a blockchain system.
  • the present application provides a computer program product or computer-readable instructions, which include computer-readable instructions, which are stored in a computer-readable storage medium.
  • the processor of the computer device reads the computer-readable instructions from the computer-readable storage medium, and the processor executes the computer-readable instructions, so that the computer device can execute the description of the blockchain data processing method in the embodiment corresponding to Figure 6 or Figure 8 above, which will not be repeated here.
  • the description of the beneficial effects of using the same method will not be repeated.
  • the above-mentioned program can be stored in a computer-readable storage medium.
  • the program When the program is executed, it can include the processes of the embodiments of the above-mentioned methods.
  • the above-mentioned storage medium can be a disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM), etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Databases & Information Systems (AREA)
  • Technology Law (AREA)
  • Data Mining & Analysis (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种区块链数据处理方法，由区块链网络中维护第一区块链的第一节点设备执行，包括：从第一区块链上的跨链通信协议中，选择与第二区块链适配的消息封装格式，所述第二区块链由所述区块链网络中第二节点设备维护，所述第一节点设备和所述第二节点设备依照所述跨链通信协议通信(S101)；确定与所述第二节点设备相关联的目标交易数据所在的目标区块，根据与所述第二区块链适配的消息封装格式，对所述第一区块链上的目标区块中的目标交易数据和所述目标交易数据的交易验证信息进行封装，得到目标数据包，根据与所述第二区块链适配的消息封装格式对所述目标区块的区块头进行封装，得到封装区块头(S102)；及向与所述第二节点设备关联的目标中继服务器发生所述目标数据包，向与所述第二节点设备关联的目标预言机服务器发送所述封装区块头，所述目标中继服务器用于向所述第二节点设备发送所述目标数据包，所述目标预言机服务器用于向所述第二节点设备发送所述封装区块头，所述第二节点设备用于在根据所述第二区块链上的数据验证规则、所述封装区块头和所述目标数据包中的交易验证信息对所述目标交易数据验证通过时，处理所述目标数据包中的目标交易数据，所述数据验证规则与所述跨链通信协议相关联(S103)。

Description

区块链数据处理方法、装置、设备及存储介质
相关申请
本申请要求2023年2月10日申请的，申请号为2023101441034，名称为“区块链数据处理方法、装置、设备及存储介质”的中国专利申请的优先权，在此将其全文引入作为参考。
技术领域
本申请涉及区块链技术领域，尤其涉及区块链数据处理方法、装置、设备及存储介质。
背景技术
区块链技术是利用块链式数据结构来验证与存储数据、利用分布式节点共识算法来生成和更新数据、利用密码学的方式保证数据传输和访问的安全、利用由自动化脚本代码组成的智能合约来编程和操作数据的一种全新的分布式基础架构与计算方式。简单的讲，区块链就是去中心化的分布式账本。
随着区块链技术的被广泛认识及认可，出现了很多不同类型的区块链。然而，现有技术中，区块链是各自独立的，各个区块链之间实现跨链通信困难，还需要人工参与，导致跨区块链的跨链通信效率较低，且容易出现数据泄露，数据丢失，不能很好的保证跨链通信的安全性。
发明内容
根据本申请的各种实施例，提供一种区块链数据处理方法、装置、设备及存储介质。
一方面，本申请实施例提供一种一种区块链数据处理方法，由区块链网络中维护第一区块链的第一节点设备执行，包括：
从第一区块链上的跨链通信协议中，选择与第二区块链适配的消息封装格式，所述第二区块链由所述区块链网络中第二节点设备维护，所述第一节点设备和所述第二节点设备依照所述跨链通信协议通信；
确定与所述第二节点设备相关联的目标交易数据所在的目标区块，根据与所述第二区块链适配的消息封装格式，对所述第一区块链上的目标区块中的目标交易数据和所述目标交易数据的交易验证信息进行封装，得到目标数据包，根据与所述第二区块链适配的消息封装格式对所述目标区块的区块头进行封装，得到封装区块头；及
向与所述第二节点设备关联的目标中继服务器发生所述目标数据包，向与所述第二节点设备关联的目标预言机服务器发送所述封装区块头，所述目标中继服务器用于向所述第二节点设备发送所述目标数据包，所述目标预言机服务器用于向所述第二节点设备发送所述封装区块头，所述第二节点设备用于在根据所述第二区块链上的数据验证规则、所述封装区块头和所述目标数据包中的交易验证信息对所述目标交易数据验证通过时，处理所述目标数据包中的目标交易数据，所述数据验证规则与所述跨链通信协议相关联。
另一方面，本申请提供一种区块链数据处理方法，由区块链网络中维护第二区块链的第二节点设备执行，包括：
当接收到目标中继服务器发送的目标数据包，以及接收到目标预言机服务器发送的封装区块头，则解析所述目标数据包，得到所述目标数据包中的目标交易数据和所述目标交易数据的交易验证信息；所述目标数据包是由维护所述第一区块链的第一节点设备向所述目标中继服务器发送的，所述封装区块头是由所述第一节点设备向所述目标预言机服务器发送的，所述目标数据包是基于与所述第二节点设备维护的第二区块链适配的消息封装格式，对所述目标交易数据以及所述目标交易数据的交易验证信息进行封装得到的，所述目标交易数据为第一区块链的目标区块中的交易数据，所述封装区块头是基于所述消息封装格式对所述目标区块的区块头进行封装得到的；所述消息封装格式是从所述第一区块链上的跨链通信协议中选择得到的，所述第一节点设备和所述第二节点设备依照所述跨链通信协议通信；
按照所述第二区块链上的数据验证规则，根据所述封装区块头和所述交易验证信息对所述目标交易数据进行验证，得到验证结果，所述数据验证规则与所述跨链通信协议相关联；及
当所述验证结果指示所述目标交易数据验证通过，则处理所述目标数据包中的目标交易数据。
另一方面，本申请实施例提供一种区块链数据处理装置，包括：
选择模块，用于从第一区块链上的跨链通信协议中，选择与第二区块链适配的消息封装格式，所述第一区块链由区块链网络中第一节点设备维护，所述第二区块链由所述区块链网络中第二节点设备维护，所述第一节点设备和所述第二节点设备依照所述跨链通信协议通信；
封装模块，用于确定与所述第二节点设备相关联的目标交易数据所在的目标区块，根据与所述第二区块链适配的消息封装格式，对所述第一区块链上的目标区块中的目标交易数据和所述目标交易数据的交易验证信息进行封装，得到目标数据包，根据与所述第二区块链适配的消息封装格式对所述目标区块的区块头进行封装，得到封装区块头；及
发送模块，用于向与所述第二节点设备关联的目标中继服务器发生所述目标数据包，向与所述第二节点设备关联的目标预言机服务器发送所述封装区块头，所述目标中继服务器用于向所述第二节点设备发送所述目标数据包，所述目标预言机服务器用于向所述第二节点设备发送所述封装区块头，所述第二节点设备用于在根据所述第二区块链上的数据验证规则、所述封装区块头和所述目标数据包中的交易验证信息对所述目标交易数据验证通过时，处理所述目标数据包中的目标交易数据，所述数据验证规则与所述跨链通信协议相关联向与所述第二节点设备关联的目标中继服务器发送所述目标数据包。
再一方面，本申请实施例提供一种区块链数据处理装置，包括：
解析模块，用于当接收到目标中继服务器向第二节点设备发送的目标数据包，以及接收到目标预言机服务器向第二节点设备发送的封装区块头，则解析所述目标数据包，得到所述目标数据包中的目标交易数据和所述目标交易数据的交易验证信息；所述目标数据包是由维护第一区块链的第一节点设备向所述目标中继服务器发送的，所述封装区块头是由所述第一节点设备向所述目标预言机服务器发送的，所述目标数据包是基于与所述第二节点设备维护的第二区块链适配的消息封装格式，对所述目标交易数据以及所述目标交易数据的交易验证信息进行封装得到的，所述目标交易数据为所述第一区块链的目标区块中的交易数据，所述封装区块头是基于所述消息封装格式对所述目标区块的区块头进行封装得到的；所述消息封装格式是从所述第一区块链上的跨链通信协议中选择得到的，所述第一节点设备和所述第二节点设备依照所述跨链通信协议通信；
数据验证模块，用于按照所述第二区块链上的数据验证规则，根据所述封装区块头和所述交易验证信息对所述目标交易数据进行验证，得到验证结果，所述数据验证规则与所述跨链通信协议相关联；
交易处理模块，用于当所述验证结果指示所述目标交易数据验证通过，则处理所述目标数据包中的目标交易数据。
另一方面，本申请实施例提供一种计算机设备，包括：处理器和存储器，所述存储器存储有计算机可读指令，所述处理器用于执行所述计算机可读指令，以使得所述计算机设备执行本申请任一方法实施例的方法。
另一方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机可读指令，所述计算机可读指令由处理器加载并执行，以使得所述处理器执行本申请任一方法实施例的方法。
另一方面，本申请实施例提供一种计算机程序产品，包括计算机可读指令，所述计算机可读指令存储在计算机可读存储介质中，所述计算机可读指令由处理器读取并执行，以使得所述处理器执行本申请任一方法实施例的方法。
本申请的一个或多个实施例的细节在下面的附图和描述中提出。本申请的其它特征、目的和优点将从说明书、附图以及权利要求书变得明显。
附图说明
为了更清楚地说明本申请实施例或传统技术中的技术方案，下面将对实施例或传统技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据公开的附图获得其他的附图。
图1是本申请实施例提供的一种区块链结构的示意图；
图2是本申请实施例提供的一种区块生成的示意图；
图3是本申请实施例提供的一种区块链网络分层结构的示意图；
图4是本申请实施例提供的一种区块链网络应用于电子票据的结构示意图；
图5是本申请实施例提供的一种进行跨链数据交互的场景示意图；
图6是本申请实施例提供的一种区块链数据处理方法的流程示意图；
图7是本申请实施例提供的一种跨链通信的示意图；
图8是本申请实施例提供的一种区块链数据处理方法的流程示意图；
图9是本申请实施例提供的一种跨链通信的应用示意图；
图10是本申请实施例提供的一种区块链数据处理装置的结构示意图；
图11是本申请实施例提供的一种区块链数据处理装置的结构示意图；
图12是本申请实施例提供的一种计算机设备的示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
区块链(Blockchain)是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。区块链由多个区块组成，参见图1，图1是本申请实施例提供的一种区块链结构的示意图，如图1所示，区块链由多个区块组成，创始块中包括区块头和区块主体，区块头中存储有输入信息特征值、版本号、时间戳和难度值，区块主体中存储有输入信息；创始块的下一区块以创始块为父区块，下一区块中同样包括区块头和区块主体，区块头中存储有当前区块的输入信息特征值、父区块的区块头特征值、版本号、时间戳和难度值，并以此类推，使得区块链中每个区块中存储的区块数据均与父区块中存储的区块数据存在关联，保证了区块中输入信息的安全性。
在生成区块链中的各个区块时，参见图2，图2是本申请实施例提供的一种区块生成的示意图，所在的节点在接收到输入信息时，对输入信息进行校验，完成校验后，将输入信息存储至内存池中，并更新其用于记录输入信息的哈希树；之后，将更新时间戳更新为接收到输入信息的时间，并尝试不同的随机数，多次进行特征值计算，使得计算得到的特征值可以满足下述公式(1)：
SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x))<
TARGET   (1)
其中，公式(1)中的SHA256为计算特征值所用的特征值算法；version(版本号)为区块链中相关区块协议的版本信息；prev_hash为当前区块的父区块的区块头特征值；merkle_root为输入信息的特征值；ntime为更新时间戳的更新时间；nbits为当前难度，在 一段时间内为定值，并在超出固定时间段后再次进行确定；x为随机数；TARGET为特征值阈值，该特征值阈值可以根据nbits确定得到。
其中，当计算得到满足上述公式(1)的随机数时，便可将信息对应存储，生成区块头和区块主体，得到当前区块。随后，区块链可以将新生成的当前区块对外广播，即将当前区块分别发送给其所在的数据共享系统中的其他节点，数据共享系统中的每个节点均存储一条相同的区块链，由其他节点对当前区块进行校验，并在完成校验后将当前区块添加至其存储的区块链中。
本申请实施例中可以将节点设备的设备特征信息输入设备有效性验证模型，设备有效性验证模型基于跨链通信协议中的风控规则，对节点设备的有效性进行验证，输入有效性验证结果，该有效性验证结果用于指示节点设备是否具有有效性，该设备有效性验证模型存储至区块链上，可以提高节点设备有效性的确定效率。
请参见图3，图3是本申请实施例提供的一种区块链网络分层结构的示意图。本申请实施例中的区块链网络分层结构可以为图3所示的区块链网络1W，该区块链网络1W对应的完整区块链业务体系可以由图3所示的业务网络、核心共识网络以及代理节点10D所在的路由代理网络所组成。
应当理解，该路由代理网络中的代理节点的节点数量可以为一个或者多个，在此不做限定。本申请实施例以代理节点10D为例，该代理节点10D可以用于对该业务网络和核心共识网络进行网络隔离。该代理节点10D可以是独立的一个物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器，在此不做限定。该代理节点10D可以将点对点(Peer To Peer，简称P2P)网络进行网络分层，以形成“业务网络—核心共识网络”这样的分层结构，进而能够提高区块链上数据的保密性和安全性。
其中，图3所示的业务网络(即见证网络)对应的区块链节点系统中可以包括一个或者多个区块链节点，这里将不对业务网络对应的区块链节点系统中的节点数量进行限制。比如，业务网络对应的区块链节点系统具体可以包括节点110a、节点110b、节点110c、…、节点110n。应当理解，本申请实施例可以将处于业务网络中的区块链节点称之为业务节点，该业务节点不需要参与记账共识，主要用于执行交易业务，以得到与该交易业务相关联的交易数据。其中，这里的业务节点可以为包含完整的区块链数据库的全量节点，也可以为存储区块链数据库中的部分数据的轻量节点，这里将不对其进行限定。为了减少业务节点的存储空间的浪费，本申请实施例中的业务节点可以以轻量节点(Simplified Payment Verification，简称SPV)为例，该业务节点不需要存储完整的交易数据，而是通过代理节点10D，从图3所示的核心共识网络中，获得区块头数据和部分授权可见的区块数据(例如，与业务节点自身相关联的交易)。
其中，图3所示的核心共识网络对应的区块链节点系统中也可以包括一个或者多个区块链节点，这里将不对核心共识网络对应的区块链节点系统中的节点数量进行限制。比如，核心共识网络对应的区块链节点系统具体可以包括节点120a、节点120b、节点120c、…、节点120m。应当理解，本申请实施例可以将处于该核心共识网络中的节点称之为共识节点(即记账节点)，该共识节点可以运行有区块链共识协议。
应当理解，本申请实施例可以将代理节点、业务节点以及共识节点可以统称为区块链网络1W中的区块链节点。其中，该区块链节点可以为接入该区块链网络1W中的服务器，也可以为接入该区块链网络1W中的用户终端，这里对区块链节点的具体形式不做限定。可以理解的是，图3所示的业务网络和核心共识网络可以处于不同的网络环境，例如，通常来说，业务节点部署在处于公网的业务网络中，而运行区块链共识协议的共识节点则部署在私有的核心共识网络中，二者可以通过路由边界进行交互。
如图4所示，图4是本申请实施例提供的一种应用于电子票据的区块链网络的结构示 意图，如图4所示，当图3中的区块链网络应用于电子票据的场景时，区块链网络可以为电子票据的整个流转过程中产生的交易数据进行记录，如图4所示，该区块链网络包括业务网络41、核心共识网络42以及路由代理网络43所组成。其中，电子票据的流转过程包括电子票据的申领、电子票据的开具、电子票据的报销、电子票据的报税等过程，其中，电子票据的开具也叫做电子票据的生成，由于整个电子票据的流转过程涉及到的角色包括管理机构、开票方、报销方和报税方，因此业务网络41中包括为管理机构提供相关服务的管理机构专网411，还包括为开票方、报销方以及报税方提供相关服务的公有云412，还包括为消费者提供电子票据保存服务的私有云413。其中，管理机构专网411中包括电子票据所涉及的管理机构所使用的计算机设备，包括管理机构终端4111，管理终端可以访问管理机构专网411。公有云412中包括电子票据所涉及的开票方、报销费以及报税方所使用的计算机设备，包括开票方终端4121、报销方终端4122和报税方终端4123，其中，开票方可以是开票服务商，报销方可以是报销服务商，企业终端可以访问公有云412。私有云413中包括电子票据所涉及的用户所使用的计算机设备，包括用于进行支付的支付终端4131，还包括用于临时为用户保存电子票据的电子票据流转终端4132，还包括一些企业的专用终端4133，消费者终端可以访问私有云413。管理机构专网411、公有云412以及私有云413中的计算机设备均可以作为业务节点通过路由层42向共识网络43发送针对电子票据的数据上链请求或数据查询请求。
可以理解的是，路由层42中的任一路由节点包括提供认证服务421、证书缓存422、路由服务423和P2P服务424的功能模块。认证服务421用于对业务网络41中的业务节点进行身份验证，证书缓存422用于缓存各节点的身份证书，路由服务423用于实现业务网络41与共识网络43之间的网络隔离，P2P服务424用于在具备幂等性的路由节点之间分配任务，路由节点之间形成组成点对点(P2P，Peer To Peer)网络，P2P协议是一个运行在传输控制协议(TCP，Transmission Control Protocol)协议之上的应用层协议。
其中，共识网络43包括多个共识分支网络，如区块链网络一431、区块链网络二432以及区块链网络三433等，每个共识分支网络包括多个共识节点(即共识节点设备)，每个共识分支网络中多个共识节点维护该共识分支网络所对应的区块链，如区块链网络一431包括的多个公式节点用于维护区块链网络一431对应的区块链一。其中，共识网络43中不同区块链的作用不同，比如，有的区块链用于记录属于某个票据号段区间的电子票据相关的交易信息，有的区块链用于记录冲红的电子票据相关的交易信息。其中，冲红是指原先开的电子票据有误或需更正，重新开发票调整账目。冲红的电子票据就可以是发生冲红事件的电子票据。
在需要记录电子票据相关的数据时，可根据业务节点的权限确定要记录至的区块链，然后由维护该区块链的共识分支网络来记录。共识节点通常可以是各个地区的管理机构所使用的计算机设备。每个共识分支网络中的共识节点包括权限合约，权限合约存储了关于电子票据的整个生命周期的流转逻辑，比如电子票据的票据状态、流转流程、数据的访问权限、电子票据申领条件、电子票据开具条件等等。共识节点还包括高速缓存和数据区块，这些功能可以为交易信息的上链与查询提供支持。可以理解的是，本方案可以实现不同区块链之间的跨链数据交易，如图4所示的业务网络中不同区块链之间的跨链数据交易，或者，业务网络中的区块链与公式网络中的区块链之间的跨链数据交易，或者，公式网络中不同区块链之间的跨链数据交易。
其中，本申请实施例中的第一区块链所属的第一区块链网络可以与第二区块链所属的第二区块链网络相同，即本申请可以实现同一区块链网络中的不同区块链之间的跨链通信。例如，第一区块链与第二区块链均为上述共识网络43中的区块链，如第一区块链可以为区块链一，第二区块链为区块链二。当然，本申请实施中的第一区块链所属的区块链网络可以与第二区块链所属的区块链网络不同，即本申请可以实现不同区块链网络中的不同区块链之间的跨链通信。例如，第一区块链所属的第一区块链网络为业务网络41，第二区块链 所属的第二区块链网络为共识网络43。
需要说明的是，本申请实施例所涉及到的区块链网络中的所有节点设备均可以是手机、平板电脑、笔记本电脑、掌上电脑、移动互联网设备(MID，mobile internet device)、车辆、路边设备、飞行器、可穿戴设备，例如智能手表、智能手环、计步器等具有数据处理功能的智能设备，每个节点设备对应的设备类型可以相同，也可以不相同。
为便于理解，本申请实施例可以将图4所示的共识网络43中的区块链一作为第一区块链，将图4所示的共识网络43中的区块链二作为第二区块链。第一节点设备可以为图4所示的区块链一中的任意一个共识节点，第二节点设备可以为图4所示的区块链二中的任意一个共识节点。当第一节点设备中存在需要同步给第二节点设备的目标交易数据时，第一节点设备可以从第一区块链上的跨链通信协议中，选择与第二区块链适配的消息封装格式。跨链通信协议包括各个节点设备之间进行跨链交易(如跨链传输数据)时所需遵守的规则，换句话说，节点设备之间需要满足跨链通信协议才能进行跨链交易。目标交易数据特指需要同步给第二节点设备的交易数据。
其中，第一节点设备为维护第一区块链的节点设备，即第一节点设备可以获取第一区块链所需要记录的交易数据，根据该第一区块链所需要记录的交易数据生成新的区块，第一节点设备可以将其新生成的区块加入第一区块链中。第二节点设备为维护第二区块链的节点设备，即第二节点设备可以获取第二区块链所需要记录的交易数据，根据该第二区块链所需要记录的交易数据生成新的区块，第二节点设备可以将其新生成的区块加入第二区块链中。第一节点设备和第二节点设备均满足跨链通信协议，换句话说，第一节点设备与第二节点设备在进行跨链交易时，均需要遵守跨链通信协议中约定的规则。应当理解，维护第一区块链的所有第一节点设备与维护第二区块链的所有第二节点设备均满足跨链通信协议，这样便可以实现第一区块链与第二区块链之间的跨链交易。其中，与第二区块链适配的消息封装格式可以包括第二区块链使用的数据交易结构、编码模式、验证模式以及加密模式等。由于不同区块链上的数据处理规范是不同的，因此，可以根据与第二区块链适配的消息封装格式对需要发送给第二区块链的跨链数据(如目标交易数据、交易验证信息以及区块头)进行封装，这样，可以便于第二节点设备成功解析第一节点设备发送的跨链数据。
进一步地，第一节点设备可以根据消息封装格式对第一区块链上的目标区块中的目标交易数据和目标交易数据的交易验证信息进行封装，得到目标数据包，根据消息封装格式对目标区块的区块头进行封装，得到封装区块头。目标交易数据是由业务需求或某种请求指定的交易数据。目标区块是记录有目标交易数据的区块。目标数据包是将目标交易数据和目标交易数据的交易验证信息封装得到的数据包。
其中，目标交易数据与第二节点设备相关联，如目标交易数据为第一区块链对应的第一节点设备需要发送给第二节点设备的跨链数据，或者，目标交易数据可以为第二区块链对应的第二节点设备向第一节点设备请求的跨链数据。第一节点设备可以向与第二节点设备关联的目标中继服务器发送目标数据包，以及向第二节点设备发送封装区块头关联的目标预言机服务器。目标中继服务器用于向第二节点设备发送目标数据包，目标预言机服务器用于向第二节点设备发送封装区块头。
其中，目标中继服务器与目标预言机服务器均为区块链之外的独立实体，这样，由区块链之外的目标中继服务器和目标预言机服务器分别转发目标数据包和封装区块头，相对于采用中间区块链来传输两条区块链的跨链数据的方式，本方案可以在实现去中心化的同时，也可以实现形成开放的跨链生态，提高跨链数据传输的安全性。同时，第二节点设备可以根据第二区块链上的数据验证规则、封装区块头以及目标数据包中的交易验证信息对目标交易数据进行验证，在对目标交易数据验证通过时，对目标数据包中的目标交易数据进行处理。其中，第二区块链上的数据验证规则与跨链通信协议相关联，即第二区块链上的数据验证规则可以是指跨链通信协议中约定的。
这样，由目标预言机服务器和中继服务器按照流式分别传输区块头和目标数据包，相对于在两个链之间互相部署对方链的轻节点，互相同步对方链完整的区块头的方案而言，本方案仅传输目标交易数据对应的区块头，可以降低验证成本，进而降低跨链交易的成本。同时，只要目标预言机服务器和目标中继服务器的独立性条件没有被破坏，就可以保证任意跨链数据的无信任有效传递，在保持无信任的前提下，只根据封装区块头和交易验证信息对目标交易数据进行验证，在确实需要时(如目标交易数据验证通过时)才消耗第二区块链上存储空间，大大节约链上的存储成本和存储费用。
为便于理解，进一步地，请参见图5，图5是本申请实施例提供的一种进行跨链数据交互的场景示意图。如图5所示，本申请实施例中的第一区块链网络500可以为上述核心共识网络，本申请实施例中的第二区块链网络510也可以为上述核心共识网络，本申请实施例中的第一区块链502可以为上述核心共识网路中的区块链一431，本申请实施例中的第二区块链512可以为上述核心共识网路中的区块链二432。如图5所示，本申请实施例中的第一节点设备501可以为上述核心共识网络中的具备出块功能且维护区块链一431的共识节点，该第一节点设备501可以为上述图4所示的维护区块链一431的共识节点中的任意一个共识节点。本申请实施例中的第二节点设备511可以为上述核心共识网络中的具备出块功能且维护区块链二432的共识节点，该第二节点设备511可以为上述图4所示的维护区块链二432的共识节点中的任意一个共识节点。第一节点设备501和第二节点设备511均满足跨链通信协议，这样，维护第一区块链502的第一节点设备501与维护第二区块链512的第二节点设备511之间可以实现跨链数据交易。其中，第一节点设备501与第二节点设备511为维护不同区块链的不同节点设备，如第一节点设备501可以为上述图4中的管理终端，第二节点设备511可以为上述图4中的企业终端。
应当理解，业务网络中的业务节点可以与第二节点设备511关联的目标交易数据执行交易业务，进而可以根据交易业务的交易执行结果，生成用于广播至核心共识网络中的交易(即待广播交易)。这里的交易业务可以为跨链数据同步业务、跨链数据转移业务等业务，目标交易数据可以是指第一节点设备501与第二节点设备511之间的跨链交易数据(如第一节点设备501需要同步给第二节点设备511的跨链同步数据，或者，第一节点设备501与第二节点设备511之间的跨链转移数据)。例如，目标交易数据可以为(第一区块链502中的账户1,第二区块链512中的账户2,20)，账户1表示资源转出账户，账户2表示资源转入账户，20表示待转移的资源量，账户1是第一区块链502中的账户，账户2是第二区块链512中的账户。
应当理解，第一节点设备501在通过代理节点接收到业务节点发送的待广播交易时，可以对接收到的待广播交易进行验证。在验证成功时，将接收到的待广播交易存储至第一节点设备501的节点交易池，并生成目标交易数据对应的区块。进一步地，第一节点设备501可以将目标交易数据对应的区块发送给维护第一区块链502的其他节点设备，当维护第一区块链502的其他节点设备对目标交易数据对应的区块共识成功时，第一节点设备501可以将目标交易数据对应的区块添加至第一区块链502中，得到目标区块5021。
应当理解，第一节点设备501可以从第一区块链上的跨链通信协议中，选择与第二节点设备511对应的第二区块链512适配的消息封装格式，该消息封装格式可以包括第二区块链使用的数据交易结构、编码模式、验证模式以及加密模式等。由于不同区块链上的数据处理规范是不同的，因此，可以根据与第二区块链512适配的消息封装格式对需要发送给第二区块链512的跨链数据(如目标交易数据、交易验证信息以及区块头)进行封装，这样，可以便于第二节点设备511成功解析第一节点设备501发送的跨链数据。
应当理解，当节点设备满足跨链通信协议时，则可以将与对应节点设备维护的区块链适配的消息封装格式添加至跨链通信协议中，这样，便于不同区块链上的数据进行跨链交易。进一步地，第一节点设备501可以获取目标区块5021中的目标交易数据以及关于目标交易数据的交易验证信息，该交易验证信息用于验证目标交易数据是否在第一节点设备 中成功执行，可以包括目标区块关联的默克尔路径、目标区块的父区块哈希值等。第一节点设备501可以根据与第二区块链512适配的消息封装格式，对目标区块5021中的目标交易数据以及交易验证信息进行封装，得到目标数据包。同时，第一节点设备501可以根据与第二区块链512适配的消息封装格式，对目标区块5021的区块头进行封装，得到封装区块头。
如图5所示，第一节点设备501可以将目标数据包发送给目标中继服务器520，以及将封装区块头发送给目标预言机服务器。其中，第一节点设备501在发送目标数据包时，可以同时发送第二区块链512的区块链标识，这样，目标中继服务器520可以根据第二区块链512的区块链标识，将目标数据包转发给维护第二区块链512的第二节点设备511。同样的，第一节点设备501在发送封装区块头时，可以同时发送第二区块链512的区块链标识，这样，目标预言机服务器530可以根据第二区块链512的区块链标识，将封装区块头转发给维护第二区块链512的第二节点设备511。如图5所示，目标中继服务器520和目标预言机服务器530为区块链之外的独立实体，目标中继服务器520在接收目标数据包时，可以自动将目标数据包转发给第二节点设备511，目标预言机服务器530在接收到封装区块头时，可以自动将封装区块头转发给第二节点设备511。
如图5所示，第二节点设备511在接收到目标中继服务器520转发的目标数据包，以及目标预言机服务器转发的封装区块头后，可以获取第二区块链512上的数据验证规则，该数据验证规则可以为跨链通信协议中约定的验证规则。第二节点设备511可以按照数据验证规则，根据封装区块头以及目标数据包中的交易验证信息，对目标数据包中的目标交易数据进行验证，得到验证结果。若该验证结果指示目标交易数据验证通过，则对目标交易数据进行处理。
例如，交易验证信息可以是指目标区块对应的默克尔路径，第二节点设备511可以对目标交易数据进行哈希算法，得到待验证哈希值，根据目标区块对应的默克尔路径对待验证哈希值进行哈希算法，得到待验证树根哈希值。进一步地，第二节点设备511可以从封装区块头中获取默克尔树哈希值，第二区块链上的数据验证规则可以包括关于默克尔路径的验证规则。其中，关于默克尔路径的验证规则用于指示在封装区块头中的默克尔树根哈希值与基于默克尔路径得到的待验证树根哈希值相同时，则确定目标交易数据验证通过，在封装区块头中的默克尔树根哈希值与基于默克尔路径得到的待验证树根哈希值不相同时，则确定目标交易数据验证未通过。应当理解，若第二节点设备511确定封装区块头中的默克尔树根哈希值与待验证树根哈希值相同，则生成用于指示目标交易数据验证通过的验证结果；若第二节点设备511确定封装区块头中的默克尔树根哈希值与待验证树根哈希值不相同，则生成用于指示目标交易数据验证未通过的验证结果。
这样，由目标预言机服务器530和中继服务器520按照流式分别传输封装区块头和目标数据包，相对于在两个链之间互相部署对方链的轻节点，互相同步对方链完整的区块头的方案而言，本方案仅传输目标交易数据对应的区块头，可以降低验证成本，进而降低跨链交易的成本。另外，通过目标预言机服务器530和中继服务器520传输用于对目标交易数据进行验证的数据(即封装区块头和交易验证信息)，可以提高跨链数据传输的安全性，只要目标预言机服务器530和目标中继服务器520的独立性条件没有被破坏，就可以保证任意跨链数据的无信任有效传递。在保持无信任的前提下，只根据封装区块头和交易验证信息对目标交易数据进行验证，在确实需要时(如目标交易数据验证通过时)才消耗第二区块链上存储空间，在确保安全性的同时，大大节约链上的存储成本和存储费用。
进一步地，请参见图6，图6是本申请实施例提供的一种区块链数据处理方法的流程示意图。如图6所示，该方法可以由区块链网络中维护第一区块链的第一节点设备执行，该区块链网络可以是指上述的核心共识网络，也可以是指上述的业务网络，也可以是其他区块链网络，本申请实施例在此不做限制，该第一节点设备可以为接入至该区块链网络中的服务器，也可以为接入至区块链网络中的用户终端，第一节点设备可以是指维护第一区 块链的节点设备中的任意一个节点设备，这里对第一节点设备的具体形式不做限定。该方法至少可以包括但不限于以下步骤：
S101，从第一区块链上的跨链通信协议中，选择与第二区块链适配的消息封装格式。
其中，第二区块链由区块链网络中第二节点设备维护，第一节点设备和第二节点设备依照跨链通信协议通信。
当第一节点设备需要将与第二节点设备关联的目标交易数据同步给第二节点设备时，第一节点设备可以从第一区块链上的跨链通信协议中，选择与第二区块链适配的消息封装格式。
其中，第一节点设备是维护第一区块链的节点设备，换句话说，第一区块链上的区块可以由第一节点设备生成并添加的，第二节点设备为维护第二区块链的节点设备，同样的，第二区块链上的区块可以由第二节点设备生成并添加的。
应当理解，第一节点设备和第二节点设备均满足跨链通信协议，换句话说，第一节点设备和第二节点设备均需要同意跨链通信协议，并第一节点设备和第二节点设备均需要按照跨链通信协议进行跨链交易，跨链通信协议中记录不同区块链进行跨链交易时所需要进行的操作以及所需要遵守的规则。
其中，与第二区块链适配的消息封装格式，是指适用于第二区块链的消息封装格式。该消息封装格式符合第二区块链的数据处理规范。使用该消息封装格式封装的消息可以在第二区块链的节点正确识别和处理。该消息封装格式符合跨链通信协议。与第二区块链适配的消息封装格式可以预先配置，并且建立第二区块链的区块链标识与该消息封装格式的关联关系，从而可以依据该关联关系，使用第二区块链的区块链标识确定与第二区块链适配的消息封装格式。
该与第二区块链适配的消息封装格式可以包括第二区块链中使用的数据交易结构、编码模式、验证模式以及加密模式等。由于不同区块链上的数据处理规范是不同的，因此，可以根据与第二区块链适配的消息封装格式对需要发送给第二区块链的跨链数据(如目标交易数据、交易验证信息以及区块头)进行封装，这样，可以便于第二节点设备成功解析第一节点设备发送的跨链数据。
当维护第一区块链的第一节点设备接收到与第二节点设备关联的目标交易数据时，可以根据目标交易数据的交易类型，调用第一区块链上的目标智能合约执行目标交易数据对应的交易业务。其中，与第二节点设备关联的目标交易数据可以是指第一节点设备与第二节点设备之间的跨链交易数据(如第一节点设备需要同步给第二节点设备的跨链同步数据，或者，第一节点设备与第二节点设备之间的跨链资产转移数据)，其中，该跨链资产转移数据可以用于跨链转移游戏金币、游戏钻石、电子票据等虚拟资产。第一区块链上的目标智能合约是与目标交易数据的交易类型相匹配的合约，例如，若目标交易数据的交易类型为数字藏品交易时，则第一区块链上的目标智能合约可以是指数字藏品合约。例如，目标交易数据可以为(第一区块链502中的账户1,第二区块链512中的账户2,20)，账户1表示资源转出账户，账户2表示资源转入账户，20表示待转移的资源量，账户1是第一区块链502中的账户，账户2是第二区块链512中的账户。
其中，第一节点设备调用目标业务合约执行目标交易数据对应的交易业务，生成关于目标交易数据的目标区块，并将目标交易数据对应的目标区块添加至第一区块链。例如，当目标交易数据为(第一区块链502中的账户1,第二区块链512中的账户2,20)时，第一节点设备可以执行第一区块链的账户1被扣除数量为20的资源数据的交易，并生成目标交易数据对应的目标区块，将目标交易数据对应的目标区块存储至第一区块链上。由于目标交易数据为第一节点设备与第二节点设备之间的跨链交易数据，因此，第一节点设备可以基于第一区块链上的跨链通信协议以及与第二区块链适配的消息封装格式，将目标交易数据发送给第二节点设备。
可选的，第一区块链上包括基于跨链通信协议生成的子账本智能合约(SpvContract)， 从第一区块链上的跨链通信协议中，选择与第二区块链适配的消息封装格式，包括：获取第二区块链的区块链标识；从第一区块链上的子账本智能合约中获取适配库集合，根据第二区块链的区块链标识，从适配库集合中，确定与第二区块链相关联的目标适配库；从目标适配库中，获取与第二节点设备对应的第二区块链适配的消息封装格式。
该第一区块链上的子账本智能合约用于实现第一区块链与其他区块链之间的跨链交易，是跨链通信协议的接口用于不同区块链对应的节点设备交互的智能合约接口。第一节点设备确定与第二区块链适配的消息封装格式的具体方式可以包括：获取第二区块链的区块链标识；从第一区块链上的子账本智能合约中获取适配库集合，根据第二区块链的区块链标识，从适配库集合中，确定与第二区块链相关联的目标适配库；从目标适配库中获取与第二节点设备对应的第二区块链适配的消息封装格式。
具体的，第一节点设备可以获取第二区块链的区块链标识，从第一区块链上的子账本智能合约中获取适配库集合，根据第二区块链的区块链标识，从适配库集合中，确定与第二区块链关联的目标适配库。其中，第一区块链上的子账本智能合约包括的适配库集合中包括多个区块链关联的适配库，即一个区块链对应一个适配库，该适配库中包括对应区块链的消息封装格式，有助于协调任意两条区块链上的子账本智能合约之间的交互。通过适配库可以构建对应区块链兼容的数据，并处理不同区块链标准编写的智能合约信息的编码和解码。例如，第一节点设备可以通过第二区块链关联的适配库，将需要发送给第二节点设备的目标交易数据封装成第二节点设备能够解析的数据，这样，第二节点设备能够对第一节点设备发送的目标交易数据进行解析并处理。
其中，第一区块链上的子账本智能合约包括的适配库集合可以存储至在第一区块链上的子账本智能合约的适配库模块(即辅助子账本智能合约)中，第一区块链上的子账本智能合约的适配库模块中的适配库，用于与对应区块链建立兼容连接计算，以实现与维护对应链的节点设备进行跨链交互。同时，第一节点设备可以在第一区块链上的子账本智能合约的适配库模块中添加新的适配库来对新的区块链的支持。其中，维护第一区块链的节点设备中均可以存储第一区块链上的子账本智能合约中的所有适配库的副本，或者可以存储所有适配库的副本。可以理解的是，在第一区块链上的子账本智能合约的适配库模块中添加新的适配库后，第一节点设备可以通过新添加的适配库，与对应新的区块链之间进行跨链交易。第一节点设备可以从目标适配库中获取与第二节点设对应的第二区块链适配的消息封装格式。这样，模块化可以允许在智能合约堆栈中插入多个适配库来确保跨链交易的易用性。同时，也可以通过适配库来对对应区块链发送的跨链数据进行解析和验证。
可选的，在第一区块链上的子账本智能合约包括的适配库集合中添加新的适配库的具体内容可以包括：当接收到第三区块链对应的第三节点设备发送的跨链通信请求，则根据跨链通信协议中的风控规则和跨链通信请求，对第三节点设备的有效性进行验证，获得有效性验证结果；当有效性验证结果表征第三节点设备具有有效性，则获取与第三区块链适配的消息封装格式；根据与第三区块链适配的消息封装格式生成与第三区块链关联的适配库；将与第三区块链关联的适配库，添加至第一区块链上的子账本智能合约包括的适配库集合中。
在一些实施例中，若第一节点设备接收到第三区块链对应的第三节点设备发送的跨链通信请求，则可以获取跨链通信协议中的风控规则，该跨链通信协议中的风控规则规定了节点设备具有有效性的条件。如跨链通信协议中的风控规则规定了在节点设备的信用度大于目标信用度阈值，且进行了实名，且使用了安全链路(即采用了相关的数据交易安全措施)时，则确定节点设备具有有效性。其中，节点设备可以根据需求设置对应的风控规则。其中，在第三节点设备向第一节点设备发送跨链通信请求之前，第三节点设备需要满足跨链通信协议，即第三节点设备需要同意跨链通信协议，并按照跨链通信协议与其他区块链对应的节点设备进行跨链交易。进一步地，第三节点设备可以根据跨链通信协议生成向第一节点设备进行跨链交易的跨链通信请求，该跨链通信请求中携带用于验证第三节点设备 的有效性的设备特征信息，如第三节点设备的信用度、第三节点设备是否进行了实名的实名信息、第三节点设备是否使用了安全链路的安全信息等。
在第一节点设备接收到第三节点设备发送的跨链通信请求后，可以根据跨链通信协议中的风控规则和跨链通信请求，对第三节点设备的有效性进行验证。例如，跨链通信协议中的风控规则规定了节点设备的信用度大于目标信用度阈值时才具有有效性，则第一节点设备可以从跨链通信请求中获取关于第三节点设备的信用度。若第三节点设备的信用度大于目标信用度阈值，则确定第三节点设备具有有效性；若第三节点设备的信用度小于或者等于目标信用度阈值，则确定第三节点设备不具有有效性。例如，跨链通信协议中的风控规则规定了节点设备需要进行实名且使用了安全链路时才具有有效性，则第一节点设备可以获取跨链通信请求携带的关于第三节点设备的实名信息和安全信息。若第三节点设备进行了实名且使用了安全链路，则确定第三节点设备具有有效性；若第三节点设备未进行实名且未使用安全链路，则确定第三节点设备不具有有效性。可选的，第一节点设备可以调用存储至第一区块链上的设备有效性验证模型，将第一节点设备的设备特征信息输入第一区块链上的设备有效性验证模型中，通过设备有效性验证模型，根据跨链通信协议中的风控规则，对第三节点设备的有效性进行预测，得到关于第三节点设备的有效性预测结果。该关于第三节点设备的有效性预测结果包括第三节点设备具有有效性，或者，第三节点设备不具有有效性。这样，通过设备有效性验证模型预测第三节点设备的有效性，可以提高第三节点设备的有效性预测的确定效率。
进一步地，若第一节点设备确定第三节点设备具有有效性，则获取与第三区块适配的消息封装格式。具体的，在第三节点设备向第一节点设备发送跨链通信请求时，在将与第三节点设备适配的消息封装格式添加至跨链通信请求中，第一节点设备可以检测第三节点设备发送的跨链通信请求中是否携带与第三节点设备适配的消息封装格式。若第三节点设备发送的跨链通信请求中携带与第三节点设备适配的消息封装格式，则根据与第三区块链适配的消息封装格式生成与第三区块链关联的适配库；若第三节点设备发送的跨链通信请求中未携带与第三节点设备适配的消息封装格式，则第一节点设备向第三节点设备发送关于与第三节点设备适配的消息封装格式的获取请求，以获取与第三节点设备适配的消息封装格式。进一步地，第一节点设备可以将与第三区块链关联的适配库添加至第一区块链上的子账本智能合约包括的适配库集合中，这样，便可以实现第一区块链上的第一节点设备与更多区块链上的节点设备之间进行跨链交易。
S102，确定与第二节点设备相关联的目标交易数据所在的目标区块，根据与第二区块链适配的消息封装格式，对第一区块链上的目标区块中的目标交易数据和目标交易数据的交易验证信息进行封装，得到目标数据包，根据与第二区块链适配的消息封装格式对目标区块的区块头进行封装，得到封装区块头。
在一些实施例中，第一节点设备可根据业务需求或请求，获取目标区块的区块链标识，该区块链标识用于标识与第二节点设备相关联的目标交易数据所在的目标区块；进而，第一节电设备可根据该区块链标识确定与第二节点设备相关联的目标交易数据所在的目标区块。
在一些实施例中，第一节点设备可根据业务需求或请求，确定与第二节点设备相关联的目标交易数据，进而定位到该目标交易数据所在的目标区块。
在一些实施例中，确定与第二节点设备相关联的目标交易数据所在的目标区块，根据与第二区块链适配的消息封装格式，对第一区块链上的目标区块中的目标交易数据和目标交易数据的交易验证信息进行封装，得到目标数据包，根据与第二区块链适配的消息封装格式对目标区块的区块头进行封装，得到封装区块头，包括：从目标区块的区块体中获取目标交易数据，根据与第二区块链适配的消息封装格式中的交易数据封装格式，对目标交易数据进行封装，得到封装后的目标交易数据；从目标区块的区块头中获取目标交易数据的交易验证信息，根据与第二区块链适配的消息封装格式中的交易验证封装格式，对交易 验证信息进行封装，得到封装后的交易验证信息；对封装后的目标交易数据以及封装后的交易验证信息进行组合，得到目标数据包；根据与第二区块链适配的消息封装格式中的区块头封装格式，对目标区块的区块头进行封装，得到封装区块头。
在一些实施例中，第一节点设备可以从目标区块的区块体中获取目标交易数据，该目标交易数据与第二节点设备关联，即目标交易数据为第一节点设备与第二节点设备之间的跨链数据(如第一节点设备需要同步给第二节点设备的跨链同步数据，或者，第一节点设备需要转移给第二节点设备的跨链转移资产等)。其中，与第二区块链适配的消息封装格式可以包括关于目标交易数据的交易数据封装格式、关于交易验证信息的交易验证封装格式以及关于区块头的区块头封装格式。其中，第一节点设备可以根据与第二区块链适配的消息封装格式中的交易数据封装格式，对第一区块链上的目标区块中的目标交易数据进行封装，得到封装后的目标交易数据。其中，交易数据封装格式可以包括第一区块链中关于交易数据的交易结构、交易协议、交易加密模式以及编码模式等。例如，交易数据封装格式指示交易结构为(资源转出账户，资源转入账户，待转移的资源量)，第一节点设备则需要按照交易数据封装格式，对目标交易数据进行封装，如(第一区块链上的账户1,第二区块链上的账户2,20)。
同时，第一节点设备也可以从目标区块的区块头中获取目标交易数据的交易验证信息，该交易验证信息用于验证第一节点设备是否执行了关于目标交易数据对应的交易业务，即第一区块链上是否存在目标交易数据对应的交易(如是否存在目标交易数据对应的目标区块)。其中，交易验证信息可以包括目标区块对应的默克尔路径、区块地址或者目标区块对应的区块信息等，目标区块的区块信息可以包括目标区块的父区块哈希值或者目标区块的区块头中的信息等。第一节点设备可以从与第二区块链适配的消息封装格式中获取交易验证封装格式，对交易验证信息进行封装，得到封装后的交易验证信息，该交易验证封装格式可以包括关于交易验证信息的验证信息种类(如默克尔路径、父区块头的哈希值或者区块地址等信息)、信息加密模式以及信息编码模式等。进一步地，第一节点设备可以对封装后的目标交易数据以及封装后的交易验证信息进行组合，得到目标数据包。
具体的，第一节点设备可以从第一区块链的目标区块中获取目标区块对应的区块头，根据与第二区块链适配的消息封装格式中包括的区块头封装格式，对目标区块的区块头进行封装，得到封装区块头。其中，区块头封装格式可以包括关于区块头的区块结构(如信息特征、生成时间戳、版本号等)、区块加密模式以及区块编码模式等。
应当理解，第一区块链上包括基于跨链通信协议生成的子账本智能合约，即根据第一区块链的数据处理规范以及跨链通信协议编写的子账本智能合约，该第一区块链上的子账本智能合约存储于维护第一区块链的各个节点设备中，当检测到各个节点设备中存在需要传输的跨链数据(如目标交易数据、交易验证信息以及区块头)时，则自动调用第一区块链上的子账本智能合约，对需要传输的跨链数据进行封装，以及传输封装后的跨链数据。
S103，向与第二节点设备关联的目标中继服务器发生目标数据包，向与第二节点设备关联的目标预言机服务器发送封装区块头，目标中继服务器用于向第二节点设备发送目标数据包，目标预言机服务器用于向第二节点设备发送封装区块头，第二节点设备用于在根据第二区块链上的数据验证规则、封装区块头和目标数据包中的交易验证信息对目标交易数据验证通过时，处理目标数据包中的目标交易数据，数据验证规则与跨链通信协议相关联。
具体的，第一节点设备向与第二节点设备关联的目标中继服务器发送目标数据包，以及向与第二节点设备关联的目标预言机服务器发送封装区块头。其中，目标中继服务器与目标预言机服务器均为区块链之外的独立实体，这样，由区块链之外的目标中继服务器和目标预言机服务器分别转发目标数据包和封装区块头，相对于采用中间区块链来传输两条区块链的跨链数据的方式，本方案可以在实现去中心化的同时，也可以实现形成开放的跨链生态，提高跨链数据传输的安全性。同时，采用目标中继服务器与目标预言机服务器两 个通道分别发送目标数据包和封装区块头，可以提高目标数据包和封装区块头传输的安全性，避免单点被攻击的风险。例如，当目标中继服务器被攻击后，目标数据包被篡改时，第二节点设备接收到目标预言机服务器的封装区块头，以及目标中继服务器发送的篡改的目标数据包后，由于封装区块头以及篡改后的交易验证信息或者目标交易数据不匹配，因此目标交易数据验证不会通过。
其中，目标中继服务器用于向第二节点设备发送目标数据包，目标预言机服务器用于向第二节点设备发送封装区块头。第二节点设备用于在根据第二区块链上的数据验证规则、封装区块头和目标数据包中的交易验证信息对目标交易数据验证通过时，对目标数据包中的目标交易数据进行处理。其中，数据验证规则与跨链通信协议相关联，即数据验证规则为跨链通信协议中规定的关于交易数据的验证规则。处理目标数据包中的目标交易数据，是按照正常的业务逻辑对目标交易数据进行处理，如转账、记账等。中继服务器是用于转发数据包的服务器，目标中继服务器，则是用于转发目标数据包的服务器。预言机服务器是用于转发封装区块头的服务器，预言机服务器中的预言机，可以是指预言机服务器能够提供对交易数据进行验证时所需的数据。目标预言机服务器则是用于转发与目标区块相关的封装区块头的服务器，目标预言机服务器能够提供对目标交易数据进行验证时所需的数据。
可选的，第一区块链上的子账本智能合约可以包括第一对话模块、第一验证模块、第一网络模块以及第一适配库模块。其中，第一对话模块用于接收第一节点设备需要通过跨链通信协议传输给第二节点设备的跨链数据(如目标交易数据、交易验证信息以及区块头)。具体的，当第一节点设备在执行目标交易数据对应的交易业务时，第一节点设备可以调用第一区块链上的子账本智能合约，将目标交易数据写入第一对话模块中，同时写入第一区块链的区块链标识和第二区块链的区块链标识。第一对话模块可以利用与第二区块链适配的目标适配库对目标交易数据进行封装，得到封装后的目标交易数据，进一步地，第一对话模块可以将封装后的目标交易数据发送给验证模块。同时，第一对话模块可以利用与第二区块链适配的目标适配库对目标交易数据的交易验证信息进行封装，得到封装后的交易验证信息，并将封装后的交易验证信息发送给验证模块。第一验证模块可以对封装后的目标交易数据以及封装后的交易验证信息进行组合，得到目标数据包。进一步地，第一验证模块可以使用目标数据包通知第一网络模块需要将目标区块的区块头发送给第二节点设备。同时，第一验证模块还可以使用目标数据包通知目标中继服务器从第一区块链上获取目标数据包。
具体的，第一网络模块可以通知目标预言机服务器从第一区块链上获取关于目标区块的区块头。根据第一网络模块的通知，目标预言机服务器可以向第一节点设备发送关于目标区块的区块头的获取请求。第一节点设备可以调用第一对话模块利用与第二区块链适配的目标适配库，对目标区块的区块头进行封装，得到封装区块头。第一对话模块可以将封装区块头发送给第一网络模块，第一网络模块将封装区块头发送给目标预言机服务器。其中，目标中继服务器获取到目标数据包后，可以将目标数据包存储在链外，在满足预设条件时，目标中继服务器把目标数据包发送给第二节点设备。同样的，目标预言机服务器获取到封装区块头后，可以将封装区块头存储在链外，在满足预设条件时，目标预言机服务器把封装区块头发送给第二节点设备。
可选的，第一节点设备向与第二节点设备关联的目标中继服务器发送目标数据包的具体方式可以包括：从候选中继服务器集合中确定与第二节点设备关联的候选中继服务器；从与第二节点设备关联的候选中继服务器确定目标中继服务器；获取目标中继服务器的第一接口协议，调用第一区块链上的子账本智能合约，根据目标中继服务器的第一接口协议，将目标数据包发送给目标中继服务器。
具体的，第一节点设备可以候选中继服务器集合中获取与第二节点设备关联的候选中继服务器，与第二节点设备关联的候选中继服务器可以是第二节点设备信任的中继服务器， 或者与第二节点设备建立通信连接的中继服务器。进一步地，第一节点设备可以从与第二节点设备关联的候选中继服务器确定目标中继服务器，并获取目标中继服务器的第一接口协议，调用第一区块链上的子账本智能合约，根据目标中继服务器的第一接口协议，将目标数据包发送给目标中继服务器。其中，除第一节点设备和第二节点设备之外的其他节点设备(即第三方)可以通过资质审查和接口适配后成为中继服务器，第一节点设备或者第二节点设备可以需求选择信任的中继服务器。应当理解，不同区块链可以自适应选用所信任的中继服务器。其中，资质审查的规则可以由跨链通信协议中约定，如在节点设备信用度高于预设信用度阈值，且进行实名，且提供服务的可用性高于目标可用性，且使用了安全链路等条件时，则确定节点设备满足成为中继服务器的资格。其中，接口适配是指所有的中继服务器均按照统一的接口协议进行通信，且配置关于数据转发接口，这样，节点设备可以条用中继服务器中的数据转发接口，以将目标数据包转发给对应节点设备。
在一些实施例中，调用第一区块链上的子账本智能合约，根据目标中继服务器的第一接口协议，将目标数据包发送给目标中继服务器包括：调用第一区块链上的子账本智能合约，获取第一接口协议中的第一数据通信方式和第一通信数据格式；根据第一通信数据格式，生成携带目标数据包以及第二区块链的区块链标识的第一数据转发请求；通过第一数据通信方式，将第一数据转发请求发送给目标中继服务器，目标中继服务器用于获取第一数据转发请求中携带的第二区块链的区块链标识，根据第二区块链的区块链标识，将目标数据包转发给维护第二区块链的第二节点设备。
具体的，第一节点设备可以调用第一区块链上的子账本智能合约，获取第一接口协议中的第一数据通信格式和第一数据通信方式，该第一数据通信格式可以是指目标中继服务器能够解析的数据格式，如(原地址，目的地址，待转发数据)。第一数据通信方式可以是指Http(即Http是一种网络传输协议)/TCP(即一种面向连接的、可靠的、基于字节流的传输层通信协议)/UDP(即一种无需建立连接就可以发送封装数据包的方法)等中的任意一种。第一节点设备可以根据第一通信数据格式，生成携带目标数据包以及第二区块链的区块链标识的第一数据转发请求。进一步地，第一节点设备可以通过第一数据通信方式将第一数据转发请求发送给目标中继服务器，目标中继服务器可以根据第一数据转发请求中携带的第二区块链的区块链标识，将目标数据包转发给维护第二区块链的第二节点设备中。
可选的，第一节点设备从与第二节点设备关联的候选中继服务器确定目标中继服务器的具体内容可以包括：若与第二节点设备关联的候选中继服务器的数量为一个，则将与第二节点设备关联的候选中继服务器确定为目标中继服务器。若与第二节点设备关联的候选中继服务器的数量为至少两个，则获取至少两个候选中继服务器分别对应的信用度，将至少两个候选中继服务器中具有最大信用度的候选中继服务器，确定为目标中继服务器。
具体的，第一节点设备可以获取与第二节点设备关联的候选中继服务器的数量，检测与第二节点设备关联的候选中继服务器的数量是否大于1，若与第二节点设备关联的候选中继服务器的数量等于1，则第一节点设备可以直接将与第二节点设备关联的候选中继服务器确定为目标中继服务器。若与第二节点设备关联的候选中继服务器的数量为至少两个，则第一节点设备可以从至少两个候选中继服务器中确定目标中继服务器。具体的，第一节点设备可以获取至少两个中继服务器分别对应的信用度，将至少两个候选中继服务器中具有最大信用度的候选中继服务器，确定为目标中继服务器。当然，第一节点设备可以获取至少两个候选中继服务器分别对应的特征信息，该特征信息可以包括信用度、提供服务的可用性、安全性等信息。进一步地，第一节点设备可以根据每个候选中继服务器对应的特征信息，生成对应候选中继服务器的设备评分，将至少两个候选中继服务器中具有最高设备评分的候选中继服务器，确定为目标中继服务器。这样，第一节点设备可以选择自己所信任的目标中继服务器，可以提高数据转发的安全性。
可选的，第一节点设备向与第二节点设备关联的目标预言机服务器发送封装区块头的具体方式可以包括：从候选预言机服务器集合中确定与第二节点设备关联的候选预言机服 务器。根据与第二节点设备关联的候选预言机服务器确定目标预言机服务器，获取目标预言机服务器的第二接口协议，调用第一区块链上的子账本智能合约，根据目标预言机服务器的第二接口协议，将封装区块头发送给目标预言机服务器。
具体的，第一节点设备可以从候选预言机服务器集合中获取与第二节点设备关联的候选预言机服务器，与第二节点设备关联的候选预言机服务器可以是第二节点设备信任的预言机服务器，或者与第二节点设备建立通信连接的预言机服务器。进一步地，第一节点设备可以根据与第二节点设备关联的候选预言机服务器确定目标预言机服务器，并获取目标预言机服务器的第二接口协议，调用第一区块链上的子账本智能合约，根据目标预言机服务器的第二接口协议，将封装区块头发送给目标预言机服务器。其中，除第一节点设备和第二节点设备之外的其他节点设备(即第三方)可以通过资质审查和接口适配后成为预言机服务器，第一节点设备或者第二节点设备可以需求选择信任的预言机服务器。应当理解，不同区块链可以自适应选用所信任的预言机服务器。其中，资质审查的规则可以由跨链通信协议中约定，如在节点设备信用度高于设备信用度阈值，且进行了实名，且提供服务的可用性高于目标可用性，且使用了安全链路等条件时，则确定节点设备满足成为预言机服务器的资格。其中，设备信用度阈值与上述成为中继服务器时所需要的预设信用度阈值可以相同，也可以不同。其中，接口适配是指所有的预言机服务器均按照统一的接口协议进行通信，且配置关于数据转发接口，这样，节点设备可以条用预言机服务器中的数据转发接口，以将封装区块头转发给对应节点设备。
可选的，第一节点设备调用第一区块链上的子账本智能合约，根据目标预言机服务器的第二接口协议，将封装区块头发送给目标预言机服务器的具体方式可以包括：调用第一区块链上的子账本智能合约，获取第二接口协议的第二数据通信方式和第二通信数据格式。根据第二通信数据格式，生成携带封装区块头以及第二区块链的区块链标识的第二数据转发请求。通过第二数据通信方式，将第二数据转发请求发送给目标预言机服务器；目标预言机服务器用于根据第二数据转发请求中携带的第二区块链的区块链标识，将封装区块头转发给维护第二区块链的第二节点设备。
具体的，第一节点设备可以调用第一区块链上的子账本智能合约，获取第二接口协议中的第二数据通信格式和第二数据通信方式，该第二数据通信格式可以是指目标预言机服务器能够解析的数据格式，如(原地址，目的地址，待转发数据)。第二数据通信方式可以是指Http(即Http是一种网络传输协议)/TCP(即一种面向连接的、可靠的、基于字节流的传输层通信协议)/UDP(即一种无需建立连接就可以发送封装数据包的方法)等中的任意一种。第一节点设备可以根据第二通信数据格式，生成携带封装区块头以及第二区块链的区块链标识的第二数据转发请求。进一步地，第一节点设备可以通过第二数据通信方式将第二数据转发请求发送给目标预言机服务器，目标预言机服务器可以根据第二数据转发请求中携带的第二区块链的区块链标识，将封装区块头转发给维护第二区块链的第二节点设备中。
可选的，第一节点设备根据与第二节点设备关联的候选预言机服务器确定目标预言机服务器的具体内容可以包括：若与第二节点设备关联的候选预言机服务器的数量为一个，则将与第二节点设备关联的候选预言机服务器确定为目标预言机服务器。若与第二节点设备关联的候选预言机服务器的数量为至少两个，则获取至少两个候选预言机服务器分别对应的信用度，将至少两个候选预言机服务器中具有最大信用度的候选预言机服务器，确定为目标预言机服务器。
具体的，第一节点设备可以获取与第二节点设备关联的候选预言机服务器的数量，检测与第二节点设备关联的候选预言机服务器的数量是否大于1，若与第二节点设备关联的候选预言机服务器的数量等于1，则第一节点设备可以直接将与第二节点设备关联的候选预言机服务器确定为目标预言机服务器。若与第二节点设备关联的候选预言机服务器的数量为至少两个，则第一节点设备可以从至少两个候选预言机服务器中确定目标预言机服务 器。具体的，第一节点设备可以获取至少两个预言机服务器分别对应的信用度，将至少两个候选预言机服务器中具有最大信用度的候选预言机服务器，确定为目标预言机服务器。当然，第一节点设备可以获取至少两个候选预言机服务器分别对应的特征信息，该特征信息可以包括信用度、提供服务的可用性、安全性等信息。进一步地，第一节点设备可以根据每个候选预言机服务器对应的特征信息，生成对应候选预言机服务器的设备评分，将至少两个候选预言机服务器中具有最高设备评分的候选预言机服务器，确定为目标预言机服务器。这样，第一节点设备可以选择自己所信任的目标预言机服务器，可以提高数据转发的安全性。
可选的，目标预言机服务器用于在区块数量大于目标数量阈值时，将封装区块头发送给第二节点设备；区块数量为第一区块链上生成时间戳晚于目标区块的生成时间戳的区块对应的数量。可以理解的是，目标预言机服务器在获取到第一区块链上的目标区块对应的封装区块头后，可以将封装区块头存储在区块链之外(如目标预言机服务器本地)。同时目标预言机服务器可以获取第一区块链上生成时间戳晚于目标区块的生成时间戳的区块对应的区块数量，即获取目标区块对应的区块确认数量，当第一区块链上添加一个生成时间戳晚于目标区块的生成时间戳的区块时，目标区块对应的区块确认数量加一。当目标预言机服务器确定区块数据大于目标数据阈值时，说明目标区块在第一区块链上达到了最终性，则目标预言机服务器可以将封装区块头发送给第二节点设备。其中，目标区块在第一区块链上达到最终性说明目标区块不可能被撤销或者更改，这样，只有在目标区块在第一区块链上达到最终性时，才把封装区块头发送给第二节点设备，可以确保跨链交易成功执行的。
可选的，目标中继服务器用于在根据第一区块链上的目标区块的区块头确定目标数据包中的目标交易数据验证通过时，将目标数据包发送给第二节点设备。可以理解的是，目标中继服务器在获取到目标数据包后，可以将目标数据包存储在区块链之外(如目标中继服务器本地)。同时目标中继服务器可以根据第一区块链上的目标区块的区块头对目标交易数据进行验证，即验证第一节点设备是否执行目标交易数据对应的交易业务。若目标交易数据验证通过，则目标中继服务器可以将目标数据包发送给第二节点设备；若目标交易数据未验证通过，则目标中继服务器可以将目标数据包确定无效消息，并对无效消息进行消除，以防止在攻击。在累计多次遇到相同来源(即同一节点设备)的无效消息时，就会进行恶意行为汇报，降低对应节点设备的信用度。
应当理解，第二节点设备接收到目标数据包和封装区块头后，可以对目标数据包进行解析，得到目标交易数据和交易验证信息。进一步地，第二节点设备可以对目标交易数据进行验证，即验证第一节点设备是否成功执行目标交易数据对应的交易业务。具体的，第二节点设备可以根据封装区块头以及交易验证信息，对目标交易数据进行验证，其中，封装区块头中包括目标区块的相关信息，如目标交易数据的特征值(如默克尔树根哈希值)、区块生成时间戳、父区块哈希值等。可选的，第二区块链上包括基于跨链通信协议生成的子账本智能合约，第二节点设备接收到目标数据包和封装区块头后，可以调用第二区块链上的子账本智能合约，对目标交易数据进行验证。
如图7所示，图7是本申请实施例提供的一种跨链通信的示意图，如图7所示，第一区块链上包括基于跨链通信协议生成的子账本智能合约，第二区块链上包括基于跨链通信协议生成的子账本智能合约。如图7所示，维护第一区块链的第一节点设备接收到目标交易数据时，可以根据目标交易数据的交易类型调用第一区块链上的目标智能合约(如执行目标交易数据的应用合约)，执行目标交易数据对应的交易业务。第一节点设备可以生成关于目标交易数据的目标区块，并将目标区块添加至第一区块链上。同时，在目标交易数据为与第二节点设备相关联的数据时，第一节点设备在调用第一区块链上的目标智能合约执行目标交易数据对应的交易业务时，可以调用第一区块链上的子账本智能合约，对需要发送给第二节点设备的跨链数据(如目标交易数据、目标交易数据的交易验证信息以及目标区块的区块头)进行封装，并将对目标交易数据以及目标交易数据的交易验证信息进行封 装得到的目标数据包发送给目标中继服务器(目标中继服务器可以是指第一节点设备从候选中继服务器中确定的)。同时，第一节点设备可以调用第一区块链上的子账本智能合约，将对目标区块的区块头进行封装得到的封装区块头发送给目标预言机服务器(目标预言机服务器可以是指第一节点设备从候选预言机服务器中确定的)。具体可以参考上述步骤S101-S103的内容，本申请实施例在此不再赘述。
进一步地，目标预言机服务器在接收到封装区块头后，可以获取第一区块链上生成时间戳晚于目标区块的生成时间戳的区块对应的数量，在区块数量大于目标数量阈值时，将封装区块头发送给第二节点设备。即当目标预言机服务器在确定目标区块在第一区块链上达到了最终性时，将封装区块头发送给第二节点设备。目标中继服务器在接收到封装区块头后，可以根据第一区块链上的目标区块的区块头确定目标数据包中的目标交易数据验证通过时，将目标数据包发送给第二节点设备。目标中继服务器与目标预言机服务器均为区块链之外的独立实体，这样，通过两个区块链之外的独立实体分别转发目标数据包和封装区块头，可以避免单点转发被攻击的风险，提高跨链通信的安全性。换句话说，只要目标预言机服务器和目标中继服务器的独立性条件没有被破坏，就可以保证任意跨链数据的无信任有效传递，提高跨链数据传输的安全性。同时，第一节点设备将与第二节点设备相关联的目标交易数据等数据同步至第二节点设备，不需要将第一区块链上的所有数据同步至第二节点设备，以降低数据传输成本，大大节约链上的存储成本和存储费用。
进一步地，当第二节点设备通过第二区块链上的子账本智能合约接收到目标数据包和封装区块头时，可以调用第二区块链上的子账本智能合约，按照第二区块链上的数据验证规则，根据封装区块头以及目标数据包中的交易验证信息，对目标交易数据进行验证。在对目标交易数据验证通过时，调用第二区块链上的子账本智能合约将目标交易数据发送给第二区块链上的目标智能合约，执行目标交易数据对应的交易业务，该第二区块链上的目标智能合约是基于目标交易数据的交易类型确定的。这样，可以实现目标交易数据的链上验证，避免目标交易数据被篡改，提高目标交易数据的安全性，提高跨链通信的安全性和效率。
在本申请实施例中提供了一种通用的跨链通信架构，跨链通信架构制定了跨链通信协议，该跨链通信协议中包括与多个区块链分别适配的数据封装格式，以及区块链对应的节点设备加入跨链通信的准入条件(即风控规则)等等，该跨链通信架构包括用于实现跨链通信的预言机服务器以及中继服务器。当第一区块链与第二区块链之间进行跨链通信时，第一区块链对应的第一节点设备和第二区块链对应的第二节点设备均满足该跨链通信协议，即第一节点设备和第二节点设备均满足该跨链通信协议中的跨链通信的准入条件，这样有利于确保实现跨链通信的安全性。具体实现过程中，第一节点设备可以从第一区块链上的跨链通信协议中，选择与第二区块链适配的数据封装格式，对该第一区块链上的目标区块中的目标交易数据和该目标交易数据的交易验证信息进行封装，得到目标数据包，根据与该第二区块链适配的消息封装格式对该目标区块的区块头进行封装，得到封装区块头。这样有利于第二节点设备能够成功对目标数据包以及封装区块头进行解析，实现第一节点设备与第二节点设备之间的互联互通，即实现第一区块链与第二区块链之间的互联互通，也即实现跨链通信。
进一步，第一节点设备可以将该目标数据包和封装区块头分两路独立发送，即将该目标数据包发送至该跨链通信架构中与第二节点设备关联的目标中继服务器，将该封装区块头发送至该跨链通信架构中与第二节点设备关联的目标预言机服务器，由中继服务器将目标数据包发送至第二节点设备，并由目标预言机服务器将封装区块头发送至第二节点设备。目标中继服务器与目标预言机服务器均为区块链之外的独立实体，这样，通过两个区块链之外的独立实体分别转发目标数据包和封装区块头，可以避免单点转发被攻击的风险，提高跨链通信的安全性。换句话说，只要目标预言机服务器和目标中继服务器的独立性条件没有被破坏，就可以保证任意跨链数据的无信任有效传递，提高跨链数据传输的安全性。 同时，第一节点设备将与第二节点设备相关联的目标交易数据等数据同步至第二节点设备，不需要将第一区块链上的所有数据同步至第二节点设备，以降低数据传输成本，大大节约链上的存储成本和存储费用。在第二节点设备获取到目标数据包以及封装区块头后，第二节点设备在根据第二区块链上的数据验证规则、封装区块头和目标数据包中的交易验证信息对目标交易数据验证通过时，才对目标数据包中的目标交易数据进行处理，实现目标交易数据的链上验证，避免目标交易数据被篡改，提高目标交易数据的安全性，提高跨链通信的安全性和效率。
进一步地，请参见图8，图8是本申请实施例提供的一种区块链数据处理方法的流程示意图。如图8所示，该方法可以由区块链网络中维护第二区块链的第二节点设备执行，该区块链网络可以是指上述的核心共识网络，也可以是指上述的业务网络，也可以是其他区块链网络，本申请实施例在此不做限制，该第二节点设备可以为接入至该区块链网络中的服务器，也可以为接入至区块链网络中的用户终端，第二点设备可以是指维护第二区块链的节点设备中的任意一个节点设备，这里对第二节点设备的具体形式不做限定。该方法至少可以包括但不限于以下步骤：
S201，当接收到目标中继服务器发送的目标数据包，以及接收到目标预言机服务器发送的封装区块头，则解析目标数据包，得到目标数据包中的目标交易数据和目标交易数据的交易验证信息。
具体的，目标数据包是由维护第一区块链的第一节点设备向目标中继服务器发送的，封装区块头是由第一节点设备向目标预言机服务器发送的，目标数据包是基于与第二节点设备维护的第二区块链适配的消息封装格式，对目标交易数据以及目标交易数据的交易验证信息进行封装得到的，目标交易数据为第一区块链的目标区块中的交易数据，封装区块头是基于消息封装格式对目标区块的区块头进行封装得到的；消息封装格式是从第一区块链上的跨链通信协议中选择得到的，第一节点设备和第二节点设备依照跨链通信协议通信。具体内容可以参考上述图6中步骤S101-步骤S103的内容。
S202，按照第二区块链上的数据验证规则，根据封装区块头和交易验证信息对目标交易数据进行验证，得到验证结果。
具体的，第二节点设备获取第二区块链上的数据验证规则，该数据验证规则与跨链通信协议相关联，可以理解的是，该数据验证规则可以为跨链通信协议中约定的针对交易数据(如目标交易数据)的验证规则。第一节点设备可以根据封装区块头和交易验证信息对目标交易数据进行验证，得到验证结果，该验证结果包括目标交易数据验证通过，或者，目标交易数据验证未通过。其中，交易验证信息可以包括目标区块对应的默克尔路径、目标区块的区块信息(如生成时间戳、区块地址、区块版本号等)以及目标区块对应的父区块哈希值等。其中，数据验证规则可以包括关于默克尔路径的验证规则、关于父区块哈希值的验证规则以及关于区块信息的验证规则等。
可选的，第二区块链上包括基于跨链通信协议生成的子账本智能合约，交易验证信息包括与目标区块关联的默克尔路径，第二区块链上的数据验证规则包括关于默克尔路径的验证规则。第二节点设备根据封装区块头和交易验证信息对目标交易数据进行验证的具体方式可以包括：调用第二区块链上的子账本智能合约，对目标交易数据进行哈希算法，得到待验证哈希值，根据默克尔路径对待验证哈希值进行哈希运算，得到待验证树根哈希值。从封装区块头中获取默克尔树根哈希值。获取默克尔树根哈希值与待验证树根哈希值的一致性检验结果，根据一致性检验结果，生成用于指示目标交易数据是否通过验证的验证结果。其中，若一致性检验结果表征封装区块头中的默克尔树根哈希值与待验证树根哈希值相同，则生成用于指示目标交易数据验证通过的验证结果；若一致性检验结果表征封装区块头中的默克尔树根哈希值与待验证树根哈希值不相同，则生成用于指示目标交易数据验证未通过的验证结果。
具体的，默克尔树也称为哈希二叉树，是一种用于有效地汇总和验证大型数据集完整 性的数据结构，包括从交易数据到树根的默克尔路径，默克尔树是由叶子节点两两组合生成的，因此，可以根据目标交易数据到树根之间的默克尔路径，便可以得到树根哈希值。第二节点设备可以调用第二区块链上的子账本智能合约，对目标交易数据进行哈希算法，得到待验证哈希值，根据默克尔路径对待验证哈希值进行哈希运算，得到待验证树根哈希值。其中，关于默克尔路径的验证规则用于指示在封装区块头中的默克尔树根哈希值与待验证树根哈希值相同时，确定目标交易数据验证通过；在封装区块头中的默克尔树根哈希值与待验证树根哈希值不相同时，确定目标交易数据验证未通过。进一步地，第二节点设备可以根据关于默克尔路径的验证规则，从封装区块头中获取默克尔树根哈希值，若封装区块头中的默克尔树根哈希值与待验证树根哈希值相同，则生成用于指示目标交易数据验证通过的验证结果。若封装区块头中的默克尔树根哈希值与待验证树根哈希值不相同，则生成用于指示目标交易数据验证未通过的验证结果。
可选的，交易验证信息包括目标区块的父区块的目标区块哈希值，第二区块链上的数据验证规则包括关于目标区块的父区块的目标区块哈希值的验证规则。第二节点设备根据封装区块头和交易验证信息对目标交易数据进行验证的具体方式可以包括：调用第二区块链上的子账本智能合约，从封装区块头中获取目标区块的父区块的区块哈希值，作为待验证父区块哈希值。对待验证父区块哈希值和目标父区块哈希值进行一致性比对，获得第二比对结果，根据第二比对结果，生成用于指示目标交易数据是否通过验证的验证结果。其中，关于目标父区块哈希值的验证规则指示在封装区块头中的目标父区块哈希值与封装区块头中的待验证父区块哈希值相同时，确定目标交易数据验证通过；在封装区块头中的目标父区块哈希值与封装区块头中的待验证父区块哈希值不相同时，确定目标交易数据验证未通过。具体的，若待验证父区块哈希值和目标父区块哈希值相同，则第二节点设备生成用于指示目标交易数据验证通过的验证结果；若待验证父区块哈希值和目标父区块哈希值不相同，则第二节点设备生成用于指示目标交易数据验证通过的验证结果。
S203，当验证结果指示目标交易数据验证通过，则处理目标数据包中的目标交易数据。
具体的，若验证结果指示目标交易数据验证通过，则第二节点设备可以调用第二区块链上的目标智能合约，对目标数据包中的目标交易数据进行处理。其中，第二区块链上的目标智能合约与目标交易数据相关联，可以理解的是，第二区块链上的目标智能合约是基于目标交易数据的交易类型确定的，若目标交易数据的交易类型为数字藏品交易时，则第二区块链上的目标智能合约可以是指数字藏品合约。
可选的，第二区块链上包括基于跨链通信协议生成的子账本智能合约，第二区块链上的子账本智能合约包括第二对话模块、第二验证模块、第二网络模块以及第二适配库模块。同样的，第二对话模块可以用于封装跨链数据，第二验证模块用于验证交易数据，第二网络模块用于通信，第二适配库模块用于存储区块链关联的适配库。目标预言机服务器可以将封装区块头发送给第二网络模块，第二网络模块可以将封装区块头转发给第二验证模块。同样的，目标中继服务器可以将目标数据包发送给第二验证模块，第二验证模块在接收到目标数据包以及封装区块头后，可以按照第二区块链上的数据验证规则，根据封装区块头以及交易验证信息，对目标交易数据进行验证。在对目标交易数据验证通过时，第二验证模块可以将目标交易数据发送给第二对话模块，第二对话模块可以根据目标智能合约的合约地址，将目标交易数据发送到第二区块链上的目标智能合约，并调用第二区块链上的目标智能合约对目标交易数据进行处理。
例如，目标交易数据为(第一区块链502中的账户1,第二区块链512中的账户2,20)，账户1表示资源转出账户，账户2表示资源转入账户，20表示待转移的资源量，账户1是第一区块链502中的账户，账户2是第二区块链512中的账户。第一节点设备可以调用第一区块链上关于资产交易的智能合约，执行目标交易数据指示的第一区块链的账户1被扣除数量为20的资源数据的交易，并生成目标交易数据对应的目标区块，将目标交易数据对应的目标区块存储至第一区块链上。进一步地，第一节点设备可以调用第一区块链上的子 账本智能合约，通过目标中继服务器将包含目标交易数据以及交易验证信息的目标数据包发送给第二节点设备。第一节点设备可以调用第一区块链上的子账本智能合约，通过目标预言机服务器将目标区块对应的封装区块头发送给第二节点设备。第二节点设备可以通过第二区块链上的子账本智能合约，根据封装区块头以及交易验证信息，对目标交易数据进行验证，在目标交易数据验证通过时，则第二节点设备可以调用第二区块链上关于资产交易的智能合约，执行目标交易数据指示的第二区块链的账户2增加数量为20的资源数据的交易。
如图9所示，图9是本申请实施例提供的一种跨链通信的应用示意图，如图9所示，第一节点设备90A在接收到与第二节点设备90D相关联的目标交易数据，可以调用第一区块链中的目标智能合约，执行目标交易数据对应的交易业务，该第一区块链上的目标智能合约是基于目标交易数据的交易类型确定的。进一步地，第一节点设备90A可以生成关于目标交易数据对应的交易业务的目标区块911A，在第一区块链91A上添加目标区块911A。进一步地，第一节点设备可以调用第一区块链上的子账本智能合约82A，该第一区块链上的子账本智能合约82A是基于第一区块链91A上的合约编写规范以及跨链通信协议编写得到的。如图9所示，子账本智能合约82A包括第一对话模块、第一验证模块、第一网络模块以及第一适配库模块。第一节点设备90A通过子账本智能合约82A中的第一对话模块，从第一适配库模块中选择与第二节点设备90D对应的第二区块链适配的消息封装格式。进一步地，第一对话模块可以采用与第二区块链适配的消息封装格式对目标区块911A中的目标交易数据和目标交易数据进行封装，得到目标数据包，采用与第二区块链适配的消息封装格式对目标区块911A的区块头进行封装，得到封装区块头。
进一步地，第一对话模块可以将目标数据包发送给第一验证模块，第一验证模块可以向目标中继服务器90B发送关于目标数据包的获取通知，以通知目标中继服务器从第一节点设备90A中获取目标数据包。目标中继服务器90B接收到第一验证模块发送的关于目标数据包的获取通知后，可以从第一节点设备90A中获取目标数据包。同时，目标中继服务器90B可以根据第一区块链上的目标区块911A的区块头对目标交易数据进行验证，在确定目标交易数据验证通过后，将目标数据包转发给第二节点设备90D。同样的，第一验证模块可以将关于第二区块链的区块链标识发送给第一网络模块，第一网络模块可以基于第二区块链的区块链标识向目标预言机服务器90C发送关于封装区块头的获取请求，该获取请求携带目标区块911A的块标识，该获取请求用于指示目标预言机服务器90C从第一节点设备90A中获取封装区块头，以及指示目标预言机服务器90C将封装区块头转发给第二节点设备90D。
应当理解，目标预言机服务器90C接收到关于封装区块头的获取请求后，可以基于目标区块的块标识从第一节点设备中获取封装区块头，目标预言机服务器90C在获取到第一区块链上的目标区块911A对应的封装区块头后，可以将封装区块头存储在区块链之外(如目标预言机服务器90C本地)。同时目标预言机服务器90C可以获取第一区块链91A上生成时间戳晚于目标区块的生成时间戳的区块对应的区块数量。当目标预言机服务器90C确定区块数据大于目标数据阈值时，说明目标区块911A在第一区块链上达到了最终性，则目标预言机服务器90C可以将封装区块头发送给第二节点设备90D。如图9所示，第二区块链上包括基于第二区块链上的合约编写规范以及跨链通信协议编写得到的子账本智能合约91D，该子账本智能合约91D包括第二对话模块、第二验证模块、第二网络模块以及第二适配库模块。目标中继服务器90B可以将目标数据包转发给第二网络模块，目标预言机服务器可以将封装区块头转发给第二验证模块。
进一步地，第二网络模块可以将封装区块头转发给第二验证模块，第二验证模块可以获取第二区块链上的数据验证规则，根据封装区块头和交易验证信息对目标交易数据进行验证，得到验证结果。若目标交易数据验证通过，则第二验证模块可以将目标交易数据转发给第二对话模块，第二对话模块可以将目标交易数据转发到第二区块链上的目标智能合 约，执行目标交易数据对应的交易业务。其中，第二区块链上的目标智能合约与目标交易数据相关联，可以理解的是，第二区块链上的目标智能合约是基于目标交易数据的交易类型确定的，若目标交易数据的交易类型为数字藏品交易时，则第二区块链上的目标智能合约可以是指数字藏品合约。可见，通过目标中继服务器与目标预言机服务器两个区块链之外的独立实体分别转发目标数据包和封装区块头，可以避免单点转发被攻击的风险，提高跨链通信的安全性。同时，第二节点设备在根据第二区块链上的数据验证规则、封装区块头和目标数据包中的交易验证信息对目标交易数据验证通过时，才对目标数据包中的目标交易数据进行处理，实现目标交易数据的链上验证，避免目标交易数据被篡改，提高目标交易数据的安全性，提高跨链通信的安全性和效率。
在本申请实施例中提供了一种通用的跨链通信架构，跨链通信架构制定了跨链通信协议，该跨链通信协议中包括与多个区块链分别适配的数据封装格式，以及区块链对应的节点设备加入跨链通信的准入条件(即风控规则)等等，该跨链通信架构包括用于实现跨链通信的预言机服务器以及中继服务器。当第一区块链与第二区块链之间进行跨链通信时，第一区块链对应的第一节点设备和第二区块链对应的第二节点设备均满足该跨链通信协议，即第一节点设备和第二节点设备均满足该跨链通信协议中的跨链通信的准入条件，这样有利于确保实现跨链通信的安全性。具体实现过程中，第一节点设备可以从第一区块链上的跨链通信协议中，选择与第二区块链适配的数据封装格式，对该第一区块链上的目标区块中的目标交易数据和该目标交易数据的交易验证信息进行封装，得到目标数据包，根据与该第二区块链适配的消息封装格式对该目标区块的区块头进行封装，得到封装区块头。这样有利于第二节点设备能够成功对目标数据包以及封装区块头进行解析，实现第一节点设备与第二节点设备之间的互联互通，即实现第一区块链与第二区块链之间的互联互通，也即实现跨链通信。
进一步，第一节点设备可以将该目标数据包和封装区块头分两路独立发送，即将该目标数据包发送至该跨链通信架构中与第二节点设备关联的目标中继服务器，将该封装区块头发送至该跨链通信架构中与第二节点设备关联的目标预言机服务器，由中继服务器将目标数据包发送至第二节点设备，并由目标预言机服务器将封装区块头发送至第二节点设备。目标中继服务器与目标预言机服务器均为区块链之外的独立实体，这样，通过两个区块链之外的独立实体分别转发目标数据包和封装区块头，可以避免单点转发被攻击的风险，提高跨链通信的安全性。换句话说，只要目标预言机服务器和目标中继服务器的独立性条件没有被破坏，就可以保证任意跨链数据的无信任有效传递，提高跨链数据传输的安全性。同时，第一节点设备将与第二节点设备相关联的目标交易数据等数据同步至第二节点设备，不需要将第一区块链上的所有数据同步至第二节点设备，以降低数据传输成本，大大节约链上的存储成本和存储费用。在第二节点设备获取到目标数据包以及封装区块头后，第二节点设备在根据第二区块链上的数据验证规则、封装区块头和目标数据包中的交易验证信息对目标交易数据验证通过时，才对目标数据包中的目标交易数据进行处理，实现目标交易数据的链上验证，避免目标交易数据被篡改，提高目标交易数据的安全性，提高跨链通信的安全性和效率。同时，根据第二区块链上的数据验证规则、封装区块头和目标数据包中的交易验证信息对目标交易数据验证，在确实需要时才消耗链上存储，大大节约链上存储成本和费用。
进一步地，请参见图10，图10是本申请实施例提供的一种区块链数据处理装置的结构示意图。该区块链数据处理装置1可以是运行于计算机设备中的一个计算机可读指令(包括程序代码)，例如，该区块链数据处理装置1为一个应用软件；该区块链数据处理装置1可以用于执行本申请实施例提供的方法中的相应步骤。如图10所示，该区块链数据处理装置1可以为维护第一区块链的第一节点设备。该区块链数据处理装置1可以包括：选择模块11、封装模块12、发送模块13、设备验证模块14、获取模块15、生成模块16以及添加模块17。
选择模块11，用于从第一区块链上的跨链通信协议中，选择与第二区块链适配的消息封装格式，第一区块链由区块链网络中第一节点设备维护，第二区块链由区块链网络中第二节点设备维护，第一节点设备和第二节点设备依照跨链通信协议通信；
封装模块12，用于确定与第二节点设备相关联的目标交易数据所在的目标区块，根据与第二区块链适配的消息封装格式，对第一区块链上的目标区块中的目标交易数据和目标交易数据的交易验证信息进行封装，得到目标数据包，根据与第二区块链适配的消息封装格式对目标区块的区块头进行封装，得到封装区块头；
发送模块13，用于向与第二节点设备关联的目标中继服务器发生目标数据包，向与第二节点设备关联的目标预言机服务器发送封装区块头，目标中继服务器用于向第二节点设备发送目标数据包，目标预言机服务器用于向第二节点设备发送封装区块头，第二节点设备用于在根据第二区块链上的数据验证规则、封装区块头和目标数据包中的交易验证信息对目标交易数据验证通过时，处理目标数据包中的目标交易数据，数据验证规则与跨链通信协议相关联向与第二节点设备关联的目标中继服务器发送目标数据包。
其中，第一区块链上包括基于跨链通信协议生成的子账本智能合约；选择模块11包括：第一获取单元1101，用于获取第二区块链的区块链标识；第一确定单元1102，用于从第一区块链上的子账本智能合约中获取适配库集合，根据第二区块链的区块链标识，从适配库集合中，确定与第二区块链相关联的目标适配库；第二获取单元1103，用于从目标适配库中，获取与第二节点设备对应的第二区块链适配的消息封装格式。
其中，区块链数据处理装置1还包括：设备验证模块14，用于当接收到第三区块链对应的第三节点设备发送的跨链通信请求，则根据跨链通信协议中的风控规则和跨链通信请求，对第三节点设备的有效性进行验证，获得有效性验证结果；获取模块15，用于当有效性验证结果表征第三节点设备具有有效性，则获取与第三区块链适配的消息封装格式；生成模块16，用于根据与第三区块链适配的消息封装格式生成与第三区块链关联的适配库；添加模块17，用于将与第三区块链关联的适配库添加至第一区块链上的子账本智能合约包括的适配库集合中。
其中，封装模块12包括：第一封装单元1201，用于从目标区块的区块体中获取目标交易数据，根据与第二区块链适配的消息封装格式中的交易数据封装格式，对目标交易数据进行封装，得到封装后的目标交易数据；第二封装单元1202，用于从目标区块的区块头中获取目标交易数据的交易验证信息，根据与第二区块链适配的消息封装格式中的交易验证封装格式，对交易验证信息进行封装，得到封装后的交易验证信息；组合单元1203，用于对封装后的目标交易数据以及封装后的交易验证信息进行组合，得到目标数据包；
第三封装单元1204，用于根据与第二区块链适配的消息封装格式中的区块头封装格式，对目标区块的区块头进行封装，得到封装区块头。
其中，发送模块13包括：第二确定单元1301，用于从候选中继服务器集合中确定与第二节点设备关联的候选中继服务器；第三确定单元1302，用于从与第二节点设备关联的候选中继服务器中确定目标中继服务器；
第一发送单元1303，用于获取目标中继服务器的第一接口协议，调用第一区块链上的子账本智能合约，根据目标中继服务器的第一接口协议，将目标数据包发送给目标中继服务器。
其中，第一发送单元1303具体用于：调用第一区块链上的子账本智能合约，获取第一接口协议中的第一数据通信方式和第一通信数据格式；根据第一通信数据格式，生成携带目标数据包以及第二区块链的区块链标识的第一数据转发请求；通过第一数据通信方式，将第一数据转发请求发送给目标中继服务器，目标中继服务器用于获取第一数据转发请求中携带的第二区块链的区块链标识，根据第二区块链的区块链标识，将目标数据包转发给维护第二区块链的第二节点设备。
在一些实施例，第三确定单元1302具体用于：当与第二节点设备关联的候选中继服务 器的数量为一个，则将与第二节点设备关联的候选中继服务器确定为目标中继服务器。
在一些实施例中，第三确定单元1302用于当与第二节点设备关联的候选中继服务器的数量为至少两个，则获取至少两个候选中继服务器分别对应的信用度，将至少两个候选中继服务器中具有最大信用度的候选中继服务器，确定为目标中继服务器。
其中，发送模块13还包括：第四确定单元1304，用于从候选预言机服务器集合中确定与第二节点设备关联的候选预言机服务器；第五确定单元1305，用于根据与第二节点设备关联的候选预言机服务器确定目标预言机服务器；第二发送单元1306，用于获取目标预言机服务器的第二接口协议，调用第一区块链上的子账本智能合约，根据目标预言机服务器的第二接口协议，将封装区块头发送给目标预言机服务器。
其中，第二发送单元1306具体用于：调用第一区块链上的子账本智能合约，获取第二接口协议的第二数据通信方式和第二通信数据格式；根据第二通信数据格式，生成携带封装区块头以及第二区块链的区块链标识的第二数据转发请求；通过第二数据通信方式，将第二数据转发请求发送给目标预言机服务器；目标预言机服务器用于根据第二数据转发请求中携带的第二区块链的区块链标识，将封装区块头转发给维护第二区块链的第二节点设备。
其中，目标预言机服务器用于在区块数量大于目标数量阈值时，将封装区块头发送给第二节点设备；区块数量为第一区块链上生成时间戳晚于目标区块的生成时间戳的区块对应的数量。
其中，目标中继服务器用于在根据第一区块链上的目标区块的区块头确定目标数据包中的目标交易数据验证通过时，将目标数据包发送给第二节点设备。
根据本申请的一个实施例，图10示的区块链数据处理装置1中的各个模块可以分别或全部合并为一个或若干个单元来构成，或者其中的某个(些)单元还可以再拆分为功能上更小的多个子单元，可以实现同样的操作，而不影响本申请的实施例的技术效果的实现。上述模块是基于逻辑功能划分的，在实际应用中，一个模块的功能也可以由多个单元来实现，或者多个模块的功能由一个单元实现。在本申请的其它实施例中，视频数据处理装置也可以包括其它单元，在实际应用中，这些功能也可以由其它单元协助实现，并且可以由多个单元协作实现。
在本申请实施例中提供了一种通用的跨链通信架构，跨链通信架构制定了跨链通信协议，该跨链通信协议中包括与多个区块链分别适配的数据封装格式，以及区块链对应的节点设备加入跨链通信的准入条件(即风控规则)等等，该跨链通信架构包括用于实现跨链通信的预言机服务器以及中继服务器。当第一区块链与第二区块链之间进行跨链通信时，第一区块链对应的第一节点设备和第二区块链对应的第二节点设备均满足该跨链通信协议，即第一节点设备和第二节点设备均满足该跨链通信协议中的跨链通信的准入条件，这样有利于确保实现跨链通信的安全性。具体实现过程中，第一节点设备可以从第一区块链上的跨链通信协议中，选择与第二区块链适配的数据封装格式，对该第一区块链上的目标区块中的目标交易数据和该目标交易数据的交易验证信息进行封装，得到目标数据包，根据与该第二区块链适配的消息封装格式对该目标区块的区块头进行封装，得到封装区块头。这样有利于第二节点设备能够成功对目标数据包以及封装区块头进行解析，实现第一节点设备与第二节点设备之间的互联互通，即实现第一区块链与第二区块链之间的互联互通，也即实现跨链通信。
进一步，第一节点设备可以将该目标数据包和封装区块头分两路独立发送，即将该目标数据包发送至该跨链通信架构中与第二节点设备关联的目标中继服务器，将该封装区块头发送至该跨链通信架构中与第二节点设备关联的目标预言机服务器，由中继服务器将目标数据包发送至第二节点设备，并由目标预言机服务器将封装区块头发送至第二节点设备。目标中继服务器与目标预言机服务器均为区块链之外的独立实体，这样，通过两个区块链之外的独立实体分别转发目标数据包和封装区块头，可以避免单点转发被攻击的风险，提 高跨链通信的安全性。换句话说，只要目标预言机服务器和目标中继服务器的独立性条件没有被破坏，就可以保证任意跨链数据的无信任有效传递，提高跨链数据传输的安全性。同时，第一节点设备将与第二节点设备相关联的目标交易数据等数据同步至第二节点设备，不需要将第一区块链上的所有数据同步至第二节点设备，以降低数据传输成本，大大节约链上的存储成本和存储费用。在第二节点设备获取到目标数据包以及封装区块头后，第二节点设备在根据第二区块链上的数据验证规则、封装区块头和目标数据包中的交易验证信息对目标交易数据验证通过时，才对目标数据包中的目标交易数据进行处理，实现目标交易数据的链上验证，避免目标交易数据被篡改，提高目标交易数据的安全性，提高跨链通信的安全性和效率。同时，根据第二区块链上的数据验证规则、封装区块头和目标数据包中的交易验证信息对目标交易数据验证，在确实需要时才消耗链上存储，大大节约链上存储成本和费用。其中，对目标交易数据进行处理，可以是按照业务逻辑对目标交易数据进行的正常业务处理。
进一步地，请参见图11，图11是本申请实施例提供的一种区块链数据处理装置的结构示意图。该区块链数据处理装置2可以是运行于计算机设备中的一个计算机可读指令(包括程序代码)，例如，该区块链数据处理装置2为一个应用软件；该区块链数据处理装置2可以用于执行本申请实施例提供的方法中的相应步骤。如图11所示，该区块链数据处理装置2可以为维护第二区块链的第二节点设备。该区块链数据处理装置2可以包括：解析模块21、数据验证模块22以及交易处理模块23。
解析模块21，用于当接收到目标中继服务器向第二节点设备发送的目标数据包，以及接收到目标预言机服务器向第二节点设备发送的封装区块头，则解析目标数据包，得到目标数据包中的目标交易数据和目标交易数据的交易验证信息；目标数据包是由维护第一区块链的第一节点设备向目标中继服务器发送的，封装区块头是由第一节点设备向目标预言机服务器发送的，目标数据包是基于与第二节点设备维护的第二区块链适配的消息封装格式，对目标交易数据以及目标交易数据的交易验证信息进行封装得到的，目标交易数据为第一区块链的目标区块中的交易数据，封装区块头是基于消息封装格式对目标区块的区块头进行封装得到的；消息封装格式是从第一区块链上的跨链通信协议中选择得到的，第一节点设备和第二节点设备依照跨链通信协议通信；
数据验证模块22，用于按照第二区块链上的数据验证规则，根据封装区块头和交易验证信息对目标交易数据进行验证，得到验证结果，数据验证规则与跨链通信协议相关联；
交易处理模块23，用于当验证结果指示目标交易数据验证通过，则处理目标数据包中的目标交易数据。
其中，第二区块链上包括基于跨链通信协议生成的子账本智能合约，交易验证信息包括与目标区块关联的默克尔路径，第二区块链上的数据验证规则包括关于默克尔路径的验证规则；
数据验证模块22包括：哈希运算单元2201，用于调用第二区块链上的子账本智能合约，对目标交易数据进行哈希算法，得到待验证哈希值，根据默克尔路径对待验证哈希值进行哈希运算，得到待验证树根哈希值；第三获取单元2202，用于从封装区块头中获取默克尔树根哈希值；生成单元2203，用于获取默克尔树根哈希值与待验证树根哈希值的一致性检验结果，根据一致性检验结果，生成用于指示目标交易数据是否通过验证的验证结果。
生成单元2203包括：第一生成单元22031，用于若一致性检验结果表征封装区块头中的默克尔树根哈希值与待验证树根哈希值相同，则生成用于指示目标交易数据验证通过的验证结果；第二生成单元22032，用于若一致性检验结果表征封装区块头中的默克尔树根哈希值与待验证树根哈希值不相同，则生成用于指示目标交易数据验证未通过的验证结果。
其中，第二区块链上包括基于跨链通信协议生成的子账本智能合约，交易验证信息包括目标区块的父区块的目标父区块哈希值，第二区块链上的数据验证规则包括关于目标父区块哈希值的验证规则；
数据验证模块22包括：第四获取单元2205，用于调用第二区块链上的子账本智能合约，从封装区块头中获取目标区块的父区块的区块哈希值，作为待验证父区块哈希值；生成模块2206，用于获取待验证父区块哈希值和目标父区块哈希值的一致性检验结果，根据一致性检验结果，生成用于指示目标交易数据是否通过验证的验证结果。
生成模块2206包括：第三生成单元22061，用于若一致性检验结果表征待验证父区块哈希值和目标父区块哈希值相同，则生成用于指示目标交易数据验证通过的验证结果；
第四生成单元2207，用于若一致性检验结果表征待验证父区块哈希值和目标父区块哈希值不相同，则生成用于指示目标交易数据验证未通过的验证结果。
根据本申请的一个实施例，图11示的区块链数据处理装置2中的各个模块可以分别或全部合并为一个或若干个单元来构成，或者其中的某个(些)单元还可以再拆分为功能上更小的多个子单元，可以实现同样的操作，而不影响本申请的实施例的技术效果的实现。上述模块是基于逻辑功能划分的，在实际应用中，一个模块的功能也可以由多个单元来实现，或者多个模块的功能由一个单元实现。在本申请的其它实施例中，视频数据处理装置也可以包括其它单元，在实际应用中，这些功能也可以由其它单元协助实现，并且可以由多个单元协作实现。
在本申请实施例中提供了一种通用的跨链通信架构，跨链通信架构制定了跨链通信协议，该跨链通信协议中包括与多个区块链分别适配的数据封装格式，以及区块链对应的节点设备加入跨链通信的准入条件(即风控规则)等等，该跨链通信架构包括用于实现跨链通信的预言机服务器以及中继服务器。当第一区块链与第二区块链之间进行跨链通信时，第一区块链对应的第一节点设备和第二区块链对应的第二节点设备均满足该跨链通信协议，即第一节点设备和第二节点设备均满足该跨链通信协议中的跨链通信的准入条件，这样有利于确保实现跨链通信的安全性。具体实现过程中，第一节点设备可以从第一区块链上的跨链通信协议中，选择与第二区块链适配的数据封装格式，对该第一区块链上的目标区块中的目标交易数据和该目标交易数据的交易验证信息进行封装，得到目标数据包，根据与该第二区块链适配的消息封装格式对该目标区块的区块头进行封装，得到封装区块头。这样有利于第二节点设备能够成功对目标数据包以及封装区块头进行解析，实现第一节点设备与第二节点设备之间的互联互通，即实现第一区块链与第二区块链之间的互联互通，也即实现跨链通信。
进一步，第一节点设备可以将该目标数据包和封装区块头分两路独立发送，即将该目标数据包发送至该跨链通信架构中与第二节点设备关联的目标中继服务器，将该封装区块头发送至该跨链通信架构中与第二节点设备关联的目标预言机服务器，由中继服务器将目标数据包发送至第二节点设备，并由目标预言机服务器将封装区块头发送至第二节点设备。目标中继服务器与目标预言机服务器均为区块链之外的独立实体，这样，通过两个区块链之外的独立实体分别转发目标数据包和封装区块头，可以避免单点转发被攻击的风险，提高跨链通信的安全性。换句话说，只要目标预言机服务器和目标中继服务器的独立性条件没有被破坏，就可以保证任意跨链数据的无信任有效传递，提高跨链数据传输的安全性。同时，第一节点设备将与第二节点设备相关联的目标交易数据等数据同步至第二节点设备，不需要将第一区块链上的所有数据同步至第二节点设备，以降低数据传输成本，大大节约链上的存储成本和存储费用。在第二节点设备获取到目标数据包以及封装区块头后，第二节点设备在根据第二区块链上的数据验证规则、封装区块头和目标数据包中的交易验证信息对目标交易数据验证通过时，才对目标数据包中的目标交易数据进行处理，实现目标交易数据的链上验证，避免目标交易数据被篡改，提高目标交易数据的安全性，提高跨链通信的安全性和效率。同时，根据第二区块链上的数据验证规则、封装区块头和目标数据包中的交易验证信息对目标交易数据验证，在确实需要时才消耗链上存储，大大节约链上存储成本和费用。
进一步地，请参见图12，图12是本申请实施例提供的一种计算机设备的示意图。如 图12所示，该计算机设备3000可以为上述图3对应实施例中的共识节点220A，该计算机设备3000可以包括：至少一个处理器3001，例如CPU，至少一个网络接口3004，用户接口3003，存储器3005，至少一个通信总线3002。其中，通信总线3002用于实现这些组件之间的连接通信。其中，用户接口3003可以包括显示屏(Display)、键盘(Keyboard)，网络接口3004可选地可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器3005可以是高速RAM存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储3005可选地还可以是至少一个位于远离前述处理器3001的存储装置。如图12所示，作为一种计算机存储介质的存储器3005可以包括操作系统、网络通信模块、用户接口模块以及设备控制应用程序。
在图12所示的计算机设备3000中，网络接口3004主要用于第二节点设备与目标中继服务器以及目标预言机服务器进行网络通信；而用户接口3003主要用于为用户提供输入的接口；而处理器3001可以用于调用存储器3005中存储的设备控制应用程序。
应当理解，本申请实施例中所描述的计算机设备3000可执行前文图6或者图8所对应实施例中对该区块链数据处理方法的描述，也可执行前文图10所对应实施例中对该区块链数据处理装置1或者图11所对应实施例中对该区块链数据处理装置2的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
此外，这里需要指出的是：本申请实施例还提供了一种计算机可读存储介质，且该计算机可读存储介质中存储有前文提及的区块链数据处理装置1或者区块链数据处理装置2所执行的计算机可读指令，且该计算机可读指令包括程序指令，当该处理器执行该程序指令时，能够执行前文图6或者图8所对应实施例中对该区块链数据处理方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机可读存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述。作为示例，程序指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行，分布在多个地点且通过通信网络互连的多个计算设备可以组成区块链系统。
本申请一方面提供了一种计算机程序产品或计算机可读指令，该计算机程序产品或计算机可读指令包括计算机可读指令，该计算机可读指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机可读指令，处理器执行该计算机可读指令，使得该计算机设备可执行前文图6或者图8所对应实施例中对区块链数据处理方法的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机可读指令来指令相关的硬件来完成，上述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，上述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。
以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (20)

  1. 一种区块链数据处理方法，由区块链网络中维护第一区块链的第一节点设备执行，包括：
    从第一区块链上的跨链通信协议中，选择与第二区块链适配的消息封装格式，所述第二区块链由所述区块链网络中第二节点设备维护，所述第一节点设备和所述第二节点设备依照所述跨链通信协议通信；
    确定与所述第二节点设备相关联的目标交易数据所在的目标区块，使用与所述第二区块链适配的消息封装格式，对所述第一区块链上的目标区块中的目标交易数据和所述目标交易数据的交易验证信息进行封装，得到目标数据包，使用与所述第二区块链适配的消息封装格式对所述目标区块的区块头进行封装，得到封装区块头；及
    向与所述第二节点设备关联的目标中继服务器发送所述目标数据包，向与所述第二节点设备关联的目标预言机服务器发送所述封装区块头，所述目标中继服务器用于向所述第二节点设备发送所述目标数据包，所述目标预言机服务器用于向所述第二节点设备发送所述封装区块头，所述第二节点设备用于在根据所述第二区块链上的数据验证规则、所述封装区块头和所述目标数据包中的交易验证信息对所述目标交易数据验证通过时，处理所述目标数据包中的目标交易数据，所述数据验证规则与所述跨链通信协议相关联。
  2. 根据权利要求1所述的方法，所述根据与所述第二区块链适配的消息封装格式，对所述第一区块链上的目标区块中的目标交易数据和所述目标交易数据的交易验证信息进行封装，得到目标数据包，根据与所述第二区块链适配的消息封装格式对所述目标区块的区块头进行封装，得到封装区块头，包括：
    从所述目标区块的区块体中获取所述目标交易数据，根据与所述第二区块链适配的消息封装格式中的交易数据封装格式，对所述目标交易数据进行封装，得到封装后的目标交易数据；
    从所述目标区块的区块头中获取所述目标交易数据的交易验证信息，根据与所述第二区块链适配的消息封装格式中的交易验证封装格式，对所述交易验证信息进行封装，得到封装后的交易验证信息；
    对所述封装后的目标交易数据以及所述封装后的交易验证信息进行组合，得到所述目标数据包；
    根据与所述第二区块链适配的消息封装格式中的区块头封装格式，对所述目标区块的区块头进行封装，得到所述封装区块头。
  3. 根据权利要求1或2所述的方法，所述第一区块链包括基于所述跨链通信协议生成的子账本智能合约；
    所述从第一区块链上的跨链通信协议中，选择与第二区块链适配的消息封装格式，包括：
    获取所述第二区块链的区块链标识；
    从所述第一区块链上的子账本智能合约中获取适配库集合，根据所述第二区块链的区块链标识，从所述适配库集合中，确定与所述第二区块链相关联的目标适配库；
    从所述目标适配库中，获取与所述第二节点设备对应的第二区块链适配的消息封装格式。
  4. 根据权利要求3所述的方法，还包括：
    当接收到第三区块链对应的第三节点设备发送的跨链通信请求，则根据所述跨链通信协议中的风控规则和所述跨链通信请求，对所述第三节点设备的有效性进行验证，获得有效性验证结果；
    当所述有效性验证结果表征所述第三节点设备具有有效性，则获取与所述第三区块链适配的消息封装格式；
    根据与所述第三区块链适配的消息封装格式生成与所述第三区块链关联的适配库；
    将与所述第三区块链关联的适配库，添加至所述第一区块链上的子账本智能合约包括的适配库集合中。
  5. 根据权利要求3或4所述的方法，所述向与所述第二节点设备关联的目标中继服务器发送所述目标数据包，包括：
    从候选中继服务器集合中确定与所述第二节点设备关联的候选中继服务器；
    从与所述第二节点设备关联的候选中继服务器中确定所述目标中继服务器；
    获取所述目标中继服务器的第一接口协议，调用所述第一区块链上的子账本智能合约，根据所述目标中继服务器的第一接口协议，将所述目标数据包发送给所述目标中继服务器。
  6. 根据权利要求5所述的方法，所述调用所述第一区块链上的子账本智能合约，根据所述目标中继服务器的第一接口协议，将所述目标数据包发送给所述目标中继服务器，包括：
    调用所述第一区块链上的子账本智能合约，获取所述第一接口协议中的第一数据通信方式和第一通信数据格式；
    根据所述第一通信数据格式，生成携带所述目标数据包以及所述第二区块链的区块链标识的第一数据转发请求；
    通过所述第一数据通信方式，将所述第一数据转发请求发送给所述目标中继服务器，所述目标中继服务器用于获取所述第一数据转发请求中携带的所述第二区块链的区块链标识，根据所述第二区块链的区块链标识，将所述目标数据包转发给维护所述第二区块链的第二节点设备。
  7. 根据权利要求5或6所述的方法，所述从与所述第二节点设备关联的候选中继服务器中确定所述目标中继服务器，包括：
    当与所述第二节点设备关联的候选中继服务器的数量为一个，则将与所述第二节点设备关联的候选中继服务器确定为所述目标中继服务器。
  8. 根据权利要求5或6所述的方法，所述从与所述第二节点设备关联的候选中继服务器中确定所述目标中继服务器，包括：
    当与所述第二节点设备关联的候选中继服务器的数量为至少两个，则获取至少两个候选中继服务器分别对应的信用度，将所述至少两个候选中继服务器中具有最大信用度的候选中继服务器，确定为所述目标中继服务器。
  9. 根据权利要求3至8任一项所述的方法，所述向与所述第二节点设备关联的目标预言机服务器发送所述封装区块头，包括：
    从候选预言机服务器集合中确定与所述第二节点设备关联的候选预言机服务器；
    根据与所述第二节点设备关联的候选预言机服务器确定所述目标预言机服务器；
    获取所述目标预言机服务器的第二接口协议，调用所述第一区块链上的子账本智能合约，根据所述目标预言机服务器的第二接口协议，将所述封装区块头发送给所述目标预言机服务器。
  10. 根据权利要求9所述的方法，所述调用所述第一区块链上的子账本智能合约，根据所述目标预言机服务器的第二接口协议，将所述封装区块头发送给所述目标预言机服务器，包括：
    调用所述第一区块链上的子账本智能合约，获取所述第二接口协议的第二数据通信方式和第二通信数据格式；
    根据所述第二通信数据格式，生成携带所述封装区块头以及所述第二区块链的区块链标识的第二数据转发请求；
    通过所述第二数据通信方式，将所述第二数据转发请求发送给所述目标预言机服务器；所述目标预言机服务器用于根据所述第二数据转发请求中携带的所述第二区块链的区块链标识，将所述封装区块头转发给维护所述第二区块链的第二节点设备。
  11. 根据权利要求1至10任一项所述的方法，所述目标预言机服务器用于在区块数量大于目标数量阈值时，将所述封装区块头发送给所述第二节点设备；所述区块数量为所述第一区块链上生成时间戳晚于所述目标区块的生成时间戳的区块对应的数量。
  12. 根据权利要求1至11任一项所述的方法，所述目标中继服务器用于在根据所述第一区块链上的目标区块的区块头确定所述目标数据包中的目标交易数据验证通过时，将所述目标数据包发送给所述第二节点设备。
  13. 一种区块链数据处理方法，由区块链网络中维护第二区块链的第二节点设备执行，包括：
    当接收到目标中继服务器发送的目标数据包，以及接收到目标预言机服务器发送的封装区块头，则解析所述目标数据包，得到所述目标数据包中的目标交易数据和所述目标交易数据的交易验证信息；所述目标数据包是由维护所述第一区块链的第一节点设备向所述目标中继服务器发送的，所述封装区块头是由所述第一节点设备向所述目标预言机服务器发送的，所述目标数据包是基于与所述第二节点设备维护的第二区块链适配的消息封装格式，对所述目标交易数据以及所述目标交易数据的交易验证信息进行封装得到的，所述目标交易数据为第一区块链的目标区块中的交易数据，所述封装区块头是基于所述消息封装格式对所述目标区块的区块头进行封装得到的；所述消息封装格式是从所述第一区块链上的跨链通信协议中选择得到的，所述第一节点设备和所述第二节点设备依照所述跨链通信协议通信；
    按照所述第二区块链上的数据验证规则，根据所述封装区块头和所述交易验证信息对所述目标交易数据进行验证，得到验证结果，所述数据验证规则与所述跨链通信协议相关联；及
    当所述验证结果指示所述目标交易数据验证通过，则处理所述目标数据包中的目标交易数据。
  14. 根据权利要求13所述的方法，所述第二区块链包括基于所述跨链通信协议生成的子账本智能合约，所述交易验证信息包括与所述目标区块关联的默克尔路径，所述第二区块链上的数据验证规则包括关于所述默克尔路径的验证规则；
    所述按照所述第二区块链上的数据验证规则，根据所述封装区块头和所述交易验证信息对所述目标交易数据进行验证，得到验证结果，包括：
    调用所述第二区块链上的子账本智能合约，对所述目标交易数据进行哈希算法，得到待验证哈希值，根据所述默克尔路径对所述待验证哈希值进行哈希运算，得到待验证树根哈希值；
    从所述封装区块头中获取默克尔树根哈希值；
    获取所述默克尔树根哈希值与所述待验证树根哈希值的一致性检验结果，根据所述一致性检验结果，生成用于指示所述目标交易数据是否通过验证的验证结果。
  15. 根据权利要求13所述的方法，所述第二区块链上包括基于所述跨链通信协议生成的子账本智能合约，所述交易验证信息包括所述目标区块的父区块的目标父区块哈希值，所述第二区块链上的数据验证规则包括关于所述目标父区块哈希值的验证规则；
    所述按照所述第二区块链上的数据验证规则，根据所述封装区块头和所述交易验证信息对所述目标交易数据进行验证，得到验证结果，包括：
    调用所述第二区块链上的子账本智能合约，从所述封装区块头中获取所述目标区块的父区块的区块哈希值，作为待验证父区块哈希值；
    获取所述待验证父区块哈希值和所述目标父区块哈希值的一致性检验结果，根据所述一致性检验结果，生成用于指示所述目标交易数据是否通过验证的验证结果。
  16. 一种区块链数据处理装置，包括：
    选择模块，用于从第一区块链上的跨链通信协议中，选择与第二区块链适配的消息封装格式，所述第一区块链由区块链网络中第一节点设备维护，所述第二区块链由所述区块 链网络中第二节点设备维护，所述第一节点设备和所述第二节点设备依照所述跨链通信协议通信；
    封装模块，用于确定与所述第二节点设备相关联的目标交易数据所在的目标区块，根据与所述第二区块链适配的消息封装格式，对所述第一区块链上的目标区块中的目标交易数据和所述目标交易数据的交易验证信息进行封装，得到目标数据包，根据与所述第二区块链适配的消息封装格式对所述目标区块的区块头进行封装，得到封装区块头；及
    发送模块，用于向与所述第二节点设备关联的目标中继服务器发生所述目标数据包，向与所述第二节点设备关联的目标预言机服务器发送所述封装区块头，所述目标中继服务器用于向所述第二节点设备发送所述目标数据包，所述目标预言机服务器用于向所述第二节点设备发送所述封装区块头，所述第二节点设备用于在根据所述第二区块链上的数据验证规则、所述封装区块头和所述目标数据包中的交易验证信息对所述目标交易数据验证通过时，处理所述目标数据包中的目标交易数据，所述数据验证规则与所述跨链通信协议相关联向与所述第二节点设备关联的目标中继服务器发送所述目标数据包。
  17. 一种区块链数据处理装置，包括：
    解析模块，用于当接收到目标中继服务器向第二节点设备发送的目标数据包，以及接收到目标预言机服务器向第二节点设备发送的封装区块头，则解析所述目标数据包，得到所述目标数据包中的目标交易数据和所述目标交易数据的交易验证信息；所述目标数据包是由维护第一区块链的第一节点设备向所述目标中继服务器发送的，所述封装区块头是由所述第一节点设备向所述目标预言机服务器发送的，所述目标数据包是基于与所述第二节点设备维护的第二区块链适配的消息封装格式，对所述目标交易数据以及所述目标交易数据的交易验证信息进行封装得到的，所述目标交易数据为所述第一区块链的目标区块中的交易数据，所述封装区块头是基于所述消息封装格式对所述目标区块的区块头进行封装得到的；所述消息封装格式是从所述第一区块链上的跨链通信协议中选择得到的，所述第一节点设备和所述第二节点设备依照所述跨链通信协议通信；
    数据验证模块，用于按照所述第二区块链上的数据验证规则，根据所述封装区块头和所述交易验证信息对所述目标交易数据进行验证，得到验证结果，所述数据验证规则与所述跨链通信协议相关联；
    交易处理模块，用于当所述验证结果指示所述目标交易数据验证通过，则处理所述目标数据包中的目标交易数据。
  18. 一种计算机设备，包括：处理器和存储器，所述存储器存储有计算机可读指令，所述处理器用于执行所述计算机可读指令，以使得所述计算机设备执行权利要求1-15任一项所述的方法。
  19. 一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机可读指令，所述计算机可读指令由处理器加载并执行，以使得所述处理器执行权利要求1-15任一项所述的方法。
  20. 一种计算机程序产品，包括计算机可读指令，所述计算机可读指令存储在计算机可读存储介质中，所述计算机可读指令由处理器读取并执行，以使得所述处理器执行权利要求1-15任一项所述的方法。
PCT/CN2023/124925 2023-02-10 2023-10-17 区块链数据处理方法、装置、设备及存储介质 Ceased WO2024164550A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP23920742.6A EP4560981A4 (en) 2023-02-10 2023-10-17 BLOCKCHAIN DATA PROCESSING METHOD AND APPARATUS, STORAGE DEVICE AND MEDIA
US19/051,589 US20250184316A1 (en) 2023-02-10 2025-02-12 Blockchain data processing method and apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202310144103.4 2023-02-10
CN202310144103.4A CN116980169A (zh) 2023-02-10 2023-02-10 区块链数据处理方法、装置、设备及存储介质

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US19/051,589 Continuation US20250184316A1 (en) 2023-02-10 2025-02-12 Blockchain data processing method and apparatus

Publications (1)

Publication Number Publication Date
WO2024164550A1 true WO2024164550A1 (zh) 2024-08-15

Family

ID=88473800

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/124925 Ceased WO2024164550A1 (zh) 2023-02-10 2023-10-17 区块链数据处理方法、装置、设备及存储介质

Country Status (4)

Country Link
US (1) US20250184316A1 (zh)
EP (1) EP4560981A4 (zh)
CN (1) CN116980169A (zh)
WO (1) WO2024164550A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN119070971A (zh) * 2024-10-31 2024-12-03 湖南大学 一种多链式联盟区块链共识方法、装置、电子设备及介质
CN119232350A (zh) * 2024-10-09 2024-12-31 中国移动通信有限公司研究院 一种区块链处理方法、装置、设备存储介质及程序产品

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111416808A (zh) * 2020-03-13 2020-07-14 财付通支付科技有限公司 跨区块链的数据互存方法、装置、设备及存储介质
WO2020258849A1 (zh) * 2019-06-28 2020-12-30 创新先进技术有限公司 一种跨链发送可认证消息的方法和装置
WO2021179655A1 (zh) * 2020-03-13 2021-09-16 腾讯科技（深圳）有限公司 跨区块链的数据迁移方法、装置、设备及存储介质
WO2022095244A1 (zh) * 2020-11-06 2022-05-12 杭州趣链科技有限公司 跨链交易方法、系统、装置、设备和存储介质
WO2022205958A1 (zh) * 2021-03-30 2022-10-06 蚂蚁区块链科技(上海)有限公司 一种基于中继设备网络跨链中转数据的方法和装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113597608B (zh) * 2020-11-25 2024-09-10 支付宝(杭州)信息技术有限公司 基于区块链的可信平台
CN112887380B (zh) * 2021-01-15 2022-06-10 杭州链网科技有限公司 一种跨链互通方法及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020258849A1 (zh) * 2019-06-28 2020-12-30 创新先进技术有限公司 一种跨链发送可认证消息的方法和装置
CN111416808A (zh) * 2020-03-13 2020-07-14 财付通支付科技有限公司 跨区块链的数据互存方法、装置、设备及存储介质
WO2021179655A1 (zh) * 2020-03-13 2021-09-16 腾讯科技（深圳）有限公司 跨区块链的数据迁移方法、装置、设备及存储介质
WO2022095244A1 (zh) * 2020-11-06 2022-05-12 杭州趣链科技有限公司 跨链交易方法、系统、装置、设备和存储介质
WO2022205958A1 (zh) * 2021-03-30 2022-10-06 蚂蚁区块链科技(上海)有限公司 一种基于中继设备网络跨链中转数据的方法和装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4560981A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN119232350A (zh) * 2024-10-09 2024-12-31 中国移动通信有限公司研究院 一种区块链处理方法、装置、设备存储介质及程序产品
CN119070971A (zh) * 2024-10-31 2024-12-03 湖南大学 一种多链式联盟区块链共识方法、装置、电子设备及介质

Also Published As

Publication number Publication date
US20250184316A1 (en) 2025-06-05
CN116980169A (zh) 2023-10-31
EP4560981A1 (en) 2025-05-28
EP4560981A4 (en) 2025-12-31

Similar Documents

Publication Publication Date Title
CN112232823B (zh) 区块链系统的交易处理方法、装置、介质及电子设备
US20220318907A1 (en) Systems and methods for generating secure, encrypted communications across distributed computer networks for authorizing use of cryptography-based digital repositories in order to perform blockchain operations in decentralized applications
US20230316273A1 (en) Data processing method and apparatus, computer device, and storage medium
CN112291376B (zh) 区块链系统中的数据处理方法及相关设备
CN112235420B (zh) 基于区块链的数据同步方法、系统及相关设备
CN113255014B (zh) 一种基于区块链的数据处理方法以及相关设备
CN111027970B (zh) 区块链系统的认证管理方法、装置、介质及电子设备
CN112733174A (zh) 区块链系统的认证管理方法、系统及电子设备
CN109245894B (zh) 一种基于智能合约的分布式云存储系统
CN112231741B (zh) 基于区块链系统的数据处理方法、装置、介质及电子设备
US20250184316A1 (en) Blockchain data processing method and apparatus
WO2024244249A1 (zh) 基于区块链的数据处理方法、装置、设备以及介质
US12549393B2 (en) Consensus result synchronization across algorithms of different fault tolerance types
WO2023221350A1 (zh) 基于区块链的代码版权登记系统、方法及平台
CN116186749A (zh) 基于区块链的业务处理方法、装置、电子设备和可读介质
CN116137627A (zh) 一种基于区块链网络的数据处理方法、装置及相关设备
CN119067657A (zh) 基于区块链的数据处理方法、装置、设备及存储介质
HK40098085A (zh) 区块链数据处理方法、装置、设备及存储介质
CN116155501A (zh) 区块链网络中的跨链通信方法、装置、设备以及介质
CN116186786A (zh) 基于区块链的业务处理方法、装置、电子设备和可读介质
EP4607849A1 (en) Hierarchical chain-based data processing method, apparatus, device, and medium
HK40093141B (zh) 基於多区块链的信息处理方法、装置、设备以及介质
HK40093141A (zh) 基於多区块链的信息处理方法、装置、设备以及介质
HK40050031A (zh) 一种基於区块链的数据处理方法以及相关设备
HK40050031B (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: 23920742

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023920742

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2023920742

Country of ref document: EP

Effective date: 20250221

WWP Wipo information: published in national office

Ref document number: 2023920742

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE