WO2021057168A1 - Procédé et appareil permettant de réaliser une opération de machine virtuelle sur la base d'un réseau fpga - Google Patents
Procédé et appareil permettant de réaliser une opération de machine virtuelle sur la base d'un réseau fpga Download PDFInfo
- Publication number
- WO2021057168A1 WO2021057168A1 PCT/CN2020/100494 CN2020100494W WO2021057168A1 WO 2021057168 A1 WO2021057168 A1 WO 2021057168A1 CN 2020100494 W CN2020100494 W CN 2020100494W WO 2021057168 A1 WO2021057168 A1 WO 2021057168A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- fpga
- configuration file
- bytecode
- key
- deployed
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/30—Profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Definitions
- One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a method and device for implementing virtual machine operations based on FPGA.
- 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.
- TEE Trusted Execution Environment
- 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.
- 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.
- 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).
- one or more embodiments of this specification provide a method and device for implementing virtual machine operations based on FPGA.
- a method for implementing virtual machine operations based on FPGA includes: FPGA structure loads the deployed circuit logic configuration file onto the FPGA chip, so that the FPGA chip A bytecode instruction set CPU is formed on the chip; the FPGA structure transfers the bytecode program of the smart contract to the bytecode instruction set CPU, so that the bytecode instruction set CPU runs the bytecode program,
- the smart contract is related to the transaction received by the blockchain node to which the FPGA structure belongs.
- a method for implementing virtual machine operations based on FPGA including: the bytecode instruction set on the FPGA chip CPU reads the bytecode program of the smart contract, so The bytecode instruction set CPU is formed by the FPGA chip loading the circuit logic configuration file deployed on the FPGA structure to which it belongs; the bytecode instruction set CPU runs the bytecode program, the smart contract and the Related to the transaction received by the blockchain node to which the FPGA structure belongs.
- a device for implementing virtual machine operations based on FPGA which includes: a loading unit that enables the FPGA structure to load the deployed circuit logic configuration file onto the FPGA chip to A bytecode instruction set CPU is formed on the FPGA chip; the transfer unit causes the FPGA structure to transfer the bytecode program of the smart contract to the bytecode instruction set CPU, so that the bytecode instruction set The CPU runs the bytecode program, and the smart contract is related to the transaction received by the blockchain node to which the FPGA structure belongs.
- a device for implementing virtual machine operations based on FPGA including: a reading unit that enables the bytecode instruction set CPU on the FPGA chip to read the words of the smart contract A code program, the bytecode instruction set CPU is formed by the FPGA chip loading a circuit logic configuration file that has been deployed on the FPGA structure to which it belongs; an operating unit that causes the bytecode instruction set CPU to run the bytecode Program, the smart contract is related to the transaction received by the blockchain node to which the FPGA structure belongs.
- an electronic device including: a processor; a memory for storing executable instructions of the processor; wherein the processor runs the executable instructions In order to realize the method as described in the first aspect.
- a computer-readable storage medium 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.
- Fig. 1 is a flowchart of a method for implementing virtual machine operations based on FPGA provided by an exemplary embodiment.
- Fig. 2 is a flowchart of another method for implementing virtual machine operations based on FPGA provided by an exemplary embodiment.
- Fig. 3 is a schematic structural diagram of a blockchain node provided by an exemplary embodiment.
- Fig. 4 is a schematic diagram of forming a functional module on an FPGA chip provided by an exemplary embodiment.
- Fig. 5 is a schematic diagram of newly updateable FPGA board provided by an exemplary embodiment.
- Fig. 6 is a block diagram of a device for implementing virtual machine operations based on FPGA provided by an exemplary embodiment.
- Fig. 7 is a block diagram of another device for implementing virtual machine operations based on FPGA provided by an exemplary embodiment.
- the steps of the corresponding method are not necessarily executed in the order shown and described in this specification.
- the method may include more or fewer steps than described in this specification.
- a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. description.
- Blockchain is generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain.
- 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.
- 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.
- the nodes in the blockchain network may use a solution that combines the blockchain and TEE (Trusted Execution Environment).
- TEE Trusted Execution Environment
- 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.
- TEE has also been rapidly developed and expanded. Compared with the originally proposed concept, the TEE referred to now is a more generalized TEE.
- 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.
- 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.
- enclave also known as an enclave
- the CPU protects data from being stolen.
- a part of the area EPC Enclave Page Cache, enclave page cache or enclave page cache
- the encryption engine MEE Memory Encryption Engine
- the first step in using TEE is to confirm the authenticity of TEE.
- the related technology provides a remote certification mechanism for the above-mentioned SGX technology to prove that the SGX platform on the target device and the challenger have deployed the same configuration file.
- the TEE technology in the related technology is implemented by software or a combination of software and hardware, even if the remote attestation method can indicate to a certain extent that the configuration file deployed in the TEE has not been tampered with, the TEE itself depends on the operation The environment cannot be verified.
- a virtual machine for executing smart contracts needs to be configured in the TEE.
- the instructions executed by the virtual machine are not directly executed, but actually executed corresponding X86 instructions (Assuming that the target device adopts the X86 architecture), which poses a certain degree of security risk.
- this specification proposes a hardware TEE technology based on FPGA implementation.
- FPGA implements hardware TEE by loading circuit logic configuration files. Since the content of the circuit logic configuration file can be checked and verified in advance, and the FPGA is configured and operated completely based on the logic recorded in the circuit logic configuration file, it can be ensured that the hardware TEE implemented by the FPGA has relatively higher security.
- the operating efficiency can be improved.
- Fig. 1 is a flowchart of a method for implementing virtual machine operations based on FPGA provided by an exemplary embodiment. As shown in Figure 1, the method is applied to the FPGA structure and may include steps 102-104.
- Step 102 The FPGA structure loads the deployed circuit logic configuration file onto the FPGA chip to form a bytecode instruction set CPU on the FPGA chip.
- the FPGA chip contains a number of editable hardware logic units. After these hardware logic units are configured via a circuit logic configuration file, they can be implemented as corresponding functional modules to implement corresponding logic functions. Specifically, the circuit logic configuration file can be burned to the FPGA structure based on the form of a bit stream.
- a bytecode instruction set CPU can be formed on the FPGA chip.
- the bytecode instruction set CPU can be used to implement virtual machine logic in related technologies, which is equivalent to the FPGA chip
- the "hardware virtual machine" formed by the above configuration for example, the virtual machine logic may include the execution logic of the Ethereum virtual machine or the execution logic of the WASM virtual machine, etc. This specification does not limit this.
- Step 104 The FPGA structure transmits the bytecode program of the smart contract to the bytecode instruction set CPU, so that the bytecode instruction set CPU runs the bytecode program, the smart contract and the Related to the transaction received by the blockchain node to which the FPGA structure belongs.
- Byte-code is composed of a series of bytes, and each byte can identify an operation. Based on many considerations such as development efficiency and readability, developers may not directly write bytecode programs, but choose a high-level language to write code programs for smart contracts. A code program written in a high-level language is compiled by a compiler to generate a corresponding bytecode program, and then the bytecode program can be deployed to the blockchain. There are many high-level languages supported by Ethereum, such as Solidity, Serpent, and LLL languages.
- the above-mentioned compiler can be deployed on the client, so that the client can use the compiler to compile a code program written in a high-level language into a bytecode program, and then submit it to the blockchain network through a transaction; or, the above-mentioned compilation
- the processor can be deployed at the blockchain node, so that after receiving the transaction submitted by the client, the blockchain node compiles a code program written in a high-level language into a bytecode program through a compiler.
- the contract written in it is very similar to the class in the object-oriented programming language.
- a variety of members can be declared in a contract, including contract state (or state variable), function, and function modifier. , Events, etc.
- the contract state is the value permanently stored in the account storage of the smart contract and is used to save the state of the contract.
- the compilation result of the compiler is, for example, as shown below (/*...*/The part of... is a comment, and if there are Chinese characters after it, it is the corresponding Chinese comment):
- dup2/* copy the second item from the top to the bottom in the stack, so at this time the stack has 1, 0, and 1 data from the top to the top*/
- Solidity code in the above code example is compiled into a corresponding bytecode program, and each bytecode contained in the bytecode program includes a byte-length opcode (Opcode) and the following zero at most Operands (Operands), which are the parameters required by the corresponding operation code during execution.
- Opcode byte-length opcode
- Operaands the following zero at most Operands
- the blockchain node when the above-mentioned bytecode program runs on a virtual machine on a blockchain node, for example, if the blockchain node adopts the X86 architecture, then the blockchain node will execute the bytecode program in the virtual machine. , In fact, through the X86 instruction set to simulate each bytecode contained in the bytecode program.
- the above-mentioned bytecode instruction set CPU is configured on the FPGA chip, so that the bytecode instruction set CPU directly adopts the bytecode instruction set during the execution of the bytecode program.
- the bytecode instructions execute each bytecode contained in the bytecode program, without the need to simulate the execution of the bytecode program through other instruction sets, so that it has a relatively higher processing efficiency.
- the above-mentioned bytecode instruction set CPU maintains a bytecode instruction set, and the bytecode instruction set can include any type of predefined bytecode instructions. For example, add instruction is used to implement addition operation, sub instruction is used to implement subtraction operation, mul instruction is used to implement multiplication operation, div instruction is used to implement division operation, or instruction is used to implement bitwise OR operation, and instruction is used to implement press Bitwise AND operation, xor instruction is used to realize bitwise XOR operation, etc. This manual does not limit this.
- the FPGA structure can obtain the above-mentioned transaction in an encrypted state from the blockchain node, and pass the transaction to the encryption and decryption module on the FPGA chip.
- the encryption and decryption module is formed by the above-mentioned deployed circuit logic configuration file on the FPGA chip, and its formation process is similar to the above-mentioned bytecode instruction set CPU. Then, the FPGA structure obtains the bytecode program according to the decrypted transaction content output by the encryption and decryption module.
- the data field of the transaction content after decryption will contain the code program of the smart contract; if the code program is written in a high-level language, the FPGA structure can also be configured on the FPGA chip through the deployed circuit logic configuration file A compiler is formed on the above, and the code program is compiled into a bytecode program by the compiler.
- the to field of the transaction content after decryption will contain the contract address of the called smart contract, and the FPGA structure can call the corresponding deployed bytecode program based on the contract address; for example, when smart When the contract is deployed at the blockchain node, the FPGA structure can send the aforementioned contract address to the blockchain node, and the blockchain node returns the bytecode program corresponding to the contract address to the FPGA structure.
- a node private key can be deployed on the FPGA structure, and the node public key corresponding to the node private key is in a public state.
- the above transaction can be encrypted and generated by the transaction initiator based on the symmetric key and node public key maintained by itself (for example, randomly generated for each transaction) using a digital envelope method: the transaction initiator encrypts the plaintext transaction content through the symmetric key to obtain The ciphertext transaction content, and the above-mentioned symmetric key is encrypted by the node public key to obtain the ciphertext symmetric key, and the above-mentioned transaction includes the ciphertext transaction content and the ciphertext symmetric key.
- the encryption and decryption module first decrypts the ciphertext symmetric key based on the node's private key to obtain the above-mentioned symmetric key, and then decrypts the ciphertext transaction content based on the symmetric key to obtain the above-mentioned plaintext
- the transaction content is the aforementioned decrypted transaction.
- the bytecode instruction set CPU executes the above bytecode program, it can generate the corresponding contract status, transaction receipt and other content.
- the transaction receipt may include information such as the transaction execution result, which needs to be fed back to the transaction initiator.
- the FPGA structure can pass the transaction receipt generated by the bytecode instruction set CPU to the encryption and decryption module, and encrypt it with the symmetric key adopted by the digital envelope, and then encrypt it After that, the transaction receipt is returned to the blockchain node and then provided to the transaction initiator. Since the symmetric key used in the digital envelope is only held 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 safety of the transaction receipt. privacy protection.
- the bytecode program that the FPGA structure needs to execute can be deployed at the blockchain node, then the FPGA structure can request the bytecode program from the blockchain node to form the bytecode on the FPGA chip
- the instruction set is executed in the CPU.
- the blockchain node belongs to the external storage space outside the FPGA chip, and the external storage space can also exist in other forms.
- the FPGA structure can include an external DDR memory connected to the FPGA chip, etc., which can also be used to deploy the above-mentioned bytecode
- the program at this time, can reduce the number of interactions between the FPGA structure and the blockchain node.
- the bytecode program can also be deployed in the on-chip storage space of the FPGA chip.
- the FPGA structure only the FPGA chip is considered a safe environment (TEE based on the FPGA structure), and the environment outside the FPGA chip is considered insecure, so the bytecode program can be deployed in the above-mentioned chip in clear text Storage space, but must be deployed in the above-mentioned external storage space in the form of ciphertext. Therefore, when the FPGA structure obtains the encrypted bytecode program from the external storage space, for example, the encrypted bytecode program can be transferred to the encryption and decryption module on the FPGA chip, and the decrypted output of the encryption and decryption module can be obtained. Bytecode program in order to be executed in the bytecode instruction set CPU.
- the encrypted bytecode program can be obtained by encrypting the bytecode program by the service root key maintained by the FPGA structure or the derived key of the service root key.
- the contract code in plain text can be obtained from the transaction.
- the contract code may be a bytecode program, or when the contract code is written in a high-level language, you can pass The compiler compiles and obtains the corresponding bytecode program.
- the FPGA structure can finally obtain the bytecode program in plain text. Then, the FPGA structure can encrypt the bytecode program through the encryption and decryption module to obtain the encrypted bytecode program.
- the key used is the business root key or the derived key of the business root key. .
- the node private key and service root key described above can be deployed to the FPGA structure by the user. Users can complete the deployment locally or remotely through the client. In the remote deployment process, the client can negotiate with the FPGA structure in advance to obtain the business secret deployment key, and the node private key or business root key can be encrypted and sent to the FPGA structure through the business secret deployment key, and the FPGA structure can be passed through The business secret deployment key decrypts the received data to obtain the node private key or the business root key.
- a key agreement module By loading the deployed circuit logic configuration file onto the FPGA chip, a key agreement module can be formed on the FPGA chip, and the FPGA structure can implement the above-mentioned key agreement operation based on the key agreement module and the client.
- the key agreement process can be implemented using any algorithm or standard in related technologies, which is not limited in this specification.
- the key agreement process can include: the user can generate a key Ka-1 at the local client, the key agreement module can generate a key Kb-1 locally, and the client can generate a key Kb-1 based on the key Ka- 1
- the key agreement module can calculate the key agreement information Kb-2 based on the key Kb-1, and then the client sends the key agreement information Ka-2 to the key agreement module
- the key agreement module sends the key agreement information Kb-2 to the client, so that the client can generate a secret value based on the key Ka-1 and the key agreement information Kb-2, and the key agreement module can be based on the key Kb -1 generates the same secret value as the key agreement information Ka-2, and finally the client and the key agreement module respectively derive the same business secret deployment key from the same secret value based on the key derivation function, and the business secret deployment
- the key can be stored in the FPGA chip or the secret management chip.
- the key agreement information Ka-2 and key agreement information Kb-2 are transmitted between the client and the key agreement module via the blockchain node, the key Ka-1 is controlled by the client , The key Kb-1 is controlled by the key agreement module, so it can ensure that the blockchain node cannot know the final secret value and the business secret deployment key, and avoid possible security risks.
- An authentication root key can be deployed in the FPGA structure, and the authentication root key can be pre-placed in the FPGA structure, or the authentication root key can be deployed to the FPGA structure by the client or other objects in an offline security environment, or the The authentication root key can be remotely deployed into the FPGA structure by the client or other objects.
- the authentication root key is an asymmetric key.
- the key agreement module can sign the generated key agreement information Kb-2 with the authentication root key, and the client can verify the signature to determine whether the received information actually comes from the FPGA structure and has not been transmitted during transmission. Tampered, and the information that fails the signature verification will not be trusted and adopted by the client.
- the public key of the authentication root key can be managed by the authentication server and not made public, then the client can send the received information to the authentication server, and the authentication server can perform signature verification with the maintained public key; then, the authentication The server can provide the client with the verification result, the verification result is signed by the verification server, and the verification result contains the certificate of the verification server or the public key of the verification server can be made public, so that the client can verify the signature to determine the validity of the verification result Sex.
- the public key of the authentication root key can be made public, so that the client can perform signature verification on the information from the FPGA structure based on the public key without going through the authentication server, which can reduce the interactive links in the signature verification process. Thereby improving the efficiency of verification and reducing the security risks caused by more interactive links.
- the aforementioned authentication root key can be deployed to the FPGA structure based on the aforementioned deployed circuit logic configuration file.
- the FPGA structure can avoid taking the authentication root key from 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.
- the FPGA structure can include a key management chip independent of the FPGA chip, and the FPGA structure can take the authentication root key out of the circuit logic configuration file to which it belongs and maintain it in the key management chip, so that only the authentication root key exists In the key management chip, it will no longer appear in the circuit logic configuration file deployed on the FPGA structure to improve the security of the authentication root key.
- the public key or preset certificate corresponding to the client can be deployed on the FPGA structure.
- the client can sign the aforementioned key agreement information Ka-2 and then send it to the FPGA structure, so that the FPGA structure can perform signature verification on the received key agreement information Ka-2, and verify that the signature is based on the key.
- Negotiation information Ka-2 is one of the conditions for generating a secret value.
- the public key or certificate corresponding to the client can be deployed in the FPGA structure by the aforementioned circuit logic configuration file.
- the FPGA structure can also negotiate other keys with the client for use in other scenarios.
- the FPGA structure can negotiate with the client through the key agreement module to obtain the configuration file deployment key, and the process can refer to the above-mentioned negotiation process for the business secret deployment key.
- the FPGA structure can also negotiate to obtain multiple keys at one time; for example, when the key agreement module negotiates with the client to obtain the above-mentioned secret value After that, a 32-bit character string can be derived at one time based on KDF, and the first 16-bit character string and the last 16-bit character string can be used as different keys, such as the configuration file deployment key and the business secret deployment key mentioned above.
- the circuit logic configuration files that have been deployed on the FPGA structure are implemented and updated.
- the FPGA structure receives the encrypted new version of the circuit logic configuration file from the client, it can read the encrypted new version of the circuit logic configuration file into the trusted update module on the FPGA chip for decryption.
- the circuit logic configuration file is formed on the FPGA chip; accordingly, the FPGA structure can update the deployed circuit logic configuration file based on the new version of the circuit logic configuration file obtained by decryption.
- the client can use the above configuration file deployment key to encrypt the new version of the circuit logic configuration file to obtain the encrypted new version of the circuit logic configuration file
- the trusted update module can also encrypt the new version of the circuit logic configuration file based on the above configuration file deployment key.
- the new version of the circuit logic configuration file is decrypted to obtain the new version of the circuit logic configuration file.
- the client can also sign the new version of the circuit logic configuration file before encryption, and the trusted update module can decrypt the new version of the circuit logic configuration file based on the user public key or preset certificate pre-configured on the FPGA structure. Carry out verification. Then, in the case of a decryption failure or a signature verification failure, the trusted update module can terminate the update operation.
- the "new version” is relative to the circuit logic configuration file that has been deployed on the FPGA structure, to indicate that the deployed circuit logic configuration file is configured in the FPGA structure relatively earlier, and It does not mean that the logic or function implemented by the corresponding circuit logic configuration file will necessarily achieve version iteration.
- the circuit logic configuration file can be directly read and configured in the FPGA chip.
- 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.
- 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 ;
- 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. Therefore, when the deployed circuit logic configuration file is located in the memory, the FPGA structure can update and deploy the memory based on the new version of the circuit logic configuration file, so that the deployed circuit logic configuration file in the memory is updated to the new version of the circuit logic configuration file.
- the FPGA structure can generate an authentication result for the new version of the circuit logic configuration file that is updated and deployed, and the authentication result includes content related to the new version of the circuit logic configuration file.
- the above-mentioned content related to the new version of the circuit logic configuration file may be the hash value of the new version of the circuit logic configuration file or a derived value of the hash value; and the client can generate the hash value or the hash value based on the new version of the circuit logic configuration file maintained by itself. If the client receives and generates the same hash value (or its derived value), the client can determine that the new version of the circuit logic file has been successfully deployed to the FPGA structure.
- the FPGA structure can sign the authentication result with the authentication root key and send it to the client, so that the client can confirm that the received authentication result comes from the FPGA structure and has not been tampered with.
- the authentication root key used in the FPGA structure can be provided by the previously deployed circuit logic configuration file; or, when the new version of the circuit logic configuration file contains the new version of the authentication root key, the FPGA structure can be based on the new version of the authentication root key Sign the authentication result.
- the authentication result may also be related to other information.
- the new version of the circuit logic configuration file can be loaded on the FPGA chip to form a new version of the key agreement module, and based on the new version of the key agreement module, the key agreement module can be negotiated with the client. If the new version configuration file deployment key is obtained, the other information mentioned above can be the hash value (or its derivative value) of the new version configuration file deployment key.
- the new version key agreement module negotiates the deployment key of the new version of the configuration file with the client, the authentication root key recently deployed on the FPGA structure is used.
- the authentication root key can come from the previously deployed circuit logic configuration file or the new version of the circuit. Logical configuration file. Among them, when the foregoing deployed circuit logic configuration file and the new version of the circuit logic configuration file on the FPGA structure are not generated and deployed by the same user, the foregoing deployed circuit logic configuration file may be viewed by other users before being burned to the FPGA structure Or check, causing the authentication root key contained in the deployed circuit logic configuration file to be known by other users, which poses a certain security risk. Therefore, deploying a new version of the authentication root key through the new version of the circuit logic configuration file can effectively improve security.
- the FPGA structure can respectively generate the hash value of the new version of the circuit logic configuration file and the hash value of the new version of the configuration file deployment key, and calculate the two hash values through such as sm3 algorithm or other algorithms.
- the calculation result can be used as the above-mentioned content related to the new version of the circuit logic configuration file; accordingly, based on the authentication result, the client can determine that the new version of the circuit logic configuration file is successfully deployed on the FPGA structure, and the client and the FPGA structure are successfully negotiated Get the new version of the configuration file deployment key.
- Fig. 2 is a flowchart of another method for implementing virtual machine operations based on FPGA provided by an exemplary embodiment. As shown in Figure 2, the method is applied to the FPGA structure and may include steps 202-204.
- Step 202 The bytecode instruction set CPU on the FPGA chip reads the bytecode program of the smart contract.
- the bytecode instruction set CPU is formed by loading the FPGA chip to the deployed circuit logic configuration file on the FPGA structure to which it belongs. .
- the FPGA chip contains a number of editable hardware logic units. After these hardware logic units are configured via a circuit logic configuration file, they can be implemented as corresponding functional modules to implement corresponding logic functions. Specifically, the circuit logic configuration file can be burned to the FPGA structure based on the form of a bit stream.
- a bytecode instruction set CPU can be formed on the FPGA chip.
- the bytecode instruction set CPU can be used to implement virtual machine logic in related technologies, which is equivalent to the FPGA chip
- the "hardware virtual machine" formed by the above configuration for example, the virtual machine logic may include the execution logic of the Ethereum virtual machine or the execution logic of the WASM virtual machine, etc. This specification does not limit this.
- the bytecode consists of a series of bytes, and each byte can identify an operation. Based on many considerations such as development efficiency and readability, developers may not directly write bytecode programs, but choose a high-level language to write code programs for smart contracts. A code program written in a high-level language is compiled by a compiler to generate a corresponding bytecode program, and then the bytecode program can be deployed to the blockchain. There are many high-level languages supported by Ethereum, such as Solidity, Serpent, and LLL languages.
- the above-mentioned compiler can be deployed on the client, so that the client can use the compiler to compile a code program written in a high-level language into a bytecode program, and then submit it to the blockchain network through a transaction; or, the above-mentioned compilation
- the processor can be deployed at the blockchain node, so that after receiving the transaction submitted by the client, the blockchain node compiles a code program written in a high-level language into a bytecode program through a compiler.
- each bytecode contained in the bytecode program includes a byte-length opcode and the following zeros at most An operand, which is a parameter required by the corresponding operation code when it is executed.
- the blockchain node when the above-mentioned bytecode program runs on a virtual machine on a blockchain node, for example, if the blockchain node adopts the X86 architecture, then the blockchain node will execute the bytecode program in the virtual machine. , In fact, through the X86 instruction set to simulate each bytecode contained in the bytecode program.
- the above-mentioned bytecode instruction set CPU is configured on the FPGA chip, so that the bytecode instruction set CPU directly adopts the bytecode instruction set during the execution of the bytecode program.
- the defined operation code executes each bytecode contained in the bytecode program without using other instruction sets to simulate the execution of the bytecode program, thereby having relatively higher processing efficiency.
- the FPGA structure can obtain the above-mentioned transaction in an encrypted state from the blockchain node, and pass the transaction to the encryption and decryption module on the FPGA chip.
- the encryption and decryption module is formed by the above-mentioned deployed circuit logic configuration file on the FPGA chip, and its formation process is similar to the above-mentioned bytecode instruction set CPU. Then, the FPGA structure obtains the bytecode program according to the decrypted transaction content output by the encryption and decryption module.
- the data field of the transaction content after decryption will contain the code program of the smart contract; if the code program is written in a high-level language, the FPGA structure can also be configured on the FPGA chip through the deployed circuit logic configuration file A compiler is formed on the above, and the code program is compiled into a bytecode program by the compiler.
- the to field of the transaction content after decryption will contain the contract address of the called smart contract, and the FPGA structure can call the corresponding deployed bytecode program based on the contract address; for example, when the smart When the contract is deployed at the blockchain node, the FPGA structure can send the aforementioned contract address to the blockchain node, and the blockchain node returns the bytecode program corresponding to the contract address to the FPGA structure.
- a node private key can be deployed on the FPGA structure, and the node public key corresponding to the node private key is in a public state.
- the above transaction can be encrypted and generated by the transaction initiator based on the symmetric key and node public key maintained by itself (for example, randomly generated for each transaction) using a digital envelope method: the transaction initiator encrypts the plaintext transaction content through the symmetric key to obtain The ciphertext transaction content, and the above-mentioned symmetric key is encrypted by the node public key to obtain the ciphertext symmetric key, and the above-mentioned transaction includes the ciphertext transaction content and the ciphertext symmetric key.
- the encryption and decryption module first decrypts the ciphertext symmetric key based on the node's private key to obtain the above-mentioned symmetric key, and then decrypts the ciphertext transaction content based on the symmetric key to obtain the above-mentioned plaintext
- the transaction content is the aforementioned decrypted transaction.
- the bytecode program that the FPGA structure needs to execute can be deployed at the blockchain node, then the FPGA structure can request the bytecode program from the blockchain node to form the bytecode on the FPGA chip
- the instruction set is executed in the CPU.
- the blockchain node belongs to the external storage space outside the FPGA chip, and the external storage space can also exist in other forms.
- the FPGA structure can include an external DDR memory connected to the FPGA chip, etc., which can also be used to deploy the above-mentioned bytecode
- the program at this time, can reduce the number of interactions between the FPGA structure and the blockchain node.
- the bytecode program can also be deployed in the on-chip storage space of the FPGA chip.
- the FPGA structure only the FPGA chip is considered a safe environment (TEE based on the FPGA structure), and the environment outside the FPGA chip is considered insecure, so the bytecode program can be deployed in the above-mentioned chip in clear text Storage space, but must be deployed in the above-mentioned external storage space in the form of ciphertext. Therefore, when the FPGA structure obtains the encrypted bytecode program from the external storage space, for example, the encrypted bytecode program can be transferred to the encryption and decryption module on the FPGA chip, and the decrypted output of the encryption and decryption module can be obtained. Bytecode program in order to be executed in the bytecode instruction set CPU.
- the encrypted bytecode program can be obtained by encrypting the bytecode program by the service root key maintained by the FPGA structure or the derived key of the service root key.
- the contract code in plain text can be obtained from the transaction.
- the contract code may be a bytecode program, or when the contract code is written in a high-level language, you can pass The compiler compiles and obtains the corresponding bytecode program.
- the FPGA structure can finally obtain the bytecode program in plain text. Then, the FPGA structure can encrypt the bytecode program through the encryption and decryption module to obtain the encrypted bytecode program.
- the key used is the business root key or the derived key of the business root key. .
- the node private key and service root key described above can be deployed to the FPGA structure by the user. Users can complete the deployment locally or remotely through the client. In the remote deployment process, the client can negotiate with the FPGA structure in advance to obtain the business secret deployment key, and the node private key or business root key can be encrypted and sent to the FPGA structure through the business secret deployment key, and the FPGA structure can be passed through The business secret deployment key decrypts the received data to obtain the node private key or the business root key.
- a key agreement module By loading the deployed circuit logic configuration file onto the FPGA chip, a key agreement module can be formed on the FPGA chip, and the FPGA structure can implement the above-mentioned key agreement operation based on the key agreement module and the client.
- the key agreement process can be implemented using any algorithm or standard in related technologies, which is not limited in this specification.
- the key agreement process can include: the user can generate a key Ka-1 at the local client, the key agreement module can generate a key Kb-1 locally, and the client can generate a key Kb-1 based on the key Ka- 1
- the key agreement module can calculate the key agreement information Kb-2 based on the key Kb-1, and then the client sends the key agreement information Ka-2 to the key agreement module
- the key agreement module sends the key agreement information Kb-2 to the client, so that the client can generate a secret value based on the key Ka-1 and the key agreement information Kb-2, and the key agreement module can be based on the key Kb -1 generates the same secret value as the key agreement information Ka-2, and finally the client and the key agreement module respectively derive the same business secret deployment key from the same secret value based on the key derivation function, and the business secret deployment
- the key can be stored in the FPGA chip or the secret management chip.
- the key agreement information Ka-2 and key agreement information Kb-2 are transmitted between the client and the key agreement module via the blockchain node, the key Ka-1 is controlled by the client , The key Kb-1 is controlled by the key agreement module, so it can ensure that the blockchain node cannot know the final secret value and the business secret deployment key, and avoid possible security risks.
- An authentication root key can be deployed in the FPGA structure, and the authentication root key can be pre-placed in the FPGA structure, or the authentication root key can be deployed to the FPGA structure by the client or other objects in an offline security environment, or the The authentication root key can be remotely deployed into the FPGA structure by the client or other objects.
- the authentication root key is an asymmetric key.
- the key agreement module can sign the generated key agreement information Kb-2 with the authentication root key, and the client can verify the signature to determine whether the received information actually comes from the FPGA structure and has not been transmitted during transmission. Tampered, and the information that fails the signature verification will not be trusted and adopted by the client.
- the public key of the authentication root key can be managed by the authentication server and not made public, then the client can send the received information to the authentication server, and the authentication server can perform signature verification with the maintained public key; then, the authentication The server can provide the client with the verification result, the verification result is signed by the verification server, and the verification result contains the certificate of the verification server or the public key of the verification server can be made public, so that the client can verify the signature to determine the validity of the verification result Sex.
- the public key of the authentication root key can be made public, so that the client can perform signature verification on the information from the FPGA structure based on the public key without going through the authentication server, which can reduce the interactive links in the signature verification process. Thereby improving the efficiency of verification and reducing the security risks caused by more interactive links.
- the aforementioned authentication root key can be deployed to the FPGA structure based on the aforementioned deployed circuit logic configuration file.
- the FPGA structure can avoid taking the authentication root key from 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.
- the FPGA structure can include a key management chip independent of the FPGA chip, and the FPGA structure can take the authentication root key out of the circuit logic configuration file to which it belongs and maintain it in the key management chip, so that only the authentication root key exists In the key management chip, it will no longer appear in the circuit logic configuration file deployed on the FPGA structure to improve the security of the authentication root key.
- the public key or preset certificate corresponding to the client can be deployed on the FPGA structure.
- the client can sign the aforementioned key agreement information Ka-2 and then send it to the FPGA structure, so that the FPGA structure can perform signature verification on the received key agreement information Ka-2, and verify that the signature is based on the key.
- Negotiation information Ka-2 is one of the conditions for generating a secret value.
- the public key or certificate corresponding to the client can be deployed in the FPGA structure by the aforementioned circuit logic configuration file.
- Step 204 the bytecode instruction set CPU runs the bytecode program, and the smart contract is related to the transaction received by the blockchain node to which the FPGA structure belongs.
- the bytecode instruction set CPU executes the above bytecode program, it can generate the corresponding contract status, transaction receipt and other content.
- the transaction receipt may include information such as the transaction execution result, which needs to be fed back to the transaction initiator.
- the FPGA structure can pass the transaction receipt generated by the bytecode instruction set CPU to the encryption and decryption module, and encrypt it with the symmetric key adopted by the digital envelope, and then encrypt it After that, the transaction receipt is returned to the blockchain node and then provided to the transaction initiator. Since the symmetric key used in the digital envelope is only held 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 safety of the transaction receipt. privacy protection.
- the FPGA structure can also negotiate other keys with the client for use in other scenarios.
- the FPGA structure can negotiate with the client through the key agreement module to obtain the configuration file deployment key, and the process can refer to the above-mentioned negotiation process for the business secret deployment key.
- the FPGA structure can also negotiate to obtain multiple keys at one time; for example, when the key agreement module negotiates with the client to obtain the above-mentioned secret value After that, a 32-bit character string can be derived at one time based on KDF, and the first 16-bit character string and the last 16-bit character string can be used as different keys, such as the configuration file deployment key and the business secret deployment key mentioned above.
- the circuit logic configuration files that have been deployed on the FPGA structure are implemented and updated.
- the FPGA structure receives the encrypted new version of the circuit logic configuration file from the client, it can read the encrypted new version of the circuit logic configuration file into the trusted update module on the FPGA chip for decryption.
- the circuit logic configuration file is formed on the FPGA chip; accordingly, the FPGA structure can update the deployed circuit logic configuration file based on the new version of the circuit logic configuration file obtained by decryption.
- the client can use the above configuration file deployment key to encrypt the new version of the circuit logic configuration file to obtain the encrypted new version of the circuit logic configuration file
- the trusted update module can also encrypt the new version of the circuit logic configuration file based on the above configuration file deployment key.
- the new version of the circuit logic configuration file is decrypted to obtain the new version of the circuit logic configuration file.
- the client can also sign the new version of the circuit logic configuration file before encryption, and the trusted update module can decrypt the new version of the circuit logic configuration file based on the user public key or preset certificate pre-configured on the FPGA structure. Carry out verification. Then, in the case of a decryption failure or a signature verification failure, the trusted update module can terminate the update operation.
- the "new version” is relative to the circuit logic configuration file that has been deployed on the FPGA structure, to indicate that the deployed circuit logic configuration file is configured in the FPGA structure relatively earlier, and It does not mean that the logic or function implemented by the corresponding circuit logic configuration file will necessarily achieve version iteration.
- the circuit logic configuration file can be directly read and configured in the FPGA chip.
- 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.
- 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 ;
- 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. Therefore, when the deployed circuit logic configuration file is located in the memory, the FPGA structure can update and deploy the memory based on the new version of the circuit logic configuration file, so that the deployed circuit logic configuration file in the memory is updated to the new version of the circuit logic configuration file.
- the FPGA structure can generate an authentication result for the new version of the circuit logic configuration file that is updated and deployed, and the authentication result includes content related to the new version of the circuit logic configuration file.
- the above-mentioned content related to the new version of the circuit logic configuration file may be the hash value of the new version of the circuit logic configuration file or a derived value of the hash value; and the client can generate the hash value or the hash value based on the new version of the circuit logic configuration file maintained by itself. If the client receives and generates the same hash value (or its derived value), the client can determine that the new version of the circuit logic file has been successfully deployed to the FPGA structure.
- the FPGA structure can sign the authentication result with the authentication root key and send it to the client, so that the client can determine that the received authentication result comes from the FPGA structure and has not been tampered with.
- the authentication root key used in the FPGA structure can be provided by the previously deployed circuit logic configuration file; or, when the new version of the circuit logic configuration file contains the new version of the authentication root key, the FPGA structure can be based on the new version of the authentication root key Sign the authentication result.
- the authentication result may also be related to other information.
- the new version of the circuit logic configuration file can be loaded on the FPGA chip to form a new version of the key agreement module, and based on the new version of the key agreement module, the key agreement module can be negotiated with the client. If the new version configuration file deployment key is obtained, the other information mentioned above can be the hash value (or its derivative value) of the new version configuration file deployment key.
- the new version key agreement module negotiates the deployment key of the new version of the configuration file with the client, the authentication root key recently deployed on the FPGA structure is used.
- the authentication root key can come from the previously deployed circuit logic configuration file or the new version of the circuit. Logical configuration file. Among them, when the foregoing deployed circuit logic configuration file and the new version of the circuit logic configuration file on the FPGA structure are not generated and deployed by the same user, the foregoing deployed circuit logic configuration file may be viewed by other users before being burned to the FPGA structure Or check, causing the authentication root key contained in the deployed circuit logic configuration file to be known by other users, which poses a certain security risk. Therefore, deploying a new version of the authentication root key through the new version of the circuit logic configuration file can effectively improve security.
- the FPGA structure can respectively generate the hash value of the new version of the circuit logic configuration file and the hash value of the new version of the configuration file deployment key, and calculate the two hash values through such as sm3 algorithm or other algorithms.
- the calculation result can be used as the above-mentioned content related to the new version of the circuit logic configuration file; accordingly, based on the authentication result, the client can determine that the new version of the circuit logic configuration file is successfully deployed on the FPGA structure, and the client and the FPGA structure are successfully negotiated Get the new version of the configuration file deployment key.
- Fig. 3 is a schematic structural diagram of a blockchain node provided by an exemplary embodiment.
- an FPGA structure can be added to the blockchain node to implement hardware TEE.
- the FPGA structure can be an FPGA board as shown in FIG. 3.
- the FPGA board can be connected to the blockchain node through the PCIE interface to realize the data interaction between the FPGA board and the blockchain node.
- FPGA boards can include FPGA chips, Flash (flash memory) chips, and dense tube chips; of course, in addition to FPGA chips in some embodiments, they may only include parts of the remaining Flash chips and dense tube chips. , Or may contain more structures, here are just examples.
- no user-defined logic is programmed on the FPGA chip, which is equivalent to the FPGA chip in a blank state.
- Users can burn circuit logic configuration files on the FPGA chip to form corresponding functions or logic on the FPGA chip.
- the FPGA board does not have the capability of security protection, so it usually needs to provide an external security environment.
- users can implement the programming of the circuit logic configuration file in an offline environment to achieve physical security isolation. Instead of implementing remote programming online.
- the corresponding logic code can be formed through FPGA hardware language, and then the logic code can be mirrored to obtain the above-mentioned circuit logic configuration file.
- the user can check the above-mentioned logic code. Especially, when multiple users are involved at the same time, multiple users can check the above logic code separately to ensure that the FPGA board can finally meet the needs of all users and prevent security risks, logic errors, fraud and other abnormalities. problem.
- the user can burn the circuit logic configuration file to the FPGA board in the above-mentioned offline environment.
- the circuit logic configuration file is transferred from the blockchain node to the FPGA board, and then deployed to the Flash chip as shown in Figure 3, so that even if the FPGA board is powered off, the Flash chip can still save the above-mentioned circuit logic. Configuration file.
- Fig. 4 is a schematic diagram of forming a functional module on an FPGA chip provided by an exemplary embodiment.
- the hardware logic unit contained in the FPGA chip can be configured to form corresponding functional modules on the FPGA chip.
- the formed functional modules can include such The key agreement module, decryption and signature verification module, encryption and decryption module, plaintext calculation module, etc. shown in Figure 4.
- the circuit logic configuration file can also be used to transmit the information that needs to be stored to the FPGA board.
- the preset certificate can be stored on the FPGA chip, and the authentication root key can be stored in the secret tube chip (the authentication root key can also be Stored on the FPGA chip) and so on.
- the FPGA board can realize remote key agreement with the user.
- the key agreement process can use related technologies. Any algorithm or standard can be implemented, and this specification does not limit it.
- the key agreement process can include: the user can generate a key Ka-1 at the local client, the key agreement module can generate a key Kb-1 locally, and the client can generate a key Kb-1 based on the key Ka- 1 Calculate the key agreement information Ka-2, the key agreement module can calculate the key agreement information Kb-2 based on the key Kb-1, and then the client sends the key agreement information Ka-2 to the key agreement module, The key agreement module sends the key agreement information Kb-2 to the client, so that the client can generate a secret value based on the key Ka-1 and the key agreement information Kb-2, and the key agreement module can be based on the key Kb -1 generates the same secret value as the key agreement information Ka-2, and finally the client and the key agreement module respectively derive the same
- the key agreement information Ka-2 and key agreement information Kb-2 are transmitted between the client and the key agreement module via the blockchain node
- the key Ka-1 is controlled by the client
- the key Kb-1 is controlled by the key agreement module, so it can ensure that the blockchain node cannot know the final secret value and the configuration file deployment key, so as to avoid possible security risks.
- the secret value is also used to derive the business secret deployment key; for example, the secret value can be derived as a 32-bit value, the first 16 bits can be used as the configuration file deployment key, and the last 16 bits can be used as the business secret deployment Key.
- the user can deploy the service key to the FPGA board through the service secret deployment key.
- the service key may include the node private key and the service root key.
- the user can use the business secret deployment key on the client to sign, encrypt the node private key or the business root key, and send it to the FPGA board, so that after the FPGA board is decrypted and verified through the decryption verification module, Deploy the obtained node private key or service root key.
- the FPGA board can be implemented as a TEE on the blockchain node to meet privacy requirements. For example, when a blockchain node receives a transaction, if the transaction is a plaintext transaction, the blockchain node can directly process the plaintext transaction, if the transaction is a private transaction, the blockchain node transmits the private transaction to the FPGA The board is processed.
- the transaction content of a plaintext transaction is in plaintext form, and the contract status generated after the transaction is executed is also stored in plaintext form.
- the transaction content of a private transaction is in the form of cipher text, which is obtained by encrypting the content of the transaction in plain text by the transaction initiator, and the contract state generated after the transaction is executed needs to be stored in the form of cipher text to ensure the protection of transaction privacy.
- the transaction initiator can generate a symmetric key randomly or based on other methods.
- the business public key corresponding to the above-mentioned business private key is disclosed, then the transaction initiator can perform transaction content in plaintext based on the symmetric key and the business public key.
- the transaction initiator encrypts the plaintext transaction content with a symmetric key, and encrypts the symmetric key with the business public key.
- the two parts obtained are included in the above-mentioned private transaction; in other words, the private transaction includes Two parts of content: the content of the transaction in plaintext encrypted with a symmetric key, and the symmetric key encrypted with the business public key.
- the encryption and decryption module can use the business private key to decrypt the symmetric key encrypted with the business public key to obtain the symmetric key, and then the encryption and decryption module
- the symmetric key is used to decrypt the plaintext transaction content encrypted with the symmetric key to obtain the plaintext transaction content.
- Private transactions can be used to deploy smart contracts, then the data field of the plaintext transaction content can contain the contract code of the smart contract to be deployed; or, the privacy transaction can be used to call the smart contract, then the to field of the plaintext transaction content can contain the called The contract address of the smart contract, and the FPGA board can retrieve the corresponding contract code based on the contract address.
- the plaintext calculation module formed on the FPGA chip is used to implement virtual machine logic in related technologies, that is, the plaintext calculation module is equivalent to the "hardware virtual machine" on the FPGA board. Therefore, after the contract code is determined based on the foregoing plaintext transaction content, the contract code can be passed into the plaintext calculation module, so that the plaintext calculation module executes the contract code. After the execution is completed, the state of the contract involved in the contract code may be updated.
- the encryption and decryption module can encrypt the updated contract state through the aforementioned business root key or its derivative key, and store the encrypted contract state to ensure privacy
- the transaction-related data is only in the clear text state in the FPGA chip and in the cipher text state outside the FPGA chip, so as to ensure the security of the data.
- the plaintext calculation module can be the bytecode instruction set CPU in this manual.
- the FPGA board can read the bytecode program of the smart contract into words
- the code instruction set CPU enables the bytecode instruction set CPU to directly execute each bytecode contained in the bytecode program, without the need to simulate the bytecode through other instruction sets, which greatly improves the performance of the bytecode. Execution efficiency, thereby speeding up transaction processing.
- the user may want to update the version of the circuit logic configuration file deployed on the FPGA board.
- the authentication root key contained in the circuit logic configuration file may be known by risky users, or the user wants to update the version on the FPGA board.
- the deployed functional modules are upgraded, etc. This manual does not limit this.
- the circuit logic configuration file that has been deployed in the above process can be referred to as the old version of the circuit logic configuration file, and the circuit logic configuration file that needs to be deployed is referred to as the new version of the circuit logic configuration file.
- the user can generate a new version of the circuit logic configuration file through the process of writing code and mirroring. Further, the user can sign the new version of the circuit logic configuration file with his own private key, and then encrypt the signed new version of the circuit logic configuration file with the configuration file deployment key negotiated above to obtain the encrypted new version of the circuit Logical configuration file. In some cases, there may be multiple users at the same time, so the old version of the circuit logic configuration file needs to deploy the preset certificates corresponding to these users to the FPGA board, and these users need to use their own private keys to pair the new version of the circuit. Sign the logical configuration file.
- Fig. 5 is a schematic diagram of newly updateable FPGA board provided by an exemplary embodiment.
- the decryption verification module formed on the FPGA chip in the foregoing process is located on the transmission path between the PCIE interface and the Flash chip, so that the new version of the circuit logic configuration file after encryption must first go through the decryption verification module. After processing, it can be transferred to the Flash chip to achieve a credible update, and the Flash chip cannot be updated directly without bypassing the decryption and verification process.
- the decryption verification module After the decryption verification module receives the encrypted new version of the circuit logic configuration file, it first decrypts it with the configuration file deployment key deployed on the FPGA board. If the decryption is successful, the decryption verification module is further based on the preset certificate deployed on the FPGA chip , To perform signature verification on the decrypted new version of the circuit logic configuration file.
- the decryption and signature verification module will trigger the termination of the update operation; and if the decryption is successful and the signature verification is passed, you can It is determined that the obtained new version of the circuit logic configuration file is from the aforementioned user and has not been tampered with during the transmission process.
- the new version of the circuit logic configuration file can be further transmitted to the Flash chip to update and deploy the old version of the circuit logic configuration file in the Flash chip.
- the above-mentioned key agreement module, decryption and verification module can also be formed on the FPGA chip, and the pre-set certificate and authentication can be stored in the FPGA chip. Root key and other information.
- the formed key agreement module, decryption verification module, etc., the implemented functional logic can be changed and upgraded, and the information stored in the deployed preset certificate, authentication root key and other information may also be different from the information before the update .
- the FPGA board can remotely negotiate with the user to obtain a new configuration file deployment key based on the updated key agreement module, authentication root key, etc., and the configuration file deployment key can be used for the next renewal Update process. Similarly, a reliable update operation for FPGA boards can be continuously implemented accordingly.
- the FPGA board can generate certification results for the new version of the circuit logic configuration file.
- the above-mentioned key agreement module can calculate the hash value of the new version of the circuit logic configuration file and the hash value of the configuration file deployment key negotiated based on the new version of the circuit logic configuration file through an algorithm such as sm3 or other algorithms.
- the calculation result can be used as the above-mentioned authentication result, and the key agreement module sends the authentication result to the user.
- the user can verify the authentication result on the client based on the maintained new version of the circuit logic configuration file and the configuration file deployment key negotiated accordingly. If the verification is successful, it indicates that the new version of the circuit logic configuration file is successful on the FPGA board. Deployed, and the user and the FPGA board successfully negotiated accordingly to obtain a consistent configuration file deployment key, thereby confirming the successful completion of the circuit logic configuration file update deployment.
- Fig. 6 is a schematic structural diagram of a device for implementing virtual machine operations based on FPGA provided by an exemplary embodiment.
- the device for implementing virtual machine operations based on FPGA may include: a loading unit 601, which enables the FPGA structure to load the deployed circuit logic configuration file onto the FPGA chip to load the FPGA chip
- the bytecode instruction set CPU is formed on the upper; the transfer unit 602 enables the FPGA structure to transfer the bytecode program of the smart contract to the bytecode instruction set CPU, so that the bytecode instruction set CPU runs the Bytecode program, the smart contract is related to the transaction received by the blockchain node to which the FPGA structure belongs.
- obtaining the bytecode program by the FPGA structure includes: the FPGA structure obtains the transaction in an encrypted state from the blockchain node; and the FPGA structure transmits the transaction to the office
- the encryption and decryption module on the FPGA chip, the encryption and decryption module is formed by the deployed circuit logic configuration file on the FPGA chip; the FPGA structure is obtained according to the decrypted transaction content output by the encryption and decryption module
- the bytecode program includes: the FPGA structure obtains the transaction in an encrypted state from the blockchain node; and the FPGA structure transmits the transaction to the office
- the encryption and decryption module on the FPGA chip, the encryption and decryption module is formed by the deployed circuit logic configuration file on the FPGA chip; the FPGA structure is obtained according to the decrypted transaction content output by the encryption and decryption module The bytecode program.
- the transaction is encrypted and generated by the transaction initiator based on the symmetric key and the node public key maintained by itself in a digital envelope mode; wherein the FPGA structure maintains the node private key corresponding to the node public key, Enabling the encryption and decryption module to decrypt the transaction based on the node private key to obtain the decrypted transaction content.
- it further includes: an encryption unit 603, which enables the FPGA structure to transfer the transaction receipt generated by the bytecode instruction set CPU to the encryption and decryption module to perform processing based on the symmetric key adopted by the digital envelope Encryption; a return unit 604 that enables the FPGA structure to return the encrypted transaction receipt to the blockchain node to provide it to the transaction initiator.
- an encryption unit 603 which enables the FPGA structure to transfer the transaction receipt generated by the bytecode instruction set CPU to the encryption and decryption module to perform processing based on the symmetric key adopted by the digital envelope Encryption
- a return unit 604 that enables the FPGA structure to return the encrypted transaction receipt to the blockchain node to provide it to the transaction initiator.
- obtaining the bytecode program by the FPGA structure includes: when the transaction is used to deploy the bytecode program, the FPGA structure extracts the bytecode from the transaction Program; In the case that the transaction is used to call the bytecode program, the FPGA structure extracts the contract address of the smart contract from the transaction, and obtains the deployed word based on the contract address Section code program.
- the bytecode program is deployed in plaintext in the on-chip storage space of the FPGA chip; or, the bytecode program is deployed in ciphertext in an external storage space outside the FPGA chip.
- obtaining the bytecode program by the FPGA structure includes: obtaining an encrypted bytecode program by the FPGA structure; and transmitting the encrypted bytecode program into the FPGA by the FPGA structure
- the encryption and decryption module on the chip, the encryption and decryption module is formed by the deployed circuit logic configuration file on the FPGA chip; the FPGA structure obtains the decrypted bytecode output by the encryption and decryption module program.
- the encrypted bytecode program is obtained by encrypting the bytecode program by a service root key maintained by the FPGA structure or a derived key of the service root key.
- it further includes: a plaintext storage unit 605 to enable the FPGA structure to store the plaintext of the contract state updated after running the bytecode program in the on-chip storage space on the FPGA structure; or, a ciphertext storage unit 606. Enable the FPGA structure to encrypt the updated contract state after the bytecode program runs through the encryption and decryption module, and output the encrypted contract state to an external storage space outside the FPGA structure for storage.
- a plaintext storage unit 605 to enable the FPGA structure to store the plaintext of the contract state updated after running the bytecode program in the on-chip storage space on the FPGA structure
- a ciphertext storage unit 606. Enable the FPGA structure to encrypt the updated contract state after the bytecode program runs through the encryption and decryption module, and output the encrypted contract state to an external storage space outside the FPGA structure for storage.
- the bytecode instruction set CPU is used to implement virtual machine logic.
- the virtual machine logic includes: the execution logic of the Ethereum virtual machine or the execution logic of the WASM virtual machine.
- it further includes: a receiving unit 607 to enable the FPGA structure to receive the encrypted new version of the circuit logic configuration file from the client; a decryption unit 608 to enable the FPGA structure to read the encrypted new version of the circuit logic configuration file into the store
- the trusted update module on the FPGA chip is decrypted, and the trusted update module is formed by the deployed circuit logic configuration file on the FPGA chip; the update unit 609 makes the FPGA structure based on the decrypted new version
- the circuit logic configuration file updates the deployed circuit logic configuration file.
- a negotiation unit 610 which enables the FPGA structure to perform remote negotiation with the client based on the deployed authentication root key to negotiate a configuration file deployment key; wherein, the encrypted new version of the circuit The logic configuration file is decrypted in the newly updateable module by the FPGA structure based on the configuration file deployment key.
- a signature verification unit 611 which enables the FPGA structure to read the encrypted new version of the circuit logic configuration file into the trusted update module for signature verification, and the client has been deployed on the FPGA structure The corresponding preset certificate.
- the updating unit 609 is specifically configured to update the deployed circuit logic configuration file based on the new version of the circuit logic configuration file when the FPGA structure succeeds in signature verification.
- the FPGA structure includes a memory outside the FPGA chip, and the deployed circuit logic configuration file and the new version of the circuit logic configuration file are deployed on the memory.
- Fig. 7 is a schematic structural diagram of another device for implementing virtual machine operations based on FPGA provided by an exemplary embodiment. Please refer to FIG. 7, in the software implementation, the device for implementing virtual machine operations based on FPGA may include a reading unit 701 and an operating unit 702.
- the reading unit 701 enables the bytecode instruction set CPU on the FPGA chip to read the bytecode program of the smart contract, and the bytecode instruction set CPU loads the deployed circuit logic configuration on the FPGA structure to which the FPGA chip belongs. File is formed.
- the running unit 702 enables the bytecode instruction set CPU to run the bytecode program, and the smart contract is related to the transaction received by the blockchain node to which the FPGA structure belongs.
- the reading unit 701 is specifically configured to: in the case that the transaction is used to deploy the bytecode program, make the bytecode instruction set CPU extract the byte from the transaction Code program; in the case that the transaction is used to call the bytecode program, the bytecode instruction set CPU is made to extract the contract address of the smart contract from the transaction, and obtain it based on the contract address The bytecode program that has been deployed.
- the bytecode program is deployed in plaintext in the on-chip storage space of the FPGA chip; or, the bytecode program is deployed in ciphertext in an external storage space outside the FPGA chip.
- the FPGA structure includes a memory outside the FPGA chip, and the deployed circuit logic configuration file is deployed on the memory.
- 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.
- the computer includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.
- processors CPU
- input/output interfaces network interfaces
- memory volatile and non-volatile 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.
- RAM random access memory
- ROM read-only memory
- flash RAM flash memory
- 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.
- 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.
- first information may also be referred to as second information, and similarly, the second information may also be referred to as first information.
- word “if” as used herein can be interpreted as "when” or “when” or "in response to determination”.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Storage Device Security (AREA)
Abstract
La présente invention porte sur un procédé et sur un appareil permettant de réaliser une opération de machine virtuelle sur la base d'un réseau FPGA. Le procédé peut comprendre les étapes suivantes : une structure de réseau FPGA charge un fichier de configuration logique de circuit déployé sur une puce de réseau FPGA de sorte à former une unité CPU d'ensemble d'instructions de code à octets sur la puce de réseau FPGA ; et la structure de réseau FPGA transmet un programme de code à octets d'un contrat intelligent à l'unité CPU d'ensemble d'instructions de code à octets de telle sorte que l'unité CPU d'ensemble d'instructions de code à octets fasse fonctionner le programme de code à octets, le contrat intelligent étant associé à une transaction reçue par un nœud de chaîne de blocs auquel appartient la structure de réseau FPGA.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910914120.5 | 2019-09-25 | ||
CN201910914120.5A CN110750329B (zh) | 2019-09-25 | 2019-09-25 | 基于fpga实现虚拟机运算的方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2021057168A1 true WO2021057168A1 (fr) | 2021-04-01 |
Family
ID=69277107
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2020/100494 WO2021057168A1 (fr) | 2019-09-25 | 2020-07-06 | Procédé et appareil permettant de réaliser une opération de machine virtuelle sur la base d'un réseau fpga |
Country Status (2)
Country | Link |
---|---|
CN (2) | CN110750329B (fr) |
WO (1) | WO2021057168A1 (fr) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110750329B (zh) * | 2019-09-25 | 2020-10-20 | 支付宝(杭州)信息技术有限公司 | 基于fpga实现虚拟机运算的方法及装置 |
CN111770206B (zh) | 2020-08-31 | 2020-12-29 | 支付宝(杭州)信息技术有限公司 | 一种部署智能合约的方法、区块链节点和存储介质 |
CN112364356A (zh) * | 2021-01-11 | 2021-02-12 | 支付宝(杭州)信息技术有限公司 | 一种数据处理设备和方法 |
CN114093465A (zh) * | 2021-10-28 | 2022-02-25 | 广东珠江智联信息科技股份有限公司 | 基于同态加密的医疗图像标注系统及其数据处理方法 |
CN114978950B (zh) * | 2022-06-02 | 2023-10-27 | 江苏新质信息科技有限公司 | 基于fpga、cpu协同的网络算法调用方法及系统 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107103472A (zh) * | 2017-04-26 | 2017-08-29 | 北京计算机技术及应用研究所 | 一种用于区块链的算法处理模块 |
US20190020538A1 (en) * | 2015-12-31 | 2019-01-17 | Amazon Technologies, Inc. | Fpga-enabled compute instances |
CN110750329A (zh) * | 2019-09-25 | 2020-02-04 | 支付宝(杭州)信息技术有限公司 | 基于fpga实现虚拟机运算的方法及装置 |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103959245B (zh) * | 2011-12-02 | 2016-08-24 | 英派尔科技开发有限公司 | 作为服务的集成电路 |
CN105653315B (zh) * | 2015-12-23 | 2019-03-22 | 北京工业大学 | 一种基于区块链技术的节点化操作系统下载方法 |
CN107046542B (zh) * | 2017-04-24 | 2020-04-14 | 杭州云象网络技术有限公司 | 一种在网络级采用硬件实现共识验证的方法 |
US10761877B2 (en) * | 2017-07-21 | 2020-09-01 | Intel Corporation | Apparatuses, methods, and systems for blockchain transaction acceleration |
CN108984471A (zh) * | 2018-06-29 | 2018-12-11 | 四川斐讯信息技术有限公司 | 一种以太坊矿机系统及其挖矿方法 |
CN109034814B (zh) * | 2018-09-14 | 2020-10-16 | 百度在线网络技术(北京)有限公司 | 基于以太坊虚拟机的智能合约处理方法和装置 |
PL3542494T3 (pl) * | 2018-12-29 | 2021-08-23 | Advanced New Technologies Co., Ltd. | System i sposób realizacji umowy wewnętrznej w łańcuchu bloków |
CN110266644B (zh) * | 2019-05-20 | 2021-04-06 | 创新先进技术有限公司 | 结合代码标注与交易类型的收据存储方法和节点 |
-
2019
- 2019-09-25 CN CN201910914120.5A patent/CN110750329B/zh active Active
- 2019-09-25 CN CN202011360855.7A patent/CN112491887B/zh active Active
-
2020
- 2020-07-06 WO PCT/CN2020/100494 patent/WO2021057168A1/fr active Application Filing
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20190020538A1 (en) * | 2015-12-31 | 2019-01-17 | Amazon Technologies, Inc. | Fpga-enabled compute instances |
CN107103472A (zh) * | 2017-04-26 | 2017-08-29 | 北京计算机技术及应用研究所 | 一种用于区块链的算法处理模块 |
CN110750329A (zh) * | 2019-09-25 | 2020-02-04 | 支付宝(杭州)信息技术有限公司 | 基于fpga实现虚拟机运算的方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
CN112491887A (zh) | 2021-03-12 |
CN110750329B (zh) | 2020-10-20 |
CN112491887B (zh) | 2023-06-30 |
CN110750329A (zh) | 2020-02-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2021057168A1 (fr) | Procédé et appareil permettant de réaliser une opération de machine virtuelle sur la base d'un réseau fpga | |
TW202113645A (zh) | 基於區塊鏈的智能合約管理方法及裝置、電子設備 | |
WO2020233642A1 (fr) | Procédé de stockage de reçu conditionnel et nœud qui combinent un marquage de code et une dimension de type | |
WO2020238959A1 (fr) | Procédé et dispositif pour réaliser un chiffrement dynamique en fonction d'une hauteur de bloc | |
WO2021057166A1 (fr) | Procédé et appareil pour mettre en œuvre un appel externe dans un fpga | |
WO2021057181A1 (fr) | Procédé et dispositif de négociation de clés à base de fpga | |
WO2021057184A1 (fr) | Procédé et appareil de fonctionnement efficace pour un processeur de contrat intelligent de sécurité basé sur un fpga | |
WO2020233638A1 (fr) | Procédé et nœud de mémorisation de reçus basés sur un marquage de codes et sur un type de transaction | |
CN110245947B (zh) | 结合交易与用户类型的条件限制的收据存储方法和节点 | |
WO2020233630A1 (fr) | Procédé et nœud de mémorisation de reçus en fonction du type d'utilisateur | |
WO2020233625A1 (fr) | Procédé de stockage de reçus combinant un type d'utilisateur, des conditions de détermination et un nœud | |
WO2020233631A1 (fr) | Procédé et nœud de stockage de reçu basés sur le type de transaction | |
WO2020233624A1 (fr) | Procédé de mémorisation de reçus et nœud utilisant un type de transaction en combinaison avec un type de fonction d'événement | |
WO2020233619A1 (fr) | Procédé et nœud de stockage de reçu en combinaison avec un type d'utilisateur et un type de transaction | |
WO2021057182A1 (fr) | Procédé et appareil de mise à jour de confiance pour logique fpga | |
WO2021057180A1 (fr) | Procédé et dispositif de mise en œuvre de chaîne de blocs de confidentialité basée sur fpga, et dispositif | |
WO2021057167A1 (fr) | Procédé et dispositif de traitement de transaction pour processeur de contrat intelligent sécurisé à base de fpga | |
WO2020233639A1 (fr) | Procédé de stockage de reçus et nœud basés sur l'étiquetage de code et le type de fonction d'événement | |
WO2020238955A1 (fr) | Procédé et appareil pour réaliser un cryptage dynamique sur la base d'un décalage de transaction | |
WO2020233627A1 (fr) | Procédé et nœud de stockage de reçu basés sur de multiples types de dimensions | |
WO2020233629A1 (fr) | Procédé et nœud de stockage de reçu au niveau d'un objet sur la base d'un marquage de code | |
WO2020233633A1 (fr) | Procédé de stockage de reçus et nœud basé sur une condition de détermination | |
CN111612462A (zh) | 区块链中实现隐私保护的方法、节点和存储介质 | |
WO2021057124A1 (fr) | Procédé et dispositif de mise en œuvre de chaîne de blocs de confidentialité à base de fpga | |
WO2020238958A1 (fr) | Procédé et dispositif pour réaliser un chiffrement dynamique basé sur l'ordre de modification d'état de contrat |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 20869549 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 20869549 Country of ref document: EP Kind code of ref document: A1 |