Electronic equipment, data processing method thereof, data processing system and medium

Abstract

The invention relates to the field of block chains, and relates to electronic equipment, a data processing method thereof, a data processing system and a medium. The method comprises the following steps: establishing a binding relationship between a first block chain and a second block chain; a first subscription request for first data sent by the first block chain to a second block chain is received, and the first data is stored on the second block chain; based on the first subscription request, first data is stored in the first block chain, and a first attribute of the first data comprises first sub-information; and in response to updating the first attribute of the first data from the first sub-information to the second sub-information, updating the first sub-information in the first block chain based on the second sub-information. Cross-chain on-demand deployment can be realized between the first block chain and the second block chain which are independently deployed in different servers through the cross-chain node; the first block chain serving as the local block chain can calculate own data and also can cooperatively calculate information of data corresponding to the second block chain serving as the external block chain.

Description

Technical Field

[0001] The embodiments of the present application relate to the technical field of blockchain. In particular, it relates to an electronic device, a data processing method, a data processing system, and a medium thereof. Background Art

[0002] With the application and development of blockchain technology, more and more enterprises realize product data management (Product Data Management, PDM) through blockchain. For example, taking a product with parts as an example, in the Bill of Material (BOM) scenario corresponding to product data management, the parts required by the purchaser are purchased from the supplier, and the information related to the purchased parts can be stored in the purchaser's blockchain, and the information related to the supplied parts can be stored in the supplier's blockchain.

[0003] In the above scenario, since different manufacturers can build their own blockchain infrastructures, some manufacturers may not transfer the data to the blockchains built by other manufacturers. Therefore, all manufacturers need to use a single blockchain (a large unified public blockchain), and each manufacturer can build a set of blockchains based on the public blockchain in the business scenario to ensure the non-disclosure of the manufacturer's data. However, if a new supplier is added, the supplier needs to deploy a blockchain node; if the supplier cooperates with multiple host manufacturers, the supplier needs to deploy multiple blockchain nodes of multiple host manufacturers, and thus the cost of the supplier will increase linearly. Summary of the Invention

[0004] The present application provides an electronic device, a data processing method, a data processing system, and a medium thereof.

[0005] In a first aspect, the present application provides a data processing method, and the method includes:

[0006] Establish a binding relationship between a first blockchain and a second blockchain; receive a first subscription request sent by the first blockchain to the second blockchain for first data, where the first data is stored on the second blockchain; based on the first subscription request, save the first data on the first blockchain, where the first attribute of the first data includes first sub-information; in response to updating the first attribute of the first data from the first sub-information to the second sub-information, update the first sub-information on the first blockchain based on the second sub-information.

[0007] In this specification, the first blockchain and the second blockchain here can be blockchains corresponding to business systems / applications of different users / enterprises. For example, blockchains corresponding to enterprise resource systems or part machining systems. The first blockchain and the second blockchain can be respectively deployed on the servers of the users / enterprises. A binding relationship can be established between the first blockchain and the second blockchain through cross-chain nodes. This binding relationship can also be called a blockchain binding relationship. Different functional business smart contracts can be deployed between the first blockchain and the second blockchain through the binding relationship for processing data on the first blockchain or the second blockchain. The first data here can be data stored on the second blockchain, such as purchased parts. The first attribute can be used to describe the first data, such as carbon emissions. The first sub-information and the second sub-information can be attribute values of the first attribute, such as carbon emissions. The first subscription request can be a cross-chain subscription request for the first data. When the first data is saved on the first blockchain and updated on the second blockchain, the first blockchain can update the first data simultaneously, that is, the first blockchain and the second blockchain maintain synchronization of the first data.

[0008] It can be seen that through the above data processing method, cross-chain on-demand deployment can be achieved between the first blockchain and the second blockchain separately deployed on different servers through cross-chain nodes; when performing cross-chain collaborative calculations for data saved on the blockchain (such as bill of materials), as the local blockchain, the first blockchain can not only calculate its own data, but also collaboratively calculate the information of the data corresponding to the second blockchain (the blockchain bound through inter-chain access) as an external blockchain. That is to say, traceable cross-chain collaborative calculations for data between multiple blockchains can be realized.

[0009] In a possible implementation of the first aspect above, establishing the binding relationship between the first blockchain and the second blockchain further includes: receiving the first registration request and the second registration request of the first blockchain and the second blockchain, where the first registration request and the second registration request respectively carry the first identification information of the first blockchain and the second identification information of the second blockchain; recording the first identification information and the second identification information; in response to the first registration request and the second registration request, deploying the first cross-chain smart contract and the second cross-chain smart contract to the first blockchain and the second blockchain respectively, where the first cross-chain smart contract and the second cross-chain smart contract respectively correspond to the first identification information and the second identification information, and the first cross-chain smart contract and the second cross-chain smart contract are used to initiate a blockchain binding request between the first blockchain and the second blockchain.

[0010] In this specification, the first registration request and the second registration request here can be registration requests sent by the first blockchain and the second blockchain to the cross-chain node respectively for cross-chain access. The first registration request and the second registration request can carry the first identification information and the second identification information respectively, such as: the protocol and version of the blockchain. The cross-chain smart contract here can be used to operate on multiple different blockchains to achieve interaction and communication between different blockchains. For example, the cross-chain smart contract can support establishing a link relationship between different blockchains and triggering the installation of different business smart contracts. The first blockchain and the second blockchain can each install a cross-chain smart contract corresponding to the first identification information and the second identification information. A blockchain binding request can be initiated between the first blockchain and the second blockchain through the cross-chain smart contract. The blockchain binding request here is used to establish a binding relationship at the chain level between the first blockchain and the second blockchain.

[0011] It can be seen that after establishing a blockchain binding relationship (blockchain binding relationship) between the first blockchain and the second blockchain, business smart contract deployments with different functions can be carried out. The business smart contracts here can include different smart contracts corresponding to different business functions. For example, the convolutional computing smart contract is used to perform traceable convolutional computing on the corresponding blockchain.

[0012] In a possible implementation of the first aspect above, it further includes: receiving a first binding request from the first blockchain, where the first binding request is sent through the first cross-chain smart contract and the first binding request carries the first identification information and the second identification information; in response to the first binding request, recording the first identification information of the first blockchain in the second blockchain and returning a first binding result to the first blockchain; in response to the first binding result, recording the second identification information of the second blockchain in the first blockchain.

[0013] In this specification, the cross-chain node here can receive the first binding request from the first blockchain. The first binding request carries the first identification information of the first blockchain and the second identification information of the second blockchain to be bound. The cross-chain node can forward the first binding request to the second blockchain. The second blockchain determines to establish a binding relationship with the first blockchain by recording the corresponding relationship between the first identification information and the second identification information.

[0014] It can be seen that the binding relationship between the first blockchain and the second blockchain can be established through the cross-chain node. Even if the first blockchain and the second blockchain are deployed on different servers, after the first blockchain and the second blockchain complete the registration of the cross-chain node, they can establish a binding relationship with any other blockchain registered in the cross-chain node through the cross-chain smart contract.

[0015] In a possible implementation of the above first aspect, it further includes: deploying a first business smart contract and a second business smart contract to the first blockchain and the second blockchain respectively, where the first business smart contract and the second business smart contract correspond to the first identification information and the second identification information respectively, and the first business smart contract and the second business smart contract are used to initiate a subscription request between the first blockchain and the second blockchain.

[0016] It can be seen that the business smart contracts here can include different smart contracts corresponding to different business functions. The first blockchain and the second blockchain deployed on different servers can subscribe to data through the business smart contracts. Furthermore, data synchronization between the first blockchain and the second blockchain is achieved.

[0017] In a possible implementation of the above first aspect, receiving a first subscription request sent by the first blockchain to the second blockchain for the first data includes:

[0018] The first subscription request is sent through the first business smart contract, and the first subscription request carries the first identification information and the first data identification information of the first data; after determining that a binding relationship is established between the second blockchain and the first blockchain, based on the first identification information and the first data identification information, record the first subscription relationship between the first data and the first blockchain in the second blockchain, and based on the second identification information and the first data identification information, record the second subscription relationship between the first data and the second blockchain in the first blockchain.

[0019] It can be seen that the first subscription request here can be a cross-chain binding transaction request, which can be used to subscribe to the second blockchain to record the first data. The first identification information here can include the smart contract type of the first business smart contract of the first blockchain, the first data identification information can include component ids, etc., and can also carry the second identification information, including the second target blockchain id, used to determine that the first subscription request is sent to the second blockchain. The second blockchain can save the correspondence between the first data and the first blockchain, and when the first data changes, synchronize the updated first data to the first blockchain.

[0020] In a possible implementation of the above first aspect, in response to updating the first attribute of the first data from the first sub-information to the second sub-information, updating the first sub-information in the first blockchain based on the second sub-information includes: detecting that when the first attribute of the first data is updated from the first sub-information to the second sub-information in the second blockchain, determining the first blockchain based on the first subscription relationship; sending an update request to the first blockchain through the second business smart contract, where the update request carries the first attribute of the first data and the second sub-information; updating the first attribute of the first data in the first blockchain based on the second sub-information.

[0021] It can be seen that when the first data stored in the second blockchain changes, the first blockchain can receive an update request and synchronously update the subscribed first data.

[0022] In a second aspect, the present application provides a data processing system. The data processing system includes: an inter-chain node. The inter-chain node is used to establish a binding relationship between the first blockchain and the second blockchain. The inter-chain node is further used to receive a first subscription request for the first data sent by the first blockchain to the second blockchain, and forward the first subscription request to the second blockchain, where the first data is stored on the second blockchain. The second blockchain returns the first data to the first blockchain through the inter-chain node based on the first subscription request, and the first blockchain stores the first data. The first attribute of the first data includes first sub-information. After the second blockchain updates the first attribute of the first data from the first sub-information to the second sub-information, it sends the second sub-information to the first blockchain through the inter-chain node, and the first blockchain updates the first sub-information based on the second sub-information.

[0023] In this specification, the first blockchain and the second blockchain here can be blockchains corresponding to the business systems / applications of different users / enterprises. The first blockchain and the second blockchain can be respectively deployed on the servers of the users / enterprises. The data processing system can be deployed on a server different from the first blockchain and the second blockchain. A binding relationship can be established between the first blockchain and the second blockchain through the inter-chain node. This binding relationship can also be called a blockchain binding relationship. Different functional business smart contracts can be deployed between the first blockchain and the second blockchain through the binding relationship for processing data on the first blockchain or the second blockchain. The first data here can be the data stored on the second blockchain, such as: outsourced parts. The first attribute can be used to describe the first data, such as: carbon emissions. The first sub-information and the second sub-information can be the attribute values of the first attribute, such as: carbon emissions. The first subscription request here can be a cross-chain subscription request for the first data, used to ensure that when the first blockchain stores the first data and the second blockchain updates the first data, the first blockchain can update the first data simultaneously, that is, the first blockchain and the second blockchain keep the first data synchronized.

[0024] In a possible implementation of the second aspect described above, the cross-chain node receives the first registration request and the second registration request of the first blockchain and the second blockchain. The first registration request and the second registration request carry the first identification information of the first blockchain and the second identification information of the second blockchain respectively. The cross-chain node records the first identification information and the second identification information. In response to the first registration request and the second registration request, the cross-chain node deploys the first cross-chain smart contract and the second cross-chain smart contract to the first blockchain and the second blockchain respectively. The first cross-chain smart contract and the second cross-chain smart contract correspond to the first identification information and the second identification information respectively, and the first cross-chain smart contract and the second cross-chain smart contract are used to initiate a blockchain binding request between the first blockchain and the second blockchain.

[0025] In this specification, the first registration request and the second registration request here may be registration requests sent by the first blockchain and the second blockchain to the cross-chain node respectively for cross-chain access. The first registration request and the second registration request may carry the first identification information and the second identification information respectively, such as the protocol and version of the blockchain. The cross-chain smart contract here can be used to operate on multiple different blockchains to realize the interaction and communication between different blockchains. For example, the cross-chain smart contract can support the establishment of a link relationship between different blockchains and trigger the installation of different business smart contracts. The first blockchain and the second blockchain can each install a cross-chain smart contract corresponding to the first identification information and the second identification information. A blockchain binding request can be initiated between the first blockchain and the second blockchain through the cross-chain smart contract. The blockchain binding request here is used to establish a binding relationship at the chain level between the first blockchain and the second blockchain.

[0026] In a possible implementation of the second aspect described above, it further includes: the cross-chain node receives the first binding request of the first blockchain, where the first binding request is sent through the first cross-chain smart contract and carries the first identification information and the second identification information. In response to the first binding request forwarded by the cross-chain node, the second blockchain records the first identification information of the first blockchain, and the cross-chain node returns the first binding result to the first blockchain. In response to the first binding result, the first blockchain records the second identification information of the second blockchain.

[0027] In this specification, the cross-chain node here can receive the first binding request of the first blockchain. The first binding request carries the first identification information of the first blockchain and the second identification information of the second blockchain to be bound. The cross-chain node can forward the first binding request to the second blockchain. The second blockchain determines the establishment of a binding relationship with the first blockchain by recording the correspondence between the first identification information and the second identification information.

[0028] In a possible implementation of the second aspect described above, it further includes: The cross-chain node deploys a first business smart contract and a second business smart contract to the first blockchain and the second blockchain respectively, where the first business smart contract and the second business smart contract correspond to the first identification information and the second identification information respectively, and the first business smart contract and the second business smart contract are used to initiate a subscription request between the first blockchain and the second blockchain.

[0029] It can be seen that the business smart contracts here can include different smart contracts corresponding to different business functions. Data can be subscribed between the first blockchain and the second blockchain deployed on different servers through the business smart contracts. Furthermore, data synchronization between the first blockchain and the second blockchain is achieved.

[0030] In a possible implementation of the second aspect described above, it includes: The first blockchain sends a first subscription request through the first business smart contract, where the first subscription request carries the first identification information and the first data identification information of the first data; after determining that a binding relationship is established between the second blockchain and the first blockchain, based on the first identification information and the first data identification information, the second blockchain records the first subscription relationship between the first data and the first blockchain, and based on the second identification information and the first data identification information, the first blockchain records the second subscription relationship between the first data and the second blockchain.

[0031] It can be seen that the first subscription request here can be a cross-chain binding transaction request, which can be used to subscribe to the second blockchain to record the first data. The first identification information here can include the smart contract type of the first business smart contract of the first blockchain, the first data identification information can include component ids, etc., and can also carry the second identification information, including the second target blockchain id, for determining that the first subscription request is sent to the second blockchain. The second blockchain can save the correspondence between the first data and the first blockchain, and when the first data changes, synchronize the changed first data to the first blockchain.

[0032] In a possible implementation of the second aspect described above, in response to updating the first attribute of the first data from the first sub-information to the second sub-information, based on the second sub-information, updating the first sub-information on the first blockchain includes: When the first blockchain detects that the first attribute of the first data is updated from the first sub-information to the second sub-information on the second blockchain, based on the first subscription relationship, the first blockchain is determined; the first blockchain sends an update request to the first blockchain through the second business smart contract, where the update request carries the first attribute of the first data and the second sub-information; based on the second sub-information, the first blockchain updates the first attribute of the first data.

[0033] It can be seen that when the first data stored in the second blockchain changes, the first blockchain can receive an update request and synchronously update the subscribed first data.

[0034] In a third aspect, the present application provides a data processing system, characterized in that the data processing system includes: an inter-chain node and a first blockchain, wherein the inter-chain node is used to establish a binding relationship between the first blockchain and the second blockchain; the inter-chain node is further used to receive a first subscription request for the first data sent by the first blockchain to the second blockchain, and forward the first subscription request to the second blockchain, wherein the first data is stored on the second blockchain; the second blockchain returns the first data to the first blockchain through the inter-chain node based on the first subscription request, and the first blockchain stores the first data, wherein the first attribute of the first data includes first sub-information; after the second blockchain updates the first attribute of the first data from the first sub-information to the second sub-information, it sends the second sub-information to the first blockchain through the inter-chain node, and the first blockchain updates the first sub-information based on the second sub-information.

[0035] In this specification, the first blockchain and the second blockchain here can be blockchains corresponding to business systems / applications of different users / enterprises, and the first blockchain and the second blockchain can be respectively deployed on the servers of the users / enterprises. The data processing system can be deployed on the server of the first blockchain. The data processing system is composed of an inter-chain node and the first blockchain. A binding relationship can be established between the first blockchain and the second blockchain through the inter-chain node, and this binding relationship can also be called a blockchain binding relationship. Different functional business smart contracts can be deployed between the first blockchain and the second blockchain through the binding relationship for processing data on the first blockchain or the second blockchain. The first data here can be the data stored on the second blockchain, such as: outsourced parts, and the first attribute can be used to describe the first data, such as: carbon emissions. The first sub-information and the second sub-information can be the attribute values of the first attribute, such as: carbon emissions. The first subscription request here can be an inter-chain subscription request for the first data, used to enable the first blockchain to update the first data simultaneously when the first blockchain stores the first data and the second blockchain updates the first data, that is, the first blockchain and the second blockchain keep the first data synchronized.

[0036] In a fourth aspect, the present application provides an electronic device, including:

[0037] a memory for storing instructions executed by one or more processors of the electronic device, and

[0038] a processor for reading the instructions to execute the data processing method in the first aspect or any implementation manner.

[0039] Fifth aspect, the present application provides a computer-readable storage medium, including instructions, which when executed on an electronic device cause the electronic device to execute the data processing method according to the first aspect or any one of the implementation manners.

[0040] The beneficial effects of the above aspects can be referred to each other. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 Exemplarily shows an application scenario of a bill of materials based on blockchain technology in the specification of the present application;

[0042] Figures 2(a) to 2(b) Exemplarily shows a schematic diagram of a data processing system in the specification of the present application;

[0043] Figures 3(a) to 3(b) Exemplarily shows a schematic diagram of a data processing method in the specification of the present application;

[0044] Figures 4(a) to 4(b) Exemplarily shows a schematic diagram of a data processing method in the specification of the present application;

[0045] Figures 5(a) to 5(b) Exemplarily shows a schematic diagram of a data processing method in the specification of the present application;

[0046] Figures 6(a) to 6(b) Exemplarily shows a schematic diagram of a data processing method in the specification of the present application;

[0047] Figures 7(a) to 7(b) Exemplarily shows a schematic diagram of a data processing method in the specification of the present application;

[0048] Figure 8 Exemplarily shows a schematic diagram of the structure of the electronic device in the specification of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0049] The technical solutions in the embodiments of the present application will be clearly and elaborately described below with reference to the drawings. The following embodiments can be referred to each other.

[0050] It can be understood that the technical solution of this application is applicable to any electronic device, which may specifically be a personal computer (PC), an ultra-mobile personal computer (UMPC), a hardware server (including: entry-level server, workgroup-level server, department-level server, and enterprise-level server), and a cloud server. The electronic device may also include: non-foldable mobile phones, foldable mobile phones, wearable devices (such as smart watches, smart bracelets, etc.), tablet computers, laptop computers, smart screens, vehicle-mounted terminals, computers, laptops, netbooks, personal digital assistants (PDAs), virtual reality (VR) devices / augmented reality (AR) devices, artificial intelligence (AI) devices, and other terminal devices.

[0051] First, some terms related to the embodiments of this application will be explained below.

[0052] A blockchain is a chain composed of many blocks (nodes). Each block can store certain information, and multiple blocks can be connected into a chain in the order of the generation time corresponding to the stored information. The chain can be stored in a blockchain server. If you want to modify the information stored in a block in the blockchain, you need to obtain the consent of more than half of the blocks corresponding to the blockchain. Therefore, it is extremely difficult to tamper with the information in the blockchain. Compared with traditional networks, the blockchain has two core characteristics: one is that the data is difficult to tamper with, and the other is decentralization. Based on these two characteristics, the information recorded by the blockchain is more authentic and reliable, which can help solve the problem of people not trusting each other.

[0053] A smart contract is an application program on the blockchain that can automatically execute some predefined rules and terms based on the immutable data in the blockchain. For example: Based on smart contracts, different industry innovations can be realized on the basis of the blockchain, especially in scenarios where multiple parties who do not trust each other participate and there are requirements for data immutability and traceability.

[0054] The data involved in the embodiments of this application may include various products (such as: parts, finished products, etc.) or information (such as: transaction information, accounting information, etc.). Below, the data is taken as an example of outsourced parts / outsourced components / components for illustration. For the data stored on different blockchains, the data can be subscribed to obtain the updated information of the data, such as: the change of the attribute value corresponding to the attribute included in the data.

[0055] It can be understood that the embodiments of the present application are not limited to outsourced parts / outsourced components / components, and can also be applied to various data that can be saved through the blockchain.

[0056] After introducing the terms related to the embodiments of the present application, a Figure 1 application scenario of a bill of materials based on blockchain technology is shown. As Figure 1 shown, Node 101, Node 102, and Node 103 respectively correspond to Supplier A, Supplier B, and the OEM. Node 101, Node 102, and Node 103 form Blockchain 1001. Among them, the OEM can create a bill of materials (BOM) mapping to Node 103 through the Product Lifecycle Management (PLM) system 106, for example: the OEM issues a subscription for outsourced components, which is saved in Node 103. Node 103 synchronizes the bill of materials data to Node 102. Supplier B can obtain the bill of materials data from Node 102 through the Enterprise Resource Planning (ERP) system 105 and create a bill of materials in the Enterprise Resource Planning system 105. When Supplier B needs to subscribe to outsourced components, Supplier B can also create a bill of materials mapping to Node 102 through the Enterprise Resource Planning system 105. Node 102 synchronizes the bill of materials data to Node 101. Supplier A updates / synchronizes the bill of materials data from Node 101 through the Computer Aided Process Planning (CAPP) system 104. After Supplier A completes the product design change, Supplier A can also create a design change bill of materials data synchronization to Node 101 through the Computer Aided Process Planning system 104. It can be seen that Node 101 of Supplier A, Node 102 of Supplier B, and Node 103 of the OEM together constitute Blockchain 1001, and each node has all the data of the bill of materials data. Through the smart contract on Blockchain 1001, operations such as automatic conversion, encryption, and recording of the bill of materials can be realized. Through the unified Blockchain 1001, it provides the guarantee of data immutability and traceability for the collaboration of bill of materials data across Supplier A, Supplier B, and the OEM. However, generally, separate blockchains are configured for the above-mentioned Supplier A, Supplier B, and the OEM. Therefore, Node 101, Node 102, and Node 103 can be regarded as additional blockchain nodes (blocks) added by Supplier A, Supplier B, and the OEM. If the OEM needs to add a new Supplier C, even if Supplier C is already using a block and even if Supplier C is configured with a separate blockchain, a new node needs to be deployed in Blockchain 1001. As the number of suppliers increases, the cost of maintaining the blockchain will increase linearly.

[0057] To solve the above problems, this specification provides a data processing method based on cross-blockchains. By establishing inter-chain access (inter-chain access permissions) between the local blockchain and external blockchains (multiple blockchains), blockchains can be bound to each other through inter-chain access; further obtain, synchronize, and trace information between blockchains, such as information corresponding to externally purchased components in the bill of materials stored in the blockchain.

[0058] Exemplarily, a blockchain can execute different smart contracts to perform cross-chain collaborative computing on the stored information / data (such as the bill of materials). It can be seen that through the above data processing method, cross-chain on-demand deployment can be achieved between individual blockchains and smart contracts with different functions; when performing cross-chain collaborative computing corresponding to the information stored in the blockchain (such as the bill of materials), in addition to calculating its own data, the local blockchain can also collaboratively calculate information on the data corresponding to the external blockchain (the blockchain bound through inter-chain access). That is to say, traceable cross-chain collaborative computing on data can be achieved between multiple blockchains. For example: taking the data as the bill of materials, in addition to calculating the information of its own bill of materials, the local blockchain can also collaboratively calculate information on externally purchased components (which can also be called externally purchased parts) corresponding to the external blockchain (the blockchain bound through inter-chain access), and achieve traceable cross-chain collaborative computing of the bill of materials between the blockchains of multiple enterprises.

[0059] Specifically, the process of establishing inter-chain access (inter-chain access permissions) between the local blockchain and the external blockchain can be implemented through a cross-blockchain data processing system 200 as shown in Figure 2(a). The data processing system 200 includes: a blockchain 201, a blockchain 202, and an inter-chain node 205. Among them, the blockchain 201 and the blockchain 202 respectively correspond to enterprise A and enterprise B. Among them, the product data management system 203 of enterprise A and the enterprise resource system 204 of enterprise B can publish relevant data to the blockchain 201 and the blockchain 202, that is, realize data on-chain. Configure the inter-chain node 205. In a multi-blockchain scenario, the blockchain 201 and the blockchain 202 can complete a registration application through the inter-chain node 205; the inter-chain node 205 determines the inter-chain access permissions between the blockchain 201 and the blockchain 202 according to the registration information corresponding to the registration application, that is, establishes inter-chain access between the blockchain 201 and the blockchain 202. The inter-chain node 205 can also deploy cross-chain smart contracts and business smart contracts as needed between the blockchain 201 and the blockchain 202 to realize cross-chain interaction between the blockchain 201 and the blockchain 202, that is, realize cross-chain information forwarding between the blockchain 201 and the blockchain 202.

[0060] It can be understood that the data processing system 200 shown in Fig. 2(a) can support various types of enterprise application systems, such as: PDM system, ERP system, Customer Relationship Management (CRM) system, etc. The above enterprise application systems are used to publish relevant data to the blockchain; support triggering the invocation of business intelligent contracts on the blockchain, and implement cross-enterprise data collaborative computing. The intelligent contracts applicable to the data processing system 200 can include: cross-chain intelligent contracts and business intelligent contracts. Here, the cross-chain intelligent contract can be installed when the blockchain accesses the cross-chain node 205, and is used to support the establishment of link relationships between different blockchains and trigger the installation of different business intelligent contracts. Here, the business intelligent contract can include different intelligent contracts corresponding to different business functions. For example, the convolution computing intelligent contract is used to perform traceable convolution computing on the corresponding blockchain. The data processing system 200 shown in Fig. 2(a) can be used in scenarios involving untrusted multi-enterprise participation and data immutability / traceability.

[0061] It can be understood that the cross-chain intelligent contract here is an intelligent contract that can be executed on different blockchains. Compared with traditional intelligent contracts that are usually limited to execution within a single blockchain, the cross-chain intelligent contract extends this ability, enabling it to operate on multiple different blockchains and achieve interaction and communication between different blockchains. The implementation of such a cross-chain intelligent contract usually requires the collaborative work of multiple blockchain networks. The cross-chain intelligent contract based on the blockchain can include the following characteristics: Multi-chain interoperability: The cross-chain intelligent contract allows communication and data transfer between multiple different blockchain networks. This means that the contract can read and operate on data on different blockchains, achieving interoperability between multiple chains. Atomic exchangeability: The cross-chain intelligent contract can achieve atomic exchange, that is, atomically exchange different cryptographic assets on two different blockchains without trusting a third party. This exchange can be implemented in the intelligent contract to ensure the security and consistency of assets during the exchange process. Consistency of consensus algorithms: Different blockchain networks may adopt different consensus algorithms. The cross-chain intelligent contract needs to ensure that a consistent consensus is reached on each blockchain network participating in the cross-chain interaction to ensure the validity and security of transactions. Security and credibility: The cross-chain intelligent contract needs to consider issues of security and credibility to ensure the confidentiality and integrity of data in cross-chain interactions. Technologies such as encryption and digital signatures are usually used to ensure the security of cross-chain intelligent contracts.

[0062] In this specification, the data processing system 200 shown in FIG. 2(a) may also include only the cross-chain node 205. The data processing system 200 can be deployed separately on a server, such as a system server or a cloud server. The cross-chain node 205 can be deployed to provide a cloud service for cross-blockchain access externally. The blockchains corresponding to the business systems / applications of each enterprise can register cross-chain access by accessing the cloud service for cross-blockchain access. As shown in FIG. 2(b), the cross-chain node 205 can also be deployed in a blockchain of a certain enterprise, forming a blockchain with the blockchain corresponding to the business system / application of the enterprise. The cross-chain node 205 can be used as a cloud service for providing blockchain access externally; other enterprises having business relationships with the enterprise can register cross-chain access of their own blockchains with the cross-chain node 205.

[0063] The data processing method of this specification will be introduced in detail below by means of the processing methods of registration, binding, subscription, synchronization, and traceability corresponding to the blockchain.

[0064] FIG. 3(a) shows the process of the blockchain 201 registering with the cross-chain node 205 in the data processing system 200 according to an embodiment of the present application. Here, the blockchain 201 needs to complete registration with the cross-chain node 205 to support the interaction between the blockchain 201 and different blockchains registered on the cross-chain node 205. The process of the blockchain 201 registering with the cross-chain node 205 includes the following steps.

[0065] S301: The blockchain 201 sends a registration request for cross-chain access to the cross-chain node 205.

[0066] Exemplarily, there can be a network connection between the blockchain 201 and the cross-chain node 205. The blockchain 201 sends a registration request to the cross-chain node 205. The registration request here may include the protocol and version of the blockchain 201.

[0067] S302: The cross-chain node 205 processes the registration request and obtains a cross-chain smart contract that matches the registration request.

[0068] Exemplarily, the cross-chain node 205 processes the registration request. After identifying the registration request, it queries the contract library for a cross-chain smart contract that matches the registration request based on the blockchain protocol and version of the blockchain 201. The cross-chain node 205 can also save the registration information of each blockchain that sends a registration request to it through the registration information library.

[0069] The following table shows the contract library information in a cross-chain node 205 according to an embodiment of the present application. It can be seen that smart contracts with the same function can correspond to different smart contract versions for different blockchain versions or blockchain protocols, and the smart contract versions can be distinguished by the smart contract id.

[0070]

[0071]

[0072] The following table shows the registration information corresponding to the blockchain in the embodiments of the present application.

[0073] Blockchain ID Blockchain protocol Blockchain version Blockchain 1: xx Ethereum V xxxx Blockchain 2: yy Ethereum V yyyy Blockchain 3: zz Quorum V zzzz

[0074] It can be seen that the cross-chain node 205 can receive registration requests of multiple blockchains, and each registered blockchain can have a unique blockchain id.

[0075] S303: The cross-chain node 205 returns a cross-chain smart contract to the blockchain 201.

[0076] Exemplarily, the cross-chain node 205 returns a response message corresponding to the registration request to the blockchain 201. The response message mainly includes deployment information of the cross-chain smart contract. For example, it includes contract code of the cross-chain smart contract that can be directly deployed, or an installation script for executing the deployment of the cross-chain smart contract.

[0077] S304: The blockchain 201 deploys the cross-chain smart contract.

[0078] Exemplarily, when receiving the deployment information of the cross-chain smart contract, the blockchain 201 deploys the cross-chain smart contract to all nodes of the blockchain 201 through the blockchain consensus mechanism. The blockchain consensus mechanism here is an algorithm or rule system applied to the blockchain. The blockchain consensus mechanism can ensure the consistency of all nodes in the same blockchain, that is, the consistency of the cross-chain smart contract supported by all nodes in the blockchain 201, thereby maintaining the security and credibility of the blockchain.

[0079] In some embodiments, the cross-chain node 205 can also receive registration requests of multiple other blockchains outside the blockchain 201, and any one of the blockchains can adopt the blockchain registration method shown in FIG. 3(a) above.

[0080] In some other embodiments, the process of the blockchain 201 registering with the cross-chain node 205 described in FIG. 3(a) can also be illustrated by FIG. 3(b). As shown in FIG. 3(b), the process of the blockchain 201 registering with the cross-chain node 205 includes the following steps: S301b: Cross-chain access registration; S302b: Process the registration and obtain the contract; S303b: Return the contract; S304b: Deploy the contract. Specifically, the blockchain 201 sends a registration request to the cross-chain node 205, and the request message includes the protocol and version of the current block. The cross-chain node 205 processes the request, identifies it as a registration request, queries the contract library for a matching cross-chain smart contract based on the blockchain protocol and version. The cross-chain node 205 returns a response message to the registration request, mainly including the deployment information of the cross-chain smart contract, which includes the contract code to be deployed. When the blockchain 201 receives the deployment information of the cross-chain smart contract, it deploys the smart contract to all nodes of the blockchain through the blockchain consensus mechanism.

[0081] It can be seen that after the blockchain 201 is registered with the cross-chain node 205 through the steps S301 to S304 shown in FIG. 3(a) above, next, the blockchain 201 can deploy various business smart contracts through the cross-chain node 205. For example, obtain the business smart contracts that the blockchain 201 can support and run from the cross-chain node 205, and then realize subscription, access, and synchronization between blockchains, that is, realize subscription, access, and synchronization between the blockchain 201 and other blockchains registered with the cross-chain node 205. Deploying business smart contracts can be divided into two steps, including: first, establishing the relationship (subscription) between blockchains, and then deploying business smart contracts with different functions.

[0082] FIG. 4 shows the process of subscription between the blockchain 201 (purchaser xx) and the blockchain 202 (supplier yy) through the cross-chain node 205 in the data processing system 200 according to the embodiment of the present application, including the following steps.

[0083] S401: The business system / application 203 initiates a blockchain binding request.

[0084] Exemplarily, the blockchain binding request here can be initiated by the business system or application 203 of the enterprise owning the blockchain 201 to establish a relationship at the chain level, such as between the blockchain 201 and the blockchain 202. For example, the product data management system corresponding to the blockchain 201 needs to obtain product information of the supplier through the blockchain 201. The business system or application 203 can initiate a blockchain binding request to the blockchain 201 (source blockchain), that is, a cross-chain binding request, to request to establish a binding relationship between the two blockchains with the blockchain 202 (target blockchain). The cross-chain binding information in the blockchain binding request here can include: source blockchain id, target blockchain id.

[0085] S402: The blockchain 201 responds to the blockchain binding request, triggers a cross-chain transaction based on a pre-set system-level smart contract, and sends a cross-chain binding request to the cross-chain node 205.

[0086] Exemplarily, the system-level smart contract here can be a cross-chain smart contract already deployed on the blockchain 201. For example, the cross-chain smart contract deployed through the above steps S301 to S304. After the business system / application 203 initiates a blockchain binding request to the blockchain 201, the cross-chain smart contract of the blockchain 201 (source blockchain) can trigger a cross-chain binding request (which can also be called a cross-chain binding smart contract request) in response to the blockchain binding request. The cross-chain binding request is sent to the cross-chain node 205 through the blockchain 201. The cross-chain binding request here can also include the source blockchain id and the target blockchain id.

[0087] S403: The cross-chain node 205 sends the cross-chain binding request to the blockchain 202 corresponding to the cross-chain binding request.

[0088] Exemplarily, the cross-chain smart contract deployed by the cross-chain node 205 can send a cross-chain binding request to the target blockchain (such as: blockchain 202) based on the target blockchain id in the cross-chain binding request sent by the blockchain 201. The cross-chain binding request forwarded by the cross-chain node 205 can include the source blockchain id.

[0089] S404: The blockchain 202 responds to the cross-chain binding request, and after smart contract consensus, formally establishes a blockchain binding relationship.

[0090] Exemplarily, the smart contract consensus here can be used for the blockchain 202 to establish a blockchain binding relationship with the blockchain 201. That is, the blockchain 202 (target blockchain) through the cross-chain smart contract, after receiving the cross-chain binding request sent by the cross-chain node 205, based on the source blockchain id included in the cross-chain binding request, formally establishes a blockchain binding relationship with the blockchain 201 (which can be confirmed through interaction with the user).

[0091] S405: The blockchain 202 records the blockchain binding relationship.

[0092] Exemplarily, the blockchain 202 can record the blockchain binding relationship (cross-chain binding relationship) in the distributed ledger of the blockchain 202, which can be used for subsequent access permission judgment between the blockchain 201 and the blockchain 202. The distributed ledger of the blockchain 202 here can mainly include source blockchain id information, such as: xx.

[0093] S406: The blockchain 202 notifies the blockchain 201 of the blockchain binding relationship through the cross-chain node 205, and the blockchain 201 records the blockchain binding relationship.

[0094] Exemplarily, the blockchain 201 notifying the blockchain binding relationship through the cross-chain node 205 can also be referred to as the mutual confirmation between the blockchain 201 and the blockchain 202. It can be that after the blockchain 202 (the target blockchain) confirms the blockchain binding relationship, the blockchain 202 notifies the blockchain 201 through the cross-chain node 205 that the blockchain 202 has confirmed. After the blockchain 202 (the target blockchain) confirms the blockchain binding relationship, the blockchain 201 (the source blockchain) also records the blockchain binding relationship (the cross-chain binding relationship) in the distributed ledger of the blockchain 201. Here, the distributed ledger of the blockchain 201 mainly includes the target blockchain id information, such as: yy.

[0095] It can be seen that after establishing the inter-blockchain binding relationship (the blockchain binding relationship) between the blockchain 201 and the blockchain 202, business smart contracts with different functions can be deployed. Here, taking a data convolution smart contract in the business smart contract as an example for illustration, in the convolution calculation based on the blockchain, the convolution smart contract can process the data on the blockchain (such as: updating / synchronizing data, etc.), and the convolution smart contract can be jointly verified and executed by multiple nodes corresponding to the blockchain to ensure the accuracy and security of the calculation. The convolution smart contract based on the blockchain has the characteristics of decentralization, transparency, and security. Since the data is distributedly stored and processed, the convolution smart contract ensures the credibility of the data processing process, making the convolution smart contract applicable to some scenarios with high requirements for data privacy and security.

[0096] S407: The business system / application 203 triggers the installation of a business smart contract with a specified function.

[0097] Exemplarily, the business system / application 203 can trigger the installation of a business smart contract with a specified function on the blockchain 201 and the blockchain 202 (the target blockchain) that has a binding relationship with the blockchain 201. That is, the business system / application 203 selects the corresponding target blockchain and triggers the installation of a business smart contract with a specified function, such as: the convolution smart contract. When the business system / application 203 triggers the installation of the convolution smart contract, this process can also be referred to as convolution function collaboration. In some embodiments, the business system / application 203 can send an installation request for the business smart contract with a specified function to the blockchain 201, and the request message carried by the installation request mainly can include the target blockchain id, the smart contract name, and so on.

[0098] S408: The blockchain 201 triggers cross-chain interaction by executing the cross-chain binding contract and publishes the installation request for the business smart contract with a specified function to the cross-chain node 205.

[0099] Exemplarily, the blockchain 201 (source blockchain) receives an installation request for a business intelligent contract triggered by the business system / application 203, such as: an installation request for a convolutional intelligent contract. The blockchain 201 can trigger the deployment of a cross-chain business intelligent contract through a cross-chain intelligent contract. For example, install / deploy a business intelligent contract on the blockchain 201 and the blockchain 202. This process can also be referred to as publishing a business intelligent contract with specified functions to other chains. The blockchain 201 can send a request for deploying a business intelligent contract to the cross-chain node 205 through a cross-chain intelligent contract. The request message carried in the request for deploying a business intelligent contract includes the target blockchain id and the intelligent contract name. In some embodiments, it can also be determined through the request message whether the blockchain 201 itself needs to install a business intelligent contract (such as: a convolutional intelligent contract). For example, if the blockchain 201 has not installed the business intelligent contract, the request message also needs to include the source blockchain id and the name of the intelligent contract to be installed; if the blockchain 201 has already installed it, it may not need to be included.

[0100] S409: The cross-chain node 205 sends the deployment information corresponding to the business intelligent contract to the blockchain 202 across the chain.

[0101] Exemplarily, after receiving the installation request sent by the blockchain 201 in step S408, the cross-chain node 205 parses the request message carried in the installation request by executing the cross-chain intelligent contract. For example: it can query the blockchain protocols and blockchain versions corresponding to the blockchain 201 and the blockchain 202 respectively from the registration information repository based on the blockchain ids in the request message (including: the source blockchain id and the target blockchain id); and query the matching business intelligent contract from the contract library based on the intelligent contract name, blockchain protocol, and blockchain version. After determining the intelligent contract version (intelligent contract id) corresponding to the business intelligent contract to be installed, the cross-chain node 205 can send the deployment information of the business intelligent contract (such as: a convolutional intelligent contract) to the blockchain 202 (target blockchain). The deployment information can include the installation script of the business intelligent contract to be installed / deployed and the source blockchain id of the blockchain 201 that sent the installation request.

[0102] S410: After receiving the deployment information sent by the cross-chain node 205, the blockchain 202 extracts the business intelligent contract and deploys it.

[0103] Exemplarily, the blockchain 202 (target blockchain) can receive the deployment information corresponding to the business smart contract of the cross-chain node 205 through a cross-chain smart contract, including: an installation script (e.g., the installation script of the convolutional smart contract) and the source blockchain id of the blockchain 201. The blockchain 202 can query the local distributed ledger and confirm whether a binding relationship has been established with the blockchain 201 based on the source blockchain id of the blockchain 201. If a binding relationship has been established, the business smart contract (convolutional smart contract) is deployed to all nodes of this blockchain through the blockchain consensus mechanism.

[0104] It can be understood that if the blockchain 201 (source blockchain) also needs to install the business smart contract (convolutional smart contract) in the above step S408, the cross-chain node 205 also needs to send the deployment information of the business smart contract (convolutional smart contract) to the blockchain 201 (source blockchain) through S409 and S410, and the blockchain 201 completes the installation / deployment of the business smart contract.

[0105] In some other embodiments, the process of implementing a subscription between the blockchain 201 (purchaser xx) and the blockchain 202 (supplier yy) described in FIG. 4(a) can also be illustrated by FIG. 4(b). As shown in FIG. 4(b), it includes: S401b: Initiate a blockchain binding request (establish a relationship at the chain level); S402b: Trigger a cross-chain transaction based on a pre-set system-level smart contract and send a cross-chain binding smart contract request; S403b: Send the binding request to the specified manufacturer's blockchain; S404b: After smart contract consensus, formally establish a blockchain binding relationship; S405b: Record the blockchain binding relationship; S406b: After mutual confirmation, record the blockchain binding relationship; S407b: Trigger convolutional function collaboration (install a smart contract with a specified function); S408b: Trigger a cross-chain transaction through the cross-chain binding contract and publish the convolutional smart contract to other chains; S409b: Cross-chain send the convolutional smart contract script; S410b: After receiving the collaboration request, extract the convolutional smart contract and deploy it. Specifically, the business system or application 203 initiates a cross-chain binding request to the blockchain 201 (source blockchain), requesting to establish a binding relationship between two blockchains with another blockchain 202 (target blockchain). The cross-chain binding request information includes the source blockchain id and the target blockchain id. The "cross-chain smart contract" of the source blockchain triggers the cross-chain binding request and sends a cross-chain binding request to the cross-chain node 205. The cross-chain smart contract of the cross-chain node 205 sends a cross-chain binding request to the target blockchain based on the target blockchain id in the request. After receiving the request, the cross-chain smart contract of the target blockchain formally establishes a blockchain binding relationship (which can be confirmed by interacting with the user). At the same time, record the cross-chain binding relationship in the distributed ledger of the blockchain, which can be used for access permission judgment later. The distributed ledger mainly includes the target blockchain id information. After the target blockchain confirms, the source blockchain also records the cross-chain binding relationship in the distributed ledger of the blockchain. The distributed ledger mainly includes the source blockchain id information. After establishing the binding relationship between blockchains, business smart contracts with different functions can be deployed. Here, the convolutional function is taken as an example. Select the corresponding target blockchain and trigger the installation of a smart contract with a specified function, such as a convolutional smart contract. The request message mainly includes the target blockchain id and the smart contract name. After receiving the request, the cross-chain smart contract of the source blockchain triggers cross-chain smart contract deployment and requests smart contract deployment from the cross-chain node. The clear message includes the target blockchain id and the smart contract name. It also includes whether it needs to install the smart contract itself. If it has already been installed, it doesn't need to. If not, it needs to provide the source blockchain id and the smart contract name to be installed. The cross-chain smart contract of the cross-chain node queries the blockchain protocol and version from the registration information library based on the blockchain id, and queries the matching smart contract from the contract library based on the smart contract name, blockchain protocol, and version.The cross-chain node sends the deployment information of the business intelligent contract (including the contract code to be deployed) and the requested source blockchain id to the target blockchain. After receiving the request, the cross-chain intelligent contract of the target blockchain queries the local distributed ledger to confirm whether a binding relationship has been established for this blockchain. If a binding relationship has been established, the intelligent contract is deployed to all nodes of this blockchain through the blockchain consensus mechanism. It can be understood that if the source blockchain also needs to install the business intelligent contract, the cross-chain node 205 also needs to install the corresponding intelligent contract for the source blockchain.

[0106] It can be seen that after implementing subscription and installing the business intelligent contract between blockchain 201 and blockchain 202, blockchain 201 and blockchain 202 can achieve cross-chain collaboration. Before this, blockchain 201 and blockchain 202 can also first ensure that blockchain 201 has the data access permission to blockchain 202. The process of implementing the data access permission of blockchain 201 subscribing to blockchain 202 is introduced below through Figure 5, that is, subscribing to the update information of the data on blockchain 202, including the following steps.

[0107] S501: The business system / application 203 initiates a cross-chain binding transaction request for the purchased part.

[0108] Exemplarily, here a purchased part or component can be used as an example of data for illustration. The purchased part can be the purchased component saved by the supplier with blockchain 202 on blockchain 202, and the one with blockchain 201 can be the purchaser. The update information of the purchased part can include: the order information of the purchased part, the attributes of the purchased part, and the attribute values (such as: carbon emissions, etc.). The cross-chain binding transaction request (subscription request) here can be initiated by the business system or application 203 of the enterprise with blockchain 201 for the cross-chain binding transaction of the purchased part. The cross-chain binding transaction request can also be called the cross-chain subscription request for the purchased component, and the request message carried by the cross-chain binding transaction request can include the intelligent contract type (such as: convolutional intelligent contract), the target blockchain id, the component id, etc.

[0109] S502: Blockchain 201 responds to the cross-chain binding transaction request and calls the business intelligent contract to trigger the cross-chain binding transaction.

[0110] Exemplarily, blockchain 201 can process the cross-chain binding transaction request through the business intelligent contract (such as: convolutional intelligent contract) and trigger the cross-chain binding transaction (i.e., cross-chain subscription request) with blockchain 202 corresponding to the target blockchain id.

[0111] S503: Blockchain 201 selects the corresponding blockchain 201 through the cross-chain node 205 and initiates a purchased part transaction.

[0112] Exemplarily, the blockchain 201 can initiate an external component transaction to the corresponding blockchain 202 based on the cross-chain interaction provided by the cross-chain nodes 205 through the convolutional smart contract, according to the target blockchain id in the request message carried by the cross-chain binding transaction request. The request for the external component transaction can carry the source blockchain id of the blockchain 201 and the component id.

[0113] S504: The blockchain 202 receives the external component transaction and determines whether a binding relationship has been established with the blockchain 201.

[0114] Exemplarily, the blockchain 202 (target blockchain) can process the external component transaction (which can be referred to as a cross-chain binding transaction or a cross-chain subscription request) through a business smart contract (such as a convolutional smart contract) to obtain the source blockchain id and the component id of the blockchain 201. Before this, the blockchain 202 can also first determine whether the blockchain 202 has established a binding relationship with the blockchain 201 (source blockchain). For example, query whether the binding relationship with the blockchain 201 is saved in the distributed ledger according to the source blockchain id. If there is a binding relationship with the blockchain 201, it can be determined that the binding relationship has been established, and step S505 is executed; otherwise, S508 can be executed to directly exit / deny the cross-chain binding transaction.

[0115] S505: After the blockchain 202 confirms the binding relationship with the blockchain 201, it triggers the invocation of the business smart contract to initiate the cross-chain binding transaction of the external component.

[0116] Exemplarily, after the blockchain 202 (target blockchain) determines that the blockchain 202 has established a binding relationship with the blockchain 201, it can process the cross-chain binding transaction through the convolutional smart contract to achieve the subscription of the external component.

[0117] It can be understood that step S504 and step S505 here can also be combined into one step, that is, to determine whether a binding relationship has been established between the two blockchains, and after permission confirmation, trigger the invocation of the smart contract of the supplier to initiate the external component transaction.

[0118] S506: The blockchain 202 records the ordering information corresponding to the external component on the distributed ledger through the business smart contract.

[0119] Exemplarily, the blockchain 202 can record the subscription information of the external component on the distributed ledger through the convolutional smart contract, including the component id (such as: 123), the purchaser (such as: xx), and the blockchain id corresponding to the purchaser (such as: xx), that is, the source blockchain id of the blockchain 201. It can be seen that the purchaser and the blockchain id corresponding to the purchaser here can use the same or different identifiers, but they need to be able to uniquely identify the purchaser and the blockchain id corresponding to the purchaser.

[0120] S507: The blockchain 201 records the subscription information corresponding to the off-the-shelf parts on the distributed ledger through the business intelligent contract.

[0121] Exemplarily, after the blockchain 202 successfully processes the cross-chain binding transaction, that is, the blockchain 202 records the order information corresponding to the off-the-shelf parts on the distributed ledger through the convolutional intelligent contract. The blockchain 201 (source blockchain) can synchronize / obtain the subscription information already recorded by the blockchain 202 based on the cross-chain interaction provided by the cross-chain node 205 through the business intelligent contract (convolutional intelligent contract). The blockchain 201 can also record the subscription information of the off-the-shelf parts on the distributed ledger, including the off-the-shelf part id (e.g., 123), the supplier (e.g., yy), and the blockchain id corresponding to the supplier (e.g., yy), that is, the target blockchain id of the blockchain 202. It can be seen that the supplier and the blockchain id corresponding to the supplier here can use the same or different identifiers, but they need to be able to uniquely identify the supplier and the blockchain id corresponding to the supplier.

[0122] In some other embodiments, the process of the blockchain 201 subscribing to the data permission of the blockchain 202 described in FIG. 5(a) can also be illustrated by FIG. 5(b). As shown in FIG. 5(b), it includes: S501b: Initiate the cross-chain binding transaction of the off-the-shelf parts; S502b: Invoke the intelligent contract to trigger the cross-chain binding transaction; S503b: Select the corresponding target blockchain and initiate the off-the-shelf parts transaction; S504b: Determine whether the two blockchains have established a binding relationship; S505b: After confirming the permission, trigger the invocation of the intelligent contract of the supplier to start the off-the-shelf parts transaction; S506b: The intelligent contract records the order information corresponding to the off-the-shelf parts on the distributed ledger; S507b: The intelligent contract records the subscription information corresponding to the off-the-shelf parts on the distributed ledger. Specifically, the business system or application 203 triggers the cross-chain subscription request for the off-the-shelf parts, and the request includes the intelligent contract type (convolutional intelligent contract), the target blockchain id, the part id, etc. The convolutional intelligent contract of the blockchain 201 (source blockchain) processes the request and triggers the cross-chain subscription request. The cross-chain node 205 forwards the request to the corresponding blockchain 202 (target blockchain) based on the target blockchain id. The convolutional intelligent contract of the target blockchain processes the request, first determines whether this blockchain has established a binding relationship with the source blockchain, and after permission confirmation, subscribes to the off-the-shelf parts. The convolutional intelligent contract records the subscription information of this part on the distributed ledger, including the part id, the purchaser and its blockchain id. After the target blockchain successfully processes, the source blockchain also records the subscription information of the off-the-shelf parts on the distributed ledger, including the off-the-shelf part id and the supplier machine blockchain id.

[0123] It can be seen that the above Figure 5 uses externally purchased parts as data to illustrate the data permissions based on the data of the cross-chain node 205. After the purchaser completes the purchase of externally purchased parts through the cross-chain node 205, that is, after the purchaser completes the subscription of externally purchased parts, if the supplier modifies the information of the externally purchased parts on the blockchain 202, it can be synchronized to the purchaser's blockchain 201 through the cross-chain interaction provided by the cross-chain node 205. The process of synchronizing the data of the blockchain 202 to the blockchain 201 is introduced below through Figure 6, including the following steps.

[0124] S601: The business system / application 204 changes the attribute value of the part.

[0125] Exemplarily, the part here can be a kind of data. For example, the part can represent an externally purchased part, and the supplier can trigger the modification of the attribute value corresponding to the externally purchased part on the blockchain 202 (target blockchain) through the business system / application 204. The business system / application 204 can send a change request for the corresponding externally purchased part to the blockchain 202. The situation message carried by the change request can include the part id (such as: 123), attribute (such as: carbon emission), and the attribute value to be modified.

[0126] S602: The blockchain 202 triggers the business smart contract to update the attribute value of the part on the chain.

[0127] Exemplarily, the blockchain 202 (target blockchain) can record the modification information corresponding to the externally purchased part in the distributed ledger through the business smart contract (convolutional smart contract). The modification information can include the part id, attribute, and the attribute value to be modified. That is, according to the part id, find the corresponding externally purchased part in the distributed ledger and update the attribute value of the found externally purchased part.

[0128] S603: The blockchain 202 triggers the permission verification and triggers the information synchronization by querying the purchaser information of the part.

[0129] Exemplarily, the permission verification here can include the blockchain 202 (target blockchain) confirming through the convolutional smart contract whether to trigger the synchronization of the attributes corresponding to the part to the source blockchain. That is, the blockchain 202 queries the subscription information corresponding to the part recorded on the distributed ledger through the convolutional smart contract to determine whether there is purchaser information to be synchronized (such as: purchaser: xx and the blockchain id corresponding to the purchaser: xx). If it exists, an attribute update request for the part is initiated to the corresponding blockchain 201 (source blockchain) through the cross-chain interaction provided by the cross-chain node 205. The request message carried by the attribute update request can include the source blockchain id, part id, attribute, and the attribute value to be modified, supplier information, etc.

[0130] S604: The blockchain 202 initiates information synchronization of the component to the blockchain of the purchaser corresponding to the component through the cross-chain node 205.

[0131] Exemplarily, after receiving the attribute update request, the cross-chain node 205 can forward the request message to the source blockchain, that is, the blockchain 201, based on the source blockchain id included in the situation message carried in the attribute update request.

[0132] S605: In response to the information synchronization, the blockchain 201 triggers permission verification, determines that the supplier information corresponding to the saved component is consistent, and triggers the business intelligent contract.

[0133] Exemplarily, after receiving the attribute update request, the blockchain 201 (source blockchain) can first perform permission verification through the convolutional intelligent contract to determine whether the component id and supplier information in the request message carried in the attribute update request are consistent with the supplier information corresponding to the purchased parts recorded in the distributed ledger corresponding to the blockchain 201. If they are consistent, the convolutional intelligent contract is used to trigger the attribute update operation corresponding to the purchased parts.

[0134] S606: The blockchain 201 refreshes the attribute value of the component through the business intelligent contract.

[0135] Exemplarily, the blockchain 201 can update the attribute value to be modified to the distributed ledger of the blockchain 201 through the convolutional intelligent contract according to the component id (e.g., 123) and the attribute (e.g., carbon emission).

[0136] In some other embodiments, the process of the blockchain 201 synchronizing the data of the blockchain 202 described in FIG. 6(a) can also be illustrated by FIG. 6(b). As shown in FIG. 6(b), it includes: S601b: The supplier changes the attribute value of the component; S602b: Trigger the smart contract to update the component attribute value on the chain; S603b: Permission verification, trigger information synchronization by querying the purchaser information of the component; S604b: Initiate the transfer of component attributes to the blockchain of the corresponding purchaser; S605b: Permission verification, determine that the component purchase information is consistent with the supplier, and trigger the smart contract; S606b: Refresh the attribute value of the component through the smart contract. Specifically, the business system / application 204 triggers the modification of the component attribute value of the target blockchain, and the request includes the component id, attribute, and value. The convolutional smart contract of the blockchain 202 (target blockchain) records information in its distributed ledger, including the component id, attribute, and value. The convolutional smart contract of the target blockchain confirms whether to trigger the attribute synchronization to the source blockchain. The convolutional smart contract queries whether there is purchaser information to be synchronized through the component subscription information. If so, it initiates an attribute update request to the corresponding source blockchain, and the request message includes the source blockchain id, component id, attribute, value, and supplier. After receiving the request, the cross-chain node 205 forwards the message to the source blockchain based on the source blockchain id. The convolutional smart contract of the blockchain 201 (source blockchain) first performs permission verification to determine whether the component id and supplier information in the request are consistent with those in the distributed ledger. If they are consistent, it triggers the attribute update operation. The convolutional integration contract updates the component id, attribute, and value to the distributed ledger.

[0137] It can be seen that in addition to the supplier synchronizing the attributes (galaxies) of the purchased parts to the blockchain 201 of the purchaser through the cross-chain node 205, the following introduces another process for the blockchain 201 to synchronize the data of the blockchain 202 through FIG. 7, including the following steps.

[0138] S701: The business system / application 203 triggers the convolutional calculation of the attributes corresponding to the components.

[0139] Exemplarily, the convolutional calculation for the components here can also be referred to as a synchronous update operation for the data. The business system or application 203 of the purchaser who owns the blockchain 201 can initiate the convolutional calculation for the attributes of all the components saved on the blockchain 201. Here, the convolutional calculation can be used to actively update the attributes of the components saved on the blockchain 201. The process of the convolutional calculation can include first finding the component ids of all the components and then performing the convolutional calculation for the attributes of each component one by one according to the component ids. This process is used to update all the components recorded by the purchaser once. The business system / application 203 can send a convolutional calculation request to the blockchain 201.

[0140] S702: The blockchain 201 automatically performs convolution calculations based on the BOM results through business smart contracts.

[0141] Exemplarily, after receiving a convolution calculation request, the blockchain 201 (source blockchain) can perform recursive convolution based on the BOM results (which can also be referred to as BOM sub-items) corresponding to all components saved on the distributed ledger. The BOM results here can include the attributes of all components, such as: component id, supplier information, etc.

[0142] S703: When it comes to purchased parts, the blockchain 201 triggers the convolution calculation of the purchased parts at the supplier through the smart contract.

[0143] Exemplarily, when the blockchain 201 is performing convolution calculations through the convolution smart contract and it is confirmed that a component is a purchased part, that is, the BOM sub-item corresponding to a component includes supplier information, then the supplier information can be queried from the subscription information corresponding to the purchased part in the distributed ledger, further triggering the convolution calculation of the purchased part at the supplier. That is, through the cross-chain interaction of the cross-chain node 205, a convolution calculation request is sent to the target blockchain of the supplier.

[0144] S704: Based on the supplier information of the purchased part, the blockchain 201 triggers a cross-chain convolution calculation request for the purchased part to the blockchain 202 through the cross-chain node 205.

[0145] Exemplarily, the blockchain 201 can send a cross-chain convolution calculation request for the purchased part to the cross-chain node 205 through the convolution smart contract. The request message carried by the convolution calculation request can include: target blockchain id (e.g., yy), component id (e.g., 123), attributes to be convolved (e.g., carbon emissions), and purchaser information (source blockchain id: xx). Through the cross-chain interaction of the cross-chain node 205, the convolution calculation request can be forwarded to the blockchain 202 (target blockchain).

[0146] S705: The blockchain 202 responds to the convolution calculation request and triggers permission verification based on the purchaser information of the purchased part.

[0147] Exemplarily, the blockchain 202 can process the convolution calculation request through the convolution smart contract and verify the subscription information of the convolution calculation request based on the subscription information (component id, purchaser information) corresponding to the components saved in the distributed ledger of the blockchain 202. That is, the blockchain 202 can query the purchased part in the distributed ledger through the component id in the convolution smart contract and determine that the purchaser information corresponding to the purchased part is consistent with the purchaser information in the convolution calculation request.

[0148] S706: The blockchain 202 triggers the convolution calculation for the purchased part.

[0149] Exemplarily, if the blockchain 202 determines that the convolution calculation request is legal through the convolution smart contract, that is, the permission verification for the convolution calculation request is passed, the blockchain 202 can trigger the convolution calculation of the purchased parts through the convolution smart contract.

[0150] S707: When the convolution calculation is completed, the blockchain 202 transfers the attributes of the purchased parts after the convolution calculation to the purchaser.

[0151] Exemplarily, after the blockchain 202 completes the convolution calculation of the purchased parts in the convolution calculation request through the convolution smart contract, it returns the attribute value corresponding to the purchased parts after the convolution calculation to the purchaser, and at the same time records the attribute value in the distributed ledger of the blockchain 202 (target blockchain). The blockchain 202 can return the attribute value corresponding to the purchased parts after the convolution calculation to the blockchain 201 through the cross-chain interaction of the cross-chain node 205.

[0152] S708: The blockchain 201 records the information of the purchased parts after the re-convolution calculation in the distributed ledger, and continues the convolution calculation until the final convolution results of all parts are obtained and recorded in the distributed ledger.

[0153] Exemplarily, after receiving the attributes of the purchased parts transferred by the blockchain 202, the blockchain 201 (source blockchain) records the attributes of the purchased parts after the re-convolution in the distributed ledger through the convolution smart contract, and continues the convolution calculation until the final convolution results are obtained. The final convolution results here can include: the blockchain 201 continues to perform convolution calculations on the attributes of all parts on the blockchain 201 through the convolution smart contract, and records the updated values (convolution values) of the part IDs and part attributes after the convolution calculation in the distributed ledger.

[0154] In some other embodiments, the process of the blockchain 201 synchronizing the data of the blockchain 202 described in FIG. 7(a) can also be illustrated by FIG. 7(b). As shown in FIG. 7(b), it includes: S701b: Trigger the convolutional calculation of attributes; S702b: The smart contract automatically performs convolutional calculation based on the BOM result; S703b: When an outsourced part is executed, trigger the convolutional calculation of the outsourced part at the supplier; S704b: Based on the supplier information of the outsourced part, trigger the convolutional calculation of the cross-chain outsourced part; S705b: Verify the legality based on the purchaser information; S706b: Trigger the recalculation of the convolutional information of the outsourced part; S707b: After the convolutional calculation is completed, transfer the attributes of the convolutional outsourced part to the purchaser; S708b: Record the re-convolutional information in the distributed ledger and continue the code calculation until the final convolutional result is obtained and recorded in the distributed ledger. Specifically, the business system / application 203 triggers the convolutional calculation of attributes, including the part id and the attributes to be convolved. The convolutional smart contract of the blockchain 201 (source blockchain) performs recursive convolution based on the BOM sub-items of the part. When a sub-item is an outsourced part, the supplier information of the part is queried from the part subscription information, and the convolutional calculation of the outsourced part at the source manufacturer is triggered. The convolutional smart contract sends a cross-chain convolutional calculation request for the outsourced part to the cross-chain node 205. The request includes the target blockchain id, the sub-item part id and the attributes to be convolved, and the purchaser (source blockchain id). The cross-chain node forwards the request to the blockchain 202 (target blockchain). The convolutional smart contract of the target blockchain processes the request and determines whether the request is legal based on the distributed ledger part subscription information (part id, purchaser). If the request is legal, the convolutional intelligent calculation is triggered for the part. After the convolutional calculation is completed by the smart contract, the attribute value of the convolutional calculation is returned to the purchaser, and at the same time, the attribute value is recorded in the distributed ledger of the target blockchain. After receiving the response, the convolutional smart contract of the source blockchain records the re-convolutional information in the distributed ledger and continues the convolutional calculation until the final convolutional result is obtained. And record the part id and the convolutional value of the attribute in the distributed ledger.

[0155] It can be seen that through cross-chain convolutional calculation, consistent convolutional calculation can be achieved between the blockchains of the purchaser and the supplier respectively, while ensuring the data security on their respective blockchains; ensuring the correctness, immutability, and traceability of the data. The outsourced parts can be traced back to the supplier side for convolutional calculation to ensure the accuracy and effectiveness of the data. At the same time, different manufacturers can adopt different blockchains to achieve cross-manufacturer data collaboration. Each manufacturer can choose its own blockchain, and through cross-chain nodes, different smart contracts can be automatically deployed between blockchains to support different business functions.

[0156] Figure 8 is a schematic structural diagram of an electronic device provided by an embodiment of the present application. InFigure 8 in which, similar components have the same reference numerals. In Figure 8 FIG. 3, the electronic device 800 includes: an interconnect unit 850 that is coupled to a processor 810; a system agent unit 880; a bus controller unit 890; an integrated memory controller unit 840; one or a group of one or more coprocessors 820, which may include integrated graphics logic, an image processor, an audio processor, and a video processor; a static random access memory (SRAM) unit 830; and a direct memory access (DMA) unit 860. In one embodiment, the coprocessor 820 includes a dedicated processor, such as, for example, a network or communication processor, a compression engine, general-purpose computing on graphics processing units (GPGPU), a high-throughput MIC processor, or an embedded processor, etc.

[0157] The static random access memory unit 830 may include one or more tangible, non-transitory computer-readable media for storing data and / or instructions. Instructions are stored in the computer-readable storage medium, specifically, temporary and permanent copies of the instructions are stored.

[0158] As Figure 8 shown, instructions are stored in the static random access memory unit 830 of the electronic device, and the instructions may include: instructions that, when executed by at least one of the processors, cause the electronic device to implement the methods shown in FIGS. 3(a), 4(a), 5(a), 6(a), and 7(a).

[0159] In the embodiments of the present application, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions according to the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (such as coaxial cable, optical fiber, digital subscriber line) or wirelessly (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that the computer can access, or a data storage device such as a server or data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid-state drive), etc.

[0160] Those of ordinary skill in the art can understand that to implement all or part of the processes in the embodiments of the present application, the processes can be completed by instructing relevant hardware with a computer program. The program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes in the embodiments of the present application. The aforementioned storage medium includes various media that can store program codes, such as read-only memory (ROM) or random access memory (RAM), magnetic disks, or optical discs.

[0161] It should be understood that although terms such as "first" and "second" may be used herein to describe various features, these features should not be limited by these terms. These terms are only used for distinction and should not be construed as indicating or implying relative importance. For example, without departing from the scope of the embodiments of the present application, the first feature can be referred to as the second feature, and similarly, the second feature can be referred to as the first feature.

[0162] In addition, various operations will be described as a number of separate operations in the most understandable way for the embodiments of the present application; however, the described order should not be construed as implying that these operations must depend on the described order, and many of these operations can be implemented in parallel, concurrently, or simultaneously. In addition, the order of the operations can also be rearranged. When the described operations are completed, the process can be terminated, but there can also be additional operations not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, and so on.

[0163] Unless otherwise specified in the context, the terms "comprise", "have", and "include" are synonyms. The phrase "A / B" means "A or B". The phrase "A and / or B" means "(A), (B), or (A and B)".

[0164] As used herein, the term "module" can refer to, as part of it, or include: a memory (shared, dedicated, or grouped) for running one or more software or firmware programs, an application specific integrated circuit (ASIC), an electronic circuit, and / or a processor (shared, dedicated, or grouped), combinational logic circuits, and / or other suitable components that provide the function.

[0165] In the drawings, some structural or method features may be shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order is not necessary. Instead, in the embodiments of the present application, these features can be described in a manner and / or order different from that shown in the illustrative drawings. Additionally, the structural or method features included in a specific drawing do not mean that all such features need to be included. In the embodiments of the present application, these features can be not included, or these features can be combined with other features.

[0166] The above has described the embodiments of the present application in detail with reference to the drawings. However, the use of the technical solutions of the present application is not limited to various applications mentioned in the embodiments of the present application. Various structures and variations can be easily implemented with reference to the technical solutions of the present application to achieve various beneficial effects mentioned herein. Within the scope of knowledge of those of ordinary skill in the art, various changes made without departing from the purpose of the present application shall fall within the scope covered by the patent of the present application.

Claims

1. A data processing method, characterized in that, the method includes: establishing a binding relationship between a first blockchain and a second blockchain; receiving a first subscription request for first data sent by the first blockchain to the second blockchain, wherein the first data is stored on the second blockchain; based on the first subscription request, storing the first data on the first blockchain, wherein a first attribute of the first data includes first sub-information; in response to updating the first attribute of the first data from the first sub-information to second sub-information, updating the first sub-information on the first blockchain based on the second sub-information.

2. The data processing method according to claim 1, characterized in that, the establishing of the binding relationship between the first blockchain and the second blockchain further includes: receiving a first registration request and a second registration request of the first blockchain and the second blockchain, wherein the first registration request and the second registration request respectively carry first identification information of the first blockchain and second identification information of the second blockchain; recording the first identification information and the second identification information; in response to the first registration request and the second registration request, deploying a first cross-chain smart contract and a second cross-chain smart contract to the first blockchain and the second blockchain respectively, wherein the first cross-chain smart contract and the second cross-chain smart contract respectively correspond to the first identification information and the second identification information, and the first cross-chain smart contract and the second cross-chain smart contract are used to initiate a blockchain binding request between the first blockchain and the second blockchain.

3. The data processing method according to claim 2, characterized in that, further includes: receiving a first binding request of the first blockchain, wherein the first binding request is sent through the first cross-chain smart contract and the first binding request carries the first identification information and the second identification information; in response to the first binding request, recording the first identification information of the first blockchain on the second blockchain and returning a first binding result to the first blockchain; in response to the first binding result, recording the second identification information of the second blockchain on the first blockchain.

4. The data processing method according to claim 3, characterized in that, further includes: deploying a first business smart contract and a second business smart contract to the first blockchain and the second blockchain respectively, wherein the first business smart contract and the second business smart contract respectively correspond to the first identification information and the second identification information, and the first business smart contract and the second business smart contract are used to initiate a subscription request between the first blockchain and the second blockchain.

5. The data processing method according to claim 4, characterized in that, the receiving of the first subscription request for the first data sent by the first blockchain to the second blockchain includes: The first subscription request is sent through the first business smart contract, and the first subscription request carries the first identification information and the first data identification information of the first data; After determining that the binding relationship is established between the second blockchain and the first blockchain, based on the first identification information and the first data identification information, record the first subscription relationship between the first data and the first blockchain in the second blockchain, and based on the second identification information and the first data identification information, record the second subscription relationship between the first data and the second blockchain in the first blockchain.

6. The data processing method according to claim 4, characterized in that, in response to updating the first attribute of the first data from the first sub-information to the second sub-information, updating the first sub-information in the first blockchain based on the second sub-information, including: when it is detected that the first attribute of the first data is updated from the first sub-information to the second sub-information in the second blockchain, determine the first blockchain based on the first subscription relationship; send an update request to the first blockchain through the second business smart contract, where the update request carries the first attribute of the first data and the second sub-information; update the first attribute of the first data in the first blockchain based on the second sub-information.

7. A data processing system, characterized in that, the data processing system includes: an inter-chain node, where the inter-chain node is used to establish a binding relationship between a first blockchain and a second blockchain; the inter-chain node is further configured to receive a first subscription request for a first data sent by the first blockchain to the second blockchain, and forward the first subscription request to the second blockchain, where the first data is stored on the second blockchain; the second blockchain returns the first data to the first blockchain through the inter-chain node based on the first subscription request, and the first blockchain stores the first data, where the first attribute of the first data includes a first sub-information; after the second blockchain updates the first attribute of the first data from the first sub-information to the second sub-information, send the second sub-information to the first blockchain through the inter-chain node, and the first blockchain updates the first sub-information based on the second sub-information.

8. The data processing system according to claim 7, characterized in that, the inter-chain node receives a first registration request and a second registration request of the first blockchain and the second blockchain, where the first registration request and the second registration request carry the first identification information of the first blockchain and the second identification information of the second blockchain respectively; the inter-chain node records the first identification information and the second identification information; In response to the first registration request and the second registration request, the cross-chain node deploys a first cross-chain smart contract and a second cross-chain smart contract to the first blockchain and the second blockchain respectively, where the first cross-chain smart contract and the second cross-chain smart contract correspond to the first identification information and the second identification information respectively, and the first cross-chain smart contract and the second cross-chain smart contract are used to initiate a blockchain binding request between the first blockchain and the second blockchain.

9. The data processing system according to claim 8, wherein, further comprising: The cross-chain node receives a first binding request from the first blockchain, where the first binding request is sent through the first cross-chain smart contract, and the first binding request carries the first identification information and the second identification information; In response to the first binding request forwarded by the cross-chain node, the second blockchain records the first identification information of the first blockchain, and the cross-chain node returns a first binding result to the first blockchain; In response to the first binding result, the first blockchain records the second identification information of the second blockchain.

10. The data processing system according to claim 9, wherein, further comprising: The cross-chain node deploys a first service smart contract and a second service smart contract to the first blockchain and the second blockchain respectively, where the first service smart contract and the second service smart contract correspond to the first identification information and the second identification information respectively, and the first service smart contract and the second service smart contract are used to initiate a subscription request between the first blockchain and the second blockchain.

11. The data processing system according to claim 10, wherein, comprising: The first blockchain sends the first subscription request through the first service smart contract, where the first subscription request carries the first identification information and the first data identification information of the first data; After determining that the binding relationship is established between the second blockchain and the first blockchain, based on the first identification information and the first data identification information, the second blockchain records the first subscription relationship between the first data and the first blockchain, and based on the second identification information and the first data identification information, the first blockchain records the second subscription relationship between the first data and the second blockchain.

12. The data processing system according to claim 10, wherein, The updating the first sub-information to the second sub-information of the first attribute of the first data in the first blockchain based on the second sub-information in response to the update includes: When the first blockchain detects that the first attribute of the first data is updated from the first sub-information to the second sub-information in the second blockchain, based on the first subscription relationship, the first blockchain is determined; The first blockchain sends an update request to the first blockchain through the second business intelligent contract, where the update request carries the first attribute of the first data and the second sub - information; Based on the second sub - information, the first blockchain updates the first attribute of the first data.

13. A data processing system, characterized in that, the data processing system includes: an inter - chain node and a first blockchain, where the inter - chain node is used to establish a binding relationship between the first blockchain and a second blockchain; the inter - chain node is further used to receive a first subscription request for first data sent by the first blockchain to the second blockchain, and forward the first subscription request to the second blockchain, where the first data is stored on the second blockchain; the second blockchain returns the first data to the first blockchain through the inter - chain node based on the first subscription request, and the first blockchain stores the first data, where the first attribute of the first data includes first sub - information; after the second blockchain updates the first attribute of the first data from the first sub - information to the second sub - information, it sends the second sub - information to the first blockchain through the inter - chain node, and the first blockchain updates the first sub - information based on the second sub - information.

14. An electronic device, characterized in that, it includes: a memory for storing instructions executed by one or more processors of the electronic device, and a processor for reading the instructions to execute the data processing method according to any one of claims 1 - 6.

15. A computer - readable storage medium including instructions, characterized in that, when the instructions are executed on an electronic device, the electronic device executes the data processing method according to any one of claims 1 - 6.

Images