Blockchain management methods, systems, and application products

Abstract

This application relates to the field of data processing, and more particularly to a blockchain management method, system, and program product. In this method, the main chain nodes of the blockchain system are divided into M partitions, each partition corresponding to a security level. The total number of main chain nodes in each partition is greater than or equal to 4, where M is an integer greater than or equal to 2. In addition to storing global data on the main chain, each main chain node in each partition is also used to store security level data corresponding to the security level of its respective partition. Based on this, the confidentiality requirements of blockchain data storage are met.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a blockchain management method, system, and program product. Background Technology

[0002] Traditional blockchain is a distributed system with chain-style storage. It inherently possesses the characteristics of distributed network-wide synchronization, public traceability, and node consensus broadcasting, but it is inherently lacking in confidentiality.

[0003] However, as blockchain technology matures and the domestic consortium blockchain industry develops rapidly, its application scenarios continue to expand, gradually covering civilian industries, government agencies, and even military-related classified fields. Therefore, while relying on blockchain to achieve on-chain data storage and business collaboration, higher requirements are also placed on the security and confidentiality capabilities of on-chain data. Summary of the Invention

[0004] To address the above issues, embodiments of this application provide a blockchain management method, system, and program product to achieve the confidentiality requirements of blockchain data storage.

[0005] Firstly, a blockchain management method is provided, applied to a blockchain system including a main chain. The method includes: dividing each main chain node corresponding to the main chain into M partitions, each partition corresponding to a security level, and the total number of main chain nodes in each partition being greater than or equal to 4; M being an integer greater than or equal to 2; in addition to storing global data on the main chain, each main chain node in each partition is also used to store security level data corresponding to the security level of its partition.

[0006] Understandably, dividing the main chain into multiple partitions corresponding to different security levels allows data of different security levels to be stored in different partitions of the main chain. This achieves classified and hierarchical management of data involved in circulation. For example, public, statistical, and basic data with low sensitivity can be managed uniformly as global data on the main chain. Confidential information, sensitive data, and other data with security requirements are stored in different partitions according to their security levels. This ensures that data of different security levels is stored in different partitions. Partitions belonging to the same security level are physically isolated, thus guaranteeing data security and confidentiality.

[0007] In one possible implementation of the first aspect above, the method further includes: acquiring new data; and writing the new data into the partition corresponding to the security level of the new data, based on the security level of the new data.

[0008] In one possible implementation of the first aspect above, each main chain node in each partition includes: a public ledger, a public account system corresponding to the public ledger, and a privacy ledger, a privacy account system corresponding to the privacy ledger; wherein, the public ledger and the public account system are independent ledgers and account systems corresponding to global data; the privacy ledger and the privacy account system are independent ledgers and account systems corresponding to the security level data of their respective partitions; and the privacy ledger and the privacy account system of main chain nodes belonging to the same partition are the same, while the privacy ledger and the privacy account system of main chain nodes in different partitions are different.

[0009] In one possible implementation of the first aspect above, the block data of the partition includes a block header and block information with a privacy ledger, wherein the privacy ledger includes at least: security level data, the security level corresponding to the security level data, and the storage path of the original data corresponding to the security level data when it is stored locally off-chain.

[0010] In one possible implementation of the first aspect mentioned above, each account in the blockchain system is associated with a security level. The allowed access objects corresponding to the security level data in the privacy ledger are: accounts that meet the first security level access conditions. The first security level access conditions are: the security level of the account is greater than or equal to the security level corresponding to the security level data in the privacy ledger. The size of the security level is proportional to the degree of confidentiality.

[0011] In one possible implementation of the first aspect mentioned above, the privacy account system is a distributed account system, and the distributed account system includes: issuer, holder and verifier; the holder, issuer and verifier, based on the verifiable credentials of the account, perform on-chain storage and data reading of the security level data of the account, wherein the verifiable credentials of the account are related to the security level of the account.

[0012] In one possible implementation of the first aspect described above, when the holder is the entity to which the first account, which requires the storage of classified data, belongs, the blockchain system acts as the verifier, the authoritative institution acts as the issuer, and the classified data of the first account is stored on the blockchain in the following manner: obtaining the holder's on-chain request, wherein the on-chain request includes the transaction to be uploaded to the blockchain for the first account, the target verifiable credential for the first account, and the identity information of the first account; the target verifiable credential is a verifiable credential corresponding to the classification level of the partition to be stored; invoking the encrypted on-chain smart contract, using the public key in the keystore corresponding to the target verifiable credential to encrypt the transaction data to be uploaded to the blockchain, obtaining the encrypted classified data; and storing the encrypted classified data on the blockchain. In one possible implementation of the first aspect described above, when the holder is the entity that needs to access the classified data of the first account, the blockchain system acts as the verifier, the authoritative institution acts as the issuer, and obtains the classified data of the first account in the following ways: It obtains the holder's data request, which includes a verification credential obtained by the holder from the issuer, the holder's identity information, and a data hash, wherein the verification credential is used to access the classified data of the first account; it calls the decryption smart contract to verify the verification credential and the identity information; and if the verification of the verification credential and the identity information is successful, it calls the private key corresponding to the verification credential in the keystore to decrypt the classified data of the first account, obtaining the decrypted classified data.

[0013] In one possible implementation of the first aspect above, the method further includes: transmitting classified data from a first node to a second node via a privacy channel, wherein the first node is a data provider node in the main chain node that provides classified data, the second node is a data access node that needs to access the classified data, and the privacy channel is used to encrypt the classified data to be transmitted.

[0014] Secondly, a blockchain system is provided, comprising multiple main chain nodes, a processing unit, and a storage unit. The storage unit stores computer programs / instructions, and the processing unit executes the blockchain management method described in the first aspect and any of its various possible implementations based on the computer programs / instructions.

[0015] Thirdly, a computer program product is provided, including a computer program / instruction, which, when executed by a processor, implements the blockchain management method described in the first aspect and any of the various possible implementations of the first aspect.

[0016] Fourthly, embodiments of this application provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the first aspect and the blockchain management method mentioned in the first aspect.

[0017] The beneficial effects of the second, third, and fourth aspects mentioned above can be referred to the first aspect mentioned above, as well as the relevant descriptions in the various possible implementations of the first aspect, which will not be repeated here. Attached Figure Description

[0018] Figure 1 According to some embodiments of this application, a node structure model between the main chain and partitions is shown.

[0019] Figure 2 According to some embodiments of this application, a data storage structure model between the main chain and partitions is shown.

[0020] Figure 3 According to some embodiments of this application, a schematic diagram of the contents of a block data structure is shown.

[0021] Figure 4 According to some embodiments of this application, a schematic diagram of an access control process based on smart contracts is shown.

[0022] Figure 5 According to some embodiments of this application, a data architecture diagram corresponding to a database structure is shown.

[0023] Figure 6 According to some embodiments of this application, a schematic diagram of the structure of an electronic device is shown. Detailed Implementation

[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] To address the aforementioned issues, this application provides a blockchain management method applied to a blockchain system. In this method, the main chain nodes corresponding to the main chain of the blockchain system are divided into M partitions, each partition corresponding to a security level. Furthermore, the total number of main chain nodes in each partition is greater than or equal to 4, where M is an integer greater than or equal to 2. In addition to storing global data on the main chain, the main chain nodes in each partition are also used to store security level data corresponding to the security level of their respective partition.

[0026] Understandably, dividing the main chain into multiple partitions corresponding to different security levels allows data of different security levels to be stored in different partitions of the main chain. This achieves classified and hierarchical management of data involved in circulation. For example, public, statistical, and basic data with low sensitivity can be managed uniformly as global data on the main chain. Confidential information, sensitive data, and other confidential data with security requirements are stored in different partitions according to their security levels. This ensures that data of different security levels is stored in different partitions. Partitions belonging to the same security level are physically isolated, thus guaranteeing data security and confidentiality.

[0027] Understandably, each partition corresponds to a level of security classification, and data stored on the same partition has the same security classification. This ensures that confidential data is isolated according to its security classification, preventing data integrity from being affected by the "write-up, read-down" paradigm. Data on each partition is encrypted and stored according to different levels of encryption requirements. Nodes within the same partition with the same security classification can synchronize data. New data is written to the corresponding partition based on its security classification. The original data of the classified data can be stored off-chain on the partition node where the data is published. Classified data can be synchronized to the partition, but the off-chain confidential original data will not be synchronized to the entire network. Only when authorized access is granted will the confidential original data be transmitted to the data access node that requested the data, but it will not be synchronized to the storage of the node that requested the data.

[0028] In some embodiments, the main chain nodes are divided into partitions based on the principle of having at least four nodes (i.e., the number of sub-chains that can be formed). Understandably, the main chain is a single blockchain, and each partition can serve as a sub-chain, allowing each partition to independently store data of the same security level.

[0029] Figure 1 This paper presents a node structure model between the main chain and partitions. Taking a main chain consisting of 8 main chain nodes and a partitioning principle of 4 nodes per partition as an example, the 8 main chain nodes are divided into 2 partitions of 4 nodes each, resulting in partition 1 and partition 2. Partition 1 includes main chain node 1, ..., main chain node 4. Partition 2 includes main chain node 5, ..., main chain node 8. Partition 1 and Partition 2 have corresponding security level identifiers MM1 and MM2 to represent the security level of each partition.

[0030] Understandably, main chain nodes within the same partition have the same security level, and their security data can be synchronized. Furthermore, when the blockchain system receives new data (i.e., data to be uploaded to the chain), it can write the new data to the partition corresponding to the security level of the new data, thereby quickly achieving data storage.

[0031] Understandably, because the global data and classified data stored on the main chain nodes have different levels of confidentiality, different systems need to be configured for global data and classified data. For example, Figure 2 This illustrates a data storage structure model between the main chain and partitions. For example... Figure 2As shown, the system storage structure corresponding to global data includes: main chain storage layer, main chain execution layer, main chain consensus layer, and physical network layer. The system architecture corresponding to each partition (e.g., partition 1, partition 2, partition 3) includes: storage layer, execution layer, consensus layer, and logical network layer. This is understandable. Figure 2 This only illustrates a theoretical hierarchical structure model, representing the necessary content for storage, execution, consensus, and network transmission. It does not imply the existence of a corresponding hierarchical structure in actual implementation. It can be implemented in various ways, and no constraints are imposed here.

[0032] Understandably, due to the different security levels of each partition, each partition stores security data using different account systems. Partitions can be homogeneous or heterogeneous, meaning they can employ different storage structures, smart contracts, and consensus algorithms for business implementation. Different storage structures, smart contracts, and consensus algorithms can be selected based on the business needs of different scenarios. Furthermore, for each partition, a dedicated encryption algorithm and key management library can be designed during data storage to ensure that each partition uses a different key for encryption. Even if a key is leaked, only the on-chain data of that corresponding partition will be compromised, without affecting the security level data of the entire blockchain, thus minimizing the loss of data security. In some implementations, relay nodes can be used for communication between the main chain and partitions. The relay node acts as both a "communicator" for each partition and a consensus node for the main chain.

[0033] The following is a detailed introduction to the account system for each zone.

[0034] (1) Account system.

[0035] As mentioned above, each main chain node can store both global data for the main chain and security-level data corresponding to the security level of its respective partition. Furthermore, global data and security-level data can correspond to different independent account systems, allowing main chain nodes to store both global and security-level data simultaneously. The account systems also differ between different partitions.

[0036] In some embodiments, each main chain node in a partition includes: a public ledger, a public account system corresponding to the public ledger, and a privacy ledger, a privacy account system corresponding to the privacy ledger; wherein, the public ledger and the public account system are independent ledgers and account systems corresponding to global data; the privacy ledger and the privacy account system are independent ledgers and account systems corresponding to the security level data of their respective partitions; and the privacy ledger and the privacy account system of main chain nodes belonging to the same partition are the same, while the privacy ledger and the privacy account system of main chain nodes in different partitions are different.

[0037] For example, continue to refer to Figure 1 Main chain nodes 1-4 correspond to the privacy account system ledger-NS1, and main chain nodes 5-8 correspond to the privacy account system ledger-NS2.

[0038] Understandably, each partition is also configured with its own independent data ledger and account system, which isolates the data between different partitions, thereby enabling hierarchical and permission-based data storage, ensuring both high confidentiality and high data integrity.

[0039] Understandably, the main chain node needs to include not only global data, but also data related to security-level data.

[0040] In some implementations, the block data of a partition includes a block header and block information. The block information includes a global ledger and a privacy ledger related to classified data. The privacy ledger includes at least: the classified data, the corresponding security level, and the storage path of the original data when it is stored locally off-chain, thus addressing the issue of secure storage of classified data at the storage layer.

[0041] Specifically, the original block data structure mainly includes two parts: the block header and ledger information (transaction list). Based on the original block's ledger information, a privacy ledger is constructed using the transaction retention field within the ledger information. Accounts with a certain security level encrypt and store confidential data in this field using a specific data format, resulting in a privacy ledger that includes security-graded data. The data in the privacy ledger can only be accessed by blockchain distributed accounts holding the same or higher security level. On-chain storage includes the hash value, storage path, on-chain time, and publishing account information of the security-grade data, while off-chain storage stores the original information of the security-grade data, and this off-chain data is only stored locally on the publishing node.

[0042] For example, Figure 3 This diagram illustrates the contents of a block data structure. For example... Figure 3As shown, block data consists of two block headers and block information. The block header records chained block data, including the block hash, parent block hash, contract state hash, transaction set hash, receipt hash, version information, block number, and block timestamp. Block information includes the global ledger and the privacy ledger. The global ledger may include transaction hashes, version information, transaction initiator addresses, transaction recipient addresses, contract call information, transaction timestamps, reserved transaction fields, random numbers, and user signatures. The privacy ledger stores the specific content of reserved transaction fields. Specifically, the privacy ledger may include transaction hashes, version information, security level, security period, transaction initiator addresses, transaction recipient addresses, contract call information, transaction timestamps, user signatures, security level data, previous version hash, and tuple information.

[0043] (2) The following is a brief introduction to the access process during block transactions.

[0044] Understandably, each account in a blockchain system is associated with a security level. The allowed access targets corresponding to the security level data in the privacy ledger are: accounts that meet the first security level access condition. The first security level access condition is: the account's security level is greater than or equal to the security level corresponding to the security level data in the privacy ledger. The security level is directly proportional to the degree of confidentiality. Understandably, each account is associated with a unique security level identifier to represent its security level. Based on the account's security level identifier, the account's security level and the corresponding verifiable credentials can be determined.

[0045] For example, when an account needs to store data, a verifiable credential with the same security level as the account can be generated based on the account's security level identifier. This allows the account to store the data in a partition corresponding to the security level based on the generated credential. When an account needs to access data, a verifiable credential with a security level less than or equal to the account's security level identifier can be generated based on the account's security level identifier. This allows the account to access the data at the corresponding security level based on the generated credential. For instance, if the account's security level is 3, and the account has 3 verifiable credentials: one credential corresponding to security level 1, one corresponding to security level 2, and one corresponding to security level 3.

[0046] In some implementations, privacy account systems can be built upon distributed digital identity account systems, using verifiable credentials with zero-knowledge proofs to authenticate access to classified data. As can be understood, a distributed account system is a new type of digital account system based on blockchain technology, enabling digital identity authentication and control, trusted verification of identity information, and cross-domain, cross-chain use of identity attributes. Adopting a distributed account system can effectively reduce the risk of identity leakage, improve the reusability of identity proofs, and solve the problems of easy leakage, difficulty in interoperability, and difficulty in collaboration of identity information.

[0047] Specifically, a distributed account system consists of three parties: the issuer, the holder, and the verifier. In some implementations, the holder, issuer, and verifier, based on the account's verifiable credentials, perform on-chain storage and data retrieval of the account's security level data. The account's verifiable credentials are related to the account's security level.

[0048] Understandably, storing account information on the blockchain allows for the recording of account management information, enabling users to self-manage their accounts. Furthermore, verifiable credentials can also be stored on the blockchain. These verifiable credentials, issued by trusted issuing authorities, represent identity and permissions, and users can manage and use them for trusted verification. Verifying parties can use the blockchain to perform trusted verification of all or some attributes of the verifiable credentials presented by users, allowing for cross-regional use of identity attributes. When performing trusted verification of all or some attributes of identity attributes based on verifiable credentials, fine-grained access control technology based on smart contracts can be employed to achieve precise access control for each piece of data resource uploaded to the blockchain, thus enabling precise access control for each piece of data resource uploaded to the blockchain.

[0049] Understandably, classified data stored in partitioned storage is data with high security requirements. The distributed account system ensures the verification of verifiable credentials issued in different partitions, making identity attribute credentials reusable and providing a foundation for cross-partition and cross-application access to classified data. Fine-grained access control technology based on smart contracts avoids the problem that, in current mainstream blockchains, most block transaction data corresponding to each partition is stored in plaintext, allowing any user to access and view this data, thus failing to achieve fine-grained controlled access to resources.

[0050] In some embodiments, when the holder is the entity to which the first account needs to store classified data belongs, the blockchain system acts as the verifier, the authoritative institution acts as the issuer, and the classified data of the first account is stored on the blockchain in the following manner: the blockchain system obtains the holder's on-chain request, which includes the transaction to be uploaded to the blockchain for the first account, the target verifiable credential of the first account, and the identity information of the first account; the target verifiable credential is a verifiable credential corresponding to the classification level of the partition to be stored; the encrypted on-chain smart contract is invoked, and the transaction data to be uploaded to the blockchain is encrypted using the public key of the target verifiable credential in the keystore to obtain the encrypted classified data; and the encrypted classified data is stored on the blockchain.

[0051] Furthermore, in other embodiments, when the holder is the entity that needs to access the classified data of the first account, the blockchain system acts as the verifier, the authoritative institution acts as the issuer, and obtains the classified data of the first account in the following ways: It obtains the holder's data request, which includes a verification credential obtained by the holder from the issuer, the holder's identity information, and a data hash, wherein the verification credential is used to access the classified data of the first account; it calls the decryption smart contract to verify the verification credential and identity information, and after successful verification, calls the private key corresponding to the verification credential in the keystore to decrypt the classified data of the first account, obtaining the decrypted classified data.

[0052] Understandably, the keystore stores several sets of VC certificates (verification credentials) and their corresponding public-private key pairs. Each user holding a VC certificate encrypts data using the public key corresponding to that VC certificate when uploading data to the blockchain, and decrypts it using the private key of the user's VC certificate when reading data. Both encryption and decryption are handled by smart contracts; consistent VC certificates ensure consistent data access. Conversely, inconsistent certificates prevent data retrieval. Through fine-grained access control based on smart contracts, secure storage and access control of confidential data can be achieved, with encryption and decryption controls refined to every single transaction and piece of data on the blockchain. Since each transaction uses a different key for encryption and decryption, data security and integrity are fully guaranteed.

[0053] The following is combined Figure 4 Explain the process of access control based on smart contracts.

[0054] like Figure 4 As shown, the blockchain includes partitions 1, ..., partition n, partition n+1, ..., which correspond to blocks 1, ..., block n, block n+1, ..., respectively. Each block contains a block header and corresponding block information. The process of uploading data to the blockchain is illustrated using the example of storing a transaction (transaction 1) from a specific account on the blockchain.

[0055] ① User submits data to the blockchain: The user is account 1, and is the data holder. The holder obtains verifiable credential 1 from the issuer and sends a data upload request to the blockchain system. The upload request includes transaction 1, verifiable credential 1 of account 1, and identity information of account 1. The security level of verifiable credential 1 is equal to the security level of the account.

[0056] ② Obtain the encryption public key: The key store contains multiple sets of VC certificates and their corresponding public and private key pairs, such as VC certificate VC1, public key PK1, VC certificate VC2, public key PK2, VC certificate VC3, public key PK3. The blockchain system calls the encrypted on-chain smart contract to obtain the public key (PK1) corresponding to the verifiable credential 1 (assuming it is VC1) from the key store and encrypt transaction 1.

[0057] ③ Encrypted data on the blockchain: The encrypted on-chain smart contract encrypts transaction 1 using a public key to obtain encrypted data.

[0058] ④ Ciphertext on-chain: The encrypted security-level data is stored on the blockchain in ciphertext form in the block corresponding to the security level of the data.

[0059] For example, suppose a user's security level is Cu, and the block to be stored corresponding to the security level is determined. The tuple to be inserted (i.e., the record to be added to the chain) is s. The rules for adding security-level data to the chain are as follows: First, check if tuple s satisfies entity integrity and null value integrity. If not, the insertion fails. Second, if tuple s satisfies entity integrity and null value integrity, and if tuple s contains a version of the data to be inserted, the newly inserted data checks referential integrity. If not, the insertion fails. Third, if tuple s contains a version of the data to be inserted, the newly inserted data must point to the hash of the previous version and increment the version number sequentially. Fourth, security-level data storage supports an on-chain hash and off-chain raw data storage mode. On-chain data is stored in a privacy ledger. To ensure data consistency and visibility, the raw data is encrypted and stored off-chain, and only one data instance is stored on the local node during publication. In the above rules, the first step is to ensure entity integrity and null value integrity, the second step is to ensure referential integrity, and the third step is to ensure multi-instance integrity.

[0060] ⑤ Requesting Encrypted Data: When a user wants to view this transaction (i.e., the encrypted data on the blockchain), they need to first apply to an authoritative institution (i.e., the issuer) for a VC certificate to access the transaction. Understandably, the obtained VC certificate is based on the user's security level. When requesting data, the VC certificate, identity information, and data hash are sent together to the decryption smart contract that invokes the data request.

[0061] ⑥ Obtain the decryption private key. After receiving the request, the decryption smart contract verifies the VC certificate (e.g., confirms it to be VC1) and identity information. If successful, it retrieves the private key corresponding to the VC certificate from the keystore.

[0062] ⑦ Decrypt on-chain data. The smart contract retrieves the required on-chain data from the block storing the corresponding security level data and decrypts it based on the private key. If decryption is successful, the decrypted plaintext data is obtained.

[0063] Understandably, let's assume a user's security level is Cu, and the security level of the block containing the data to be read is Su. The rules for reading this data are as follows: First, check if the user's security level Cu falls within the security level range corresponding to Su. If not, the read operation is rejected. Second, if the user's security level Cu meets the security requirements, the data is read and decrypted using the private key obtained from the keystore.

[0064] Furthermore, to ensure the reliability of data transmission between data providing nodes and data access nodes, an encrypted privacy channel can be established, and the classified data can be further encrypted to achieve point-to-point transmission of classified data. After transmission, the data access node verifies data consistency and does not store the encrypted instance of the classified data. It then decrypts the classified data received through the encrypted channel using the security certificate held by the accessing user, reading the metadata. Finally, the classified data access record must be stored on the blockchain, completing one data retrieval process.

[0065] (2) Privacy channel.

[0066] As mentioned above, to ensure the reliability of data transmission between data providing nodes and data accessing nodes, an encrypted privacy channel can be established, and then the classified data can be encrypted again to achieve point-to-point transmission of classified data. The privacy channel will be explained in detail below.

[0067] Specifically, when nodes communicate, the transport layer between nodes can adopt the Protobuf network communication and data exchange format to serialize the classified data. Then, a secure encrypted channel is established between the two parties using TLS for point-to-point data transmission. This ensures both high efficiency and security of data transmission. After the data is exchanged, it remains encrypted. The accessing party needs to undergo additional authentication at a different classification level and decrypt the data using the corresponding encrypted certificate key to obtain the original data. At this point, only the publishing node stores the confidential data related to the required classification level. The accessing party can only authorize access to and read the required confidential data, without storing the confidential data on the accessing node. The accessing node can also write new confidential data to the corresponding classification level partition, but cannot write confidential data to the main chain or other sub-chains with different classification levels. Based on the above transmission mechanism, the access process for confidential data is secure. Data exchange between partitions uses relay nodes for communication. Due to channel encryption and data encryption, data packets transmitted across chains are secure.

[0068] also, Figure 5According to some embodiments of this application, a data architecture diagram corresponding to a database structure for data storage is shown. It is understood that the database may include a master database and slave databases, where the master database can be used to store global data, and the slave databases are used to store confidential data related to classified data. The master and slave databases can be configured based on user permissions and indexing. Furthermore, the master and slave databases can record data throughout its entire lifecycle, and indexing can accelerate data retrieval. The master database can also serve as the system's sole data write entry point, uniformly performing entity integrity, null value integrity, and referential integrity checks on incoming data, intercepting data writes that do not conform to the rules, and ensuring and resolving data integrity issues in the distributed blockchain system from the data source. Slave databases can be further configured based on the attributes of classified data, thereby creating a multi-level database. For example, a slave database can also include a classified source data database and a classified metadata database. The classified source data database can be used to record classified source data (i.e., the specific data content of classified data), and the classified metadata database can be used to record classified metadata (i.e., the metadata of classified data). Multi-level databases can solve data confidentiality issues. When data needs to be read, it can be done based on user permissions and the index. For classified data, different classification source databases and classification metadata databases can correspond to different classification levels, resulting in master-slave tables for different classification levels (one master node corresponds to one classification level master-slave table). For example, there can be classification level 1 master-slave tables, classification level 2 master-slave tables, classification level 3 master-slave tables, ..., classification level n master-slave tables. Generally, the classification level master table is used to store newly added classification level data, and the slave tables are used to store updated or deleted classification level data. When operating on data in the database, it is necessary to check the data classification level and the permissions of the user performing the write operation.

[0069] It is understandable that the embodiments of this application can improve response efficiency while ensuring hierarchical storage and access control, and ensure that critical data still has high availability under strict security constraints.

[0070] Understandably, the embodiments of this application implement a multi-level secure data model on a single chain through a parallel architecture with multiple partitions, which simultaneously has high confidentiality, high data integrity and high data availability, thereby achieving confidentiality requirements while meeting data integrity requirements.

[0071] It is understood that the application scenarios of this application include, but are not limited to, data storage, data exchange, finance and taxation, law and order, BeiDou Navigation Satellite System, distributed computing, logistics storage, and collaborative operations. In particular, for government, enterprise, and military scenarios, there are a large amount of classified data and sensitive information. Different types of data have different classification levels, different confidentiality periods, and different confidentiality requirements. In this case, the method based on the embodiments of this application can ensure data integrity while meeting high confidentiality requirements. Figure 6 This is a structural block diagram of an electronic device provided in an embodiment of this application. The electronic device may include: a memory 110, a processor 120, and a communication interface 130. The memory 110, processor 120, and communication interface 130 are connected via internal connection paths. The memory 110 is used to store computer programs; in some implementations, the computer program may include code for implementing the methods of the embodiments of this application.

[0072] The processor 120 executes the computer program stored in the memory 110 to control the communication interface 130 to receive input data and information, and output operation results and other data. In some implementations, when the solutions of the embodiments of this application are implemented by software or firmware, the computer program used to implement the solutions of the embodiments of this application can be stored in the processor 120 and executed by the processor 120.

[0073] The memory 110 may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory may be random access memory (RAM). It should be noted that the memory 110 described herein is intended to include, but is not limited to, any memory of these and other suitable types. As an example, the memory 110 includes random access memory (RAM), cache memory, and read-only memory (ROM). The memory 110 stores a computer program that can be executed by processor 120, causing processor 120 to implement the steps of any of the methods described above.

[0074] This application also provides a blockchain system, which includes multiple main chain nodes, a processing unit, and a storage unit. The storage unit stores computer programs / instructions, and the processing unit executes the blockchain management method of any of the above embodiments based on the computer programs / instructions.

[0075] This application also provides a computer program product, characterized in that it includes a computer program / instruction, which, when executed by a processor, implements the blockchain management method of any of the above embodiments.

[0076] It should be noted that all units / modules mentioned in the device embodiments of this application are logical units / modules. Physically, a logical unit / module can be a physical unit / module, a part of a physical unit / module, or a combination of multiple physical units / modules. The physical implementation of these logical units / modules themselves is not the most important factor; the combination of functions implemented by these logical units / modules is the key to solving the technical problems proposed in this application. Furthermore, to highlight the innovative aspects of this application, the above-described device embodiments of this application have not introduced units / modules that are not closely related to solving the technical problems proposed in this application. This does not mean that the above-described device embodiments do not contain other units / modules.

[0077] It should be noted that, in the examples and description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, 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, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0078] Although this application has been illustrated and described with reference to certain embodiments thereof, those skilled in the art should understand that various changes in form and detail may be made thereto without departing from the spirit and scope of this application.

[0079] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A blockchain management method applied to a blockchain system, the blockchain system comprising a main chain, characterized in that, The method includes: The main chain nodes corresponding to the main chain are divided into M partitions, each partition corresponds to a security level, and the total number of main chain nodes in each partition is greater than or equal to 4; M is an integer greater than or equal to 2. In addition to storing global data on the main chain, each main chain node in the partition is also used to store security level data corresponding to the security level of its respective partition.

2. The method according to claim 1, characterized in that, The method further includes: Retrieve new data; Based on the security level of the newly added data, the newly added data is written into the partition corresponding to the security level of the newly added data.

3. The method according to claim 1, characterized in that, Each of the partitions contains the following main chain nodes: A public ledger, and the public account system corresponding to the public ledger; and a privacy ledger, and the privacy account system corresponding to the privacy ledger. The public ledger and the public account system are independent ledgers and account systems corresponding to the global data. The privacy ledger and the privacy account system are independent ledgers and account systems corresponding to the security level data of the respective partition; Furthermore, the privacy ledger and privacy account system of main chain nodes belonging to the same partition are the same, while the privacy ledger and privacy account system of main chain nodes in different partitions are different.

4. The method according to claim 3, characterized in that, The block data of the partition includes a block header and block information with the privacy ledger, wherein the privacy ledger includes at least: the security level data, the security level corresponding to the security level data, and the storage path of the original data corresponding to the security level data when it is stored locally off-chain.

5. The method according to claim 3, characterized in that, Each account in the blockchain system is associated with a security level. The allowed access objects corresponding to the security level data in the privacy ledger are: accounts that meet the first security level access conditions. The first security level access conditions are: the security level of the account is greater than or equal to the security level corresponding to the security level data in the privacy ledger. The size of the security level is proportional to the degree of confidentiality.

6. The method according to claim 4, characterized in that, The privacy account system is a distributed account system, and the distributed account system includes: issuer, holder and verifier; The holder, the issuer, and the verifier perform on-chain storage and data retrieval of the account's security level data based on the account's verifiable credentials, wherein the account's verifiable credentials are related to the account's security level.

7. The method according to claim 6, characterized in that, When the holder is the entity owning the first account that needs to store classified data, the blockchain system acts as the verifier, the authoritative institution acts as the issuer, and the classified data of the first account is stored on the blockchain in the following manner: Obtain the on-chain request from the holder, wherein the on-chain request includes the transaction to be on-chain for the first account, the target verifiable credential for the first account, and the identity information of the first account; the target verifiable credential is a verifiable credential corresponding to the security level of the partition to be stored. The encrypted on-chain smart contract is invoked, and the public key corresponding to the target verifiable credential in the key store is used to encrypt the transaction data to be uploaded to the chain, so as to obtain the encrypted security level data. The encrypted security data is then stored on the blockchain.

8. The method according to claim 6, characterized in that, When the holder is the entity that needs to access the confidential data of the first account, the blockchain system acts as the verifier, the authoritative institution acts as the issuer, and the confidential data of the first account is obtained through the following methods: Obtain the data request from the holder, the data request including the unverified credential obtained by the holder from the issuer, the holder's identity information and data hash, wherein the unverified credential is used to access the security-level data of the first account; The decryption smart contract is invoked to verify the credential to be verified and the identity information. If the credential to be verified and the identity information are successfully verified, the private key corresponding to the credential to be verified in the key store is invoked to decrypt the security data of the first account, thereby obtaining the decrypted security data.

9. The method according to claim 1, characterized in that, The method further includes: The classified data is transmitted from a first node to a second node via a privacy channel. The first node is a data provider node in the main chain that provides the classified data, and the second node is a data access node that needs to access the classified data. The privacy channel is used to encrypt the classified data to be transmitted.

10. A blockchain system comprising multiple main chain nodes, a processing unit, and a storage unit, wherein the storage unit stores computer programs / instructions, and the processing unit executes the blockchain management method of any one of claims 1 to 9 based on the computer programs / instructions.

11. A computer program product, characterized in that, It includes a computer program / instruction that, when executed by a processor, implements the blockchain management method of any one of claims 1 to 9.

Images