WO2021057124A1

WO2021057124A1 - Fpga-based privacy block chain implementing method and device

Info

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

Abstract

An FPGA-based privacy block chain implementing method and device. Said method comprises: a client deploying a circuit logic configuration file to an FPGA structure at a block chain node, the circuit logic configuration file being used for implementing the FPGA structure as a trusted execution environment of the block chain node (102); the client receiving an authentication result returned by the FPGA structure, the authentication result being signed by an authentication root key deployed in the FPGA structure, and a public key corresponding to the authentication root key being published (104); and the client confirming, in cases where the authentication result passes signature verification and the authentication result contains content related to the circuit logic configuration file, that the circuit logic configuration file is successfully deployed on the FPGA structure (106).

Description

Method and device for implementing privacy blockchain based on 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 a privacy blockchain based on 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 a privacy blockchain based on FPGA.

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

According to the first aspect of one or more embodiments of this specification, a method for implementing a privacy blockchain based on FPGA is proposed, which includes:

The client deploys a circuit logic configuration file to the FPGA structure at the blockchain node, where the circuit logic configuration file is used to implement the FPGA structure as a trusted execution environment of the blockchain node;

The client receives the authentication result returned by the FPGA structure, the authentication result is signed by the authentication root key deployed in the FPGA structure, and the public key corresponding to the authentication root key is made public;

The client confirms that the circuit logic configuration file is successfully deployed on the FPGA structure when the authentication result passes the signature verification and the authentication result includes content related to the circuit logic configuration file.

According to the second aspect of one or more embodiments of this specification, a method for implementing a privacy blockchain based on FPGA is proposed, which includes:

The FPGA structure deploys a circuit logic configuration file from the client, and the circuit logic configuration file is used to implement the FPGA structure as a trusted execution environment on the blockchain node to which it belongs;

The FPGA structure signs the authentication result through the deployed authentication root key, the authentication result includes content related to the circuit logic configuration file, and the public key corresponding to the authentication root key is disclosed;

The FPGA structure returns the signed authentication result to the client, so that the client passes the signature verification on the authentication result and the authentication result includes content related to the circuit logic configuration file In this case, it is confirmed that the circuit logic configuration file is successfully deployed on the FPGA structure.

According to the third aspect of one or more embodiments of this specification, a device for implementing a privacy blockchain based on FPGA is proposed, including:

The configuration file deployment unit enables the client to deploy a circuit logic configuration file to the FPGA structure at the blockchain node, where the circuit logic configuration file is used to implement the FPGA structure as a trusted execution environment for the blockchain node;

The authentication result receiving unit enables the client to receive the authentication result returned by the FPGA structure, the authentication result being signed by the authentication root key deployed in the FPGA structure, and the public key corresponding to the authentication root key Be made public

A confirmation unit is deployed to enable the client to confirm that the circuit logic configuration file is on the FPGA structure when the authentication result passes the signature verification and the authentication result contains content related to the circuit logic configuration file The deployment was successful.

According to the fourth aspect of one or more embodiments of this specification, a device for implementing a privacy blockchain based on FPGA is proposed, including:

The configuration file deployment unit enables the FPGA structure to deploy the circuit logic configuration file from the client, and the circuit logic configuration file is used to implement the FPGA structure as a trusted execution environment on the blockchain node to which it belongs;

The authentication result signing unit causes the FPGA structure to sign the authentication result through the deployed authentication root key, the authentication result includes content related to the circuit logic configuration file, and the public authentication root key corresponds to the authentication result. Key is made public;

The authentication result returning unit is configured to enable the FPGA structure to return the signed authentication result to the client, so that the client passes the signature verification on the authentication result and the authentication result includes the circuit logic In the case of configuration file-related content, it is confirmed that the circuit logic configuration file is successfully deployed on the FPGA structure.

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

processor;

A memory for storing processor executable instructions;

Wherein, the processor implements the method according to the first aspect by running the executable instruction.

According to the sixth 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.

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

processor;

A memory for storing processor executable instructions;

Wherein, the processor implements the method according to the second aspect by running the executable instruction.

According to the eighth aspect of one or more embodiments of the present specification, a computer-readable storage medium is provided with computer instructions stored thereon, which when executed by a processor implements the steps of the method described in the second aspect.

Description of the drawings

Fig. 1 is a flowchart of a method for implementing a privacy blockchain based on FPGA provided by an exemplary embodiment.

Fig. 2 is a flowchart of another method for implementing a privacy blockchain based on FPGA provided by an exemplary embodiment.

Fig. 3 is a schematic flowchart of an interaction process between a client and an FPGA structure provided by an exemplary embodiment.

Fig. 4 is a schematic diagram of a blockchain node processing a transaction according to an exemplary embodiment.

Fig. 5 is a schematic structural diagram of a device provided by an exemplary embodiment.

Fig. 6 is a block diagram of a device for implementing a privacy blockchain based on FPGA provided by an exemplary embodiment.

Fig. 7 is a schematic structural diagram of another device provided by an exemplary embodiment.

Fig. 8 is a block diagram of another device for implementing a privacy blockchain based on 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.

Block chains are 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. In related technologies, a remote attestation mechanism is used to confirm whether the TEE is authentic and credible. Taking Intel SGX technology as an example, when a challenger wants to verify a certain circle in the target device, the circle to be verified first generates the configuration file deployed by itself as a Report, for example, the report can include the circle to be verified The hash value of the deployed configuration file, etc.; then, the enclave to be verified uses the local authentication mechanism to obtain the remote verifiable Quote. Specifically, a special enclave called Quoting Enclave (QE) on the target device can use the CPU of the target device The deployed asymmetric key signs the aforementioned Report, thereby generating the aforementioned remotely verifiable Quote, and the target device sends the Quote to the challenger. The above asymmetric keys are burned into the CPU during the production process. The asymmetric keys burned in different CPUs are completely different, and the public key corresponding to each asymmetric key is uniformly maintained in IAS (Intel Attestation Server) Place. Therefore, the challenger needs to further send the Quote provided by the target device to the IAS, and the IAS will verify the signature contained in the Quote to determine the validity of the SGX platform on the target device and feed back the judgment result to the challenger. If the judgment result shows that the SGX platform on the target device is valid, the challenger can further verify the Report contained in the Quote, for example, compare the hash value contained in the Report with the hash value corresponding to the standard configuration file held by the challenger : If the hash values are consistent, the challenger can determine that the standard configuration file is correctly configured in the circle to be verified of the target device, that is, the circle to be verified above has passed the remote certification.

However, although the remote certification mechanism in related technologies can prove that the correct configuration file is deployed in the TEE, the operating environment on which the TEE itself depends cannot be verified; for example, on the blockchain nodes that need 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 execute a number of corresponding X86 instructions (assuming that the target device adopts the X86 architecture), which causes a certain degree of Security risks on the Internet.

The following describes a method for implementing a privacy blockchain based on FPGA provided in this specification in conjunction with embodiments to improve security.

Fig. 1 is a flowchart of a method for implementing a privacy blockchain based on FPGA provided by an exemplary embodiment. As shown in Figure 1, the method is applied to the client and can include the following steps:

Step 102: The client deploys a circuit logic configuration file to the FPGA structure at the blockchain node, where the circuit logic configuration file is used to implement the FPGA structure as a trusted execution environment of the blockchain node.

The client can include any object that needs to implement deployment operations to the FPGA structure, so that the FPGA structure can implement corresponding services or functions based on the deployed circuit logic configuration file. For example, the client can include a key management server, that is, a KMS (Key Management Service) server. After determining that the correct circuit logic configuration file is deployed on the FPGA structure, the KMS server can assign the corresponding service key to the FPGA structure so that The FPGA structure can be implemented as a TEE on a blockchain node, thereby realizing a blockchain node with privacy functions.

Therefore, the client deploys an appropriate circuit logic configuration file to the FPGA structure, so that the FPGA structure can be implemented as a TEE on the blockchain node after the circuit logic configuration file is correctly configured. For example, the circuit logic configuration file may include a virtual machine used to implement (taking the aforementioned Ethereum blockchain as an example, the virtual machine may be an Ethereum Virtual Machine (EVM); in other blockchains) It can also be the configuration information of other types of virtual machines), encryption and decryption functions. These configuration information can be specifically represented in the form of bitstreams to facilitate burning to the FPGA structure. Of course, this specification does not limit the circuit logic configuration files used form.

The FPGA structure can be pre-deployed with an authentication root key (Attestation Key), the authentication root key can be pre-placed in the FPGA structure, or the authentication root key can be deployed to the FPGA in an offline secure environment by the client or other objects Structure. Wherein, the authentication root key is an asymmetric key, and the public key corresponding to the authentication root key is disclosed, so that even if the authentication root key is not deployed by the client (preset or deployed by other objects), the client The end can also verify the signature generated by the authentication root key based on the public key that is disclosed.

The client can realize key agreement with the FPGA structure. Assuming that the SM2 (or other algorithm) algorithm is used to realize the negotiation, the client and the FPGA structure need to implement at least one information exchange during the negotiation process: when the FPGA structure sends the negotiation information to the client, the above authentication root key can be used for the negotiation The information is signed, so that the client can use the public key to perform signature verification after receiving the signed negotiation information, so as to confirm that the negotiation information is indeed sent by the FPGA structure and trust the negotiation information; and when the signature fails During verification, the client can choose not to trust the received negotiation information. Based on the above process, the client and FPGA structure can complete key negotiation, so that the client and FPGA structure can obtain the same configuration file deployment key respectively. Among them, the configuration file deployment key can be directly obtained by the client and the FPGA structure through a key agreement process, that is, the configuration file deployment key can be a secret value (or master key); or, the configuration file deployment key The key can be derived from the above-mentioned secret value by the client and the FPGA structure respectively through the Key Derivation Function (KDF). Based on the configuration file deployment key obtained through negotiation, the client can encrypt the above-mentioned circuit logic configuration file and send the encrypted circuit logic configuration file to the FPGA structure; accordingly, the FPGA structure receives the encrypted circuit logic configuration file Later, the corresponding circuit logic configuration file can be obtained by decrypting according to the configuration file deployment key, and the circuit logic configuration file can be deployed.

The FPGA structure may include an FPGA chip, and when the FPGA structure deploys a circuit logic configuration file, the circuit logic configuration file can be directly read into the FPGA chip. However, the FPGA chip is volatile, and the circuit logic configuration file deployed after the power is off will be lost, so that the client needs to re-deploy the circuit logic configuration file after power on. Therefore, in order to reduce the number of deployments of the client, the FPGA structure can further include a memory, which is connected to 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 implement related functions ; Among them, the memory is non-volatile, even if the power is off, the circuit logic configuration file can still be saved, and after the power is turned on, it is only necessary to read the FPGA chip from the memory again, without the client re-deployment. The memory may have various forms, such as non-volatile memory that can be repeatedly erased and writable such as flash memory, and non-repeatable memory such as fuse memory, which is not limited in this specification.

The FPGA structure may include a key management chip, and the aforementioned authentication root key may be stored in the key management chip to have high security and high reliability. Of course, the authentication root key can also be stored in the aforementioned FPGA chip or memory, which is not limited in this specification.

Step 104: The client receives the authentication result returned by the FPGA structure, the authentication result is signed by the authentication root key deployed in the FPGA structure, and the public key corresponding to the authentication root key is made public.

Step 106: The client confirms that the circuit logic configuration file is successfully deployed on the FPGA structure when the authentication result passes the signature verification and the authentication result contains content related to the circuit logic configuration file .

As mentioned earlier, since the authentication root key deployed in the FPGA structure is an asymmetric key, and the public key corresponding to the authentication root key is disclosed, the client can obtain the public key in advance and target the FPGA structure accordingly. The returned authentication result is subjected to signature verification, and if the signature verification is passed, it is determined that the authentication result is provided by the FPGA structure and the authentication result has not been tampered with. The above verification process can be completed locally by the client without the need of a third party. On the one hand, it can reduce the number of interactions and improve the efficiency of verification. On the other hand, it can avoid the intervention of third parties and the increase in the number of interactions that may cause additional security risks. To ensure the reliability of the verification results does not depend on the self-control and credibility of a third party.

The client can verify the content related to the circuit logic configuration file contained in the authentication result, so as to determine whether the content is consistent with the circuit logic configuration file deployed by the client to the FPGA structure. For example, the above-mentioned content related to the circuit logic configuration file may be the hash value of the circuit logic configuration file, or the value obtained by calculating the hash value of the circuit logic configuration file using a preset algorithm (such as sm3 algorithm, etc.), so that In the case that the client has the above-mentioned circuit logic configuration file and the above-mentioned preset algorithm is known, it can calculate the hash value of the circuit logic configuration file locally or use the above-mentioned preset algorithm to further calculate the hash value, and verify it with The above-mentioned hash values or values contained in the result are compared: if they are consistent, it indicates that the FPGA structure correctly deploys the circuit logic configuration file provided by the client; otherwise, it indicates that the circuit logic configuration file is not configured successfully.

Further, the aforementioned authentication result may also include content related to the deployment key of the configuration file. Correspondingly, the client can verify the above-mentioned authentication result according to the deployment key of the configuration file exported by itself. For example, the authentication result can include the hash value of the configuration file deployment key, or the value obtained by calculating the configuration file deployment key or its hash value using a preset algorithm, which is similar to the above-mentioned circuit logic configuration file. The client can calculate the hash value or the value related to the above-mentioned preset algorithm according to the configuration file deployment key exported by itself: if the authentication result contains the content related to the circuit logic configuration file and the content related to the configuration file deployment key. Passing the verification indicates that the FPGA structure and the client have successfully negotiated the configuration file deployment key, and the FPGA structure has correctly deployed the circuit logic configuration file provided by the client, otherwise it indicates that the key negotiation failed or the circuit logic configuration file deployment failed . For another example, the content related to the circuit logic configuration file and the content related to the configuration file deployment key in the authentication result can be generated as the same content, that is, the authentication result can include a circuit logic configuration file and configuration file deployment key at the same time. Related content; for example, the FPGA structure can use a preset algorithm to calculate the deployed circuit logic configuration file (or its hash value) and the negotiated configuration file deployment key (or its hash value) to obtain a value , As the content related to the circuit logic configuration file and the configuration file deployment key in the above authentication result, and the client maintains the circuit logic configuration file, the configuration file deployment key and the known above-mentioned preset algorithm according to its own maintenance, namely The value contained in the certification result can be verified.

Similar to the configuration file deployment key mentioned above, the client can negotiate a key with the FPGA structure, so that the client and FPGA structure can respectively export the same business secret deployment key to use the service provided by the client The key or other business secrets are deployed to the FPGA structure. Among them, in the key negotiation process, the client and the FPGA structure need to send negotiation information to each other, and after the FPGA structure generates the negotiation information, it can sign with the aforementioned authentication root key, and send the signed negotiation information to the client The client can perform signature verification according to the public key that has been disclosed: after the signature is verified, the client determines that the negotiation information comes from the FPGA structure, and further completes the negotiation process based on the negotiation information, otherwise the client can terminate the key negotiation. Finally, the client and FPGA structure can obtain the same business secret deployment key after negotiation. Among them, the business secret deployment key can be directly obtained by the client and the FPGA structure through a key agreement process, that is, the business secret deployment key can be a secret value (or master key); or, the business secret deployment key The key can be derived from the above-mentioned secret value through the key derivation function through the client and FPGA structure respectively.

Based on the negotiated business secret deployment key, the client can encrypt the business key that needs to be deployed and send the encrypted business key to the FPGA structure; accordingly, after the FPGA structure receives the encrypted business key, The corresponding service key can be obtained by decryption according to the service secret deployment key, and the service key can be deployed.

For example, the service key may include: the node private key, the node public key corresponding to the node private key is disclosed; where the node public key is used to encrypt the transaction, or the node public key is symmetrical with the transaction submitting party The key is commonly used to encrypt transactions through digital envelopes. Take the privacy transaction in the blockchain scenario as an example. Assuming that the transaction submitting party wants to keep the content of the submitted transaction confidential, the transaction submitting party can encrypt the transaction with the above-mentioned node public key and submit it to the blockchain node. The node can use the node's private key to decrypt in the FPGA structure to obtain the transaction content in plain text; or, the transaction submitting party can use a randomly generated (or obtained by other means) symmetric key to encrypt the transaction, and then pass through the above-mentioned node The public key encrypts the symmetric key, and submits the encrypted transaction and the encrypted symmetric key to the blockchain node, and the blockchain node can use the node private key in the FPGA structure to decrypt the encrypted symmetric key , And decrypt the encrypted transaction with the symmetric key obtained by decryption, so as to obtain the transaction content in plain text.

For another example, the business key may include: the business root key, the business root key or the derived key of the business root key is used to encrypt the private data generated in the trusted execution environment and store it to the blockchain node Maintained in the database. For example, after a blockchain node executes a transaction in the TEE formed by the FPGA structure, the above-mentioned private data with encryption requirements may be generated. For example, the private data may include the value of the contract state generated by the execution of the smart contract, then the FPGA structure may The private data is encrypted by the business root key or its derived key, and the encrypted private data is stored in the database maintained by the blockchain node. Correspondingly, when the private data needs to be read, by reading the encrypted private data into the FPGA structure, the FPGA structure can be decrypted based on the business root key or its derivative key, and the corresponding plaintext can be obtained. Private data, so as to read or update the value of the private data, or use the value of the private data to participate in other calculation processes, etc.

The client and the FPGA structure can negotiate to obtain the above-mentioned configuration file deployment key and business secret deployment key through two negotiation processes. Or, the client and the FPGA structure can negotiate to obtain the above configuration file deployment key and business secret deployment key at the same time through a negotiation process; for example, the client and the FPGA structure can negotiate to obtain the same secret value, and then pass the above-mentioned secret value. The key export function exports the configuration file deployment key and the business secret deployment key. For example, the key export function can export a 32-byte random number at one time. The first 16 bytes can be used as the configuration file deployment key and the last 16 bytes can be used as the configuration file deployment key. Business secret deployment key.

Fig. 2 is a flowchart of another method for implementing a privacy blockchain based on FPGA provided by an exemplary embodiment. As shown in Figure 2, the method is applied to the FPGA structure and can include the following steps:

Step 202: The FPGA structure deploys the circuit logic configuration file from the client, and the circuit logic configuration file is used to implement the FPGA structure as a trusted execution environment on the blockchain node to which it belongs.

The client can include any object that needs to implement deployment operations to the FPGA structure, so that the FPGA structure can implement corresponding services or functions based on the deployed circuit logic configuration file. For example, the client may include a key management server, that is, a KMS server. After determining that the correct circuit logic configuration file is deployed on the FPGA structure, the KMS server may assign the FPGA structure to the corresponding business key, so that the FPGA structure can be implemented as The TEE on the blockchain node realizes the blockchain node with privacy function.

Therefore, the client deploys an appropriate circuit logic configuration file to the FPGA structure, so that the FPGA structure can be implemented as a TEE on the blockchain node after the circuit logic configuration file is correctly configured. For example, the circuit logic configuration file may include configuration information used to implement functions such as virtual machines (EVM or other types of virtual machines), encryption and decryption, and these configuration information may be specifically represented in the form of a bit stream to facilitate burning to the FPGA structure Of course, this specification does not limit the form of the circuit logic configuration file.

An authentication root key may be pre-deployed on the FPGA structure, and the authentication root key may be preset in the FPGA structure, or the authentication root key may be deployed into the FPGA structure by the client or other objects in an offline security environment. Wherein, the authentication root key is an asymmetric key, and the public key corresponding to the authentication root key is disclosed, so that even if the authentication root key is not deployed by the client (preset or deployed by other objects), the client The end can also verify the signature generated by the authentication root key based on the public key that is disclosed.

The client can realize key agreement with the FPGA structure. Assuming that the SM2 (or other algorithm) algorithm is used to realize the negotiation, the client and the FPGA structure need to implement at least one information exchange during the negotiation process: when the FPGA structure sends the negotiation information to the client, the above authentication root key can be used for the negotiation The information is signed, so that the client can use the public key to perform signature verification after receiving the signed negotiation information, so as to confirm that the negotiation information is indeed sent by the FPGA structure and trust the negotiation information; and when the signature fails During verification, the client can choose not to trust the received negotiation information. Based on the above process, the client and FPGA structure can complete key negotiation, so that the client and FPGA structure can obtain the same configuration file deployment key respectively. Among them, the configuration file deployment key can be directly obtained by the client and the FPGA structure through a key agreement process, that is, the configuration file deployment key can be a secret value (or master key); or, the configuration file deployment key The key can be derived from the above-mentioned secret value through the key derivation function through the client and FPGA structure respectively. Based on the configuration file deployment key obtained through negotiation, the client can encrypt the above-mentioned circuit logic configuration file and send the encrypted circuit logic configuration file to the FPGA structure; accordingly, the FPGA structure receives the encrypted circuit logic configuration file Later, the corresponding circuit logic configuration file can be obtained by decrypting according to the configuration file deployment key, and the circuit logic configuration file can be deployed.

The FPGA structure may include an FPGA chip, and when the FPGA structure deploys a circuit logic configuration file, the circuit logic configuration file can be directly read into the FPGA chip. However, the FPGA chip is volatile, and the circuit logic configuration file deployed after the power is off will be lost, so that the client needs to re-deploy the circuit logic configuration file after power on. Therefore, in order to reduce the number of deployments of the client, the FPGA structure can further include a memory, which is connected to 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 implement related functions ; Among them, the memory is non-volatile, even if the power is off, the circuit logic configuration file can still be saved, and after the power is turned on, it is only necessary to read the FPGA chip from the memory again, without the client re-deployment. The memory may have various forms, such as a non-volatile memory that can be re-erasable, such as flash memory, and a non-re-erasable memory, such as a fuse memory, which is not limited in this specification.

Step 204: The FPGA structure signs the authentication result through the deployed authentication root key, the authentication result includes content related to the circuit logic configuration file, and the public key corresponding to the authentication root key is disclosed .

In step 206, the FPGA structure returns the signed authentication result to the client, so that the client passes the signature verification on the authentication result and the authentication result contains information related to the circuit logic configuration file In the case of the content, confirm that the circuit logic configuration file is successfully deployed on the FPGA structure.

For another example, the business key may include: the business root key, the business root key or the derived key of the business root key is used to encrypt the private data generated in the trusted execution environment and store it to the blockchain node Maintained in the database. For example, after a blockchain node executes a transaction in the TEE formed by the FPGA structure, the above-mentioned private data with encryption requirements may be generated. For example, the private data may include the value of the contract state generated by the execution of the smart contract, then the FPGA structure can The private data is encrypted by the business root key or its derived key, and the encrypted private data is stored in the database maintained by the blockchain node. Correspondingly, when the private data needs to be read, by reading the encrypted private data into the FPGA structure, the FPGA structure can be decrypted based on the business root key or its derivative key, and the corresponding plaintext can be obtained. Private data, so as to read or update the value of the private data, or use the value of the private data to participate in other calculation processes, etc.

Fig. 3 is a schematic flowchart of an interaction process between a client and an FPGA structure provided by an exemplary embodiment. Assuming that the client can be a KMS server, the FPGA structure is configured on the blockchain node, and the KMS server authenticates the FPGA structure, so that if the FPGA structure is authenticated, it is required to deploy the blockchain node to the FPGA structure To configure the blockchain node to have a privacy function, so as to realize a blockchain network with privacy function. As shown in Figure 3, the method may include the following steps:

Step 301, the FPGA structure deploys the authentication root key.

The authentication root key can be deployed by the manufacturer in the process of manufacturing the FPGA structure, that is, the manufacturer deploys the authentication root key to the FPGA structure, for example, to the key management chip contained in the FPGA structure.

Of course, the authentication root key can also be deployed by the client. For example, the user corresponding to the client can deploy the authentication root key into the FPGA structure in a physical security environment in an offline state, for example, into the above-mentioned key management chip.

No matter which deployment method is adopted, the authentication root key deployed in the FPGA structure is an asymmetric key, that is, the authentication root key has a corresponding authentication public key, and the authentication public key is in a public state. For example, a certain website can be provided so that the client can download the above-mentioned authentication public key.

Step 302, the client and the FPGA structure remotely negotiate a key.

It is assumed that the client and FPGA structure can use algorithms such as SM2 to achieve key negotiation. In the negotiation process, the client and the FPGA structure need to generate negotiation information separately, and exchange the negotiation information generated by each other remotely, so as to complete the negotiation process. Wherein, after the FPGA structure generates the negotiation information, it can sign the negotiation information with the above authentication root key, and then send the signed negotiation information to the client. Correspondingly, after the client receives the negotiation information from the remote end, it can use the pre-obtained authentication public key to sign the negotiation information: if the verification is successful, it indicates that the negotiation information does come from the FPGA structure, that is, the negotiation information is credible , So as to complete the subsequent negotiation process based on the negotiation information, otherwise terminate the key negotiation. It can be seen that because the FPGA structure has a built-in authentication root key, and the authentication public key corresponding to the authentication root key is in the public state, the client and the FPGA structure can realize remote key negotiation based on this, and the client can complete the signature locally. Verification without resorting to a third party can prevent the interaction between the client and the third party from reducing the verification efficiency, and avoid the reliability of the verification result from relying on the credibility of the third party, which helps to improve security.

Step 303: The client and FPGA structure respectively export the configuration file deployment key and the business secret deployment key.

Based on the key agreement operation, the client and the FPGA structure can respectively generate the same secret value, and further process the secret value through the KDF function, and can derive the above-mentioned configuration file deployment key and business secret deployment key. For example, the KDF function can derive a set of 32-byte random numbers, the first 16-byte random number can be used as the configuration file deployment key, and the last 16-byte random number can be used as the business secret deployment key; of course, the KDF function can derive other The length of the random number, and each key can use other lengths respectively, this specification does not limit this. The random numbers exported by the KDF function are not necessarily used to generate business keys. For example, the KDF function can export a 64-byte random number. The first 16-byte random number can be selected as the configuration file deployment key, and the last 16-byte random number can be selected as the configuration file deployment key. The number is used as the business secret deployment key, and the remaining 32 bytes of random numbers are discarded.

The client and FPGA structure respectively maintain the exported configuration file deployment key and business secret deployment key. Wherein, the FPGA structure may include an FPGA chip and a key management chip, wherein the configuration file deployment key and the business secret deployment key can be maintained in the key management chip to ensure its security.

In step 304, the client generates and encrypts the circuit logic configuration file, and then sends the encrypted circuit logic configuration file to the FPGA structure.

The client encrypts the circuit logic configuration file according to the configuration file deployment key derived in step 303, so that when the encrypted circuit logic configuration file is remotely transmitted to the FPGA structure, no loss will be caused even if data leakage occurs.

Step 305: Decrypt the FPGA structure to obtain the circuit logic configuration file and deploy it.

After the FPGA structure receives the encrypted circuit logic configuration file sent by the client, it can use the configuration file deployment key exported in step 303 to decrypt to obtain the circuit logic configuration file in plain text; then, the FPGA structure can configure the circuit logic in plain text File implementation deployment.

The FPGA structure can include an FPGA chip and a flash chip. The circuit logic configuration file can be deployed in the flash chip, so that the FPGA chip can read and load the above circuit logic configuration file from the flash chip every time it is powered on, and after power off The circuit logic configuration files deployed in the flash chip will not be lost, and there is no need for repeated deployment by the client.

Step 306: The FPGA structure generates and signs the authentication result, and then returns the signed authentication result to the client.

After completing the deployment of the circuit logic configuration file, the FPGA structure can generate the authentication result. For example, the FPGA structure can generate the hash value corresponding to the circuit logic configuration file, such as user_bitstream_hash; at the same time, the FPGA structure can generate the corresponding hash value for the aforementioned configuration file deployment key, such as userbitkey_hash; then, the FPGA structure For example, the sm3 algorithm can be used for calculation, for example, the obtained calculation result is msg, and msg=sm3 (user_bitstream_hash||userbitkey_hash), and the msg information is added to the authentication result.

The FPGA structure further signs the generated authentication result according to the aforementioned authentication root key, so as to send the signed authentication result to the client.

Step 307: After receiving the signed authentication result, the client verifies the signature and authentication content.

As mentioned above, the client can obtain the authentication public key corresponding to the authentication root key in advance, so that the client can perform signature verification based on the authentication public key after receiving the signed authentication result.

After the signature is verified, the client may further verify the authentication content contained in the authentication result, and the authentication content may include the aforementioned msg information. The client can use the sm3 algorithm to calculate msg’=sm3(user_bitstream_hash’||userbitkey_hash’), where: user_bitstream_hash’ represents the circuit logic configuration file maintained locally by the client, and userbitkey_hash’ represents the configuration file deployment key maintained locally by the client. Then, if msg=msg' is calculated, it indicates that the client and the FPGA structure have successfully negotiated the configuration file deployment key in step 303, and that the FPGA structure has successfully deployed the circuit logic configuration file provided by the client; The configuration file deployment key and the business secret deployment key are derived based on the same secret value, which also indicates that the two successfully negotiated the business secret deployment key.

Therefore, the client can complete the verification of the authentication result locally without relying on a third party, which can reduce interaction and improve security.

In step 308, the client determines and encrypts the node private key and the service root key, and then sends the encrypted node private key and the service root key to the FPGA structure.

Step 309: Decrypt the FPGA structure to obtain the node private key and the service root key.

After the client uses the service secret deployment key obtained in step 303 to encrypt service keys such as the node private key and the service root key, the client can safely and remotely transmit the node private key and the service root key to the FPGA structure; Correspondingly, the FPGA structure can be decrypted based on the service secret deployment key obtained in step 303 to obtain the node private key and the service root key, and deploy the node private key and the service root key.

Based on the node private key and business root key deployed on the FPGA structure, the blockchain node can realize the privacy transaction function based on the FPGA structure. For example, FIG. 4 is a schematic diagram of a blockchain node processing transactions provided by an exemplary embodiment. As shown in Figure 4, the blockchain node includes the conventional execution environment on the left and the TEE formed by the FPGA structure on the right. The transaction submitted by the user first enters the "transaction scheduling" interface in the conventional execution environment for type identification, and will identify The plaintext transactions of ”are left in the regular execution environment for processing (corresponding to the "transaction execution" link on the left), and the identified private transactions are passed to the TEE for processing (corresponding to the "transaction execution" link on the right).

The private transaction is encrypted by the user and submitted to the blockchain node. For example, the user can randomly generate a symmetric key, and the node private key deployed on the FPGA structure has a public node public key, so that the user can implement digital envelope encryption on the transaction content based on the symmetric key and the node public key: the user adopts symmetric The key encrypts the transaction content of the plaintext, generates the encrypted transaction content, uses the node public key to encrypt the symmetric key, generates the encrypted symmetric key, and then uses the encrypted transaction content and the encrypted symmetric key as privacy The transaction is submitted to the blockchain node at the same time. Correspondingly, the blockchain node reads the private transaction into the FPGA structure, decrypts the encrypted symmetric key through the node private key deployed in the FPGA structure, obtains the symmetric key, and further encrypts the transaction based on the symmetric key The content is decrypted to obtain the transaction content in plain text, and then the transaction content is processed on the FPGA structure.

Among them, privacy transactions can be understood as transactions that have privacy requirements; in addition to privacy transactions, blockchain nodes may receive plaintext transactions, which are transactions that do not require privacy. Privacy requirements can be expressed in a variety of ways, and this manual does not limit this. For example, each transaction may include a type field, which is used to indicate whether the corresponding transaction is a private transaction or a plaintext transaction. As mentioned earlier, the blockchain node can identify the transaction type in the "transaction scheduling" interface in the conventional execution environment as shown in Figure 1. In related technologies, for example, in the Ethereum network, transactions usually contain fields such as to, value, and data; and this embodiment adds a type field to the transaction on the basis of related technologies, such as a type field, and based on The value of the type field indicates the type of the related transaction: for example, when the type field is the first value, it indicates that the related transaction is a plaintext transaction, and when the type field is the second value, it indicates that the related transaction is a private transaction. For another example, the user can add an encrypted identifier to the transaction in the process of creating a transaction to express the aforementioned privacy requirements. Then, when it is checked that the transaction contains an encrypted identifier, the blockchain node can determine that the transaction is a private transaction, otherwise it is determined that the transaction is a plaintext transaction. For another example, the blockchain node can identify the type of smart contract called for the transaction, when the called smart contract belongs to the privacy type (for example, the smart contract contains a privacy identifier, or the code of the smart contract includes the contract status marked by the privacy identifier, etc. ), the transaction can be determined to be a private transaction, otherwise the transaction is determined to be a plaintext transaction.

The transactions in this specification can be used to implement relatively simple processing logic, for example, similar to the transfer logic in related technologies. At this time, whether it is the above-mentioned plaintext transaction or private transaction, it can not be related to the smart contract.

The transactions in this specification can also be used to implement relatively complex processing logic, which can be implemented here with the help of the above-mentioned smart contract. Taking Ethereum as an example, supporting users to create and/or call some complex logic in the Ethereum network is the biggest challenge that distinguishes Ethereum from Bitcoin blockchain technology. The core of Ethereum as a programmable blockchain is the Ethereum Virtual Machine (EVM), and every Ethereum node can run EVM. EVM is a Turing complete virtual machine, which means that various complex logic can be implemented through it. Users who publish and call smart contracts in Ethereum run on the EVM. As shown in Figure 4, by deploying the EVM in the conventional execution environment, the smart contract issued or called by the plaintext transaction can be executed through the EVM to realize the "transaction execution" link in the conventional execution environment; and, by deploying the EVM in the TEE (The FPGA structure is based on the deployed circuit logic configuration file, which can realize the functions of EVM or other virtual machines). The smart contract issued or called by the private transaction can be executed through the EVM to realize the "transaction execution" link in the TEE.

After the private transaction is processed in the FPGA structure, the account balance of the relevant account or the value of the contract state related to the smart contract may change, and the FPGA structure can be based on the aforementioned business root key or its derivative key to obtain these values. Encryption is performed, and the encrypted value is stored in the database maintained by the blockchain node.

Therefore, only the data in the FPGA structure can be presented in plaintext state to achieve efficient data processing, while the data outside the FPGA structure are all in an encrypted state to ensure data security, thereby enabling privacy protection on the blockchain Features.

Fig. 5 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to FIG. 5. At the hardware level, the device includes a processor 502, an internal bus 504, a network interface 506, a memory 508, and a non-volatile memory 510. Of course, it may also include hardware required for other services. The processor 502 reads the corresponding computer program from the non-volatile memory 510 to the memory 508 and then runs it to form an FPGA-based device for implementing a privacy blockchain at the logical level. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each The logic unit can also be a hardware or a logic device.

Please refer to Fig. 6, in the software implementation, the FPGA-based device for implementing a privacy blockchain may include:

The configuration file deployment unit 61 enables the client to deploy a circuit logic configuration file to the FPGA structure at the blockchain node, where the circuit logic configuration file is used to implement the FPGA structure as a trusted execution environment for the blockchain node ；

The authentication result receiving unit 62 enables the client to receive the authentication result returned by the FPGA structure, the authentication result being signed by the authentication root key deployed in the FPGA structure, and the publicity corresponding to the authentication root key Key is made public;

The deployment confirmation unit 63 enables the client to confirm that the circuit logic configuration file is in the FPGA structure when the authentication result passes the signature verification and the authentication result contains content related to the circuit logic configuration file. The deployment is successful.

Optionally, the authentication root key is preset in the FPGA structure; or, the authentication root key is deployed into the FPGA structure by the client or other objects in an offline security environment.

Optionally, the configuration file deployment unit 61 is specifically configured to:

The client is allowed to negotiate a configuration file deployment key with the FPGA structure according to the negotiation information sent by the FPGA structure, so that the client and the FPGA structure respectively determine the configuration file deployment key; wherein, The negotiation information is signed by the authentication root key;

Make the client encrypt the circuit logic configuration file by using the configuration file deployment key, and send the encrypted circuit logic configuration file to the FPGA structure, so that the FPGA structure deploys the password according to the configuration file. Key to decrypt and deploy the circuit logic configuration file.

Optionally, the authentication result also includes content related to the configuration file deployment key.

Optionally, it also includes:

The service key agreement unit 64 enables the client to negotiate a service secret deployment key with the FPGA structure according to the negotiation information sent by the FPGA structure, so that the client and the FPGA structure respectively determine the service Secret deployment key; wherein the negotiation information is signed by the authentication root key;

The service key deployment unit 65 enables the client to encrypt the service key through the service secret deployment key, and sends the encrypted service key to the FPGA structure so that the FPGA structure is based on the service The secret deployment key performs decryption and deploys the service key.

Optionally, the service key includes: a node private key, and the node public key corresponding to the node private key is disclosed;

Wherein, the node public key is used to encrypt the transaction; or, the node public key and the symmetric key provided by the transaction submitting party are jointly used to encrypt the transaction through a digital envelope.

Optionally, the service key includes: a service root key, and the service root key or a derivative key of the service root key is used to encrypt and store the private data generated in the trusted execution environment To the database maintained by the blockchain node.

Optionally, the client includes a key management server.

Fig. 7 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to FIG. 7. At the hardware level, the device includes a processor 702, an internal bus 704, a network interface 706, a memory 708, and a non-volatile memory 710. Of course, it may also include hardware required for other services. The processor 702 reads the corresponding computer program from the non-volatile memory 710 to the memory 708 and then runs it to form an FPGA-based device for implementing a privacy blockchain at the logical level. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each The logic unit can also be a hardware or a logic device.

Please refer to FIG. 8. In the software implementation, the FPGA-based device for implementing a privacy blockchain may include:

The configuration file deployment unit 81 enables the FPGA structure to deploy the circuit logic configuration file from the client, where the circuit logic configuration file is used to implement the FPGA structure as a trusted execution environment on the blockchain node to which it belongs;

The authentication result signing unit 82 enables the FPGA structure to sign the authentication result through the deployed authentication root key, the authentication result includes content related to the circuit logic configuration file, wherein the authentication root key corresponds to The public key is made public;

The authentication result returning unit 83 enables the FPGA structure to return the signed authentication result to the client, so that the client passes the signature verification on the authentication result and the authentication result includes the same as the circuit In the case of content related to the logic configuration file, it is confirmed that the circuit logic configuration file is successfully deployed on the FPGA structure.

Optionally, the FPGA structure includes a key management chip, and the authentication root key is stored in the key management chip.

Optionally, the FPGA structure includes an FPGA chip and a memory; wherein the circuit logic configuration file is deployed in the memory, and the FPGA chip reads the circuit logic configuration file from the memory to implement Related functions.

Optionally, the memory includes a non-volatile memory or a fuse memory.

Optionally, the configuration file deployment unit 81 is specifically configured to:

Make the FPGA structure negotiate a configuration file deployment key with the client by sending negotiation information to the client, so that the client and the FPGA structure respectively determine the configuration file deployment key; wherein, The negotiation information is signed by the authentication root key;

Enabling the FPGA structure to receive the encrypted circuit logic configuration file sent by the client, where the encrypted circuit logic configuration file is obtained by encrypting the circuit logic configuration file by the configuration file deployment key;

The FPGA structure decrypts the encrypted circuit logic configuration file according to the file deployment key, and deploys the decrypted circuit logic configuration file.

Optionally, it also includes:

The negotiation unit 84 enables the FPGA structure to negotiate with the client to configure the service secret deployment key by sending negotiation information to the client, so that the client and the FPGA structure respectively determine the service secret deployment Key; wherein the negotiation information is signed by the authentication root key;

The receiving unit 85 enables the FPGA structure to receive the encrypted service key sent by the client, where the encrypted service key is obtained by encrypting the service key by the service secret deployment key;

The decryption unit 86 enables the FPGA structure to decrypt the encrypted service key according to the service secret deployment key, and deploy the decrypted service key.

Optionally, the service key includes: a service root key, and the service root key or a derived key of the service root key is used to encrypt private data generated in the trusted execution environment Stored in the database maintained by the blockchain node.

Optionally, the client includes a key management server.

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 "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 a privacy blockchain based on FPGA includes:

The client deploys a circuit logic configuration file to the FPGA structure at the blockchain node, where the circuit logic configuration file is used to implement the FPGA structure as a trusted execution environment of the blockchain node;

The client receives the authentication result returned by the FPGA structure, the authentication result is signed by the authentication root key deployed in the FPGA structure, and the public key corresponding to the authentication root key is made public;

The client confirms that the circuit logic configuration file is successfully deployed on the FPGA structure when the authentication result passes the signature verification and the authentication result includes content related to the circuit logic configuration file.
According to the method of claim 1, the authentication root key is preset in the FPGA structure; or, the authentication root key is deployed by the client or other objects in the offline security environment to the In the FPGA structure.
The method according to claim 1, wherein the deployment of the circuit logic configuration file by the client to the FPGA structure at the blockchain node comprises:

The client negotiates a configuration file deployment key with the FPGA structure according to the negotiation information sent by the FPGA structure, so that the client and the FPGA structure respectively determine the configuration file deployment key; The negotiation information is signed by the authentication root key;

The client encrypts the circuit logic configuration file by using the configuration file deployment key, and sends the encrypted circuit logic configuration file to the FPGA structure, so that the FPGA structure deploys the key according to the configuration file Decrypt and deploy the circuit logic configuration file.
The method according to claim 3, wherein the authentication result further includes content related to the deployment key of the configuration file.
The method according to claim 1, further comprising:

The client negotiates the business secret deployment key with the FPGA structure according to the negotiation information sent by the FPGA structure, so that the client and the FPGA structure determine the business secret deployment key; The negotiation information is signed by the authentication root key;

The client encrypts the service key by using the service secret deployment key, and sends the encrypted service key to the FPGA structure, so that the FPGA structure decrypts and deploys according to the service secret deployment key The service key.
The method according to claim 5, wherein the service key comprises: a node private key, and the node public key corresponding to the node private key is disclosed;

Wherein, the node public key is used to encrypt the transaction; or, the node public key and the symmetric key provided by the transaction submitting party are jointly used to encrypt the transaction by means of a digital envelope.
The method according to claim 5, wherein the service key comprises: a service root key, and the service root key or a derived key of the service root key is used to verify data generated in the trusted execution environment The private data is encrypted and stored in the database maintained by the blockchain node.
The method of claim 1, wherein the client includes a key management server.
A method for implementing a privacy blockchain based on FPGA includes:

The FPGA structure deploys a circuit logic configuration file from the client, and the circuit logic configuration file is used to implement the FPGA structure as a trusted execution environment on the blockchain node to which it belongs;

The FPGA structure signs the authentication result through the deployed authentication root key, the authentication result includes content related to the circuit logic configuration file, and the public key corresponding to the authentication root key is disclosed;

The FPGA structure returns the signed authentication result to the client, so that the client passes the signature verification on the authentication result and the authentication result includes content related to the circuit logic configuration file In this case, it is confirmed that the circuit logic configuration file is successfully deployed on the FPGA structure.
According to the method of claim 9, the authentication root key is pre-placed in the FPGA structure; or, the authentication root key is deployed by the client or other objects in the offline security environment to the In the FPGA structure.
The method according to claim 9, wherein the FPGA structure includes a key management chip, and the authentication root key is stored in the key management chip.
The method according to claim 9, wherein the FPGA structure includes an FPGA chip and a memory; wherein the circuit logic configuration file is deployed in the memory, and the FPGA chip reads the circuit from the memory Logical configuration files to achieve related functions.
The method according to claim 12, the memory comprises a non-volatile memory or a fuse memory.
The method according to claim 9, wherein the FPGA structure deploys the circuit logic configuration file from the client, comprising:

The FPGA structure negotiates the configuration file deployment key with the client by sending negotiation information to the client, so that the client and the FPGA structure respectively determine the configuration file deployment key; The negotiation information is signed by the authentication root key;

The FPGA structure receives the encrypted circuit logic configuration file sent by the client, and the encrypted circuit logic configuration file is obtained by encrypting the circuit logic configuration file by the configuration file deployment key;

The FPGA structure decrypts the encrypted circuit logic configuration file according to the file deployment key, and deploys the circuit logic configuration file obtained by decryption.
The method according to claim 14, wherein the authentication result further includes content related to the deployment key of the configuration file.
The method according to claim 9, further comprising:

The FPGA structure sends negotiation information to the client, and negotiates with the client to configure the service secret deployment key, so that the client and the FPGA structure respectively determine the service secret deployment key; wherein, The negotiation information is signed by the authentication root key;

The FPGA structure receives the encrypted service key sent by the client, and the encrypted service key is obtained by encrypting the service key by the service secret deployment key;

The FPGA structure decrypts the encrypted service key according to the service secret deployment key, and deploys the decrypted service key.
The method according to claim 16, wherein the service key comprises: a node private key, and the node public key corresponding to the node private key is disclosed;

Wherein, the node public key is used to encrypt the transaction; or, the node public key and the symmetric key provided by the transaction submitting party are jointly used to encrypt the transaction through a digital envelope.
The method according to claim 16, wherein the service key comprises: a service root key, and the service root key or a derived key of the service root key is used to verify data generated in the trusted execution environment The private data is encrypted and stored in the database maintained by the blockchain node.
The method of claim 9, wherein the client includes a key management server.
A device for implementing a privacy blockchain based on FPGA, including:

The configuration file deployment unit enables the client to deploy a circuit logic configuration file to the FPGA structure at the blockchain node, where the circuit logic configuration file is used to implement the FPGA structure as a trusted execution environment for the blockchain node;

The authentication result receiving unit enables the client to receive the authentication result returned by the FPGA structure, the authentication result being signed by the authentication root key deployed in the FPGA structure, and the public key corresponding to the authentication root key Be made public

A confirmation unit is deployed to enable the client to confirm that the circuit logic configuration file is on the FPGA structure when the authentication result passes the signature verification and the authentication result contains content related to the circuit logic configuration file The deployment was successful.
A device for implementing a privacy blockchain based on FPGA, including:

The configuration file deployment unit enables the FPGA structure to deploy the circuit logic configuration file from the client, where the circuit logic configuration file is used to implement the FPGA structure as a trusted execution environment on the blockchain node to which it belongs;

The authentication result signing unit causes the FPGA structure to sign the authentication result through the deployed authentication root key, the authentication result includes content related to the circuit logic configuration file, and the public authentication root key corresponds to the authentication result. Key is made public;

The authentication result returning unit is configured to enable the FPGA structure to return the signed authentication result to the client, so that the client passes the signature verification on the authentication result and the authentication result includes the circuit logic In the case of configuration file-related content, it is confirmed that the circuit logic configuration file is successfully deployed on the FPGA structure.
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-8 by running the executable instruction.
A computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implements the steps of the method according to any one of claims 1-8.
An electronic device including:

processor;

A memory for storing processor executable instructions;

Wherein, the processor executes the executable instruction to implement the method according to any one of claims 9-19.
A computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of the method according to any one of claims 9-19.