A blockchain smart contract architecture and a design method thereof

Abstract

The application discloses a kind of blockchain smart contract architecture and its design method, belong to blockchain field, including: the interaction of using generic interface implementation and access layer, consensus algorithm layer and account data, smart contract module is generated independent software function module by integrating standard library, trusted check information packing, the call and callback function of mode are passed through function pointer, the call and interaction of smart contract framework and smart contract dynamic library are realized, the interaction of smart contract library and TA is realized by implementing the core logic of smart contract in the form of TA in trusted execution environment, and using the GP specification of Trustzone;Transaction information handled and generated by smart contract is temporarily stored to the transaction cache area, read by consensus algorithm, consensus and finally form new block and fall disk.The application guarantees the execution safety of the core logic of smart contract, optimizes blockchain software architecture, realizes the trusted check and efficient operation of contract, improves programming efficiency.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchains, and more particularly to a blockchain smart contract architecture and a design method thereof. BACKGROUND

[0002] A common smart contract execution environment provides a Turing-complete contract scripting and a blockchain network architecture that can be compiled and deployed at any time, which means maximizing the degree of freedom of function customization, i.e., the ability to respond to various businesses at any time, but also bears the risk of contract vulnerability attacks, reduces the efficiency of contract execution, and increases the complexity of the architecture. The existing smart contract architecture has many deficiencies in scenarios with high requirements for efficiency and security. In terms of security, the lack of standard library support can lead to design flaws and logical errors, and can easily cause security problems such as re-entrant vulnerabilities, short address attacks, and code injection. In terms of openness, smart contracts are all open and transparent, and attackers can analyze the smart contract code. If a code defect is found, the maintainability of the smart contract code of a common blockchain system is poor once it is deployed to the network, which brings many inconveniences to subsequent iterations of the smart contract. In terms of efficiency, the smart contract architecture based on virtual machines and containers has great deficiencies in contract execution efficiency, concurrency, and other aspects, and the limitations on Gas and call stack size make it unsuitable for implementing complex contract logic. SUMMARY

[0003] The present application aims to overcome the deficiencies of the prior art and provide a blockchain smart contract architecture and a design method thereof, which ensures the execution safety of the core logic of the smart contract, optimizes the blockchain software architecture, enables trusted verification and efficient operation of the contract, reduces the learning cost of developers, reduces design flaws and logical errors of the smart contract, and improves programming efficiency.

[0004] The purpose of the present application is achieved by the following scheme:

[0005] A blockchain smart contract architecture includes a smart contract framework, a smart contract dynamic library, a smart contract module, and a transaction cache area. The smart contract framework specifically includes a generic interface. The generic interface is used to interact with the access layer, the consensus algorithm layer, and the ledger data. The smart contract module integrates a standard library and trusted verification information to generate independent software function modules. The smart contract framework and the smart contract dynamic library are called and interacted through the function pointer transmission and callback function mode. The core logic of the smart contract is implemented in the form of a TA in a trusted execution environment, and the GP specification of the Trustzone technology is used to realize the interaction between the smart contract library and the TA. The transaction information processed and generated by the smart contract is temporarily stored in the transaction cache area, read by the consensus algorithm, and finally formed into a new block and written to the disk.

[0006] A design method of a blockchain smart contract architecture, based on the blockchain smart contract architecture as described above, and comprising: an interaction design step of a client application CA and a TA: for the part of the smart contract that needs to be protected, implementation in a trusted execution environment TEE, the TEE being a trusted execution environment that is isolated from the REE and completely independent, for the TA running in the TEE, using a signature to ensure its legitimacy.

[0007] Further, the part of the smart contract that needs to be protected is implemented in a trusted execution environment TEE, the TEE being a trusted execution environment that is isolated from the REE and completely independent, for the TA running in the TEE, using a signature to ensure its legitimacy, comprising the following sub-steps:

[0008] The interaction process of the smart contract and the TA in the TEE environment follows the GP specification implementation of Trustzone, and specifically comprises the following steps:

[0009] 1) TEEC_InitializeContext: initialize the session context, establish a connection between the CA and the TEE, and apply for a memory address from the TEE for data storage and interaction;

[0010] 2) TEEC_OpenSession: establish a session between the CA and the TA for communication between the CA and the TA, which is the starting point of the interaction between the smart contract on the REE side and the smart contract on the TEE side;

[0011] 3) TEEC_InvokeCommand: rely on the established session to send the CA call instruction and parameters to the TA to implement the execution of the TEE-side smart contract logic and the return of the results;

[0012] 4) TEEC_CloseSession: close the session and close the channel between the CA and the TA;

[0013] 5) TEEC_FinalizeContext: release the session context and end the connection between the CA and the TEE.

[0014] Further, the part of the smart contract that needs to be protected is implemented in a trusted execution environment TEE, the TEE being a trusted execution environment that is isolated from the REE and completely independent, for the TA running in the TEE, using a signature to ensure its legitimacy, comprising the following sub-steps:

[0015] Further encapsulation is performed for the communication between the CA and the TEE, specifically comprising the following steps:

[0016] 1) Based on the GP specification, according to the part of the smart contract that needs to be protected and trusted execution, implement the smart contract TA;

[0017] 2) encapsulate TEEC_InitializeContext, TEEC_OpenSession methods into initTee method, through initTee method, complete session establishment and keep when smart contract framework is initialized;

[0018] 3) in the process of smart contract framework running, CA side smart contract and TA side smart contract send command through TEEC_InvokeCommand, pass parameter, complete related method calling and returning in trusted execution environment;

[0019] 4) the session established in step 1) is closed until the main process of blockchain system is ended.

[0020] A design method of a blockchain smart contract architecture, based on the blockchain smart contract architecture as described above, comprising a contract library verification design step:

[0021] The smart contract module is constructed based on a dynamic library, the smart contract is compiled and packaged into an ELF file, the smart contract file includes an ELF header and a smart contract library, the ELF header is used to store the description, version and verification information of the smart contract respectively, the smart contract dynamic library is dynamically loaded through the CGO mechanism of Golang, and the smart contract function is wrapped through the contract framework, the smart contract function is dynamically adapted, and is called by the transaction request from the access layer.

[0022] A design method of a blockchain smart contract architecture, based on the blockchain smart contract architecture as described above, and the core logic of the trust transmission of the smart contract framework to the smart contract library is to confirm whether the smart contract module is trusted by using digital signature and hash algorithm, and to ensure that the components loaded in the starting process are not maliciously tampered, wherein the signature ensures authenticity, and the hash algorithm ensures integrity, and specifically comprising the following steps:

[0023] 1) generate a public-private key pair;

[0024] 2) hash operation is performed on the smart contract library by using a hash algorithm, and the hash value of the smart contract library is calculated;

[0025] 3) the hash value in step 2) is signed by using the private key in the public-private key pair generated in step 1);

[0026] 4) the hash value in step 2) and the signature in step 3) are packaged into the ELF header of the smart contract dynamic library;

[0027] 5) The smart contract framework internally stores the public key in step 1). When loading the smart contract library, first read the signature information and hash information in the ELF header of the smart contract library, use the public key to verify the signature information and hash information, after verification, calculate the hash value of the smart contract library without the ELF header, compare it with the hash value in the ELF header, and if they are consistent, load the smart contract library.

[0028] A design method of a blockchain smart contract architecture, based on the blockchain smart contract architecture as described above, comprising a ledger data operation design step: implementing a ledger data operation buffer queue in the smart contract SDK for caching and rolling back the ledger data operation behavior in the smart contract call. After a successful contract call, the data in the queue is inserted into the transaction cache area on the smart contract framework side through callback. If the call fails, the queue data of this call is emptied.

[0029] Further, the implementation of the ledger data operation buffer queue in the smart contract SDK for caching and rolling back the ledger data operation behavior in the smart contract call, after a successful contract call, the data in the queue is inserted into the transaction cache area on the smart contract framework side through callback. If the call fails, the queue data of this call is emptied, comprising the following sub-steps:

[0030] 1) Building a transaction cache area on the smart contract framework side for storing transactions to be processed by the consensus algorithm;

[0031] 2) Implementing the appendTx method on the smart contract framework side for adding the behavior of modifying the database after the smart contract execution to the transaction cache area;

[0032] 3) Exporting the appendTx function declaration on the smart contract framework side through the export method for calling the callback function in the smart contract SDK;

[0033] 4) Declaring and implementing the setCallBack method on the smart contract SDK side for receiving the pointer of the callback function. The smart contract framework side calls setCallBack to pass the pointer of the callback function appendTx to the smart contract SDK, and the smart contract SDK saves the pointer address;

[0034] 5) Implementing the buffer queue in the smart contract SDK;

[0035] 6) in the smart contract SDK, the increase, deletion and modification methods for the ledger data operation are implemented, the appendTx pointer transmitted in step 4) is combined with the buffer queue implemented in step 5), the increase, deletion and modification methods for the ledger data implemented by the smart contract are first put into the buffer queue, after a complete smart contract method is executed, the information in the buffer queue is called by the appendTx pointer to call the appendTx method of the smart contract framework side, and is put into the transaction buffer area, and if the smart contract is abnormally executed, the buffer queue is directly emptied;

[0036] 7) the query method for the ledger data in the smart contract SDK, the query operation for the ledger data does not need consensus, and the encapsulation of the read operation for the ledger data is implemented in the smart contract SDK.

[0037] Further, in step 4), the pointer of the callback function appendTx transmitted to the smart contract SDK by the smart contract framework side calling setCallBack is specifically: the pointer of the callback function appendTx transmitted to the smart contract SDK by the smart contract framework side calling setCallBack through the CGO mechanism.

[0038] Further, in step 5), the buffer queue implemented in the smart contract SDK is specifically: the buffer queue is implemented in the smart contract SDK by constructing a dynamic array.

[0039] The beneficial effects of the present application include:

[0040] (1) the present application implements the key and general logic of the smart contract through the TrustZone technology, and guarantees the execution safety of the core logic of the smart contract;

[0041] (2) the present application optimizes the software architecture of the blockchain, and trims the smart contract running environment, so that the smart contract execution only depends on the operating system environment;

[0042] (3) the present application realizes the dynamic loading of the smart contract in the form of a library file, and can realize the trusted verification and efficient operation of the contract;

[0043] (4) the present application supports the high-level programming language and the standard library of the smart contract, reduces the learning cost of the developer, reduces the design defects and logic errors of the smart contract, and improves the programming efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0044] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description only constitute some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained from these drawings without creative labor.

[0045] Figure 1 The figure is a schematic diagram of the blockchain smart contract architecture based on the TrustZone technology in the embodiment of the present application.

[0046] Figure 2 The figure is a schematic diagram of the interaction process between the smart contract CA and the TA in the embodiment of the present application.

[0047] Figure 3 The figure is a schematic diagram of the encapsulation of the interaction between the CA and the TA in the embodiment of the present application.

[0048] Figure 4 The figure is a schematic diagram of the dynamically loadable smart contract architecture in the embodiment of the present application.

[0049] Figure 5 The figure is a schematic diagram of the design of the ledger data operation in the embodiment of the present application. DETAILED DESCRIPTION

[0050] All the features disclosed by all the embodiments in the present specification, or all the steps in the methods or processes implied by the present specification, can be combined and / or extended, replaced, unless the features and / or steps are mutually exclusive.

[0051] In view of the technical problems in the background, the inventors of the present application believe that, for the characteristics of specific application scenarios, the target is clear and the business logic is clear, and a blockchain smart contract execution environment for compiling, debugging and deploying by numerous blockchain users is not needed. Therefore, in the present application concept, the dynamically loadable smart contract architecture is designed for the characteristics of the blockchain application in specific application scenarios, the smart contract can be dynamically loaded into the core code of the blockchain software, executed simultaneously with the blockchain software and share hardware resources, and support plug-in and upgrade of the smart contract, provide higher security and execution efficiency, and according to different application scenarios, different blockchain smart contract modules are loaded, which is a technical approach more suitable for the development route of the blockchain in specific application scenarios.

[0052] Therefore, in view of the deficiencies of the existing smart contract architecture in security, maintainability, concurrency and efficiency, and the characteristics of the specific application scenarios of the blockchain, such as clear business logic, the application aims to design a dynamically loadable smart contract framework based on TrustZone technology, which directly loads the smart contract to the core code of the blockchain software, realizes the loadable and plug-in of the smart contract module, the checkable module and the secure contract, and provides a more general development environment and rich support for the development and implementation of the smart contract by using the programming characteristics of the high-level language and the rich standard library support. At the same time, on the basis of realizing the Turing-complete contract, the application provides more efficient contract execution efficiency.

[0053] In the overall design of the embodiment of the application, the fields of blockchain, smart contract and TrustZone technology are involved, and in particular, a blockchain smart contract architecture design scheme based on TrustZone technology is provided. As shown in Figure 1 As shown in the figure, the application realizes the interaction with the access layer, the consensus algorithm layer and the ledger data by designing an adaptable new smart contract framework and using a generic interface. The smart contract module is packaged into an independent software function module by integrating a standard library and trusted verification information, and the calling and interaction of the smart contract framework and the smart contract dynamic library are realized by using the function pointer passing, calling and callback function mode. The core logic of the smart contract is realized in the form of TA (Trusted Application) in the trusted execution environment, and the interaction between the smart contract library and the TA is realized by using the GP (Global Platform) specification of the Trustzone technology. At the same time, the transaction information processed and generated by the smart contract can be temporarily stored in the transaction cache area by constructing the transaction cache area, and the consensus algorithm reads, consensus and finally forms a new block to be written to the disk.

[0054] Specifically, in the CA and TA interaction design of the embodiment of the application, the part of the smart contract logic is realized in the rich execution environment (REE), which is an open and vulnerable environment, and the program running in the environment is called a client application (CA). The part of the smart contract that needs to be protected is realized in the trusted execution environment (TEE), and the TEE is a trusted execution environment isolated from the REE and completely independent of the REE. The TA running in the TEE needs to use signature technology to ensure its legality. As shown in Figure 2 The interaction process between the smart contract and the TA in the TEE environment complies with the GP (Global Platform) specification of the Trustzone technology, and the process is as follows:

[0055] 1) TEEC_InitializeContext: initialize the session context, establish a connection between CA and TEE, apply for memory address from TEE for data storage and interaction.

[0056] 2) TEEC_OpenSession: establish a session between CA and TA, which is used for communication between CA and TA, and is the starting point of interaction between the smart contract on the REE side and the smart contract on the TEE side.

[0057] 3) TEEC_InvokeCommand: send the CA calling instruction and parameters to the TA through the established session, and realize the execution of the TEE side smart contract logic and the return of the result.

[0058] 4) TEEC_CloseSession: close the session and close the channel between CA and TA.

[0059] 5) TEEC_FinalizeContext: release the session context and end the connection between CA and TEE.

[0060] The establishment and release of CA and TEE session have a large overhead, therefore, in the architecture of the present application, further encapsulation is carried out for the communication between CA and TEE, as shown in Figure 3 , which specifically includes the following processes:

[0061] 1) Based on the above GP specification, according to the protected and trusted execution part of the smart contract, the smart contract TA is realized;

[0062] 2) The TEEC_InitializeContext and TEEC_OpenSession methods are encapsulated into the initTee method, and through the initTee method, the establishment and maintenance of the session are completed when the smart contract framework is initialized;

[0063] 3) During the running process of the smart contract framework, the CA side smart contract and the TA side smart contract send commands and pass parameters through TEEC_InvokeCommand, and complete the calling and returning of related methods in the trusted execution environment;

[0064] 4) The session established in step 1) is closed until the main process of the blockchain system is ended.

[0065] In the contract library verification design of the embodiment architecture of the application, the smart contract module is constructed based on a dynamic library, the smart contract is compiled and packaged into an ELF (Executable and Linkable Format) file, the smart contract file can be composed of an ELF header and a smart contract library, the ELF header is used to store the description, version, verification and other information of the smart contract, the smart contract dynamic library is dynamically loaded through the CGO mechanism of Golang, and the smart contract function is wrapped through the contract framework, the smart contract function is dynamically adapted, and the transaction request from the access layer is called.

[0066] As shown in Figure 4 The core logic of the trust transfer from the smart contract framework to the smart contract library is to use a digital signature and a hash algorithm to confirm whether the smart contract module is trusted, and to ensure that the components loaded in the starting process are not maliciously tampered with, wherein the signature ensures authenticity and the hash algorithm ensures integrity.

[0067] The implementation steps are as follows:

[0068] 1) generating a public-private key pair;

[0069] 2) performing hash operation on the smart contract library by using a hash algorithm to calculate the hash value of the smart contract library;

[0070] 3) signing the hash value in step 2 by using the private key in the public-private key pair generated in step 1;

[0071] 4) packaging the hash value in step 2 and the signature in step 3 into the ELF header of the smart contract dynamic library;

[0072] 5) the public key in step 1 is built into the smart contract framework, when the smart contract library is loaded, the signature information and the hash information in the ELF header of the smart contract library are read first, the signature information and the hash information are verified by using the public key, after the verification is legal, the hash value of the smart contract library without the ELF header is calculated, and the hash value is compared with the hash value in the ELF header, if they are consistent, the smart contract library is loaded.

[0073] In the account data operation design of the embodiment architecture of the application, the read and write of the account data in the smart contract are the key to the execution logic of the smart contract, and unlike the traditional database read and write operation, the operation on the data is not directly reflected to the database, but needs to be agreed by the consensus algorithm before being written to the disk, and the operation of the abnormal behavior also needs to be rolled back. Therefore, the account data operation buffer queue is implemented in the smart contract SDK to realize the caching and rollback of the account data operation behavior in the smart contract call. After the successful execution of a contract call, the data in the queue is inserted into the transaction cache area on the side of the smart contract framework through callback, and if the call fails, the queue data of this call is emptied. The account data operation design is shown in Figure 5 The implementation steps are as follows:

[0074] 1) Construct a transaction cache area on the side of the smart contract framework, and the method is used to store the transactions to be processed by the consensus algorithm;

[0075] 2) Implement the appendTx method on the side of the smart contract framework, which is used to add the behavior of modifying the database after the execution of the smart contract to the transaction cache area;

[0076] 3) Export the appendTx function declaration on the side of the smart contract framework through the export method, which is used to call the callback function in the smart contract SDK;

[0077] 4) Declare and implement the setCallBack method on the side of the smart contract SDK, which is used to receive the pointer of the callback function. The smart contract framework calls the setCallBack to pass the pointer of the callback function appendTx to the smart contract SDK through the CGO mechanism, and the smart contract SDK saves the pointer address;

[0078] 5) Implement the buffer queue in the smart contract SDK by constructing a dynamic array;

[0079] 6) Implement the add, delete, and modify methods of the account data operation in the smart contract SDK through the appendTx pointer passed in step 4 and the buffer queue implemented in step 5. The add, delete, and modify methods of the account data implemented in the smart contract are first put into the buffer queue, and then the information of the buffer queue is called through the appendTx pointer to the appendTx method on the side of the smart contract framework after the execution of a complete smart contract method, and is put into the transaction cache area. If the smart contract execution is abnormal, the buffer queue is directly emptied;

[0080] 7) The query method of the account data in the smart contract SDK, because the query operation on the account data does not need consensus, the read operation of the account data is encapsulated in the smart contract SDK.

[0081] It should be noted that, within the scope of protection defined in the claims of the present application, the following embodiments can be combined and / or extended, replaced in any logical manner from the specific embodiments described above, such as disclosed technical principles, disclosed technical features or implied disclosed technical features, etc.

[0082] Embodiment 1

[0083] A blockchain smart contract architecture includes a smart contract framework, a smart contract dynamic library, a smart contract module and a transaction cache area.

[0084] The smart contract framework specifically includes a generic interface; the generic interface is used to realize interaction with the access layer, the consensus algorithm layer and the ledger data, the smart contract module generates independent software function modules by integrating standard libraries and packaging trusted verification information, realizes the calling and interaction of the smart contract framework and the smart contract dynamic library through the function pointer passing, calling and callback function mode, realizes the interaction of the smart contract library and the TA by implementing the core logic of the smart contract in the form of TA in the trusted execution environment, and using the GP specification of the Trustzone technology.

[0085] The transaction information processed and generated by the smart contract is temporarily stored in the transaction cache area, read by the consensus algorithm, consensus and finally forms a new block.

[0086] Embodiment 2

[0087] A design method of a blockchain smart contract architecture, based on the blockchain smart contract architecture described in Embodiment 1, and including the interaction design steps of the client application CA and the TA:

[0088] For the part of the smart contract that needs to be protected, it is implemented in the trusted execution environment TEE, and the TEE is a trusted execution environment isolated from the REE and completely independent. For the TA running in the TEE, the signature is used to ensure its legality.

[0089] Embodiment 3

[0090] On the basis of Embodiment 2, for the part of the smart contract that needs to be protected, it is implemented in the trusted execution environment TEE, and the TEE is a trusted execution environment isolated from the REE and completely independent. For the TA running in the TEE, the signature is used to ensure its legality, including the following sub-steps:

[0091] The interaction process between the smart contract and the TA in the TEE environment follows the GP specification of Trustzone, specifically including the following steps:

[0092] 1) TEEC_InitializeContext: initialize the session context, establish connection between CA and TEE, apply memory address to TEE for data storage and interaction;

[0093] 2) TEEC_OpenSession: establish a session between CA and TA, used for CA and TA communication, as the starting point of interaction between REE side smart contract and TEE side smart contract;

[0094] 3) TEEC_InvokeCommand: send CA calling instruction and parameters to TA through the established session, implement execution and result return of TEE side smart contract logic;

[0095] 4) TEEC_CloseSession: close the session and close the channel between CA and TA;

[0096] 5) TEEC_FinalizeContext: release the session context and end the connection between CA and TEE.

[0097] Embodiment 4

[0098] On the basis of embodiment 2, the part needing protection in the smart contract is implemented in the trusted execution environment TEE, and the TEE is a trusted execution environment isolated from the REE and completely independent. For the TA running in the TEE, the legality is guaranteed by signature, including the following sub-steps:

[0099] Further encapsulation is carried out for the communication between CA and TEE, including the following steps:

[0100] 1) Based on the GP specification, the smart contract TA is implemented according to the part of the smart contract needing protection and trusted execution;

[0101] 2) The TEEC_InitializeContext and TEEC_OpenSession methods are encapsulated into the initTee method, and the session is established and maintained through the initTee method during the initialization of the smart contract framework;

[0102] 3) During the running of the smart contract framework, the CA side smart contract and the TA side smart contract send commands and pass parameters through TEEC_InvokeCommand, complete the calling and returning of related methods in the trusted execution environment;

[0103] 4) The session established in step 1) is closed until the main process of the blockchain system is ended.

[0104] Embodiment 5

[0105] A design method of a blockchain smart contract architecture, based on the blockchain smart contract architecture described in Embodiment 1, comprising a contract library verification design step:

[0106] The smart contract module is constructed based on a dynamic library, the smart contract is compiled and packaged into an ELF file, the smart contract file comprises an ELF header and a smart contract library, the ELF header is used for storing description, version and verification information of the smart contract respectively, the smart contract dynamic library is dynamically loaded through a CGO mechanism of Golang, and the smart contract function is wrapped through a contract framework, the smart contract function is dynamically adapted, and the transaction request from the access layer is called.

[0107] Embodiment 6

[0108] A design method of a blockchain smart contract architecture, based on the blockchain smart contract architecture described in Embodiment 1, and the core logic of trust transmission from the smart contract framework to the smart contract library is to confirm whether the smart contract module is trusted by using a digital signature and a hash algorithm, so as to ensure that the components loaded in the starting process are not maliciously tampered with, wherein the signature ensures authenticity, and the hash algorithm ensures integrity, and the method comprises the following steps:

[0109] 1) generating a public-private key pair;

[0110] 2) performing hash operation on the smart contract library by using a hash algorithm to calculate the hash value of the smart contract library;

[0111] 3) signing the hash value in step 2) by using the private key in the public-private key pair generated in step 1);

[0112] 4) packing the hash value in step 2) and the signature in step 3) into the ELF header of the smart contract dynamic library;

[0113] 5) the public key in step 1) is built in the smart contract framework, when the smart contract library is loaded, first reading the signature information and hash information in the ELF header of the smart contract library, verifying the signature information and the hash information by using the public key, after verifying the signature information and the hash information, calculating the hash value of the smart contract library without the ELF header, and comparing with the hash value in the ELF header, if consistent, then loading the smart contract library.

[0114] Embodiment 7

[0115] A design method of a blockchain smart contract architecture, based on the blockchain smart contract architecture described in Embodiment 1, comprising an account book data operation design step:

[0116] The ledger data operation buffer queue is implemented in the smart contract SDK, which is used to realize the caching and rollback of the ledger data operation behavior in the smart contract call. After a successful execution of a contract call, the data in the queue is inserted into the transaction cache area on the side of the smart contract framework through callback. If the call fails, the queue data of this call is emptied.

[0117] Embodiment 8

[0118] On the basis of embodiment 7, the ledger data operation buffer queue is implemented in the smart contract SDK, which is used to realize the caching and rollback of the ledger data operation behavior in the smart contract call. After a successful execution of a contract call, the data in the queue is inserted into the transaction cache area on the side of the smart contract framework through callback. If the call fails, the queue data of this call is emptied, including the following sub-steps:

[0119] 1) A transaction cache area is constructed on the side of the smart contract framework, which is used to store transactions to be processed by the consensus algorithm;

[0120] 2) An appendTx method is implemented on the side of the smart contract framework, which is used to add the behavior of modifying the database after the execution of the smart contract to the transaction cache area;

[0121] 3) The appendTx function declaration is exported on the side of the smart contract framework through the export method, which is used to call the callback function in the smart contract SDK;

[0122] 4) The setCallBack method is declared and implemented on the side of the smart contract SDK, which is used to receive the pointer of the callback function. The smart contract framework calls setCallBack to pass the pointer of the callback function appendTx to the smart contract SDK, and the smart contract SDK saves the pointer address;

[0123] 5) The buffer queue is implemented in the smart contract SDK;

[0124] 6) The add, delete, and modify methods of the ledger data operation are implemented in the smart contract SDK. The add, delete, and modify methods of the ledger data implemented by the smart contract are first put into the buffer queue. After the execution of a complete smart contract method, the information in the buffer queue is called through the appendTx pointer to the appendTx method on the side of the smart contract framework and put into the transaction cache area. If the smart contract execution is abnormal, the buffer queue is directly emptied;

[0125] 7) The query method of the ledger data in the smart contract SDK does not need consensus. The read operation of the ledger data is encapsulated in the smart contract SDK.

[0126] Embodiment 9

[0127] On the basis of Embodiment 8, in step 4), the smart contract framework side calls setCallBack to pass the pointer of the callback function appendTx to the smart contract SDK, specifically: the smart contract framework side calls setCallBack to pass the pointer of the callback function appendTx to the smart contract SDK through the CGO mechanism.

[0128] Embodiment 10

[0129] On the basis of Embodiment 8, in step 5), the buffer queue implemented in the smart contract SDK is specifically implemented in the smart contract SDK by constructing a dynamic array.

[0130] The units described in the embodiments of the present application can be implemented in the form of software, or can be implemented in the form of hardware, and the described units can also be arranged in a processor. In some cases, the names of these units do not constitute a limitation on the units themselves.

[0131] According to an aspect of the embodiments of the present application, a computer program product or computer program is provided, which includes computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions to enable the computer device to perform the methods provided in the various optional implementation manners described above.

[0132] As another aspect, the embodiments of the present application also provide a computer readable medium, which can be included in the electronic device described in the above embodiments, or can exist separately without being assembled into the electronic device. The computer readable medium carries one or more programs, which, when executed by the electronic device, enable the electronic device to implement the methods described in the above embodiments.

[0133] The parts not involved in the present application are the same as or can be implemented by the prior art.

[0134] The above technical solutions are only one embodiment of the present application, and for those skilled in the art, on the basis of the application disclosed application methods and principles, various types of improvements or modifications can be easily made, and are not limited to the methods described in the above embodiments, therefore the above description is only preferred, and does not have a limiting meaning.

[0135] In addition to the above examples, other embodiments can be obtained by those skilled in the art based on the above disclosure or by using knowledge or technology in the relevant field, and the features of each embodiment can be interchanged or replaced. Any modification and change made by those skilled in the art without departing from the spirit and scope of the present application shall be within the protection scope of the appended claims of the present application.

Claims

1. A blockchain smart contract architecture, characterized by: Includes smart contract framework, smart contract dynamic library, smart contract module and transaction cache; The smart contract framework specifically includes a generic interface; the generic interface is used to implement interaction with the access layer, consensus algorithm layer, and ledger data. The smart contract module integrates the standard library and trusted verification information to generate an independent software function module. The smart contract framework and the smart contract dynamic library are called and interacted by passing calls and callback functions through function pointers. The core logic of the smart contract is implemented in the form of a TA in a trusted execution environment and uses the Trustzone GP specification to achieve interaction between the smart contract library and the TA. The transaction information processed and generated by the smart contract is temporarily stored in the transaction buffer area, and is read and agreed upon by the consensus algorithm to form a new block and store it on disk; It also includes the interaction design steps between the client application CA and the TA: the parts of the smart contract that need to be protected are implemented in the Trusted Execution Environment (TEE). The TEE is a completely independent and isolated trusted execution environment from the REE. The legitimacy of the TA running in the TEE is guaranteed by signatures. The specific sub-steps include: The interaction process between the smart contract and the TA in the TEE environment follows the Trustzone GP specification and includes the following steps: 1) TEEC_InitializeContext: Initializes the session context, establishes a connection between CA and TEE, and requests memory addresses from TEE for data storage and interaction; 2) TEEC_OpenSession: Establishes a session between the CA and the TA for communication between the CA and the TA, serving as the starting point for interaction between the REE-side smart contract and the TEE-side smart contract; 3) TEEC_InvokeCommand: Relying on the established session, the CA call instruction and parameters are sent to the TA to implement the execution and result return of the smart contract logic on the TEE side; 4) TEEC_CloseSession: closes the session and closes the channel between CA and TA; 5) TEEC_FinalizeContext: Releases the session context and ends the connection between CA and TEE.

2. The blockchain smart contract architecture according to claim 1, characterized in that: The parts of the smart contract that need to be protected are implemented in the Trusted Execution Environment (TEE). TEE is a completely independent and isolated trusted execution environment from REE. The legitimacy of the TA running in the TEE is guaranteed by signature, including the following sub-steps: Further encapsulation is performed for the communication between CA and TEE, including the following steps: 1) Based on the GP specification, implement smart contract TA according to the protection and trusted execution parts of the smart contract; 2) Encapsulate the TEEC_InitializeContext and TEEC_OpenSession methods into the initTee method. When the smart contract framework is initialized, the initTee method is used to establish and maintain the session. 3) During the operation of the smart contract framework, the CA-side smart contract and the TA-side smart contract send commands through TEEC_InvokeCommand, pass parameters, and complete the call and return of relevant methods in the trusted execution environment; 4) The session established in step 1) is closed until the main process of the blockchain system ends.

3. A design method for a blockchain smart contract architecture, characterized in that: The blockchain smart contract architecture according to claim 1 includes the following steps: The smart contract module is built based on the dynamic library method, and the smart contract is compiled and packaged into an ELF file. The smart contract file includes an ELF header and a smart contract library. The ELF header is used to store the description, version, and verification information of the smart contract. The smart contract dynamic library is dynamically loaded through Golang's CGO mechanism, and the smart contract function is packaged through the contract framework. The smart contract function is dynamically adapted for transaction requests from the access layer.

4. A design method for a blockchain smart contract architecture, characterized in that: Based on the blockchain smart contract architecture described in claim 1, the core logic of trust transfer from the smart contract framework to the smart contract library is to use digital signatures and hash algorithms to confirm whether the smart contract module is trustworthy and ensure that the components loaded during the startup process have not been maliciously tampered with. The signature ensures authenticity and the hash algorithm ensures integrity. Specifically, the following steps are included: 1) Generate a public-private key pair; 2) Use the hash algorithm to perform hash operation on the smart contract library to calculate the hash value of the smart contract library; 3) Use the private key from the public-private key pair generated in step 1) to sign the hash value from step 2); 4) Package the hash value from step 2) and the signature from step 3) into the ELF header of the smart contract dynamic library; 5) The smart contract framework has the public key from step 1). When loading the smart contract library, it first reads the signature and hash information in the ELF header of the smart contract library. The signature and hash information are verified using the public key. If the signature is verified to be legitimate, the hash value of the smart contract library without the ELF header is calculated and compared with the hash value in the ELF header. If they are consistent, the smart contract library is loaded.

5. A design method for a blockchain smart contract architecture, characterized in that: The blockchain smart contract architecture according to claim 1 includes the following steps for designing account data operations: The ledger data operation buffer queue is implemented in the smart contract SDK to achieve caching and rollback of ledger data operation behaviors in smart contract calls. After a contract call is successfully executed, all data in the queue are inserted into the transaction buffer area on the smart contract framework side through callback. If the call fails, the queue data of that call is cleared.

6. The design method of blockchain smart contract architecture according to claim 5, characterized in that: The ledger data operation buffer queue is implemented in the smart contract SDK to implement the caching and rollback of ledger data operation behaviors in smart contract calls. After a contract call is successfully executed, all data in the queue are inserted into the transaction buffer area on the smart contract framework side through callback. If the call fails, the queue data of the call is cleared, including sub-steps: 1) Build a transaction cache on the smart contract framework side to store transactions to be processed by the consensus algorithm; 2) Implement the appendTx method on the smart contract framework to add the database modification operations required after the smart contract is executed to the transaction cache; 3) On the smart contract framework side, use the export method to export the appendTx function declaration for callback function calls in the smart contract SDK; 4) Declare and implement the setCallBack method on the smart contract SDK to receive the pointer to the callback function. The smart contract framework calls setCallBack to pass the pointer to the callback function appendTx to the smart contract SDK, and the smart contract SDK saves the pointer address. 5) Implementing a buffer queue in the smart contract SDK; 6) Implement the methods for adding, deleting, and modifying ledger data in the smart contract SDK. This is achieved through the appendTx pointer passed in step 4) and the buffer queue implemented in step 5). The smart contract's methods for adding, deleting, and modifying ledger data are first placed in the buffer queue. After a complete smart contract method is executed, the information in the buffer queue is called through the appendTx pointer on the smart contract framework side and placed in the transaction buffer. If the smart contract execution fails, the buffer queue is directly cleared. 7) The method for querying ledger data in the smart contract SDK does not require consensus for the query operation of ledger data. The encapsulation of the ledger data reading operation is implemented in the smart contract SDK.

7. The design method of blockchain smart contract architecture according to claim 6, characterized in that: In step 4), the smart contract framework side calls setCallBack to pass the pointer of the callback function appendTx to the smart contract SDK. Specifically, the smart contract framework side calls setCallBack through the CGO mechanism to pass the pointer of the callback function appendTx to the smart contract SDK.

8. The design method of blockchain smart contract architecture according to claim 6, characterized in that: In step 5), the implementation of the buffer queue in the smart contract SDK is specifically: implementing the buffer queue by constructing a dynamic array in the smart contract SDK.

Images