C2B service data synchronization method and device, equipment, storage medium and program product

Abstract

The invention provides a C2B service data synchronization method and device, equipment, a storage medium and a program product. The method comprises the steps that first encrypted data uploaded by a first DAPP are received, and the first encrypted data are obtained by encrypting first C2B service data under the condition that the first DAPP obtains the first C2B service data; generating a block according to the first encrypted data under the condition that the first encrypted data is verified and the verification is passed; determining the sequence of the blocks according to a consensus algorithm so as to add the blocks into the block chain sub-chain; and broadcasting the block to other nodes in the block chain sub-chain, and storing the block on the block chain main chain. Thus, the block chain technology can be adopted, the first C2B service data is stored in the block, and rapid access and efficient synchronization of the data are achieved.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, and in particular relates to a C2B business data synchronization method, apparatus, device, storage medium and program product. Background Technology

[0002] Customer-to-business (C2B) business data is typically stored in relational databases. During business processing, timely synchronization of C2B business data is often required. Currently, to achieve C2B business data synchronization, the AEE process is generally used for periodic scanning and synchronization, which suffers from low synchronization efficiency. Summary of the Invention

[0003] This application provides a C2B business data synchronization method, apparatus, device, storage medium, and program product to solve the technical problem of low efficiency in C2B business data synchronization.

[0004] In a first aspect, embodiments of this application provide a C2B business data synchronization method, applied to the first node of a blockchain sub-chain, the method comprising:

[0005] Receive the first encrypted data uploaded by the first DAPP. The first encrypted data is obtained by the first DAPP encrypting the first C2B business data after obtaining the first C2B business data.

[0006] If the first encrypted data is verified and the verification is successful, a block is generated based on the first encrypted data;

[0007] The order of blocks is determined according to the consensus algorithm and added to the blockchain subchain;

[0008] The block is broadcast to other nodes in the blockchain subchain and stored on the blockchain main chain.

[0009] Secondly, embodiments of this application provide a C2B business data synchronization device, the device comprising:

[0010] The receiving module is used to receive the first encrypted data uploaded by the first DAPP. The first encrypted data is obtained by the first DAPP encrypting the first C2B business data after obtaining the first C2B business data.

[0011] A generation module is used to generate a block based on the first encrypted data if the verification of the first encrypted data is successful.

[0012] The module is used to determine the order of blocks according to the consensus algorithm so that they can be added to the blockchain subchain;

[0013] The synchronization module is used to broadcast blocks to other nodes in the blockchain subchain and store them on the blockchain main chain.

[0014] Thirdly, embodiments of this application provide a C2B business data synchronization device, the device comprising:

[0015] Processor and memory storing programs or instructions;

[0016] The processor implements the above methods when executing programs or instructions.

[0017] Fourthly, embodiments of this application provide a machine-readable storage medium storing a program or instructions that, when executed by a processor, implement the method described above.

[0018] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform the above-described method.

[0019] The C2B business data synchronization method, apparatus, device, storage medium, and program product of this application embodiment can receive first encrypted data uploaded by a first DAPP. The first encrypted data is obtained by the first DAPP encrypting the first C2B business data after obtaining it. Upon verification of the first encrypted data and successful verification, a block is generated based on the first encrypted data. The order of the blocks is determined according to a consensus algorithm and added to the blockchain sub-chain. The block is broadcast to other nodes in the blockchain sub-chain and stored on the blockchain main chain. In this way, blockchain technology can be used to store the first C2B business data in blocks, achieving fast data access and efficient synchronization. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating a C2B business data synchronization method provided in one embodiment of this application;

[0022] Figure 2 This is a schematic diagram of the structure of a C2B business data synchronization device provided in another embodiment of this application;

[0023] Figure 3 This is a schematic diagram of the structure of an electronic device provided in another embodiment of this application. Detailed Implementation

[0024] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0025] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0026] Furthermore, it should be noted that the acquisition, storage, use, and processing of data in the embodiments of this application all comply with the relevant provisions of national laws and regulations. It should also be noted that certain software, components, models, and other existing industry solutions may be mentioned in the embodiments of this application. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solution of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0027] To address the problems of the prior art, embodiments of this application provide a C2B business data synchronization method, apparatus, device, storage medium, and program product. The C2B business data synchronization method provided in this application embodiment is described below.

[0028] Figure 1 A flowchart illustrating a C2B business data synchronization method according to an embodiment of this application is shown. Figure 1 As shown, the C2B business data synchronization method may include the following steps:

[0029] Step 101: Receive the first encrypted data uploaded by the first DAPP. The first encrypted data is obtained by the first DAPP encrypting the first C2B business data after obtaining the first C2B business data.

[0030] Step 102: If the first encrypted data is verified and the verification is successful, a block is generated based on the first encrypted data;

[0031] Step 103: Determine the order of blocks according to the consensus algorithm to add them to the blockchain sub-chain;

[0032] Step 104: Broadcast the block to other nodes in the blockchain subchain and store it on the blockchain main chain.

[0033] The specific implementation methods of each of the above steps will be described in detail below.

[0034] In this embodiment, the C2B business data synchronization method can receive first encrypted data uploaded by a first DAPP. The first encrypted data is obtained by the first DAPP encrypting the first C2B business data after acquiring it. Upon successful verification of the first encrypted data, a block is generated based on the first encrypted data. The order of the blocks is determined according to a consensus algorithm and added to the blockchain sub-chain. The block is broadcast to other nodes in the blockchain sub-chain and stored on the blockchain main chain. In this way, blockchain technology can be used to store the first C2B business data in blocks, achieving fast data access and efficient synchronization.

[0035] The specific implementation methods for each of the above steps are described below.

[0036] In step 101, the first node of the blockchain subchain can receive the first encrypted data uploaded by the first DApp. For example, a business system can encrypt first C2B business data, such as order data or contract data, through the first DApp (i.e., the blockchain subchain uploader), generating first encrypted data and sending it to the first node in the blockchain subchain, so that the first node can receive the first encrypted data. The first node can be any node in the blockchain subchain.

[0037] In some embodiments, the first C2B business data is generated when a business event is triggered in the business system and uploaded to the first node through the first DAPP;

[0038] Alternatively, the business system uploads data to the first node via the first DAPP at preset time intervals.

[0039] In this embodiment, when a certain C2B business event in the business system is triggered, such as when a consumer completes a transaction or submits an order, the corresponding first C2B business data will be generated based on the business event and uploaded to the first node of the blockchain sub-chain.

[0040] Alternatively, a fixed time interval can be set, such as once per minute, to periodically upload the first C2B business data from the business system to the first node of the blockchain sub-chain.

[0041] Specifically, the corresponding synchronization driver method can be selected according to the actual business type, which increases the flexibility of data synchronization.

[0042] In some embodiments, the first encrypted data is obtained by performing symmetric or asymmetric encryption on the first C2B business data.

[0043] Understandably, symmetric encryption is more efficient but relatively less secure, while asymmetric encryption is more secure but relatively slower. Therefore, the appropriate encryption algorithm should be selected based on the type of business.

[0044] For example, asymmetric encryption can be used as an example to illustrate this. The first DAPP can use an encryption algorithm to perform a hash operation on the first C2B business data, and use its private key to encrypt the hash value to obtain the first encrypted data.

[0045] In step 102, the first node can verify the first encrypted data. For example, the first node can decrypt the first encrypted data using the same hash algorithm and the public key of the first DAPP, and compare the decrypted hash value with the calculated hash value to verify the legality and integrity of the data. After successful verification, the first node can package the first encrypted data into a block.

[0046] Therefore, to prevent data tampering, asymmetric encryption algorithms can be used to encrypt the first C2B business data, ensuring its integrity and authenticity. Simultaneously, the first node in the blockchain subchain needs to verify the submitted encrypted data to ensure its legitimacy.

[0047] In some embodiments, step 102 above may further include the following steps:

[0048] If the first encrypted data is verified and the verification is successful, the transaction corresponding to the first C2B business data is executed according to the first smart contract in the blockchain subchain to generate the second C2B business data.

[0049] The second C2B business data is encrypted to obtain the second encrypted data;

[0050] A block is generated based on the first encrypted data and the second encrypted data.

[0051] In this embodiment, it can be understood that the first smart contract is an automated contract executed on a blockchain sub-chain, responsible for verifying and executing transactions on the blockchain sub-chain and interacting with the blockchain sub-chain. In other words, the first smart contract in the blockchain sub-chain can automate the execution of transactions. When specific conditions are met, the first smart contract can automatically perform corresponding operations, such as generating orders and distributing rewards. The first smart contract can be customized according to business needs and implemented by writing smart contract code.

[0052] The first smart contract can store and manage data on a blockchain subchain. The smart contract can store the second C2B business data generated from transactions executed by the transaction server in a specific location on the blockchain subchain, such as the contract's storage space or event logs.

[0053] If the first encrypted data is successfully verified, the first smart contract can be triggered based on the first C2B business data. The first node can then execute corresponding transactions through the first smart contract. These transactions may include the business logic corresponding to the first C2B business data, as well as reading or modifying the data in the first smart contract.

[0054] Before a transaction is executed, the first node verifies it to ensure it complies with the rules and constraints of the first smart contract. This verification may include checking the transaction's signature, validating the legality of its inputs and outputs, and so on.

[0055] In a blockchain subchain, nodes need to reach a consensus to determine the validity and order of transactions. Therefore, common consensus algorithms, such as Proof of Work and Proof of Stake, can be used to ensure that all nodes agree on the state of transactions and data.

[0056] Once a transaction is verified and added to the blockchain subchain, the data in the first smart contract will be updated accordingly.

[0057] Understandably, to protect user privacy, anonymity technologies such as zero-knowledge proofs (ZKP) or ring signatures can be used to hide the participants and details of a transaction. At the same time, sensitive user information needs to be encrypted to ensure data privacy.

[0058] To prevent smart contract vulnerabilities, the first smart contract can undergo rigorous security audits and testing to ensure its logical correctness and security. Simultaneously, multi-signature technology can be employed, requiring multiple parties to confirm the operations performed on the first smart contract, thereby increasing its security.

[0059] After the transaction is completed, corresponding second C2B business data can be generated and encrypted to obtain second encrypted data. The first node can then package the first and second encrypted data into a single block.

[0060] In some embodiments, the second encrypted data is obtained by performing symmetric or asymmetric encryption on the second C2B business data.

[0061] Understandably, symmetric encryption is more efficient but relatively less secure, while asymmetric encryption is more secure but relatively slower. Therefore, the appropriate encryption algorithm should be selected based on the type of business.

[0062] For example, asymmetric encryption can be used as an example. The first node can use an encryption algorithm to perform a hash operation on the second C2B business data, and use the private key of the blockchain sub-chain to encrypt the hash value to obtain the second encrypted data.

[0063] This allows for the selection of appropriate encryption methods to protect data confidentiality, ensuring that only authorized users can decrypt and access the data. Encryption algorithms use keys to transform the data, preventing unauthorized users from accessing the original data content. This prevents unauthorized access and leakage of data, enhancing data security and privacy protection.

[0064] To prevent access bypass, a role-based access control (RBAC) model can be used to manage user roles and permissions, ensuring that only users with the appropriate permissions can access sensitive data.

[0065] In step 103, the order of blocks can be determined according to the consensus algorithm to add them to the blockchain sub-chain. The consensus algorithm suitable for large-scale networks and high transaction throughput can be used on the blockchain sub-chain, such as Proof of Work, Proof of Stake, Delegated Proof of Stake, and Proof of Authority. A suitable consensus algorithm can be selected based on the business type; for example, an optimized Delegated Proof of Stake consensus algorithm can be used to accelerate transaction confirmation.

[0066] The order of blocks can be determined by consensus algorithms such as Proof-of-Work, Proof-of-Stake, Delegated Proof-of-Stake, Proof-of-Utility, or Stake Voting, in order to add blocks to a blockchain subchain.

[0067] To prevent 51% attacks, a suitable consensus algorithm can be chosen, such as Proof-of-Stake or Proof-of-Work, to ensure the distribution of nodes and the decentralization of power. Simultaneously, a multi-node consensus algorithm can be employed to prevent malicious behavior by a single node from impacting the entire blockchain.

[0068] In step 104, the block can be broadcast to other nodes in the blockchain subchain. For example, after a block is added to the blockchain subchain by the first node, the first node will broadcast the block to other nodes to achieve network-wide data synchronization. All nodes in the blockchain subchain can use a consensus algorithm to determine the longest chain in the blockchain subchain, ensuring data consistency.

[0069] The first node can also submit blocks to a specific contract on the main blockchain or to on-chain storage.

[0070] In some embodiments, storing block broadcasts on the main blockchain may include:

[0071] Blocks can be stored on the blockchain main chain by invoking any one of the following: a second smart contract in the blockchain main chain, on-chain storage, cross-chain protocol, and data subscription.

[0072] For example, a blockchain subchain can submit data that needs to be synchronized to the main blockchain to the main blockchain to ensure data consistency and reliability. This means submitting blocks to a specific contract or on-chain storage on the main blockchain. This can be achieved in several ways:

[0073] a. Secondary Smart Contract: A blockchain subchain can package data that needs to be synchronized to the main blockchain into transactions and submit the data by calling a secondary smart contract on the main blockchain. The secondary smart contract on the main chain can define the data receiving and processing logic, ensuring data consistency and reliability.

[0074] b. On-chain storage: Blockchain subchains can store data that needs to be synchronized to the main blockchain in the main blockchain's on-chain storage. The on-chain storage on the main blockchain can be a specific contract used to store and manage data. Blockchain subchains can submit data to the on-chain storage so that the main blockchain can read and process it.

[0075] c. Cross-chain protocols: Cross-chain protocols are special protocols used for data interaction and communication between different blockchains. Blockchain sub-chains can use cross-chain protocols to synchronize data with the main blockchain. Cross-chain protocols can achieve data synchronization in the following ways:

[0076] 1) Cross-chain asset transfer: Cross-chain protocols allow users to transfer assets between different blockchains. This typically involves locking assets on one blockchain and generating corresponding cross-chain assets on another. Data synchronization is achieved by recording and verifying the state of asset transfers between the main blockchain and its sub-chains.

[0077] 2) Cross-chain data query and sharing: Cross-chain protocols enable the transfer and sharing of data between different blockchains. This is achieved by establishing specific communication channels between the main blockchain and its sub-chains. Data synchronization is achieved by sharing and synchronizing data between the main blockchain and its sub-chains.

[0078] 3) Cross-chain smart contracts: Cross-chain protocols allow smart contracts to be executed between different blockchains. This enables cross-chain contracts to access and manipulate data and resources on multiple blockchains. Data synchronization is achieved by executing smart contracts between the main blockchain and its sub-chains.

[0079] d. Data Subscription: Blockchain subchains can publish data to the main blockchain and notify the main blockchain of data updates through the main blockchain's subscription mechanism. The main blockchain can subscribe to events or state changes on subchains and synchronize data according to the subscribed content.

[0080] In some embodiments, the C2B business data synchronization method may further include:

[0081] Receive block download requests sent by the second DApp. The block download request is generated by the second DApp when it detects block changes in the blockchain sub-chain, verifies the block data, and the verification is successful.

[0082] In response to the block download request, the block is sent to the second DApp.

[0083] For example, the second DApp (i.e., the downloader of the blockchain sub-chain) can detect changes in the blocks of the blockchain sub-chain through a listening mechanism and proactively trigger data synchronization. At this time, the data in the block can be verified. For example, the public key of the first DApp can be used to verify the validity of the digital signature. That is, the data is decrypted using the public key of the first DApp using the same hash algorithm as the first DApp. The second DApp compares the decrypted hash value with the calculated hash value to verify the integrity and consistency of the data and ensure that the data has not been tampered with.

[0084] If the verification is successful, a block download request can be generated and sent to the blockchain sub-chain. The first node of the blockchain sub-chain can then respond to the block download request, send the block to the second DApp, and complete the block download.

[0085] The C2B business data synchronization method provided in this application uses blockchain technology to store C2B business data in blocks, enabling fast data access and efficient synchronization. Simultaneously, blockchain sub-chains can also achieve distributed data storage and sharing, avoiding duplicate data storage and transmission, and improving the utilization efficiency of C2B business data.

[0086] It also employs blockchain smart contract technology to automate the processing and verification of data synchronization tasks. A smart contract is a computer program that executes automatically and can process and verify data according to preset rules and conditions. By applying smart contracts, the processing and verification of data synchronization tasks can be automated, avoiding errors and delays in the data synchronization process and ensuring data consistency and security.

[0087] It also employs a distributed architecture and consensus algorithm to distribute data synchronization tasks to multiple nodes for processing, avoiding single points of failure and system bottlenecks, thereby improving the reliability and stability of C2B business data synchronization.

[0088] Based on the C2B business data synchronization method provided in the above embodiments, this application also provides a C2B business data synchronization device, namely, an embodiment of the first node of a blockchain sub-chain.

[0089] Figure 2 A schematic diagram of the structure of a C2B business data synchronization device provided in one embodiment of this application is shown. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0090] Reference Figure 2 The C2B business data synchronization device 200 may include:

[0091] The first receiving module 201 is used to receive the first encrypted data uploaded by the first DAPP. The first encrypted data is obtained by the first DAPP encrypting the first C2B business data after obtaining the first C2B business data.

[0092] The generation module 202 is used to generate a block based on the first encrypted data if the verification of the first encrypted data is successful.

[0093] Add module 203, which is used to determine the order of blocks according to the consensus algorithm and add them to the blockchain sub-chain;

[0094] Synchronization module 204 is used to broadcast blocks to other nodes in the blockchain subchain and store them on the blockchain main chain.

[0095] In some embodiments, the generation module 202 can also be used for:

[0096] If the first encrypted data is verified and the verification is successful, the transaction corresponding to the first C2B business data is executed according to the first smart contract in the blockchain subchain to generate the second C2B business data.

[0097] The second C2B business data is encrypted to obtain the second encrypted data;

[0098] A block is generated based on the first encrypted data and the second encrypted data.

[0099] In some embodiments, the first C2B business data is generated when a business event is triggered in the business system and uploaded to the first node through the first DAPP;

[0100] Alternatively, the business system uploads data to the first node via the first DAPP at preset time intervals.

[0101] In some embodiments, the synchronization module 204 can also be used for:

[0102] Blocks can be stored on the blockchain main chain by invoking any one of the following: a second smart contract in the blockchain main chain, on-chain storage, cross-chain protocol, and data subscription.

[0103] In some embodiments, the C2B business data synchronization device 200 may further include:

[0104] The second receiving module is used to receive the block download request sent by the second DAPP. The block download request is generated by the second DAPP when it detects a block change in the blockchain sub-chain, verifies the block data, and the verification is successful.

[0105] The sending module is used to send blocks to the second DAPP in response to block download requests.

[0106] In some embodiments, the first encrypted data is obtained by performing symmetric or asymmetric encryption on the first C2B business data;

[0107] The second encrypted data is obtained by performing symmetric or asymmetric encryption on the second C2B business data.

[0108] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. They are devices corresponding to the above-mentioned C2B business data synchronization method. All implementation methods in the above-mentioned method embodiments are applicable to the embodiments of this device. For details on its specific functions and the technical effects it brings, please refer to the method embodiment section. It will not be repeated here.

[0109] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0110] Figure 3 A schematic diagram of the hardware structure of an electronic device provided in yet another embodiment of this application is shown.

[0111] The device may include a processor 301 and a memory 302 storing programs or instructions.

[0112] When processor 301 executes the program, it implements the steps in any of the above method embodiments.

[0113] For example, the program can be divided into one or more modules / units, one or more of which are stored in memory 302 and executed by processor 301 to complete this application. The one or more modules / units can be a series of program instruction segments capable of performing a specific function, which describe the execution process of the program in the device.

[0114] Specifically, the processor 301 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0115] Memory 302 may include mass storage for data or instructions. For example, and not limitingly, memory 302 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 302 may include removable or non-removable (or fixed) media. Where appropriate, memory 302 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 302 is non-volatile solid-state memory.

[0116] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) machine-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0117] The processor 301 implements any of the methods described above by reading and executing programs or instructions stored in the memory 302.

[0118] In one example, the electronic device may also include a communication interface 303 and a bus 304. The processor 301, memory 302, and communication interface 303 are connected via the bus 304 and communicate with each other.

[0119] The communication interface 303 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0120] Bus 304 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 304 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0121] Furthermore, in conjunction with the methods in the above embodiments, this application embodiment can provide a machine-readable storage medium for implementation. This machine-readable storage medium stores a program or instructions; when executed by a processor, the program or instructions implement any of the methods in the above embodiments. This machine-readable storage medium can be read by a machine such as a computer.

[0122] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0123] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0124] This application provides a computer program product stored in a machine-readable storage medium. The program product is executed by at least one processor to implement the various processes of the above method embodiments and achieve the same technical effects. To avoid repetition, it will not be described again here.

[0125] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0126] The functional modules shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer grids such as the Internet, intranets, etc.

[0127] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0128] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by a computer program or instructions. These programs or instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0129] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A C2B business data synchronization method, characterized in that, The first node applied to a blockchain subchain includes: Receive first encrypted data uploaded by the first DAPP, wherein the first encrypted data is obtained by the first DAPP encrypting the first C2B business data after obtaining the first C2B business data; If the first encrypted data is verified and the verification is successful, a block is generated based on the first encrypted data; The order of the blocks is determined according to the consensus algorithm and added to the blockchain subchain; The block is broadcast to other nodes in the blockchain subchain and stored on the blockchain main chain.

2. The method according to claim 1, characterized in that, The step of generating a block based on the first encrypted data after verifying the first encrypted data and the verification is successful includes: If the first encrypted data is verified and the verification is successful, the transaction corresponding to the first C2B business data is executed according to the first smart contract in the blockchain sub-chain to generate the second C2B business data. The second C2B business data is encrypted to obtain the second encrypted data; A block is generated based on the first encrypted data and the second encrypted data.

3. The method according to claim 1, characterized in that, The first C2B business data is generated when a business event is triggered in the business system and uploaded to the first node through the first DAPP; Alternatively, the business system may upload data to the first node via the first DAPP at preset time intervals.

4. The method according to claim 1, characterized in that, Storing the blocks on the main blockchain includes: The block is stored on the blockchain main chain by invoking any one of the following: a second smart contract in the blockchain main chain, on-chain storage, cross-chain protocol, and data subscription.

5. The method according to claim 1, characterized in that, After broadcasting the block to other nodes in the blockchain sub-chain and storing it on the main blockchain, the method further includes: Receive a block download request sent by a second DApp. The block download request is generated by the second DApp when it detects a block change in the blockchain sub-chain, verifies the data of the block, and the verification is successful. In response to the block download request, the block is sent to the second DAPP.

6. The method according to claim 2, characterized in that, The first encrypted data is obtained by performing symmetric or asymmetric encryption on the first C2B business data; The second encrypted data is obtained by performing symmetric or asymmetric encryption on the second C2B business data.

7. A C2B business data synchronization device, characterized in that, The device includes: The first receiving module is used to receive the first encrypted data uploaded by the first DAPP. The first encrypted data is obtained by the first DAPP encrypting the first C2B business data after obtaining the first C2B business data. A generation module is used to generate a block based on the first encrypted data if the verification of the first encrypted data is successful. An add module is used to determine the order of the blocks according to the consensus algorithm so as to add them to the blockchain sub-chain; The synchronization module is used to broadcast the block to other nodes in the blockchain sub-chain and store it on the blockchain main chain.

8. An electronic device, characterized in that, The device includes: a processor and a memory storing programs or instructions; When the processor executes the program or instructions, it implements the method as described in claims 1-6.

9. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores a program or instructions that, when executed by a processor, implement the method as described in claims 1-6.

10. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device causes the electronic device to perform the method as described in claims 1-6.

Images