A method, device, electronic device and storage medium for maintaining blockchain data

Abstract

The specification provides a method, device, electronic equipment and storage medium for maintaining blockchain data, which is applied to a node device deployed with a blockchain node, the node device maintaining a blockchain non-relational database and a blockchain relational database, the blockchain non-relational database being used for maintaining homomorphic ciphertext data and corresponding zero-knowledge proof, the homomorphic ciphertext data being obtained by homomorphic encryption of blockchain data generated by the blockchain node when running a blockchain service; the method comprises: obtaining the homomorphic ciphertext data and the corresponding zero-knowledge proof maintained in the blockchain non-relational database; in the case that the zero-knowledge proof is verified successfully, converting the homomorphic ciphertext data into standard data defined by database mode information of the blockchain relational database; maintaining the standard data in the blockchain relational database, the blockchain relational database being used for providing a data analysis service to an analysis demand party, the data analysis service comprising a ciphertext operation service.

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 blockchain nodes. The node device maintains a blockchain non-relational database and a blockchain relational database. The blockchain non-relational database is used to maintain homomorphic ciphertext data and its corresponding zero-knowledge proofs. The homomorphic ciphertext data is obtained by the blockchain node through homomorphic encryption of blockchain data generated when running a blockchain service. The method includes:

[0006] Obtain the homomorphic ciphertext data maintained in the blockchain non-relational database and its corresponding zero-knowledge proof;

[0007] If the zero-knowledge proof verification is successful, the homomorphic ciphertext data will be converted into standard data defined by the database schema information corresponding to the blockchain relational database.

[0008] The standard data is maintained in the blockchain relational database, which is used to provide data analysis services to those with analysis needs. The data analysis services include encrypted computation services.

[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 blockchain nodes. The node device maintains a blockchain non-relational database and a blockchain relational database. The blockchain non-relational database is used to maintain homomorphic ciphertext data and its corresponding zero-knowledge proofs. The homomorphic ciphertext data is obtained by the blockchain node through homomorphic encryption of blockchain data generated while running a blockchain service. The apparatus includes:

[0010] The homomorphic ciphertext data acquisition unit is used to acquire the homomorphic ciphertext data maintained in the blockchain non-relational database and its corresponding zero-knowledge proof;

[0011] The data conversion unit is used to convert the homomorphic ciphertext data into standard data defined by the database schema information corresponding to the blockchain relational database when the zero-knowledge proof verification is successful.

[0012] A standard data maintenance unit is used to maintain the standard data in the blockchain relational database, which is used to provide data analysis services to the analysis requester, including encrypted computation services.

[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, the blockchain non-relational database maintains homomorphic ciphertext data obtained by encrypting the blockchain data generated when the blockchain node runs the blockchain service, along with its corresponding zero-knowledge proofs. This enables efficient storage of encrypted blockchain data and efficient retrieval of homomorphic ciphertext data when the blockchain node runs the blockchain service. On the other hand, by converting the homomorphic ciphertext data maintained from the blockchain non-relational database into standard data and simultaneously maintaining it in the blockchain relational database, convenient data analysis services can be achieved using the blockchain relational database. Furthermore, since the zero-knowledge proofs corresponding to the homomorphic ciphertext data need to be verified before conversion, the validity of the converted homomorphic ciphertext data can be ensured. The method for maintaining blockchain data involved in this specification's embodiments achieves one set of data backed up in two places, objectively improving disaster recovery capabilities and enabling convenient data analysis services while ensuring efficient access during blockchain service execution. Simultaneously, since the backed-up data is not plaintext blockchain data but encrypted homomorphic ciphertext data, and the data analysis service includes ciphertext computation services, it achieves basic computational analysis capabilities for ciphertext while ensuring data security through ciphertext. 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 blockchain nodes. The node device maintains a blockchain non-relational database and a blockchain relational database. The blockchain non-relational database is used to maintain homomorphic ciphertext data and its corresponding zero-knowledge proofs. The homomorphic ciphertext data is obtained by the blockchain node through homomorphic encryption of blockchain data generated while running a blockchain service. The method includes:

[0026] S102: Obtain the homomorphic ciphertext data maintained in the blockchain non-relational database and its corresponding zero-knowledge proof.

[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, and each node device maintains both a blockchain non-relational database and a blockchain relational database. In the embodiments of this specification, the blockchain non-relational database is a type of non-relational database, while the blockchain relational database is a type of relational database.

[0028] 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. On the other hand, to ensure data security, when blockchain nodes need to store blockchain data in the blockchain non-relational database, as an alternative to directly storing blockchain data, the blockchain nodes can first perform homomorphic encryption on the blockchain data to obtain homomorphic ciphertext data, and then store the homomorphic 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 homomorphic 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. Furthermore, in the embodiments of this specification, since it is necessary to ensure that homomorphic ciphertext data has a provable valid credential, when a blockchain node stores any homomorphic ciphertext data in the blockchain non-relational database, it also generates a corresponding zero-knowledge proof for that homomorphic ciphertext data. The zero-knowledge proof corresponding to any homomorphic ciphertext data is used to prove to a third party that the plaintext data (i.e., the blockchain data before encryption) corresponding to that homomorphic ciphertext data has specific data attributes, such as the range of data values, whether the data belongs to a specified set, whether the data is generated by a specified operation logic, etc. The specific information of the proof depends on the functional semantic definition in the actual scenario, and there is no distinction in terms of capabilities. This specification does not limit the specific type of zero-knowledge proof. Therefore, any homomorphic ciphertext data maintained in the blockchain non-relational database involved in the embodiments of this specification is jointly maintained with a corresponding zero-knowledge proof. 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, unlike relational databases, they cannot use SQL (structured query language) with WHERE clauses to filter and query portions of the stored data. 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, while key-value databases outperform relational databases in terms of absolute access speed, the requirement to know the key value limits their application scenarios. Although the above description only covers key-value databases, it essentially applies to most non-relational databases. In general, non-relational databases offer high access speeds but lack data analysis capabilities, such as the ability to query based on indexes and relationships between data.

[0029] 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 homomorphic ciphertext data obtained by encrypting blockchain data, the security risks caused by data leakage can also be avoided.

[0030] 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.

[0031] In the embodiments of this specification, due to the data analysis system (including) deployed off-chain by the node device Figure 2The data analysis engine (not shown) and its corresponding database utilize a high-speed non-relational database (i.e., a blockchain relational database). This allows node devices to leverage the powerful data analysis capabilities of the blockchain non-relational database when running data analysis services by calling the data analysis engine, ensuring convenient data analysis services are provided to those with analysis requests. Furthermore, since some standard data maintained in the blockchain relational database is obtained through homomorphic ciphertext conversion, it remains in a ciphertext state and has limited data value. While those with analysis requests can obtain this ciphertext-state standard data through query services, they may lack the necessary ciphertext computation capabilities to utilize it. This application embodiment provides a ciphertext computation service. Responding to the analysis requester's request for ciphertext computation of some ciphertext-state standard data, the ciphertext computation is completed on the node device side, and the computation result is directly returned to the analysis requester. This avoids the analysis requester bearing the burden of complex ciphertext computations, minimizing demands on their technical environment and computational pressure, providing a convenient ciphertext computation service, and maximizing the utilization of the data value of the ciphertext-state standard data in the blockchain relational database.

[0032] 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.

[0033] In the embodiments of this specification, obtaining the homomorphic ciphertext data and its corresponding zero-knowledge proof maintained in the blockchain non-relational database includes: receiving the homomorphic ciphertext data and its corresponding zero-knowledge proof actively pushed by the blockchain node; and / or sending a blockchain data request to the blockchain node and receiving the homomorphic ciphertext data and its corresponding zero-knowledge proof returned by the blockchain node in response to the blockchain data request.

[0034] The method for maintaining blockchain data described in the embodiments of this specification is applied to node devices, specifically to the data transformation engine deployed off-chain on the node device. Node devices can obtain homomorphic ciphertext data and its corresponding zero-knowledge proofs maintained in a blockchain non-relational database through at least one of two methods. These methods include: First, receiving homomorphic ciphertext data and its corresponding zero-knowledge proofs actively pushed by the blockchain node. For example, each time a blockchain node adds or modifies homomorphic ciphertext data in the blockchain non-relational database during the operation of a blockchain service, the blockchain node actively pushes a data update message carrying the latest added or modified homomorphic ciphertext data and its corresponding zero-knowledge proofs to the off-chain data conversion engine. This method can promptly convert and synchronize data from the blockchain non-relational database to the blockchain relational database, thereby ensuring the symmetry and timeliness of data in the blockchain relational database. Second, sending a blockchain data request to the blockchain node to obtain the homomorphic ciphertext data and its corresponding zero-knowledge proofs returned by the blockchain node in response to the blockchain data request. This method obtains homomorphic ciphertext data and its corresponding zero-knowledge proofs through a request-response model, which can effectively control the scope of the requested homomorphic ciphertext data and thus shield some data that does not need to be maintained in the blockchain relational database.

[0035] Optionally, sending a blockchain data request to the blockchain node includes: initiating a blockchain data request to the smart contract deployed on the blockchain node for the homomorphic ciphertext data and its corresponding zero-knowledge proof maintained by the smart contract in the blockchain non-relational database; or, initiating a blockchain data request to the blockchain node for the homomorphic ciphertext data and its corresponding zero-knowledge proof maintained in the blockchain non-relational database.

[0036] 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 homomorphic ciphertext 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 homomorphic ciphertext 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.

[0037] In one embodiment, a blockchain node deploys several smart contracts, each maintaining corresponding state data. This state data is stored in the contract storage space corresponding to the smart contract in the blockchain non-relational database as encrypted homomorphic ciphertext data. A node device can initiate a blockchain data request to the 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 homomorphic ciphertext data indicated by the blockchain transaction from the contract storage space corresponding to the smart contract in the blockchain non-relational database. It then sends this homomorphic ciphertext data and its corresponding zero-knowledge proof as a response message (e.g., in the form of a blockchain event) back to the node device, thereby achieving the acquisition of the homomorphic ciphertext data and its corresponding zero-knowledge proof maintained in the blockchain non-relational database by invoking the smart contract.

[0038] 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 homomorphic ciphertext data (obtained by homomorphically encrypting block data) indicated by the blockchain data request from the blockchain non-relational database and its corresponding zero-knowledge proof and send it back to the node device.

[0039] 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 without going through the blockchain node. The blockchain non-relational database directly responds to the received blockchain data request by returning the homomorphic ciphertext data indicated by the blockchain data request and its corresponding zero-knowledge proof.

[0040] 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.

[0041] S104: If the zero-knowledge proof verification is successful, the homomorphic ciphertext data is converted into standard data defined by the database schema information corresponding to the blockchain relational database.

[0042] In the embodiments of this specification, when a node device confirms the successful verification of the zero-knowledge proofs (which can be one or more), it can determine that the plaintext data corresponding to the homomorphic ciphertext data (i.e., the blockchain data before homomorphic encryption) possesses the data attributes corresponding to each zero-knowledge proof. Therefore, the node device can verify the integrity, standardization, and correctness of the homomorphic ciphertext data by verifying the zero-knowledge proofs, thereby ultimately determining whether the homomorphic ciphertext data is valid. Only after confirming the validity of the homomorphic ciphertext data will the node device proceed with the subsequent data transformation and migration steps to filter out invalid data, ultimately ensuring the integrity, standardization, and correctness of the standard data maintained in the blockchain relational database.

[0043] 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.

[0044] After obtaining and verifying the validity of homomorphic ciphertext data, the node device will convert the homomorphic ciphertext data into standard data defined by the database schema information corresponding to the blockchain relational database. 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 homomorphic ciphertext data to standard data includes, but is not limited to, the conversion of data tables, rows, and columns. For example, the conversion from homomorphic ciphertext 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 converted homomorphic ciphertext data is in a ciphertext state and the conversion process does not involve decryption, the converted standard data is also in a ciphertext state and has a ciphertext form. Of course, the embodiments in this specification also support directly converting plaintext data (such as blockchain data whose plaintext state is stored in a blockchain non-relational database) into standard data. The specific method is the same as that for converting homomorphic ciphertext data, except that the standard data obtained after the final conversion is in plaintext state.

[0045] Optionally, when the blockchain data request is for the homomorphic ciphertext data maintained by the smart contract in the blockchain non-relational database and its corresponding zero-knowledge proof, the method further includes:

[0046] 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.

[0047] 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 blockchain data and / or homomorphic ciphertext data maintained by different smart contracts in a blockchain non-relational database, this specification embodiment requests the first database schema information maintained by the corresponding smart contract, corresponding to the blockchain data and / or homomorphic ciphertext data maintained by the smart contract in the non-relational database. This first schema information serves as the organizational schema for maintaining the standard data obtained by converting the blockchain data and / or homomorphic ciphertext data involved in the smart contract in the blockchain relational database. This ensures the correct maintenance of the standard data involved in 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 specification embodiment can obtain the database schema information corresponding to each smart contract. Based on the database schema information of the corresponding smart contract, the conversion of the blockchain data and / or homomorphic ciphertext data involved in the corresponding smart contract to standard data is achieved using the database schema information corresponding to the blockchain relational database. Ultimately, based on the respective database schema information of different smart contracts, the correct maintenance of the standard data involved in 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 standard data involved in that smart contract (i.e., standard data obtained by converting blockchain data and / or homomorphic ciphertext data from that smart contract). This supports multiple smart contracts with different data organization forms maintaining blockchain data and / or homomorphic ciphertext data in the blockchain non-relational database, which are then correctly converted into standard data and finally migrated to the blockchain relational database for maintenance in the form of standard data.

[0048] S106: The standard data is maintained in the blockchain relational database, which is used to provide data analysis services to the analysis requester, including encrypted operation services.

[0049] After obtaining standard data, node devices can store the standard data in the blockchain relational database according to the corresponding blockchain schema information, thus realizing the conversion and migration of homomorphic encrypted data from the blockchain non-relational database to standard data in the blockchain relational database. Because blockchain relational databases support various SQL queries and possess powerful data analysis capabilities (such as data query capabilities based on various conditions, indexes, and relationships), they can easily provide convenient data analysis services to those with analysis needs. For example, by providing data analysis interfaces to external parties through data analysis engines deployed on and off the node device, data analysis services targeting the blockchain relational database can be offered to those calling these interfaces. Since the data analysis service includes encrypted computation services, it can also fully utilize the data value of the standard data maintained in encrypted form within the blockchain relational database.

[0050] This specification's embodiments deploy a blockchain non-relational database and a blockchain relational database on the node device. On one hand, the blockchain non-relational database maintains homomorphic ciphertext data obtained by encrypting the blockchain data generated when the blockchain node runs the blockchain service, along with its corresponding zero-knowledge proofs. This enables efficient storage of encrypted blockchain data and efficient retrieval of homomorphic ciphertext data when the blockchain node runs the blockchain service. On the other hand, by converting the homomorphic ciphertext data maintained from the blockchain non-relational database into standard data and simultaneously maintaining it in the blockchain relational database, convenient data analysis services can be achieved using the blockchain relational database. Furthermore, since the zero-knowledge proofs corresponding to the homomorphic ciphertext data need to be verified before conversion, the validity of the converted homomorphic ciphertext data can be ensured. The method for maintaining blockchain data involved in this specification's embodiments achieves one set of data backed up in two places, objectively improving disaster recovery capabilities and enabling convenient data analysis services while ensuring efficient access during blockchain service execution. Simultaneously, since the backed-up data is not plaintext blockchain data but encrypted homomorphic ciphertext data, and the data analysis service includes ciphertext computation services, it achieves basic computational analysis capabilities for ciphertext while ensuring data security through ciphertext.

[0051] Optionally, it also includes: receiving a data analysis request sent by the analysis requester; and returning the analysis results obtained by analyzing the blockchain relational database based on the data analysis request to the analysis requester. As an embodiment of providing data analysis services, the data analysis engine deployed on and off the node device can also be used to receive a data analysis request sent by the analysis requester, then analyze a portion of the data in the blockchain relational database based on the data analysis engine, and finally return the analysis results to the analysis requester, thereby realizing a complete data analysis service. For example, if the data analysis request is a data query request that simultaneously satisfies condition A and condition B, then the data analysis engine will query the blockchain relational database for data that simultaneously meets condition A and condition B, and return this data as the analysis result to the analysis requester.

[0052] Optionally, the data analysis request is a ciphertext operation request, and the analysis result is a ciphertext calculation result. The analysis of the blockchain relational database based on the data analysis request includes: performing ciphertext calculations on at least one piece of data to be processed indicated by the ciphertext operation request maintained in the blockchain relational database to obtain the ciphertext calculation result. As an embodiment of providing ciphertext operation services, the data analysis engine deployed on-chain and off-chain on the node device can also be used to receive ciphertext operation requests sent by the analysis requester, retrieve at least one piece of data to be processed from the blockchain relational database based on the ciphertext operation request, wherein at least a portion of the at least one piece of data to be processed is standard data in a ciphertext state (supporting fully ciphertext operations and mixed ciphertext and plaintext operations), and then perform ciphertext calculations on the at least one piece of data to be processed according to the requirements of the ciphertext operation request to obtain a ciphertext calculation result, which is also in a ciphertext state. The node device returns this ciphertext calculation result as a response message to the analysis requester, thereby realizing a complete ciphertext operation service.

[0053] Optionally, the zero-knowledge proof, upon successful verification, is used to indicate that the blockchain data belongs to the first set corresponding to the first data range; maintaining the standard data in the blockchain relational database includes: maintaining the standard data in the data table corresponding to the first set in the blockchain relational database. In the embodiments of this specification, the blockchain relational database maintains its own data tables for standard data corresponding to different sets, and different sets have different data properties, such as different data ranges. For plaintext standard data, its data range can be clearly known by the node device and thus maintained in the corresponding data table. However, for ciphertext standard data, the node device needs to use the zero-knowledge proof corresponding to the homomorphic ciphertext data before conversion to determine the data range of the plaintext data (i.e., the blockchain data before homomorphic encryption) corresponding to the homomorphic ciphertext data. For example, when the zero-knowledge proof is used to indicate that the blockchain data is in the first data range and the first data range corresponds to the first set, the data range is used to maintain the standard data in the data table corresponding to the first set in the blockchain relational database. Since the standard data obtained after the homomorphic ciphertext data conversion should also belong to the first set corresponding to the first data range (because the data conversion process does not change the value of the data, but only changes the structure and relationship of the data), the node device can store the standard data in the data table corresponding to the first set in the blockchain relational database. This ensures that the standard data of the ciphertext state can also be allocated to the correct data table according to the predefined table structure. At the same time, this classification of the standard data of the ciphertext state based on the data table structure also helps the subsequent data analysis of these standard data (equivalent to providing a retrieval dimension for the data range).

[0054] Figure 3 This is a schematic structural diagram of a device provided in an exemplary embodiment. Please refer to... Figure 3 At 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.

[0055] 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 3The device shown implements the technical solution of this specification; the device is applied to a node device with deployed blockchain nodes, the node device maintaining a blockchain non-relational database and a blockchain relational database, the blockchain non-relational database being used to maintain homomorphic ciphertext data and its corresponding zero-knowledge proofs, the homomorphic ciphertext data being obtained by the blockchain node through homomorphic encryption of blockchain data generated when running the blockchain service; the device includes:

[0056] The homomorphic ciphertext data acquisition unit 401 is used to acquire the homomorphic ciphertext data maintained in the blockchain non-relational database and its corresponding zero-knowledge proof;

[0057] The data conversion unit 402 is used to convert the homomorphic ciphertext data into standard data defined by the database schema information corresponding to the blockchain relational database when the zero-knowledge proof verification is successful.

[0058] The standard data maintenance unit 403 is used to maintain the standard data in the blockchain relational database, which is used to provide data analysis services to the analysis requester, including encrypted operation services.

[0059] Optionally, the homomorphic ciphertext data acquisition unit 401 is specifically used for:

[0060] Receive the homomorphic ciphertext data and its corresponding zero-knowledge proof actively pushed by the blockchain node; and / or,

[0061] Send a blockchain data request to the blockchain node, and receive the homomorphic ciphertext data and its corresponding zero-knowledge proof returned by the blockchain node in response to the blockchain data request.

[0062] Optionally, the homomorphic ciphertext data acquisition unit 401 is further configured to:

[0063] Initiate a blockchain data request to the smart contract deployed on the blockchain node, requesting the homomorphic ciphertext data maintained by the smart contract in the blockchain's non-relational database and its corresponding zero-knowledge proof; or,

[0064] A blockchain data request is initiated to the blockchain node for the homomorphic ciphertext data maintained in the blockchain's non-relational database and its corresponding zero-knowledge proof.

[0065] Optionally, when the blockchain data request is for the homomorphic ciphertext data maintained by the smart contract in the blockchain non-relational database and its corresponding zero-knowledge proof, the apparatus further includes:

[0066] 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.

[0067] Optionally, the blockchain non-relational database is also used to maintain the blockchain data generated when the blockchain node runs the blockchain service.

[0068] Optionally, the blockchain data includes block data, state data, and event data.

[0069] Optional, also includes:

[0070] The data analysis request receiving unit 405 is used to receive the data analysis request sent by the analysis requester.

[0071] The analysis result return unit 406 is used to return the analysis results obtained from analyzing the blockchain relational database based on the data analysis request to the analysis requester.

[0072] Optionally, the data analysis request is a ciphertext operation request, and the analysis result is a ciphertext calculation result; the analysis result return unit 406 is specifically used for:

[0073] At least one piece of data to be processed, indicated by the ciphertext operation request and maintained in the blockchain relational database, is subjected to ciphertext computation to obtain the ciphertext computation result.

[0074] Optionally, the zero-knowledge proof, upon successful verification, is used to indicate that the blockchain data belongs to the first set corresponding to the first data range; the standard data maintenance unit 403 is specifically used for:

[0075] The standard data is maintained in the data table corresponding to the first set in the blockchain relational database.

[0076] 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.

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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.

[0081] 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.

[0082] 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.

[0083] 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.

[0084] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0085] 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.

[0086] 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.

[0087] 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.

[0088] 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.

[0089] 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.

[0090] 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 blockchain nodes, wherein the node device maintains a blockchain non-relational database and a blockchain relational database, the blockchain non-relational database being used to maintain homomorphic ciphertext data and its corresponding zero-knowledge proofs, the homomorphic ciphertext data being obtained by the blockchain node through homomorphic encryption of blockchain data generated when running a blockchain service, so that the blockchain node stores the homomorphic ciphertext data in the blockchain non-relational database; the method comprising: Obtain the homomorphic ciphertext data maintained in the blockchain non-relational database and its corresponding zero-knowledge proof; The zero-knowledge proof is used to verify the integrity, standardization, and correctness of the homomorphic ciphertext data; If the zero-knowledge proof verification is successful, the homomorphic ciphertext data will be converted into standard data defined by the database schema information corresponding to the blockchain relational database. The standard data is maintained in the blockchain relational database, which is used to provide data analysis services to those with analysis needs. The data analysis services include encrypted computation services.

2. The method according to claim 1, wherein obtaining the homomorphic ciphertext data maintained in the blockchain non-relational database and its corresponding zero-knowledge proof comprises: Receive the homomorphic ciphertext data and its corresponding zero-knowledge proof actively pushed by the blockchain node; And / or, Send a blockchain data request to the blockchain node, and receive the homomorphic ciphertext data and its corresponding zero-knowledge proof returned by the blockchain node in response to the blockchain data request.

3. The method according to claim 2, wherein sending a blockchain data request to the blockchain node comprises: Initiate a blockchain data request to the smart contract deployed on the blockchain node, requesting the homomorphic ciphertext data maintained by the smart contract in the blockchain's non-relational database and its corresponding zero-knowledge proof; or, A blockchain data request is initiated to the blockchain node for the homomorphic ciphertext data maintained in the blockchain's non-relational database and its corresponding zero-knowledge proof.

4. The method according to claim 3, wherein when the blockchain data request is directed to the homomorphic ciphertext data maintained by the smart contract in the blockchain non-relational database and its corresponding zero-knowledge proof, the method further comprises: 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.

5. The method according to claim 1, wherein the blockchain non-relational database is further used to maintain the blockchain data generated when the blockchain node runs the blockchain service.

6. The method according to claim 1, wherein the blockchain data includes block data, state data, and event data.

7. The method according to claim 1, further comprising: Receive data analysis requests sent by the client requesting the analysis; The analysis results obtained by analyzing the blockchain relational database based on the data analysis request will be returned to the analysis requester.

8. The method according to claim 7, wherein the data analysis request is a ciphertext operation request, and the analysis result is a ciphertext calculation result; the analysis of the blockchain relational database based on the data analysis request includes: At least one piece of data to be processed, indicated by the ciphertext operation request and maintained in the blockchain relational database, is subjected to ciphertext computation to obtain the ciphertext computation result.

9. The method according to claim 1, wherein the zero-knowledge proof, upon successful verification, is used to indicate that the blockchain data belongs to a first set corresponding to a first data range; the step of maintaining the standard data in the blockchain relational database includes: The standard data is maintained in the data table corresponding to the first set in the blockchain relational database.

10. An apparatus for maintaining blockchain data, applied to a node device deployed with blockchain nodes, the node device maintaining a blockchain non-relational database and a blockchain relational database, the blockchain non-relational database being used to maintain homomorphic ciphertext data and its corresponding zero-knowledge proofs, the homomorphic ciphertext data being obtained by the blockchain node through homomorphic encryption of blockchain data generated when running a blockchain service, so that the blockchain node stores the homomorphic ciphertext data in the blockchain non-relational database; the apparatus comprising: The homomorphic ciphertext data acquisition unit is used to acquire the homomorphic ciphertext data maintained in the blockchain non-relational database and its corresponding zero-knowledge proof; The zero-knowledge proof is used to verify the integrity, standardization, and correctness of the homomorphic ciphertext data; The data conversion unit is used to convert the homomorphic ciphertext data into standard data defined by the database schema information corresponding to the blockchain relational database when the zero-knowledge proof verification is successful. A standard data maintenance unit is used to maintain the standard data in the blockchain relational database, which is used to provide data analysis services to the analysis requester, including encrypted computation services.

11. An electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1-9 by executing the executable instructions.

12. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-9.

Images