A blockchain data processing method and related apparatus

Abstract

The application provides a blockchain data processing method and related device, by introducing a circular buffer with a fixed storage length, and based on the splicing order of the to-be-processed Merkle path proof, the hash blocks are received layer by layer, the hash operation is performed level by level, and the in-situ coverage is performed, which is completely different from the processing mode of the prior art which needs to load the complete Merkle path proof data at one time. The application only needs to load the current level hash block each time, and the hash operation result of the current level can be directly stored in the circular buffer to participate in the next level calculation, so as to realize the state check with higher memory complexity. At this time, the fixed storage length of the circular buffer only needs to be not less than the byte length of a single hash operation result, so that the physical limit of the hardware memory can be broken through, the state tree verification of any depth can be supported, and the strong dependence of the blockchain state verification process in the prior art on the memory capacity is fundamentally overcome.

Description

Technical Field

[0001] This application relates to the field of blockchain, and more specifically, to a blockchain data processing method and related apparatus. Background Technology

[0002] With the deep integration of blockchain technology with fields such as the Internet of Things and mobile payments, the need to directly maintain and update the state of blockchain accounts through restricted hardware devices such as hardware wallets, Near Field Communication (NFC) smart cards, and secure units with Bluetooth or other wireless communication is becoming increasingly urgent. These restricted hardware devices typically integrate a Secure Element (SE) to provide hardware-level key storage and cryptographic computation capabilities to ensure the security of blockchain assets and transaction credentials.

[0003] In a typical blockchain state verification process, the terminal device needs to receive the pending transaction and its associated Merkle path proof sent by an external terminal (such as a mobile phone or card reader), and recalculate the Merkle root through a step-by-step hash operation. The calculated Merkle root is then compared with the currently stored state root to confirm the validity of the transaction. This process is the core technological foundation for implementing decentralized lightweight clients (Simplified Payment Verification, SPV).

[0004] However, existing blockchain state verification schemes generally face significant memory compatibility risks when applied to the aforementioned constrained hardware environments. Specifically, existing Merkel verification methods require the verifying end to load the complete Merkel path proof data at once (e.g., the hash values ​​of all sibling nodes along the path from the leaf node corresponding to the transaction to be verified to the root node), and complete the hash concatenation and computation at all levels in memory. For the deep state trees commonly found in real-world blockchain systems (such as Ethereum's state tree, which can reach depths of 32 layers or more), the required memory overhead far exceeds the Random Access Memory (RAM) capacity of mainstream security elements (typically only 16KB to 32KB). Under these resource constraints, loading the complete proof path at once can easily lead to memory overflow, resulting in system crashes and severely limiting the ability of constrained hardware devices to directly participate in blockchain state maintenance.

[0005] Therefore, how to achieve efficient, reliable and secure blockchain state verification and updates in a memory-constrained hardware environment is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0006] This application provides at least one blockchain data processing method and related apparatus. By introducing a circular buffer with a fixed storage length and receiving hash blocks layer by layer and performing hash operations and in-situ overwriting level by level based on the splicing order of the Merkel path proofs to be processed, this method is completely different from the processing mode in the prior art that requires loading the complete Merkel path proof data at once. This method effectively solves the memory compatibility risk of restricted hardware devices, ensures the stable operation of restricted hardware devices in blockchain state maintenance, and fundamentally overcomes the strong dependence of the blockchain state verification process in the prior art on memory capacity.

[0007] Firstly, this application provides a blockchain data processing method, applied to a target terminal device within a blockchain, comprising:

[0008] When an external terminal device sends a data packet of a transaction to be processed, a Merkel path proof to be processed, and a path index information to be processed to a target terminal device, the target terminal device receives the path index information to be processed and determines the splicing order of the Merkel path proof to be processed based on the path index information to be processed. The target terminal device receives hash blocks from the Merkel path proof to be processed layer by layer according to the splicing order of the Merkel path proof to be processed. It performs a hash operation on the current level hash block and the current data in the circular buffer. The corresponding hash operation result is stored in the circular buffer for hash operation processing of the next level hash block, until the Merkel root hash value corresponding to the Merkel path proof to be processed is obtained. The circular buffer is a region with a fixed storage length that is pre-set in the random access memory of the security element of the target terminal device. The fixed storage length is not less than the byte length of a single hash operation result. If the Merkel root hash value corresponding to the Merkel path proof to be processed matches the current state root of the target terminal device, the target terminal device receives the transaction data packet to be processed in order to execute the transaction to be processed, and updates the state root of the target terminal device according to the transaction data packet to be processed.

[0009] Secondly, this application also provides a blockchain data processing device, applied to a target terminal device within a blockchain, comprising: The determining unit is used to receive the path index information and determine the concatenation order of the Merkel path proofs to be processed based on the path index information when the external terminal device sends the transaction data packet, the Merkel path proof, and the path index information corresponding to the transaction to be processed to the target terminal device. The processing unit is used to receive hash blocks from the Merkel path proof to be processed layer by layer according to the splicing order of the Merkel path proof to be processed, and to perform hash operation on the current level hash block and the current data in the circular buffer. The corresponding hash operation result is stored in the circular buffer for hash operation processing of the next level hash block, until the Merkel root hash value corresponding to the Merkel path proof to be processed is obtained. The circular buffer is a region with a fixed storage length that is pre-set in the random access memory of the security element of the target terminal device. The fixed storage length is not less than the byte length of a single hash operation result. The update unit is used to receive the transaction data packet to be processed so as to execute the transaction to be processed if the Merkel root hash value corresponding to the Merkel path proof to be processed matches the current state root of the target terminal device, and update the state root of the target terminal device according to the transaction data packet to be processed.

[0010] Thirdly, this application also provides an electronic device, including: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and when the machine-readable instructions are executed by the processor, the blockchain data processing method provided in this application is executed.

[0011] Fourthly, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the blockchain data processing method provided in this application.

[0012] Fifthly, this application also provides a computer program product, including a computer program that is executed by a processor to perform the blockchain data processing method provided in this application.

[0013] In summary, this application provides a blockchain data processing method and related apparatus. By introducing a circular buffer with a fixed storage length, and based on the concatenation order of the Merkel path proofs to be processed, it receives hash blocks layer by layer, performs hash operations and in-situ overwriting level by level. This is completely different from the processing mode in the prior art that requires loading the complete Merkel path proof data at once. This application only needs to load the hash block of the current level each time, and can directly store the hash operation result of the current level into the circular buffer to participate in the calculation of the next level, thereby achieving state verification with high memory complexity. At this time, the fixed storage length of the circular buffer only needs to be no less than the byte length of a single hash operation result. Therefore, it can break through the physical limit of hardware memory, support state tree verification of arbitrary depth, effectively solve the memory adaptability risk of restricted hardware devices, ensure the stable operation of restricted hardware devices in blockchain state maintenance, and fundamentally overcome the strong dependence of the blockchain state verification process on memory capacity in the prior art.

[0014] Other advantages of this application will be explained in more detail in conjunction with the following description and figures.

[0015] It should be understood that the above description is merely an overview of the technical solution of this application, so as to enable a general understanding of the technical means of this application and to implement it in accordance with the contents of the specification. In order to make the above and other objects, features and advantages of this application more apparent and understandable, specific embodiments of this application are illustrated below. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below. The accompanying drawings are incorporated in and constitute a part of this specification. These drawings illustrate embodiments conforming to this application and are used together with the specification to explain the technical solutions of this application. It should be understood that the drawings only illustrate certain embodiments of this application and should not be considered as a limitation on the scope of protection. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort. Furthermore, the same reference numerals denote the same components throughout the drawings. In the drawings: Figure 1 A flowchart of a blockchain data processing method provided in this application embodiment; Figure 2 A schematic diagram of an inactive page write provided in an embodiment of this application; Figure 3 An asynchronous alignment diagram provided for an embodiment of this application; Figure 4 This is a schematic diagram of a blockchain data processing device provided in an embodiment of this application. Detailed Implementation

[0017] Exemplary embodiments of this application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of this application and to fully convey the scope of this application to those skilled in the art.

[0018] In the description of embodiments of this application, it should be understood that terms such as “comprising” or “having” are intended to indicate the presence of the disclosed features, figures, steps, behaviors, components, portions or combinations thereof in this specification, and do not exclude the possibility of the presence of one or more other features, figures, steps, behaviors, components, portions or combinations thereof.

[0019] Unless otherwise stated, " / " means "or". For example, A / B can mean A or B. In this article, "and / or" is merely a way of describing the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A alone, A and B at the same time, and B alone.

[0020] The terms "first," "second," etc., are used only for ease of description to distinguish identical or similar technical features and should not be construed as indicating or implying the relative importance or number of these technical features. Therefore, a feature defined by "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of embodiments of this application, unless otherwise stated, the term "multiple" means two or more.

[0021] With the deep integration of blockchain technology with fields such as the Internet of Things and mobile payments, the need to directly maintain and update the state of blockchain accounts through restricted hardware devices such as hardware wallets, NFC smart cards, and secure units with Bluetooth or other wireless communication is becoming increasingly urgent. These restricted hardware devices typically integrate security elements to provide hardware-level key storage and cryptographic computation capabilities to ensure the security of blockchain assets and transaction credentials.

[0022] In a typical blockchain state verification process, the terminal device needs to receive the pending transaction and its associated Merkle path proof sent by an external terminal (such as a mobile phone or card reader), and recalculate the Merkle root through a step-by-step hash operation. The calculated Merkle root is then compared with the currently stored state root to confirm the validity of the transaction. This process is the core technological foundation for implementing decentralized lightweight clients.

[0023] However, existing blockchain state verification schemes generally face significant memory compatibility risks when applied to the aforementioned constrained hardware environments. Specifically, existing Merkel verification methods require the verifying end to load the complete Merkel path proof data at once (e.g., the hash values ​​of all sibling nodes along the path from the leaf node corresponding to the transaction to be verified to the root node), and complete the hash concatenation and computation at all levels in memory. For the deep state trees commonly found in real-world blockchain systems (such as Ethereum's state tree, which can reach depths of 32 layers or more), the required memory overhead far exceeds the RAM capacity of mainstream security elements (typically only 16KB to 32KB). Under these resource constraints, loading the complete proof path at once can easily lead to memory overflow, resulting in system crashes and severely limiting the ability of constrained hardware devices to directly participate in blockchain state maintenance.

[0024] Therefore, how to achieve efficient, reliable and secure blockchain state verification and updates in a memory-constrained hardware environment is a technical problem that urgently needs to be solved in this field.

[0025] In view of this, this application provides a blockchain data processing method and related apparatus. By introducing a circular buffer with a fixed storage length, and based on the splicing order of the Merkel path proofs to be processed, it receives hash blocks layer by layer, performs hash operations and in-situ overwriting level by level. This is completely different from the processing mode in the prior art that requires loading the complete Merkel path proof data at once. It effectively solves the memory compatibility risk of restricted hardware devices, ensures the stable operation of restricted hardware devices in blockchain state maintenance, and fundamentally overcomes the strong dependence of the blockchain state verification process on memory capacity in the prior art.

[0026] The following describes a blockchain data processing method provided in this application through method embodiments, such as... Figure 1 As shown, Figure 1 This application provides a flowchart of a blockchain data processing method, which is applied to a target terminal device within a blockchain, particularly the aforementioned restricted hardware device. The method includes: S101. When the external terminal device sends the pending transaction data packet, pending Merkel path proof, and pending path index information corresponding to the pending transaction to the target terminal device, the target terminal device receives the pending path index information and determines the splicing order of the pending Merkel path proof according to the pending path index information.

[0027] Specifically, external terminal devices refer to external devices that communicate with the target terminal device, such as smartphones, POS machines, and card readers, and are responsible for initiating transaction requests and sending the data required for verification.

[0028] The target terminal device refers to a restricted hardware device that integrates a security element, such as a hardware wallet or an NFC smart card, used to maintain and update the state of blockchain accounts locally.

[0029] When a pending transaction occurs, the external terminal device can send a pending transaction data packet, a pending Merkel path proof, and pending path index information to the target terminal device. The pending transaction data packet includes a set of data containing specific information about the pending transaction (such as the transfer amount and the recipient's address), used to update the account status. The pending Merkel path proof includes a sequence of hash values ​​of all sibling nodes required from the leaf node corresponding to the pending transaction upwards to the root node, used to recalculate the Merkel root to verify the validity of the transaction. The pending path index information includes metadata indicating the concatenation order of each hash block in the pending Merkel path proof, used to correctly perform hash operations.

[0030] The target terminal device receives the path index information to be processed and determines the concatenation order of the Merkel path proof to be processed based on the path index information. The concatenation order refers to the order in which each level of hash block in the Merkel path proof to be processed performs hash operations with the intermediate results and the left and right concatenation relationships.

[0031] This step is a prerequisite for streaming verification, so that subsequent steps can read hash blocks layer by layer and perform in-situ overwrite calculations based on the splicing order of the Merkel path proof to be processed. Furthermore, determining the splicing order in advance eliminates the need for temporary parsing or caching of redundant data in subsequent calculation steps, thus improving verification efficiency.

[0032] S102. The target terminal device receives the hash blocks in the Merkel path proof to be processed layer by layer according to the splicing order of the Merkel path proof to be processed, and performs hash operation on the current level hash block and the current data in the circular buffer. The corresponding hash operation result is stored in the circular buffer for hash operation on the next level hash block, until the Merkel root hash value corresponding to the Merkel path proof to be processed is obtained.

[0033] Specifically, the circular buffer is a region with a fixed storage length that is pre-set in the random access memory of the security element of the target terminal device. The security element refers to an encryption chip with independent computing and storage capabilities integrated in the target hardware device. In this application, the fixed storage length is not less than the byte length of a single hash operation result. For example, in practical applications, the fixed storage length can be equal to the byte length of a single hash operation result (such as 32 bytes), which is suitable for limited hardware devices with RAM capacity of only 16KB to 32KB.

[0034] Using a fixed-length circular buffer pre-configured in the RAM of the secure element, hash blocks from the Merkel path proof to be processed are received layer by layer in the concatenation order. For the current level, a hash operation is performed between the current level's hash block and the current data stored in the circular buffer, where the current data in the circular buffer is the hash result of the previous level. Then, the hash result of the current level directly overwrites the old data in the circular buffer in place, for use by the next level. This process is repeated until all levels have been processed, finally yielding the Merkel root hash value corresponding to the Merkel path proof to be processed.

[0035] This step, through a streaming processing mechanism of receiving, computing, and overwriting layer by layer, reduces the high memory overhead of existing technologies, which require loading the entire Merkel path proof at once (growing linearly with the state tree depth to several KB or even tens of KB), to only a fixed-length (e.g., 32-byte) circular buffer, achieving constant-level (O(1)) memory complexity. Regardless of whether the state tree depth is 32 layers or higher, the required memory usage remains unchanged, thus completely breaking through the physical limitation of the RAM capacity of the security element on blockchain state verification and avoiding system crashes caused by memory overflow.

[0036] In one possible implementation, in S102, the target terminal device receives hash blocks from the Merkel path proof to be processed layer by layer based on the concatenation order of the Merkel path proof to be processed, and performs hash operations on the current level hash block and the current data in the circular buffer, including: Based on the concatenation order of the Merkel path proof to be processed, the target terminal device receives the hash value of a sibling node at the current level as the hash block at the current level, and performs a hash operation on the hash block at the current level and the current data in the circular buffer.

[0037] Specifically, in each level of processing, the target terminal device receives only one sibling node hash value from the external terminal as the current level's hash block, instead of receiving all the data from the entire path. Then, it performs a hash operation on this sibling node hash value and the existing current data in the circular buffer according to the concatenation order. After the operation is complete, the hash result is stored back in the circular buffer, overwriting the original current data, so that the next level can continue to use the circular buffer.

[0038] In one possible implementation, in S102, the target terminal device receives hash blocks from the Merkel path proof to be processed, layer by layer, based on the concatenation order of the Merkel path proof to be processed, including: The target terminal device receives the hash blocks in the Merkel path proof to be processed layer by layer through a contactless interface, Bluetooth interface or other communication interface, based on the splicing order of the Merkel path proof to be processed.

[0039] Specifically, during the verification process, the target terminal device can obtain the hash blocks required for each level from the external terminal in a step-by-step manner through a contactless interface (such as NFC) or Bluetooth interface, according to a pre-determined splicing order. The contactless interface is suitable for passive or low-power scenarios (such as NFC smart cards that rely on sensing fields for power), while the Bluetooth interface is suitable for active IoT security modules or those equipped with energy storage buffers.

[0040] By combining a layer-by-layer receiving mechanism with multiple communication interfaces, constrained hardware devices can stably and efficiently complete the verification of blockchain state under different power supply environments and communication distances.

[0041] It should be noted that, in addition to contactless interfaces or Bluetooth interfaces, other foreseeable communication interfaces can also be used in this application to receive hash blocks in the Merkel path proof to be processed.

[0042] In one possible implementation, step S102 involves performing a hash operation between the current-level hash block and the current data in the circular buffer, including: The target terminal device's hardware hash accelerator performs hash operations on the current level hash block and the current data in the circular buffer.

[0043] Specifically, the hardware hash accelerator integrated into the secure element is a dedicated circuit module for quickly calculating hash values. The hash operation is performed by the hardware hash accelerator inside the target terminal device. In practical applications, with the help of the hardware hash accelerator, the time for a single hash operation can be reduced to approximately 50 microseconds, and the overall verification of a 32-layer-deep state tree can be completed within 2 milliseconds.

[0044] S103. If the Merkel root hash value corresponding to the Merkel path proof to be processed matches the current state root of the target terminal device, the target terminal device receives the transaction data packet to be processed in order to execute the transaction to be processed, and updates the state root of the target terminal device according to the transaction data packet to be processed.

[0045] Specifically, the current state root of the target terminal device refers to the Merkle root hash value stored locally on the target terminal device that represents the current account state (such as balance, nonce, etc.).

[0046] When the Merkle root hash value obtained by the target terminal device through step S102 matches the current state root, it indicates the validity of the pending transaction and its existence in the current state tree. At this time, the target terminal device can receive the pending transaction data packet sent by the external terminal, execute the transaction indicated by the pending transaction, such as balance adjustment, random number increment, etc., and calculate a new state root based on the changed account status to complete the local update of the account status.

[0047] This step, through an atomic process of "verify first, then execute," ensures that only verified and valid transactions are accepted and executed, avoiding the waste of computing and storage resources on limited hardware devices caused by invalid or forged transactions. Simultaneously, verified transactions directly trigger state root updates, enabling target terminal devices to autonomously maintain account state consistency in offline or asynchronous environments without relying on the trust of external terminals.

[0048] In one possible implementation, the method further includes: The storage area of ​​the security element is pre-divided into a first storage page and a second storage page with the same structure; After executing the pending transaction and updating the state root of the target terminal device, the target terminal device writes the state data containing the updated state root into the inactive pages of the first and second storage pages, and performs integrity verification on the written state data. If the integrity verification is successful, the target terminal device modifies the status pointer, changing the inactive page to an active state.

[0049] Specifically, in passive near field communication (NFC) or low-power sensing environments, the power supply is instantaneous and uncertain. In-situ update methods in related technologies are prone to data corruption or being in an unpredictable intermediate state due to power loss during the writing process, i.e., data tearing.

[0050] In this regard, such as Figure 2 As shown, the storage area of ​​the security element is pre-divided into a first storage page and a second storage page with the same structure. The storage area of ​​the security element refers to the non-volatile storage area inside the security element, which is used to persistently store account status data. The first storage page (page A) and the second storage page (page B) refer to two storage units with the same storage structure that are pre-divided within the storage area and are physically isolated from each other. The first storage page and the second storage page are used alternately as active pages and inactive pages, respectively. The active page is the storage page that is currently pointed to by the status pointer and is used to provide valid status data. The inactive page (shadow page) is the shadow storage page that is not currently pointed to by the status pointer and is used to write new status data.

[0051] After verifying and executing the pending transaction and generating the updated state root, the target terminal device does not directly overwrite the state data in the currently active page. Instead, it writes the state data containing the updated state root to the inactive page of two pre-divided storage pages. After writing, the written data undergoes integrity verification, such as a Cyclic Redundancy Check (CRC), to confirm the correctness and integrity of the data. Only when the verification is successful and the data is confirmed to be correct does the target terminal device modify the state pointer using a single-cycle atomic instruction, making the inactive page the new active page.

[0052] In other words, this application adopts an inactive page pre-write strategy. The update process does not affect the valid data of the current active page. Only when the verification is successful will the target terminal device modify the status pointer through a single-cycle atomic instruction to make the inactive page become the new active page, thereby significantly improving the interaction robustness and data integrity of the limited hardware device in an energy-unstable environment.

[0053] In one possible implementation, the method further includes: If the integrity check fails, the target terminal device rolls back to the active page in the first and second storage pages according to the logical relationship of the status pointers, and restores the previous valid state with the data of the active page.

[0054] Specifically, after writing new status data to an inactive page and performing an integrity check, if the check fails, it indicates that the data was not transmitted completely, for example, due to interruption of the sensing field energy, communication errors, or data corruption caused by flash memory write abnormalities. The target terminal device does not use the invalid data in the inactive page, but automatically locates and rolls back to the current active page according to the logical relationship of the status pointer. The active page stores the previous valid status data before this update, and the system uses this data to restore the status, thereby ensuring that the account status always remains consistent and available.

[0055] In other words, by using dual-page shadow writing in conjunction with rollback logic, any failed update operation will not affect the valid data on the active page. Once an integrity check failure is detected, the system can automatically recover to the previous valid state without manual intervention or additional repair procedures. This significantly improves the robustness and reliability of constrained hardware devices in harsh power supply environments.

[0056] In one possible implementation, the method further includes: During the process of writing the state data containing the updated state root into the inactive pages of the first and second storage pages, the target terminal device monitors the voltage level provided by the external electromagnetic field in real time. If the voltage level is lower than the preset voltage threshold, the target terminal device releases the power of the hardware energy storage buffer circuit so that the status data can continue to be written to the inactive page or the status pointer can be rolled back to the active page.

[0057] Specifically, a hardware energy storage buffer circuit refers to a charge pump or capacitor energy storage unit integrated inside the target terminal device. It is used to release residual power to maintain the completion of critical operations when the external electromagnetic field energy fluctuates or is briefly interrupted. For example, in practical applications, a hardware energy storage buffer circuit can maintain a stable power supply for 200ms to 500ms after the external main power supply is turned off.

[0058] The target terminal device monitors the voltage level provided by the external electromagnetic field in real time. Once the voltage is detected to be lower than a preset voltage threshold, indicating an impending power outage or insufficient energy, the device immediately releases the pre-stored power in the hardware energy storage buffer circuit. This residual power is used for two possible operations: first, if the write operation is nearing completion, the stored power is used to continue writing state data to inactive pages until completion; second, if the write operation is still in its early stages or the stored power is insufficient to complete the write, the state pointer is rolled back to the original active page, and the update is abandoned. Through this dynamic decision-making, data integrity can be maximized even under critical energy conditions.

[0059] In one possible implementation, the method further includes: After the inactive page is brought to an active state, the target terminal device increments the counter value of the hardware monotonic counter in the secure element by one. The target terminal device generates an encrypted credential containing the updated state root, the current counter value of the hardware monotonic counter, and the target hardware unique identifier of the target terminal device, and sends the encrypted credential to the on-chain smart contract so that the blockchain network can perform asynchronous verification based on the current counter value and the maximum settled counter value recorded by the on-chain smart contract.

[0060] Specifically, a hardware monotonic counter is a unidirectionally incrementing counter built into a secure element and protected by physical circuitry. It is used to prevent replay attacks and ensure transaction order. After an inactive page is converted to an active state, the hardware monotonic counter in the secure element is incremented by one to ensure that the counter value strictly increases in one direction. The physical-level unidirectional incrementing characteristic of the hardware monotonic counter ensures that each state update corresponds to a unique sequence number.

[0061] The target terminal device forms an encrypted credential based on the updated state root, the current counter value of the hardware monotonic counter, and the target hardware unique identifier. The target hardware unique identifier refers to an immutable unique identifier (UID) bound inside the secure element chip. The introduction of the target hardware unique identifier prevents the risk of the encrypted credential being copied between different devices or used across devices.

[0062] The target terminal device sends the encrypted credential to an on-chain smart contract deployed on the blockchain. The on-chain smart contract can compare the current counter value in the encrypted credential with the maximum settled counter value (Max_Settled_Nonce) recorded in the contract, and execute asynchronous verification logic. For example, if the current counter value is equal to the maximum settled counter value plus one, then the anchor is accepted and updated.

[0063] On-chain smart contracts verify transactions by comparing the maximum settled counter value with the current counter value in the cryptographic certificate, enabling the blockchain network to process transaction certificates generated offline asynchronously, without requiring the target terminal device to be online in real time.

[0064] In one possible implementation, the method further includes: If the current counter value is greater than the maximum settled counter value plus one, the blockchain network will store the encrypted certificate in the pending sequence until the missing counter value is retransmitted and made up by the target terminal device.

[0065] Specifically, if the current counter value is greater than the maximum settled counter value plus one, such as... Figure 3 As shown, the current counter value is 103, and the maximum settled counter value is less than 103, which means that the local state is ahead of the on-chain anchor point, indicating that there is a counting gap. At this time, the blockchain network will not directly reject the certificate, but will store it in the pending processing sequence for temporary storage, and wait for the target terminal device to retransmit to fill in the missing counter value (such as filling in the missing 101 and 102). Only when all the encrypted certificates corresponding to the missing counter values ​​are submitted and verified can the originally temporarily stored encrypted certificate (103) be finally settled in order.

[0066] This step effectively solves the problem of discontinuous counters caused by network packet loss, disordered offline generation order, or delayed on-chaining of some encrypted credentials in asynchronous settlement scenarios, avoiding the blockage of settlement of all subsequent valid credentials due to the absence of a single encrypted credential. Furthermore, due to the unidirectional increment constraint of the hardware monotonic counter, the target terminal device cannot forge or skip intermediate counter values; therefore, gaps can only be caused by the loss of genuine encrypted credentials, thus ensuring security.

[0067] In one possible implementation, the method further includes: If the current counter value is less than the maximum settled counter value plus one, the target terminal device receives a synchronization proof generated by the blockchain network. The synchronization proof includes the target counter value, the updated state root, and the unique identifier of the target hardware. The target counter value is equal to the maximum settled counter value. The target terminal device performs synchronous verification through the target hardware unique identifier. When the target hardware unique identifier and the target terminal device's local hardware unique identifier are consistent, the counter value of the hardware monotonic counter is updated to the target counter value, and the state root of the target terminal device is updated to the updated state root.

[0068] Specifically, if the current counter value is less than the maximum settled counter value plus one, meaning the local state is lagging behind the on-chain anchor, the target terminal device receives a synchronization proof generated by the blockchain network. The synchronization proof includes at least the target counter value (the target counter value is equal to the maximum settled counter value), the corresponding updated state root, and the unique identifier of the target hardware.

[0069] The target terminal device first verifies whether the target hardware unique identifier in the synchronization proof is consistent with its own local hardware unique identifier. After the verification is successful, the device jumps to update the counter value of the hardware monotonic counter to the target counter value, where the target counter value is equal to the maximum settled counter value, thereby synchronizing the target terminal device with the chain and updating the local state root to the updated state root in the proof.

[0070] It should be noted that the above jump update strictly follows the following constraints: Unidirectional increment constraint: Modification instructions for hardware monotonic counters are configured at the logic level to only allow "increment" operations. Any attempt to modify the counter value to a smaller value through synchronous proof will be forcibly intercepted by the hardware comparator before the instruction is executed.

[0071] Three-state strong consistency constraint: After a jump update, the secure element must simultaneously update its internal state root to ensure consistency with the updated state root in the synchronization proof. Only after the hardware monotonic counter's value has synchronously flipped with the local state root can the target terminal device allow the generation of subsequent incremental transaction credentials based on the new state.

[0072] Physical-level atomic commit constraint: The final update step (i.e., modifying the counter value of the hardware monotonic counter and the local state root) must be executed as a single-cycle atomic instruction. In environments with extremely unstable induced energy, if the completion of this atomic commit cannot be guaranteed, the security file will utilize the power of the hardware energy storage buffer circuit to prioritize state protection rather than blindly updating, thereby avoiding the risk of logic tearing.

[0073] Through the aforementioned forced alignment mechanism, this application provides a secure recovery path for restricted hardware devices, enabling them to recover to a state consistent with the on-chain anchor point even after experiencing power failure rollback, state loss, or cloning attacks. This avoids the risk of permanent device failure and strictly prevents rollback attacks and credential reuse across devices.

[0074] In one possible implementation, the synchronous proof also includes signature information and expiration information; The target terminal device performs synchronous verification through the target hardware unique identifier, signature information, and expiration information. When the target hardware unique identifier and the target terminal device's local hardware unique identifier are consistent, the signature information is successfully verified, and the expiration information meets the preset expiration conditions, the counter value of the hardware monotonic counter is updated to the target counter value, and the state root of the target terminal device is updated to the updated state root.

[0075] Specifically, in addition to the target counter value, the updated state root, and the unique identifier of the target hardware, the synchronization proof may also include signature information and expiration information. The signature information refers to the result of digitally signing the content of the synchronization proof, which is usually composed of multi-signatures of on-chain contract validators or signatures of administrative authority, and is used to prove the legality of the source and the integrity of the content of the synchronization proof. The expiration information refers to the validity period limit or associated block height limit contained in the synchronization proof, which is used to prevent the synchronization proof from being reused indefinitely or used outdated.

[0076] After receiving the synchronization proof, the target terminal device performs multi-dimensional verification: First, it verifies whether the target hardware unique identifier in the synchronization proof matches the local hardware unique identifier; second, it uses a hardware accelerator to verify the signature information, confirming that the proof originates from a legitimate signature of an on-chain contract validator, such as a multi-signature or administrative permission signature; third, it checks whether the expiration information meets preset conditions, such as the validity period not having expired and the block height not exceeding the limit. Only when all verifications pass will the device jump to update the counter value of the hardware monotonic counter to the target counter value and synchronize the local state root to the updated state root in the proof.

[0077] The multi-dimensional verification mechanism effectively prevents cross-device reuse of synchronous proofs (UID verification), forgery attacks (signature verification), and replay expiration attacks (expiration verification), providing a highly secure forced alignment scheme for restricted hardware devices in abnormal state recovery scenarios.

[0078] In one possible implementation, the state root of the target terminal device is stored in the protected storage area of ​​the security element.

[0079] Specifically, the secure element, as an independent hardware encryption chip, has hardware-level access control and anti-tampering features in its protected storage area. External programs cannot directly read or modify it, so the state root of the target terminal device can be stored in the protected storage area of ​​the secure element. During the verification process, the target terminal device reads the current state root from the protected storage area for comparison; after the transaction is executed, the new updated state root is also written to the protected storage area.

[0080] By storing the state root in a protected storage area, attackers are effectively prevented from tampering with the state root through software vulnerabilities or physical probes. This ensures the credibility of the state verification process and the confidentiality and integrity of account data, providing hardware-level security protection for restricted hardware devices in offline asynchronous scenarios.

[0081] The method of this application will be explained below through specific embodiments: 1. Example 1 - Status Update System Based on Passive NFC Smart Card In this embodiment, the target terminal device consists of a passive NFC card (with an integrated secure element) and a smart terminal with NFC functionality. The RAM capacity of the secure element is limited to 32KB.

[0082] Hardware components include: a contactless communication interface module, a hardware SHA-256 accelerator as a hardware hash accelerator, a non-volatile flash memory control module as a protected storage area, and a hardware monotonic counter circuit.

[0083] Key processes: 101: The external terminal device sends a transaction request and a Merkle proof with a depth of 32 layers.

[0084] 102: Secure Element Call Verification Mechanism. A 32-byte circular buffer is allocated, and path hashes are read sequentially. A single hash operation takes approximately 50μs, and the overall verification is completed within 2ms.

[0085] 103: After successful verification, write the updated status to inactive page B.

[0086] 104: If the NFC sensing field strength weakens, the status monitoring unit triggers an IRQ interrupt before the voltage drops to the voltage threshold V_min. Since the pointer has not yet flipped at this time, the old state of page A remains intact, and the system can safely restore on the next sensing.

[0087] 2. Example 2 - Active IoT Security Module with Energy Storage Buffer In this embodiment, the safety module integrates a micro charge pump energy storage circuit as a hardware energy storage buffer circuit, which can maintain a stable power supply for 200ms to 500ms after the external main power supply is cut off.

[0088] Core data structures: 32-byte Merkle root hash (state_root), 4-byte current value of hardware monotonic (nonce), 1-byte state pointer (page_ptr), and 4-byte cyclic redundancy check value (crc_val).

[0089] Exception handling branch: If a power failure occurs during the writing of a non-active page (shadow page), the micro charge pump energy storage circuit releases the residual power. If the writing fails to complete and the CRC check fails, the power-on self-check program will detect that the crc_val does not match the data, thus abandoning the current non-active page (shadow page) and keeping the system status pointer pointing to the original active page, effectively preventing the risk of data tearing.

[0090] If it is detected that the value of the internal hardware monotonic counter (N_HW) is inconsistent with the maximum settled counter value (N_ON) recorded by the on-chain contract anchor, especially when N_HW < N_ON due to an unexpected rollback or a cloning attempt after loss of the device, the security element (SE) will trigger the "Hardware Jump Alignment" mechanism. Under this mechanism, the system will reject the generation of new signature credentials based on the current stale state until the state is forced to align through a verified and valid on-chain synchronization proof (State_Sync_Proof).

[0091] In summary, the present application provides a blockchain data processing method. By introducing a circular buffer with a fixed storage length and based on the splicing order of the Merkle path proofs to be processed, hash blocks are received layer by layer, hash operations are performed level by level, and in-place coverage is carried out. This is completely different from the processing mode in the prior art that requires loading the complete Merkle path proof data at once. In the present application, only the hash block of the current level needs to be loaded each time, and the hash operation result of the current level can be directly stored in the circular buffer to participate in the calculation of the next level, thereby achieving state verification with a relatively high memory complexity. At this time, the fixed storage length of the circular buffer only needs to be not less than the byte length of a single hash operation result. Therefore, it can break through the physical limit of the hardware memory, support the verification of state trees of any depth, effectively solve the memory adaptability risk of limited hardware devices, ensure the stable operation of limited hardware devices in blockchain state maintenance, and fundamentally overcome the strong dependence of the blockchain state verification process in the prior art on the memory capacity.

[0092] In the description of this specification, the descriptions made with reference to terms such as "some possible implementation manners", "some implementation manners", "examples", "specific examples", or "some examples" etc. mean that the specific features, structures, materials, or characteristics described in connection with the implementation manner or example are included in at least one implementation manner or example of the present application, and the above terms do not necessarily represent the same implementation manner or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in a suitable manner in any one or more implementation manners or examples. In addition, without contradiction, those skilled in the art can combine and combine the different implementation manners or examples described in this specification and the features of different implementation manners or examples.

[0093] The method flowcharts for embodiments of this application describe certain operations as different steps performed in a certain order. Such flowcharts are illustrative and not restrictive. Some steps described herein may be grouped together and performed in a single operation, or some steps may be divided into multiple sub-steps, and some steps may be performed in an order different from that shown herein. The various steps shown in the flowcharts may be implemented in any way by any circuit structure and / or tangible mechanism (e.g., by software running on a computer device, hardware (e.g., logic functions implemented by a processor or chip), and / or any combination thereof).

[0094] Those skilled in the art will understand that in the methods described in the above specific embodiments, the order in which the steps are written does not imply a strict execution order, and the specific execution order of each step should be determined by its function and possible internal logic.

[0095] Based on the foregoing Figures 1-3 The blockchain data processing apparatus provided in this application will be described below through device embodiments. Figure 4 This application provides a schematic diagram of a blockchain data processing device, applied to a target terminal device within a blockchain, such as... Figure 4 As shown, the blockchain data processing device 400 includes: The determining unit 401 is used to receive the path index information and determine the concatenation order of the Merkel path proofs to be processed based on the path index information when the external terminal device sends the transaction data packet, the Merkel path proof, and the path index information corresponding to the transaction to be processed to the target terminal device. The operation unit 402 is used to receive hash blocks in the Merkel path proof to be processed layer by layer according to the splicing order of the Merkel path proof to be processed, and to perform hash operation on the current level hash block and the current data in the circular buffer. The corresponding hash operation result is stored in the circular buffer for hash operation on the next level hash block, until the Merkel root hash value corresponding to the Merkel path proof to be processed is obtained. The circular buffer is a region with a fixed storage length that is pre-set in the random access memory of the security element of the target terminal device. The fixed storage length is not less than the byte length of a single hash operation result. The update unit 403 is configured to receive the transaction data packet to be processed so as to execute the transaction to be processed if the Merkel root hash value corresponding to the Merkel path proof to be processed matches the current state root of the target terminal device, and update the state root of the target terminal device according to the transaction data packet to be processed.

[0096] In one possible implementation, the arithmetic unit 402 is used for: Based on the concatenation order of the Merkel path proofs to be processed, the hash value of a sibling node at the current level is received as the hash block of the current level, and the hash block of the current level is hashed with the current data in the circular buffer.

[0097] In one possible implementation, the arithmetic unit 402 is used for: Based on the concatenation order of the Merkel path proofs to be processed, the hash blocks in the Merkel path proofs to be processed are received layer by layer through a contactless interface or Bluetooth interface.

[0098] In one possible implementation, the arithmetic unit 402 is used for: The target terminal device's hardware hash accelerator performs hash operations on the current level hash block and the current data in the circular buffer.

[0099] In one possible implementation, the blockchain data processing device 400 further includes a storage unit for: The storage area of ​​the security element is pre-divided into a first storage page and a second storage page with the same structure; After executing the pending transaction and updating the state root of the target terminal device, the state data containing the updated state root is written to the inactive page in the first storage page and the second storage page, and the integrity of the written state data is verified. If the integrity check is successful, modify the status pointer and change the inactive page to an active state.

[0100] In one possible implementation, the storage unit is also used for: If the integrity check fails, the system rolls back to the active page in the first and second storage pages according to the logical relationship of the status pointers, and restores the previous valid state with the data of the active page.

[0101] In one possible implementation, the storage unit is also used for: During the process of writing the state data containing the updated state root into the inactive pages of the first and second storage pages, the target terminal device monitors the voltage level provided by the external electromagnetic field in real time. If the voltage level is lower than the preset voltage threshold, the target terminal device releases the power of the hardware energy storage buffer circuit so that the status data can continue to be written to the inactive page or the status pointer can be rolled back to the active page.

[0102] In one possible implementation, the blockchain data processing device 400 further includes an asynchronous verification unit for: After an inactive page is brought to an active state, the value of the hardware monotonic counter in the secure element is incremented by one. Generate an encrypted credential containing the updated state root, the current counter value of the hardware monotonic counter, and the target hardware unique identifier of the target terminal device, and send the encrypted credential to the on-chain smart contract so that the blockchain network can perform asynchronous verification based on the current counter value and the maximum settled counter value recorded by the on-chain smart contract.

[0103] In one possible implementation, a blockchain network is used for: After the target terminal sends the encrypted certificate to the on-chain smart contract, if the current counter value in the encrypted certificate is greater than the maximum settled counter value recorded by the on-chain smart contract plus one, the encrypted certificate is stored in the pending processing sequence until the missing counter value is retransmitted and supplemented by the target terminal device.

[0104] In one possible implementation, the asynchronous verification unit is also used for: After the target terminal sends the encrypted certificate to the on-chain smart contract, if the current counter value in the encrypted certificate is less than the maximum settled counter value recorded by the on-chain smart contract plus one, the target terminal device receives the synchronization proof generated by the blockchain network. The synchronization proof includes the target counter value, the updated state root, and the unique identifier of the target hardware. The target counter value is equal to the maximum settled counter value. Synchronous verification is performed using the unique identifier of the target hardware. When the unique identifier of the target hardware matches the unique identifier of the local hardware of the target terminal device, the counter value of the hardware monotonic counter is updated to the target counter value, and the state root of the target terminal device is updated to the updated state root.

[0105] In one possible implementation, the synchronous proof also includes signature information and expiration information; Asynchronous verification unit, used for: The unique identifier of the target hardware, signature information, and expiration information are synchronously verified. When the unique identifier of the target hardware is consistent with the local unique identifier of the target terminal device, the signature information is successfully verified, and the expiration information meets the preset expiration conditions, the counter value of the hardware monotonic counter is updated to the target counter value, and the state root of the target terminal device is updated to the updated state root.

[0106] It should be noted that the apparatus in the embodiments of this application can implement each process of the aforementioned method and achieve the same effect and function, which will not be elaborated here.

[0107] This application also provides an electronic device, including a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the following processing is performed: When an external terminal device sends a data packet of the transaction to be processed, a Merkel path proof to be processed, and path index information to be processed to the target terminal device, the system receives the path index information to be processed and determines the splicing order of the Merkel path proof to be processed based on the path index information to be processed. The target terminal device receives hash blocks from the Merkel path proof to be processed layer by layer according to the splicing order of the Merkel path proof to be processed. It performs a hash operation on the current level hash block and the current data in the circular buffer. The corresponding hash operation result is stored in the circular buffer for hash operation processing of the next level hash block, until the Merkel root hash value corresponding to the Merkel path proof to be processed is obtained. The circular buffer is a region with a fixed storage length that is pre-set in the random access memory of the security element of the target terminal device. The fixed storage length is not less than the byte length of a single hash operation result. If the Merkel root hash value corresponding to the Merkel path proof to be processed matches the current state root of the target terminal device, the target terminal device receives the transaction data packet to be processed in order to execute the transaction to be processed, and updates the state root of the target terminal device according to the transaction data packet to be processed.

[0108] This application also provides a computer-readable storage medium storing a computer program. When a processor runs the computer program, it executes the steps of the blockchain data processing method described in the above-described method embodiments. The storage medium can be either volatile or non-volatile computer-readable storage.

[0109] This application also provides a computer program product, including a computer program carrying program code. The program code includes instructions that can be used to execute the steps of the blockchain data processing method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0110] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0111] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, the descriptions of the apparatus, device, and computer-readable storage medium embodiments are simplified because they are substantially similar to the method embodiments; relevant details can be found in the descriptions of the method embodiments.

[0112] The apparatus, device, and computer-readable storage medium provided in the embodiments of this application correspond one-to-one with the method. Therefore, the apparatus, device, and computer-readable storage medium also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the method have been described in detail above, the beneficial technical effects of the apparatus, device, and computer-readable storage medium will not be repeated here.

[0113] While the spirit and principles of this application have been described above with reference to several specific embodiments, it should be understood that this application is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined. This application is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. A blockchain data processing method, characterized in that, Target terminal devices used within the blockchain include: When an external terminal device sends a data packet of a transaction to be processed, a Merkel path proof to be processed, and path index information to be processed to the target terminal device, the target terminal device receives the path index information to be processed and determines the splicing order of the Merkel path proof to be processed based on the path index information to be processed. The target terminal device receives hash blocks from the Merkel path proof to be processed layer by layer based on the concatenation order of the Merkel path proof to be processed. It performs a hash operation on the current level hash block and the current data in the circular buffer, and stores the corresponding hash operation result in the circular buffer for hash operation on the next level hash block, until the Merkel root hash value corresponding to the Merkel path proof to be processed is obtained. The circular buffer is a region with a fixed storage length that is pre-set in the random access memory of the security element of the target terminal device. The fixed storage length is not less than the byte length of a single hash operation result. If the Merkle root hash value corresponding to the Merkle path proof to be processed matches the current state root of the target terminal device, the target terminal device receives the transaction data packet to be processed in order to execute the transaction to be processed, and updates the state root of the target terminal device according to the transaction data packet to be processed.

2. The method according to claim 1, characterized in that, The target terminal device receives hash blocks from the Merkel path proof to be processed layer by layer based on the concatenation order of the Merkel path proof to be processed, and performs hash operations on the current level hash block and the current data in the circular buffer, including: The target terminal device receives the hash value of a sibling node at the current level as the current level hash block based on the splicing order of the Merkel path proof to be processed, and performs hash operation on the current level hash block and the current data in the circular buffer.

3. The method according to claim 1, characterized in that, The target terminal device receives the hash blocks in the Merkel path proof to be processed layer by layer based on the concatenation order of the Merkel path proof to be processed, including: The target terminal device receives the hash blocks in the Merkel path proof to be processed layer by layer through a contactless interface or Bluetooth interface, based on the splicing order of the Merkel path proof to be processed.

4. The method according to claim 1, characterized in that, The step of performing a hash operation between the current level hash block and the current data in the circular buffer includes: The target terminal device's hardware hash accelerator performs hash operations on the current level hash block and the current data in the circular buffer.

5. The method according to claim 1, characterized in that, The method further includes: The storage area of ​​the security element is pre-divided into a first storage page and a second storage page with the same structure; After executing the pending transaction and updating the state root of the target terminal device, the target terminal device writes the state data containing the updated state root into the inactive pages of the first storage page and the second storage page, and performs an integrity check on the written state data. If the integrity verification is successful, the target terminal device modifies the status pointer and changes the inactive page to an active state.

6. The method according to claim 5, characterized in that, The method further includes: If the integrity check fails, the target terminal device rolls back to the active page in the first storage page and the second storage page according to the logical relationship of the status pointer, and restores the previous valid state with the data of the active page.

7. The method according to claim 6, characterized in that, The method further includes: During the process of writing state data containing the updated state root into the inactive pages of the first storage page and the second storage page, the target terminal device monitors the voltage level provided by the external electromagnetic field in real time. If the voltage level is lower than a preset voltage threshold, the target terminal device releases power from the hardware energy storage buffer circuit to continue writing the status data to the inactive page or roll back the status pointer to the active page.

8. The method according to claim 5, characterized in that, The method further includes: After the inactive page is brought to an active state, the target terminal device increments the counter value of the hardware monotonic counter in the security element by one. The target terminal device generates an encrypted credential containing the updated state root, the current counter value of the hardware monotonic counter, and the target hardware unique identifier of the target terminal device, and sends the encrypted credential to the on-chain smart contract so that the blockchain network can perform asynchronous verification based on the current counter value and the maximum settled counter value recorded by the on-chain smart contract.

9. The method according to claim 8, characterized in that, After the target terminal device sends the encrypted certificate to the on-chain smart contract, the method further includes: If the current counter value in the encrypted certificate is greater than the maximum settled counter value recorded by the on-chain smart contract plus one, the blockchain network will store the encrypted certificate in the pending processing sequence until the missing counter value is retransmitted and supplemented by the target terminal device.

10. The method according to claim 8, characterized in that, After the target terminal device sends the encrypted certificate to the on-chain smart contract, the method further includes: If the current counter value in the encrypted certificate is less than the maximum settled counter value recorded by the on-chain smart contract plus one, the target terminal device receives a synchronization proof generated by the blockchain network. The synchronization proof includes the target counter value, the updated state root, and the target hardware unique identifier. The target counter value is equal to the maximum settled counter value. The target terminal device performs synchronous verification through the target hardware unique identifier, and when the target hardware unique identifier and the local hardware unique identifier of the target terminal device are consistent, the counter value of the hardware monotonic counter is updated to the target counter value, and the state root of the target terminal device is updated to the updated state root.

11. The method according to claim 10, characterized in that, The synchronization certificate also includes signature information and time limit information; The target terminal device performs synchronous verification through the target hardware unique identifier, and when the target hardware unique identifier and the target terminal device's local hardware unique identifier are consistent, updates the counter value of the hardware monotonic counter to the target counter value, and updates the state root of the target terminal device to the updated state root, including: The target terminal device performs synchronous verification using the target hardware unique identifier, the signature information, and the expiration information. When the target hardware unique identifier and the target terminal device's local hardware unique identifier are consistent, the signature information is successfully verified, and the expiration information meets the preset expiration conditions, the counter value of the hardware monotonic counter is updated to the target counter value, and the state root of the target terminal device is updated to the updated state root.

12. The method according to claim 1, characterized in that, The state root of the target terminal device is stored in the protected storage area of ​​the security element.

13. A blockchain data processing device, characterized in that, Target terminal devices used within the blockchain include: The determining unit is configured to receive the pending path index information and determine the concatenation order of the pending Merkel path proof based on the pending path index information when the external terminal device sends the pending transaction data packet, pending Merkel path proof, and pending path index information corresponding to the pending transaction to the target terminal device. The processing unit is configured to receive hash blocks from the Merkel path proof to be processed layer by layer based on the concatenation order of the Merkel path proof to be processed, and perform hash operation on the current level hash block and the current data in the circular buffer. The corresponding hash operation result is stored in the circular buffer for hash operation on the next level hash block, until the Merkel root hash value corresponding to the Merkel path proof to be processed is obtained. The circular buffer is a region with a fixed storage length that is pre-set in the random access memory of the security element of the target terminal device. The fixed storage length is not less than the byte length of a single hash operation result. The update unit is configured to receive the transaction data packet to be processed so as to execute the transaction to be processed if the Merkel root hash value corresponding to the Merkel path proof to be processed matches the current state root of the target terminal device, and update the state root of the target terminal device according to the transaction data packet to be processed.

14. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the blockchain data processing method as described in any one of claims 1 to 12 is performed.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the blockchain data processing method as described in any one of claims 1 to 12.

16. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, performs the blockchain data processing method as described in any one of claims 1 to 12.

Images