WO2021057166A1

WO2021057166A1 - Method and apparatus for implementing external call in fpga

Info

Publication number: WO2021057166A1
Application number: PCT/CN2020/100491
Authority: WO
Inventors: 潘国振; 魏长征; 闫莺
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2019-09-25
Filing date: 2020-07-06
Publication date: 2021-04-01
Also published as: CN110750488B; CN110750488A

Abstract

One or more embodiments of the present description provide a method and apparatus for implementing an external call in an FPGA. The method may comprise: a coprocessor on an FPGA chip receives a call request sent by a central processing unit during the process of executing a smart contract, wherein the FPGA chip is an FPGA structure, and the smart contract is relevant to a transaction received by a blockchain node to which the FPGA structure belongs; and the coprocessor sends a call instruction to a target call object which can respond to the call request, so that the target call object responds to the call request, wherein a circuit logic configuration file deployed in a memory comprised in the FPGA structure is loaded into the FPGA chip, so as to form the central processing unit and the coprocessor.

Description

Method and device for realizing external call in FPGA

Technical field

One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a method and device for implementing external calls in FPGA.

Background technique

Blockchain technology is built on a transmission network (such as a peer-to-peer network). The network nodes in the transmission network use chained data structures to verify and store data, and use distributed node consensus algorithms to generate and update data.

At present, the two biggest challenges in enterprise-level blockchain platform technology are privacy and performance. It is often difficult to solve these two challenges at the same time. Most of the solutions are to lose performance in exchange for privacy, or do not consider privacy to pursue performance. Common encryption technologies that solve privacy problems, such as Homomorphic encryption and Zero-knowledge proof, are highly complex, have poor versatility, and may also cause serious performance losses.

Trusted Execution Environment (TEE) is another way to solve privacy issues. TEE can play the role of a black box in the hardware. Neither the code executed in the TEE nor the data operating system layer can be peeped, and only the pre-defined interface in the code can operate on it. In terms of efficiency, due to the black box nature of TEE, plaintext data is calculated in TEE instead of complex cryptographic operations in homomorphic encryption. There is no loss of efficiency in the calculation process. Therefore, the combination with TEE can achieve less performance loss. Under the premise, the security and privacy of the blockchain are greatly improved. At present, the industry is very concerned about the TEE solution. Almost all mainstream chip and software alliances have their own TEE solutions, including TPM (Trusted Platform Module) in software and Intel SGX (Software Guard Extensions) in hardware. , Software Protection Extension), ARM Trustzone (trust zone) and AMD PSP (Platform Security Processor, platform security processor).

Summary of the invention

In view of this, one or more embodiments of this specification provide a method and device for implementing external calls in FPGA.

To achieve the foregoing objectives, one or more embodiments of the present specification provide technical solutions as follows.

According to the first aspect of one or more embodiments of this specification, a method for implementing external calls in an FPGA is proposed, which includes: the coprocessor on the FPGA chip receives the calls issued by the central processing unit during the execution of the smart contract Request; wherein the FPGA chip belongs to the FPGA structure, the smart contract is related to the transaction received by the blockchain node to which the FPGA structure belongs; the coprocessor calls the target to the target that can respond to the call request Send a call instruction to make the target call object respond to the call request; wherein the deployed circuit logic configuration file in the memory contained in the FPGA structure is loaded to the FPGA chip to form the center The processor and the coprocessor.

According to the second aspect of one or more embodiments of the present specification, a device for implementing external calls in FPGA is proposed, including: a receiving unit, which enables the coprocessor on the FPGA chip to receive the process of executing the smart contract by the central processor Where the FPGA chip belongs to the FPGA structure, and the smart contract is related to the transaction received by the blockchain node to which the FPGA structure belongs; the sending unit enables the coprocessor to respond to The target call object of the call request sends a call instruction to make the target call object respond to the call request; wherein, the circuit logic configuration file that has been deployed in the memory contained in the FPGA structure is loaded into the FPGA chip to form the central processing unit and the coprocessor.

According to a third aspect of one or more embodiments of this specification, an electronic device is proposed, including: a processor;

A memory for storing executable instructions of a processor; wherein the processor executes the executable instructions to implement the method according to the first aspect.

According to the fourth aspect of one or more embodiments of the present specification, a computer-readable storage medium is provided, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method described in the first aspect are implemented.

Description of the drawings

Fig. 1 is a flowchart of a method for implementing external calls in FPGA provided by an exemplary embodiment.

Fig. 2 is a schematic structural diagram of a blockchain node provided by an exemplary embodiment.

Fig. 3 is a schematic diagram of forming a functional module on an FPGA chip provided by an exemplary embodiment.

Fig. 4 is a block diagram of a device for implementing external calls in FPGA provided by an exemplary embodiment.

detailed description

The exemplary embodiments will be described in detail here, and examples thereof are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings indicate the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with one or more embodiments of this specification. Rather, they are merely examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding method are not necessarily executed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. description.

Blockchain is generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain. In addition, there are many types of combinations, such as private chain + alliance chain, alliance chain + public chain and other different combinations. Among them, the most decentralized one is the public chain. The public chain is represented by Bitcoin and Ethereum. Participants who join the public chain can read the data records on the chain, participate in transactions, and compete for the accounting rights of new blocks. Moreover, each participant (ie, node) can freely join and exit the network, and perform related operations. The private chain is the opposite. The write permission of the network is controlled by an organization or institution, and the data read permission is regulated by the organization. In simple terms, the private chain can be a weakly centralized system with strict restrictions and few participating nodes. This type of blockchain is more suitable for internal use by specific institutions. Consortium chain is a block chain between public chain and private chain, which can realize "partial decentralization". Each node in the alliance chain usually has a corresponding entity or organization; participants are authorized to join the network and form a stakeholder alliance to jointly maintain the operation of the blockchain.

Regardless of whether it is a public chain, a private chain or a consortium chain, for the purpose of privacy protection, the nodes in the blockchain network may use a solution that combines the blockchain and the TEE (Trusted Execution Environment). Execute received transactions within TEE. TEE is a secure extension based on CPU hardware and a trusted execution environment that is completely isolated from the outside. TEE was first proposed by Global Platform to solve the security isolation of resources on mobile devices, and parallel to the operating system to provide a trusted and secure execution environment for applications. ARM's Trust Zone technology is the first to realize the real commercial TEE technology. With the rapid development of the Internet, security requirements are getting higher and higher. Not only mobile devices, cloud devices, and data centers have put forward more demands on TEE. The concept of TEE has also been rapidly developed and expanded. Compared with the originally proposed concept, the TEE referred to now is a more generalized TEE. For example, server chip manufacturers Intel and AMD have successively introduced hardware-assisted TEE and enriched the concepts and features of TEE, which has been widely recognized in the industry. The TEE mentioned now usually refers more to this kind of hardware-assisted TEE technology.

Taking Intel SGX technology as an example, SGX provides an enclave (also known as an enclave), which is an encrypted trusted execution area in the memory, and the CPU protects data from being stolen. Taking the first blockchain node using a CPU that supports SGX as an example, using the newly added processor instructions, a part of the area EPC (Enclave Page Cache, enclave page cache or enclave page cache) can be allocated in the memory, and through the CPU The encryption engine MEE (Memory Encryption Engine) encrypts the data in it. The encrypted content in EPC will be decrypted into plain text only after entering the CPU. Therefore, in SGX, users can distrust the operating system, VMM (Virtual Machine Monitor), and even BIOS (Basic Input Output System). They only need to trust the CPU to ensure that private data will not leakage. Therefore, the enclosure is equivalent to the TEE produced under SGX technology.

Different from the mobile terminal, cloud access requires remote access, and the end user is invisible to the hardware platform. Therefore, the first step in using TEE is to confirm the authenticity of TEE. For example, the related technology provides a remote certification mechanism for the above-mentioned SGX technology to prove that the SGX platform on the target device and the challenger have deployed the same configuration file. However, because the TEE technology in the related technology is implemented by software or a combination of software and hardware, even if the remote attestation method can indicate to a certain extent that the configuration file deployed in the TEE has not been tampered with, the TEE itself depends on the operation The environment cannot be verified. For example, on a blockchain node that needs to implement privacy functions, a virtual machine for executing smart contracts needs to be configured in the TEE. The instructions executed by the virtual machine are not directly executed, but actually executed corresponding X86 instructions (Assuming that the target device adopts the X86 architecture), which poses a certain degree of security risk.

To this end, this specification proposes a hardware TEE technology based on FPGA implementation. FPGA implements hardware TEE by loading circuit logic configuration files. Because the content of the circuit logic configuration file can be checked and verified in advance, and the FPGA is configured and operated completely based on the logic recorded in the circuit logic configuration file, it can be ensured that the hardware TEE implemented by the FPGA has relatively higher security. Among them, the circuit logic configuration file can form a central processing unit for executing the code program of the smart contract on the FPGA to satisfy the operation of the smart contract. In the process of executing code programs, the central processing unit needs to implement external calls for the purpose of improving operating efficiency or data interaction. Therefore, in this specification, the operating efficiency can be improved by configuring the coprocessor on the FPGA.

The following describes a method for implementing external calls in FPGA provided in this specification in conjunction with embodiments, so as to meet the external call requirements of the central processing unit.

Fig. 1 is a flowchart of a method for implementing external calls in FPGA provided by an exemplary embodiment. As shown in FIG. 1, the method is applied to the FPGA structure and may include the following

steps

102 and 104.

Step 102: The coprocessor on the FPGA chip receives the call request sent by the central processing unit during the execution of the smart contract; wherein, the FPGA chip belongs to the FPGA structure, and the smart contract and the blockchain to which the FPGA structure belongs The transaction received by the node is related.

By configuring the FPGA chip, a central processing unit can be formed on the FPGA chip. The central processing unit is used to implement virtual machine logic, which is equivalent to a "hardware virtual machine" configured on the FPGA chip. For example, the virtual machine logic can include Ethernet This manual does not limit the execution logic of the Fang virtual machine or the execution logic of the WASM virtual machine.

When the contract code of the smart contract is a byte-code program, the central processing unit may be a byte-code instruction set CPU. The bytecode consists of a series of bytes, and each byte can identify an operation. Based on many considerations such as development efficiency and readability, developers may not directly write bytecode programs, but choose a high-level language to write code programs for smart contracts. A code program written in a high-level language is compiled by a compiler to generate a corresponding bytecode program, and then the bytecode program can be deployed to the blockchain. There are many high-level languages supported by Ethereum, such as Solidity, Serpent, and LLL languages. The above-mentioned compiler can be deployed on the client, so that the client can use the compiler to compile a code program written in a high-level language into a bytecode program, and then submit it to the blockchain network through a transaction; or, the above-mentioned compilation The processor can be deployed at the blockchain node, so that after receiving the transaction submitted by the client, the blockchain node compiles a code program written in a high-level language into a bytecode program through a compiler.

Take the Solidity language as an example. The contract written in it is very similar to the class in the object-oriented programming language. A variety of members can be declared in a contract, including contract state (or state variable), function, and function modifier. , Events, etc. The contract state is the value permanently stored in the account storage of the smart contract and is used to save the state of the contract.

The following is a code example of a simple smart contract written in Solidity language:

For the C() function part of the above code example, the compilation result of the compiler is, for example, as shown below (/*...*/The part of... is a comment, and if there are Chinese characters after it, it is the corresponding Chinese comment):

/*compile function C()balance+=1 Compile function C()balance+=1*/

tag_2

/*pushes 1 onto stack pushes 1 onto the top of the stack, this 1 is the 1 to be assigned*/

0x1

/*pushes 0 onto the stack pushes 0 onto the top of the stack. This 0 means that the data of balance will be stored in position 0 of the contract account data storage. After the above two sentences are executed, from the top to the bottom of the stack, there are two data of 0 and 1*/

0x0

/*balance+=1 Assign balance to the value after balance+1*/

dup2/*copy the second item from the top to the bottom in the stack, so at this time the stack has 1, 0, and 1 data from the top to the top*/

swap1/*Swap the two data at the top of the stack. At this time, the stack stores 0, 1, 1 from the top to the bottom*/

/*store(0x0,0x1) stores (0x0,0x1), counts down from the top of the stack, stores the second item of data to the location identified by the first item, and simultaneously pops these two items from the stack. Here is to store data 1 to position 0. Because the balance has been bound to position 0, the assignment of balance=1 is completed. At this time, there is only one layer of data left in the stack: 1*/

sstore

pop/*discard the data on the top of the stack, at this time the stack becomes empty, waiting for the execution of the next instruction*/

It can be seen that the Solidity code in the above code example is compiled into a corresponding bytecode program, and each bytecode contained in the bytecode program includes a byte-length opcode (Opcode) and the following zero at most Operands (Operands), which are the parameters required by the corresponding operation code during execution.

In related technologies, when the above-mentioned bytecode program runs on a virtual machine on a blockchain node, for example, if the blockchain node adopts the X86 architecture, then the blockchain node will execute the bytecode program in the virtual machine. , In fact, through the X86 instruction set to simulate each bytecode contained in the bytecode program. In the technical solution of this specification, the above-mentioned bytecode instruction set CPU is configured on the FPGA chip, so that the bytecode instruction set CPU directly adopts the bytecode instruction set during the execution of the bytecode program. The bytecode instructions execute each bytecode contained in the bytecode program, without the need to simulate the execution of the bytecode program through other instruction sets, so that it has a relatively higher processing efficiency.

The above-mentioned bytecode instruction set CPU maintains a bytecode instruction set, and the bytecode instruction set can include any type of predefined bytecode instructions. For example, add instruction is used to implement addition operation, sub instruction is used to implement subtraction operation, mul instruction is used to implement multiplication operation, div instruction is used to implement division operation, or instruction is used to implement bitwise OR operation, and instruction is used to implement press Bitwise AND operation, xor instruction is used to realize bitwise XOR operation, etc. This manual does not limit this.

Of course, the central processing unit in this specification may not be a bytecode instruction set CPU. For example, the central processing unit can use other forms of instruction sets, and simulate execution of each word contained in the bytecode program through the other forms of instruction sets. The code section can also implement the execution of smart contracts.

The above transactions can be used to deploy or call smart contracts. If the transaction is used to deploy a smart contract, the data field of the transaction content will contain the code program of the smart contract; if the code program is written in a high-level language, the FPGA structure can also be formed on the FPGA chip through the deployed circuit logic configuration file A compiler, and the code program is compiled into a bytecode program through the compiler. If the transaction is used to call a smart contract, the to field of the transaction content will contain the contract address of the called smart contract, and the FPGA structure can call the corresponding deployed bytecode program based on the contract address.

Step 104: The coprocessor sends a call instruction to a target call object that can respond to the call request, so that the target call object responds to the call request; wherein, the memory contained in the FPGA structure The deployed circuit logic configuration file is loaded into the FPGA chip to form the central processing unit and the coprocessor.

The FPGA chip contains a number of editable hardware logic units. After these hardware logic units are configured via a circuit logic configuration file, they can be implemented as corresponding functional modules to implement corresponding logic functions. Specifically, the circuit logic configuration file can be burned to the FPGA structure based on the form of a bit stream. Therefore, by deploying the corresponding circuit logic configuration file to the FPGA structure, the central processing unit and the co-processor as described above can be formed on the FPGA chip.

The coprocessor is used to provide assistance to the central processing unit to complete processing tasks that the central processing unit cannot complete, or although the central processing unit can complete processing tasks that are inefficient and perform poorly, etc. The coprocessor usually exists independently of the central processing unit. The co-processor receives related requests from the central processing unit to implement assisted operations for the central processing unit. For example, if the central processing unit sends a call request for a target calling object to the coprocessor, the coprocessor can send a calling instruction to the target calling object, so that the target calling object can meet the calling requirements of the central processing unit.

The above call request may include local call, that is, the call request is a local call request, and the corresponding target call object is a local object on the FPGA structure; or, the above call request may include remote call, that is, the call request is a remote call request , The corresponding target call object is an external object connected to the FPGA structure, or the corresponding target call object includes both external objects and local objects. It can be seen that there may be a large number of target call objects. By setting the coprocessor, it can be avoided that the central processor directly docks with each target call object. The central processor only needs to dock the coprocessor, and the coprocessor calls the objects with each target. The docking can not only achieve higher docking efficiency, but also greatly save the resources consumed by the central processing unit in terms of external docking, so as to improve the execution efficiency of smart contracts.

When the target calling object includes a local object, the local object may include a preset function module formed on the FPGA chip by loading the above-mentioned circuit logic configuration file. For example, the preset function module may include at least one of the following: an encryption module, which is used to encrypt plaintext data generated by the central processing unit; a decryption module, which is used to perform encryption on ciphertext data transferred from the outside to the FPGA structure. Decryption; calculation module, used to perform calculation operations related to the smart contract; cache module, used to store the state of the contract generated by the smart contract, etc., this specification does not limit this.

For example, when the transaction initiator has a privacy protection requirement, it can submit an encrypted private transaction to the blockchain, so that the blockchain node transmits the private transaction to the FPGA structure. After the private transaction is transferred to the central processing unit, the central processing unit can initiate a local call to the co-processor to call the decryption module, then the co-processor can transmit the private transaction to the decryption module, and decrypt the decryption module to obtain the result The clear text transaction content is returned to the central processing unit. As mentioned earlier, when the private transaction is used to deploy a smart contract, the central processor can obtain the contract code of the smart contract from the data field of the received plaintext transaction content; when the private transaction is used to call the smart contract, the central processor can obtain the contract code of the smart contract. The processor can obtain the contract address of the smart contract from the to field of the received plaintext transaction content, and then obtain the corresponding contract code based on the contract address: if the contract code is deployed in the above-mentioned cache module, the central processor can pass Initiate a local call to the coprocessor, so that the coprocessor assists in retrieving the corresponding contract code from the cache module. If the contract code is deployed on a blockchain node or an external storage device connected to the FPGA chip, the target is involved The case where the calling object is an external object will be described in detail below.

In the process of running the contract code, the central processing unit may need to call the calculation module to assist in processing. For example, when the contract code is characterized as a wasm bytecode program, since the wasm bytecode specifies a data length of 32b or 64b, the processing efficiency of some large-length data is often affected. For example, when comparing data with a length of 1024b, if it is directly processed by the central processing unit, the data with a length of 1024b needs to be divided into 32 data segments with a length of 32b or 16 data segments with a length of 64b, and then each data segment is compared separately , You need to compare 32 times or 16 times; and if you use the additional configuration of the calculation module on the FPGA chip, you can not be restricted by the wasm bytecode, for example, you can set the maximum data length to 1024b or greater, then only one time The comparison operation of 1024b length data can be completed, which greatly improves the processing efficiency. Similarly, in the process of realizing operations such as multiplication of large numbers, the call to the calculation module can greatly improve the execution efficiency of the contract code.

After the central processing unit runs the contract code, the value of at least a part of the contract state involved in the contract code may change. If the contract state is maintained on the FPGA chip, such as the above-mentioned cache module, the central processing unit can initiate a local call to the coprocessor, so that the coprocessor can store the updated value of the relevant contract state in the above-mentioned cache module; if The state of the contract is maintained at the aforementioned blockchain node or external storage device, which involves the case where the target calling object is an external object, which will be described in detail below. Similarly, the central processing unit can initiate a local call to the coprocessor to process the transaction receipt generated by the execution of the contract code.

Since the inside of the FPGA chip is considered to be in the safe range, and the outside of the FPGA chip is considered to be in the non-safe range, when the FPGA structure needs to transmit the contract code, contract status, transaction receipt, etc. from the FPGA chip to the outside, for example, to the blockchain For nodes or external storage devices, the central processing unit needs to initiate a local call to the coprocessor, so that the coprocessor can transmit the above-mentioned contract code, contract status, transaction receipt, etc. to the aforementioned encryption module for encryption processing to ensure that the block The chain node or external storage device transmits the corresponding ciphertext contract code, ciphertext contract status, ciphertext transaction receipt, etc.

When the target calling object includes an external object, the external object may include: an external storage device or a blockchain node (actually a node host included in the blockchain node), and the call request initiated by the central processing unit is used to communicate with the external The storage device or blockchain node reads and writes data.

For example, after the FPGA structure receives a transaction for deploying a smart contract, it can initiate a remote call to the coprocessor for the contract code extracted from the transaction, so that the coprocessor can assist in sending the contract code to the above External storage device or blockchain node for deployment. A DMA (Direct Memory Access) connection can be established between the coprocessor and the blockchain node to realize data interaction.

As mentioned earlier, after the FPGA structure receives the transaction used to call the smart contract, if the corresponding contract code is deployed at an external object, the central processing unit can initiate a remote call to the coprocessor to make the coprocessor Assist in obtaining contract code from external objects to be executed by the central processing unit. In the process of executing the contract code, the central processing unit needs to use the value of the contract state involved, and update at least a part of the value during or after the execution of the contract code. Among them, the central processing unit can send a remote call to the coprocessor, so that the coprocessor can obtain the value of the contract state from the external object, or return the value of the updated contract state to the external object. In addition, as mentioned earlier, the contract code and contract status obtained from external objects may be in ciphertext state. The central processing unit needs to initiate a local call together so that the coprocessor can call the decryption module for decryption. Before returning the relevant data, the central processing unit needs to initiate a local call together, so that the coprocessor can call the encryption module for encryption.

Fig. 2 is a schematic structural diagram of a blockchain node provided by an exemplary embodiment. Based on the technical solution in this specification, an FPGA structure can be added to the blockchain node to implement hardware TEE. For example, the FPGA structure can be an FPGA board as shown in FIG. 2. The FPGA board can be connected to the blockchain node through the PCIE interface to realize the data interaction between the FPGA board and the blockchain node. FPGA boards can include FPGA chips, Flash (flash memory) chips, and dense tube chips; of course, in addition to FPGA chips in some embodiments, they may only include parts of the remaining Flash chips and dense tube chips. , Or may contain more structures, here are just examples.

In the initial stage, no user-defined logic is programmed on the FPGA chip, which is equivalent to the FPGA chip in a blank state. Users can burn circuit logic configuration files on the FPGA chip to form corresponding functions or logic on the FPGA chip. When programming the circuit logic configuration file for the first time, the FPGA board does not have the capability of security protection, so it usually needs to provide an external security environment. For example, users can implement the programming of the circuit logic configuration file in an offline environment to achieve physical security isolation. Instead of implementing remote programming online.

For the function or logic that the user needs to implement, the corresponding logic code can be formed through FPGA hardware language, and then the logic code can be mirrored to obtain the above-mentioned circuit logic configuration file. Before programming to the FPGA board, the user can check the above-mentioned logic code. Especially, when multiple users are involved at the same time, multiple users can check the above logic code separately to ensure that the FPGA board can finally meet the needs of all users and prevent security risks, logic errors, fraud and other abnormalities. problem.

After confirming that the code is correct, the user can burn the circuit logic configuration file to the FPGA board in the above-mentioned offline environment. Specifically, the circuit logic configuration file is transferred from the blockchain node to the FPGA board, and then deployed to the Flash chip as shown in Figure 2, so that even if the FPGA board is powered off, the Flash chip can still save the above-mentioned circuit logic. Configuration file.

Fig. 3 is a schematic diagram of forming a functional module on an FPGA chip provided by an exemplary embodiment. By loading the circuit logic configuration file deployed in the Flash chip to the FPGA chip, the hardware logic unit contained in the FPGA chip can be configured to form corresponding functional modules on the FPGA chip. For example, the formed functional modules can include such The central processing unit, co-processor, cache module, encryption and decryption module, calculation module, key agreement module, decryption verification module, etc. shown in FIG. 3. At the same time, the circuit logic configuration file can also be used to transmit the information that needs to be stored to the FPGA board. For example, the preset certificate can be stored on the FPGA chip, and the authentication root key can be stored in the secret tube chip (the authentication root key can also be Stored on the FPGA chip) and so on.

Based on the key agreement module formed on the FPGA chip and the authentication root key deployed on the FPGA board, the FPGA board can realize remote key agreement with the user. The key agreement process can use related technologies. Any algorithm or standard can be implemented, and this specification does not limit it. For example, the key agreement process can include: the user can generate a key Ka-1 at the local client, the key agreement module can generate a key Kb-1 locally, and the client can generate a key Kb-1 based on the key Ka- 1 Calculate the key agreement information Ka-2, the key agreement module can calculate the key agreement information Kb-2 based on the key Kb-1, and then the client sends the key agreement information Ka-2 to the key agreement module, The key agreement module sends the key agreement information Kb-2 to the client, so that the client can generate a secret value based on the key Ka-1 and the key agreement information Kb-2, and the key agreement module can be based on the key Kb -1 generates the same secret value as the key agreement information Ka-2, and finally the client and the key agreement module respectively derive the same configuration file deployment key from the same secret value based on the key derivation function, and the configuration file deployment The key can be stored in the FPGA chip or the secret management chip. In the above process, although the key agreement information Ka-2 and key agreement information Kb-2 are transmitted between the client and the key agreement module via the blockchain node, the key Ka-1 is controlled by the client , The key Kb-1 is controlled by the key agreement module, so it can ensure that the blockchain node cannot know the final secret value and the configuration file deployment key, so as to avoid possible security risks.

In addition to the configuration file deployment key, the secret value is also used to derive the business secret deployment key; for example, the secret value can be derived as a 32-bit value, the first 16 bits can be used as the configuration file deployment key, and the last 16 bits can be used as the business secret deployment Key. The user can deploy the service key to the FPGA board through the service secret deployment key. For example, the service key may include the node private key and the service root key. For example, the user can use the business secret deployment key on the client to sign, encrypt the node private key or the business root key, and send it to the FPGA board, so that after the FPGA board is decrypted and verified through the decryption verification module, Deploy the obtained node private key or service root key.

Based on the deployed node key, business root key and encryption and decryption modules, central processing unit, coprocessor, computing module, etc. on the FPGA chip, the FPGA board can be implemented as a TEE on the blockchain node to meet privacy demand. For example, when a blockchain node receives a transaction, if the transaction is a plaintext transaction, the blockchain node can directly process the plaintext transaction, if the transaction is a private transaction, the blockchain node transmits the private transaction to the FPGA The board is processed.

The transaction content of a plaintext transaction is in plaintext form, and the contract status generated after the transaction is executed is also stored in plaintext form. The transaction content of a private transaction is in ciphertext form, which is obtained by encrypting the plaintext transaction content by the transaction initiator, and the contract status generated after transaction execution needs to be stored in ciphertext form to ensure the protection of transaction privacy. For example, the transaction initiator can generate a symmetric key randomly or based on other methods. Similarly, the business public key corresponding to the above-mentioned business private key is disclosed, then the transaction initiator can perform transaction content in plaintext based on the symmetric key and the business public key. Digital Envelope Encryption: The transaction initiator encrypts the plaintext transaction content with a symmetric key, and encrypts the symmetric key with the business public key. The two parts obtained are included in the above-mentioned private transaction; in other words, the private transaction includes Two parts of content: the content of the transaction in plaintext encrypted with a symmetric key, and the symmetric key encrypted with the business public key.

Therefore, after the FPGA board receives the private transaction from the blockchain node, the private transaction can be handed over to the central processing unit for processing. The central processor initiates a local call call request to the coprocessor, and the coprocessor further calls the encryption and decryption module, so that the encryption and decryption module uses the service private key to decrypt the symmetric key encrypted with the service public key to obtain the symmetric key , And then the encryption and decryption module further uses the symmetric key to decrypt the plaintext transaction content encrypted with the symmetric key to obtain the plaintext transaction content.

If a private transaction is used to deploy a smart contract, the data field of the plaintext transaction content can contain the contract code of the smart contract to be deployed. The central processing unit can deploy the obtained contract code. If it is deployed on the cache module on the FPGA chip, the central processing unit directly deploys the contract code to the cache module in plain text; if it is deployed on a blockchain node (or other external object, here is a blockchain node as an example), then The central processor initiates a local call call request to the coprocessor, and the coprocessor calls the encryption and decryption module to encrypt the contract code, and then deploys the encrypted ciphertext contract code to the blockchain node.

If a private transaction is used to call a smart contract, the to field of the plaintext transaction content can contain the contract address of the called smart contract, and the FPGA board can retrieve the corresponding contract code based on the contract address. If the contract code is deployed in the cache module of the FPGA chip, the contract code is often stored in plain text, and the coprocessor can directly obtain the contract code from the cache module and hand it over to the central processing unit for processing. If the contract code is deployed on a blockchain node, and the coprocessor obtains the ciphertext contract code from the blockchain node, the central processing unit needs to further initiate a local call request to the coprocessor, and the coprocessor will call the encryption and decryption module The ciphertext contract code is decrypted, and the central processing unit executes the decrypted contract code.

The central processing unit is used to implement virtual machine logic in related technologies, that is, the central processing unit is equivalent to the "hardware virtual machine" on the FPGA board. Therefore, after the contract code is determined based on the foregoing plaintext transaction content, the contract code can be transferred to the central processing unit, so that the central processing unit executes the contract code. The central processing unit can be the bytecode instruction set CPU in this manual. For the smart contract that needs to be deployed or called for the transaction received by the blockchain node, the FPGA board can read the bytecode program of the smart contract into words The code instruction set CPU enables the bytecode instruction set CPU to directly execute each bytecode contained in the bytecode program, without the need to simulate the bytecode through other instruction sets, which greatly improves the performance of the bytecode. Execution efficiency, thereby speeding up transaction processing.

Before or during the execution of the contract code by the central processing unit, the most recent value of the contract state involved in the contract code needs to be obtained. The latest value of the contract state may be deployed in the cache module on the FPGA chip in clear text, then the central processing unit can initiate a local call request to the coprocessor, and the coprocessor can retrieve the latest value of the contract state from the cache module. Value. The latest value of the contract state may be deployed in the form of cipher text at the blockchain node (or other external object), then the central processing unit can initiate a remote call call request to the coprocessor, and the coprocessor can send it from the blockchain. The node remotely calls the latest value of the contract state in the form of ciphertext, and the central processor can initiate a local call call request to the coprocessor, and the coprocessor can call the encryption and decryption module to get the latest value of the contract state in the form of ciphertext. The value is decrypted, and the central processing unit obtains the latest value of the decrypted contract state.

After the execution is completed, the state of the contract involved in the contract code may be updated. If the update value of the contract state needs to be deployed in the cache module on the FPGA chip, the central processing unit can initiate a local call request to the coprocessor, and the coprocessor directly saves the update value of the contract state into the cache module . If the updated value of the contract state needs to be deployed at the blockchain node, the central processing unit can initiate a local call call request to the coprocessor, and the coprocessor can call the encryption and decryption module to encrypt the updated value of the contract state , And the central processor initiates a remote call call request to the coprocessor, and the coprocessor remotely stores the updated value of the contract state in the form of ciphertext to the blockchain node.

For some reasons, the user may want to update the version of the circuit logic configuration file deployed on the FPGA board. For example, the authentication root key contained in the circuit logic configuration file may be known by risky users, or the user wants to update the version on the FPGA board. The deployed functional modules are upgraded, etc. This manual does not limit this. In order to facilitate the distinction, the circuit logic configuration file that has been deployed in the above process can be referred to as the old version of the circuit logic configuration file, and the circuit logic configuration file that needs to be deployed is referred to as the new version of the circuit logic configuration file.

Similar to the old version of the circuit logic configuration file, the user can generate a new version of the circuit logic configuration file through the process of writing code and mirroring. Further, the user can sign the new version of the circuit logic configuration file with his own private key, and then encrypt the signed new version of the circuit logic configuration file with the configuration file deployment key negotiated above to obtain the encrypted new version of the circuit Logical configuration file. In some cases, there may be multiple users at the same time, so the old version of the circuit logic configuration file needs to deploy the preset certificates corresponding to these users to the FPGA board, and these users need to use their own private keys to pair the new version of the circuit. Sign the logical configuration file.

The user can remotely send the encrypted new version of the circuit logic configuration file to the blockchain node through the client, and the blockchain node will further transfer it to the FPGA board. The decryption verification module formed on the FPGA chip in the foregoing process is located on the transmission path between the PCIE interface and the Flash chip, so that the encrypted new version of the circuit logic configuration file must first be successfully processed by the decryption verification module before it can be The Flash chip is passed in to achieve a credible update, and the Flash chip cannot be updated directly without bypassing the process of decryption and verification.

After the decryption verification module receives the encrypted new version of the circuit logic configuration file, it first decrypts it with the configuration file deployment key deployed on the FPGA board. If the decryption is successful, the decryption verification module is further based on the preset certificate deployed on the FPGA chip , To perform signature verification on the decrypted new version of the circuit logic configuration file. If the decryption fails or the signature verification fails, it means that the received file is not from the above-mentioned user or has been tampered with, and the decryption and signature verification module will trigger the termination of the update operation; and if the decryption is successful and the signature verification is passed, you can It is determined that the obtained new version of the circuit logic configuration file is from the aforementioned user and has not been tampered with during the transmission process. The new version of the circuit logic configuration file can be further transmitted to the Flash chip to update and deploy the old version of the circuit logic configuration file in the Flash chip.

After the new version of the circuit logic configuration file is loaded into the FPGA chip, the above-mentioned key agreement module, decryption and verification module can also be formed on the FPGA chip, and the pre-set certificate and authentication can be stored in the FPGA chip. Root key and other information. Among them, the formed key agreement module, decryption verification module, etc., the implemented functional logic can be changed and upgraded, and the information stored in the deployed preset certificate, authentication root key and other information may also be different from the information before the update . Then, the FPGA board can remotely negotiate with the user to obtain a new configuration file deployment key based on the updated key agreement module, authentication root key, etc., and the configuration file deployment key can be used for the next renewal Update process. Similarly, a reliable update operation for FPGA boards can be continuously implemented accordingly.

After completing the update deployment, the FPGA board can generate certification results for the new version of the circuit logic configuration file. For example, the above-mentioned key agreement module can calculate the hash value of the new version of the circuit logic configuration file and the hash value of the configuration file deployment key negotiated based on the new version of the circuit logic configuration file through an algorithm such as sm3 or other algorithms. The calculation result can be used as the above-mentioned authentication result, and the key agreement module sends the authentication result to the user. Correspondingly, the user can verify the authentication result on the client based on the maintained new version of the circuit logic configuration file and the configuration file deployment key negotiated accordingly. If the verification is successful, it indicates that the new version of the circuit logic configuration file is successful on the FPGA board. Deployed, and the user and the FPGA board successfully negotiated accordingly to obtain a consistent configuration file deployment key, thereby confirming the successful completion of the circuit logic configuration file update deployment.

Fig. 4 is a schematic structural diagram of a device for implementing external calls in an FPGA provided by an exemplary embodiment. Referring to FIG. 4, in the software implementation, the device for implementing external calls in FPGA may include a receiving unit 401 and a sending unit 402.

The receiving unit 401 enables the coprocessor on the FPGA chip to receive the call request sent by the central processing unit during the execution of the smart contract; wherein the FPGA chip belongs to the FPGA structure, and the smart contract and the area to which the FPGA structure belongs The transaction received by the blockchain node is related.

The sending unit 402 is configured to cause the coprocessor to send a call instruction to a target call object that can respond to the call request, so that the target call object responds to the call request; wherein, the FPGA structure contains The circuit logic configuration file deployed in the memory is loaded to the FPGA chip to form the central processing unit and the coprocessor.

Optionally, when the invocation request is a local invocation request, the target invocation object is a local object on the FPGA structure; or, when the invocation request is a remote invocation request, the target invocation object is and The external object connected to the FPGA structure, or the target calling object is the external object and the local object.

Optionally, the local object includes: a preset function module formed on the FPGA chip by loading the circuit logic configuration file.

Optionally, the preset function module includes at least one of the following: an encryption module, which is used to encrypt plaintext data generated by the central processing unit; and a decryption module, which is used to encrypt the ciphertext transferred from the outside of the FPGA structure The data is decrypted; the calculation module is used to execute the calculation operations involved in the smart contract; the cache module is used to store the contract state generated by the smart contract.

Optionally, the external object includes: an external storage device or a node host included in the blockchain node.

Optionally, the call request is used to read and write data with the external storage device or the node host.

Optionally, the transaction is used to deploy or invoke the smart contract.

Optionally, the contract code of the smart contract is a bytecode program, and the central processing unit is a bytecode instruction set CPU.

Optionally, the central processing unit is used to implement virtual machine logic.

Optionally, the virtual machine logic includes: the execution logic of the Ethereum virtual machine or the execution logic of the WASM virtual machine.

The systems, devices, modules, or units explained in the above embodiments may be implemented by computer chips or entities, or implemented by products with certain functions. A typical implementation device is a computer. The specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game control A console, a tablet computer, a wearable device, or a combination of any of these devices.

In a typical configuration, the computer includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.

The memory may include non-permanent memory in a computer readable medium, random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer readable media.

Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

It should also be noted that the terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or equipment including a series of elements not only includes those elements, but also includes Other elements that are not explicitly listed, or they also include elements inherent to such processes, methods, commodities, or equipment. If there are no more restrictions, the element defined by the sentence "including a..." does not exclude the existence of other identical elements in the process, method, commodity, or equipment that includes the element.

The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than in the embodiments and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown in order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms of "a", "said" and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and/or" as used herein refers to and includes any or all possible combinations of one or more associated listed items.

It should be understood that, although the terms first, second, third, etc. may be used to describe various information in one or more embodiments of this specification, the information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information. Depending on the context, the word "if" as used herein can be interpreted as "when" or "when" or "in response to determination".

The foregoing descriptions are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. All within the spirit and principle of one or more embodiments of this specification, Any modification, equivalent replacement, improvement, etc. made should be included in the protection scope of one or more embodiments of this specification.

Claims

A method for implementing external calls in FPGA, including:

The coprocessor on the FPGA chip receives the call request issued by the central processing unit during the execution of the smart contract; wherein the FPGA chip belongs to the FPGA structure, and the smart contract and the blockchain node to which the FPGA structure belongs receive the call request Transaction related;

The coprocessor sends a call instruction to a target call object that can respond to the call request, so that the target call object responds to the call request; wherein, the deployed memory in the FPGA structure The circuit logic configuration file is loaded into the FPGA chip to form the central processing unit and the coprocessor.
According to the method of claim 1,

When the call request is a local call request, the target call object is a local object on the FPGA structure; or,

When the call request is a remote call request, the target call object is an external object connected to the FPGA structure, or the target call object is the external object and the local object.
The method according to claim 2, wherein the local object comprises: a preset function module formed on the FPGA chip by loading the circuit logic configuration file.
The method according to claim 3, the preset function module comprises at least one of the following:

An encryption module for encrypting the plaintext data generated by the central processing unit;

The decryption module is used to decrypt the ciphertext data transferred from the outside of the FPGA structure;

A calculation module, used to execute the calculation operations involved in the smart contract;

The cache module is used to store the state of the contract generated by the smart contract.
The method according to claim 2, wherein the external object comprises: an external storage device or a node host included in the blockchain node.
The method according to claim 5, wherein the call request is used to read and write data with the external storage device or the node host.
According to the method of claim 1, the transaction is used to deploy or invoke the smart contract.
The method according to claim 1, wherein the contract code of the smart contract is a bytecode program, and the central processing unit is a bytecode instruction set CPU.
According to the method of claim 1, the central processing unit is used to implement virtual machine logic.
The method according to claim 9, wherein the virtual machine logic comprises: the execution logic of the Ethereum virtual machine or the execution logic of the WASM virtual machine.
A device for implementing external calls in FPGA, including:

The receiving unit enables the coprocessor on the FPGA chip to receive the call request sent by the central processing unit during the execution of the smart contract; wherein the FPGA chip belongs to the FPGA structure, and the smart contract and the block to which the FPGA structure belongs Related to the transaction received by the chain node;

The sending unit causes the coprocessor to send a call instruction to a target call object that can respond to the call request, so that the target call object responds to the call request; wherein the memory contained in the FPGA structure The circuit logic configuration files deployed in the FPGA chip are loaded into the FPGA chip to form the central processing unit and the coprocessor.
An electronic device including:

processor;

A memory for storing processor executable instructions;

Wherein, the processor implements the method according to any one of claims 1-10 by running the executable instruction.
A computer-readable storage medium having computer instructions stored thereon, and when the instructions are executed by a processor, the method according to any one of claims 1-10 is implemented.