A method, device, electronic device and storage medium for maintaining blockchain data
By deploying non-relational and relational databases on blockchain node devices and utilizing the key mechanism of a trusted execution environment, the contradiction between data access efficiency and analysis capabilities in blockchain services is resolved, achieving the dual goals of efficient access and convenient analysis, while also improving data security and disaster recovery capabilities.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-06-29
- Publication Date
- 2026-03-17
AI Technical Summary
In existing blockchain technologies, non-relational databases have high data storage efficiency but weak analytical capabilities, while relational databases have poor online read and write performance, making it difficult to achieve efficient access and convenient data analysis when running blockchain services on blockchain nodes.
Deploy blockchain non-relational databases and blockchain relational databases on node devices, and use key decryption and encryption mechanisms in a trusted execution environment to convert the encrypted data of the non-relational database into standard data of the relational database, thereby achieving dual data backup and convenient analysis.
While ensuring efficient access to blockchain services, it provides convenient data analysis services, improves disaster recovery capabilities, and reduces the risk of data leakage through a trusted execution environment, thus achieving trusted data processing throughout the entire process.
Smart Images

Figure CN115129785B_ABST
Abstract
Description
Technical Field
[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a method, apparatus, electronic device and storage medium for maintaining blockchain data. Background Technology
[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together in a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable.
[0003] In traditional blockchain technology, to meet the storage needs of blockchain nodes for large amounts of data during blockchain service operation, blockchain nodes typically use high-efficiency non-relational databases for data storage. However, non-relational databases lack transaction relationships, resulting in a lack of connections between data and non-standardization, which is detrimental to data analysis. Relational databases, on the other hand, have complete transaction relationships, interconnected data, and a strictly standardized structure. While replacing non-relational databases in traditional blockchain technology with relational databases facilitates data analysis, directly using relational databases in the underlying blockchain system poses a significant challenge to the online read / write performance of blockchain nodes during blockchain service operation. Therefore, how to achieve convenient data analysis services while ensuring high-efficiency access during blockchain service execution is a pressing problem to be solved in this field. Summary of the Invention
[0004] The purpose of this invention is to provide a method, apparatus, electronic device, and storage medium for maintaining blockchain data.
[0005] According to a first aspect of one or more embodiments of this specification, a method for maintaining blockchain data is proposed, applied to a node device deployed with a blockchain node and a first trusted execution environment. The node device maintains a blockchain non-relational database and a blockchain relational database. The blockchain non-relational database is used to maintain encrypted data, which is obtained by encrypting blockchain data generated by the blockchain node when running a blockchain service in a second trusted execution environment using a first key corresponding to the second trusted execution environment. The method includes:
[0006] If the blockchain node passes the remote proof verification corresponding to the first trusted execution environment, the encrypted data maintained in the blockchain non-relational database is obtained.
[0007] In the first trusted execution environment, the encrypted data is decrypted into blockchain data using the first key, and the blockchain data is converted into standard data defined by the database schema information corresponding to the blockchain relational database. Then, the standard data is encrypted into encrypted standard data using the second key corresponding to the first trusted execution environment.
[0008] The encrypted standard data is maintained in the blockchain relational database, which is used to provide data analysis services running in a first trusted execution environment to the analysis requester.
[0009] According to a second aspect of one or more embodiments of this specification, an apparatus for maintaining blockchain data is provided, applied to a node device deployed with a blockchain node and a first trusted execution environment. The node device maintains a blockchain non-relational database and a blockchain relational database. The blockchain non-relational database is used to maintain encrypted data, which is obtained by encrypting blockchain data generated by the blockchain node when running a blockchain service in a second trusted execution environment using a first key corresponding to the second trusted execution environment. The apparatus includes:
[0010] The blockchain data acquisition unit is used to acquire the encrypted data maintained in the blockchain non-relational database when the blockchain node passes the remote proof verification corresponding to the first trusted execution environment.
[0011] A blockchain data acquisition unit is used to decrypt the ciphertext data into blockchain data using a first key in a first trusted execution environment, convert the blockchain data into standard data defined by the database schema information corresponding to the blockchain relational database, and encrypt the standard data into ciphertext standard data using a second key corresponding to the first trusted execution environment.
[0012] A standard data maintenance unit is used to maintain the encrypted standard data in the blockchain relational database, which is used to provide data analysis services running in a first trusted execution environment to the analysis requester.
[0013] According to a third aspect of one or more embodiments of this specification, an electronic device is provided, comprising:
[0014] processor;
[0015] Memory used to store processor-executable instructions;
[0016] The processor implements the method as described in the first aspect by running the executable instructions.
[0017] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in the first aspect.
[0018] This specification's embodiments deploy a blockchain non-relational database and a blockchain relational database on the node device. On one hand, since the blockchain non-relational database maintains ciphertext data obtained by encrypting the blockchain data generated when the blockchain node runs blockchain services, this enables efficient storage and retrieval of encrypted blockchain data when the blockchain node runs blockchain services. On the other hand, by decrypting, converting, and encrypting the ciphertext data maintained from the blockchain non-relational database into ciphertext standard data and simultaneously maintaining it in the blockchain relational database, convenient data analysis services can be achieved using the blockchain relational database. Furthermore, both the blockchain services run by the blockchain node and the process of decrypting, converting, and encrypting ciphertext data by the node device are performed within the corresponding trusted execution environment. Simultaneously, before providing ciphertext data, the blockchain node needs to verify the remote proof corresponding to the first trusted execution environment, thereby ensuring system-level data security for data processing, data transmission, and data storage. The method for maintaining blockchain data described in the embodiments of this specification achieves two backups of the same data, which objectively improves disaster recovery capabilities and enables convenient data analysis services while ensuring efficient access during the execution of blockchain services. At the same time, due to the integration of trusted execution environment technology, it realizes a trusted data flow and trusted data processing process from on-chain blockchain services to off-chain data conversion and data analysis services, minimizing the risk of data leakage. Attached Figure Description
[0019] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0020] Figure 1 This is a flowchart illustrating a method for maintaining blockchain data, provided in an exemplary embodiment.
[0021] Figure 2 This is an exemplary embodiment of a system architecture diagram for maintaining blockchain data.
[0022] Figure 3 This is a schematic diagram of the structure of a device provided in an exemplary embodiment.
[0023] Figure 4 This is a block diagram of an apparatus for maintaining blockchain data, provided in an exemplary embodiment. Detailed Implementation
[0024] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.
[0025] Figure 1 This is a flowchart illustrating a method for maintaining blockchain data, provided in an exemplary embodiment. The method is applied to a node device deployed with a blockchain node and a first trusted execution environment. The node device maintains a blockchain non-relational database and a blockchain relational database. The blockchain non-relational database is used to maintain encrypted data, which is obtained by encrypting blockchain data generated by the blockchain node when running a blockchain service in a second trusted execution environment using a first key corresponding to the second trusted execution environment. The method includes:
[0026] S102: If the blockchain node passes the remote proof verification corresponding to the first trusted execution environment, the encrypted data maintained in the blockchain non-relational database is obtained.
[0027] Figure 2 This is an exemplary embodiment providing a system architecture diagram for maintaining blockchain data. For example... Figure 2 As shown, each blockchain node in the blockchain network is deployed on a corresponding node device. Each node device maintains both a blockchain non-relational database and a blockchain relational database. Simultaneously, the node device also deploys a first trusted execution environment (TEE) and a second trusted execution environment. In the embodiments of this specification, the blockchain non-relational database is a non-relational database, while the blockchain relational database is a relational database. Furthermore, the second trusted execution environment is used to handle the blockchain node's operation of blockchain services, while the first trusted execution environment is used to handle the node device's operation of data analysis services. The first trusted execution environment also handles the node device's decryption, transformation, and re-encryption of encrypted data. Specifically, the node device has a data transformation engine and a data analysis engine deployed off-chain within the first trusted execution environment. The data transformation engine performs the decryption, transformation, and re-encryption of encrypted data, while the data analysis engine runs data analysis services.
[0028] In the embodiments of this specification, data within the trusted execution environment needs to be in plaintext. However, when data leaves the domain, i.e., when it needs to be output outside the trusted execution environment, it needs to be encrypted and in ciphertext. Therefore, the trusted execution environment maintains a corresponding key for encrypting internal data and outputting it externally, or for reading ciphertext from the outside and decrypting it back to plaintext internally. Typically, the key corresponding to the trusted execution environment is a symmetric key. For example, in the embodiments of this specification, the first trusted execution environment maintains a second key for encryption and decryption during data retrieval from a blockchain non-relational database, while the second trusted execution environment maintains a first key for encryption and decryption during data retrieval from a blockchain relational database.
[0029] On the one hand, the blockchain non-relational database, as the native database for blockchain nodes to run blockchain services, is part of the underlying infrastructure of the blockchain system. It is used to efficiently access blockchain data generated during the process of blockchain nodes running blockchain services. To ensure data security, when a blockchain node needs to store blockchain data in the blockchain non-relational database, as an alternative to directly storing blockchain data, the blockchain node can first encrypt the blockchain data in a second trusted execution environment to obtain ciphertext data (using the first key corresponding to the second trusted execution environment), and then store the ciphertext data in the blockchain non-relational database. This avoids the risk of data leakage caused by directly storing plaintext data. Of course, in addition to maintaining ciphertext data, the blockchain non-relational database is also used to maintain the blockchain data generated when the blockchain node runs the blockchain service. That is to say, for some blockchain data with low privacy requirements, it can be directly accessed in plaintext in the blockchain non-relational database. Blockchain-based non-relational databases can specifically adopt key-value databases (a typical type of non-relational database, often abbreviated as KV database). Unlike relational databases, KV databases do not know the values of the stored data, and they lack the concept of schema (database schema information) found in MySQL (a relational database management system) and PostgreSQL (a feature-rich free software object-relational database management system). This means that they cannot use SQL (Structured Query Language) with WHERE clauses to filter and query portions of the stored data as relational databases do. If you don't know where to start querying, you need to iterate through all the key values, find the corresponding values, filter them, and ultimately only keep the data you want. This results in a very high computational load, meaning that KV databases can only guarantee high performance when the key is known; otherwise, their performance is significantly insufficient. Therefore, although KV databases outperform relational databases in terms of absolute access speed, the requirement of knowing the key value limits their application scenarios. Although the above description only covers the introduction of KV databases, it is actually applicable to most non-relational databases. In general, non-relational databases have high access speeds but lack data analysis capabilities, such as the ability to query based on indexes and relationships between data.
[0030] In the embodiments of this specification, since the underlying blockchain system deployed on the node device (including blockchain nodes and corresponding blockchain databases) uses a non-relational database with high access speed (i.e., blockchain non-relational database), the blockchain node can efficiently access and retrieve data from the blockchain non-relational database when running blockchain services, thereby ensuring the efficient operation of blockchain services. At the same time, since the stored data is encrypted blockchain data, the security risks caused by data leakage can also be avoided.
[0031] On the other hand, the node devices involved in the embodiments of this specification also additionally maintain a blockchain relational database as the native database for providing data analysis services to users, that is, as part of the infrastructure of the data analysis system, used to provide data analysis services to those with analysis needs. For example, the blockchain non-relational database can specifically adopt relational databases such as Oracle and MySQL. A relational database refers to a database that uses a relational model to organize data. It stores data in the form of rows and columns for easy user understanding. This series of rows and columns in a relational database is called a table, and a group of tables makes up the database. Users retrieve data from the database through queries, and a query is an executable code used to limit certain areas in the database. The relational model can be simply understood as a two-dimensional table model. A relational database is a data organization composed of two-dimensional tables and the relationships between them. Relational databases require pre-defining table structures, table relationships, and normalized data structures—the database schema information—before storing data according to this schema. They support SQL and have powerful data analysis capabilities. However, because relational databases heavily emphasize data consistency, they pay a significant price in terms of reduced read / write performance. While relational databases offer excellent reliability in storing and processing data, their efficiency becomes very poor when dealing with massive amounts of data, especially under high-concurrency read / write operations. In short, relational databases have powerful data analysis capabilities but poor access speed and read / write performance, making them unsuitable for large-scale concurrent read / write applications.
[0032] In the embodiments of this specification, due to the data analysis system (including) deployed off-chain by the node device Figure 2 The data analysis engine and corresponding database (not shown) adopt a non-relational database (i.e., a blockchain relational database) with high access speed. Therefore, when node devices run data analysis services by calling the data analysis engine, they can take advantage of the powerful data analysis capabilities of the blockchain non-relational database, thereby ensuring convenient data analysis services are provided to the analysis requesters.
[0033] The data maintained in the blockchain relational database described in the embodiments of this specification is obtained through data transformation and migration from the blockchain non-relational database. The process of this data transformation and migration will be described in detail below.
[0034] In this embodiment, the node device can only obtain the encrypted data maintained in the blockchain non-relational database if the remote proof corresponding to the first trusted execution environment is verified by the blockchain node. For a blockchain node, it needs to verify the access rights of any data requester seeking data from the blockchain non-relational database. Data is only provided to the data requester if they have the necessary access rights. In this embodiment, the node device (specifically, the data transformation engine deployed on the node device) is considered a data requester. Therefore, the blockchain node needs to verify whether the node device has access rights to the blockchain non-relational database. This embodiment determines whether the node device has access rights to the blockchain non-relational database by verifying the validity of the remote proof corresponding to the first trusted execution environment deployed on the node device. Specifically, the remote proof corresponding to the first trusted execution environment includes a digital signature obtained by the first trusted execution environment using its corresponding CPU private key to sign all programs running in the environment (the hash values corresponding to these programs). After obtaining this remote proof, the blockchain node can verify the digital signature contained in the remote proof using the CPU public key corresponding to the first trusted execution environment maintained locally. If the verification is successful, it can be confirmed that the node device does indeed run the first trusted execution environment and that the programs running in the first trusted execution environment are legitimate, trustworthy, and have not been tampered with, thereby determining that the node device has access to the blockchain's non-relational database; or, the blockchain node in After obtaining the remote proof, if the CPU public key corresponding to the first trusted execution environment is not available, the remote proof can be sent to an authentication third party that holds the CPU public key corresponding to the first trusted execution environment. After verifying the remote proof, the authentication third party returns a corresponding remote authentication report to the blockchain node. If the blockchain node verifies the validity of the remote authentication report using the public key corresponding to the authentication third party, and the remote authentication report is used to indicate the validity of the remote proof, the node node can confirm that the node device does indeed run the first trusted execution environment and that the program running in the first trusted execution environment is legitimate, trustworthy, and has not been tampered with, thereby determining that the node device has access to the blockchain non-relational database.
[0035] In the embodiments of this specification, obtaining the encrypted data maintained in the blockchain non-relational database includes: receiving the encrypted data actively pushed by the blockchain node; and / or sending a blockchain data request to the blockchain node and receiving the encrypted data returned by the blockchain node in response to the blockchain data request.
[0036] The method for maintaining blockchain data described in the embodiments of this specification is applied to node devices, specifically to the data conversion engine deployed off-chain on the node device. The node device can obtain encrypted data maintained in the blockchain non-relational database through at least one of two methods: First, by receiving encrypted data actively pushed by the blockchain node. For example, each time a blockchain node adds or modifies encrypted data in the blockchain non-relational database while running a blockchain service in a second trusted execution environment, the blockchain node actively pushes a data update message carrying the latest added or modified encrypted data to the off-chain data conversion engine. This method can promptly convert and synchronize data in the blockchain non-relational database to the blockchain relational database, thereby ensuring the symmetry and timeliness of data in the blockchain relational database. Second, by sending a blockchain data request to the blockchain node to obtain the encrypted data returned by the blockchain node in response to the blockchain data request. This method obtains encrypted data through a request-response model, which can effectively control the scope of the requested encrypted data and thus shield some data that does not need to be maintained in the blockchain relational database.
[0037] In the embodiments described in this specification, the remote proof is included in the blockchain data request; or, the remote proof is pre-maintained on the blockchain node. When remote authentication is included in the blockchain data request, it is equivalent to the blockchain node verifying the latest remote proof corresponding to the first trusted execution environment, thereby ensuring the timeliness of the remote proof. When the remote proof is pre-maintained on the blockchain node, it is equivalent to the blockchain node being able to determine in advance whether the node device has access to the blockchain non-relational database through the remote proof pre-maintained on the blockchain node. Therefore, it can reduce the intermediate steps in the process of the node device obtaining encrypted data and increase the efficiency of obtaining encrypted data.
[0038] Optionally, sending a blockchain data request to the blockchain node includes: initiating a blockchain data request to a smart contract deployed on the blockchain node for the encrypted data maintained by the smart contract in the blockchain non-relational database; or, initiating a blockchain data request to the blockchain node for the encrypted data maintained in the blockchain non-relational database.
[0039] The blockchain data involved in the embodiments of this specification includes block data, state data, and event data. Block data refers to the blockchain ledger maintained by each blockchain node in the blockchain network. The blockchain ledger and / or the corresponding encrypted data are essentially maintained in a blockchain non-relational database. Because the blockchain ledger is a special data structure, it is composed of multiple blocks linked together by hash anchors, possessing immutability. Each block consists of a block header and a block body. The block header of any block contains information such as the state tree root, transaction root, receipt tree root, block height, and the hash value of the corresponding parent block, while the block body contains the transaction data (transaction hashes) contained in that block. The block data involved in the embodiments of this specification refers to the data contained in the blockchain ledger. The state data and event data involved in the embodiments of this specification are maintained by the various smart contracts deployed by the blockchain nodes. In essence, the state data, event data, and / or the encrypted data corresponding to the state data and event data are maintained in the contract storage space corresponding to each smart contract in the blockchain non-relational database.
[0040] In one embodiment, a blockchain node deploys several smart contracts, each maintaining corresponding state data. This state data is encrypted into ciphertext data using a first key within a second trusted execution environment and maintained in the contract storage space corresponding to each smart contract in the blockchain non-relational database. A node device can initiate a blockchain data request to a smart contract deployed on the blockchain node (in fact, each smart contract is deployed on every blockchain node in the blockchain network). This blockchain data request is formally a blockchain transaction. After being received by the blockchain node, the node further invokes the smart contract indicated by the blockchain transaction to execute the transaction. When executing the blockchain transaction, the smart contract searches for and retrieves the ciphertext data indicated by the blockchain transaction from the contract storage space corresponding to the smart contract in the blockchain non-relational database, and sends this ciphertext data back to the node device as a response message (e.g., in the form of a blockchain event) corresponding to the blockchain data request. This achieves the retrieval of ciphertext data maintained in the blockchain non-relational database by invoking a smart contract.
[0041] In another embodiment, the node device can directly initiate a blockchain data request to the blockchain node, for example, by initiating a blockchain data request through the blockchain node's data query interface. The blockchain data request is used to enable the blockchain node to retrieve the encrypted data indicated by the blockchain data request (obtained by encrypting the block data in the second trusted execution environment with a first key) from the blockchain non-relational database and send it back to the node device.
[0042] In another embodiment, the node device can directly initiate a blockchain data request to the blockchain non-relational database, for example, by initiating a blockchain data request through the database interface of the blockchain non-relational database. In this case, it is equivalent to a local call on the node device off-chain without going through the blockchain node. The blockchain non-relational database directly responds to the received blockchain data request and returns the encrypted data indicating the blockchain data request.
[0043] It is important to note that although blockchain data requests are similar in form to blockchain transactions, they do not necessarily possess all the characteristics of blockchain transactions. For example, after receiving a blockchain data request, a blockchain node may not necessarily conduct consensus within the blockchain network, but rather process it as a local call request. Such blockchain transactions that do not undergo consensus and are executed only within the local blockchain node are called local transactions. Of course, blockchain data requests can also possess all the characteristics of blockchain transactions, that is, after completing consensus within the blockchain network as a consensus transaction, they can be executed separately by each blockchain node in the blockchain network.
[0044] S104: In the first trusted execution environment, the encrypted data is decrypted into blockchain data using the first key, and the blockchain data is converted into standard data defined by the database schema information corresponding to the blockchain relational database. Then, the standard data is encrypted into encrypted standard data using the second key corresponding to the first trusted execution environment.
[0045] After acquiring the encrypted data, the node device reads it into the first trusted execution environment (TEX). Simultaneously, it invokes the data transformation engine running within the TEX to perform decryption, transformation, and encryption tasks related to the encrypted data. Specifically, the node device first decrypts the encrypted data into plaintext data (the aforementioned blockchain data) using a first key. Then, it converts the blockchain data into standard data defined by the database schema information corresponding to the blockchain relational database. Finally, it encrypts the standard data into encrypted standard data using a second key corresponding to the first TEX. Because all of the above processes are implemented within the first TEX, data leakage issues can be effectively avoided, improving system security.
[0046] In the embodiments described in this specification, the first key is provided to the first trusted execution environment deployed on the node device by the blockchain node after the remote proof is verified; alternatively, the first key is pre-maintained in the first trusted execution environment. The first key can be provided to the first trusted execution environment in the node device by the blockchain node in a timely manner upon verification of the remote proof (i.e., when the blockchain node confirms that the node device has access to the blockchain non-relational database), or it can be pre-maintained in the first trusted execution environment. For example, if the node device has historically been confirmed by the blockchain node to have the corresponding access rights and the first key has already been provided to the first trusted execution environment by the blockchain node, then the first trusted execution environment will pre-maintain the first key.
[0047] The database schema information involved in the embodiments of this specification specifically refers to the database schema. A schema is an abstract collection of metadata, containing a set of schema components: primarily the declaration of elements and attributes, and the definition of complex and simple data types. Specifically, it includes: defining elements that can appear in a document; defining attributes that can appear in a document; defining which elements are child elements; defining the order of child elements; defining the number of child elements; defining whether an element is empty or can contain text; defining the data types of elements and attributes; and defining default values and fixed values for elements and attributes. In a database, the schema is the organization and structure of the database. Database schema information contains schema objects, which can be tables, columns, data types, views, stored procedures, relationships, primary keys, foreign keys, etc. Database schema information can be represented by a visual diagram, showing database objects and the relationships between them. Since database schema information is used to describe the structure of a database and can serve as a blueprint for creating a database, specifying the database schema information corresponding to a database can guide how the data in that database is stored.
[0048] After decrypting the blockchain data, the node device will convert the blockchain data into standard data defined by the database schema information corresponding to the blockchain relational database in the first trusted execution environment. This means that the converted standard data can be maintained in the blockchain relational database according to certain rules, and the standard data already has a standardized structure and defined relationships with other data in the blockchain relational database. The conversion process from blockchain data to standard data includes, but is not limited to, the conversion of data tables, rows, and columns. For example, the conversion from blockchain data to standard data is achieved through the ETL (Extract-Transform-Load, a data warehouse technology based on data extraction, transformation, and loading) mechanism. The specific implementation methods are documented in existing technologies and will not be elaborated here. Since the encrypted standard data is obtained by encrypting the standard data, it only desensitizes the numerical values but still retains the structure of the standard data in its original state and the relationships between the standard data and other data in its original state. That is, the encrypted standard data, like the standard data before encryption, can be maintained in the blockchain relational database according to certain rules.
[0049] Optionally, when the blockchain data request is for the encrypted data maintained by the smart contract in the blockchain non-relational database, the method further includes:
[0050] A pattern information query request is initiated to the smart contract, and the first database pattern information recorded in the smart contract returned by the smart contract in response to the pattern information query request is determined as the database pattern information corresponding to the blockchain relational database.
[0051] In the embodiments described in this specification, the database schema information corresponding to the blockchain relational database can be pre-maintained on the node device (e.g., set by the node device's administrator user), or obtained by requesting from the smart contract. As mentioned earlier, since each smart contract deployed on a blockchain node has a corresponding contract storage space in the blockchain non-relational database, and each smart contract has different characteristics in processing, organizing, and storing data, the contract storage space corresponding to different smart contracts in the blockchain non-relational database has different data organization forms. This data organization form includes the data organization format, relationships, and connotations, and it is also maintained in the smart contract in the form of database schema information. Therefore, to correctly handle the different organizational characteristics of encrypted data maintained by different smart contracts in the blockchain non-relational database, this embodiment requests the first database schema information corresponding to the encrypted data maintained by the smart contract in the non-relational database from the corresponding smart contract. This first schema information serves as the organizational schema for maintaining the encrypted standard data obtained by decrypting, converting, and encrypting the encrypted data related to the smart contract in the blockchain relational database (the process of decryption, conversion, and encryption can also be referred to as conversion in this specification). This ensures the correct maintenance of the encrypted standard data related to the smart contract in the blockchain relational database. When a blockchain node contains multiple smart contracts, and different smart contracts have different data organization forms, this embodiment can obtain the database schema information corresponding to each smart contract. The database schema information of the corresponding smart contract is then used as the database schema information corresponding to the blockchain relational database to convert the encrypted data related to the corresponding smart contract into encrypted standard data. Finally, based on the respective database schema information of different smart contracts, the correct maintenance of the encrypted standard data related to multiple smart contracts in the blockchain relational database is achieved. At this point, it is equivalent to the blockchain relational database application having multiple different database schema information, and the database schema information corresponding to any smart contract only supports maintaining the ciphertext standard data involved in that smart contract (i.e., the ciphertext standard data obtained by decrypting, converting and encrypting the ciphertext data in that smart contract). This supports multiple smart contracts with different data organization forms maintaining ciphertext data in the blockchain non-relational database, which are then correctly converted into ciphertext standard data and finally migrated to the blockchain relational database for maintenance in the form of ciphertext standard data.
[0052] S106: The encrypted standard data is maintained in the blockchain relational database, which is used to provide data analysis services running in the first trusted execution environment to the analysis requester.
[0053] After obtaining the encrypted standard data in the first trusted environment, the node device can store the encrypted standard data in the blockchain relational database according to the corresponding blockchain schema information, thus realizing the conversion and migration of encrypted data from the blockchain non-relational database to the encrypted standard data in the blockchain relational database. Because the blockchain relational database supports various SQL queries and has powerful data analysis capabilities (such as data query capabilities based on various conditions, indexes, and relationships), it can easily provide convenient data analysis services to those with analysis needs. Furthermore, since the data analysis service runs in the first trusted execution environment, the encrypted standard data is actually decrypted and analyzed within the first trusted execution environment to obtain the analysis results. Analyzing plaintext data ensures efficiency, and running the data analysis service in the TEE ensures data security. For example, the data analysis engine deployed on and off the node device in the first trusted execution environment provides a data analysis interface to external parties requesting analysis services for the blockchain relational database.
[0054] This specification's embodiments deploy a blockchain non-relational database and a blockchain relational database on the node device. On one hand, since the blockchain non-relational database maintains ciphertext data obtained by encrypting the blockchain data generated when the blockchain node runs blockchain services, this enables efficient storage and retrieval of encrypted blockchain data when the blockchain node runs blockchain services. On the other hand, by decrypting, converting, and encrypting the ciphertext data maintained from the blockchain non-relational database into ciphertext standard data and simultaneously maintaining it in the blockchain relational database, convenient data analysis services can be achieved using the blockchain relational database. Furthermore, both the blockchain services run by the blockchain node and the process of decrypting, converting, and encrypting ciphertext data by the node device are performed within the corresponding trusted execution environment. Simultaneously, before providing ciphertext data, the blockchain node needs to verify the remote proof corresponding to the first trusted execution environment, thereby ensuring system-level data security for data processing, data transmission, and data storage. The method for maintaining blockchain data described in the embodiments of this specification achieves two backups of the same data, which objectively improves disaster recovery capabilities and enables convenient data analysis services while ensuring efficient access during the execution of blockchain services. At the same time, due to the integration of trusted execution environment technology, it realizes a trusted data flow and trusted data processing process from on-chain blockchain services to off-chain data conversion and data analysis services, minimizing the risk of data leakage.
[0055] Optional, also includes:
[0056] Receive data analysis requests sent by the client requesting the analysis;
[0057] The first trusted execution environment reads at least one encrypted standard data corresponding to the data analysis request maintained in the blockchain relational database, decrypts the at least one encrypted standard data into at least one standard data using the second key, and returns the analysis result obtained by analyzing the at least one standard data based on the data analysis request to the analysis requesting party.
[0058] As an example of providing data analysis services, the data analysis engine deployed on and off the node device can also be used to receive data analysis requests sent by the analysis requester. Then, based on the data analysis engine, it retrieves at least one encrypted standard data corresponding to the data analysis request from the blockchain relational database and reads it into a first trusted execution environment. Using a second key, it decrypts the at least one encrypted standard data into at least one standard data, and builds an in-memory database based on the at least one standard data (in plaintext) within the first trusted execution environment. Based on the data analysis request, it analyzes this in-memory database and returns the analysis results to the analysis requester. The analysis results can be returned to the analysis requester after being encrypted with the second key, or directly in plaintext. This specification does not impose any restrictions on this, thus realizing a complete data analysis service. For example, if the data analysis request is a data query request that simultaneously satisfies conditions A and B, the data analysis engine will query the blockchain relational database for encrypted standard data that simultaneously meets conditions A and B, read this encrypted standard data into the first trusted execution environment, decrypt it into standard data using the second key, and return it as the analysis result to the analysis requester.
[0059] Optionally, reading at least one encrypted standard data corresponding to the data analysis request maintained in the blockchain relational database into the first trusted execution environment includes:
[0060] If it is determined that the party requesting the analysis belongs to a legitimate user of the data analysis service, the at least one encrypted standard data corresponding to the data analysis request maintained in the blockchain relational database is read into the first trusted execution environment.
[0061] In the embodiments described in this specification, the node device first needs to verify the analysis permissions of the requester. Only after confirming that the requester has analysis permissions will the node device respond to the data analysis request sent by the requester and execute subsequent steps. The node device maintains a list of legitimate users corresponding to the data analysis service in the first trusted execution environment. The node device—specifically, the data analysis engine—can verify the identity of the requester (for example, by verifying the digital signature contained in the data analysis request using the first public key corresponding to the first requester, and confirming that the data analysis request does indeed come from the first requester corresponding to the first public key) by checking if the identification information of the requester is included in the list of legitimate users. If the identification information of the requester is not included in the list of legitimate users, the node device determines that the requester does not have analysis permissions.
[0062] Optionally, the encrypted first user list corresponding to the legitimate user is maintained in the blockchain relational database. The encrypted first user list is obtained by the node device encrypting the first user list using a second key in a first trusted execution environment. The encrypted second user list is obtained by the node device decrypting the encrypted second user list using a first key in the first trusted execution environment and converting it based on the database schema information. The encrypted second user list is maintained in the blockchain non-relational database by the user authorization contract deployed by the blockchain node.
[0063] In the embodiments of this specification, the list of legitimate users corresponding to the legitimate users is obtained by the node device reading the encrypted first user list from the blockchain relational database and decrypting it using the second key in the first trusted execution environment. The encrypted first user list maintained in the blockchain relational database is also migrated from the encrypted second user list in the blockchain non-relational database through the method of maintaining blockchain data involved in the embodiments of this specification. Specifically, the list of legitimate users corresponding to the legitimate users is actually maintained in the user authorization contract deployed on the blockchain node. This contract can be modified, updated, and added through blockchain transactions. As mentioned earlier, the list of legitimate users maintained by the user authorization contract is actually encrypted into a second user list ciphertext by the blockchain node using a second key, and then maintained in the contract storage space corresponding to the user authorization contract in the blockchain non-relational database. Therefore, the second user list ciphertext can be used as the ciphertext data involved in the embodiments of this specification. Through the method of maintaining blockchain data involved in the embodiments of this specification, it is obtained by the data conversion engine deployed on the node device, and decrypted into a plaintext legitimate user list using the second key in the first trusted execution environment. The legitimate user list is further converted into a standard legitimate user list defined by the database schema information corresponding to the blockchain relational database (its data content is consistent with the legitimate user list), so that the standard legitimate user list is finally encrypted into a second user list ciphertext using the first key and maintained in the blockchain relational database. When the data analysis engine running in the first trusted execution environment needs to obtain the legitimate user list, it can read the first user list ciphertext from the blockchain relational database and decrypt it using the second key to obtain the standard legitimate user list. In the embodiments of this specification, the list of legitimate users corresponding to legitimate users is actually maintained by the user authorization contract deployed on the blockchain node. The node device can use the method of maintaining blockchain data involved in the embodiments of this specification to synchronously maintain the list of legitimate users stored in the blockchain non-relational database in the form of the second user list ciphertext in the form of the first user list ciphertext in the blockchain relational database. This allows the node device to obtain the list of legitimate users off-chain without calling the user authorization contract on the chain.
[0064] Figure 3 This is a schematic structural diagram of a device provided in an exemplary embodiment. Please refer to... Figure 3At the hardware level, the device includes a processor 302, an internal bus 303, a network interface 306, memory 308, and non-volatile memory 310, and may also include other hardware required for its functions. One or more embodiments of this specification can be implemented in software, for example, the processor 302 reads the corresponding computer program from the non-volatile memory 310 into memory 308 and then runs it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.
[0065] like Figure 4 As shown, Figure 4 This is a block diagram of an apparatus for maintaining blockchain data according to an exemplary embodiment, which can be applied to, for example... Figure 3 The device shown implements the technical solution of this specification; the device is applied to a node device deployed with a blockchain node and a first trusted execution environment, the node device maintaining a blockchain non-relational database and a blockchain relational database, the blockchain non-relational database being used to maintain encrypted data, the encrypted data being obtained by the blockchain node encrypting blockchain data generated when running a blockchain service in a second trusted execution environment using a first key corresponding to the second trusted execution environment; the device includes:
[0066] The encrypted data acquisition unit 401 is used to acquire the encrypted data maintained in the blockchain non-relational database when the blockchain node passes the remote proof verification corresponding to the first trusted execution environment;
[0067] The data conversion unit 402 is used to decrypt the ciphertext data into the blockchain data using a first key in a first trusted execution environment, convert the blockchain data into standard data defined by the database schema information corresponding to the blockchain relational database, and encrypt the standard data into ciphertext standard data using a second key corresponding to the first trusted execution environment.
[0068] The encrypted standard data maintenance unit 403 is used to maintain the encrypted standard data in the blockchain relational database, which is used to provide data analysis services running in the first trusted execution environment to the analysis requester.
[0069] Optionally, the encrypted data acquisition unit 401 is specifically used for:
[0070] Receive the encrypted data actively pushed by the blockchain node; and / or,
[0071] Send a blockchain data request to the blockchain node and receive the encrypted data returned by the blockchain node in response to the blockchain data request.
[0072] Optionally, the encrypted data acquisition unit 401 is further configured to:
[0073] Initiate a blockchain data request to the smart contract deployed on the blockchain node for the encrypted data maintained by the smart contract in the blockchain's non-relational database; or,
[0074] Initiate a blockchain data request to the blockchain node for the encrypted data maintained in the blockchain's non-relational database.
[0075] Optionally, when the blockchain data request is for the encrypted data maintained by the smart contract in the blockchain non-relational database, the apparatus further includes:
[0076] The pattern information query request sending unit 404 is used to initiate a pattern information query request to the smart contract, and determine the first database pattern information recorded in the smart contract returned by the smart contract in response to the pattern information query request as the database pattern information corresponding to the blockchain relational database.
[0077] Optionally, the remote proof is included in the blockchain data request; or,
[0078] The remote proof is pre-maintained on the blockchain node.
[0079] Optionally, the blockchain data includes block data, state data, and event data.
[0080] Optionally, the first key is provided to the first trusted execution environment deployed on the node device by the blockchain node if the remote proof is verified successfully; or, the first key is pre-maintained in the first trusted execution environment.
[0081] Optional, also includes:
[0082] The data analysis request receiving unit 405 is used to receive the data analysis request sent by the analysis requester.
[0083] The analysis result return unit 406 is used to read at least one encrypted standard data corresponding to the data analysis request maintained in the blockchain relational database into the first trusted execution environment, decrypt the at least one encrypted standard data into at least one standard data respectively using the second key, and return the analysis result obtained by analyzing the at least one standard data based on the data analysis request to the analysis requester.
[0084] Optionally, the analysis result return unit 406 is further used for:
[0085] If it is determined that the party requesting the analysis belongs to a legitimate user of the data analysis service, the at least one encrypted standard data corresponding to the data analysis request maintained in the blockchain relational database is read into the first trusted execution environment.
[0086] Optionally, the encrypted first user list corresponding to the legitimate user is maintained in the blockchain relational database. The encrypted first user list is obtained by the node device encrypting the first user list using a second key in a first trusted execution environment. The encrypted second user list is obtained by the node device decrypting the encrypted second user list using a first key in the first trusted execution environment and converting it based on the database schema information. The encrypted second user list is maintained in the blockchain non-relational database by the user authorization contract deployed by the blockchain node.
[0087] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.
[0088] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.
[0089] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this invention does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.
[0090] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.
[0091] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.
[0092] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0093] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0094] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0095] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0096] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.
[0097] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.
[0098] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0099] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.
[0100] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.
[0101] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.
Claims
1. A method for maintaining blockchain data, applied to a node device deployed with a blockchain node and a first trusted execution environment, the node device maintaining a blockchain non-relational database and a blockchain relational database, the blockchain non-relational database being used for maintaining ciphertext data, the ciphertext data being obtained by encrypting, by a first key corresponding to a second trusted execution environment, blockchain data generated by the blockchain node when a blockchain service is running in the second trusted execution environment; the method comprising: obtaining the ciphertext data maintained in the blockchain non-relational database, in a case where remote attestation corresponding to the first trusted execution environment is verified by the blockchain node; decrypting, in the first trusted execution environment, the ciphertext data into the blockchain data by the first key, converting the blockchain data into standard data defined by database schema information corresponding to the blockchain relational database, and encrypting the standard data into ciphertext standard data by a second key corresponding to the first trusted execution environment; maintaining the ciphertext standard data in the blockchain relational database, the blockchain relational database being used for providing a data analysis service running in the first trusted execution environment to an analysis demand party. 2.The method of claim 1, wherein the obtaining the ciphertext data maintained in the blockchain non-relational database comprises: receiving the ciphertext data actively pushed by the blockchain node; and / or sending a blockchain data request to the blockchain node, and receiving the ciphertext data returned by the blockchain node in response to the blockchain data request. 3.The method of claim 2, wherein the sending a blockchain data request to the blockchain node comprises: initiating, to a smart contract deployed in the blockchain node, the blockchain data request for the ciphertext data maintained in the blockchain non-relational database by the smart contract; or initiating, to the blockchain node, the blockchain data request for the ciphertext data maintained in the blockchain non-relational database. 4.The method of claim 3, wherein in a case where the blockchain data request is for the ciphertext data maintained in the blockchain non-relational database by the smart contract, the method further comprises: initiating a schema information query request to the smart contract, and determining first database schema information recorded in the smart contract and returned by the smart contract in response to the schema information query request as the database schema information corresponding to the blockchain relational database. 5.The method of claim 2, wherein the remote attestation is contained in the blockchain data request; or the remote attestation is pre-maintained in the blockchain node. 6.The method of claim 1, wherein the blockchain data comprises block data, state data and event data. 7.The method of claim 1, wherein the first key is provided to the first trusted execution environment deployed by the node device in a case that the remote attestation verification by the blockchain node is passed, or the first key is pre-maintained in the first trusted execution environment. 8.The method of claim 1, further comprising: receiving a data analysis request sent by an analysis demand party; reading at least one ciphertext standard data corresponding to the data analysis request maintained in the blockchain relational database into the first trusted execution environment, decrypting the at least one ciphertext standard data into at least one standard data respectively by a second key, and returning an analysis result obtained by analyzing the at least one standard data based on the data analysis request to the analysis demand party. 9.The method of claim 8, wherein the reading the at least one ciphertext standard data corresponding to the data analysis request maintained in the blockchain relational database into the first trusted execution environment comprises: reading the at least one ciphertext standard data corresponding to the data analysis request maintained in the blockchain relational database into the first trusted execution environment in a case that it is determined that the analysis demand party belongs to a legal user of the data analysis service. The second user list ciphertext is maintained in the blockchain non-relational database by a user authorization contract deployed by the blockchain node. 11.An apparatus for maintaining blockchain data, applied to a node device in which a blockchain node and a first trusted execution environment are deployed, the node device maintaining a blockchain non-relational database and a blockchain relational database, the blockchain non-relational database being used for maintaining ciphertext data, the ciphertext data being obtained by encrypting blockchain data generated when the blockchain service is run in a second trusted execution environment by the first key corresponding to the second trusted execution environment; the apparatus comprising: a blockchain data obtaining unit, configured to obtain the ciphertext data maintained in the blockchain non-relational database in a case that the remote attestation verification by the first trusted execution environment is passed by the blockchain node; a blockchain data obtaining unit, configured to decrypt the ciphertext data into the blockchain data in the first trusted execution environment by the first key, convert the blockchain data into standard data defined by database schema information corresponding to the blockchain relational database, and encrypt the standard data into ciphertext standard data by the second key corresponding to the first trusted execution environment; and a standard data maintaining unit, configured to maintain the ciphertext standard data in the blockchain relational database, the blockchain relational database being used for providing a data analysis service run in the first trusted execution environment to an analysis demand party. 12.An electronic device, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor implements the method of any one of claims 1-10 by running the executable instructions.
10. The method of claim 9, wherein the first user list ciphertext corresponding to the legitimate user is maintained in the blockchain relational database, the first user list ciphertext being obtained by the node device encrypting a first user list in a first trusted execution environment by using a second key, and the first user list being obtained by the node device decrypting the second user list ciphertext in the first trusted execution environment by using a first key and converting based on the database schema information. 13. A computer readable storage medium having stored thereon computer instructions, the instructions, when executed by a processor, implementing the steps of the method of any of claims 1-10.
Citation Information
Patent Citations
Data processing method, system, and storage medium
CN109408513A
Block chain-based data processing method, device, apparatus and system
CN113821817A