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

Abstract

The application discloses a kind of data processing method, device and readable medium based on blockchain, the blockchain includes terminal equipment, and the terminal equipment includes main processor and coprocessor;The method comprises: generating cryptography operation instruction according to business transaction instruction by main processor, and issuing cryptography operation instruction to coprocessor;Cryptography operation instruction is received by coprocessor, and the instruction type of cryptography operation instruction is identified;The instruction type is used to indicate the cryptography operation type corresponding to cryptography operation instruction;Business transaction instruction is executed by main processor, and cryptography operation instruction is executed according to instruction type by coprocessor.This scheme realizes the parallel execution of business transaction and cryptography operation by the collaborative architecture of main processor and integrated coprocessor, greatly improves the overall data processing speed and concurrent capability of blockchain terminal, avoids that main processor is blocked by a large number of cryptography operation tasks.

Description

Technical Field

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

[0002] With the widespread application of blockchain technology, the types and numbers of blockchain terminal devices are growing rapidly. These terminal devices need to frequently perform a large number of cryptographic operations, but existing embedded processors require a large number of instruction cycles when performing cryptographic operations, resulting in high latency and power consumption in transaction signing, verification, or block verification processes, and low data processing efficiency. Summary of the Invention

[0003] The purpose of this application is to provide a blockchain-based data processing method, apparatus, device, and readable medium to improve data processing speed.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part by practice of this application.

[0005] According to one aspect of the embodiments of this application, a data processing method based on blockchain is provided, wherein the blockchain includes a terminal device, the terminal device includes a main processor and a coprocessor, the main processor is used to process business transactions, and the coprocessor is integrated on the main processor;

[0006] The method includes: The main processor generates cryptographic operation instructions based on the business transaction instructions and sends the cryptographic operation instructions to the coprocessor; the cryptographic operation instructions are used to perform encrypted calculations on the business transaction data corresponding to the business transaction instructions. The coprocessor receives the cryptographic operation instructions and identifies the instruction type of the cryptographic operation instructions; the instruction type is used to indicate the cryptographic operation type corresponding to the cryptographic operation instructions. The main processor executes the business transaction instructions, and the coprocessor executes the cryptographic operation instructions according to the instruction type.

[0007] According to one aspect of the embodiments of this application, a blockchain-based data processing apparatus is provided, comprising: The instruction generation module is used to generate cryptographic operation instructions based on the business transaction instructions through the main processor, and to send the cryptographic operation instructions to the coprocessor; the cryptographic operation instructions are used to perform encrypted calculations on the business transaction data corresponding to the business transaction instructions; A type identification module is used to receive the cryptographic operation instructions through the coprocessor and identify the instruction type of the cryptographic operation instructions; the instruction type is used to indicate the cryptographic operation type corresponding to the cryptographic operation instructions. The instruction execution module is used to execute the business transaction instruction through the main processor and to execute the cryptographic operation instruction according to the instruction type through the coprocessor.

[0008] According to one aspect of the embodiments of this application, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the blockchain-based data processing method provided in any embodiment of this application.

[0009] According to one aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor executes the executable instructions to cause the electronic device to perform a blockchain-based data processing method according to any embodiment of this application.

[0010] According to one aspect of the embodiments of this application, a computer program product or computer program is provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the blockchain-based data processing method in any embodiment of this application.

[0011] In the technical solution provided in this application embodiment, the main processor first generates cryptographic operation instructions based on the business transaction instructions and sends the cryptographic operation instructions to the coprocessor. The cryptographic operation instructions are used to perform encrypted calculations on the business transaction data corresponding to the business transaction instructions. Subsequently, the coprocessor receives the cryptographic operation instructions and identifies the instruction type of the cryptographic operation instructions. The instruction type is used to indicate the cryptographic operation type corresponding to the cryptographic operation instructions. Finally, the main processor executes the business transaction instructions, and the coprocessor executes the cryptographic operation instructions according to the instruction type. Thus, through the collaborative architecture of the main processor and the integrated coprocessor, parallel execution of business transactions and cryptographic operations is achieved, significantly improving the overall data processing speed and concurrency capability of the blockchain terminal and avoiding the main processor being blocked by a large number of cryptographic operations.

[0012] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0013] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0014] Figure 1 The diagram illustrates a blockchain terminal device architecture provided in one embodiment of this application.

[0015] Figure 2 A flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application is shown.

[0016] Figure 3 A schematic diagram illustrating the structure of a blockchain-based data processing device provided in an embodiment of this application is shown.

[0017] Figure 4 A schematic diagram of the computer system architecture used to implement the technical solution of this application is shown. Detailed Implementation

[0018] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0019] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0020] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0021] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0022] Figure 1 The diagram illustrates a blockchain terminal device architecture provided in one embodiment of this application.

[0023] like Figure 1 As shown, the blockchain terminal device in this embodiment includes a RISC-V (Reduced Instruction Set Computing-V) main processor and a coprocessor, which can be integrated on the main processor.

[0024] The RISC-V main processor achieves instruction-level interaction with the coprocessor through a custom instruction interface. This custom instruction interface is used by the RISC-V main processor to generate cryptographic operation instructions based on business transaction instructions received from the blockchain application according to user business requests, and then sends these instructions to the coprocessor. For example, the custom instruction interface can be a RoCC (Rocket Custom Coprocessor) interface or an ALU (Arithmetic Logic Unit Bypass).

[0025] Meanwhile, the coprocessor consists of four core functional modules: an instruction interface and distribution module, three major cryptographic operation execution clusters, a dedicated blockchain temporary storage memory, and a security protection module. These modules work collaboratively through internal data pathways to form a complete closed loop for cryptographic operation execution. The following is a detailed explanation: The instruction interface and distribution module is responsible for receiving cryptographic operation instructions generated and issued by the RISC-V main processor; then it decodes the instruction to obtain the corresponding instruction type (such as hash operation instruction, signature operation instruction, post-quantum cryptography operation instruction, etc.) and information such as the memory address, key index, and return address of the business transaction data, and then distributes them in parallel to the corresponding hardware execution unit according to the instruction type to start the cryptographic operation.

[0026] The hash operation cluster is a dedicated hardware unit for performing hash operations, comprising submodules such as a multi-pipeline hash engine, a dedicated Merkle tree execution unit, and a proof-of-work auxiliary unit. The multi-pipeline hash engine supports various commonly used hash algorithms in blockchains, including SHA-256 (Secure Hash Algorithm 256-bit), Keccak / SHA-3 (Keccak / Secure Hash Algorithm 3), and Blake2b / Blake3 hash algorithms. The multi-pipeline architecture allows the hash operation cluster to process multiple bytes of data per clock cycle, significantly improving hash operation throughput. The dedicated Merkle tree execution unit has a built-in Merkle root operation pipeline, supporting fast Merkle root computation or Merkle proof verification. This unit can process multiple hash branches in parallel, performing SPV (Simplified Payment Verification) verification and block synchronization processes for light nodes. The Proof-of-Work (PoW) auxiliary unit provides hardware support for Nonce (Number Only Used Once) incrementing and hash recalculation for the PoW consensus algorithm. For example, in a Proof-of-Work computation scenario, this unit can automatically increment the Nonce value and repeatedly calculate the block header hash until a Nonce that meets the difficulty target is found or the preset iteration limit is reached.

[0027] The signature / verification execution cluster performs elliptic curve cryptography (ECC) operations and includes submodules such as an elliptic curve cryptography engine, a two-domain arithmetic unit, and a batch signature verification execution unit. The elliptic curve cryptography engine implements commonly used elliptic curve algorithms in blockchain and supports core operations such as dot multiplication and dot addition for complete signature generation or verification. The two-domain arithmetic unit supports elliptic curve operations in both prime and binary fields to meet the needs of different blockchain protocols. The batch signature verification execution unit is a dedicated parallel signature verification data path designed for scenarios where multiple transaction signatures are verified in batches within blockchain nodes. This unit utilizes the linear combination property of elliptic curve dot multiplication (such as the Strauss algorithm) to merge the verification of multiple signatures into a finite number of dot addition and dot multiplication operations, thereby significantly improving transaction throughput.

[0028] The post-quantum cryptography cluster is used to execute lattice-based quantum-resistant cryptographic algorithms, comprising submodules such as the NTT (Number Theoretic Transform) / INTT (Inverse Number Theoretic Transform) execution engine, a quantum-resistant signature execution unit, and a hybrid signature support unit. The NTT / INTT execution engine can perform polynomial multiplication operations on lattice-based cryptographic algorithms (such as the algebraic lattice cryptographic suite-Kyber algorithm, Dilithium's algorithm, and the Fast Fourier Compact Signature Algorithm for lattices). This engine also supports custom configuration parameters, including modulus and polynomial dimension, to adapt to different security levels. The quantum-resistant signature execution unit incorporates dedicated hardware for Dilithium signature generation and verification, supporting fast signing and verification of blockchain transactions in post-quantum migration scenarios. The hybrid signature support unit supports the combination logic of traditional ECC (Elliptic Curve Cryptography) signatures and post-quantum signatures to achieve hybrid transaction signing modes.

[0029] The dedicated blockchain temporary storage adopts an on-chip high-speed memory architecture, integrating a DMA (Direct Memory Access) controller. Its core functions include: temporarily storing transaction data to be processed, block header data, and intermediate computation results to reduce the number of accesses to external DDR (Double Data Rate) memory, lower memory access latency, and improve computational efficiency. The DMA controller enables batch loading and storage of data, supporting batch reading of data to be processed from external DDR memory and batch writing back of results after computation, thus significantly improving data transmission efficiency in large-scale data processing scenarios. Simultaneously, as a unified data interaction hub for the three major computing clusters, each cluster can read data to be processed from the temporary storage, write the results back to the temporary storage after computation, and then complete data interaction with the main processor or external DDR memory via the DMA data bus.

[0030] The key management and security protection module is responsible for the secure storage of keys and protection against side-channel attacks. It includes sub-modules such as a key storage isolation unit, a true random number generator, and a side-channel attack protection unit. The key storage isolation unit directly stores the private key in non-volatile memory or write-only registers within the coprocessor. The RISC-V main processor cannot directly read it, but the coprocessor can read the corresponding private key fragment based on the private key index and perform masking on the internal bus to prevent malware theft. The true random number generator integrates a true random number generator architecture compliant with the NIST SP800-90B standard. This generator generates a raw random bitstream by collecting physical noise sources (such as ring oscillator jitter), and generates high-quality true random numbers after online self-testing and entropy extraction. The side-channel attack protection unit introduces random delay, masking techniques, and power balancing circuits in critical operations (especially signature generation) to prevent external attacks and protect user assets. It should be noted that the protection mechanism of the side-channel attack protection unit is deeply bound to the execution flow of cryptographic operation instructions and can be automatically activated during instruction execution.

[0031] Based on the aforementioned coprocessor architecture, each module can collaboratively complete the entire process of cryptographic operations: First, it receives custom cryptographic operation instructions from the RISC-V main processor through the instruction interface and distribution module, and decodes the instructions; according to the type of the decoded instructions, the cryptographic operation instructions are distributed to the corresponding operation clusters; simultaneously, the blockchain-dedicated temporary storage memory reads the business transaction data (such as transaction data and block header data) corresponding to the cryptographic operation instructions in batches from external DDR memory through the DMA controller and caches it in the on-chip high-speed memory; subsequently, the business transaction data is read from the temporary storage memory through the operation clusters corresponding to the cryptographic operation instructions, and cryptographic operations are performed through dedicated hardware circuits. During the operation, the security protection module provides security guarantees such as key isolation and side-channel protection, and generates the operation results; after the operation is completed, the operation results are written back to the blockchain-dedicated temporary storage memory, and then written back to the external DDR memory in batches through the DMA data bus. At this time, an interrupt signal can also be sent to the RISC-V main processor to notify the main processor that the operation is complete.

[0032] The blockchain-based data processing method provided in this application will be described in detail below with reference to specific implementation methods.

[0033] Figure 2 A flowchart illustrating a blockchain-based data processing method provided in an embodiment of this application is shown. The implementation process of the technical solution of this application will be described below using a blockchain terminal device as the execution subject. Figure 2 As shown, the blockchain-based data processing method provided in this embodiment includes steps 210 to 230, as detailed below: Step 210: The main processor generates cryptographic operation instructions based on the business transaction instructions and sends the cryptographic operation instructions to the coprocessor; the cryptographic operation instructions are used to perform cryptographic operations on the business transaction data corresponding to the business transaction instructions.

[0034] Specifically, the main processor is the central processing unit in the blockchain terminal device, which can adopt a RISC-V architecture. It is used to execute business transaction instructions and process business transaction tasks. These business transaction instructions are raw instructions generated by the blockchain application based on current business requests. Specific business requests may include initiating transfer transactions, querying account balances, deploying smart contracts, verifying the existence of a transaction in a block, etc. The blockchain application is the software program running on the blockchain terminal device, including cryptocurrency wallets and blockchain node software.

[0035] Cryptographic operation instructions are custom instructions generated from the instruction portion of the business transaction instructions received from the main processor that requires cryptographic operations. These instructions have preset opcode and operand formats. The opcode indicates the type of cryptographic operation, while the operands point to the memory address storing the business transaction data to be processed or the coprocessor's internal key index. One cryptographic operation instruction corresponds to one complete cryptographic operation and can be used to trigger the coprocessor's internal hardware circuitry to complete a complete cryptographic operation, such as digital signatures, hash operations, signature verification, and post-quantum signatures.

[0036] Business transaction data refers to the raw input information or data to be processed by the coprocessor during the processing of specific blockchain business transactions by blockchain terminal devices. The specific form of this data depends on the business scenario and includes, but is not limited to, transaction hash values ​​to be signed, the complete content of the block header (such as version number, timestamp, difficulty target, nonce value), and plaintext or ciphertext data encrypted by symmetry.

[0037] Step 220: Receive cryptographic operation instructions through the coprocessor and identify the instruction type of the cryptographic operation instructions.

[0038] Specifically, the coprocessor is a hardware extension unit integrated on the main processor of the blockchain terminal device, specifically responsible for performing various cryptographic operations, as mentioned above. Figure 1 As shown, the coprocessor includes an instruction interface and distribution module, on-chip temporary storage memory, hash operation cluster, signature / verification acceleration cluster, post-quantum cryptography operation cluster, and key management and side-channel protection module.

[0039] Cryptographic operation instructions typically include an instruction type field and an address field. The address field indicates the storage location of the business transaction data in system memory and the write-back location of the operation result. The instruction type field indicates the type of cryptographic operation to be performed and which hardware circuitry should be invoked for processing. Optionally, instruction types include, but are not limited to, hash operation instructions, signature operation instructions, post-quantum cryptography operation instructions, zero-knowledge proof verification instructions, symmetric encryption / decryption instructions, key derivation instructions, and random number generation instructions.

[0040] Cryptographic operations are computational operations that use cryptographic algorithms to process business transaction data, including but not limited to hash operations, signature operations, signature verification operations, post-quantum cryptography operations, symmetric encryption and decryption operations, key derivation operations, random number generation operations, etc., which are used to ensure the security and reliability of data processing.

[0041] Step 230: Execute business transaction instructions through the main processor and execute cryptographic operation instructions through the coprocessor according to the instruction type.

[0042] Specifically, while the main processor executes business transaction instructions to complete blockchain business logic processing, the coprocessor independently identifies the instruction type of cryptographic operation instructions and executes the corresponding cryptographic operations. This allows the business transaction execution process and the cryptographic operation process to proceed synchronously and concurrently at the hardware level. This parallel execution method avoids resource contention and execution blocking caused by a single processor simultaneously handling business processing and cryptographic operations. It also allows for the completion of highly complex cryptographic operations without extending the overall business transaction processing time, significantly improving the transaction processing efficiency, system concurrency, and operational stability of blockchain terminal devices. Simultaneously, it achieves hardware isolation between business logic and sensitive operations, enhancing data processing security.

[0043] In the technical solution provided in this application embodiment, the main processor first generates cryptographic operation instructions based on the business transaction instructions and sends these instructions to the coprocessor. The cryptographic operation instructions are used to perform encryption operations on the business transaction data corresponding to the business transaction instructions. Subsequently, the coprocessor receives the cryptographic operation instructions and identifies their instruction type. The instruction type indicates the type of cryptographic operation corresponding to the instruction. Finally, the main processor executes the business transaction instructions, and the coprocessor executes the cryptographic operation instructions according to their instruction types. Thus, through the collaborative architecture of the main processor and the integrated coprocessor, parallel execution of business transactions and cryptographic operations is achieved, significantly improving the overall data processing speed and concurrency capability of the blockchain terminal and preventing the main processor from being blocked by a large number of cryptographic operations.

[0044] In one embodiment of this application, the process of generating cryptographic operation instructions may include: identifying the instruction identifier of the business transaction instruction through the main processor, and determining whether the business transaction instruction needs to perform cryptographic operations based on the instruction identifier; if the instruction identifier indicates that the business transaction instruction needs to perform cryptographic operations, then extracting the cryptographic data in the business transaction instruction, and encapsulating the cryptographic data to generate cryptographic operation instructions.

[0045] Specifically, an instruction identifier is a pre-set flag or field in the binary encoding or intermediate representation of a business transaction instruction, used to indicate whether the instruction requires cryptographic operations. This identifier can be a single bit or a set of specific encoded values. Optionally, during the compilation phase (referring to the entire process of converting source code written in a high-level programming language into target machine code), the compiler can add the instruction identifier to a fixed position in the binary encoding or the opcode extension field based on whether the business transaction instruction requires signature operations, hash operations, or other cryptographic operations; alternatively, the programmer can explicitly specify an instruction identifier for the business transaction instruction directly through specific compiler built-in functions or attribute syntax.

[0046] Cryptographic data includes the type of cryptographic operation and the address information (such as register indexes, memory address pointers, etc.) of the business transaction data required to perform the cryptographic operation. This address information identifies the storage location of the business transaction data in system memory (such as DDR, on-chip SRAM, or coprocessor temporary storage), and is typically represented as a memory address or address pointer. In this application, the address information can be passed to the coprocessor as an operand of cryptographic operation instructions, instructing the coprocessor where to read the data to be operated on (e.g., the transaction hash to be signed, the Merkel path node to be verified, the public key list for batch signing, etc.), or where to write the operation result (e.g., the signature value, root hash, verification result, etc.). It should be noted that the address information can be a physical address or a virtual address, depending on the system's memory management mechanism; this is not limited here.

[0047] Encapsulation refers to the process of organizing the extracted cryptographic data into a complete custom cryptographic operation instruction that can be directly executed by the coprocessor according to a preset cryptographic operation instruction format. Optionally, the main processor can determine the corresponding custom instruction opcode based on the cryptographic operation type (e.g., mapping "secp256k1 signature" to the tx_sign opcode), then write the address information, key index, and other parameters of the business transaction data into the instruction's register operand field (e.g., rs1, rs2, rd), and set other control bits of the instruction as needed, thereby forming a complete cryptographic operation instruction.

[0048] For example, the coprocessor can monitor each business transaction instruction that the main processor needs to execute in real time through a custom instruction interface in the main processor, and parse each business transaction instruction to obtain an instruction identifier, thereby determining whether the business transaction instruction requires cryptographic operations. If it is determined that cryptographic operations are not required, the coprocessor directly ignores the instruction, and the main processor executes it normally. If it is determined that cryptographic operations are required, cryptographic data is extracted from the register field of the business transaction instruction, and a cryptographic operation instruction that can be directly executed by the coprocessor is generated internally based on the cryptographic data. This cryptographic operation instruction contains all the information required to perform the corresponding cryptographic operation (operation type, data source, result destination, etc.). Subsequently, the cryptographic operation instruction is sent to the instruction dispatch module inside the coprocessor, waiting to be allocated to the corresponding target unit for execution. It should be noted that the custom instruction interface in the main processor does not modify or delete the original business transaction instructions in the main processor pipeline during the generation of cryptographic operation instructions. The logic of the original business transaction instructions is still processed by the main processor, but the cryptographic operation part has been "taken over" by the coprocessor, and the main processor no longer needs to perform cryptographic operations.

[0049] In one embodiment of this application, after the coprocessor receives a cryptographic operation instruction from the main processor, it identifies the instruction type of the instruction, that is, it first parses the opcode of the cryptographic operation instruction; the opcode includes a preset encoding value for indicating the instruction type; then, based on the opcode, it searches in a preset instruction mapping table to determine the instruction type that matches the cryptographic operation instruction; the preset instruction mapping table includes the association between the opcode and the instruction type.

[0050] Specifically, the opcode is a specific field in a cryptographic instruction that indicates the type of cryptographic operation the instruction is to perform. In the RISC-V instruction set architecture, the high-order bits of each 32-bit instruction (usually bits 0 to 6, or distributed across different bit segments depending on the instruction format) are defined as the opcode field. Predefined encoding values ​​are binary values ​​that are predetermined and fixed during the instruction set design phase, used to uniquely identify a specific instruction or class of instructions. These encoding values ​​are typically explicitly defined by the processor architecture specification or assigned by the hardware designer during custom instruction extensions. Each encoding value corresponds to only one instruction type within the same instruction set space, uniquely determining which cryptographic operation the current instruction needs to perform.

[0051] The default instruction map is a hardware lookup table or read-only memory structure stored within the coprocessor, used to establish a mapping relationship between opcode values ​​and instruction types. Each row of this map typically contains two core fields: an opcode value field, which stores the default encoding value for a certain type of cryptographic operation instruction; and an instruction type field, which stores the cryptographic operation type identifier corresponding to that encoding value. For example, one row in the map might record "encoding value A → hash operation type," and another row might record "encoding value B → secp256k1 signature operation type." When the coprocessor parses the opcode of a cryptographic operation instruction, it uses that opcode as a lookup key to match and search the default instruction map to obtain the instruction type of the current cryptographic operation instruction.

[0052] In one embodiment of this application, the coprocessor includes multiple target units, each target unit including hardware circuitry in the coprocessor that performs cryptographic operations; after obtaining the instruction type of the current cryptographic operation instruction, the target unit corresponding to the cryptographic operation instruction can be determined according to the instruction type; cryptographic operations are performed on the business transaction data through the target unit to obtain the operation result.

[0053] Specifically, the target unit includes a hardware circuit module within the coprocessor used to perform specific cryptographic operations. This hardware circuit includes, but is not limited to, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or custom logic circuits. As described above... Figure 1 As shown, the target unit in this embodiment can be a hash operation circuit, a signature verification circuit, a post-quantum cryptography circuit, an elliptic curve cryptography circuit, a symmetric encryption / decryption circuit, a key derivation circuit, or a random number generation circuit, etc. The target unit is selected based on the instruction type of the cryptographic operation instruction and is responsible for performing the corresponding cryptographic operations on the business transaction data. Each target unit adopts a parallel or pipelined architecture, capable of completing the entire cryptographic operation process triggered by a single instruction.

[0054] The business transaction data corresponding to cryptographic operation instructions is stored in system memory, and its storage location is indicated by the address field of the cryptographic operation instruction. The content of business transaction data may be different for different instruction types.

[0055] The result of the operation is the data output by the coprocessor after completing the cryptographic operation. The content of the operation result may be different for different instruction types. For example, the operation result of the post-quantum cryptography operation instruction is the post-quantum signature or signature verification result, and the operation result of the random number generation instruction is a random number.

[0056] It should be noted that after the main processor issues the cryptographic operation instructions, it immediately continues to execute the other parts of the business transaction instructions that do not require cryptographic operations, while the coprocessor independently completes the cryptographic operations in the background. After the operation is completed, it notifies the main processor through an interrupt or a status flag. This design of parallel execution by two processors completely hides the cryptographic operation time within the processing time of the business transaction, thereby achieving a significant reduction in instruction cycles and an effective increase in system throughput without increasing the burden on the main processor.

[0057] In one embodiment of this application, after determining the target unit of the cryptographic operation instructions, the coprocessor can also obtain business transaction data from the main processor according to the cryptographic operation instructions and store the business transaction data in the temporary storage memory in the coprocessor; then, when the cryptographic operation is officially started, the target unit reads the business transaction data from the temporary storage memory.

[0058] Specifically, the temporary storage is a high-speed, low-latency on-chip memory integrated within the coprocessor, used to temporarily store business transaction data to be processed and intermediate results during computation. Because the temporary storage is located inside the coprocessor and connected to the target unit via a dedicated data path, its access latency is much lower than the tens to hundreds of clock cycles required to directly access the main processor's system memory, resulting in higher efficiency for cryptographic operations.

[0059] In one embodiment of this application, after receiving business transaction data, the target unit can perform cryptographic operations on the business transaction data to obtain the operation result, that is, obtain a first random number generated for the cryptographic operation instruction; pre-encrypt the first random number and the business transaction data to generate operation data; and perform cryptographic operations on the operation data to obtain the operation result.

[0060] Specifically, the first random number is a numerical sequence with unpredictability and statistical independence, used to mask the true bit values ​​of the key data. In this example, the first random number can be generated by a true random number generator integrated into the coprocessor or automatically generated by software. It is understood that, unlike software-generated pseudo-random numbers, true random numbers generated by a true random number generator originate from random physical processes, such as phase jitter of a ring oscillator, thermal noise, or quantum effects—physical entropy sources. They are highly bound to the hardware circuitry, making it virtually impossible for external devices to obtain information, thus providing higher security. For example, the length of the first random number matches the bit width of the business transaction data to be masked. For instance, if the business transaction data is a 32-byte hash value, then the first random number is also 32 bytes, and the first random number is regenerated each time a cryptographic operation instruction is executed, without being reused.

[0061] For example, pre-encrypting the first random number and business transaction data can be done using masking operations. This involves performing a modulo addition or bitwise XOR operation on the original business transaction data and the first random number, thereby randomizing and scattering the original business transaction data. This ensures that there is no fixed linear relationship between the value actually processed by the target unit and the original data. Thus, when the target unit performs cryptographic operations on the computational data, its instantaneous power consumption fluctuations will be related to the randomized computational data, rather than directly dependent on the original business transaction data. Even if an attacker collects a large number of power consumption curves, they will be unable to extract valid information from the original data through statistical methods.

[0062] The result of the operation is the output value obtained by the target unit after performing cryptographic operations on the data. Since the input of the target unit is preprocessed data rather than the original real data, the output result is naturally masked, meaning that there is a mathematical relationship between the result and the real result determined by random numbers. For example, in the case of XOR masking and linear cryptographic operations, the result and the real result may maintain a simple XOR relationship; however, in the case of nonlinear cryptographic operations (such as hash functions or elliptic curve product), the relationship between the result and the real result needs to be recovered through demasking (the inverse operation of masking). That is, the result is temporarily stored in mask form inside the coprocessor and does not directly expose the real result. Therefore, even if an attacker monitors the intermediate result or the result during the operation, they cannot directly know the real signature value, hash value, or verification result. Optionally, after obtaining the result, it can be written back to the main processor, which will then perform demasking to recover the real result. It should be noted that the demasking operation requires combining the first random number used in the masking operation (bitwise XOR operation or modulo addition operation) and the specific operation method, and then performing an inverse transformation on the operation result.

[0063] For example, suppose a user initiates an Ethereum transfer transaction request via a blockchain-enabled mobile phone. The blockchain application generates a business transaction instruction based on this request, including transaction assembly, parameter verification, and transaction signing. When the main processor executes the transaction signing instruction, it detects that the instruction identifier indicates the need for elliptic curve signature computation, and its register field points to the storage address of the transaction hash value and the private key index (business transaction data). Therefore, a cryptographic operation instruction is generated based on the transaction signing instruction through a custom instruction interface and sent to the coprocessor to execute the cryptographic operation instruction. Simultaneously, the main processor immediately continues executing the business transaction instruction. The process of the coprocessor executing the cryptographic operation instruction includes: first, obtaining a first random number from a true random number generator, and using the random number to perform a bitwise XOR operation on the private key and the transaction hash value to generate operation data; then, calling the elliptic curve cryptography dot product engine (corresponding to the target unit in this application) to perform a signature operation on the operation data; after completing the operation, outputting the masked signature result (operation result); then, sending the masked signature result to the main processor, where the demasking circuit in the main processor combines the random number to perform a demasking operation on the result to recover the real signature value (real result).

[0064] In this embodiment, the main processor processes business transactions in parallel while the coprocessor performs signature operations. The time of the signature operation is completely hidden (overlapping with the business transaction processing time), and the transaction confirmation delay perceived by the user is significantly reduced. At the same time, the private key never leaves the security boundary of the coprocessor. The signature operation is protected by the mask and side channel protection module throughout the process. Even if an attacker can monitor power consumption or electromagnetic radiation, they cannot obtain the private key information.

[0065] In one embodiment of this application, during the process of performing cryptographic operations on computational data by the target unit to obtain the computation result, the method further includes: obtaining multiple second random numbers, each second random number corresponding to one clock cycle in the process of the target unit performing cryptographic operations; inserting an idle clock cycle into the instruction pipeline corresponding to the cryptographic operation instruction based on the second random number; wherein, the instruction pipeline includes multiple execution steps with a sequential order required to execute the cryptographic operation instruction; and the idle clock cycle includes clock cycles in which no computational operation is performed.

[0066] Specifically, the second random number is used to control the timing of idle clock cycle insertion. Optionally, unlike the first random number used for bitwise XOR or modulo addition operations, the second random number typically does not need to have the same bit width as the business transaction data, and may even require only 1 bit or a few bits. For example, when the second random number is "1", an idle clock cycle is inserted during the non-operational phase of the clock cycle; when it is "0", no insertion is performed. Optionally, a second random number of several bits can be generated, where some bits determine whether an idle cycle is inserted, other bits determine the number of idle cycles to insert, and still others determine whether the insertion occurs at the front or back end of the pipeline.

[0067] An instruction pipeline comprises multiple sequential execution steps, derived from the complete execution of a cryptographic instruction, such as fetch, decode, register read, execution, and write-back. Each step is processed in parallel by independent hardware circuits within a continuous clock cycle. The fetch, decode, register read, and write-back steps only perform instruction flow control and data movement; they do not perform arithmetic logic or cryptographic transformations and do not alter the result, thus they are considered non-computational steps. Because these steps do not perform effective computations, their power consumption characteristics are weakly correlated with operands. Inserting idle clock cycles into these steps will not affect the correctness of the result, but it can disrupt an attacker's observation of the overall execution time, making it impossible to accurately identify the start and end positions of computational steps in the power consumption trajectory.

[0068] An idle clock cycle is one or more complete clock cycles inserted into the non-operational steps of the instruction pipeline for cryptographic operations, during which no valid computational operations are performed. During an idle clock cycle, the target unit pauses the execution of cryptographic operations, maintains the current state of all data paths and registers, and prohibits arithmetic logic units, multipliers, hash compression engines, and other computational components from performing any calculations or state updates. This is equivalent to the entire computation process being forcibly "paused" for one or more clock cycles.

[0069] It is understandable that the insertion of idle clock cycles only extends the total execution time of the operation and does not change the final result. Optionally, from the perspective of an external observer, the overall timing waveform of the same cryptographic operation exhibits different characteristics during its first and second executions due to the different insertion positions and lengths of the idle clock cycles. The timing waveform is a set of signal states that change over time during the execution of cryptographic operations by the target unit, typically including the timing relationships of key signals such as clock signals, control signals, data bus signals, and operation completion markers. Different cryptographic operations have different timing waveform characteristics; for example, the waveform of a hash operation may exhibit a regular round function iteration pattern, while the waveform of an elliptic curve dot product operation may exhibit length variations related to the key bits. In practical applications of blockchain, attackers can use high-precision oscilloscopes or logic analyzers to collect the timing waveform of the target unit, analyze the timing characteristics of the operation, and then combine this with timing attack techniques to deduce key information. However, the insertion of idle clock cycles in this embodiment prevents attackers from establishing a correspondence between "operation time and key bits" through the timing waveform, thus effectively resisting timing attacks.

[0070] In one embodiment of this application, during the process of performing cryptographic operations on computational data through the target unit to obtain the mask operation result, the method further includes: monitoring the power consumption status value of the target unit; when the power consumption status value is lower than a preset threshold range, performing pseudo-operations to compensate for the power consumption of the target unit, so that the power consumption status value of the target unit during the cryptographic operation is within a preset range; the pseudo-operations include energy consumption operations that do not perform cryptographic operations and do not generate operation results.

[0071] Specifically, the power state value is used to indicate the energy (such as current or power) consumed by a target cell per unit time. For example, monitoring the power state value of a target cell can be achieved in several ways: monitoring the supply current of the target cell using an on-chip current sensor, converting the current value into a voltage signal, and then quantizing it into a digital value using an analog-to-digital converter; monitoring the voltage drop of the target cell to infer power consumption by detecting the voltage drop on the power network; and monitoring the statistical value of the number of switching transistors in the target cell, since the dynamic power consumption of the circuit is proportional to the number of transistors switching per unit time. It should be noted that the power state value can reflect the instantaneous power consumption within the current clock cycle or the average power consumption over the most recent few clock cycles.

[0072] The preset threshold range is a pre-defined range of power consumption status values ​​used to determine whether the current power consumption of the target unit is within a safe range. If the power consumption status value is lower than the preset threshold range, it indicates that the target unit's current power consumption is low, which may not be able to mask the correlation between certain sensitive operations (such as the computation path when the key bit is 0) and power consumption, making it easier for attackers to distinguish different operations through power consumption analysis. Conversely, if the power consumption status value is too high, it may cause thermal security issues.

[0073] Pseudo-operations are a special type of hardware operation performed by the target unit. Their purpose is to consume energy to increase instantaneous power consumption, but they do not perform any meaningful cryptographic calculations or produce any valid results. Specifically, they can include: incrementing a register on an idle arithmetic logic unit and immediately discarding the result; performing an XOR operation on irrelevant data and writing the result to a temporary register without outputting it; or performing a pre-charge operation on multiple data paths without completing the full operation.

[0074] By performing pseudo-operations, the instantaneous power consumption of the target unit is increased to a level close to that of normal operation, thereby compensating for the power consumption dip caused by processing specific low-power operands. Thus, throughout the entire cryptographic operation, regardless of whether the target unit actually performs a high-power complex operation or a low-power simple operation, the power consumption of the target unit remains stable within a preset threshold range with minimal fluctuations. Attackers cannot distinguish between "genuine low-power operations" and "compensated low-power operations" based on differences in power consumption amplitude, thereby ensuring the security of the cryptographic operation process.

[0075] For example, when the detected power consumption value is below a preset threshold range, the coprocessor can trigger a virtual counter to increment. The result of this counter is not used by any subsequent logic; it is only used to consume power. Furthermore, the power compensation process is performed in parallel with the cryptographic operations, without blocking the normal computational pipeline. Through this compensation mechanism, regardless of whether the target unit actually performs zero-intensive or one-intensive operations, the externally observed total power consumption curve remains at a relatively constant level, thus effectively defending against simple power analysis and differential power analysis attacks.

[0076] When the detected power state value is higher than the preset threshold range, a power suppression operation is performed. This power suppression operation includes the following: applying a clock gating signal to the sub-modules in the target unit that do not currently need to participate in the operation (such as some multipliers, adder trees, and temporary registers) to temporarily shut down their clock input, so that they do not have signal flipping within the clock cycle, thereby reducing dynamic power consumption; splitting high-power operations that were originally completed in one clock cycle (such as large-width multiplication and multi-round hash compression) into multiple sub-cycles to be completed step by step, reducing the instantaneous power consumption peak by reducing the parallelism within a single cycle, while maintaining the correctness of the final operation result; temporarily reducing the operating voltage or clock frequency of the target unit until the power state value falls back to the preset safe range. The additional timing delay introduced by the frequency reduction operation itself can simultaneously enhance the randomness of side-channel protection.

[0077] In one embodiment of this application, after the coprocessor executes cryptographic operation instructions according to the instruction type and obtains the operation result, the operation result can be written back to the on-chip temporary memory inside the coprocessor to avoid the additional bus latency caused by directly writing back to the system memory of the main processor. Subsequently, the coprocessor sends a completion interrupt signal to the main processor through the interrupt controller, or sets the completion flag in the coprocessor status register to asynchronously notify the main processor that the cryptographic operation has ended. After receiving the interrupt notification, the main processor can choose to respond to the interrupt immediately and enter the interrupt service routine, or continue to complete the currently processed business transaction instruction before responding, depending on the progress of its own instruction stream execution.

[0078] After the main processor reads the required computation results from the temporary storage, it merges the cryptographic results with the original business transaction instruction context (such as transaction data to be broadcast, block headers to be verified, Merkle roots to be stored, etc.) and continues to execute subsequent blockchain business logic, such as broadcasting the signed transaction to the network, marking verified blocks as valid, or submitting the decrypted data to the upper-layer application. Through this asynchronous cooperation mechanism of "result temporary storage + interrupt notification + on-demand reading," the main processor can process other business tasks in parallel while the coprocessor performs heavy cryptographic operations, only briefly intervening when results are needed. This minimizes the main processor's waiting time and context switching overhead, achieving dual optimization of overall system throughput and response latency.

[0079] In one embodiment of this application, if the instruction type is a hash operation instruction, the target unit is determined to be a hash operation circuit; the hash operation circuit performs cryptographic operations on the business transaction data corresponding to the hash operation instruction to obtain the operation result.

[0080] Specifically, hash operation instructions are used to trigger the coprocessor to execute hash operation tasks. These instructions carry the address information of the business transaction data. The coprocessor uses this address to retrieve the block header data, transaction hash value, and other business transaction data from system memory. Hash operation instructions include, but are not limited to, block hash operation instructions, Merkle proof verification instructions, and cross-chain hash operation instructions. Specifically, block hash operation instructions are used to calculate the hash value of the block header, which is then used for block verification or proof-of-work calculation scenarios; Merkle proof verification instructions are used to verify whether a specified transaction is included in the Merkle tree; and cross-chain hash operation instructions are used to perform parallel calculations of transaction hash values ​​from multiple different blockchains.

[0081] The hash operation circuit is a dedicated hardware circuit module inside the coprocessor used to perform hash operations. Figure 1 The hash operation cluster shown can complete a complete hash operation task by responding to a single hash operation instruction, without the need to write software loops or instruction sequences.

[0082] In one embodiment of this application, if the hash operation instruction is a block hash operation instruction, the hash operation circuit performs a hash operation on the block header data in the business transaction data according to the current blockchain scenario type to obtain the operation result; wherein, if the blockchain scenario type is a block verification scenario, a single hash operation is performed on the block header data; if the blockchain scenario type is a proof-of-work calculation scenario, the hash operation is repeatedly performed until the preset difficulty target is met.

[0083] Specifically, blockchain scenario types refer to classification information used to distinguish the execution environment of block hash operation instructions, including two types: block verification scenarios and proof-of-work computation scenarios. The block verification scenario corresponds to the process by which blockchain nodes verify the validity of received blocks during block synchronization. In this scenario, verification can be completed by performing a single hash operation on the block header. The proof-of-work computation scenario corresponds to the process by which blockchain nodes search for a valid random number when competing for the right to record transactions. In this scenario, hash operations need to be repeatedly performed on the block header, incrementing the random value after each operation until the calculated block hash value meets a preset difficulty target. The preset difficulty target is a threshold condition set by the blockchain network, usually represented in integer form. The block hash value must be less than or equal to this preset difficulty target to be accepted by the network.

[0084] For example, if the main processor generates a custom block hash operation instruction `blk_hash_calc rd,rs1` based on a business transaction instruction, the coprocessor needs to capture this instruction through the instruction interface, parse the instruction parameters, and obtain the storage address of the block header data. The `rs1` register points to the starting address of the block header data in system memory, and the `rd` register is used to return the calculation result. Taking Bitcoin as an example, the block header contains a version number (4 bytes), the previous block hash (32 bytes), the Merkle root hash (32 bytes), a timestamp (4 bytes), a difficulty target (4 bytes), and a random number (4 bytes), totaling 80 bytes. The block header length and field definitions may differ for different blockchain protocols, and the coprocessor adapts the corresponding data format according to the instruction type or preset configuration. Next, the coprocessor initiates the Direct Memory Access (DMA) controller to load the block header data of the specified length from system memory into the on-chip temporary storage memory within the coprocessor in burst transfer mode. The data length is determined according to the blockchain protocol, and the coprocessor can obtain this length information through instruction parameters, preset configuration, or automatic detection. Furthermore, during the data loading process, the main processor is idle and can perform other tasks without interfering with the data transmission process.

[0085] After loading, depending on the blockchain scenario, hash operations are divided into two modes: block verification mode and proof-of-work calculation mode. When the coprocessor is in the block verification scenario, the hash operation circuit first reads the complete block header data from the temporary storage, then selects the corresponding hash engine according to the blockchain protocol and performs a hash operation on the block header data to obtain the block hash value. Finally, the calculated block hash value is temporarily stored as the result in the result register. This scenario is suitable for operations such as full node verification of received blocks and light node synchronization of block headers. It has a fast processing speed, and verification can be completed in a single hash operation. When the coprocessor is in the proof-of-work calculation scenario, the proof-of-work auxiliary unit first reads the block header data from the temporary storage, locates the position of the random number segment, then uses the current random value as the initial value, sets an iteration counter, and repeatedly performs the following operations: performs a hash operation on the current block header data to obtain the block hash value, and then compares the calculated block hash value with the preset difficulty target. If the block hash value is less than or equal to the difficulty target, a valid random number is found, and the iteration terminates. If the block hash value is greater than the difficulty target, the random value is incremented, the random number segment in the block header is updated, and the next iteration continues. If a valid random number is not found after reaching the preset iteration limit, the iteration terminates, and the last calculated random number or a specific status code is returned. In other words, the proof-of-work auxiliary unit has built-in automatic incrementing logic, automatically incrementing the random value after each iteration without software intervention. Furthermore, intermediate results during the computation process (such as the unchanging part in the block header) can be pre-computed and reused, thereby reducing the overhead of repeated computations. After the hash calculation is completed, the coprocessor writes the calculation result back to the main processor for reading. In the block verification scenario, the coprocessor returns the block header hash value (such as a 256-bit hash value), stored in a designated buffer in system memory. In the proof-of-work computation scenario, it returns a valid random number (Nonce value) that meets the difficulty target. If a valid random number is not found after reaching the iteration limit, the last calculated random number or a status code can be returned.

[0086] This embodiment can complete the full hash operation task in block verification or proof-of-work calculation scenarios with a single custom block hash operation instruction. It does not require writing software loops or intervening in the iteration process, which can significantly improve the efficiency of proof-of-work calculation and verification. It also provides blockchain terminal devices with efficient and flexible block hash operation capabilities.

[0087] In one embodiment of this application, if the hash operation instruction is a Merkel proof verification instruction, then the hash operation circuit performs cryptographic operations on the hash value and the Merkel path node list in the business transaction data to obtain the root hash value; the root hash value is compared with the preset Merkel root, and the first comparison result is output as the operation result; the first comparison result is used to indicate whether the root hash value is consistent with the preset Merkel root.

[0088] Specifically, the Merkle proof verification instruction is a custom extension instruction within hash operation instructions specifically used to verify whether a specified transaction is included in the Merkle tree. It is the core operation for light nodes to simplify payment verification. This instruction is widely used in scenarios requiring rapid verification of transaction existence, such as blockchain light wallets and SPV nodes, confirming that a transaction has been confirmed by the network without downloading the complete block data.

[0089] The business transaction data corresponding to the Merkel proof verification instruction can specifically include the transaction hash value to be verified and the Merkel path node list. The transaction hash value to be verified is the hash value of the transaction data whose existence in a certain block needs to be proven. This hash value is usually obtained by hashing the original transaction data and is located at the bottom level of the Merkel tree as a leaf node. The Merkel path node list includes the sibling node hash values ​​and path position information arranged sequentially from the leaf node to the root node. The sibling node hash value is the hash value of the node at the same level as the current hash value in the Merkel tree that needs to be concatenated with it to calculate the parent node hash. This hash value comes from another child node in the current level of the Merkel path besides the current node; the path position information is a data identifier indicating the relative position of the current hash value during concatenation, used to determine the left-right order of the current hash value and the sibling node hash values ​​during concatenation.

[0090] For example, the Merkle path node list is typically stored in system memory as a contiguous data structure, with a storage format of {field, length, sibling node hash value + path location information}. When the main processor generates a custom Merkle proof verification instruction `merkle_verify rd,rs1,rs2` based on the business transaction instruction, the coprocessor captures this instruction through the instruction interface and parses the address of the transaction hash value to be verified (pointed to by rs1) and the address of the Merkle path node list (pointed to by rs2) from the instruction parameters. Subsequently, the coprocessor loads the transaction hash value to be verified and the Merkle path node list from system memory into the on-chip temporary storage in batches. After the data loading is complete, the dedicated Merkle tree execution unit reads the transaction hash value from the temporary storage as the current hash value and processes it layer by layer in the order from the leaf node to the root node: retrieving the sibling node hash value and path location information of the current layer from the temporary storage, and determining the concatenation order based on the path location information. If the path location information indicates the first state, then the current hash value is on the left and the sibling node is on the right; if it indicates the second state, then the sibling node is on the left and the current hash value is on the right. Then, the two are concatenated and sent to the hash engine to perform a hash operation. The result of the operation is used as the current hash value of the next layer. The above process is repeated until all layers are processed to obtain the root hash value.

[0091] If multiple Merkle proofs are verified simultaneously, the dedicated Merkle tree execution unit can process multiple path branches in parallel. Each branch is calculated independently, and intermediate results are temporarily stored in intermediate registers. After the root hash value is calculated, the coprocessor compares the calculated root hash value with the Merkle root pre-stored in the block header. If they match, success is output; otherwise, failure is output. The comparison result is written back to the main processor through a register, and an interrupt can be triggered to notify the main processor to read the result, thus completing the entire Merkle proof verification process.

[0092] In one embodiment of this application, if the hash operation instruction is a cross-chain hash operation instruction, then multiple pipeline units in the hash operation circuit perform cryptographic parallel operations on the hash values ​​of business transaction data in different blockchains to obtain multiple execution results; the multiple execution results are aggregated to obtain the operation result.

[0093] Specifically, cross-chain hash operation instructions are used in scenarios such as cross-chain bridges and cross-chain aggregators that require processing transaction data from multiple chains simultaneously, receiving task descriptors as business transaction data. The task descriptor contains the transaction data addresses of multiple chains, data length, hash algorithm identifier, and output buffer address.

[0094] Parallel computing refers to the operation method in which multiple hardware pipeline units in a coprocessor simultaneously execute different hash operations. In this embodiment, the hash operation circuit includes multiple independent pipeline units, each of which can be configured with a different hash algorithm. When a cross-chain hash operation instruction is executed, each pipeline unit starts simultaneously, processing transaction data from different blockchains independently without interference. The core advantage of parallel computing lies in compressing the hash operation tasks of multiple chains that originally needed to be executed serially into simultaneous execution. The total time is equal to the time of the longest hash operation in a single chain, rather than the sum of the times of each chain, thus significantly improving the efficiency of cross-chain transaction processing. The multiple execution results are the hash values ​​output by each pipeline unit after performing hash operations on the transaction data of different blockchains during the execution of the cross-chain hash operation instruction. Each execution result corresponds to the transaction hash of a blockchain, and its format and length depend on the hash algorithm used by that chain (such as SHA-256 outputting 256 bits, Keccak outputting 256 bits, Blake2b outputting 512 bits, etc.).

[0095] Aggregation processing refers to the operation of organizing and summarizing the hash results output by multiple pipeline units according to the order specified by the task descriptor. During the execution of cross-chain hash operation instructions, the time for each pipeline unit to complete the hash operation may differ. The aggregation processing module is responsible for waiting for all pipeline units to complete their operations and then writing the execution results sequentially into the output buffer of system memory according to the chain order in the task descriptor. Aggregation processing ensures that the order of the output data is consistent with the order of the chain in the task descriptor, facilitating reading and subsequent processing by upper-layer applications. After aggregation is completed, the coprocessor sends a completion notification to the main processor.

[0096] For example, when the main processor generates a custom cross-chain hash operation instruction `crosschain_hash rd,rs1` based on a business transaction instruction, the coprocessor captures this instruction through the instruction interface and parses the address of the task descriptor (pointed to by `rs1`) from the instruction parameters. Subsequently, the coprocessor loads the task descriptor from system memory into on-chip temporary storage. Next, the instruction dispatch unit parses the task descriptor, obtaining information such as the transaction data addresses, data lengths, hash algorithm identifiers, and output buffer addresses of the multiple chains it contains. Based on the algorithm identifiers of each chain, it allocates the transaction data from different chains to different pipeline units in the hash operation circuit. For example, Bitcoin transaction data using the SHA-256 algorithm is allocated to pipeline A, Ethereum transaction data using the Keccak algorithm is allocated to pipeline B, and Polkadot transaction data using the Blake2b algorithm is allocated to pipeline C. After allocation, the coprocessor loads the transaction data from each chain into the temporary storage area associated with the corresponding pipeline unit. Each pipeline unit then performs hash operations independently and in parallel, without interference. The pipelined architecture within each pipeline unit allows it to process multiple bytes of data per clock cycle, significantly improving throughput. After each pipeline unit completes its hash operation, the result is temporarily stored in the corresponding location in the on-chip buffer.

[0097] Throughout the computation process, the coprocessor continuously monitors the status of all pipeline units. After all pipeline units have completed their computations, the hash results are sequentially organized according to the chain order specified in the task descriptor and written back to the corresponding output buffer address in the main processor via the DMA controller. This ensures that the order of the output data matches the chain order in the task descriptor, facilitating reading and subsequent processing by upper-layer applications. Thus, this embodiment enables parallel computation of hashes for multiple blockchain transactions. Multiple pipeline units execute different hash algorithms simultaneously, compressing serial computation into parallel execution. The total computation time is only equal to the longest hash computation time in a single chain, significantly improving cross-chain transaction processing efficiency. Furthermore, by using DMA to batch load data and aggregate output results, processor intervention is reduced, lowering system overhead. A single set of hardware resources can meet the needs of multi-chain heterogeneous hash computation, thereby providing efficient and low-latency hash computation capabilities for cross-chain bridges and cross-chain aggregators.

[0098] In one embodiment of this application, if the instruction type is a signature operation instruction, the target unit is determined to be a signature circuit; the signature circuit performs a signature operation on the hash value in the business transaction data corresponding to the signature operation instruction to generate a signature as the operation result.

[0099] Specifically, the signature operation instruction is used to trigger the coprocessor to perform a digital signature generation operation, that is, to sign the hash value of a single transaction to generate a digital signature to prove the authenticity and non-repudiation of the transaction. The signature circuit is a hardware circuit module inside the coprocessor specifically used to perform the digital signature generation operation, and belongs to the aforementioned... Figure 1 The signature / verification execution cluster is shown. Since the signature operation instructions carry the address information of the business transaction data, the coprocessor can retrieve the transaction hash value from system memory based on this address and the corresponding private key from the internal secure storage unit based on the private key index, thereby enabling the signature circuit to perform the signature operation. The transaction hash value is a fixed-length output obtained by hashing the original transaction data, serving as the input message for the signature algorithm. Its length is determined by the hash algorithm used (e.g., SHA-256 outputs 256 bits). The private key index is used to locate the corresponding private key in the coprocessor's internal secure storage unit. The private key itself is invisible to the main processor. The coprocessor can read a fragment of the private key from non-volatile memory or a write-only register based on the index and perform masking processing on the internal bus to ensure that the key is not leaked during transmission.

[0100] For example, when a blockchain application initiates a transaction that requires generating a digital signature, the main processor generates custom signature operation instructions `tx_sign rd, rs1, rs2` based on the business transaction instructions. Here, `rs1` points to the storage address of the transaction hash value in system memory, `rs2` points to the private key index or private key storage address, and `rd` is used to specify the return register for the signature result. After the coprocessor captures this instruction through the instruction interface, it first reads the corresponding private key fragment from the internal secure storage unit according to the private key index, and masks the private key data during internal bus transmission to prevent side-channel probing of intermediate data. Subsequently, the coprocessor loads the transaction hash value from the main processor's system memory to the on-chip temporary storage memory according to the address indicated by `rs1`, and calls the elliptic curve multiplication engine in the signature circuit to perform a signature operation on the transaction hash value, that is, generating a random temporary key pair according to the selected elliptic curve algorithm and operating on the signature components `r` and `s`. After the signature operation is completed, the coprocessor writes the generated signature back to the specified area of ​​system memory through temporary storage or directly through the result register, and triggers a completion interrupt or sets a status flag to notify the main processor that the signature is ready. After receiving the notification, the main processor reads the signature from the specified location, appends the signature to the original transaction, and broadcasts it to the blockchain network, thus completing the entire transaction signature process.

[0101] This embodiment compresses the elliptic curve multiplication and signature operations, which originally required thousands of instructions, into a single-instruction trigger, significantly improving signature efficiency and reducing the energy consumption of completing a signature. Simultaneously, the private key is securely stored within the coprocessor and is invisible to the main processor, fundamentally eliminating the risk of malicious software stealing the private key, thus achieving a balance between high performance and high security.

[0102] In one embodiment of this application, if the instruction type is a batch signature verification instruction, the target unit is determined to be a batch signature verification circuit; the batch signature verification circuit performs a preset number of dot addition and dot multiplication operations on the signature data descriptor corresponding to the batch signature verification instruction to obtain an intermediate result; the signature data descriptor includes a transaction hash list, a public key list, and a signature value list; a comprehensive verification result is generated as the calculation result based on the intermediate result; the comprehensive verification result includes a fully passed state or at least one failed state.

[0103] Specifically, the batch signature verification instruction is used to trigger the coprocessor to verify the validity of multiple transaction signatures simultaneously. The business transaction data corresponding to the batch signature verification instruction is a signature data descriptor, which carries the address information of the signature data descriptor. The coprocessor can obtain a data set containing multiple transaction hashes, public keys, and signature values ​​from the system memory based on the address, and complete the verification of all signatures at once through hardware execution. This is suitable for scenarios that require efficient verification of a large number of signatures, such as block synchronization and batch transaction processing.

[0104] A signature data descriptor is a data structure used for batch signature verification. It contains a list of transaction hashes to be verified, a list of public keys, and a list of signature values, along with information about the number of signatures in each list. The transaction hash list stores the hash values ​​of each transaction to be verified; each hash value has a fixed length, and the list length is equal to the number of signatures to be verified, N. The public key list stores the public keys corresponding to each signature; each public key is represented as the coordinates of a point on an elliptic curve, and the list length is also N. The signature value list stores the signature values ​​of each transaction; each signature typically consists of two components, r and s, and the list length is N. The quantity information indicates the numerical value N of the number of signatures in each list, used to determine the number of iterations for batch signature verification. The elements in the three lists correspond one-to-one in the same order; that is, the i-th transaction hash, the i-th public key, and the i-th signature value together constitute the i-th signature to be verified.

[0105] The batch signature verification circuit is a dedicated hardware circuit module within the coprocessor used to simultaneously verify the validity of multiple digital signatures, corresponding to the aforementioned... Figure 1 The batch verification execution unit of the signature / verification execution cluster shown is characterized by utilizing the linear combination property of elliptic curve multiplication to merge the verification of N signatures into a finite number of dot addition and multiplication operations, rather than verifying them individually. The preset number of iterations refers to the predetermined number of loops for performing dot addition and multiplication operations during batch verification, determined by the quantity information N in the signature data descriptor. Specifically, when verifying N signatures, the batch verification circuit utilizes the linear combination property of elliptic curve multiplication to merge the verification equations of N independent signatures into a single comprehensive equation. Solving this equation requires performing a finite number of dot addition and multiplication operations related to N, a number far less than the N-fold computational complexity of individual verification.

[0106] Intermediate results are temporary data generated by the batch signature verification circuit during point addition and multiplication operations. These data are used to gradually accumulate the final comprehensive verification result. Intermediate results typically include the following: the accumulated value of each signature verification equation, temporary coordinates of elliptic curve points, and cached data of partial products. The batch signature verification circuit temporarily stores the intermediate results in a dedicated register, updating the accumulated value after processing each signature. Once all signatures have been processed, the accumulated value is the final comprehensive verification result. The comprehensive verification result is the final judgment output by the batch signature verification circuit after completing all signature verifications, indicating whether all signatures in the batch are valid. The comprehensive verification result includes two states: First, a "all passed" state, indicating that all signatures in the signature data descriptor have passed verification, meaning that each signature pair consisting of a transaction hash, public key, and signature value is valid, indicating that the transactions in this batch are all genuine and trustworthy. Second, a "at least one failed" state, indicating that at least one invalid signature exists in the signature data descriptor, meaning that a certain signature verification failed. When the overall verification result is at least one failure state, the batch signature verification circuit can choose to return the index of the first failed signature, which makes it easier for the software to locate the specific invalid signature and identify the problematic signature without having to re-verify each one.

[0107] For example, when the main processor generates a custom batch verification instruction `batch_verifyrs1` based on the business transaction instruction, the coprocessor captures the instruction through the instruction interface and parses the address of the signature data descriptor (pointed to by `rs1`) from the instruction parameters. Subsequently, the coprocessor loads the transaction hash list, public key list, signature value list, and quantity information N from the signature data descriptor from system memory to the on-chip temporary storage memory in batches according to this address. At the same time, the batch verification circuit initializes its internal state and clears the accumulation register and intermediate result cache. After the data is loaded, the batch verification circuit first calculates the corresponding elliptic curve points based on the hash value, public key, and signature value of each signature. Then, it performs multiple point multiplications in parallel using a multi-scalar multiplication algorithm. The hardware pipeline processes multiple sets of data simultaneously, performing multiple point addition or point multiplication operations each clock cycle, and the intermediate results are temporarily stored in dedicated registers and accumulated level by level. After all signatures have been processed, a comprehensive verification result is generated based on the final summation result. If the summation result satisfies the elliptic curve verification equation, the comprehensive verification result is "all passed," indicating that all signatures in the signature data descriptor are valid. If not, the comprehensive verification result is "at least one failed." In this case, the batch verification circuit can choose to return the index of the first failed signature to facilitate locating the specific invalid signature. After the calculation is completed, the coprocessor writes the comprehensive verification result and the optional failed signature index back to the main processor through a register, completing the entire batch verification process.

[0108] In one embodiment of this application, if the instruction type is a post-quantum signature generation instruction or a post-quantum signature verification instruction, then the target unit is determined to be a post-quantum cryptographic operation circuit; if the instruction type of the cryptographic operation instruction is a post-quantum signature generation instruction, then the business transaction data corresponding to the post-quantum signature generation instruction is signed to generate a post-quantum signature as the operation result. Specifically, the post-quantum signature generation and verification instructions are used to trigger the coprocessor to execute lattice-based quantum-resistant cryptographic algorithms to address the threat posed by quantum computing to traditional elliptic curve cryptography. The post-quantum signature generation instruction generates a quantum-resistant digital signature for a message. The corresponding business transaction data includes a message hash and a private key. The private key is the secret data used to generate the signature and is stored in a secure storage unit within the coprocessor or in a private key buffer in system memory as pointed to by the instruction parameter. The post-quantum signature verification instruction verifies the validity of the quantum-resistant signature. In this scenario, the business transaction data can include the message hash, the public key, and the post-quantum signature. The message hash is a fixed-length output obtained by hashing the original message; the public key is the public data used to verify the signature, generated from the private key using a trapdoor function of a difficult problem on a lattice; and the post-quantum signature is the signature data to be verified, typically containing multiple polynomial vectors such as commitment and response components.

[0109] The post-quantum cryptography circuit is a hardware circuit module within the coprocessor specifically designed to perform lattice-based quantum-resistant cryptographic algorithms, corresponding to the aforementioned... Figure 1 The post-quantum cryptography cluster shown.

[0110] Post-quantum signatures, also known as quantum-resistant digital signatures, are used to attach to transactions or messages to prove their authenticity and non-repudiation. Unlike traditional elliptic curve signatures, the data structure of post-quantum signatures typically contains multiple polynomial vectors. Even if an attacker has a quantum computing machine, they cannot crack the private key in a feasible time, making them significantly more secure than ordinary signatures.

[0111] For example, when the main processor generates a custom post-quantum signature generation instruction `pq_sign_gen` based on a business transaction instruction, the coprocessor captures the instruction through the instruction interface and parses the address of the message hash, the storage location of the private key, and the address of the signature buffer from the instruction parameters. Subsequently, the coprocessor loads the message hash and private key from system memory into on-chip temporary storage, while simultaneously obtaining a high-quality random entropy source from a true random number generator to generate the random mask and noise components in the signature. After data loading, the number theory transformation engine in the post-quantum cryptographic circuit performs NTT transformation on the random mask polynomial to perform polynomial multiplication and generate a commitment. Then, the hash module in the post-quantum cryptographic circuit generates a challenge value based on the message hash and commitment. Finally, the polynomial operation unit in the post-quantum cryptographic circuit constructs a response component based on the private key, challenge value, and random mask, and combines the commitment and response component into a complete post-quantum signature. Throughout the signature generation process, the side-channel protection unit can automatically insert random delays and apply masks to intermediate data, causing the timing and power consumption curves related to the private key to exhibit a random distribution, effectively resisting timing attacks and power analysis attacks. Once the signature is generated, the coprocessor writes the post-quantum signature, which contains multiple polynomial vectors, back to the signature buffer specified in the system memory via DMA and triggers an interrupt to notify the main processor. The main processor then reads the signature, appends it to a message, and broadcasts it to the network.

[0112] This embodiment utilizes the NTT engine hardware to perform polynomial multiplication, compressing the complex operation that requires thousands of polynomial multiplications in the software implementation into a single instruction trigger. The complete quantum-resistant signature generation can be completed with only a single post-quantum signature generation instruction, significantly improving the signature generation speed.

[0113] In one embodiment of this application, if the instruction type of the cryptographic operation instruction is a post-quantum signature verification instruction, then a commitment to be verified is generated based on the business transaction data corresponding to the post-quantum signature verification instruction; the commitment to be verified is used to verify whether the signer knows the private key for signing the business transaction data; the commitment is compared with the commitment carried by the post-quantum signature in the post-quantum signature verification instruction, and the comparison result is used as the operation result; the comparison result is used to indicate whether the commitment to be verified is consistent with the commitment carried by the post-quantum signature in the post-quantum signature verification instruction.

[0114] Specifically, establishing a commitment to be verified based on business transaction data refers to the process by which the verifier recalculates the commitment value using polynomial operations based on the public key, message hash, and response component in the signature. The comparison result is the verification result output after comparing the commitment to be verified with the original commitment carried in the signature during the post-quantum signature verification process. If the commitment to be verified matches the original commitment carried in the signature, the signature is valid; otherwise, the signature is invalid or has been tampered with. The computational process for generating the commitment to be verified is similar to the commitment computation process in signature generation, both requiring the NTT engine to perform polynomial multiplication to ensure the efficiency of the verification process.

[0115] For example, when the main processor generates a custom post-quantum signature verification instruction `pq_verify` based on a business transaction instruction, the coprocessor captures this instruction through the instruction interface and parses the address of the message hash, the public key storage address, and the address of the post-quantum signature to be verified from the instruction parameters. Subsequently, the coprocessor loads the message hash, public key, and post-quantum signature from system memory into on-chip temporary storage in batches. After data loading, the post-quantum cryptographic operation circuit performs polynomial multiplication on the response component in the post-quantum signature using a number theory transformation engine based on the public key and message hash, generating a commitment to be verified. Then, the commitment to be verified is compared item by item with the original commitment carried in the post-quantum signature. After comparison, the coprocessor generates a comparison result. If the commitment to be verified is completely consistent with the original commitment, the verification result is successful, indicating that the signature is valid and the message has not been tampered with; if they are inconsistent, the verification result is unsuccessful. The coprocessor writes the verification result back to a specified area of ​​system memory via DMA and triggers an interrupt to notify the main processor. The main processor decides whether to accept the message or transaction based on the verification result.

[0116] This embodiment's solution can complete quantum-resistant signature verification with a single post-quantum signature verification instruction. It utilizes the same NTT engine to quickly reconstruct the commitment and compare it with the commitment in the signature, making the verification process highly efficient and reliable. Furthermore, hardware execution keeps the performance loss of post-quantum signature verification within an acceptable range, enabling terminal devices to possess quantum resistance capabilities without significantly impacting transaction processing speed, thus meeting the practical needs of post-quantum migration in blockchain.

[0117] In one embodiment of this application, if the instruction type is a zero-knowledge proof verification instruction, the target unit is determined to be an elliptic curve cryptography circuit; the elliptic curve cryptography circuit performs elliptic curve cryptography operations on the proof data and verification key corresponding to the zero-knowledge proof verification instruction to obtain the operation result.

[0118] Specifically, zero-knowledge proof verification instructions are used to trigger the coprocessor to execute zero-knowledge proof verification operations. Zero-knowledge proofs allow the prover to prove a statement to the verifier without revealing any information other than the truth of that statement. In blockchain privacy transaction scenarios, zero-knowledge proofs are often used to hide the sender, receiver, and transaction amount of a transaction, while allowing network nodes to verify the legality of the transaction. The business transaction data corresponding to the zero-knowledge proof verification instructions can include proof data and a verification key. The proof data is cryptographic data generated by the prover, containing three elliptic curve points A, B, and C, used to prove the statement is true. The verification key is a public parameter used to verify the validity of the proof, containing elliptic curve points such as α, β, γ, and δ, generated by a trusted setting. The size of the verification key is related to the size of the circuit to be proven, typically ranging from a few KB to several hundred KB. The verification key is public and can be pre-stored on the blockchain or cached locally on the node, eliminating the need to reload it with each verification.

[0119] Elliptic curve cryptography circuits refer to hardware circuits within a coprocessor specifically designed to perform elliptic curve-related cryptographic operations, corresponding to the aforementioned... Figure 1 The diagram shows an elliptic curve pairing engine used for zero-knowledge proof verification. Elliptic curve cryptography operations are a series of complex mathematical operations on elliptic curves required for verifying zero-knowledge proofs, with bilinear pairing operations at its core.

[0120] For example, when the main processor generates a custom zero-knowledge proof verification instruction zk_verify rs1 based on the business transaction instruction, the coprocessor captures the instruction through the instruction interface and parses the address of the proof data and verification key (pointed to by rs1) from the instruction parameters. Subsequently, the coprocessor loads the proof data (containing three elliptic curve points A, B, and C) and the verification key (containing elliptic curve points such as α, β, γ, and δ, as well as public input encoding parameters) from the system memory into the on-chip temporary storage in batches. After the data is loaded, the elliptic curve pairing engine begins executing the core operations of bilinear pairing: first, it performs the pairing operation e(A,B) on points A and B in the proof data, and simultaneously performs pairing operations on points α and β in the verification key; concurrently, the hash cluster performs parallel computation of the public input hash in the proof, mapping the public input to points on the elliptic curve and aligning them with the parameters in the verification key; the multi-stage pipeline control unit combines the results of each pairing operation with the encoded results of the public input to complete the final bilinear pairing equality verification (checking whether the preset mathematical relationship holds), such as whether e(A,B) is equal to the product of e(α,β) and the relevant terms of the public input. After the verification operation is completed, the coprocessor generates the verification result. If the bilinear pairing equality holds, the verification result is true (success), indicating that the zero-knowledge proof is valid and the privacy transaction is legal; if it does not hold, the verification result is false (failure), indicating that the proof is invalid. Finally, the coprocessor writes the verification result back to the designated register of the main processor, which then decides whether to accept the privacy transaction.

[0121] This embodiment can complete bilinear pairing verification with a single zero-knowledge proof verification instruction. It utilizes an elliptic curve pairing engine to accelerate pairing operations on elliptic curves, while hash clusters perform parallel computation of the public input hash. The multi-stage pipeline efficiently completes the final equality verification, compressing the originally computationally intensive zero-knowledge proof verification from software time-of-flight to hardware time-of-milliseconds. This provides efficient verification capabilities for blockchain privacy transactions, enabling terminal devices to quickly process privacy transactions.

[0122] In one embodiment of this application, if the instruction type is a symmetric encryption / decryption instruction, the target unit is determined to be a symmetric encryption / decryption circuit; the symmetric encryption / decryption circuit performs encryption / decryption processing on the business transaction data corresponding to the symmetric encryption / decryption instruction block by block in streaming mode to obtain the calculation result.

[0123] Specifically, symmetric encryption / decryption instructions are used to trigger the coprocessor to execute encryption or decryption operations using a symmetric key algorithm. Symmetric encryption / decryption instructions include two subtypes: symmetric encryption instructions and symmetric decryption instructions, used to encrypt plaintext data to generate ciphertext or decrypt ciphertext data to restore plaintext, respectively. The symmetric encryption / decryption circuit is a dedicated hardware circuit within the coprocessor used to execute symmetric key algorithm encryption and decryption operations, corresponding to the aforementioned... Figure 1The symmetric encryption engine shown.

[0124] Streaming mode is a working method for symmetric encryption / decryption circuits to process data. It allows data to be input and output block by block in a continuous stream, without waiting for the complete data to be loaded before processing begins. In streaming mode, symmetric encryption / decryption circuits employ a pipelined architecture, breaking down the encryption or decryption process into multiple stages: as the first block of data enters the first stage, the second block can enter the first stage, while the first block enters the second stage, and so on, ensuring that a processing result is output every clock cycle. Common streaming modes include Galois / counter mode, counter mode, ciphertext feedback mode, and output feedback mode. These modes convert block ciphers into stream ciphers, enabling block-by-block data processing, and are suitable for scenarios such as network data encryption and disk encryption. Block-by-block processing refers to the symmetric encryption / decryption circuit dividing business transaction data into fixed-size blocks and sequentially performing encryption or decryption operations on each block.

[0125] For example, when the main processor generates a custom symmetric encryption / decryption instruction `aes_encrypt rs1 rs2` or `aes_decrypt rs1 rs2` based on the business transaction instruction, the coprocessor captures the instruction through the instruction interface and parses the plaintext or ciphertext buffer address (pointed to by rs1) and key handle (pointed to by rs2) from the instruction parameters. Then, the coprocessor loads the symmetric key from the internal key storage unit or system memory into a dedicated register based on the key handle. After the key is loaded, the coprocessor loads the plaintext or ciphertext data to be processed from the system memory buffer in batches into the on-chip temporary storage. The symmetric encryption / decryption circuit then begins to divide the business transaction data into fixed-size blocks, processing multiple bytes per clock cycle. The hardware automatically performs operations such as byte substitution, row shifting (byte position rearrangement), column obfuscation, and round key addition. For counter mode, the encryption / decryption engine adopts a pipelined architecture so that a processing result can be output per clock cycle, significantly improving throughput. For Galois / counter mode, authentication tags are calculated simultaneously during encryption, and tag integrity is automatically verified during decryption. After data processing is complete, the coprocessor writes the encrypted ciphertext data (or decrypted plaintext data) and an optional authentication tag directly back to a designated area of ​​system memory via DMA, and updates the final status register (such as indicating successful operation, successful or failed authentication tag verification, etc.). Then, it triggers an interrupt or sets a status flag to notify the main processor. The main processor reads the status register to confirm the operation is complete and can then use the processed data. This embodiment can complete the entire encryption or decryption process with a single symmetric encryption / decryption instruction. The symmetric encryption / decryption circuit processes data block by block in streaming mode, and can process multiple bytes per clock cycle, significantly improving encryption / decryption throughput and energy efficiency.

[0126] In one embodiment of this application, if the instruction type is a key derivation instruction, the target unit is determined to be a key derivation circuit; the key derivation circuit performs key derivation operations on the business transaction data corresponding to the key derivation instruction to generate a key as the operation result.

[0127] Specifically, the key derivation instruction triggers the coprocessor to perform key derivation operations for hierarchical deterministic wallets. The key derivation circuit is a dedicated hardware circuit within the coprocessor for performing key derivation operations for hierarchical deterministic wallets. This circuit can complete the entire derivation process from seed to target subkey in response to a single key derivation instruction, without requiring software-written loops or multiple calls to hash functions.

[0128] In the context of key derivation instructions, business transaction data refers to the input data required for key derivation operations, including seed data and derivation paths. Seed data is the root key material for key derivation, typically generated by a random number generator, and is the source of the root key for a hierarchical deterministic wallet. Seed data can be stored in plaintext or encrypted and is loaded by the coprocessor during derivation. The derivation path indicates the path information for deriving a specific subkey from the seed, represented according to the format defined in the hierarchical deterministic wallet specification. A derivation path typically consists of a series of index values, with each index corresponding to a derivation level. For example, "m / 44' / 0' / 0' / 0 / 0" indicates: master key (m), conforming to BIP44 specification (44'), currency is Bitcoin (0'), account index is 0 (0'), external chain (0), address index is 0 (0). The apostrophe (') in the path indicates hard derivation.

[0129] Key derivation refers to the process by which a key derivation circuit generates a target key through multiple hash operations based on seed data and a derivation path. This key is used for address generation and transaction signing in blockchain wallets and can include a private key, chaincode, and a public key.

[0130] For example, when the main processor generates a custom key derivation instruction `key_derivers1 rs2` based on a business transaction instruction, the coprocessor captures the instruction through the instruction interface and parses the seed data address (pointed to by `rs1`) and the derivation path address (pointed to by `rs2`) from the instruction parameters. The coprocessor then loads the seed data and derivation path from system memory into on-chip temporary storage in batches. The key derivation circuit first performs a hash operation on the seed data to generate a master private key and a master chain code (each 256 bits), which serve as the root key. Then, it derives subkeys level by level according to the index sequence in the derivation path. That is, for each level of index in the path, based on the chain code of the parent key and the index value, it distinguishes between hard derivation and ordinary derivation and performs a hash operation. The first 256 bits of the result are added to the parent private key to obtain the sub-private key, and the last 256 bits are used as the sub-chain code. The intermediate results (sub-private key and sub-chain code) generated at each level of derivation are temporarily stored in an internal dedicated register, without needing to be written back to memory, thus avoiding frequent data transfer. The above process is repeated until all indices in the derivation path are processed to obtain the target key. After key derivation is complete, the coprocessor writes the final derived key pair (private key and public key) and chaincode back to a designated area of ​​system memory via registers or DMA, for upper-layer applications to generate blockchain addresses or sign transactions. This embodiment's solution completes the entire derivation process from seed to target subkey with a single key derivation instruction, significantly improving wallet initialization and address generation efficiency.

[0131] In one embodiment of this application, if the instruction type is a random number generation instruction, the target unit is determined to be a random number generation circuit; a physical noise source is obtained, and an original random bit stream is generated based on the physical noise source; the physical noise source includes physical phenomena used to generate random entropy; a health check is performed on the original random bit stream, the health check including at least one of a repeat count test, an adaptive scaling test, and a run-length test; a hash operation is performed on the original random bit stream that passes the check to generate a true random number as the operation result.

[0132] Specifically, the random number generation instruction is used to trigger the coprocessor to generate truly random numbers. The random number generation circuit is a dedicated hardware circuit within the coprocessor used to generate truly random numbers, corresponding to the aforementioned... Figure 1 The diagram shows a true random number generator. This circuit generates unpredictable true random numbers by collecting data from physical noise sources. These physical noise sources refer to hardware circuits or physical processes that utilize physical phenomena to generate random entropy, and may specifically include ring oscillator jitter, thermal noise, flicker noise, and quantum effects, etc.

[0133] The raw random bitstream is an unprocessed sequence of random bits directly output by the physical entropy source acquisition unit in the random number generation circuit. The raw random bitstream itself is not directly output as random numbers; it needs to undergo health checks and entropy extraction to become qualified true random numbers. Health checks refer to the process by which the random number generation circuit performs real-time statistical tests on the raw random bitstream. The purpose is to monitor the working status of the physical entropy source and ensure that the quality of the output random numbers meets standard requirements. The health check circuit runs continuously during random number generation; once an anomaly is detected, it immediately triggers an alarm and stops outputting. Health checks include at least one of the following tests: Repeat counting test, which monitors the number of consecutive identical bits in the raw random bitstream. When the number of consecutive identical bits exceeds a preset threshold range, it is considered abnormal. This test is used to detect whether the entropy source is experiencing a jamming fault (such as outputting only all 0s or all 1s) or low-frequency drift; Adaptive ratio test, which monitors whether the ratio of 0s and 1s in the raw random bitstream is severely imbalanced. Within a fixed-length detection window, the number of 0s and 1s is counted; if either ratio exceeds a preset range (such as 40% to 60%), it is considered abnormal. This test is used to detect whether there is a serious statistical bias in the entropy source; the run test monitors whether the distribution of run lengths of consecutive identical bits in the original random bit stream conforms to expectations. It counts the occurrences of run lengths of different lengths (e.g., consecutive identical bits of length 1, 2, 3…), and if the number of occurrences of a run of a certain length exceeds a preset range, it is judged as an anomaly. This test is used to detect whether the entropy source has periodic patterns or other non-random characteristics.

[0134] For example, when the main processor generates a custom random number generation instruction `rng_get` based on a business transaction instruction, the coprocessor captures this instruction through the instruction interface. Subsequently, the physical entropy source acquisition unit in the random number generation circuit collects physical noise sources such as ring oscillator jitter and samples the oscillator output using a reference clock to generate a raw random bitstream. Then, the online self-test circuit performs real-time health checks on the raw random bitstream, including repeat count tests, adaptive ratio tests, and run-length tests, to ensure that the entropy source is working properly. Next, the raw random bitstream that has passed the health check is input into the entropy extraction circuit, which uses the hash operation circuit in the coprocessor to perform hash operations, extracting entropy and eliminating any possible deviations and correlations in the raw bitstream to generate uniformly distributed true random numbers. Finally, the generated true random numbers are directly written to a designated register of the main processor. It is evident that the entire random number generation process requires no external data input and is entirely completed automatically by the coprocessor's internal hardware, ensuring the unpredictability and high quality of the random numbers. This provides a reliable random entropy source for security-sensitive operations such as key generation and signature nonce in blockchain terminal devices, fundamentally eliminating the security risk of predictable pseudo-random numbers.

[0135] It should be noted that the above instructions are only some of the instruction types in this application. In this application, there may also be other custom cryptographic operation instructions, which are not limited here.

[0136] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0137] The following describes an apparatus embodiment of this application, which can be used to execute the blockchain-based data processor method in the above embodiments of this application. Figure 3 A schematic block diagram illustrating the structure of a blockchain-based data processing device provided in an embodiment of this application is shown. Figure 3 As shown, the data processing apparatus provided in this application embodiment includes: The instruction generation module 310 is used to generate cryptographic operation instructions based on the business transaction instructions through the main processor, and to send the cryptographic operation instructions to the coprocessor; the cryptographic operation instructions are used to perform encrypted calculations on the business transaction data corresponding to the business transaction instructions; The type identification module 320 is used to receive the cryptographic operation instruction through the coprocessor and identify the instruction type of the cryptographic operation instruction; the instruction type is used to indicate the cryptographic operation type corresponding to the cryptographic operation instruction; The instruction execution module 330 is used to execute the business transaction instruction through the main processor and to execute the cryptographic operation instruction according to the instruction type through the coprocessor.

[0138] In one embodiment of this application, the instruction generation module 310 is specifically used for: Identify the instruction identifier of the business transaction instruction, and determine whether the business transaction instruction needs to perform cryptographic operations based on the instruction identifier; wherein, the instruction identifier includes an identifier set at a preset position during the compilation stage of the business transaction instruction, used to indicate whether the business transaction instruction needs to perform cryptographic operations; If the instruction identifier indicates that the business transaction instruction needs to perform cryptographic operations, then the cryptographic data in the business transaction instruction is extracted and encapsulated to generate a cryptographic operation instruction; the cryptographic data includes the type of cryptographic operation and the address information of the business transaction data required to perform the cryptographic operation.

[0139] In one embodiment of this application, the type identification module 320 is specifically used for: Parse the opcode of the cryptographic operation instruction; the opcode includes a preset encoding value indicating the type of instruction. The instruction type matching the cryptographic operation instruction is determined by searching a preset instruction mapping table based on the opcode; the preset instruction mapping table includes the association between the opcode and the instruction type.

[0140] In one embodiment of this application, the instruction execution module 330 is specifically used for: The target unit corresponding to the cryptographic operation instruction is determined according to the instruction type; The target unit performs cryptographic operations on the business transaction data to obtain the operation result.

[0141] In one embodiment of this application, the instruction execution module 330 is specifically used for: Obtain the first random number generated for the cryptographic operation instruction; The first random number and the business transaction data are pre-encrypted to generate computational data; Cryptographic operations are performed on the data to obtain the results.

[0142] In one embodiment of this application, the instruction execution module 330 is specifically used for: Obtain multiple second random numbers, each second random number corresponding to one clock cycle in the cryptographic operation process performed by the target unit; insert idle clock cycles into the instruction pipeline corresponding to the cryptographic operation instruction based on the second random numbers; wherein, the instruction pipeline includes multiple execution steps corresponding to the cryptographic operation instruction; the idle clock cycles include clock cycles in which no operation is performed; and / or The power consumption status value of the target unit is monitored; the power consumption status value is used to indicate the energy consumed by the target unit per unit time; when the power consumption status value is lower than a preset threshold range, a pseudo-operation is performed to compensate for the power consumption of the target unit, so that the power consumption status value of the target unit during the execution of cryptographic operations is within the preset threshold range; the pseudo-operation includes energy consumption operations that do not perform cryptographic operations and do not generate operation results.

[0143] In one embodiment of this application, the instruction execution module 330 is specifically used for: If the instruction type of the cryptographic operation instruction is a post-quantum signature generation instruction, then the business transaction data corresponding to the post-quantum signature generation instruction is signed to generate a post-quantum signature as the operation result. If the instruction type of the cryptographic operation instruction is a post-quantum signature verification instruction, then a commitment to be verified is generated based on the business transaction data corresponding to the post-quantum signature verification instruction; the commitment to be verified is used to verify whether the signer knows the private key used to sign the business transaction data; the commitment to be verified is compared with the commitment carried in the post-quantum signature of the post-quantum signature verification instruction, and the comparison result is used as the operation result; wherein, if the comparison result indicates that the commitment to be verified is consistent with the commitment carried in the post-quantum signature of the post-quantum signature verification instruction, then the post-quantum signature in the post-quantum signature verification instruction is valid; if the comparison result indicates that the commitment to be verified is inconsistent with the commitment carried in the post-quantum signature of the post-quantum signature verification instruction, then the post-quantum signature in the post-quantum signature verification instruction is invalid.

[0144] The specific details of the data processing apparatus provided in the various embodiments of this application have been described in detail in the corresponding method embodiments, and will not be repeated here.

[0145] Figure 4 A schematic block diagram of a computer system structure for implementing the technical solution of this application is shown.

[0146] It should be noted that, Figure 4 The computer system 400 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0147] like Figure 4 As shown, the computer system 400 includes a central processing unit (CPU) 401, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 402 or programs loaded from storage section 407 into random access memory (RAM). The RAM 403 also stores various programs and data required for system operation. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output interface 405 (I / O interface) is also connected to the bus 404.

[0148] The following components are connected to the input / output interface 405: an input section 406 including a keyboard, mouse, etc.; an output section 407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 408 including a hard disk, etc.; and a communication section 409 including a network interface card such as a local area network card, modem, etc. The communication section 409 performs communication processing via a network such as the Internet. A drive 410 is also connected to the input / output interface 405 as needed. A removable medium 411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 410 as needed so that computer programs read from it can be installed into the storage section 408 as needed.

[0149] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. The transmitted data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0150] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0151] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0152] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the methods according to the embodiments of this application.

[0153] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0154] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A data processing method based on blockchain, characterized in that, The blockchain includes a terminal device, which includes a main processor and a coprocessor. The main processor is used to process business transactions, and the coprocessor is integrated on the main processor. The method includes: The main processor generates cryptographic operation instructions based on the business transaction instructions and sends these instructions to the coprocessor. The cryptographic operation instructions are used to perform cryptographic operations on the business transaction data corresponding to the business transaction instructions. The coprocessor receives the cryptographic operation instructions and identifies the instruction type of the cryptographic operation instructions; the instruction type is used to indicate the cryptographic operation type corresponding to the cryptographic operation instructions. The main processor executes the business transaction instructions, and the coprocessor executes the cryptographic operation instructions according to the instruction type.

2. The data processing method based on blockchain according to claim 1, characterized in that, The coprocessor includes multiple target units, and each target unit includes hardware circuitry in the coprocessor that performs cryptographic operations. The execution of the cryptographic operation instructions by the coprocessor according to the instruction type includes: The target unit corresponding to the cryptographic operation instruction is determined according to the instruction type; The target unit performs cryptographic operations on the business transaction data to obtain the operation result.

3. The data processing method based on blockchain according to claim 2, characterized in that, The step of performing cryptographic operations on the business transaction data to obtain the operation result includes: Obtain the first random number generated for the cryptographic operation instruction; The first random number and the business transaction data are pre-encrypted to generate computational data; Cryptographic operations are performed on the data to obtain the results.

4. The data processing method based on blockchain according to claim 3, characterized in that, In the process of performing cryptographic operations on the computational data to obtain the computation result, the method further includes: Obtain multiple second random numbers, each second random number corresponding to one clock cycle in the cryptographic operation process performed by the target unit; insert idle clock cycles into the instruction pipeline corresponding to the cryptographic operation instruction based on the second random numbers; wherein, the instruction pipeline includes multiple execution steps corresponding to the cryptographic operation instruction; the idle clock cycles include clock cycles in which no operation is performed; and / or The power consumption status value of the target unit is monitored; the power consumption status value is used to indicate the energy consumed by the target unit per unit time; when the power consumption status value is lower than a preset threshold range, a pseudo-operation is performed to compensate for the power consumption of the target unit, so that the power consumption status value of the target unit during the execution of cryptographic operations is within the preset threshold range; the pseudo-operation includes energy consumption operations that do not perform cryptographic operations and do not generate operation results.

5. The data processing method based on blockchain according to claim 1, characterized in that, The instruction types include post-quantum signature generation instructions and post-quantum signature verification instructions; the execution of the cryptographic operation instructions according to the instruction types includes: If the instruction type of the cryptographic operation instruction is a post-quantum signature generation instruction, then the business transaction data corresponding to the post-quantum signature generation instruction is signed to generate a post-quantum signature as the operation result. If the instruction type of the cryptographic operation instruction is a post-quantum signature verification instruction, then a commitment to be verified is generated based on the business transaction data corresponding to the post-quantum signature verification instruction; the commitment to be verified is used to verify whether the signer knows the private key used to sign the business transaction data; the commitment to be verified is compared with the commitment carried in the post-quantum signature of the post-quantum signature verification instruction, and the comparison result is used as the operation result; wherein, if the comparison result indicates that the commitment to be verified is consistent with the commitment carried in the post-quantum signature of the post-quantum signature verification instruction, then the post-quantum signature in the post-quantum signature verification instruction is valid; if the comparison result indicates that the commitment to be verified is inconsistent with the commitment carried in the post-quantum signature of the post-quantum signature verification instruction, then the post-quantum signature in the post-quantum signature verification instruction is invalid.

6. The data processing method based on blockchain according to claim 1, characterized in that, The step of generating cryptographic operation instructions based on business transaction instructions includes: Identify the instruction identifier of the business transaction instruction, and determine whether the business transaction instruction needs to perform cryptographic operations based on the instruction identifier; wherein, the instruction identifier includes an identifier set at a preset position during the compilation stage of the business transaction instruction, used to indicate whether the business transaction instruction needs to perform cryptographic operations; If the instruction identifier indicates that the business transaction instruction needs to perform cryptographic operations, then the cryptographic data in the business transaction instruction is extracted and encapsulated to generate a cryptographic operation instruction; the cryptographic data includes the type of cryptographic operation and the address information of the business transaction data required to perform the cryptographic operation.

7. The data processing method based on blockchain according to claim 1, characterized in that, The instruction type for identifying the cryptographic operation instruction includes: Parse the opcode of the cryptographic operation instruction; the opcode includes a preset encoding value indicating the type of instruction. The instruction type matching the cryptographic operation instruction is determined by searching a preset instruction mapping table based on the opcode; the preset instruction mapping table includes the association between the opcode and the instruction type.

8. A data processing device based on blockchain, characterized in that, include: The instruction generation module is used to generate cryptographic operation instructions based on the business transaction instructions through the main processor, and to send the cryptographic operation instructions to the coprocessor; the cryptographic operation instructions are used to perform encrypted calculations on the business transaction data corresponding to the business transaction instructions; A type identification module is used to receive the cryptographic operation instructions through the coprocessor and identify the instruction type of the cryptographic operation instructions; the instruction type is used to indicate the cryptographic operation type corresponding to the cryptographic operation instructions. The instruction execution module is used to execute the business transaction instruction through the main processor and to execute the cryptographic operation instruction according to the instruction type through the coprocessor.

9. An electronic device, characterized in that, include: Data processor; as well as A memory for storing executable instructions of the processor; wherein the processor executes the executable instructions, causing the electronic device to perform the blockchain-based data processing method according to any one of claims 1 to 7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the blockchain-based data processing method according to any one of claims 1 to 7.

Images