A trusted contract pre-running system and method based on FPGA

Abstract

The present invention discloses a trusted contract pre-running system and method based on FPGA, including a hardware programming accelerator, a software programming controller, and a direct memory access unit for data transmission between the two; the hardware programming accelerator includes multiple acceleration units and storage modules, and the Ethereum bytecode sequentially passes through the stages of fetching, decoding, executing, and writing back, and the hardware programming accelerator is controlled by the software programming controller; the software programming controller adopts the Ethereum control protocol to communicate, and sets the on-chip memory as a secure memory to store sensitive data; the system sets a hardware and software collaborative interrupt mechanism to complete complex tasks, safely and reliably protect sensitive data and control communication with the outside world. The present invention completes the equivalent implementation of the Ethereum virtual machine that is dynamically updated with the upgrade of the Ethereum network, and improves the pre-running efficiency, accuracy, security and reliability of smart contracts.

Description

Technical Field

[0001] The present invention relates to the field of hardware acceleration design, and in particular to a trusted contract pre-running system and method based on FPGA (Field-Programmable Gate Array). Background Art

[0002] Ethereum is a blockchain platform that has emerged in the past few years and provides a decentralized smart contract platform. Smart contracts are self-executing contracts that can perform predetermined actions without the intervention of a third party. They are stored in the form of code on the blockchain. This technology is widely used in finance, supply chain management, digital asset trading and other fields.

[0003] Contract pre-running is a method of pre-running smart contracts before formal execution to verify the correctness and security of the contract. Before the actual transaction occurs, the contract execution process can be simulated and analyzed through pre-running to ensure that the logic and results of the contract meet expectations and avoid potential loopholes and errors. Contract pre-running plays an important role in improving the reliability and security of the Ethereum network, especially for smart contracts involving large amounts of funds and complex logic, pre-running can provide additional protection. For security practitioners, fast contract pre-running can predict contract behavior before the contract reaches a consensus, identify total risks, and complete attack blocking. However, the traditional pre-running method relies on software simulation, which is inefficient and difficult to meet the high performance and high security requirements in actual applications. Due to the stack-based operand structure of the Ethereum virtual machine and the potential correlation between transactions, the execution of the Ethereum virtual machine is difficult to give full play to the multi-core execution performance of the central processor. Therefore, it is necessary to ensure the execution efficiency and sensitive data security of the remote contract pre-running service through hardware acceleration design and security design. Summary of the invention

[0004] In view of the deficiencies in the prior art, the present invention proposes a FPGA-based trusted contract pre-running system and method thereof.

[0005] The specific technical solutions are as follows:

[0006] A trusted contract pre-running system based on FPGA, comprising: a hardware programming accelerator on the FPGA, a software programming controller on the processor core of the FPGA, and a direct memory access unit for data transmission between the two; the hardware programming accelerator comprises a plurality of acceleration units and a storage module, the acceleration unit comprises a stack unit, an arithmetic acceleration unit, and a hash acceleration unit, and the storage module comprises a running memory module, a world state recording module, a code module, and an environment variable module; the Ethereum bytecode sequentially goes through the stages of instruction fetching, decoding, execution, and write-back, wherein the Ethereum bytecode is input into different data paths according to different types of instructions obtained in the decoding stage, and acts on the corresponding acceleration unit and storage module; the hardware programming accelerator is controlled by the software programming controller;

[0007] The software programming controller uses the Ethernet control protocol for communication, and the Ethernet control protocol includes: type code, uniformly encoded source address or target data address, and data; the on-chip memory of the processor on the board is set as a secure memory for storing sensitive data. If the space of the on-chip memory is insufficient, part of the data is encrypted and swapped out to the unsecure memory, and then swapped in and decrypted when needed;

[0008] The system sets a hardware-software collaborative interrupt mechanism. Under normal circumstances, the hardware programming accelerator works, and the software programming controller observes the status of the hardware programming accelerator in a polling manner. In the case of a control instruction interrupt, for complex semantic instructions that cannot be processed independently, the hardware programming accelerator is interrupted, and the system control is transferred to the software programming controller. The software programming controller receives the message of the Ethereum control protocol, and after performing corresponding operations on the hardware programming accelerator according to the message type, the system control is transferred to the hardware programming accelerator, and the hardware programming accelerator enters a working state.

[0009] In the case of data reading and writing interruption, when the hardware programming accelerator needs to access data that is not stored in it, the hardware programming accelerator is interrupted and the system control is transferred to the software programming controller. The software programming controller checks whether the required data is available in the on-chip memory. If not, it initiates a data query to the decentralized node and performs a Merkle tree check. The required data that passes the check is transmitted to the hardware programming accelerator through the direct memory access unit, and the hardware programming accelerator enters the working state.

[0010] Furthermore, the Ethereum bytecode goes through the stages of instruction fetch, decoding, execution, and writeback in sequence, and the operations performed in each stage are as follows:

[0011] (1) Instruction fetching stage: The hardware programming accelerator reads the Ethereum bytecode to be executed from the code module and stores it in the instruction decoding buffer; the Ethereum bytecode is a variable-length instruction set, and its length ranges from 1 byte to 33 bytes. The part exceeding 1 byte is the immediate value attached to the push-type instruction; the instruction decoding buffer uses a dual-port read and single-port write random access memory reader / writer. When reading instruction data, the address program counter and program counter + 1 are respectively passed in to read 1 byte from the program counter address of the code module, and 32 bytes of code data are read from the program counter + 1 address;

[0012] (2) Decoding stage: The hardware programming accelerator decodes the extracted Ethereum bytecode. According to the different functions of the instructions, the decoded instructions are divided into six categories, including: stack operation instructions, arithmetic instructions, hash instructions, environment variable instructions, data instructions, and control instructions;

[0013] The stack operation instructions only change the state of the stack and are input into the stack unit for execution during the execution phase;

[0014] The arithmetic instruction takes a number of operands from the top of the stack unit, writes the result back to the top of the stack unit after the calculation, and inputs the arithmetic execution unit in the execution stage;

[0015] The hash instruction takes out a number of operands from the top of the stack unit, reads continuous data from the running memory according to the address, and inputs the data into the hash acceleration unit in the execution stage;

[0016] The environment variable instruction is used to query the contract execution environment variables and world status, take out the operand from the top of the stack unit according to the specific instruction, and input the environment variable module in the execution stage;

[0017] The data instruction acts on the running memory module and the world state recording module, and is used to take out the operand from the top of the stack unit, and is sent to the corresponding module to perform data reading and writing operations in the execution stage;

[0018] The control instructions are used to cooperate with the software and hardware collaborative interrupt mechanism;

[0019] (3) Execution phase: The hardware programming accelerator sends the Ethereum bytecode to the corresponding data path according to the different instruction categories obtained by decoding. Each data path corresponds to a different acceleration unit and storage module;

[0020] (4) Write-back stage: The hardware programming accelerator writes the result of instruction execution back to the top of the stack unit.

[0021] Furthermore, the stack unit includes registers and random access memory readers and writers, which are used to provide the necessary top stack operands for all instruction executions; the stack operation instructions in the Ethereum bytecode that only change the state of the stack are input into the stack unit for execution; the remaining instructions read the top stack data from the stack unit as operands;

[0022] At most 16 operands at the top of the stack are stored in registers, and the remaining elements are stored in random access memory readers and writers; when the registers are full, the old top data is written to the random access memory readers and writers in sequence; when the registers are free, the old top data is read from the random access memory readers and writers and written to the registers; when the Ethereum bytecode accesses the 17th element at the top of the stack, it is equivalent to reading the last written data from the random access memory reader and writer; when the Ethereum bytecode pops multiple elements from the top of the stack in a single cycle, it is equivalent to reading an equal amount of data from the random access memory reader and writer and writing them to the registers in sequence.

[0023] Furthermore, the arithmetic acceleration unit includes an arithmetic logic unit and a multiplication and division logic unit; the multiplication and division logic unit supports 512-bit multiplication and division operations to adapt to the modulo addition instructions and modulo multiplication instructions of the Ethereum bytecode, the multiplication operation is performed by the quaternary-based Booth algorithm, and the division operation is performed by the non-borrow division algorithm.

[0024] Furthermore, the hash acceleration unit is used to execute hash instructions, which are Keccak-256 hash algorithms. The algorithm uses 256 bits as a single input, feeds the data into a sponge structure for squeezing, and obtains a 256-bit output. The hash acceleration unit includes an input buffer and a hash core unit. The input buffer is used to feed data 256 bits at a time, and control the running memory module according to the working status of the hash core unit. The hash core unit has configurable parameters for completing a sponge structure update operation within different numbers of clock cycles.

[0025] Furthermore, the complex semantic instructions that the hardware programming accelerator cannot process alone include CALL instructions. When the hardware programming accelerator executes the CALL instruction, the hardware programming accelerator is interrupted and the control of the system is transferred to the software programming controller; the software programming controller receives the Ethereum control protocol request of the hardware programming accelerator through polling, and according to the semantics of the CALL instruction, first copies the currently executed context data from the hardware programming accelerator and stores it in the local data storage; the software programming controller writes new context data of the calling contract to the hardware programming accelerator according to the semantics of the CALL instruction; the software programming controller returns the control of the system to the hardware programming accelerator, and sets the hardware programming accelerator to enter the working state.

[0026] Furthermore, the context data includes: stack, running memory, state record, and environment variables.

[0027] A trusted contract pre-running method based on FPGA is implemented based on the trusted contract pre-running system based on FPGA, and includes the following steps:

[0028] S1: The FPGA device is started by the trusted secure boot function preset by the hardware device manufacturer, and establishes communication with the remote contract pre-run service demander. The two parties negotiate to exchange communication keys and verify whether the measurement value of the FPGA-based trusted contract pre-run system is consistent with the measurement value of the system pre-provided by the remote contract pre-run service provider. After the verification is passed, proceed to the next step;

[0029] S2: The remote contract pre-run service demander encrypts the smart contract data to be pre-run and executes through the network port and transmits it to the FPGA device, which is received by the software programming controller in a polling manner;

[0030] S3: The software programming controller controls the hardware programming accelerator according to the needs and characteristics of the smart contract, initializes the hardware programming accelerator and writes necessary execution information, wherein the necessary execution information includes the code data of the smart contract and the environment variables called by the smart contract; the software programming controller controls the hardware programming accelerator to enter the execution state, and monitors the running state of the hardware programming accelerator by polling;

[0031] S4: The hardware programming accelerator sends different data paths to accelerate the execution of smart contracts according to the characteristics of the Ethereum virtual machine bytecode. During the execution process, the on-chip memory and the software and hardware collaborative interrupt mechanism are used to realize the execution of complex semantic instructions and the encryption call of data; after the smart contract execution is completed, it enters the waiting state;

[0032] S5: The software programming controller reads the contract pre-running result of the hardware programming accelerator through the direct memory access unit, and then encrypts and forwards the result to the remote contract pre-running service demander through the network port.

[0033] Furthermore, the specific operation of S1 is as follows: FPGA uses the key preset by the hardware device manufacturer as the trusted root, measures the startup file of the next level step by step, and generates a signature for the startup process through the key preset by the hardware device manufacturer; the remote contract pre-run service demander challenges the hardware device manufacturer of the FPGA device, requiring it to prove the startup process, and verify whether the measurement value of the trusted contract pre-run system is consistent with the measurement value of the system pre-provided by the remote contract pre-run service provider; if they are inconsistent, it is considered that the service has a security risk and the pre-run service is stopped; if they are consistent, it is considered that the remote FPGA device is executing the service claimed by the remote contract pre-run service provider, that is, the remote contract pre-run service provider has deployed a trusted public execution environment. In this process, the security of the contract pre-run service is ensured by auditing the code disclosed by the remote contract pre-run service provider;

[0034] After the proof is completed, the remote contract pre-run service demander and the remote contract pre-run service provider negotiate a temporary public key for the pre-run behavior through a key exchange protocol, which is used as the symmetric encryption key for the entire execution process. Both parties communicate using ciphertext data encrypted by this key.

[0035] The beneficial effects of the present invention are:

[0036] (1) The present invention proposes a trusted contract pre-running system based on FPGA. Through the hardware-software cooperative interrupt mechanism set between the hardware programming accelerator on the FPGA and the software programming controller on the processor core on the FPGA board, an equivalent implementation of the Ethereum virtual machine that can be dynamically updated with the upgrade of the Ethereum network is completed. This system supports all Ethereum bytecode instructions and has exactly the same semantics and functions as the Ethereum virtual machine specified in the Ethereum Yellow Paper specification, effectively improving the pre-running efficiency and credibility of Ethereum smart contracts.

[0037] (2) The present invention proposes a trusted contract pre-running method based on FPGA, which uses remote trusted execution technology to protect the security of sensitive data and uses Merkle tree verification to defend against attacks from malicious decentralized nodes, thereby improving the security and reliability of the Ethereum contract pre-running service and providing solid technical support and practical exploration for the development of the Ethereum contract pre-running service. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 This is an architecture diagram of a trusted contract pre-running system based on FPGA in an embodiment of the present invention.

[0039] Figure 2 is an architectural diagram of a stack unit in an embodiment of the present invention.

[0040] Figure 3 Schematic diagram of controlling instruction interruption in an embodiment of the present invention.

[0041] Figure 4 It is a flow chart of a trusted contract pre-running method based on FPGA in an embodiment of the present invention. DETAILED DESCRIPTION

[0042] The present invention will be described in detail below according to the accompanying drawings and preferred embodiments, and the purpose and effect of the present invention will become more clear. The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0043] like Figure 1 As shown, a trusted contract pre-running system based on FPGA includes: a hardware programming accelerator on the FPGA, a software programming controller on the processor core on the FPGA board, and a direct memory access unit (Direct Memory Access, hereinafter referred to as DMA).

[0044] DMA is used for data transmission between the hardware programming accelerator and the software programming controller. DMA uses the AXI4 protocol for communication and requires a buffer at least as large as the processor core on the FPGA board to ensure the accuracy of data transmission. When data (including code, running memory, status records, execution context, etc.) needs to be transferred between the hardware programming accelerator and the software programming controller, the software programming controller sets the DMA configuration register through memory mapping (Memory-Mapped I / O, hereinafter referred to as MMIO) and waits for DMA to move data.

[0045] The hardware programming accelerator on the FPGA has multiple control registers, which can be divided into registers used to indicate the operating status of the accelerator and registers used to store interrupt requests issued by the accelerator. In this system, these control registers are controlled by the software programming controller, and the AXI4Lite protocol based on the software programming controller is used to read and write registers, so that the software programming controller has complete control over the hardware programming accelerator.

[0046] The hardware programming accelerator on the FPGA includes three acceleration units and four storage modules; the acceleration units include: stack unit, arithmetic acceleration unit, hash acceleration unit; the storage modules include: running memory module (memory), world state recording module (storage), code module, environment variable module. The hardware programming accelerator adopts a sequential four-stage pipeline structure, and the Ethereum bytecode will be executed in four stages: instruction fetch, decoding, execution, and write back. In the instruction fetch stage, the code is taken out in units of 33 bytes. In the decoding stage, the decoder decodes the instructions. In the execution stage, the stack unit provides the required operands and sends them to the corresponding execution unit or module for execution according to the type of bytecode. In the write-back stage, the result returned by the bytecode is written to the top of the stack as a new operand. The operations performed in the four stages are as follows:

[0047] (Phase 1) Instruction fetching phase: The hardware programming accelerator reads the Ethereum bytecode to be executed from the code module and stores it in the instruction decoding buffer. The Ethereum bytecode is a variable-length instruction set, and its length ranges from 1 byte to 33 bytes (the part exceeding 1 byte is the immediate value attached to the push-type instruction), so it is necessary to fetch up to 33 bytes of data from the instruction decoding buffer during decoding. The hardware programming accelerator designs a special instruction decoding buffer to adapt to the characteristics of the Ethereum bytecode, thereby reducing the waiting time overhead during the instruction fetching process; in this embodiment, a dual-port read and single-port write random access memory reader / writer is used as the instruction decoding buffer. When reading instruction data from the instruction decoding buffer, the address program counter (pc) and program counter + 1 are respectively passed in, and 1 byte of code data is read from the program counter address of the code module, and 32 bytes of code data are read from the program counter + 1 address. This design can effectively reduce the hardware logic complexity of the instruction decoding buffer and reduce the timing pressure of the instruction fetching phase.

[0048] (Phase 2) Decoding phase: The hardware programming accelerator decodes the extracted Ethereum bytecode in the decoding phase. According to the different functions of the instructions, the decoded instructions can be divided into six categories. Each category of instructions corresponds to different data paths in the execution phase and acts on different acceleration units and storage modules. The details are as follows:

[0049] Stack operation instructions: including push instruction (PUSH), pop instruction (POP), swap instruction (SWAP), and copy instruction (DUP). These instructions only change the state of the stack and will be sent to the stack unit for execution during the execution phase.

[0050] Arithmetic instructions: include instructions with bytecodes starting from 0x01 to 0x1D. These instructions take a number of operands from the top of the stack unit, write the result back to the top of the stack unit through arithmetic operations, and are sent to the arithmetic execution unit for execution during the execution phase.

[0051] Hash instruction: specifically refers to Keccak-256 hash instruction. This type of instruction takes out several operands from the top of the stack unit, reads continuous data from the running memory according to the address, and is sent to the hash acceleration unit for execution during the execution stage.

[0052] Environment variable instructions: The functions of this type of instructions include querying the contract execution environment variables and querying the world status. According to the specific instructions, the operands are taken from the top of the stack unit and sent to the environment variable module during the execution phase.

[0053] Data instructions: These instructions act on the running memory module and the world status recording module. They are used to take operands from the top of the stack unit and are sent to the corresponding module for data reading and writing operations during the execution phase.

[0054] Control instructions: These instructions represent relatively complex control semantics, involving the switching, backup, and modification of the Ethereum virtual machine context. Hardware programming accelerators alone cannot execute their complex semantics well, and software programming controllers need to be introduced for collaborative execution. For specific collaborative execution methods, please see the description of the hardware and software collaborative interrupt mechanism later.

[0055] (Phase 3) Execution phase: During the execution phase, the hardware programming accelerator sends the Ethereum bytecode to the corresponding data path according to the different instruction categories obtained by decoding. Each data path corresponds to a different acceleration unit and storage module, as follows:

[0056] (1) Stack unit: The function of the stack unit is equivalent to the stack implemented by the Ethereum virtual machine software. It provides the necessary top-of-stack operands for all instruction executions. The PUSH, POP, SWAP, and DUP instructions in the Ethereum bytecode will be sent to the stack unit for execution, and other instructions need to read the top-of-stack data from the stack unit as operands. Ethereum bytecode instructions will access at most 17 operands at the top of the stack, pop 7 operands, and write 1 operand. Based on this property, the stack unit in this system adopts a structure that combines registers and random access memory readers and writers, such as Figure 2 Specifically, up to 16 operands at the top of the stack are stored in registers, and the remaining elements are stored in random access memory readers; when the registers are full, the old top-of-stack data will be written to the random access memory readers in order, and vice versa, when there is space in the registers, the old top-of-stack data will be read from the random access memory readers and written to the registers.

[0057] When the Ethereum bytecode accesses the 17th element at the top of the stack, this behavior is equivalent to reading the last written data from the random access memory reader / writer. When the Ethereum bytecode pops multiple elements at the top of the stack in a single cycle, this behavior is equivalent to reading an equal amount of data from the random access memory reader / writer and writing it into the register in sequence. The random access memory reader / writer needs to have 7 read ports and 1 write port. It can be designed with sub-modules grouped by subscripts to convert it into 16 single-channel read and write random access memory readers / writers, reducing the logical complexity of the hardware programming part. This design makes full use of the characteristics of the Ethereum bytecode instructions on the stack, summarizes all operations on the stack into operations on registers and random access memory readers / writers, and uses the high read and write speed of registers to accelerate the execution speed of the stack unit and reduce timing pressure.

[0058] (2) Arithmetic Acceleration Unit: The computational instructions in the Ethereum bytecode will be sent to the arithmetic acceleration unit for execution. The arithmetic acceleration unit includes an arithmetic logic unit and a multiplication and division logic unit. The multiplication and division logic unit supports 512-bit multiplication and division operations to adapt to the ADDMOD (modular addition) and MULMOD (modular multiplication) instructions of the Ethereum bytecode, uses the quaternary-based Booth algorithm for multiplication operations, and uses the non-borrow division algorithm for division operations, which shortens the clock cycles spent on the execution of multiplication and division instructions.

[0059] (3) Hash acceleration unit: Hash instructions in the Ethereum bytecode will be sent to the hash acceleration unit for execution. The hash instructions in Ethereum specifically refer to the Keccak-256 hash algorithm, which uses 256 bits as a single input, sends the data into the sponge structure for compression, and finally obtains a 256-bit output. The hash acceleration unit includes an input buffer and a hash core unit. The input buffer is responsible for inputting data 256 bits at a time and controlling the running memory module according to the working status of the hash core unit. The hash core unit has configurable parameters and can complete a sponge structure update operation within different clock cycles. In actual use, the hash acceleration unit can be configured according to the actual performance of the selected FPGA to achieve the best effect.

[0060] (4) Storage module: In the hardware programming accelerator part, there are multiple storage modules, including: running memory module, world state record module, code module, and environment variable module; they all use pages as the basic data management size and are equipped with page tables for management. The size of each page is 1024 bytes. All data has a unified address encoding. When the software programming controller on the processor core wants to access a certain data, it can quickly query the status of the corresponding page through the unified address and perform data transmission operations according to the actual situation. The running memory module and the world state record module are designed with a 4KB data note to reduce the performance loss caused by data access loss. During the execution of Ethereum bytecode, the storage module provides the reading and writing functions of data information, and completes the execution task together with the stack unit and hash acceleration unit.

[0061] (Phase 4) Write-back phase: In the write-back phase, the hardware programming accelerator writes the result of instruction execution back to the top of the stack unit. This phase adopts a bypass transmission design to reduce data competition in the pipeline and improve the acceleration performance of the hardware programming accelerator.

[0062] The software programming controller on the processor core on the FPGA board includes local data storage for maintaining all complex data structures of the call stack and local world state. The data structure is maintained in the form of a stack, and each item in the stack corresponds to the running memory, stack content, and state record modification under a contract execution state. When the hardware programming accelerator needs to query the world state or data, the software programming controller first searches for the relevant address and data information in the local data storage (i.e., the data content stored in the on-chip memory), and then obtains it from the decentralized node if it is not found. This design reduces the repeated overhead of obtaining data from decentralized nodes by locally storing data of high-frequency contracts and high-frequency information.

[0063] The software programming controller can control the behavior of the hardware programming accelerator and prepare an execution environment for the hardware programming accelerator. The software programming controller uses a custom Ethereum control protocol for communication, which consists of a type code, a uniformly encoded source address or target data address, and data. Depending on the type code, the Ethereum control protocol data packet can represent the data transmission requirements, and can also be used by the software programming controller to control the state of the hardware programming accelerator. Among them, the protocol data packet representing the state control corresponds to the change of the state of the hardware programming accelerator, or the software programming controller controls the state of the hardware programming accelerator; the protocol data packet representing the data transmission corresponds to the hardware programming accelerator needing to access data outside the hardware or the software programming controller, thereby communicating data with external decentralized nodes. In order to be compatible with various types of data transmission requirements, these Ethereum control protocols use uniformly encoded source addresses or target data addresses, that is, uniformly encoded addresses are designed for the state registers, stack units, and storage modules of the hardware programming accelerator.

[0064] During the execution of the system, the software programming controller will inevitably read the sensitive data generated during the contract pre-running process. In order to protect sensitive data from being stolen by the pre-running service provider, this system introduces the concept of secure memory. The on-chip memory (On-Chip Memory) of the processor on the board is set to be a reliable secure memory, and the data stored in it is not easy to be leaked or stolen, while other storage such as double-rate synchronous dynamic random access memory is regarded as unsecure memory, which is used as a backup memory to store the encrypted runtime context content when the on-chip memory is insufficient. During the execution of the system, the software programming controller will store all sensitive data in the on-chip memory to protect its confidentiality and integrity. If the space of the on-chip memory is insufficient, part of the data will be encrypted with the negotiated key, and the integrity and confidentiality of the sensitive data will be protected by message signing and symmetric encryption methods, and swapped out to the unsecure memory, waiting to be swapped in and decrypted when needed. In this way, this system protects the data security of sensitive data during the contract pre-running process.

[0065] The present invention uses a software-hardware collaborative interrupt mechanism to complete complex tasks, safely and reliably protect sensitive data and control external communications; the software-hardware collaborative interrupt mechanism includes two situations: control instruction interrupt and data read and write interrupt, as follows:

[0066] Control instruction interruption: There are some control-type instructions with complex semantics and friendly to software design (hereinafter referred to as complex semantic instructions) in the Ethereum bytecode instructions, such as CALL, STOP instructions, etc. These instructions often involve complex operations such as context switching, and are therefore not suitable for pure hardware programming solutions. In order to support this type of instruction, this system adopts a hardware-software collaborative interruption mechanism. Under normal circumstances, only one of the hardware programming accelerator and the software programming controller is in working state. That is, when the hardware programming accelerator is working, the software programming controller observes the status of the hardware programming accelerator in a polling manner. When the hardware programming accelerator encounters complex instructions that are difficult to handle alone, the hardware programming accelerator will be interrupted and send a signal to transfer control to the software programming controller. The software programming controller receives messages from the Ethereum control protocol and operates the hardware programming accelerator according to the message type, such as Figure 3 As shown, taking the CALL instruction as an example, when the hardware programming accelerator executes the CALL instruction, the hardware programming accelerator will fall into an interrupt and transfer the control of the system to the software programming controller. The software programming controller receives the Ethereum control protocol request of the hardware programming accelerator through polling. According to the semantics of the CALL instruction, the currently executed context data is first copied from the hardware programming accelerator and stored in the local data storage. The context data includes: stack, running memory, state record, and environment variables; then the software programming controller writes the new context data of the call contract to the hardware programming accelerator according to the semantics of the CALL instruction, that is, the new execution environment; finally, the software programming controller returns the control of the system to the hardware programming accelerator and sets the hardware programming accelerator to enter the working state. Through this hardware-software collaborative interrupt mechanism, the behavior of the hardware programming accelerator itself for complex semantic instructions is simplified to fall into an interrupt until the software programming controller allows it to continue execution. Therefore, the accelerator does not need to consider how to implement complex control instruction semantics, but only needs to complete relatively simple execution tasks. This design greatly reduces the logical complexity of the hardware programming accelerator. Based on the above settings, this system can support all Ethereum bytecode instructions, has exactly the same semantics as the Ethereum virtual machine, and realizes complete Ethereum virtual machine functions.

[0067] Data read and write interruption: The Ethereum virtual machine has Turing completeness. In theory, it can support unlimited runtime memory and access to a huge world state, which is in conflict with the limited resources of the hardware programming accelerator. In order to achieve its Turing completeness, this system adopts a hardware-software collaborative interruption mechanism. When the hardware programming accelerator needs to access data that is not in the hardware programming accelerator, the hardware programming accelerator will fall into an interruption and send a signal to hand over the control to the software programming controller. The software programming controller receives the Ethereum control protocol message and operates the storage module of the hardware programming accelerator according to the message type: first, it searches for data in the on-chip memory of the processor core. If the required data is not in the on-chip memory, the software programming controller initiates a data query to the decentralized node, and then transfers the required data to the storage module of the hardware programming accelerator through DMA, and finally sets the hardware programming accelerator to re-enter the working state. In the process of asking the decentralized node, the software programming controller will also query the Merkle tree check of the data to prove that the data has not been maliciously tampered with, so as to ensure the correctness of the smart contract pre-running process.

[0068] According to the above-mentioned FPGA-based trusted contract pre-running system, this embodiment proposes a FPGA-based trusted contract pre-running execution method, which involves three roles: FPGA hardware equipment manufacturer (hereinafter referred to as manufacturer), remote contract pre-running service provider (hereinafter referred to as provider), and remote contract pre-running service demander (hereinafter referred to as demander). FPGA hardware equipment manufacturer refers to the manufacturer that provides FPGA equipment and needs to provide a trusted startup certificate for FPGA equipment; remote contract pre-running service provider refers to the service provider that deploys and provides this system on FPGA equipment, and needs to upload the hardware programming accelerator on the FPGA and the software programming controller on the processor core on the FPGA board in advance for the remote contract pre-running service demander to audit and obtain the hash value; remote contract pre-running service demander refers to the service user who needs to use this system, and needs to verify the trusted startup with the manufacturer before the service starts, and verify the world state hash value with the decentralized node after the service is completed.

[0069] like Figure 4 As shown, the method specifically comprises the following steps:

[0070] S1: The FPGA device is started through the trusted secure boot function preset by the manufacturer, and establishes communication with the demander. The two parties negotiate to exchange communication keys and verify whether the measurement values ​​of the FPGA-based trusted contract pre-run system are consistent with the measurement values ​​of the system pre-provided by the provider. After the verification is passed, proceed to the next step.

[0071] Specifically, FPGA uses the key preset by the manufacturer as the root of trust, measures the startup file of the next level step by step, and generates a signature for the startup process through the key preset by the manufacturer. The demander challenges the manufacturer of the FPGA device, requiring it to prove the startup process and verify whether the measurement value of the trusted contract pre-run system is consistent with the measurement value of the system pre-provided by the provider. If it is inconsistent, the demander can judge that there is a security risk in the service and stop further pre-running services; if it is consistent, the demander can believe that the remote FPGA device is executing the service claimed by the provider, that is, the provider has deployed a trusted public execution environment, and can ensure the security of the contract pre-run service by auditing the code disclosed by the provider. After completing the proof, the two parties (the demander and the provider) negotiate a temporary public key for the pre-run behavior through the key exchange protocol, which is used as the symmetric encryption key for the entire subsequent execution process. Both parties communicate with the ciphertext data encrypted by the key.

[0072] S2: The demander encrypts the smart contract data to be pre-run and executes and transmits it to the FPGA device through the network port, and the software programming controller on the processor core on the FPGA board receives it in a polling manner.

[0073] S3: The software programming controller controls the hardware programming accelerator on the FPGA according to the needs and characteristics of the smart contract, initializes the hardware programming accelerator and writes the necessary execution information (including the code data of the smart contract, the environment variables called by the smart contract, etc.), controls the hardware programming accelerator to enter the execution state, and monitors the operating status of the hardware programming accelerator through polling.

[0074] S4: The hardware programming accelerator sends different data paths according to the characteristics of the Ethereum virtual machine bytecode to accelerate the execution of smart contracts. During the execution process, the reliable on-chip memory and software and hardware collaborative interrupt mechanism are used to realize the execution of complex instructions and the encrypted call of data. After the smart contract execution is completed, it enters the waiting state.

[0075] S5: After the software programming controller finds that the smart contract has been executed, it reads the contract pre-run result of the hardware programming accelerator through DMA, and encrypts and forwards the result of the smart contract pre-run to the demander through the network port.

[0076] The data that the present invention finally returns to the remote contract pre-run service demander is the execution result status of the pre-run contract (execution success or execution failure) and the changes made by the pre-run contract to the world state (including state record modification, account balance modification, account code modification), and the world state hash value during the contract pre-run is attached. The remote contract pre-run service demander only needs to check whether the hash value is the world state confirmed by the Ethereum blockchain network consensus to ensure that the data provided by the external decentralized node used during the contract pre-run is credible data that has not been maliciously tampered with.

[0077] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0078] The above description is only the preferred embodiment of the present invention, which enables those skilled in the art to understand or implement the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various changes and variations, and the various modifications to these embodiments will be obvious to those skilled in the art. The general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention shall be included in the protection scope of the present invention.

Claims

1. A trusted contract pre-running system based on FPGA, characterized in that: include: A hardware programming accelerator on the FPGA, a software programming controller on the processor core of the FPGA, and a direct memory access unit for data transmission between the two; the hardware programming accelerator includes multiple acceleration units and storage modules, the acceleration units include stack units, arithmetic acceleration units, hash acceleration units, and the storage modules include running memory modules, world state recording modules, code modules, and environment variable modules; the Ethereum bytecode goes through the stages of instruction fetch, decoding, execution, and write-back in sequence, wherein the Ethereum bytecode is input into different data paths according to different types of instructions obtained in the decoding stage, and acts on the corresponding acceleration units and storage modules; the hardware programming accelerator is controlled by the software programming controller; The software programming controller uses the Ethernet control protocol for communication, and the Ethernet control protocol includes: type code, uniformly encoded source address or target data address, and data; the on-chip memory of the processor on the board is set as a secure memory for storing sensitive data. If the space of the on-chip memory is insufficient, part of the data is encrypted and swapped out to the unsecure memory, and then swapped in and decrypted when needed; The system sets a hardware-software collaborative interrupt mechanism. Under normal circumstances, the hardware programming accelerator works, and the software programming controller observes the status of the hardware programming accelerator in a polling manner. In the case of a control instruction interrupt, for complex semantic instructions that cannot be processed independently, the hardware programming accelerator is interrupted, and the system control is transferred to the software programming controller. The software programming controller receives the message of the Ethereum control protocol, operates the hardware programming accelerator according to the message type, and then the system control is transferred to the hardware programming accelerator, and the hardware programming accelerator enters the working state. In the case of data reading and writing interruption, when the hardware programming accelerator needs to access data that is not stored in it, the hardware programming accelerator is interrupted and the system control is transferred to the software programming controller. The software programming controller checks whether the required data is available in the on-chip memory. If not, it initiates a data query to the decentralized node and performs a Merkle tree check. The required data that passes the check is transmitted to the hardware programming accelerator through the direct memory access unit, and the hardware programming accelerator enters the working state.

2. The FPGA-based trusted contract pre-running system according to claim 1, characterized in that: The Ethereum bytecode goes through the stages of instruction fetch, decoding, execution, and writeback in sequence. The operations performed in each stage are as follows: (1) Instruction fetching stage: The hardware programming accelerator reads the Ethereum bytecode to be executed from the code module and stores it in the instruction decoding buffer; the Ethereum bytecode is a variable-length instruction set, and its length ranges from 1 byte to 33 bytes. The part exceeding 1 byte is the immediate value attached to the push-type instruction; the instruction decoding buffer uses a dual-port read and single-port write random access memory reader / writer. When reading instruction data, the address program counter and program counter + 1 are respectively passed in to read 1 byte from the program counter address of the code module, and 32 bytes of code data are read from the program counter + 1 address; (2) Decoding stage: The hardware programming accelerator decodes the extracted Ethereum bytecode. According to the different functions of the instructions, the decoded instructions are divided into six categories, including: stack operation instructions, arithmetic instructions, hash instructions, environment variable instructions, data instructions, and control instructions; The stack operation instructions only change the state of the stack and are input into the stack unit for execution during the execution phase; The arithmetic instruction takes a number of operands from the top of the stack unit, writes the result back to the top of the stack unit after the calculation, and inputs the arithmetic execution unit in the execution stage; The hash instruction takes out a number of operands from the top of the stack unit, reads continuous data from the running memory according to the address, and inputs the data into the hash acceleration unit in the execution stage; The environment variable instruction is used to query the contract execution environment variables and world status, take out the operand from the top of the stack unit according to the specific instruction, and input the environment variable module in the execution stage; The data instruction acts on the running memory module and the world state recording module, and is used to take out the operand from the top of the stack unit, and is sent to the corresponding module to perform data reading and writing operations in the execution stage; The control instructions are used to cooperate with the software and hardware collaborative interrupt mechanism; (3) Execution phase: The hardware programming accelerator sends the Ethereum bytecode to the corresponding data path according to the different instruction categories obtained by decoding. Each data path corresponds to a different acceleration unit and storage module; (4) Write-back stage: The hardware programming accelerator writes the result of instruction execution back to the top of the stack unit.

3. The FPGA-based trusted contract pre-running system according to claim 1, characterized in that: The stack unit includes registers and random access memory readers and writers, which are used to provide the necessary top stack operands for all instruction executions; the stack operation instructions in the Ethereum bytecode that only change the state of the stack are input into the stack unit for execution; the remaining instructions read the top stack data from the stack unit as operands; At most 16 operands at the top of the stack are stored in registers, and the remaining elements are stored in random access memory readers and writers; when the registers are full, the old top data is written to the random access memory readers and writers in sequence; when the registers are free, the old top data is read from the random access memory readers and writers and written to the registers; when the Ethereum bytecode accesses the 17th element at the top of the stack, it is equivalent to reading the last written data from the random access memory reader and writer; when the Ethereum bytecode pops multiple elements from the top of the stack in a single cycle, it is equivalent to reading an equal amount of data from the random access memory reader and writer and writing them to the registers in sequence.

4. The FPGA-based trusted contract pre-running system according to claim 1, characterized in that: The arithmetic acceleration unit includes an arithmetic logic unit and a multiplication and division logic unit; the multiplication and division logic unit supports 512-bit multiplication and division operations to adapt to the modulo addition instructions and modulo multiplication instructions of the Ethereum bytecode, the multiplication operation is performed by the Booth algorithm based on quaternary, and the division operation is performed by the division algorithm without borrowing.

5. The FPGA-based trusted contract pre-running system according to claim 1, characterized in that: The hash acceleration unit is used to execute hash instructions, which are Keccak-256 hash algorithms. The algorithm uses 256 bits as a single input, sends the data into a sponge structure for compression, and obtains a 256-bit output. The hash acceleration unit includes an input buffer and a hash core unit. The input buffer is used to send data 256 bits at a time, and control the running memory module according to the working status of the hash core unit. The hash core unit has configurable parameters for completing a sponge structure update operation within different numbers of clock cycles.

6. The FPGA-based trusted contract pre-running system according to claim 1, characterized in that: The complex semantic instructions that the hardware programming accelerator cannot process independently include CALL instructions. When the hardware programming accelerator executes the CALL instruction, the hardware programming accelerator is interrupted and the control of the system is transferred to the software programming controller. The software programming controller receives the Ethereum control protocol request from the hardware programming accelerator through polling. According to the semantics of the CALL instruction, the software programming controller first copies the currently executed context data from the hardware programming accelerator and stores it in the local data storage; The software programming controller writes new context data of the call contract to the hardware programming accelerator according to the semantics of the CALL instruction; the software programming controller returns the control of the system to the hardware programming accelerator and sets the hardware programming accelerator to enter a working state.

7. The FPGA-based trusted contract pre-running system according to claim 6, characterized in that: The context data includes: stack, running memory, state record, and environment variables.

8. A trusted contract pre-running method based on FPGA, implemented based on the trusted contract pre-running system based on FPGA according to any one of claims 1 to 7, characterized in that: The following steps are involved: S1: The FPGA device is started by the trusted secure boot function preset by the hardware device manufacturer, and establishes communication with the remote contract pre-run service demander. The two parties negotiate to exchange communication keys and verify whether the measurement value of the FPGA-based trusted contract pre-run system is consistent with the measurement value of the system pre-provided by the remote contract pre-run service provider. After the verification is passed, proceed to the next step; S2: The remote contract pre-run service demander encrypts the smart contract data to be pre-run and executes through the network port and transmits it to the FPGA device, which is received by the software programming controller in a polling manner; S3: The software programming controller controls the hardware programming accelerator according to the needs and characteristics of the smart contract, initializes the hardware programming accelerator and writes necessary execution information, wherein the necessary execution information includes the code data of the smart contract and the environment variables called by the smart contract; the software programming controller controls the hardware programming accelerator to enter the execution state, and monitors the running state of the hardware programming accelerator by polling; S4: The hardware programming accelerator sends different data paths to accelerate the execution of smart contracts according to the characteristics of the Ethereum virtual machine bytecode. During the execution process, the on-chip memory and the software and hardware collaborative interrupt mechanism are used to realize the execution of complex semantic instructions and the encryption call of data; after the smart contract execution is completed, it enters the waiting state; S5: The software programming controller reads the contract pre-running result of the hardware programming accelerator through the direct memory access unit, and then encrypts and forwards the result to the remote contract pre-running service demander through the network port.

9. The FPGA-based trusted contract pre-running method according to claim 8, characterized in that: The specific operation of S1 is as follows: FPGA uses the key preset by the hardware device manufacturer as the trusted root, measures the startup file of the next level step by step, and generates a signature for the startup process through the key preset by the hardware device manufacturer; the remote contract pre-run service demander challenges the hardware device manufacturer of the FPGA device, requiring it to prove the startup process and verify whether the measurement value of the trusted contract pre-run system is consistent with the measurement value of the system pre-provided by the remote contract pre-run service provider; if they are inconsistent, it is considered that the service has a security risk and the pre-run service is stopped; if they are consistent, it is considered that the remote FPGA device is executing the service claimed by the remote contract pre-run service provider, that is, the remote contract pre-run service provider has deployed a trusted public execution environment. In this process, the security of the contract pre-run service is ensured by auditing the code disclosed by the remote contract pre-run service provider; After the proof is completed, the remote contract pre-run service demander and the remote contract pre-run service provider negotiate a temporary public key for the pre-run behavior through a key exchange protocol, which is used as the symmetric encryption key for the entire execution process. Both parties communicate using ciphertext data encrypted by this key.

Images