CN110738567A

CN110738567A - Transaction processing method and device of safe intelligent contract processor based on FPGA

Info

Publication number: CN110738567A
Application number: CN201910913482.2A
Authority: CN
Inventors: 潘国振; 魏长征; 闫莺; 郭学鹏
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2019-09-25
Filing date: 2019-09-25
Publication date: 2020-01-31
Anticipated expiration: 2039-09-25
Also published as: CN110738567B; WO2021057167A1

Abstract

The or more embodiments of the present specification provide transaction processing methods and apparatuses for an FPGA-based secure intelligent contract processor, where the method may include loading, by an FPGA structure, a circuit logic configuration file already deployed in a memory onto an FPGA chip to form, on the FPGA chip, a register-type on-chip processor for implementing virtual machine logic, acquiring, by the FPGA structure, a register-type code program of an intelligent contract related to a transaction according to the transaction received by a block chain node to which the FPGA structure belongs, and transferring, by the FPGA structure, the register-type code program to the register-type on-chip processor, so that the register-type on-chip processor executes the register-type code program.

Description

Transaction processing method and device of safe intelligent contract processor based on FPGA

Technical Field

One or more embodiments of the specification relate to the field of blockchain technology, and in particular, to a transaction processing method and apparatus for secure intelligent contract processors based on an FPGA.

Background

The blockchain technique is built on top of a transport network, such as a point-to-point network. Network nodes in a transport network utilize a chained data structure to validate and store data and employ a distributed node consensus algorithm to generate and update data.

The two biggest challenges in the current enterprise-level blockchain platform technology are privacy and performance, which are often difficult to solve simultaneously. Most solutions trade privacy for loss of performance or do not consider privacy much to pursue performance. Common encryption technologies for solving privacy problems, such as Homomorphic encryption (Homomorphic encryption) and Zero-knowledge proof (Zero-knowledge proof), have high complexity and poor universality, and may cause serious performance loss.

The TEE can play a role of a black box in hardware, and both a code and a data operating system layer executed in the TEE cannot be peeped, and only a predefined interface in the code can operate the TEE.

Disclosure of Invention

Accordingly, one or more embodiments of the present disclosure provide a method and an apparatus for processing a transaction of secure intelligent contract processors based on an FPGA.

To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions:

according to a aspect of one or more embodiments of the present specification , there is provided a method for processing transactions by an FPGA-based secure intelligent contract processor, comprising:

the FPGA structure loads a deployed circuit logic configuration file in a memory onto an FPGA chip so as to form a register type on-chip processor for realizing the logic of a virtual machine on the FPGA chip;

the FPGA structure acquires a register type code program of an intelligent contract related to the transaction according to the transaction received by the block chain node to which the FPGA structure belongs;

and the FPGA structure transmits the register code program to the register on-chip processor, so that the register on-chip processor executes the register code program.

According to a second aspect of one or more embodiments of this specification , there is provided FPGA-based secure intelligent contract processor transaction processing apparatus, comprising:

the loading unit is used for loading the deployed circuit logic configuration file in the memory onto the FPGA chip by the FPGA structure so as to form a register type on-chip processor for realizing the logic of the virtual machine on the FPGA chip;

the acquisition unit is used for enabling the FPGA structure to acquire a register type code program of the intelligent contract related to the transaction according to the transaction received by the block chain node to which the FPGA structure belongs;

and the execution unit enables the FPGA structure to transmit the register code program to the register on-chip processor and enables the register on-chip processor to execute the register code program.

According to a third aspect of one or more embodiments of this specification , there is provided electronic devices, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of aspect by executing the executable instructions.

According to a fourth aspect of one or more embodiments of this specification , there is provided computer readable storage media having stored thereon computer instructions which, when executed by a processor, perform the steps of the method of aspect .

Drawings

FIG. 1 is a flowchart of a transaction processing method of the FPGA-based secure intelligent contract processors provided by the exemplary embodiment of .

Fig. 2 is a schematic structural diagram of the blockchain nodes provided in the exemplary embodiment.

FIG. 3 is a schematic diagram of an example embodiment of providing types of functional blocks formed on an FPGA chip.

FIG. 4 is a block diagram of a transaction processing arrangement of the FPGA-based secure intelligent contract processors provided by the exemplary embodiment of .

Detailed Description

The embodiments described in the exemplary embodiments below are not intended to represent all embodiments from the one or more embodiments of this specification , but rather are merely examples of apparatus and methods from the aspects of the one or more embodiments , as detailed in the appended claims.

It should be noted that in other embodiments, the order in which the steps of the corresponding method are performed is not , and in other embodiments, may include more or less steps than those described.

The blockchains are generally divided into three types, Public chains (Public chains), private chains (privateblockchains) and federation chains (Consortium blockchains). furthermore, there are various types of associations, such as private chains + federation chains, federation chains + Public chains, and various combinations, where decentralized is the most common Public chain.

For privacy protection purposes, nodes in a blockchain network may execute received transactions within a TEE (Trusted Execution Environment) through a solution in which the blockchain is combined with the TEE, whether public, private, or alliance, the TEE is a Trusted Execution Environment based on secure extensions of CPU hardware and completely isolated from the outside.

Taking the Intel SGX technology as an example, the SGX provides an enclosure (also called Enclave), that is, encrypted trusted execution regions in the memory, and the CPU protects data from being stolen, taking the th block link point as an example, the CPU supporting the SGX is used, partial regions EPC (enclosure Page Cache, or Enclave Page Cache) can be allocated in the memory by using an added processor instruction, and data therein is encrypted by an Encryption engine mee (memory Encryption engine) in the CPU.

For example, because the TEE technology in the related art is realized in a software or hardware-software combined mode, even though the remote certification mode can show that the configuration file deployed in the TEE is not tampered at fixed level, the operating environment depending on the TEE cannot be verified, for example, a virtual machine for executing an intelligent contract needs to be configured in the TEE, and the instruction executed by the virtual machine is not directly executed but actually executes a plurality of corresponding X86 instructions (assuming that the target device adopts an X39 86 architecture), so that the security risk of a certain degree is caused.

The hardware TEE realized by the FPGA can be ensured to have relatively higher security because the content of the circuit logic configuration file can be checked and checked in advance and the FPGA is configured and operated completely based on the logic recorded in the circuit logic configuration file.

The following describes, with reference to embodiments, methods for implementing virtual machine operation based on an FPGA, which are provided in this specification, so as to take security and operation efficiency into consideration.

FIG. 1 is a flow chart of a transaction processing method of FPGA-based secure intelligent contract processors provided by an exemplary embodiment of , as shown in FIG. 1, the method applied to an FPGA structure may include the following steps:

step 102, the FPGA structure loads a deployed circuit logic configuration file in a memory onto an FPGA chip to form a register type on-chip processor for realizing virtual machine logic on the FPGA chip.

The FPGA chip comprises a plurality of editable hardware logic units, and the hardware logic units can be realized as corresponding functional modules after being configured by a circuit logic configuration file so as to realize corresponding logic functions. Specifically, the circuit logic configuration file may be burned into the FPGA fabric based on the form of the bit stream.

Therefore, by deploying a corresponding circuit logic configuration file to the FPGA structure, a register-type on-chip processor may be formed on the FPGA chip, and the register-type on-chip processor may be used to implement a virtual machine logic in the related art, which corresponds to a "hardware virtual machine" configured and formed on the FPGA chip, for example, the virtual machine logic may include an execution logic of an ethernet virtual machine or an execution logic of a WASM virtual machine, and the description does not limit this.

And 104, acquiring a register type code program of the intelligent contract related to the transaction by the FPGA structure according to the transaction received by the block chain node.

The method includes that Byte codes (Byte-codes) are composed of concatenated bytes, each Byte can identify operations, based on multiple considerations such as development efficiency and readability, developers can select high-level languages to write code programs of intelligent contracts instead of writing Byte code programs directly, the code programs written by the high-level languages are compiled by a compiler and can generate corresponding Byte code programs, and the Byte code programs can be deployed to a block chain.

Taking the Solidity language as an example, the contract written by it is very similar to a Class (Class) in the object-oriented programming language, and various members can be declared in contracts, including contract states (or state variables), functions, function modifiers, events, etc.

The following code example is a simple intelligent contract written in the Solidity language:

for the C () function part in the code example, the compilation result of the compiler is, for example, as follows (/ × …/part … in the note, followed by a corresponding chinese note if chinese characters):

/component function C () balance + ═ 1 compilation function C () balance + ═ 1 ═ greater/greater

tag_2

/pushes 1onto stack pushes 1 to the top of the stack, which 1 is the 1/will be assigned

0x1

/' pushies 0onto stack pushes 0 to the top of the stack, this 0 refers to balance which data is to be stored to position 0 of the contract account data store. After the two sentences are executed, two data items 0 and 1 are located from the top to the bottom in the stack

0x0

V balance +1 assigns balance to a value after balance +1 +

dup 2/. copy the second term from the top down in the stack, so this time the stack has three data items 1, 0, 1 from the top up >

swap 1/swap two items of data at the top of the stack, when the stack stores 0, 1 ×/greater/less

Store (0x0,0x1), count from the top of the stack, store the second item of data to the position identified by item , and pop the two items out of the stack, here store data 1 to position 0, since balance has already been bound to position 0, the assignment of balance 1 is completed, at this time, only layers of data: 1 +erremains in the stack

sstore

pop/discard Top of Stack data, when the stack becomes empty, awaits execution of the next instructions +

It can be seen that the identity code in the above code example is compiled into a corresponding bytecode program, which contains, per bytecode, a -byte-length operation code (Opcode) followed by zero to multiple Operands (Operands), which are parameters required by the corresponding Opcode when executing.

Therefore, the code programs obtained by the block link point in the related art are usually byte code programs, for example, after a user writes a high level language program by using a high level language, the high level language program can be compiled into a byte code program at a client.

As mentioned above, the compiler can compile the high-level language program into the byte code program, and further compile the byte code program into the register code program , the byte code program is based on the stack, and the stack architecture is characterized by no ambiguity, so that by compiling the high-level language program into the byte code program first, the code behavior represented by the code program can be solidified, so that the register code program compiled in step is completely based on the solidified code behavior, and does not change the code behavior, thereby ensuring that the logic executed by all the blockchain nodes is complete .

And 106, the FPGA structure transmits the register code program to the register on-chip processor, so that the register on-chip processor executes the register code program.

In the related art, the bytecode program compiled by the high-level language program is in a stack type, and operands involved in the bytecode program are written into an operand stack during the execution process, so the process of executing the bytecode program is relatively cumbersome. Taking the addition operation as an example, assume that "c ═ a + b" needs to be performed; if a stacked on-chip processor is formed on an FPGA structure, the process of "c ═ a + b" performed by the stacked on-chip processor may include the steps of:

POP a (indicating that a is popped from the operand stack)

POP b (indicating that b is popped from the operand stack)

ADD (meaning that the operation of a + b is performed and the result is assigned to c)

PUSH c (indicating pushing c to the Top of the operand stack)

It can be seen that, in the stack architecture, at least the above-mentioned 4 steps need to be executed to complete the operation "c ═ a + b", and in the present specification, by using the register on-chip processor, when executing the compiled register code program, the operation "c ═ a + b" needs only 2 steps, that is, ① executes a + b operation (the register storing a and b needs to be specified), ② stores the value obtained by the operation in a register as the value of c.

As described above, operands involved in the register code program are written into registers on the FPGA chip, but not into the operand stack, so that when the register on-chip processor executes operations according to corresponding operation codes, the operands stored in the registers can be directly processed according to information (such as names) of the registers.

The FPGA structure can obtain the transaction in an encrypted state from the link point of the block and transmit the transaction to an encryption and decryption module on the FPGA chip. The encryption and decryption module is formed on an FPGA chip by the deployed circuit logic configuration file, and the forming process is similar to that of the register type on-chip processor. And then, the FPGA structure acquires the byte code program according to the decrypted transaction content output by the encryption and decryption module.

If the transaction is used to deploy an intelligent contract, the data field of the decrypted transaction content will contain the registered code program for the intelligent contract. If the transaction is used for calling the intelligent contract, the to field of the decrypted transaction content contains the contract address of the called intelligent contract, and the FPGA structure can call a corresponding deployed register code program based on the contract address; for example, when intelligent contracts are deployed at block chain nodes, the FPGA fabric may send the contract addresses described above to the block chain nodes, which return register-based code programs corresponding to the contract addresses to the FPGA fabric.

The FPGA structure can be deployed with a node private key, and a node public key corresponding to the node private key is in a public state. The transaction can be generated by the transaction initiator by encrypting in a digital envelope manner based on a symmetric key and a node public key maintained by the transaction initiator (such as randomly generated for each transaction): the transaction initiator encrypts the plaintext transaction content through the symmetric key to obtain ciphertext transaction content, and encrypts the symmetric key through the node public key to obtain a ciphertext symmetric key, wherein the transaction comprises the ciphertext transaction content and the ciphertext symmetric key. Correspondingly, the FPGA structure can form a decryption module on the FPGA chip through the deployed circuit logic configuration file, and the transaction is decrypted through the decryption module. The decryption module decrypts the symmetric cipher key based on the node private key to obtain the symmetric cipher key, and then decrypts the encrypted transaction content based on the symmetric cipher key to obtain the plaintext transaction content, namely the decrypted transaction.

After the register type on-chip processor executes the register type code program, the corresponding contract state, transaction receipt and other contents can be generated. The transaction receipt may include information such as the result of the transaction execution, which needs to be fed back to the transaction initiator. Under the condition that the transaction is encrypted in a digital envelope mode, the FPGA structure can transmit a transaction receipt generated by the register type on-chip processor into the encryption module to be encrypted by a symmetric key based on the digital envelope, and then the encrypted transaction receipt is returned to a block chain node to be provided to a transaction initiator; the encryption module is formed by loading a deployed circuit logic configuration file by an FPGA chip. Since the symmetric key employed by the digital envelope is held only by the transaction initiator, using the symmetric key to generate an encrypted transaction receipt can ensure that the encrypted transaction receipt can only be decrypted by the transaction initiator to ensure the security and privacy protection of the transaction receipt.

As previously described, the code program may be deployed at block chain nodes, and the FPGA fabric may request the code program from the block chain nodes for execution in a registered on-chip processor formed on the FPGA chip. The block chain nodes belong to an external storage space outside the FPGA chip, and the external storage space can also have other forms, for example, the FPGA structure can comprise an external DDR memory connected with the FPGA chip, and the like, and can also be used for deploying the code program, and at the moment, the interaction times between the FPGA structure and the block chain node points can be reduced. In addition to the external memory space described above, the code program may also be deployed in the on-chip memory space of the FPGA chip.

For the FPGA architecture, only the FPGA chip is considered as belonging to a secure environment (TEE formed based on the FPGA architecture), and the environment outside the FPGA chip is considered as insecure, so the register code program can be deployed in a plaintext form in the above on-chip storage space, but must be deployed in a ciphertext form in the above external storage space. Therefore, when the FPGA architecture obtains the encrypted register code program from, for example, an external memory space, the encrypted register code program can be transmitted to the decryption module on the FPGA chip, and the decrypted register code program output by the decryption module can be obtained for execution in the register on-chip processor.

The encrypted register code program can be obtained by encrypting the register code program by a service root key maintained by the FPGA structure or a derivative key of the service root key. For example, after the FPGA fabric obtains a transaction for deploying the smart contract, the plain-text register-based code program may be obtained from the transaction. Then, the FPGA structure may encrypt the register code program through an encryption module to obtain the encrypted register code program, where the adopted key is the service root key or a derivative key of the service root key.

The node private key and the service root key described above may be deployed to the FPGA fabric by a user. The user can complete the deployment locally or realize the remote deployment through the client. In the remote deployment process, the client can negotiate with the FPGA structure in advance to obtain a service secret deployment key, the node private key or the service root key is encrypted through the service secret deployment key and is sent to the FPGA structure, and the FPGA structure can decrypt received data through the service secret deployment key to obtain the node private key or the service root key.

For example, the key agreement process may include that a user may generate a key Ka-1 at a local client, the key agreement module may locally generate a key Kb-1, the client may obtain key agreement information Ka-2 by calculation based on the key Ka-1, the key agreement module may obtain key agreement information Kb-2 by calculation based on the key Ka-1, the key agreement module may then obtain key agreement information Kb-2 by calculation based on the key Kb-1, the client may then send 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 may generate a secret value based on the key Ka-1 and the key agreement information Kb-2, and the client may obtain a secret value of a key that is derived from the key agreement information Kb-2 based on the key Ka-1 and the key agreement information Kb-2, the secret value of the key agreement module may be derived from the key agreement information Kb-2 by the client, and the secret key agreement module may not obtain a secret value derived from the key agreement information Kb-2, and the secret key agreement information k-2, the secret key may be derived from the secret key agreement module, and a secret key may be derived from the client, the secret key agreement module, the secret key may be derived from the same key, the secret key agreement module, and a secret key, the secret key may be derived from the secret key, and a secret key, the secret key may be obtained by a secret key, and may.

The FPGA structure can be deployed with an authentication root key, the authentication root key can be preset in the FPGA structure, or the authentication root key can be deployed into the FPGA structure by a client or other objects under an offline security environment, or the authentication root key can be remotely deployed into the FPGA structure by the client or other objects. The authentication root key belongs to an asymmetric key. The key agreement module can sign the generated key agreement information Kb-2 through the authentication root key, and the client can determine whether the received information really comes from the FPGA structure and is not tampered in the transmission process through verifying the signature, and the information which does not pass the signature verification cannot be trusted and adopted by the client. The public key of the authentication root key can be managed by the authentication server and is not public, so that the client side can send the received information to the authentication server, and the authentication server performs signature verification through the maintained public key; the authentication server may then provide the client with a verification result, which is signed by the authentication server and which contains the certificate of the authentication server or whose public key may be published, so that the client can verify the signature to determine the validity of the verification result. Or the public key of the authentication root key can be published, so that the client can perform signature verification on the information from the FPGA structure based on the public key without passing through an authentication server, and thus, the interaction links in the signature verification process can be reduced, the verification efficiency is improved, and the security risk caused by more interaction links is reduced.

The authentication root key described above may be deployed to the FPGA fabric based on the previously deployed circuit logic configuration file. The FPGA structure can avoid taking the authentication root key out of the circuit logic configuration file, so that the FPGA structure can obtain the corresponding authentication root key after loading the circuit logic configuration file to the FPGA chip. Or, the FPGA structure may include a key management chip independent of the FPGA chip, and the FPGA structure may take out the authentication root key from the circuit logic configuration file to which the authentication root key belongs and maintain the authentication root key in the key management chip, so that the authentication root key only exists in the key management chip and does not appear in the circuit logic configuration file deployed on the FPGA structure, thereby improving the security of the authentication root key.

The client can sign the key negotiation information Ka-2 and then send the signed key negotiation information Ka-2 to the FPGA structure, so that the FPGA structure can verify the signature of the received key negotiation information Ka-2, and the verified signature is used as for generating a secret value based on the key negotiation information Ka-2, wherein the public key or the certificate corresponding to the client can be deployed in the FPGA structure through the circuit logic configuration file.

For example, in addition to obtaining the secret value through negotiation between the key negotiation module and the client, the FPGA structure may obtain multiple keys through times of negotiation, for example, after obtaining the secret value through negotiation between the key negotiation module and the client, 32-bit strings may be obtained through KDF times of negotiation, and the first 16-bit strings and the second 16-bit strings are respectively used as different keys, for example, as the configuration file deployment key and the secret service deployment key.

The method comprises the steps that a client side can encrypt a new version circuit logic configuration file to obtain an encrypted new version circuit logic configuration file, the trusted update module can also use a configuration file deployment key to decrypt the encrypted new version circuit logic configuration file to obtain the encrypted new version circuit logic configuration file, and the trusted update module can also use the configuration file deployment key to decrypt the encrypted new version circuit logic configuration file to obtain the new version circuit logic configuration file.

In the above-mentioned new version of the circuit logic configuration file, "new version" is relative to the deployed circuit logic configuration file on the FPGA structure to indicate that the deployed circuit logic configuration file is configured at a relatively earlier time than the FPGA structure, and does not indicate that the logic or function implemented by the corresponding circuit logic configuration file necessarily implements version iteration.

Therefore, in order to reduce the deployment times of the client, the FPGA structure can further comprise a memory, the memory is connected with the FPGA chip, so that the circuit logic configuration file is deployed in the memory, and the FPGA chip reads the circuit logic configuration file from the memory to realize related functions, wherein the memory has non-volatility, so that the circuit logic configuration file can be stored even if the power is off, and only the FPGA chip needs to be read from the memory again after the power is on again without the redeployment of the client.

For example, the content related to the new version of circuit logic configuration file can be a hash value of the new version of circuit logic configuration file or a derivative of the hash value, and the client can generate the hash value or the derivative based on the new version of circuit logic configuration file maintained by the client, so that the client can determine that the new version of circuit logic file has been successfully deployed to the FPGA structure in the case that the client receives and generates the hash value (or the derivative) .

For example, after the FPGA structure deploys the new version of the circuit logic configuration file, the new version of the circuit logic configuration file can be loaded on an FPGA chip to form a new version key agreement module, and the client performs key agreement to obtain a new version configuration file deployment key based on the new version key agreement module, so that the other information can be the hash value (or derivative value) of the deployment key for the new version of the circuit logic configuration file, in the process of negotiating the new version key agreement module with the client for the new version of the configuration file deployment key, the newly deployed authentication root key on the FPGA structure is adopted, and the authentication root key can be derived from the deployed circuit logic configuration file or the new version of the circuit logic configuration file, wherein, when the deployed circuit logic configuration file on the FPGA structure is not the same as the deployed circuit logic configuration file user generation and deployment result, the deployed circuit logic configuration file can be successfully deployed by other users, such as the new version of the circuit logic configuration file, and the new version of the circuit logic configuration file can be successfully deployed by checking the hash value of the new version of the authentication circuit logic configuration file, so that the new version of the authentication circuit logic configuration file can be successfully deployed by the client, the client can be obtained by calculating the new version of the authentication root key agreement module, and the new version of the authentication circuit logic configuration file, so that the new version of the authentication circuit logic configuration file can be obtained by the client, the new version of the authentication circuit logic configuration file, the new version of the new.

Fig. 2 is a schematic structural diagram of block chain nodes provided in an exemplary embodiment, based on the technical solution of this specification, an FPGA structure may be added to the block chain nodes to implement hardware TEE, for example, the FPGA structure may be an FPGA board card as shown in fig. 2, the FPGA board card may be connected to the block chain nodes through a PCIE interface to implement data interaction between the FPGA board card and the block chain nodes.

In the initial stage, no logic defined by a user is burned on the FPGA chip, which is equivalent to that the FPGA chip is in a blank state. A user can form corresponding functions or logics on the FPGA chip by burning a circuit logic configuration file on the FPGA chip. When a circuit logic configuration file is burned for the first time, the FPGA board card does not have a safety protection capability, so that a safety environment is usually provided externally, for example, a user can burn the circuit logic configuration file in an offline environment to realize physical safety isolation, rather than remotely burn on line.

And aiming at the functions or logics required to be realized by the user, corresponding logic codes can be formed through an FPGA hardware language, and the logic codes are subjected to mirroring treatment, so that the circuit logic configuration file can be obtained. Before burning the logic codes to the FPGA board card, a user can check the logic codes. Particularly, when a plurality of users are involved at the same time, the logic codes can be checked by the plurality of users respectively, so that the FPGA board card can meet the requirements of all the users finally, and abnormal problems such as security risk, logic errors and fraud are prevented.

After determining that the code is correct, the user can burn the circuit logic configuration file to the FPGA board card in the off-line environment. Specifically, the circuit logic configuration file is transmitted from the block link point to the FPGA board, and is further deployed in the Flash chip shown in fig. 2, so that even if the FPGA board is powered off, the Flash chip can still store the circuit logic configuration file.

Fig. 3 is a schematic diagram of an exemplary embodiment providing types of function modules formed on an FPGA chip, a circuit logic configuration file disposed in a Flash chip is loaded to the FPGA chip, so that a hardware logic unit included in the FPGA chip can be configured, and a corresponding function module is formed on the FPGA chip, for example, the formed function module may include a plaintext calculation module, a key negotiation module, a decryption and verification module, an encryption and decryption module, and the like as shown in fig. 3.

For example, the key agreement process may include that a user may generate key Ka-1 at a local client, the key agreement module may locally generate key Kb-1, the client may calculate key agreement information Ka-2 based on the key Ka-1, the key agreement module may calculate key agreement information Kb-2 based on the key Kb-1 to obtain key agreement information Kb-2, the client may then send the key agreement information Ka-2 to the key agreement module, the key agreement module may send the key agreement information Kb-2 to the client based on the key Ka-1 and the client may generate secret values based on the key Ka-1 and the key agreement information Kb-2 to the client, the key agreement module may generate the same key agreement value based on the key Ka-1 and the key agreement information Kb-2 and the client may finally obtain a secret value derived from a key agreement block of the key agreement module, and a secret key configuration block of the key agreement information Kb-2 may be derived from the key agreement block of the client, and the key agreement block may be derived from the key agreement block of the key agreement information Kb-2, and the key agreement block may be derived from the key agreement block, the key agreement block may be derived from the key agreement block, and the key agreement block, which may be derived from the key agreement block, and may be derived from the key.

In addition to the configuration file deployment key, the secret value is used to derive a business secret deployment key; for example, the secret value may derive a 32-bit value, and the first 16 bits may be used as a configuration file deployment key and the last 16 bits may be used as a service secret deployment key. The user can deploy the service key to the FPGA card through the service secret deployment key, for example, the service key may include a node private key and a service root key. For example, a user can sign and encrypt the node private key or the service root key by using the service secret deployment key on the client, and send the signed and encrypted service root key to the FPGA board, so that the FPGA board deploys the obtained node private key or the service root key after decrypting and verifying the signature by the decryption and verification module.

For example, when a block link point receives transactions, if the transaction is a plaintext transaction, the block link point can directly process the plaintext transaction, and if the transaction is a privacy transaction, the block link point transmits the privacy transaction to the FPGA board for processing.

For example, the transaction initiator can randomly or based on other modes generate symmetric keys, and a service public key corresponding to the service private key is disclosed, so that the transaction initiator can perform digital envelope encryption on the plaintext transaction content based on the symmetric keys and the service public key, wherein the transaction initiator encrypts the plaintext transaction content through the symmetric keys and encrypts the symmetric keys through the service public key, and two obtained parts of contents are contained in the privacy transaction, or in other words, the privacy transaction contains two parts of contents, namely, the plaintext transaction content encrypted by the symmetric keys and the symmetric keys encrypted by the service public key.

Therefore, after receiving the private transaction transmitted by the block chain link point, the FPGA board can decrypt the symmetric key encrypted by the service public key through the service private key by the encryption and decryption module to obtain the symmetric key, and then decrypt the plaintext transaction content encrypted by the symmetric key through the symmetric key by the encryption and decryption module to obtain the plaintext transaction content. The private transaction can be used for deploying the intelligent contract, and then the data field of the content of the clear text transaction can contain the register type contract code of the intelligent contract to be deployed; alternatively, the private transaction may be used to invoke an intelligent contract, and then the to field of the plaintext transaction content may contain the contract address of the invoked intelligent contract, and the FPGA board may invoke the corresponding register-based contract code based on the contract address.

The plaintext calculation module formed on the FPGA chip is used for realizing the logic of the virtual machine in the related technology, namely the plaintext calculation module is equivalent to a hardware virtual machine on the FPGA board card. Thus, after the register contract code is determined based on the content of the plaintext transaction, the register contract code may be passed into a plaintext calculation module for execution by the plaintext calculation module. After execution, the contract state referred to by the register contract code may be updated. If the contract state needs to be stored outside the FPGA chip, the encryption and decryption module encrypts the updated contract state through the service root key or the derivative key thereof and stores the encrypted contract state so as to ensure that the data related to the privacy transaction is only in a plaintext state in the FPGA chip and is in a ciphertext state outside the FPGA chip, thereby ensuring the security of the data.

The plaintext calculation module may be a register-type on-chip processor in this specification. And executing the register code program of the intelligent contract by the register on-chip processor aiming at the intelligent contract which needs to be deployed or called for the transaction received by the blockchain node. The register code program can be obtained by a transaction submitting party by directly compiling a high-level language program on a client, or the high-level language program is compiled into a byte code program and then the byte code program is compiled into the register code program.

Compared with the stack architecture, the number of the operands involved in the machine code can be or more, compared with the stack architecture, the stack operation involves 4 steps and the register operation involves 2 steps, and if each step needs to occupy clock cycles of the processor on the register chip, the stack operation needs to consume 4 clock cycles and the register operation only needs to consume 2 clock cycles.

For example, when the contract code contains 1000 instructions, the contract code is executed sequentially by consuming 1000 clock cycles assuming that each instruction occupies clock cycles of the register on-chip processor, and the consumption of the clock cycles can be reduced based on the parallel operation, wherein the specific reduction amount depends on the dependency relationship among the instructions.

For reasons, a user may wish to perform version update on a circuit logic configuration file deployed on an FPGA board, for example, an authentication root key included in the circuit logic configuration file may be known by a risky user, and for example, the user may wish to upgrade a function module deployed on the FPGA board.

, the user can sign the new circuit logic configuration file through a private key owned by the user, then encrypt the signed new circuit logic configuration file through a configuration file deployment key issued by the above protocol to obtain the encrypted new circuit logic configuration file, under conditions, a plurality of users may exist at the same time, the old circuit logic configuration file needs to deploy preset certificates corresponding to the users to the FPGA board card, and the users need to sign the new circuit logic configuration file by using the private keys owned by the users.

The decryption and signature checking module formed on the FPGA chip is located on a transmission path between the PCIE interface and the Flash chip, so that the encrypted new version circuit logic configuration file can be transmitted into the Flash chip to realize credible updating without passing through the decryption and signature checking process, and the Flash chip can not be directly updated.

After receiving the encrypted new version circuit logic configuration file, the decryption and signature module decrypts the encrypted new version circuit logic configuration file by using a configuration file deployment key deployed on the FPGA board card, if the decryption is successful, the decryption and signature module proceeds to steps to verify the signature of the decrypted new version circuit logic configuration file based on a preset certificate deployed on the FPGA chip, if the decryption is failed or the signature verification is not passed, the decryption and signature module triggers to terminate the current updating operation if the received file is not from the user or is tampered, and if the decryption is successful and the signature passes, the decryption and signature module can determine that the obtained new version circuit logic configuration file is from the user and is not tampered in the transmission process, and the new version circuit logic configuration file can be further transmitted to a Flash chip to update and deploy the old version circuit logic configuration file in the Flash chip.

The FPGA board card can be remotely negotiated with a user to obtain a new configuration file deployment key based on the updated key negotiation module, the authentication root key and the like, and the configuration file deployment key can be used for times of new updating processes.

For example, the key agreement module may calculate a hash value of the new version circuit logic configuration file and a hash value of a configuration file deployment key negotiated based on the new version circuit logic configuration file through, for example, an sm3 algorithm or other algorithms, and the obtained calculation result may be used as the authentication result and sent to the user by the key agreement module.

FIG. 4 is a schematic block diagram of a transaction processing arrangement of the FPGA-based secure intelligent contract processors provided by an exemplary embodiment of . referring to FIG. 4, in a software implementation, the arrangement may include:

a loading unit 401, configured to enable the FPGA structure to load the deployed circuit logic configuration file in the memory onto the FPGA chip, so as to form a register-type on-chip processor for implementing virtual machine logic on the FPGA chip;

an obtaining unit 402, configured to enable the FPGA structure to obtain, according to a transaction received by a block chain node to which the FPGA structure belongs, a register code program of an intelligent contract related to the transaction;

an execution unit 403, which causes the FPGA fabric to transfer the register code program into the register on-chip processor, and causes the register on-chip processor to execute the register code program.

Optionally, during the processing by the register-type on-chip processor, operands involved by the register-type code program are written into registers on the FPGA chip.

Alternatively to this, the first and second parts may,

the register code program is obtained by directly compiling a high-level language program; alternatively, the first and second electrodes may be,

the register code program is obtained by directly compiling a byte code program, and the byte code program is obtained by directly compiling the high-level language program.

Optionally, the method further includes:

a decryption unit 404, which enables the FPGA structure to obtain encrypted transactions from the affiliated block link points, and transmits the transactions to a decryption module on the FPGA chip to obtain plaintext transaction contents; wherein the decryption module is formed on the FPGA chip from the deployed circuit logic configuration file;

an extracting unit 405, which causes the FPGA fabric to extract the registered code program from the plaintext transaction content if the transaction is used to deploy a smart contract;

the search unit 406, in the case that the transaction is used to invoke an intelligent contract, causes the FPGA structure to extract a contract address from the plaintext transaction content, and obtains the register-based code program based on the contract address.

Optionally, the search unit 406 is specifically configured to:

enabling the FPGA structure to request the block chain link points and obtain an encrypted register code program corresponding to the contract address;

and enabling the FPGA structure to transmit the encrypted register code program to the decryption module so as to decrypt the encrypted register code program.

Optionally, the method further includes:

a plaintext storage unit 407, configured to enable the FPGA structure to store the contract state updated after the register code program runs in an on-chip storage space of the FPGA chip; alternatively, the first and second electrodes may be,

a cipher text storage unit 408, which enables the FPGA structure to encrypt the contract state updated after the register code program runs through an encryption module on the FPGA chip, and stores the encrypted contract state in an external storage space outside the FPGA chip; wherein the encryption module is formed on the FPGA chip from the deployed circuit logic configuration file.

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

typical implementation devices are computers, which may be in the form of personal computers, laptop computers, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email transceivers, game consoles, tablet computers, wearable devices, or a combination of any of these devices.

In typical configurations, a computer includes or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile 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 a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, 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, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises the series of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.

In addition, the processes depicted in the accompanying figures do not require the particular order shown or sequential order to achieve desirable results .

As used in this specification or more embodiments and the appended claims, the singular forms "," "said," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

It should be understood that although the terms , second, third, etc. may be used throughout this specification in or various embodiments to describe various information, such information should not be limited to these terms.

While the above disclosure describes preferred embodiments, it is not intended to limit the present disclosure to the particular embodiments, and it is intended to cover all modifications, equivalents, improvements, etc. that fall within the spirit and scope of the present disclosure or more embodiments within the spirit and principles of the present disclosure or more embodiments.

Claims

1, transaction processing method of security intelligent contract processor based on FPGA, comprising:

2. The method of claim 1, wherein operands involved in the registered code program are written to registers on the FPGA chip during processing by the registered on-chip processor.

3. The method of claim 1, wherein the first and second light sources are selected from the group consisting of,

4. The method of claim 1, further comprising:

the FPGA structure obtains encrypted transactions from the affiliated block link points, and transmits the transactions to a decryption module on the FPGA chip to obtain plaintext transaction contents; wherein the decryption module is formed on the FPGA chip from the deployed circuit logic configuration file;

in the event that the transaction is for deploying a smart contract, the FPGA structure extracts the registered code program from the clear text transaction content;

in the case where the transaction is used to invoke an intelligent contract, the FPGA structure extracts a contract address from the plaintext transaction content and retrieves the register-based code program based on the contract address.

5. The method of claim 4, the FPGA fabric fetching the registered code program based on the contract address, comprising:

the FPGA structure requests the block chain link point and obtains an encrypted register code program corresponding to the contract address;

and the FPGA structure transmits the encrypted register code program to the decryption module to decrypt and obtain the register code program.

6. The method of claim 1, further comprising:

the FPGA structure stores the contract state updated after the register code program runs in an on-chip storage space of the FPGA chip; alternatively, the first and second electrodes may be,

the FPGA structure encrypts the contract state updated after the register code program runs through an encryption module on the FPGA chip and stores the encrypted contract state in an external storage space outside the FPGA chip; wherein the encryption module is formed on the FPGA chip from the deployed circuit logic configuration file.

7. The method of claim 1, the virtual machine logic comprising: the execution logic of the EtherFang virtual machine or the execution logic of the WASM virtual machine.

8, transaction processing device of safety intelligent contract processor based on FPGA, comprising:

An electronic device of the type , comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any of claims 1-7 by executing the executable instructions.

10, computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method of any of claims 1-7, wherein the steps are as set forth in any of claims .