Blockchain-based data processing method, apparatus, device, and readable storage medium

Abstract

The application discloses a kind of data processing method, device and equipment based on blockchain and readable storage medium, method includes: super-light node receives the event service data sent by subscription node;Event service data includes the first transaction data corresponding to blockchain event, and the transaction verification data corresponding to first transaction data;Based on the block consensus data of latest block, first transaction data and transaction verification data, the accuracy of event service data is verified, and first verification result is obtained;Obtain the amount of data that super-light node should receive for blockchain event, based on the amount of data that should receive, the integrity of event service data is verified, and second verification result is obtained;When first verification result and second verification result are both verification pass result, event service data is stored and maintained processing.Adopting the present application, in the business of the synchronization and verification data of blockchain, transmission flow burden can be reduced, data storage pressure is relieved, and data verification efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data processing method, apparatus, device, and readable storage medium based on blockchain. Background Technology

[0002] With the rapid development of blockchain technology, many business systems now use blockchain to store relevant business data. Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. It is mainly used to organize data in chronological order and encrypt it into a ledger, making it tamper-proof and forgery-proof, while also enabling data verification, storage, and updating.

[0003] In a blockchain, there are different types of blockchain nodes. For example, a blockchain contains core nodes (i.e., consensus nodes) and lightweight nodes. Specifically, core nodes participate in verifying and broadcasting transaction data and block information, and they discover and maintain connections with other nodes. Core nodes contain the complete blockchain database, including all transaction data; core nodes can also be called full nodes. Lightweight nodes, on the other hand, only store a portion of the blockchain database. They typically only store block header information and transaction data associated with their own node, not the complete transaction data. They complete transaction verification through "Simplified Payment Verification (SPV)," so lightweight nodes can also be called SPV nodes.

[0004] In related technologies, lightweight nodes in blockchains need to synchronize a large number of block headers and related verification data from scratch during the data synchronization process, and then verify this large amount of data. This not only consumes a lot of transmission bandwidth but also wastes a lot of storage space. In addition, the large amount of data also affects the verification efficiency. In other words, in related technologies, lightweight nodes suffer from heavy transmission bandwidth burden, high storage pressure, and low verification efficiency when synchronizing verification data. Summary of the Invention

[0005] This application provides a data processing method, apparatus, device, and readable storage medium based on blockchain, which can reduce the burden of transmission traffic, alleviate data storage pressure, and improve data verification efficiency in the business of synchronizing and verifying data on the blockchain.

[0006] One embodiment of this application provides a blockchain-based data processing method, including:

[0007] The ultralight node receives event business data sent by the subscribing node; the subscribing node refers to a lightweight node in the business network that has an event subscription relationship with the ultralight node; the event business data refers to the data in the blockchain associated with the blockchain events subscribed to by the ultralight node; the event business data includes the first transaction data corresponding to the blockchain event, and the transaction verification data corresponding to the first transaction data; the event business data is obtained by the subscribing node from the consensus node in the consensus network; there is network isolation between the business network and the consensus network;

[0008] In the consensus service component used to maintain the consensus network, the block consensus data of the latest block in the blockchain is obtained. Based on the block consensus data of the latest block, the first transaction data, and the transaction verification data, the accuracy of the event business data is verified to obtain the first verification result.

[0009] In the index service component used to maintain the amount of data, the amount of data that the ultralight node should receive for a blockchain event is obtained, and the integrity of the event business data is verified based on the amount of data that should be received, to obtain a second verification result.

[0010] When both the first and second verification results are successful, the event business data will be stored and maintained.

[0011] One embodiment of this application provides a blockchain-based data processing device, including:

[0012] The data receiving module is used to receive event business data sent by the subscribing nodes. Subscribing nodes refer to lightweight nodes in the business network that have an event subscription relationship with the ultra-light nodes. Event business data refers to data in the blockchain associated with blockchain events subscribed to by the ultra-light nodes. Event business data includes the first transaction data corresponding to the blockchain event and the transaction verification data corresponding to the first transaction data. The event business data is obtained by the subscribing nodes from the consensus nodes in the consensus network. There is network isolation between the business network and the consensus network.

[0013] The consensus data acquisition module is used to acquire the latest block consensus data in the blockchain from the consensus service component used to maintain the consensus network.

[0014] The first data verification module is used to verify the accuracy of event business data based on the latest block consensus data, the first transaction data, and the transaction verification data, and obtain the first verification result.

[0015] The data acquisition module is used to acquire the amount of data that the ultralight node should receive for a blockchain event in the index service component used to maintain the data quantity.

[0016] The second data verification module is used to perform integrity verification on event business data based on the amount of data to be received, and obtain a second verification result.

[0017] The data storage module is used to store and maintain event business data when both the first and second verification results are successful.

[0018] In one embodiment, the blockchain-based data processing device may further include:

[0019] The registration request sending module is used to send an identity registration request carrying the public key of the ultralight node to the consensus nodes in the consensus network;

[0020] The subscription request generation module is used to receive the registration success message returned by the consensus node in the consensus network, and generate an event subscription request for the blockchain event based on the registration success message.

[0021] The request signature sending module is used to sign the event subscription request based on the private key of the ultralight node to obtain the first digital signature, and then send the event subscription request and the first digital signature to the subscription node.

[0022] The step execution module is used to execute the step of the ultralight node receiving the event business data sent by the subscription node when it receives the subscription success prompt message returned by the subscription node; the subscription success prompt message is generated by the subscription node verifying the first digital signature based on the public key of the ultralight node in the consensus network, and after the verification is successful.

[0023] In one embodiment, the first data verification module verifies the accuracy of event business data based on the latest block consensus data, the first transaction data, and transaction verification data to obtain the first verification result. Specific implementation methods include:

[0024] In the transaction verification data, the transaction block data of the transaction block to which the first transaction data belongs is obtained. Based on the first transaction data and the transaction block data, the existence of the first transaction data is verified to obtain the transaction verification result of the first transaction data.

[0025] Based on the latest block consensus data and transaction block data, the existence of the transaction block is verified to obtain the block verification result of the transaction block;

[0026] When both the transaction verification result and the block verification result are verified as passed, the verified result will be determined as the first verification result.

[0027] If the transaction verification result or the block verification result is a verification failure result, the verification failure result will be determined as the first verification result.

[0028] The transaction block data includes the transaction Merkle root of the transaction block, and the transaction Merkle path for the first transaction data; the transaction Merkle path includes the transaction hash value corresponding to the second transaction data; the block to which the second transaction data belongs is the transaction block;

[0029] In one embodiment, the specific implementation method of the first data verification module performing existence verification on the first transaction data based on the first transaction data and transaction block data to obtain the transaction verification result of the first transaction data includes:

[0030] The transaction hash value corresponding to the first transaction data is determined as the transaction hash value to be verified;

[0031] Based on the Merkle tree construction rules, the transaction hash value corresponding to the second transaction data contained in the transaction Merkle path is hashed with the transaction hash value to be verified to generate the Merkle root to be verified corresponding to the first transaction data.

[0032] Match the transaction Merkle root of the transaction block with the Merkle root to be verified;

[0033] If the transaction Merkle root and the Merkle root to be verified are successfully matched, the verification result will be determined as the transaction verification result of the first transaction data.

[0034] If the transaction Merkle root and the Merkle root to be verified are not matched, the verification failure result will be determined as the transaction verification result of the first transaction data.

[0035] In one embodiment, the transaction block data includes the Merkel mountain root of the predecessor block and the block hash value corresponding to the incremental block; the predecessor block refers to the block in the blockchain that is before the transaction block; the incremental block refers to the block in the blockchain whose block generation timestamp is later than the block generation timestamp of the transaction block.

[0036] The first data verification module, based on the latest block consensus data and transaction block data, performs existence verification on transaction blocks to obtain the block verification result. The specific implementation methods include:

[0037] The block hash value of the transaction block is determined as the hash value of the block to be verified;

[0038] Based on the construction rules of the Merkel mountain tree, the Merkel mountain root of the predecessor block, the hash value of the block to be verified, and the hash value of the block corresponding to the incremental block are hashed to generate the Merkel mountain root to be verified corresponding to the latest block.

[0039] In the consensus data of the latest block, obtain the real Merkel mountain root of the latest block, and match the unverified Merkel mountain root corresponding to the latest block with the real Merkel mountain root of the latest block;

[0040] If the Merkel mountain root to be verified corresponding to the latest block is matched with the real Merkel mountain root of the latest block, then the verification result will be determined as the block verification result of the transaction block.

[0041] If the Merkel mountain root to be verified corresponding to the latest block fails to match the actual Merkel mountain root of the latest block, then the verification failure result will be determined as the block verification result of the transaction block.

[0042] In one embodiment, the first data verification module, based on the construction rules of the Merkel mountain tree, performs hash calculations on the Merkel mountain root of the predecessor block, the hash value of the block to be verified, and the hash value of the block corresponding to the incremental block to generate the Merkel mountain root to be verified for the latest block. The specific implementation of this method includes:

[0043] Based on the construction rules of the Merkel mountain tree, the Merkel mountain root of the predecessor block and the hash value of the block to be verified are hashed to generate the Merkel mountain root corresponding to the transaction block.

[0044] The Merkel mountain root corresponding to the transaction block is hashed with the block hash value of the incremental block to generate the Merkel mountain root to be verified for the latest block.

[0045] In one embodiment, the first data verification module is further configured to obtain a second digital signature from the block consensus data of the latest block; the second digital signature is obtained by the block consensus node of the latest block signing the latest block based on the private key of the block consensus node;

[0046] The first data verification module is also used to obtain the public key of the block consensus node, and to verify the second digital signature based on the public key of the block consensus node, so as to obtain the verification result of the second digital signature.

[0047] The first data verification module is also used to execute the step of determining the verification result as the first verification result when the verification result of the second digital signature is a verification pass result.

[0048] In one embodiment, the number of blockchain events in the blockchain is one or more, and the amount of data to be received is the total number of events corresponding to one or more blockchain events;

[0049] The second data verification module performs integrity verification on the event business data based on the amount of data to be received, and obtains the second verification result through the following specific implementation methods:

[0050] Based on event business data, the number of blockchain events received by the ultralight node is counted, and the number of blockchain events received by the ultralight node is determined as the number of received events.

[0051] The number of received events is matched with the total number of events, and the second verification result is determined based on the matching result between the number of received events and the total number of events.

[0052] In one embodiment, the second data verification module determines the specific implementation method of the second verification result based on the matching result between the number of received events and the total number of events, including:

[0053] If the matching result between the number of received events and the total number of events is that the number of received events equals the total number of events, then the verification result is determined as the second verification result.

[0054] If the matching result between the number of received events and the total number of events is that the number of received events is less than the total number of events, then the ultralight node is determined as the receiving differential node, and the verification failure result is determined as the second verification result.

[0055] If the matching result between the number of received events and the total number of events is that the number of received events is greater than the total number of events, then the ultralight node is identified as a node that receives an excessive amount of events, and the verification failure result is identified as the second verification result.

[0056] In one embodiment, after determining the ultralight node as a receiving differential node, the second data verification module is further configured to determine the blockchain events already received by the ultralight node as received blockchain events of the ultralight node.

[0057] Among one or more blockchain events, those other than the blockchain events that have been received are identified as blockchain events that have not been received.

[0058] Based on the unreceived blockchain event, an event supplement retrieval request is generated and sent to the subscribing node. The subscribing node then retrieves the unreceived event business data associated with the unreceived blockchain event from the consensus node of the consensus network based on the event supplement retrieval request, and returns the unreceived event business data to the ultralight node.

[0059] In one embodiment, the number of blockchain events received by the ultralight node is M; M are positive integers.

[0060] After identifying the ultralight node as a receiving super-quantity node, the second data verification module is also used to identify all M received blockchain events as received blockchain events, and to identify the set of the M received blockchain events as the first event set.

[0061] Define the set of one or more blockchain events as the second event set;

[0062] The intersection of the first event set and the second event set is obtained;

[0063] The received blockchain events in the first event set, excluding the intersection set, are identified as blockchain events to be cleared, and the received event business data associated with the blockchain events to be cleared are cleared.

[0064] One embodiment of this application provides a computer device, including: a processor and a memory;

[0065] The memory stores a computer program, which, when executed by a processor, causes the processor to perform the methods described in the embodiments of this application.

[0066] One aspect of this application provides a computer-readable storage medium storing a computer program, which includes program instructions. When executed by a processor, the program instructions perform the methods described in this application.

[0067] One aspect of this application provides a computer program product comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the method provided in one aspect of the embodiments of this application.

[0068] In this embodiment, ultra-light node technology is introduced into the layered blockchain technology. An event subscription relationship is established between the ultra-light node and lightweight nodes in the business network. This event subscription relationship allows the ultra-light node to synchronously obtain relevant event business data of blockchain events from the lightweight node. That is, the ultra-light node can synchronize and store only data related to blockchain events, rather than data based on the entire transaction or a large number of related blocks. This significantly reduces the data storage space and transmission traffic of the ultra-light node during data synchronization. Furthermore, this application adds a consensus service component for maintaining the consensus network and an index service component for maintaining the data quantity in the consensus network. Based on these two components, fast and accurate verification can be performed without obtaining all historical blocks and block headers to verify the accuracy and completeness of the event business data received by the ultra-light node, thereby significantly improving verification efficiency. In summary, this application can reduce the transmission traffic burden, alleviate data storage pressure, and improve data verification efficiency in the business of synchronizing and verifying blockchain data. Attached Figure Description

[0069] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0070] Figure 1 This is a schematic diagram of the application environment of a method provided in an embodiment of this application;

[0071] Figure 2 This is a schematic diagram of the architecture of a blockchain network provided in an embodiment of this application;

[0072] Figure 3 This is a schematic diagram of the architecture for applying a blockchain network to electronic invoice scenarios;

[0073] Figure 4 This is a schematic diagram of a layered blockchain architecture that incorporates an ultralight node cluster, provided in an embodiment of this application.

[0074] Figure 5 This is a flowchart of a data processing method based on blockchain provided in an embodiment of this application;

[0075] Figure 6 This is a schematic diagram illustrating the construction of the Merkel Mountains, provided in an embodiment of this application;

[0076] Figure 7 This is a schematic diagram illustrating the process of an ultralight node verifying the accuracy of event business data, provided in an embodiment of this application.

[0077] Figure 8 This is a schematic diagram illustrating the process of an ultralight node performing integrity verification on event business data, provided in an embodiment of this application.

[0078] Figure 9 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of this application;

[0079] Figure 10 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0080] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0081] Please see Figure 1 , Figure 1 This is a schematic diagram illustrating the application environment of a method provided in an embodiment of this application. For example... Figure 1 As shown, the blockchain-based data processing method provided in this application can be applied to a blockchain network 100. A blockchain network comprises a network of nodes that record and query data blocks on the blockchain. Each node in the blockchain network is a blockchain node, a computer device capable of querying or recording data blocks. For example... Figure 1 As shown, the blockchain network 100 may include a business network 1100, a routing layer 1200, and a consensus network 1300. Business nodes 1102 in the business network 1100 and routing nodes 1202 in the routing layer 120 are connected via a network. Routing node 1202 and consensus node 1302 in the consensus network 1300 are also connected via a network. Therefore, communication between the business network 1100 and the consensus network 1300 requires the use of routing node 1202.

[0082] Business node 1102 can specifically be a desktop or mobile terminal used by the business party generating transaction information. Mobile terminals can be smartphones, tablets, laptops, desktop computers, smart TVs, smart speakers, smartwatches, in-vehicle terminals, or other smart terminals with data processing capabilities, but are not limited to these. Routing node 1202 can be implemented using a standalone server or a server cluster composed of multiple servers. Consensus node 1302 in the consensus network 1300 can record the transaction information (transaction data) generated by the business nodes onto the blockchain. Consensus node 1302 can be implemented using a standalone server or a server cluster composed of multiple servers. Each consensus node in the consensus network 1300 can be authorized and set up by an authoritative institution. For example, when the consensus network 1300 is applied to processing electronic invoice data, the consensus nodes in the consensus network 1300 can typically be authorized and set up by a regulatory agency.

[0083] Blockchain is the carrier and organizational method for running blockchain technology. Blockchain technology (BT), also known as distributed ledger technology, is an internet database technology characterized by decentralization and transparency, allowing everyone to participate in database recording. Blockchain technology utilizes a block-chain data structure to verify and store data, distributed node consensus algorithms to generate and update data, cryptography to ensure the security of data transmission and access, and smart contracts composed of automated script code to program and manipulate data—a distributed infrastructure and computing method.

[0084] To facilitate understanding, the following will explain blockchain and related concepts:

[0085] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. It is primarily used to organize data chronologically and encrypt it into a ledger, making it tamper-proof and forgery-proof. It also allows for data verification, storage, and updating. Essentially, a blockchain is a decentralized database where each node stores an identical blockchain record. The blockchain network classifies nodes into core nodes, data nodes, and light nodes. Core nodes are responsible for the consensus of the entire blockchain network; in other words, they are the consensus nodes. The process of a consensus node entering the consensus process can be as follows: a client sends transaction data to a data node or light node. This transaction data is then relayed among the data nodes or light nodes in the blockchain network until the consensus node receives the transaction data. The consensus node then packages the transaction data into a block and performs consensus with other consensus nodes.

[0086] After receiving transaction data from a data node or light node, any core node can store the transaction data in a memory pool (such as a transaction pool) and update its hash tree used to record input data. Then, it updates the timestamp to the time the transaction data was received and attempts to calculate a feature value using different random numbers. When a feature value is obtained, it is determined that the core node that obtained the feature value has won the block creation permission for that transaction data. The core node can then store the transaction data, generate a block header and block body, and obtain a newly generated block. Subsequently, the core node can send the newly generated block to other core nodes in its blockchain network based on the node identifiers of other core nodes (i.e., consensus nodes). These other core nodes will verify the newly generated block (i.e., reach consensus) and, after verification, add the newly generated block to their stored blockchain. Each core node in the blockchain network has its own corresponding node identifier, and each core node can store the node identifiers of other core nodes in the blockchain network. This allows the generated blocks to be broadcast to other core nodes in the blockchain network based on the node identifiers of other core nodes, ensuring that the transaction data stored on all core nodes in the blockchain network is consistent.

[0087] To facilitate understanding the architecture of the blockchain network in this application, please also refer to... Figure 2 , Figure 2 This is a schematic diagram of a blockchain network architecture provided in an embodiment of this application. Figure 2As shown, the blockchain network may include a business network 2100, a routing layer 2200, and a consensus network 2300. The business network 2100 may include business nodes 2101 (which can verify data blocks recorded on the blockchain by consensus nodes), and the consensus network 2300 may include consensus nodes 2301 that record data blocks on the blockchain. The business network 2100 and the consensus network 2300 can be connected via the routing layer 2200. Routing nodes 2201 in the routing layer 2200 can transmit data processing requests sent by business nodes 2101 to consensus nodes 2301. Routing nodes 2201 can also forward transaction information (such as execution results for transaction data) obtained from consensus nodes 2301 to business nodes 2101. Business nodes 2101 are deployed in the public business network, while consensus nodes 2301, which run the blockchain consensus protocol, are deployed in a private consensus network. The two can interact through routing nodes (such as routing node 2201). Router node 2201 serves to isolate the business network 2100 from the core consensus network 2300. In the business network 2100, each business node is peer-to-peer (P2P) with the P2P protocol being an application layer protocol running on top of the Transmission Control Protocol (TCP). Business node 2101 can forward messages received from router node 2201 to surrounding business nodes, enabling the message to propagate among all business nodes in the business network.

[0088] To facilitate understanding of the application scenarios of the aforementioned blockchain network, the following will use the application of a blockchain network in an electronic invoice scenario as an example to illustrate the specific scenario architecture. Please refer to [link / reference needed]. Figure 3 , Figure 3 This is a schematic diagram of the architecture for applying blockchain networks to electronic invoice scenarios.

[0089] When the above Figure 2 When the blockchain network shown is applied to the scenario of electronic invoices, it can record transaction information generated throughout the entire circulation process of the electronic invoice. For example... Figure 3 As shown, the blockchain network may include a business network 3200, a routing layer 3400, and a consensus network 3600.

[0090] The circulation process of electronic invoices can include the application, issuance, reimbursement, and tax filing of electronic invoices. The issuance of electronic invoices can also be referred to as the generation of electronic invoices. Since the entire circulation process involves regulatory agencies, the invoicing party, the reimbursing party, and the tax filing party, the business network 3200 may include a dedicated regulatory network 3201 providing related services, a public cloud 3202 providing related services to the invoicing party, the reimbursing party, and the tax filing party, and a private cloud 3203 providing electronic invoice storage services for consumers. The dedicated regulatory network 3201 may include the computer equipment used by the regulatory agencies involved in the electronic invoices, including regulatory agency terminals 32011. The public cloud 3202 may include the computer equipment used by the invoicing party, the reimbursement party, and the tax filing party in connection with the electronic invoice, including invoicing party terminal 32021, reimbursement party terminal 32022, and tax filing party terminal 32023. The invoicing party can be an invoicing service provider, the reimbursement party can be a reimbursement service provider, and the enterprise terminals can access the public cloud. The private cloud 3203 may include the computer equipment used by the users involved in the electronic invoice, including payment terminal 32031 for payment, electronic invoice circulation terminal 32032 for temporarily storing electronic invoices for users, and enterprise-specific terminals 32033. Consumer terminals can access the private cloud. The computer equipment in the regulatory agency's private network 3201, the public cloud 3202, and the private cloud 3202 can all act as business nodes, sending data upload requests or data query requests for electronic invoices to the consensus network through routing nodes.

[0091] Any routing node in the routing layer 3400 may include functional modules that provide authentication service 3401, certificate caching 3402, routing service 3403, and P2P service 3404. Authentication service 3401 can be used to authenticate business nodes in the business network; certificate caching 3402 can be used to cache the identity certificates of each business node; routing service 3403 can be used to implement network isolation between the business network and the consensus network; and the P2P server can be used to allocate tasks among routing nodes with idempotency. The routing nodes form a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol that runs on top of the TCP protocol.

[0092] The consensus network 3600 may include multiple consensus branch networks 360, and each consensus branch network 360 may include multiple consensus nodes 3601. These consensus nodes 3601 maintain the sub-blockchains corresponding to their respective consensus branch network 360. For example, some sub-blockchains are used to record transaction information related to electronic bills belonging to a certain bill number range, while others are used to record transaction information related to overdue electronic bills. When it is necessary to record data related to electronic bills, the sub-blockchain to be recorded can be determined according to the permissions of the business nodes, and then the consensus branch network maintaining that sub-blockchain will record it. Consensus nodes 3601 are typically computer devices used by regulatory agencies in various regions. The consensus nodes 3601 in each consensus branch network 360 may include permission contracts, which store the flow logic of the entire lifecycle of electronic bills, such as the bill status, flow process, data access permissions, electronic bill application conditions, and electronic bill issuance conditions. Consensus nodes 3601 may also include caches and data blocks, which can support the on-chaining and querying of transaction information.

[0093] Understandably, the business nodes in the aforementioned business network 2100 (such as business node 2101) can also be called lightweight nodes or SPV nodes. Lightweight nodes only store a portion of the blockchain database, generally only storing block header information and transaction data associated with their own node, without storing complete transaction data. They complete transaction verification through "Simplified Payment Verification (SPV)". Typically, lightweight nodes need to synchronize the transaction data associated with their own node and related block header information from the blockchain, verify them, and store them locally after successful verification. To save node storage space, reduce transmission traffic burden, and improve data verification efficiency in the business of synchronizing and verifying data on blockchain SPV nodes, this application introduces ultra-light node technology. Ultra-light nodes synchronize and store data based on blockchain events (objects (such as users) generate various events when using the blockchain, for example: after network consensus is reached, a new block is generated; block generation can be considered a blockchain event; another example is when an object initiates a transaction and it is written to the ledger; the event of this transaction being written to the ledger can also be considered a blockchain event; yet another example is when an object calls a function of a smart contract and executes a specific operation; the contract call execution...). The execution of a specific operation can also serve as a blockchain event. These events are of significant value to external business systems, which can process and refine them, feeding the results back into actual business operations. For example, specific events can be used to monitor changes in the balance of a particular account on the blockchain, or to monitor network block production and transaction rates. This allows for the storage of less data by ultralight nodes, and the data stored by different ultralight nodes can constitute the relevant business data for all blockchain events.

[0094] In other words, the aforementioned architecture and system process form the basic framework of this application. Based on this, this application introduces an additional ultra-light node cluster into the business network. Each ultra-light node in the cluster can subscribe to a specific business node in the business network, which then synchronously provides the ultra-light node with business data (i.e., event business data) for a specific blockchain event. Upon receiving event business data for a blockchain event, the ultra-light node can verify the data. This verification includes accuracy and completeness checks, ensuring that the event business data received by the ultra-light node is complete and accurate. After both accuracy and completeness verifications pass, the ultra-light node can store the event business data locally for data maintenance and processing. For ease of understanding, please refer to [further details omitted]. Figure 4, Figure 4 This is a schematic diagram of a layered blockchain architecture that introduces an ultralight node cluster, as provided in an embodiment of this application.

[0095] like Figure 4 As shown, the architecture may include a consensus network 4100, a business network 4200, an ultra-light node cluster 4300, and service components (specifically, consensus service components and index service components) for providing services and maintenance to the consensus network 4100. The consensus network 4100 may refer to the aforementioned... Figure 2 The consensus network 2300 and service network 4200 in the corresponding embodiments may refer to the above-mentioned Figure 2 The corresponding embodiment includes a service network 2100. The consensus network 4100 contains multiple different consensus nodes (e.g., consensus node 4102), and the service network 4200 contains multiple different service nodes (e.g., service node 4201). The service nodes in the service network 4200 can refer to lightweight nodes (or SPV nodes). The ultra-lightweight node cluster 4300 contains multiple different ultra-lightweight nodes (e.g., ultra-lightweight node 4301), where an ultra-lightweight node can refer to an SPV node that is even lighter than a lightweight node (SPV node). It should be understood that communication between the consensus network 4100 and the service network 4200 can be established through a routing node.

[0096] Understandably, in situations like Figure 4 In the illustrated architecture, any ultralight node in the ultralight node cluster can subscribe to a blockchain event from a business node in the business network 4200. By subscribing to a blockchain event, the ultralight node can designate that business node as its own subscriber node, establishing an event subscription relationship between them. Subsequently, the subscriber node can obtain the business data (referred to as event business data) associated with the blockchain event subscribed to by the ultralight node from the corresponding consensus node in the consensus network 4100. The subscriber node can then send the event business data to the ultralight node, which can then store and maintain this data. To ensure the integrity and accuracy of the event business data sent by the subscriber node, the ultralight node can perform integrity and accuracy verification on the event business data. Only when both the integrity and accuracy verifications pass can the event business data be stored and maintained.

[0097] In particular, when ultra-light nodes perform integrity and accuracy verification on event business data, they can leverage technologies such as... Figure 4The service components shown are used for verification. Specifically, these service components include a consensus service component and an index service component. The consensus service component can refer to the publicly available Quorumcert address table service component (referred to as the QC service component). This QC service component can be maintained by the consensus network 4100 (in other words, the QC service component can be used to record and store relevant data in the consensus network 4100). For example, the QC service component can provide the current node status (such as whether it is running normally) and historical status of each consensus node in the consensus network 4100. The QC service component can be used to record the consensus nodes participating in the consensus of each block in the blockchain, and it can also be used to record the consensus nodes added or removed during each consensus process. For example, for block 1, the consensus nodes participating in the consensus include all consensus nodes in the consensus network 4100, so the QC service component can record this. For the next block after block 1 (such as block 2), if consensus node 4102 withdraws from the consensus process for block 2, the QC service component will also record this (consensus node 4102 is not among the consensus nodes participating in block 2). Similarly, for the next block after block 2 (such as block 3), if consensus node 4102 joins the consensus process for block 3, the QC service component will also record this (all consensus nodes participate in the consensus for block 3). In other words, the QC service component can obtain which consensus nodes participated in the consensus for a given block at any block height. That is, in the blockchain, blocks that are generated and pass consensus are added to the chain, and for each added block, the QC service component records the relevant consensus data for that block (such as which consensus nodes participated in the block's consensus, etc.). The ultralight node can verify the accuracy of the event business data it receives by using the data recorded by this QC service component.

[0098] The indexing service component can be used to count the number of a certain blockchain event contained in blocks at each block height. For example, taking the blockchain event "Smart Contract A is called" as an example, in block A indicated by block height 1 (i.e., the first block in the blockchain), the blockchain event "Smart Contract A is called" exists 3 times (i.e., the event "Smart Contract A is called" has occurred 3 times), so the number of blockchain events "Smart Contract A is called" contained in block A can be 3. As another example, in block K indicated by block height 10 (i.e., the 10th block in the blockchain), the blockchain event "Smart Contract A is called" exists 2 times (i.e., the event "Smart Contract A is called" has occurred 2 times), so the number of blockchain events "Smart Contract A is called" contained in block K can be 2. It should be understood that, assuming a light node subscribes to the blockchain event "Smart Contract A is invoked" from a subscribing node, then the light node should receive all associated data for that blockchain event contained in each block of the blockchain (i.e., the event business data corresponding to the three blockchain events in block A, and the event business data corresponding to the two blockchain events in block K). Through the data maintained in this index service component, the light node can verify the completeness of the event business data it receives.

[0099] In summary, this application introduces ultra-light node technology into a layered blockchain. Through event subscription technology, ultra-light nodes can subscribe to and synchronize only business data based on blockchain events. This saves bandwidth during data transmission and reduces the storage pressure on nodes. Furthermore, this application adds public QC services and public indexing services to the consensus network. Based on these two public services, ultra-light nodes can perform rapid, small-scale verification of acquired event-based business data without retrieving relevant historical blocks and block headers, thereby improving data verification efficiency. When ultra-light nodes have relatively small data storage requirements and low transmission power needs, embedding them into terminal devices (such as smartphones) also becomes possible.

[0100] It should be noted that, in the specific embodiments of this application, data involving user information and user data (such as transaction information related to electronic bills within a certain bill number range, data related to electronic bills, and uploaded transaction information) are all collected only after the user's manual authorization (i.e., with the user's informed consent or separate consent). In other words, when the above embodiments of this application are applied to specific products or technologies, the methods and related functions provided by the embodiments of this application operate with the user's permission or consent (the user can actively activate the functions provided by the embodiments of this application), and the collection, use, and processing of related data must strictly comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0101] Furthermore, for ease of understanding, please also refer to Figure 5 , Figure 5 This is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application. The data processing method introduces ultra-light node technology into a blockchain network, where ultra-light nodes store and maintain event business data based on blockchain events. The blockchain network may include a business network and a consensus network (such as...). Figure 4 The consensus network shown above, and the routing layer used to isolate the service network from the consensus network. The following will apply the method to the above. Figure 4 The ultralight node in the corresponding embodiment (e.g., ultralight node 4301 is used as an example) is illustrated below. Figure 5 As shown, the blockchain-based data processing method may include the following steps S101-S104:

[0102] Step S101: The ultralight node receives event business data sent by the subscribing node; the subscribing node refers to a lightweight node in the business network that has an event subscription relationship with the ultralight node; the event business data refers to the data in the blockchain associated with the blockchain event subscribed to by the ultralight node; the event business data includes the first transaction data corresponding to the blockchain event, and the transaction verification data corresponding to the first transaction data; the event business data is obtained by the subscribing node from the consensus node in the consensus network; there is network isolation between the business network and the consensus network.

[0103] In this application, different blockchain nodes exist within the blockchain. For a particular type of blockchain node, it only stores block header information and transaction data associated with itself, without storing complete transaction data. Compared to a full node that stores all data in the blockchain database, this type of blockchain node, storing only a portion of the data, is more lightweight and is thus considered a lightweight node in the blockchain. The ultra-lightweight node mentioned in this application can refer to a blockchain node that is even lighter than a lightweight node. An ultra-lightweight node can synchronously store only business data based on blockchain events, resulting in even lighter data storage. Here, a blockchain event can refer to a specific event occurring within the blockchain. When an object uses the blockchain, it generates various events, each of which can be considered a blockchain event. For example, after network consensus is reached, a new block is generated; block generation can be considered a blockchain event. Similarly, when an object initiates a transaction and it is written to the ledger, the event of that transaction being written to the ledger can also be considered a blockchain event. Furthermore, when an object calls a function of a smart contract and executes a specific operation, the event of the contract calling and executing that operation can also be considered a blockchain event. It should be understood that these blockchain events have significant value to external business systems. These systems can process and analyze these events, feeding the results back into their actual business operations. For example, they can subscribe to specific events (such as account crediting events) to monitor changes in the balance of a particular account on the blockchain; or they can use specific events (such as block generation events) to monitor the network's block production and transaction rates.

[0104] Specifically, the blockchain network in this application can refer to a layered blockchain network comprising a business network, a consensus network, and a layered blockchain network used to isolate the business network from the consensus network. In other words, there is network isolation between the business network and the consensus network in this layered blockchain network. The business network contains different business nodes, each of which can be understood as a lightweight node (SPV node), and the consensus network contains different consensus nodes. In this layered blockchain network, a super-lightweight node can subscribe to events from the lightweight nodes in the business network. Through event subscription, the lightweight node in the business network can act as a subscriber node for the super-lightweight node. Subsequently, it can obtain the event business data of the blockchain events subscribed to by the super-lightweight node from the consensus nodes in the consensus network and synchronously send the event business data to the super-lightweight node. In other words, a super-lightweight node can establish an event subscription relationship with a lightweight node in the business network through event subscription, and the lightweight node can send event business data associated with the blockchain events it has subscribed to to the super-lightweight node through this event subscription relationship.

[0105] It should be noted that, in order to improve the security of the transmitted data, before establishing an event subscription relationship with an ultralight node, the lightweight node can first verify the identity of the ultralight node to confirm its legitimacy. Only after confirming the legitimacy of the ultralight node's identity can the lightweight node establish an event subscription relationship with it; otherwise, the lightweight node can refuse to establish an event subscription relationship with the ultralight node.

[0106] Specifically, a light node can first send an identity registration request carrying its public key to a consensus node in the consensus network. The consensus node can then register the light node's identity (i.e., register its public key and other information) based on this request. After registration is complete, the consensus node can return a registration success message to the light node. The light node can receive this success message from the consensus node and generate an event subscription request for a blockchain event. Further, the light node can sign the event subscription request using its private key, thus obtaining a digital signature (which may be referred to as the first digital signature for clarity). Subsequently, the light node can combine the event subscription request with the first digital signature... A digital signature is sent to the subscribing node (i.e., a lightweight node before establishing an event subscription relationship). Based on the event subscription request, the lightweight node can verify the first digital signature using the public key of an ultra-light node registered in the consensus network. After successful verification, the lightweight node can establish an event subscription relationship based on blockchain events with the ultra-light node and act as the ultra-light node's subscribing node. Subsequently, the subscribing node can generate a subscription success message and return it to the ultra-light node. Upon receiving the subscription success message from the subscribing node, the ultra-light node can execute the steps of receiving event business data sent by the subscribing node. The subscription success message is generated by the subscribing node after verifying the first digital signature using the public key of the ultra-light node in the consensus network.

[0107] It's understandable that each blockchain event corresponds to different transaction data. A blockchain event can be understood as an event generated by executing related operations within the transaction data. For example, taking the transaction data as transferring 5 units from account A to account B, the operations for this transaction data could at least include calling smart contract A to deduct 5 units from account A's balance and calling smart contract A to add 5 units to account B's balance. Therefore, the blockchain event generated by this transaction data would at least include the event of smart contract A being called, the event of account A's balance changing, and the event of account B's balance changing. Therefore, for the event business data returned by the subscription node to the ultra-light node, in addition to containing the blockchain event itself, it can also contain the transaction data corresponding to that blockchain event. Furthermore, it's understandable that for each transaction data, the ultra-light node needs to verify its existence in the blockchain. Therefore, the event business data returned by the subscription node to the ultra-light node also needs to contain transaction verification data for the ultra-light node to verify the transaction data. In other words, the event business data received by the ultralight node from the subscribing node may include the transaction data corresponding to the blockchain event (which can be referred to as the first transaction data for easy distinction from the following), and the transaction verification data corresponding to the first transaction data.

[0108] Step S102: In the consensus service component used to maintain the consensus network, the block consensus data of the latest block in the blockchain is obtained. Based on the block consensus data of the latest block, the first transaction data, and the transaction verification data, the accuracy of the event business data is verified to obtain the first verification result.

[0109] In this application, the consensus service component can refer to the publicly available Quorumcert address table service component (referred to as the QC service component). This QC service component can be maintained by the consensus network (in other words, the QC service component can be used to record and store relevant data in the consensus network). For example, the QC service component can provide the current node status (such as whether it is running normally) and historical status of each consensus node in the consensus network. The QC service component can be used to record the consensus nodes participating in the consensus of each block in the blockchain, and can also be used to record the consensus nodes added or removed during each consensus process. For example, for block 1, the consensus nodes participating in the consensus include all consensus nodes in the consensus network, so the QC service component can record this. For the next block after block 1 (such as block 2), if consensus node 4102 withdraws from the consensus process for block 2, the QC service component will also record this (consensus node 4102 is not among the consensus nodes participating in block 2). Similarly, for the next block after block 2 (such as block 3), if consensus node 4102 joins the consensus process for block 3, the QC service component will also record this (consensus nodes participating in the consensus for block 3 include all consensus nodes). In other words, the QC service component can obtain which consensus nodes participate in the consensus for a given block at any block height.

[0110] It should be understood that for each block, after consensus is reached by consensus nodes, it can be generated and added to the blockchain. In this application, the Merkle Mountain Ranges (MMR) can be constructed to record and store the generation and addition of each block in the blockchain. When a consensus is reached and a block is generated, the existing Merkle Mountain Ranges can be updated based on the newly added block, resulting in a new Merkle Mountain Range. The root of this Merkle Mountain Range (i.e., the MMR root) will also be updated accordingly. In this application, the MMR root updated based on the newly added block can be signed by the consensus nodes participating in the consensus. The QC service component can record and store the MMR root corresponding to the latest block (the block with the latest generation timestamp in the blockchain) and the digital signature obtained after the consensus nodes participating in the consensus have signed it (to distinguish it from the first digital signature mentioned above, it can be referred to as the second digital signature). It should be understood that the MMR root of the block stored by the QC service component and the digital signatures of the consensus nodes participating in the consensus can be referred to as the block consensus data of the block in this application. It should be understood that by adding a public QC service component to the consensus network, this application enables ultra-light nodes to verify the accuracy of event business data based on the latest block consensus data, the first transaction data sent by the subscribing node, and the corresponding transaction verification data recorded in the QC service component. This results in a verification result (referred to as the first verification result), ensuring the accuracy of the event business data received by the ultra-light nodes. For a detailed explanation of how ultra-light nodes verify the accuracy of event business data based on the latest block consensus data, the first transaction data, and the transaction verification data to obtain the first verification result, please refer to the subsequent sections. Figure 7 The description in the corresponding embodiments.

[0111] For a better understanding of the Merkel Mountains (MMR), please also refer to... Figure 6 , Figure 6 This is a schematic diagram illustrating the construction of a Merkel tree according to an embodiment of this application. The difference between an MMR and a Merkel binary tree is that when a new block (a new leaf node) arrives, the value of intermediate nodes does not need to be changed; nodes are always appended. Constructing an MMR tree does not require additional data structure support; it only requires adding the address of the previous root to each block. Taking block 0 as the genesis block (the block with the earliest generated timestamp in the blockchain) as an example... Figure 6As shown, based on block 0 and block 1, a Merkel mountain range 6101 can be constructed. In this Merkel mountain range 6101, the root is Root1, which can be understood as the root of the Merkel mountain range corresponding to block 1. Furthermore, when adding block 2, it can be directly constructed based on the root of the Merkel mountain range corresponding to block 1 (Root1) and the hash value of block 2, as shown below. Figure 6 The Merkel mountain range 6102 shown here has its root as Root2. This Root2 can be understood as the root of the Merkel mountain range corresponding to block 2. Furthermore, when adding block 3, it can be directly constructed based on the root of the Merkel mountain range Root2 corresponding to block 2 and the hash value of block 3, as shown below. Figure 6 The Merkel mountain range 6103 shown in the figure has a root of Root3, which can be understood as the root of the Merkel mountain range corresponding to block 3.

[0112] It's understandable that Root1, Root2, and Root3 mentioned above are simply the roots of MMR at different points in time. This is a characteristic of MMR: the root of the latest block can cover all nodes, and the address of the corresponding root does not need to be changed once a block is created. By quickly obtaining the MMR root of the latest block from the public Quorumcert address table service, ultralight nodes can quickly verify whether a block is included in MMR. If the block is included in MMR, it can be confirmed that the block exists in the blockchain, and thus, it can be confirmed that a certain transaction data exists in the blockchain.

[0113] Step S103: In the index service component used to maintain the amount of data, obtain the amount of data that the ultralight node should receive for the blockchain event, and perform integrity verification on the event business data based on the amount of data that should be received to obtain the second verification result.

[0114] In this application, the index service component can refer to a service component used to count the number of a certain blockchain event contained in blocks at each block height. For example, taking the blockchain event "Smart Contract A is called" as an example, in block A indicated by block height 1 (i.e., the first block in the blockchain), the blockchain event "Smart Contract A is called" exists 3 times (i.e., the event "Smart Contract A is called" has occurred 3 times), then the number of blockchain events "Smart Contract A is called" contained in block A can be 3; as another example, in block K indicated by block height 10 (i.e., the 10th block in the blockchain), the blockchain event "Smart Contract A is called" exists 2 times (i.e., the event "Smart Contract A is called" has occurred 2 times), then the number of blockchain events "Smart Contract A is called" contained in block K can be 2.

[0115] It should be understood that, assuming a light node subscribes to the blockchain event "Smart Contract A is invoked" from a subscribing node, then the light node should receive all associated data for that blockchain event contained in each block of the blockchain (i.e., the event business data corresponding to the three blockchain events in block A, and the event business data corresponding to the two blockchain events in block K). Through the data maintained in this index service component, the light node can verify the completeness of the event business data it receives.

[0116] Based on the above, the amount of data that the ultra-light node should receive for blockchain events in this application can be understood as the total number of blockchain events contained in each block of the blockchain (which can be referred to as the total number of events). Based on this index service component, the ultra-light node can verify whether the received event business data is complete and whether the subscribing nodes have sent or missed data, thereby obtaining a verification result (which can be referred to as the second verification result). For the specific implementation method of the ultra-light node performing integrity verification on event business data based on the amount of data it should receive to obtain the second verification result, please refer to the following sections. Figure 8 The description in the corresponding embodiments.

[0117] Step S104: When both the first verification result and the second verification result are verification passed, the event business data is stored and maintained.

[0118] In this application, when both the first verification result and the second verification result are verified as passed, the ultralight node can confirm that the event business data has completeness and accuracy, and the ultralight node can synchronously store it locally and perform maintenance processing on it.

[0119] In this embodiment, ultra-light node technology is introduced into the layered blockchain technology. An event subscription relationship is established between the ultra-light node and lightweight nodes in the business network. This event subscription relationship allows the ultra-light node to synchronously obtain relevant event business data of blockchain events from the lightweight node. That is, the ultra-light node can synchronize and store only data related to blockchain events, rather than data based on the entire transaction or a large number of related blocks. This significantly reduces the data storage space and transmission traffic of the ultra-light node during data synchronization. Furthermore, this application adds a consensus service component for maintaining the consensus network and an index service component for maintaining the data quantity in the consensus network. Based on these two components, fast and accurate verification can be performed without obtaining all historical blocks and block headers to verify the accuracy and completeness of the event business data received by the ultra-light node, thereby significantly improving verification efficiency. In summary, this application can reduce the transmission traffic burden, alleviate data storage pressure, and improve data verification efficiency in the business of synchronizing and verifying blockchain data.

[0120] Further, please see Figure 7 , Figure 7 This is a schematic diagram illustrating a process for verifying the accuracy of event service data using an ultra-lightweight node, as provided in an embodiment of this application. This process can correspond to the above-mentioned... Figure 5 In the corresponding embodiment, the process involves verifying the accuracy of event business data based on the latest block consensus data, the first transaction data, and the transaction verification data to obtain the first verification result. For example... Figure 7 As shown, the process may include at least the following steps S701-S705:

[0121] Step S701: In the transaction verification data, obtain the transaction block data of the transaction block to which the first transaction data belongs, and perform an existence verification on the first transaction data based on the first transaction data and the transaction block data to obtain the transaction verification result of the first transaction data.

[0122] Specifically, as described above, the event business data sent from the subscription node to the ultralight node includes the first transaction data corresponding to the blockchain event and the transaction verification data corresponding to the first transaction data. This transaction verification data contains the block containing the first transaction data (referred to as the transaction block in this application). The ultralight node can use this transaction verification data to verify whether the first transaction data exists in the transaction block. It can be understood that for each transaction data in a block, a Merkle binary tree can be constructed based on the hash value of each transaction data. This yields a Merkle root corresponding to all transaction data within the block, which can be understood as the transaction Merkle root of the block. In this application, the transaction block data of a transaction block can include the transaction Merkle root of the transaction block and the transaction Merkle path for the first transaction data. The transaction Merkle path contains the hash value (which can be called the transaction hash value) corresponding to the second transaction data (transaction data in the transaction block other than the first transaction data, i.e., the block to which the second transaction data belongs is also the transaction block). Based on the transaction Merkle root of the transaction block and the transaction hash value of the second transaction data, the ultralight node can verify whether the first transaction data exists in the transaction block.

[0123] In other words, the specific implementation method for verifying the existence of the first transaction data based on the first transaction data and the transaction block data to obtain the transaction verification result of the first transaction data can be as follows: The transaction hash value corresponding to the first transaction data can be determined as the transaction hash value to be verified; then, based on the Merkle tree construction rules, the transaction hash value corresponding to the second transaction data contained in the transaction Merkle path can be hashed with the transaction hash value to be verified, thereby generating the Merkle root to be verified corresponding to the first transaction data; further, the transaction Merkle root of the transaction block can be matched with the Merkle root to be verified; if the transaction Merkle root and the Merkle root to be verified are the same, it can be determined that the transaction Merkle root and the Merkle root to be verified are a successful match, and the verification result can be determined as the transaction verification result of the first transaction data; if the transaction Merkle root and the Merkle root to be verified are different, it can be determined that the transaction Merkle root and the Merkle root to be verified are a failed match, and the verification result can be determined as the transaction verification result of the first transaction data.

[0124] It is understandable that the Merkle tree construction rule here refers to the construction rule of the Merkle binary tree. The ultralight node can calculate the transaction hash value corresponding to the first transaction data. Based on the transaction hash value of the first transaction data and the transaction hash value of the second transaction data in the transaction Merkle path, the ultralight node can construct a Merkle binary tree through hash calculation. The root of this Merkle binary tree can be used as a Merkle root to be verified calculated by the ultralight node. If the Merkle root to be verified is the same as the transaction Merkle root of the transaction block, it can be determined that the first transaction data does exist in the transaction block. At this time, the transaction verification result of the first transaction data can be determined as a verification passed result; otherwise, the transaction verification result of the first transaction data can be determined as a verification failed result.

[0125] Step S702: Based on the latest block consensus data and transaction block data, perform an existence verification on the transaction block to obtain the block verification result of the transaction block.

[0126] Specifically, based on the above, the public QC service component records and stores the consensus data of the latest block in the blockchain. This consensus data may include the Merkel Mountain Root (MMR Root) of the latest block. By using the Merkel Mountain Root of the latest block, it can be verified whether the transaction block exists in the Merkel Mountain. If it exists, it can be determined that the transaction block does exist in the blockchain, and thus it can be determined that the first transaction data does exist in the blockchain. When it is determined that the first transaction data does exist in the blockchain, it can be determined that the event business data is accurate. In this application, the transaction block data of a transaction block may include the Merkel mountain root of the predecessor block (the previous block of the transaction block in the blockchain) and the block hash value corresponding to the incremental block (a block in the blockchain whose block generation timestamp is later than the block generation timestamp of the transaction block; when the transaction block is the latest block, the transaction block may not have an incremental block, i.e., the incremental block in this application may be null). Based on the Merkel mountain root of the predecessor block and the block hash value of the incremental block, the ultralight node can verify whether the transaction block exists in the blockchain.

[0127] In other words, for the block consensus data and transaction block data based on the latest block, the specific implementation of verifying the existence of the transaction block to obtain the block verification result can be as follows: the block hash value of the transaction block can be determined as the hash value of the block to be verified; subsequently, based on the construction rules of the Merkel mountain tree, the Merkel mountain root of the previous block, the hash value of the block to be verified, and the block hash value corresponding to the incremental block can be hashed to generate the Merkel mountain root to be verified corresponding to the latest block; furthermore, the real Merkel mountain root of the latest block can be obtained from the block consensus data of the latest block, and the Merkel mountain root to be verified corresponding to the latest block can be... The verification result is then matched against the real Merkel mountain root of the latest block. If the Merkel mountain root to be verified for the latest block is the same as the real Merkel mountain root of the latest block, then the matching result between the Merkel mountain root to be verified for the latest block and the real Merkel mountain root of the latest block is considered successful, and the verification result can be determined as the block verification result of the transaction block. If the Merkel mountain root to be verified for the latest block is different from the real Merkel mountain root of the latest block, then the matching result between the Merkel mountain root to be verified for the latest block and the real Merkel mountain root of the latest block is considered unsuccessful, and the verification result can be determined as the block verification result of the transaction block.

[0128] Specifically, regarding the construction rules based on the Merkel mountain tree, the specific implementation of hashing the Merkel mountain root of the predecessor block, the hash value of the block to be verified, and the block hash value corresponding to the incremental block to generate the Merkel mountain root to be verified for the latest block can be as follows: Based on the construction rules of the Merkel mountain tree, the Merkel mountain root of the predecessor block and the hash value of the block to be verified can be hashed to generate the Merkel mountain root corresponding to the transaction block; subsequently, the Merkel mountain root corresponding to the transaction block and the block hash value of the incremental block can be hashed to generate the Merkel mountain root to be verified for the latest block.

[0129] Understandably, the construction rules for the Merkel mountain tree can refer to the above. Figure 6The description in the corresponding embodiment is that each new block can be treated as a leaf node. Based on the block hash value of the new block and the Merkel mountain root of the previous block, a new Merkel mountain can be calculated and constructed. In this new Merkel mountain, the root of the mountain can be used as the Merkel mountain root of the new block. Subsequently, the new block can be used as the previous block of the next new block. Based on the block hash of the next new block and the Merkel mountain root of the previous block, a new Merkel mountain can be calculated, and the root of this Merkel mountain can be used as the Merkel mountain root of the new block... and so on. Using the same principle, for transaction blocks, the Merkel mountain root corresponding to the transaction block can be calculated based on the block hash value (the hash value of the block to be verified) of the predecessor block. Based on the Merkel mountain root of the transaction block and the block hash value of the incremental block, a new Merkel mountain can be calculated. Finally, a Merkel mountain root to be verified corresponding to the latest block can be obtained.

[0130] Furthermore, the Merkel mountain root recorded and stored by the public QC service component can be considered as a real Merkel mountain root. The ultralight node can match the calculated Merkel mountain root to be verified with the real Merkel mountain root. If the Merkel mountain root to be verified is the same as the real Merkel mountain root, it can be determined that the transaction block does exist in the blockchain, and the block verification result of the transaction block can be determined as a verification passed result; otherwise, the block verification result of the transaction block can be determined as a verification failed result.

[0131] Step S703: Determine whether both the transaction verification result and the block verification result are verification passed.

[0132] Specifically, after obtaining the transaction verification result and the block verification result, it can be determined whether both the transaction verification result and the block verification result are valid. Only when both the transaction verification result and the block verification result are valid can it be confirmed that the first transaction data does exist in the blockchain, and thus the accuracy of the event business data can be determined. Accordingly, if it is determined that both the transaction verification result and the block verification result are valid, the subsequent step S704 can be executed; if it is determined that either the transaction verification result or the block verification result is invalid, the subsequent step S705 can be executed.

[0133] Step S704: When both the transaction verification result and the block verification result are verified as passed, the verified result is determined as the first verification result.

[0134] Specifically, when both the transaction verification result and the block verification result are verified as passed, the first verification result of the event business data can be determined as the verified result (the verified result can be used to indicate that the event business data is accurate).

[0135] It should be noted that when both the transaction verification result and the block verification result are valid, the validity (or legality) of the MMR root (i.e., the true Merkel mountain root) of the latest block recorded and stored in the public QC service component can be further verified. If the true Merkel mountain root is verified to be legal, then the verification result is determined as the first verification result. Specifically, since the true Merkel mountain root of the latest block exists in the block consensus data of the latest block, the verification of the legality of the true Merkel mountain root can be transformed into the verification of the legality of the block consensus data of the latest block. If the block consensus data of the latest block is legal, then the true Merkel mountain root is also determined to be legal. As can be seen from the above, the consensus data of each block can be signed by the consensus nodes that participated in the consensus. That is, the consensus data of the latest block contains the signature data (second digital signature) of the consensus nodes that participated in the consensus. The ultralight node can verify the second digital signature. After the verification is successful, it can be determined that the consensus data of the latest block is legitimate.

[0136] Specifically, a light node can obtain a second digital signature from the consensus data of the latest block. This second digital signature is obtained by the consensus node of the latest block (i.e., the consensus node participating in the consensus of the latest block) signing the latest block based on its private key. Subsequently, the public key of the consensus node can be obtained, and the second digital signature can be verified using this public key, thus obtaining the verification result. If the verification result of the second digital signature is successful, the step of determining the successful verification result as the first verification result can be executed. If the verification result of the second digital signature is successful, the first verification result can be determined as a failed verification result.

[0137] Step S705: When the transaction verification result or block verification result is a verification failure result, the verification failure result is determined as the first verification result.

[0138] Specifically, when the transaction verification result or block verification result is a verification failure result, the first verification result of the event business data can be determined as a verification failure result (the verification failure result can be used to indicate that the event business data does not have accuracy).

[0139] In this embodiment, ultra-light node technology is introduced into the layered blockchain technology. An event subscription relationship is established between the ultra-light node and the lightweight nodes in the business network. This event subscription relationship allows the ultra-light node to synchronously obtain relevant event business data of blockchain events from the lightweight node. That is, the ultra-light node can only synchronize and store data related to blockchain events, rather than data based on the entire transaction or a large number of related blocks. This significantly reduces the data storage space and transmission traffic of the ultra-light node during data synchronization. Furthermore, this application adds a consensus service component to the consensus network for maintaining the consensus network. This consensus service component enables the ultra-light node to perform fast and accurate verification without obtaining all historical blocks and block headers, thereby verifying the accuracy of the event business data received by the ultra-light node and improving data verification efficiency.

[0140] Further, please see Figure 8 , Figure 8 This is a schematic diagram illustrating a process for an ultra-light node to perform integrity verification on event service data, provided in an embodiment of this application. This process can correspond to the above-mentioned... Figure 5 In the corresponding embodiment, the process involves verifying the integrity of event business data based on the amount of data to be received, and obtaining a second verification result. Based on the above, the amount of data to be received for a blockchain event corresponding to an ultra-light node refers to the total number of events corresponding to the blockchain events contained in each block of the blockchain. However, in cases where... Figure 8 The process shown is illustrated using an example where the number of blockchain events is one or more. Figure 8 As shown, the process may include at least the following steps S801-S802:

[0141] Step S801: Based on the event business data, count the number of blockchain events received by the ultralight node, and determine the number of blockchain events received by the ultralight node as the number of received events.

[0142] Specifically, based on the above, for a given blockchain event, the number of blockchain events in various blocks of the blockchain may include multiple events (usually two or more). This application can refer to the event business data corresponding to one blockchain event in a block as a batch of event business data for that blockchain event. In other words, for a given blockchain event, the blockchain may contain multiple batches of event business data. The subscribing node needs to send all batches of event business data for that blockchain event to the ultra-light node. The number of blockchain events already received by the ultra-light node can be understood as the batch size of event business data already received. In other words, one or more blockchain events in the blockchain can be associated with a batch of event business data. Each time a batch of event business data is received, the blockchain event corresponding to that batch of event business data can be understood as a received blockchain event for an ultra-light node.

[0143] Step S802: Match the number of received events with the total number of events, and determine the second verification result based on the matching result between the number of received events and the total number of events.

[0144] Specifically, this application can match the number of received events with the total number of events in the blockchain, and determine the second verification result based on the matching result between the number of received events and the total number of events. The specific implementation method for determining the second verification result based on the matching result between the received event quantity and the total number of events can be as follows: If the matching result between the received event quantity and the total number of events is that the received event quantity equals the total number of events, it can be determined that the event business data received by the ultralight node for the subscribed blockchain event is complete and error-free, and the verification pass result can be determined as the second verification result; if the matching result between the received event quantity and the total number of events is that the received event quantity is less than the total number of events, it can be determined that in the blockchain, for the subscribed blockchain event, there is a batch of event business data that the ultralight node has not successfully received, and the ultralight node can be determined as the receiving differential node, and the verification failure result can be determined as the second verification result; if the matching result between the received event quantity and the total number of events is that the received event quantity is greater than the total number of events, it can be determined that in the blockchain, for the subscribed blockchain event, the event business data received by the ultralight node is complete and error-free, and the ultralight node has also received relevant event business data from other unsubscribed blockchain events, and the ultralight node can be determined as the receiving excess node, and the verification failure result can be determined as the second verification result.

[0145] Optionally, after identifying the ultralight node as the receiving differential node, it can be determined that the event business data received by the ultralight node from the blockchain events is incomplete. In this case, the ultralight node can initiate an event supplement retrieval request to the subscribing node, requesting the subscribing node to send the missing event business data to the ultralight node. Specifically, the ultralight node can identify the blockchain events already received as received blockchain events; and identify the blockchain events other than the received blockchain events as unreceived blockchain events. Based on the unreceived blockchain events, the ultralight node can generate an event supplement retrieval request and send it to the subscribing node. This allows the subscribing node to retrieve the unreceived event business data associated with the unreceived blockchain events from the consensus nodes of the consensus network, and then return the unreceived event business data to the ultralight node.

[0146] For example, taking the blockchain event "Smart Contract A is invoked" as an example for the ultralight node, there are 3 instances of Smart Contract A being invoked in Block 1, with event numbers (event numbers are used to uniquely identify a blockchain event, and can effectively distinguish between different blockchain events) of 1, 2, and 3 respectively. In Block 5, there are also 3 instances of Smart Contract A being invoked, with event numbers of 6, 8, and 9 respectively. The ultralight node has already received the event business data corresponding to blockchain events 1, 2, 3, 8, and 9, so blockchain events 1, 2, 3, 8, and 9 can all be considered as received blockchain events. As for blockchain event 6, it can be considered as an unreceived blockchain event. The ultralight node can generate an event supplement retrieval request for blockchain event 6 to request the subscribing node to send the event business data of blockchain event 6 (i.e., the unreceived event business data) to the ultralight node, so as to obtain the complete event business data of the blockchain event "Smart Contract A is invoked".

[0147] Similarly, optionally, after identifying the ultralight node as a receiving node for excessive events, it can be determined that the event business data of the blockchain events received by the ultralight node includes event business data of other blockchain events. In this case, the ultralight node can clean up the extra received event business data. Taking M blockchain events (M is a positive integer) received by the ultralight node as an example, the specific implementation is as follows: all M received blockchain events can be identified as received blockchain events. Then, the set of the M received blockchain events can be defined as the first event set; and the set of one or more blockchain events can be defined as the second event set. Further, the intersection of the first event set and the second event set can be obtained; then, the received blockchain events in the first event set other than those in the intersection set can be identified as blockchain events to be cleared, and the received event business data associated with the blockchain events to be cleared can be cleared. It is understandable that blockchain events included in the intersection set can be considered as blockchain events that the ultralight node should receive. Then, blockchain events that have been received but not included in the intersection set can be considered as blockchain events that the ultralight node should not receive, and the event business data of these blockchain events can be cleared.

[0148] In this embodiment, ultra-light node technology is introduced into the layered blockchain technology. An event subscription relationship is established between the ultra-light node and the lightweight nodes in the business network. This event subscription relationship allows the ultra-light node to synchronously obtain relevant event business data of blockchain events from the lightweight node. That is, the ultra-light node can only synchronize and store data related to blockchain events, rather than data based on the entire transaction or a large number of related blocks. This significantly reduces the data storage space and transmission traffic of the ultra-light node during data synchronization. Furthermore, this application adds an index service component to the consensus network to maintain the amount of data. This index service component enables the ultra-light node to perform fast and accurate verification without obtaining all historical blocks and block headers, thereby verifying the integrity of the event business data received by the ultra-light node and improving data verification efficiency.

[0149] Further, please see Figure 9 , Figure 9 This is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of this application. The blockchain-based data processing device can be a computer program (including program code) running on a computer device; for example, the blockchain-based data processing device is an application software. The blockchain-based data processing device can be used to execute... Figure 3 The method shown. (As illustrated) Figure 9As shown, the blockchain-based data processing device 1 may include: a data receiving module 11, a consensus data acquisition module 12, a first data verification module 13, a data acquisition module 14, a second data verification module 15, and a data storage module 16.

[0150] The data receiving module 11 is used to receive event business data sent by the subscribing node; the subscribing node refers to a lightweight node in the business network that has an event subscription relationship with the ultra-light node; the event business data refers to the data in the blockchain associated with the blockchain event subscribed to by the ultra-light node; the event business data includes the first transaction data corresponding to the blockchain event, and the transaction verification data corresponding to the first transaction data; the event business data is obtained by the subscribing node from the consensus node in the consensus network; there is network isolation between the business network and the consensus network;

[0151] The consensus data acquisition module 12 is used to acquire the latest block consensus data in the blockchain from the consensus service component used to maintain the consensus network.

[0152] The first data verification module 13 is used to verify the accuracy of event business data based on the latest block consensus data, the first transaction data, and the transaction verification data, and obtain the first verification result.

[0153] The quantity acquisition module 14 is used to acquire the amount of data that the ultralight node should receive for a blockchain event in the index service component used to maintain the data quantity;

[0154] The second data verification module 15 is used to perform integrity verification on the event business data based on the amount of data to be received, and obtain a second verification result.

[0155] The data storage module 16 is used to store and maintain event business data when both the first verification result and the second verification result are verification pass results.

[0156] The specific implementation methods of the data receiving module 11, consensus data acquisition module 12, first data verification module 13, quantity acquisition module 14, second data verification module 15, and data storage module 16 can be found in the above description. Figure 5 The descriptions of steps S101-S104 in the corresponding embodiments will not be repeated here.

[0157] In one embodiment, the blockchain-based data processing device 1 may further include: a registration request sending module 17, a subscription request generation module 18, a request signature sending module 19, and a step execution module 20.

[0158] The registration request sending module 17 is used to send an identity registration request carrying the public key of the ultralight node to the consensus node in the consensus network;

[0159] The subscription request generation module 18 is used to receive the registration success message returned by the consensus node in the consensus network, and generate an event subscription request for the blockchain event based on the registration success message.

[0160] The request signature sending module 19 is used to sign the event subscription request based on the private key of the ultralight node to obtain the first digital signature, and send the event subscription request and the first digital signature to the subscription node;

[0161] The step execution module 20 is used to execute the step of the ultralight node receiving the event business data sent by the subscription node when it receives the subscription success prompt information returned by the subscription node; the subscription success prompt information is generated by the subscription node verifying the first digital signature based on the public key of the ultralight node in the consensus network, and after the verification is successful.

[0162] The specific implementation methods of the registration request sending module 17, subscription request generation module 18, request signature sending module 19, and step execution module 20 can be found in the above description. Figure 5 The description of step S101 in the corresponding embodiment will not be repeated here.

[0163] In one embodiment, the first data verification module 13 verifies the accuracy of event business data based on the latest block consensus data, the first transaction data, and the transaction verification data to obtain the first verification result. The specific implementation of this method includes:

[0164] In the transaction verification data, the transaction block data of the transaction block to which the first transaction data belongs is obtained. Based on the first transaction data and the transaction block data, the existence of the first transaction data is verified to obtain the transaction verification result of the first transaction data.

[0165] Based on the latest block consensus data and transaction block data, the existence of the transaction block is verified to obtain the block verification result of the transaction block;

[0166] When both the transaction verification result and the block verification result are verified as passed, the verified result will be determined as the first verification result.

[0167] If the transaction verification result or the block verification result is a verification failure result, the verification failure result will be determined as the first verification result.

[0168] The transaction block data includes the transaction Merkle root of the transaction block, and the transaction Merkle path for the first transaction data; the transaction Merkle path includes the transaction hash value corresponding to the second transaction data; the block to which the second transaction data belongs is the transaction block;

[0169] In one embodiment, the specific implementation method of the first data verification module 13 performing existence verification on the first transaction data based on the first transaction data and transaction block data to obtain the transaction verification result of the first transaction data includes:

[0170] The transaction hash value corresponding to the first transaction data is determined as the transaction hash value to be verified;

[0171] Based on the Merkle tree construction rules, the transaction hash value corresponding to the second transaction data contained in the transaction Merkle path is hashed with the transaction hash value to be verified to generate the Merkle root to be verified corresponding to the first transaction data.

[0172] Match the transaction Merkle root of the transaction block with the Merkle root to be verified;

[0173] If the transaction Merkle root and the Merkle root to be verified are successfully matched, the verification result will be determined as the transaction verification result of the first transaction data.

[0174] If the transaction Merkle root and the Merkle root to be verified are not matched, the verification failure result will be determined as the transaction verification result of the first transaction data.

[0175] In one embodiment, the transaction block data includes the Merkel mountain root of the predecessor block and the block hash value corresponding to the incremental block; the predecessor block refers to the block in the blockchain that is before the transaction block; the incremental block refers to the block in the blockchain whose block generation timestamp is later than the block generation timestamp of the transaction block.

[0176] The first data verification module 13 performs existence verification on transaction blocks based on the latest block consensus data and transaction block data, and obtains the specific implementation method of the transaction block verification result, including:

[0177] The block hash value of the transaction block is determined as the hash value of the block to be verified;

[0178] Based on the construction rules of the Merkel mountain tree, the Merkel mountain root of the predecessor block, the hash value of the block to be verified, and the hash value of the block corresponding to the incremental block are hashed to generate the Merkel mountain root to be verified corresponding to the latest block.

[0179] In the consensus data of the latest block, obtain the real Merkel mountain root of the latest block, and match the unverified Merkel mountain root corresponding to the latest block with the real Merkel mountain root of the latest block;

[0180] If the Merkel mountain root to be verified corresponding to the latest block is matched with the real Merkel mountain root of the latest block, then the verification result will be determined as the block verification result of the transaction block.

[0181] If the Merkel mountain root to be verified corresponding to the latest block fails to match the actual Merkel mountain root of the latest block, then the verification failure result will be determined as the block verification result of the transaction block.

[0182] In one embodiment, the first data verification module 13, based on the construction rules of the Merkel mountain tree, performs hash calculations on the Merkel mountain root of the predecessor block, the hash value of the block to be verified, and the hash value of the block corresponding to the incremental block to generate the Merkel mountain root to be verified for the latest block. The specific implementation includes:

[0183] Based on the construction rules of the Merkel mountain tree, the Merkel mountain root of the predecessor block and the hash value of the block to be verified are hashed to generate the Merkel mountain root corresponding to the transaction block.

[0184] The Merkel mountain root corresponding to the transaction block is hashed with the block hash value of the incremental block to generate the Merkel mountain root to be verified for the latest block.

[0185] In one embodiment, the first data verification module 13 is further configured to obtain a second digital signature in the block consensus data of the latest block; the second digital signature is obtained by the block consensus node of the latest block signing the latest block based on the private key of the block consensus node;

[0186] The first data verification module 13 is also used to obtain the public key of the block consensus node, and to verify the second digital signature based on the public key of the block consensus node, so as to obtain the verification result of the second digital signature.

[0187] The first data verification module 13 is also used to perform the step of determining the verification result as the first verification result when the verification result of the second digital signature is a verification pass result.

[0188] In one embodiment, the number of blockchain events in the blockchain is one or more, and the amount of data to be received is the total number of events corresponding to one or more blockchain events;

[0189] The second data verification module 15 performs integrity verification on the event business data based on the amount of data to be received, and obtains the second verification result. The specific implementation methods include:

[0190] Based on event business data, the number of blockchain events received by the ultralight node is counted, and the number of blockchain events received by the ultralight node is determined as the number of received events.

[0191] The number of received events is matched with the total number of events, and the second verification result is determined based on the matching result between the number of received events and the total number of events.

[0192] In one embodiment, the second data verification module 15 determines the specific implementation method of the second verification result based on the matching result between the number of received events and the total number of events, including:

[0193] If the matching result between the number of received events and the total number of events is that the number of received events equals the total number of events, then the verification result is determined as the second verification result.

[0194] If the matching result between the number of received events and the total number of events is that the number of received events is less than the total number of events, then the ultralight node is determined as the receiving differential node, and the verification failure result is determined as the second verification result.

[0195] If the matching result between the number of received events and the total number of events is that the number of received events is greater than the total number of events, then the ultralight node is identified as a node that receives an excessive amount of events, and the verification failure result is identified as the second verification result.

[0196] In one embodiment, after determining the ultralight node as a receiving differential node, the second data verification module 15 is further configured to determine the blockchain events already received by the ultralight node as received blockchain events of the ultralight node.

[0197] Among one or more blockchain events, those other than the blockchain events that have been received are identified as blockchain events that have not been received.

[0198] Based on the unreceived blockchain event, an event supplement retrieval request is generated and sent to the subscribing node. The subscribing node then retrieves the unreceived event business data associated with the unreceived blockchain event from the consensus node of the consensus network based on the event supplement retrieval request, and returns the unreceived event business data to the ultralight node.

[0199] In one embodiment, the number of blockchain events received by the ultralight node is M; M are positive integers.

[0200] After identifying the ultralight node as a receiving super-quantity node, the second data verification module 15 is also used to identify all M received blockchain events as received blockchain events, and to identify the set of the M received blockchain events as the first event set.

[0201] Define the set of one or more blockchain events as the second event set;

[0202] The intersection of the first event set and the second event set is obtained;

[0203] The received blockchain events in the first event set, excluding the intersection set, are identified as blockchain events to be cleared, and the received event business data associated with the blockchain events to be cleared are cleared.

[0204] In this embodiment, ultra-light node technology is introduced into the layered blockchain technology. An event subscription relationship is established between the ultra-light node and the lightweight nodes in the business network. This event subscription relationship allows the ultra-light node to synchronously obtain relevant event business data of blockchain events from the lightweight node. That is, the ultra-light node can only synchronize and store data related to blockchain events, rather than data based on the entire transaction or a large number of related blocks. This significantly reduces the data storage space and transmission traffic of the ultra-light node during data synchronization. Furthermore, this application adds a consensus service component for maintaining the consensus network and an index service component for maintaining the data quantity in the consensus network. Based on these two components, fast and accurate verification can be performed without obtaining all historical blocks and block headers to verify the accuracy and completeness of the event business data received by the ultra-light node, thereby significantly improving verification efficiency.

[0205] Further, please see Figure 10 , Figure 10 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 10 As shown, the aforementioned computer device 8000 may include: a processor 8001, a network interface 8004, and a memory 8005. Furthermore, the computer device 8000 also includes: a user interface 8003, and at least one communication bus 8002. The communication bus 8002 is used to enable communication between these components. The user interface 8003 may include a display screen and a keyboard; optionally, the user interface 8003 may also include a standard wired interface or a wireless interface. The network interface 8004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 8005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 8005 may also be at least one storage device located remotely from the aforementioned processor 8001. Figure 10 As shown, the memory 8005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application program.

[0206] exist Figure 10In the computer device 8000 shown, the network interface 8004 provides network communication functionality; the user interface 8003 is mainly used to provide an input interface for the user; and the processor 8001 can be used to call the device control application program stored in the memory 8005 to achieve:

[0207] The system receives event business data sent by subscribing nodes; subscribing nodes refer to lightweight nodes in the business network that have an event subscription relationship with ultra-light nodes; event business data refers to data in the blockchain associated with blockchain events subscribed to by ultra-light nodes; event business data includes the first transaction data corresponding to the blockchain event, and the transaction verification data corresponding to the first transaction data; event business data is obtained by subscribing nodes from consensus nodes in the consensus network; there is network isolation between the business network and the consensus network;

[0208] In the consensus service component used to maintain the consensus network, the block consensus data of the latest block in the blockchain is obtained. Based on the block consensus data of the latest block, the first transaction data, and the transaction verification data, the accuracy of the event business data is verified to obtain the first verification result.

[0209] In the index service component used to maintain the amount of data, the amount of data that the ultralight node should receive for a blockchain event is obtained, and the integrity of the event business data is verified based on the amount of data that should be received, to obtain a second verification result.

[0210] When both the first and second verification results are successful, the event business data will be stored and maintained.

[0211] It should be understood that the computer device 8000 described in the embodiments of this application can execute the foregoing text. Figure 5 The description of the blockchain-based data processing method in the corresponding embodiments can also be performed as described above. Figure 9 The description of the blockchain-based data processing device 1 in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated here.

[0212] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program executed by the aforementioned data processing computer device 8000. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figure 5The description of the blockchain-based data processing method in the corresponding embodiments is already provided and will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application.

[0213] The aforementioned computer-readable storage medium can be the internal storage unit of the blockchain-based data processing apparatus provided in any of the foregoing embodiments or the computer device, such as the hard drive or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium can include both internal and external storage units of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0214] One aspect of this application provides a computer program product comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the method provided in one aspect of the embodiments of this application.

[0215] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0216] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0217] The methods and related apparatuses provided in this application are described with reference to the method flowcharts and / or structural diagrams provided in this application. Specifically, each block of the method flowchart and / or structural diagram, as well as combinations of blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to create a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing device, generate instructions for implementing the process. Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 A process or multiple processes and / or structures illustrate the steps of the functions specified in one or more boxes.

[0218] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data processing method based on blockchain, characterized in that, The method is executed by an ultralight node, and the method includes: The system receives event service data sent by a subscription node; the subscription node refers to a lightweight node in the service network that has an event subscription relationship with the ultra-light node; the event service data refers to data in the blockchain associated with blockchain events subscribed to by the ultra-light node; the event service data includes first transaction data corresponding to the blockchain event and transaction verification data corresponding to the first transaction data; the event service data is obtained by the subscription node from a consensus node in the consensus network; the service network and the consensus network are isolated from each other. In the consensus service component used to maintain the consensus network, the block consensus data of the latest block in the blockchain is obtained. Based on the block consensus data of the latest block, the first transaction data, and the transaction verification data, the accuracy of the event business data is verified to obtain a first verification result. In the index service component used to maintain the amount of data, the amount of data that the ultralight node should receive for the blockchain event is obtained, and the integrity of the event business data is verified based on the amount of data that should be received to obtain a second verification result. When both the first verification result and the second verification result are successful, the event business data will be stored and maintained.

2. The method according to claim 1, characterized in that, The method further includes: The ultralight node sends an identity registration request carrying the public key of the ultralight node to the consensus node in the consensus network; Receive consensus nodes in the consensus network, generate an event subscription request for the blockchain event based on the registration success message returned by the identity registration request; The event subscription request is signed using the private key of the ultralight node to obtain a first digital signature, and the event subscription request and the first digital signature are sent to the subscription node. Upon receiving a subscription success message from the subscription node, the ultralight node executes the step of receiving event service data sent by the subscription node; the subscription success message is generated by the subscription node after verifying the first digital signature based on the public key of the ultralight node in the consensus network.

3. The method according to claim 1, characterized in that, The accuracy of the event business data is verified based on the block consensus data of the latest block, the first transaction data, and the transaction verification data to obtain a first verification result, including: In the transaction verification data, the transaction block data of the transaction block to which the first transaction data belongs is obtained. Based on the first transaction data and the transaction block data, the existence of the first transaction data is verified to obtain the transaction verification result of the first transaction data. Based on the block consensus data of the latest block and the transaction block data, the existence of the transaction block is verified to obtain the block verification result of the transaction block; When both the transaction verification result and the block verification result are verification passed, the verification passed result is determined as the first verification result; When the transaction verification result or the block verification result is a verification failure result, the verification failure result is determined as the first verification result.

4. The method according to claim 3, characterized in that, The transaction block data includes the transaction Merkle root of the transaction block and the transaction Merkle path for the first transaction data; the transaction Merkle path includes the transaction hash value corresponding to the second transaction data; the block to which the second transaction data belongs is the transaction block; The step of performing an existence check on the first transaction data based on the first transaction data and the transaction block data to obtain the transaction check result of the first transaction data includes: The transaction hash value corresponding to the first transaction data is determined as the transaction hash value to be verified; Based on the Merkle tree construction rules, the transaction hash value corresponding to the second transaction data contained in the transaction Merkle path is hashed with the transaction hash value to be verified to generate the Merkle root to be verified corresponding to the first transaction data. Match the transaction Merkle root of the transaction block with the Merkle root to be verified; If the transaction Merkle root and the Merkle root to be verified are successfully matched, the verification result is determined as the transaction verification result of the first transaction data; If the transaction Merkle root and the Merkle root to be verified are not matched, the verification failure result is determined as the transaction verification result of the first transaction data.

5. The method according to claim 3, characterized in that, The transaction block data includes the Merkel mountain root of the predecessor block and the block hash value corresponding to the incremental block; the predecessor block refers to the block before the transaction block in the blockchain; the incremental block refers to the block in the blockchain whose block generation timestamp is later than the block generation timestamp of the transaction block. The existence verification of the transaction block is performed based on the block consensus data of the latest block and the transaction block data to obtain the block verification result of the transaction block, including: The block hash value of the transaction block is determined as the hash value of the block to be verified; Based on the construction rules of the Merkel mountain tree, the Merkel mountain root of the predecessor block, the hash value of the block to be verified, and the hash value of the block corresponding to the incremental block are hashed to generate the Merkel mountain root to be verified corresponding to the latest block. In the block consensus data of the latest block, the real Merkel mountain root of the latest block is obtained, and the Merkel mountain root to be verified corresponding to the latest block is matched with the real Merkel mountain root of the latest block; If the Merkel mountain root to be verified corresponding to the latest block is successfully matched with the real Merkel mountain root of the latest block, then the verification result is determined as the block verification result of the transaction block. If the Merkel mountain root to be verified corresponding to the latest block fails to match the actual Merkel mountain root of the latest block, then the verification failure result is determined as the block verification result of the transaction block.

6. The method according to claim 5, characterized in that, The construction rules based on the Merkel mountain tree perform hash calculations on the Merkel mountain root of the predecessor block, the hash value of the block to be verified, and the hash value of the block corresponding to the incremental block to generate the Merkel mountain root to be verified for the latest block, including: Based on the construction rules of the Merkel mountain tree, the Merkel mountain root of the predecessor block and the hash value of the block to be verified are hashed to generate the Merkel mountain root corresponding to the transaction block. The Merkel mountain root corresponding to the transaction block is hashed with the block hash value of the incremental block to generate the Merkel mountain root to be verified corresponding to the latest block.

7. The method according to claim 3, characterized in that, The method further includes: Obtain a second digital signature from the block consensus data of the latest block; the second digital signature is obtained by the block consensus node of the latest block signing the latest block based on the private key of the block consensus node; Obtain the public key of the block consensus node, and verify the second digital signature based on the public key of the block consensus node to obtain the verification result of the second digital signature; When the verification result of the second digital signature is a successful verification result, the step of determining the successful verification result as the first verification result is executed.

8. The method according to claim 1, characterized in that, The number of blockchain events in the blockchain is one or more, and the amount of data to be received is the total number of events corresponding to one or more blockchain events; The process of performing integrity verification on the event service data based on the amount of data to be received, to obtain a second verification result, includes: Based on the event business data, the number of blockchain events received by the ultralight node is counted, and the number of blockchain events received by the ultralight node is determined as the number of received events. The number of received events is matched with the total number of events, and the second verification result is determined based on the matching result between the number of received events and the total number of events.

9. The method according to claim 8, characterized in that, Determining the second verification result based on the matching result between the number of received events and the total number of events includes: If the matching result between the number of received events and the total number of events is that the number of received events is equal to the total number of events, then the verification result is determined as the second verification result; If the matching result between the number of received events and the total number of events is that the number of received events is less than the total number of events, then the ultralight node is determined as the receiving differential node, and the verification failure result is determined as the second verification result. If the matching result between the number of received events and the total number of events is that the number of received events is greater than the total number of events, then the ultralight node is determined as a node that receives an excessive amount of data, and the verification failure result is determined as the second verification result.

10. The method according to claim 9, characterized in that, After identifying the ultralight node as a differential receiving node, the method further includes: The blockchain events that the ultralight node has received are identified as the blockchain events that the ultralight node has received. Among the one or more blockchain events, those other than the received blockchain events are identified as unreceived blockchain events; Based on the unreceived blockchain event, an event supplement retrieval request is generated and sent to the subscription node, so that the subscription node can obtain the unreceived event business data associated with the unreceived blockchain event from the consensus node of the consensus network based on the event supplement retrieval request, and return the unreceived event business data to the ultralight node.

11. The method according to claim 9, characterized in that, The number of blockchain events received by the ultralight node is M; M are positive integers. After identifying the ultralight node as a receiving excess node, the method further includes: All M received blockchain events are identified as received blockchain events, and the set of the M received blockchain events is identified as the first event set. Define the set of one or more blockchain events as the second event set; The intersection of the first event set and the second event set is obtained; The received blockchain events in the first event set, excluding the intersection set, are identified as blockchain events to be cleared, and the received event business data associated with the blockchain events to be cleared are cleared.

12. A data processing device based on blockchain, characterized in that, The blockchain-based data processing device is deployed on an ultralight node, and the blockchain-based data processing device includes: A data receiving module is used to receive event business data sent by a subscribing node; the subscribing node refers to a lightweight node in the business network that has an event subscription relationship with the ultra-light node; the event business data refers to data in the blockchain associated with blockchain events subscribed to by the ultra-light node; the event business data includes first transaction data corresponding to the blockchain event and transaction verification data corresponding to the first transaction data; the event business data is obtained by the subscribing node from a consensus node in the consensus network; there is network isolation between the business network and the consensus network; The consensus data acquisition module is used to acquire the block consensus data of the latest block in the blockchain from the consensus service component used to maintain the consensus network. The first data verification module is used to verify the accuracy of the event business data based on the block consensus data of the latest block, the first transaction data, and the transaction verification data, and obtain a first verification result. The quantity acquisition module is used to acquire the amount of data that the ultralight node should receive for the blockchain event in the index service component used to maintain the data quantity; The second data verification module is used to perform integrity verification on the event business data based on the amount of data to be received, and obtain a second verification result. The data storage module is used to store and maintain the event business data when both the first verification result and the second verification result are verification pass results.

13. A computer device, characterized in that, include: Processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide network communication functions, the memory is used to store computer programs, and the processor is used to call the computer programs to cause the computer device to execute the method according to any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and to execute the method according to any one of claims 1-11.

15. A computer program product, characterized in that, The computer program product includes a computer program stored in a computer-readable storage medium, the computer program being adapted to be read and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-11.

Images