Business environment-oriented enterprise-level composite blockchain construction method

Abstract

The present application relates to a business environment-oriented enterprise-level composite blockchain construction method, belonging to the field of blockchain data storage. The present application uses on-chain and off-chain data cooperation to store enterprise original data. First, an improved hash function SHA256 algorithm is introduced to encrypt enterprise original data, and the data is stored in an off-chain Level DB database based on non-volatile memory, so as to reduce the communication and storage pressure of the system. Then, the data is stored on the chain, and the Key values in the Level DB are stored in the Conflux public chain based on DAG in the composite blockchain, and the enterprise state data is stored in the consortium chain in the composite blockchain, providing credible evidence data for business environment evaluation, effectively improving the read-write performance of the off-chain Level DB and the storage efficiency of the on-chain composite blockchain, and reducing the storage overhead of the on-chain composite blockchain.

Description

Technical Field

[0001] This invention belongs to the field of blockchain data storage, and specifically relates to the design of blockchain storage systems, and more specifically to the design of an enterprise-level composite blockchain integrated and optimized storage system oriented towards the business environment. Background Technology

[0002] According to the World Bank's definition, the business environment refers to the sum of time and costs incurred by businesses throughout their entire lifecycle, from startup to closing, including compliance with policies and regulations in areas such as permitting construction, obtaining electricity and credit, property registration, contract enforcement, intellectual property protection, cross-border trade, taxation, bankruptcy, and contract enforcement. It encompasses social, economic, political, and legal factors that influence business activities, and is a systematic project involving policy reforms across numerous areas such as openness to the outside world and horizontal and vertical communication. A favorable business environment accelerates urban economic development and contributes to the city's continuous growth. Therefore, to better evaluate the business environment, it is essential to store data generated at each stage of a business's lifecycle, from startup to closing, as evidence for the evaluation. Blockchain technology, with its decentralized, immutable, and traceable characteristics, offers significant advantages in ensuring data security and integrity, which aligns perfectly with the urgent need for improved data authenticity and security in business environment evaluations.

[0003] Unlike other systems, information stored in a blockchain is shared among network members, and through cryptographic methods, it is virtually impossible to delete or manipulate the recorded information. Blockchain technology possesses unique advantages such as decentralization, tamper-proofing, traceability, high trustworthiness, openness, independence, stability, accuracy, and efficiency. These advantages contribute to increased productivity, savings in time and money, guaranteed data security, and rapid access to information. Therefore, blockchain technology has been widely applied in various fields such as finance, public services, the Internet of Things, cybersecurity, and supply chains. However, traditional blockchains have shortcomings in throughput, transaction confirmation speed, and scalability, making them difficult to implement in some short-term, high-concurrency data scenarios.

[0004] Existing enterprise-level composite blockchain construction methods for the business environment have several shortcomings: some methods suffer from write pauses, write amplification, and poor read-friendliness in Level DB optimization; others suffer from low throughput, slow confirmation speed, and poor scalability in traditional blockchain construction and storage. Therefore, designing an efficient enterprise-level composite blockchain construction method for the business environment is of great significance for the efficient storage of big data in enterprises within the business environment. Summary of the Invention

[0005] To address the shortcomings of existing enterprise-level blockchain storage systems for the business environment, this invention provides a method for constructing an enterprise-level composite blockchain for the business environment, which can effectively store data on business entities and their activities within the business environment.

[0006] This invention is achieved through the following technical solution: a method for constructing an enterprise-level composite blockchain for the business environment, comprising the following steps:

[0007] Step 1: Constructing an Enterprise-Grade Composite Blockchain Architecture: The enterprise-grade composite blockchain architecture consists of a LevelDB database, a public blockchain, and a consortium blockchain. Off-chain, the LevelDB database stores the enterprise's original data information; the value is the original data, and the key is the hash value encrypted using the SHA256 algorithm. On-chain, the public blockchain, responsible for transactions, stores the key values ​​corresponding to the enterprise's original data in the LevelDB database, while the consortium blockchain, responsible for state, stores the enterprise's state data. Through this architecture, on-chain and off-chain data collaboration is achieved. The on-chain expands its computing and storage capabilities through off-chain resources, and the off-chain and on-chain interfaces enable the sharing of heterogeneous information.

[0008] Step Two: Before storing the original data in the off-chain Level DB database, the enterprise's original data is encrypted using the SHA256 hash function. This allows verification of whether the original data has been tampered with when querying data for business environment assessments. The hash function transforms arbitrarily long messages into shorter, fixed-length message digests. This digest serves as the key in a key-value pair, with the value corresponding to the original data. This digest is stored in the key-value database Level DB, while the corresponding key is stored in the Conflux public blockchain within the enterprise-level composite blockchain. To further enhance data security, the number of operations in the data block hashing operation is increased based on the SHA256 hash function, and the algorithm logic and compression function are improved to enhance collision resistance and reduce the avalanche effect of the hash results.

[0009] The SHA256 algorithm uses six logical functions and a set of constants K. t The input is a 512-bit message block x i Then it is divided into 16 groups of 32-bit words M0, M1, ..., M 15The output is a 256-bit message digest. In improving the SHA256 algorithm, firstly, 16 operations are added to the hash operation of each 512-bit data block to ensure that each bit of the message can affect more bits, further improving the algorithm's non-linear diffusion. Then, the complexity of the SHA256 algorithm logic and compression function is increased to accelerate the differential diffusion of the message, making the recursive process more "random" and thus eliminating the compliance conditions for local collisions.

[0010] The specific execution process of the improved SHA256 algorithm includes:

[0011] 2.1) For message block M (i) For i = 1, 2, ..., N, perform the following loop:

[0012] 2.1.1) Prepare message list W t :

[0013]

[0014] W t =W t-4 +σ0(W t-9 )+σ1(W t-12 )+W t-16 (16≤t≤79)

[0015] 2.1.2) Initialization of working variables:

[0016]

[0017]

[0018] In the formula, A to H represent eight working variables, each with a length of 32 bits. This represents the hash value from the previous calculation. When i = 1, The initial value is a constant and can be randomly selected. Referring to the unmodified SHA256 algorithm, it is set as follows:

[0019]

[0020]

[0021] 2.2) When 0 ≤ t ≤ 79, execute the following compression function:

[0022] T1=h+∑0(e)+Ch(e,f,g)+K t +W t

[0023] T2=∑1(a)+M aj (a,b,c)

[0024] h=g+T1,g=f+T2,f=e+T1,e=d+T2,d=c+T1,c=b+T2,b=a+T1,a=T1+T2

[0025] In the formula, T1 and T2 are intermediate variables, and the compression function uses 80 32-bit words of K. t {256} (0≤t≤79) constant sequence.

[0026] The improved SHA256 algorithm uses six logical functions, each based on a 32-bit word (x, y, z), to perform operations. The result of each logical function is a new 32-bit word, as defined below:

[0027]

[0028]

[0029]

[0030]

[0031]

[0032]

[0033] Through the above-mentioned improved process, the SHA256 algorithm is made more unidirectional, nonlinear, pseudo-random, collision-resistant, and avalanche-effect-resistant. The improved hash function SHA256 algorithm is used to encrypt the enterprise's original data and generate the corresponding hash value as the key value in the off-chain Level DB database for subsequent storage operations.

[0034] Step 3: Constructing an off-chain Level DB storage model based on NVM: After encryption calculation using the improved SHA256 hash function, the hash value of the encrypted enterprise data is used as the key, and the original data is used as the value, which are then stored in the off-chain key-value database Level DB. Level DB is a key-value non-relational database storage system based on the LSM-tree architecture. Due to its advantages such as fast write speed and small space consumption, it has been widely used in many fields. However, the LSM-tree architecture has disadvantages such as write pauses, write amplification, and poor read performance. Therefore, this invention proposes an LSM-tree storage model based on NVM.

[0035] This invention places the L0 layer of the original LSM-tree architecture on NVM, and the L1 layer to L...n The layer is stored on SSD to solve the write latency problem during data merging, and a learning index is introduced for the L0 layer files to make the L0 layer files ordered and reduce read latency, thereby improving the speed of finding the location of data in the L0 layer files.

[0036] NVMTable is divided into three types of blocks based on its stored content: Super Block, Meta Block, and Entry Block. The Super Block is the first block of each NVMTable and is responsible for storing the file's metadata. Its attribute fields are shown in Table 1. The Entry Block is responsible for storing key-value pairs or pointer pairs. The Meta Block is responsible for storing 1024 bitmap information indicating whether the key or value stored in the Entry Block is actual data or a pointer.

[0037] Table 1: Storage Field Reference Table

[0038]

[0039] When Minor Compaction occurs—that is, when the Immutable MemTable is written to disk L0 and its format is changed to SSTable—data needs to be written to NVMTable. At this time, NVMTable and Container files are created. During the data write operation, it is first determined whether the length of the key-value pair to be written is shorter than 32 bytes. If so, it is inline data and is written directly to the Entry Block; otherwise, the corresponding data pointer in the Container file is written to the Entry Block. Then, while writing data to the Entry Block, a Meta Block is created in memory until no more data is written to NVMTable. Next, the Meta Block in memory is appended to the end of the file, and finally, the Super Block at the beginning of the file is updated to complete the write operation.

[0040] This invention also proposes using a learned index at the NVM layer to predict the location of data using the learned model, thereby accelerating the data retrieval speed in the NVM. By learning the index, the location of a specific key in the L0 layer can be found. First, each NVMTable needs to learn an index model independently, and then establish an approximate mapping from key to data location. Next, starting from the approximate mapping location, a comparison is made with the target key, and the correct location is determined through a linear search forward or backward. This invention chooses the PGM index for location positioning. The PGM index is a multi-level structure, where each level represents a piecewise simple linear regression with different lower bounds for error rates. The piecewise linear regression divides the data into n+1 segments, containing a set of points p0, p1, ..., p n The entire piecewise linear regression can be represented as the following piecewise function:

[0041]

[0042] In the first level of the PGM index, the data is divided into three partitions, each represented by a simple linear model (f1, f2, f3). By constructing these linear models, each model can predict the corresponding key value within its respective partition using a pre-defined error value. Then, the partition boundary of the first level is used as its own sorted dataset, and another piecewise linear regression with bounded error is calculated. This process is repeated until the top-level PGM becomes sufficiently small. The PGM index is built from the bottom up, first selecting an error boundary, and then using a minimal piecewise linear model to reach this error boundary. This step is repeated until the piecewise model is smaller than a threshold. Each regression in the PGM index uses a fixed error bound, which is treated as an approximate index and applied recursively. First, a piecewise regression model is constructed using the underlying data, and then another piecewise regression with a fixed error is constructed using the partition point of the first regression. Key lookup involves searching for each regression model until the underlying data is found.

[0043] Step 4: Constructing the Conflux public chain in an enterprise-grade composite blockchain: Starting from the special structure of a directed acyclic graph (DAG), the Conflux consensus protocol based on the backbone chain is used to construct the Conflux public chain;

[0044] Traditional public blockchains have shortcomings in scalability, throughput, and transaction confirmation latency. To improve blockchain performance, this invention starts from the special structure of Directed Acyclic Graphs (DAGs) and adopts the Conflux consensus protocol based on the backbone chain to construct the Conflux public blockchain in an enterprise-grade composite blockchain.

[0045] Transactions in Conflux consist of key values ​​corresponding to the original enterprise data in the off-chain Level DB database. Each transaction has a unique ID generated by a cryptographic digest function to ensure its integrity. A block consists of a list of transactions and references to previous blocks. Each block also has a unique ID generated by a cryptographic digest function to ensure data integrity. Conflux starts with a predefined genesis block to determine the initial state of the blockchain. All blocks and edges form a Directed Acyclic Graph (DAG). Due to network latency, the DAG structure may differ between nodes for short periods; Conflux's ultimate goal is to maintain consistency among nodes. All participating nodes in Conflux are connected via a Gossip network. Whenever a node initiates a transaction, it broadcasts the transaction to all other nodes via the Gossip network. Whenever a node generates a new block, it also broadcasts this block to all other nodes via the network.

[0046] In Conflux, each node maintains a pool of pending transactions, containing all transactions that have been broadcast to the node but have not yet been included in any blocks. Whenever a node receives a new transaction from the Gossip network, it adds that transaction to its pool. Whenever a node discovers a new block (whether by generating a block or receiving a block from another node), it removes all transactions from its pool of pending transactions. Due to network latency and malicious nodes, concurrent blocks may include duplicate or conflicting transactions, which are resolved by the consensus protocol. Each node in Conflux runs a block generator to produce valid new blocks to include pending transactions. Each node maintains a local state containing all blocks that it has become aware of through broadcasting. Whenever a node discovers a new block, whether by generating or receiving it, it updates its local DAG state accordingly.

[0047] The underlying block data structure of the Conflux public blockchain adopts a tree graph format, which accelerates the block generation speed of the entire blockchain through parallel processing and does not reduce its security due to forks. This allows each enterprise to upload transactions in parallel, i.e., the hash value corresponding to the enterprise's original data, ultimately enabling the entire system to process blocks and transactions more efficiently.

[0048] The Conflux public blockchain operates using a novel consensus protocol that optimistically handles concurrent blocks without discarding any as forks. In Conflux, each block, except for the genesis block (Genesis), has an out-degree parent edge representing the voting relationship between blocks. For example, there's a parent edge from C to A. Each block can have multiple out-degree reference edges, representing the order in which blocks were generated. For example, an edge from E to D indicates that D was generated before E. All parent edges in the Directed Acyclic Graph (DAG) together form a parental tree, with the genesis block as the root. Within the parental tree, Conflux selects a chain from the genesis block to one of its leaf blocks as the main chain. Unlike the longest chain, Conflux uses the Ghost protocol to select the main chain, starting from the Genesis block, calculating the subtree size of each node, and choosing the node with the largest subtree as a node in the main chain.

[0049] Whenever a node generates a new block, it first computes the main chain in its local DAG state and sets the last block in the main chain as the parent block of the new block. Then, it searches the DAG for all end blocks without in-degree edges and creates referencing edges from the new block to each end block. Given a pivot chain starting from the genesis block and containing only parent edges, the sorting algorithm uses the pivot chain to divide all blocks in the DAG into epochs, with each block on the pivot chain corresponding to an epoch. Blocks in each epoch have the following constraints: 1) they are reachable from the corresponding block on the pivot chain via a combination of parent and referencing edges, including the pivot chain block itself; 2) they are not included in previous epochs.

[0050] When determining the overall block order through consensus, Conflux first sorts the blocks according to their corresponding epochs, and then sorts the blocks within each epoch according to their topological order. When determining the transaction order, the order of transactions is determined by the Block Total Order of the block containing the transaction. If two transactions are in the same block, they are sorted according to their appearance order. While sorting the orders, Conflux checks for transaction conflicts; if two transactions conflict, Conflux discards the second transaction. If a transaction appears in multiple blocks, Conflux retains only the first occurrence and discards all other transactions. Following this process, the key values ​​corresponding to the raw data uploaded by the enterprise are then processed for on-chain data storage.

[0051] Step 5: Constructing the Hyperledger Fabric Consortium Blockchain in an Enterprise-Grade Composite Blockchain: The consortium blockchain module of an enterprise-grade composite blockchain is responsible for storing the state data of the enterprise throughout its entire process from establishment, operation, to termination. Due to the large number of enterprises, to significantly reduce network resource consumption, this invention selects a certain number of verified pre-selected nodes to build the consortium blockchain, and uses these pre-selected nodes to implement consensus algorithms, public verification, and secure data storage. The consortium blockchain module is implemented using the Hyperledger Fabric framework, a well-known representative of consortium blockchains. The Hyperledger Fabric architecture mainly consists of four modules: member management services, blockchain services, smart contracts, and event streams.

[0052] Member management services ensure the identity mechanism for accessing the Fabric platform, providing services for member registration, management, and verification; blockchain services, as the core architecture of Fabric, mainly provide services for P2P protocols for inter-node communication, distributed ledgers for nodes, databases for ledger storage, and consensus mechanism management for ledgers; smart contract services mainly include clients implementing corresponding business logic operations by calling functions in chaincode; event streams mainly provide asynchronous communication functions for various components in Fabric, increasing Fabric's flexibility.

[0053] Once the triggering conditions for contract execution are met, the smart contract will automatically access and share the data, and perform data output, sharing, and other operations according to the defined constraints. The operation of the consortium blockchain responsible for state data storage mainly includes the function of storing state data. The symbols used in the storage process and their meanings are shown in Table 2.

[0054] Table 2: Symbol Content Comparison Table

[0055]

[0056] The specific execution process of storing the state data includes:

[0057] 5.1) System Initialization: First, each enterprise node needs to be authenticated by the regulatory agency node. After successful authentication, it becomes a legitimate consortium blockchain network node; then, it obtains... These represent the public and private key pairs used for encrypting data and their certificates, respectively; finally, the system initialization is performed, and the enterprise node downloads the current consortium blockchain's block data storage location index table from the record pool of the neighboring enterprise headquarters node.

[0058] 5.2) Status data upload: First, enterprise node N... i To local corporate headquarters nodes BS j Send an upload request, the request includes N i Currently in use And a digital signature Sig_1 is used to ensure the reliability and authenticity of the data source; then, BS j Receive and verify N i The request and identity information are used to verify its legitimacy and respond accordingly; finally, N i Use the public key from the current public / private key pair The state data (Data) is encrypted and sent to the BS along with its digital signature. j BS j Through its public key For N i The sent record data is encrypted to obtain the final uploaded data Record. The formal language description of the above process is as follows:

[0059]

[0060] in,

[0061] 5.3) Data collection and upload: Local enterprise headquarters node BS j The uploaded record is verified. If the data is safe and valid, it is stored in the local record pool; otherwise, it is ignored.

[0062] 5.4) Proof of Work for Local Enterprise Headquarters Node: Each period T is set to 10 minutes in this paper, BS j All valid data collected within time T is merged into a single data set, Data_set, and then signed to ensure the legitimacy and verifiability of its source. First, a valid proof-of-work base (BS) is found. j Those who can obtain the right to record this data block will receive a corresponding reward. Valid proof-of-work refers to... j The hash of the current block is calculated using a random number x and the values ​​of the hash, timestamp, and Merkle root of the previous block, represented by P_data. This x must satisfy Hash(x + P_data) < Difficulty. Difficulty is used to adjust the block size distribution (BS). j The difficulty of calculating the correct x-value quickly. The BS that obtains the right to record transactions. j The current Data_set and the calculated x value need to be broadcast to other enterprise headquarters nodes for verification and validation. If other enterprise headquarters nodes successfully verify this proof-of-work that calculates the x value fastest, the BS (Business Provider) is considered valid. j The Data_set is merged into a new data block and stored in the consortium blockchain, while receiving the corresponding system reward.

[0063] 5.5) Block consensus process among enterprise headquarters nodes: The enterprise headquarters nodes (BS) calculate the valid proof-of-work in the shortest possible time. j The leader node becomes the master node in the current consensus process, while other enterprise headquarters nodes act as slave nodes. The consortium blockchain uses the Byzantine Fault Tolerance (PBFT) consensus mechanism for consensus, and the consensus process is as follows:

[0064] 5.5.1) First, the Leader collects the Data_sets from each Slave and integrates them into a new data block, attaching the Leader's digital signature and the hash of the new data block for verification. Then, the Leader broadcasts the newly generated data block to each Slave, awaiting verification from other nodes. The formal language description of the above process is as follows:

[0065]

[0066] Among them, Data_hash=Hash(Data_sets||Timestamp),

[0067] 5.5.2) After receiving a data block, the Slave verifies the block hash and digital signature information sent by the Leader to confirm its correctness and legality, and broadcasts the verification result Result along with its own digital signature to other Slaves, thereby achieving the purpose of interconnection and mutual verification among Slaves.

[0068] 5.5.3) A certain Slave BS l The Slave receives and aggregates the verification results from other Slaves, compares them with its own verification results, and sends a reply (Reply) to the Leader after verification. This Reply includes the Slave's own verification result (my_result), all received verification results (Rece_results), the final verification comparison conclusion (Comparision), and the corresponding digital signature. The formal language description of the above process is as follows:

[0069]

[0070] Among them, Data_3=my_result||Rece_results||Comparision,

[0071] 5.5.4) The Leader collects and summarizes the verification responses from all Slaves. If all Slaves have verified the correctness and validity of the current block, the Leader integrates the data block and the certificate set of the participating Slaves {Certificate}. BSThe data block is then processed along with its corresponding digital signature and sent to all Slaves. Subsequently, this data block is stored in chronological order within the consortium blockchain, and the Leader receives a reward from the system. The formal language description of the above process is as follows:

[0072]

[0073] Among them, Data_4=(Data_sets||Data_hash||{Cert BS}||Timestamp),

[0074] 5.5.5) If some enterprise headquarters nodes fail to verify the current verification result, the Leader will analyze and verify the verification results of these enterprise headquarters nodes. If necessary, the Leader will resend the data block to these enterprise headquarters nodes for secondary verification. If any nodes still fail, the majority will prevail. If more than a certain percentage of enterprise headquarters nodes pass the verification, the data block will be loaded into the consortium blockchain as described in 5.4). Simultaneously, the Leader will further analyze the verification results of the failed enterprise headquarters nodes to determine if these nodes are engaging in malicious behavior, and will promptly handle malicious enterprise headquarters nodes to detect and remove illegal or malicious enterprise headquarters nodes, thereby ensuring the secure and stable operation of the system.

[0075] The beneficial effects of this invention are as follows: This invention uses a collaborative approach of on-chain and off-chain data to store raw enterprise data. First, an improved hash function, SHA256, is introduced to encrypt the raw enterprise data and store it in an off-chain Level DB database based on non-volatile memory, thereby reducing the system's communication and storage pressure. Then, the data is stored on-chain, with the key values ​​in Level DB stored on the DAG-based Conflux public blockchain and the enterprise status data stored on the consortium blockchain, providing reliable evidence data for business environment evaluation. Attached Figure Description

[0076] Figure 1 This is a schematic diagram of the enterprise-level composite blockchain architecture for the business environment of this invention.

[0077] Figure 2 This is a schematic diagram of the operation of the improved SHA256 algorithm of the present invention.

[0078] Figure 3 This is a schematic diagram of the off-chain LevelDB storage model architecture of the present invention.

[0079] Figure 4This is a schematic diagram of the NVMTable data organization in the upper layer of the NVM of this invention.

[0080] Figure 5 This is a schematic diagram illustrating an example of the PGM index of the present invention.

[0081] Figure 6 This is a schematic diagram of the Conflux public blockchain architecture of the present invention.

[0082] Figure 7 This is a schematic diagram of the Conflux public blockchain data structure of the present invention.

[0083] Figure 8 This is a schematic diagram of the Hyperledger Fabric consortium blockchain architecture of the present invention.

[0084] Figure 9 This is a schematic diagram of the consortium blockchain consensus process of the present invention. Detailed Implementation

[0085] A business-oriented approach to building enterprise-grade blockchains includes the following steps:

[0086] Step 1: Construct an enterprise-level composite blockchain architecture: consisting of a Level DB database, a public blockchain, and a consortium blockchain. The Level DB database stores the enterprise's original data information, with the value being the original data and the key being the hash value encrypted using the SHA256 algorithm. The public blockchain, responsible for transactions, stores the key value corresponding to the enterprise's original data in the Level DB database, and the consortium blockchain, responsible for state, stores the enterprise's state data.

[0087] Specifically, the enterprise-level composite blockchain architecture consists of a Level DB database, a public blockchain, and a consortium blockchain. The Level DB database stores the enterprise's original data information; the value is the original data, and the key is the hash value encrypted using the SHA256 algorithm. The public blockchain, responsible for transactions, stores the key values ​​corresponding to the enterprise's original data in the Level DB database, while the consortium blockchain, responsible for state management, stores the enterprise's state data. Through this architecture, on-chain and off-chain data collaboration is achieved. On-chain computing and storage capabilities are expanded through off-chain connections, and off-chain and on-chain interfaces enable the sharing of heterogeneous information.

[0088] Step 2: Encryption Calculation of Original Enterprise Data: The improved SHA256 hash function algorithm is used to encrypt the original enterprise data. This is used to verify whether the original enterprise data has been tampered with when data is needed for business environment assessment.

[0089] Specifically, before storing the original data in the off-chain Level DB database, the enterprise's original data is encrypted using the SHA256 hash function. When data is needed for business environment assessment, it can be verified whether the original enterprise data has been tampered with. The hash function transforms arbitrarily long messages into shorter, fixed-length message digests. This digest serves as the key in a key-value pair, with the value corresponding to the original data. This digest is stored in the key-value database Level DB, and the corresponding key is simultaneously stored in the Conflux public chain within the enterprise-level composite blockchain. To further enhance data security, the number of operations in the data block hashing operation is increased based on the SHA256 hash function, and the algorithm logic and compression function are improved to enhance collision resistance and the avalanche effect of the hash results.

[0090] The SHA256 algorithm uses six logical functions and a set of constants K. t The input is a 512-bit message block x i Then it is divided into 16 groups of 32-bit words M0, M1, ..., M 15 The output is a 256-bit message digest. In improving the SHA256 algorithm, firstly, 16 operations are added to the hash operation of each 512-bit data block to ensure that each bit of the message can affect more bits, further improving the algorithm's non-linear diffusion. Then, the complexity of the SHA256 algorithm logic and compression function is increased to accelerate the differential diffusion of the message, making the recursive process more "random" and thus eliminating the compliance conditions for local collisions.

[0091] The specific execution process of the improved SHA256 algorithm includes:

[0092] (1) For message block M (i) For i = 1, 2, ..., N, perform the following loop:

[0093] 1) Prepare message list W t :

[0094]

[0095] W t =W t-4 +σ0(W t-9 )+σ1(W t-12 )+W t-16 (16≤t≤79)

[0096] 2) Initialization of working variables:

[0097]

[0098]

[0099] In the formula, A to H represent eight working variables, each with a length of 32 bits. This represents the hash value from the previous calculation. When i = 1, The initial value is a constant and can be randomly selected. Referring to the unmodified SHA256 algorithm, it is set as follows:

[0100]

[0101]

[0102] (2) When 0 ≤ t ≤ 79, execute the following compression function:

[0103] T1=h+∑0(c)+Ch(e,f,g)+K t +W t

[0104] T2=∑1(a)+M aj (a,b,c)

[0105] h=g+T1,g=f+T2,f=e+T1,e=d+T2,d=c+T1,c=b+T2,b=a+T1,a=T1+T2

[0106] In the formula, T1 and T2 are intermediate variables, and the compression function uses 80 32-bit words of K. t {256} (0≤t≤79) constant sequence.

[0107] The improved SHA256 algorithm uses six logical functions that operate on 32-bit words (e.g., x, y, z). The result of each logical function is a new 32-bit word, as defined below:

[0108]

[0109]

[0110]

[0111]

[0112]

[0113]

[0114] The improved process enhances the SHA256 algorithm's one-wayness, non-linearity, pseudo-randomness, collision resistance, and avalanche effect. The improved SHA256 hash function is then used to encrypt the enterprise's original data, generating a corresponding hash value that serves as the key in the off-chain Level DB database for subsequent storage operations.

[0115] Step 3: Construct an off-chain Level DB storage model based on NVM: Use the hash value of the encrypted enterprise's original data as the key and the original data as the value, and store them in the off-chain key-value database Level DB accordingly;

[0116] Specifically, the improved SHA256 hash function is used for encryption calculation. The encrypted hash value of the original enterprise data is used as the key, and the original data is used as the value, which is then stored in the off-chain key-value database Level DB. Level DB is a key-value non-relational database storage system based on the LSM-tree (log-structured merge tree) architecture. Due to its advantages such as fast write speed and small space consumption, it has been widely used in many fields. However, the LSM-tree architecture has disadvantages such as write pauses, write amplification, and poor read performance. Therefore, this invention proposes an NVM-based LSM-tree storage model based on the LSM-tree architecture.

[0117] This invention places the L0 layer of the original LSM-tree architecture on NVM, and stores the L1 to Ln layers on SSD (SolidState Disk), solving the write latency problem during data merging. It also introduces a learned index to the L0 layer files, making the L0 layer files ordered and reducing read latency, thereby improving the speed of finding the location of data in the L0 layer files.

[0118] NVMTable is divided into three types of blocks based on its stored content: Super Block, Meta Block, and Entry Block. The Super Block is the first block of each NVMTable and is responsible for storing the file's metadata. Its attribute fields are shown in Table 1. The Entry Block is responsible for storing key-value pairs or pointer pairs. The Meta Block is responsible for storing 1024 bitmap information indicating whether the key or value stored in the Entry Block is actual data or a pointer.

[0119] Table 1: Storage Field Reference Table

[0120]

[0121] When Minor Compaction occurs (i.e., the process of writing the Immutable MemTable to disk L0 level, changing its format to SSTable), data needs to be written to NVMTable. At this time, NVMTable and Container files are created. During the data write operation, it's first determined whether the length of the key-value pair to be written is shorter than 32 bytes. If so, it's inline data and is written directly to the Entry Block; otherwise, the corresponding data pointer from the Container file is written to the Entry Block. Then, while writing data to the Entry Block, a Meta Block is created in memory until no more data is written to NVMTable. Next, the Meta Block in memory is appended to the end of the file, and finally, the Super Block at the beginning of the file is updated to complete the write operation.

[0122] This invention also proposes using a learned index at the NVM layer to predict the location of data using the learned model, thereby accelerating the data retrieval speed in the NVM. By learning the index, the location of a specific key in the L0 layer can be found. First, each NVMTable needs to learn an index model independently, and then establish an approximate mapping from key to data location. Next, starting from the approximate mapped position, a comparison is made with the target key, and the correct location is determined through a linear search forward or backward. This paper chooses the PGM (Piecewise Geometric Model) index for location positioning. The PGM index is a multi-level structure, where each level represents a piecewise simple linear regression with different lower bounds for error rates. The piecewise linear regression divides the data into n+1 segments, containing a set of points p0, p1, ..., p n The entire piecewise linear regression can be represented as the following piecewise function:

[0123]

[0124] In the first level of the PGM index, the data is divided into three partitions, each represented by a simple linear model (f1, f2, f3). By constructing these linear models, each model can predict the corresponding key value within its respective partition using a pre-defined error value. Then, the partition boundary of the first level is used as its own sorted dataset, and another piecewise linear regression with bounded error is calculated. This process is repeated until the top-level PGM becomes sufficiently small. The PGM index is built from the bottom up, first selecting an error boundary, and then using a minimal piecewise linear model to reach this error boundary. This step is repeated until the piecewise model is smaller than a threshold. Each regression in the PGM index uses a fixed error bound, which is treated as an approximate index and applied recursively. First, a piecewise regression model is constructed using the underlying data, and then another piecewise regression with a fixed error is constructed using the partition point of the first regression. Key lookup involves searching for each regression model until the underlying data is found.

[0125] Step 4: Construct the Conflux public chain in an enterprise-grade composite blockchain: Starting from the special structure of a directed acyclic graph (DAG), the Conflux consensus protocol based on the backbone chain is used to construct the Conflux public chain;

[0126] Specifically, traditional public blockchains have shortcomings in scalability, throughput, and transaction confirmation latency. To improve blockchain performance, this invention starts from the special structure of Directed Acyclic Graphs (DAGs) and adopts the Conflux consensus protocol based on the backbone chain to construct the Conflux public blockchain in an enterprise-grade composite blockchain.

[0127] Transactions in Conflux consist of key values ​​corresponding to the original enterprise data in the off-chain Level DB database. Each transaction has a unique ID generated by a cryptographic digest function to ensure its integrity. A block consists of a list of transactions and references to previous blocks. Each block also has a unique ID generated by a cryptographic digest function to ensure data integrity. Conflux starts with a predefined genesis block to determine the initial state of the blockchain. All blocks and edges form a Directed Acyclic Graph (DAG). Due to network latency, the DAG structure may differ between nodes for short periods; Conflux's ultimate goal is to maintain consistency among nodes. All participating nodes in Conflux are connected via a Gossip network. Whenever a node initiates a transaction, it broadcasts the transaction to all other nodes via the Gossip network. Whenever a node generates a new block, it also broadcasts this block to all other nodes via the network.

[0128] In Conflux, each node maintains a pool of pending transactions, containing all transactions that have been broadcast to the node but have not yet been included in any blocks. Whenever a node receives a new transaction from the Gossip network, it adds that transaction to its pool. Whenever a node discovers a new block (whether by generating a block or receiving a block from another node), it removes all transactions from its pool of pending transactions. Due to network latency and malicious nodes, concurrent blocks may include duplicate or conflicting transactions, which are resolved by the consensus protocol. Each node in Conflux runs a block generator to produce valid new blocks to include pending transactions. Each node maintains a local state containing all blocks that it has become aware of through broadcasting. Whenever a node discovers a new block (whether by generating or receiving), it updates its local DAG state accordingly.

[0129] The underlying block data structure of the Conflux public blockchain adopts a tree graph format, which accelerates the block generation speed of the entire blockchain through parallel processing and does not reduce its security due to forks. This allows each enterprise to upload transactions in parallel, i.e., the hash value corresponding to the enterprise's original data, ultimately enabling the entire system to process blocks and transactions more efficiently.

[0130] The Conflux public blockchain operates using a novel consensus protocol that optimistically handles concurrent blocks without discarding any as forks. In Conflux, each block, except for the genesis block, has an out-degree parent edge representing the voting relationship between blocks. For example, there's a parent edge from C to A. Each block can have multiple out-degree reference edges representing the order in which blocks were generated. For example, an edge from E to D indicates that D was generated before E. All parent edges in the Directed Acyclic Graph (DAG) form a parental tree, with the genesis block as the root. Within this parental tree, Conflux selects a chain from the genesis block to one of its leaf blocks as the main chain. Unlike the longest chain, Conflux uses the Ghost protocol to select the main chain, starting from the genesis block, calculating the subtree size of each node, and choosing the node with the largest subtree as a node in the main chain.

[0131] Whenever a node generates a new block, it first computes the main chain in its local DAG state and sets the last block in the main chain as the parent block of the new block. Then, it searches the DAG for all end blocks without in-degree edges and creates referencing edges from the new block to each end block. Given a pivot chain starting from the genesis block and containing only parent edges, the sorting algorithm uses the pivot chain to divide all blocks in the DAG into epochs, with each block on the pivot chain corresponding to an epoch. Blocks included in each epoch have the following constraints: 1) they must be reachable from the corresponding block on the pivot chain via a combination of parent and referencing edges, including the pivot chain block itself; 2) they must not have been in previous epochs.

[0132] When determining the overall block order through consensus, Conflux first sorts the blocks according to their corresponding epochs, and then sorts the blocks within each epoch according to their topological order. When determining the transaction order, the order of transactions is determined by the Block Total Order of the block containing the transaction. If two transactions are in the same block, they are sorted according to their appearance order. While sorting the orders, Conflux checks for transaction conflicts; if two transactions conflict, Conflux discards the second transaction. If a transaction appears in multiple blocks, Conflux retains only the first occurrence and discards all other transactions. Following this process, the key values ​​corresponding to the raw data uploaded by the enterprise are then processed for on-chain data storage.

[0133] Step 5: Building a Hyperledger Fabric consortium blockchain in an enterprise-grade composite blockchain: Select a certain number of verified pre-selected nodes to build a consortium blockchain, and use these pre-selected nodes to implement consensus algorithms, public verification, and secure data storage, and use the Hyperledger Fabric framework to implement the consortium blockchain module.

[0134] Specifically, the consortium blockchain module of the enterprise-level composite blockchain is responsible for storing the state data of an enterprise throughout its entire process from establishment, operation, to termination. Due to the large number of enterprises, to significantly reduce network resource consumption, this invention selects a certain number of verified pre-selected nodes to build the consortium blockchain, and uses these pre-selected nodes to implement consensus algorithms, public verification, and secure data storage. The consortium blockchain module is implemented using the Hyperledger Fabric framework, a well-known representative of consortium blockchains. The Hyperledger Fabric architecture mainly consists of four modules: member management services, blockchain services, smart contracts, and event streams.

[0135] Member management services ensure the identity mechanism for accessing the Fabric platform, providing services for member registration, management, and verification; blockchain services, as the core architecture of Fabric, mainly provide services for P2P protocols for inter-node communication, distributed ledgers for nodes, databases for ledger storage, and consensus mechanism management for ledgers; smart contract services mainly include clients implementing corresponding business logic operations by calling functions in chaincode; event streams mainly provide asynchronous communication functions for various components in Fabric, increasing Fabric's flexibility.

[0136] Once the triggering conditions for contract execution are met, the smart contract will automatically access and share the data, and perform data output, sharing, and other operations according to the defined constraints. The operation of the consortium blockchain responsible for state data storage mainly includes the function of storing state data. The symbols used in the storage process and their meanings are shown in Table 2.

[0137] Table 2: Symbol Content Comparison Table

[0138]

[0139] The specific execution process of storing the state data includes:

[0140] (1) System Initialization: First, each enterprise node needs to be authenticated by the regulatory agency node. After successful authentication, it becomes a legitimate consortium blockchain network node; then, it obtains... These represent the public and private key pairs used for encrypting data and their certificates, respectively; finally, the system initialization is performed, and the enterprise node downloads the current consortium blockchain's block data storage location index table from the record pool of the neighboring enterprise headquarters node.

[0141] (2) Status data upload: First, enterprise node N i To local corporate headquarters nodes BS j Send an upload request, the request includes N i Currently in use And a digital signature Sig_1 is used to ensure the reliability and authenticity of the data source; then, BS j Receive and verify N i The request and identity information are used to verify its legitimacy and respond accordingly; finally, N i Use the public key from the current public / private key pair The state data (Data) is encrypted and sent to the BS along with its digital signature. j BS j Through its public key For N iThe sent record data is encrypted to obtain the final uploaded data Record. The formal language description of the above process is as follows:

[0142]

[0143] in,

[0144] (3) Data collection and upload: Local enterprise headquarters node BS j The uploaded record is verified. If the data is safe and valid, it is stored in the local record pool; otherwise, it is ignored.

[0145] (4) Proof of workload for local enterprise headquarters node: Each period T is set to 10 minutes in this paper, BS j All valid data collected within time T is merged into a single data set, Data_set, and then signed to ensure the legitimacy and verifiability of its source. First, a valid proof-of-work base (BS) is found. j Those who can obtain the right to record this data block will receive a corresponding reward. Valid proof-of-work refers to... j The hash of the current block is calculated using a random number x and the values ​​of the hash, timestamp, and Merkle root of the previous block, denoted by P_data. This x must satisfy Hash(x + P_data) < Difficulty. Difficulty is used to adjust the block size distribution (BS). j The difficulty of calculating the correct x-value quickly. The BS that obtains the right to record transactions. j The current Data_set and the calculated x value need to be broadcast to other enterprise headquarters nodes for verification and validation. If other enterprise headquarters nodes successfully verify this proof-of-work that calculates the x value fastest, the BS (Business Provider) is considered valid. j The Data_set is merged into a new data block and stored in the consortium blockchain, while receiving the corresponding system reward.

[0146] (5) Block consensus process among enterprise headquarters nodes: The enterprise headquarters nodes (BS) calculate the valid proof of work in the shortest possible time. j The leader node becomes the master node in the current consensus process, while other enterprise headquarters nodes act as slave nodes. The consortium blockchain uses the Byzantine Fault Tolerance (PBFT) consensus mechanism for consensus, and the consensus process is as follows:

[0147] 1) First, the Leader collects the Data_sets from each Slave and integrates them into a new data block, attaching the Leader's digital signature and the hash of the new data block for verification. Then, the Leader broadcasts the newly generated data block to each Slave, awaiting verification from other nodes. The formal language description of the above process is as follows:

[0148]

[0149] Among them, Data_hash=Hash(Data_sets||Timestamp),

[0150] 2) After receiving a data block, the Slave verifies the block hash and digital signature information sent by the Leader to confirm its correctness and legality, and broadcasts the verification result Result along with its own digital signature to other Slaves, thereby achieving the purpose of interconnection and mutual verification between Slaves.

[0151] 3) A certain Slave BS l The Slave receives and aggregates the verification results from other Slaves, compares them with its own verification results, and sends a reply (Reply) to the Leader after verification. This Reply includes the Slave's own verification result (my_result), all received verification results (Rece_results), the final verification comparison conclusion (Comparision), and the corresponding digital signature. The formal language description of the above process is as follows:

[0152]

[0153] Among them, Data_3=my_result||Rece_results||Comparision,

[0154] 4) The Leader collects and summarizes the verification responses from all Slaves. If all Slaves successfully verify the correctness and validity of the current block, the Leader integrates the data block and the certificate set of the participating Slaves {Certificate}. BS The data block is then processed along with its corresponding digital signature and sent to all Slaves. Subsequently, this data block is stored in chronological order within the consortium blockchain, and the Leader receives a reward from the system. The formal language description of the above process is as follows:

[0155]

[0156] Among them, Data_4=(Data_sets||Data_hash||{Cert BS}||Timestamp),

[0157] 5) If some enterprise headquarters nodes fail to verify the current verification result, the Leader will analyze and verify the verification results of these enterprise headquarters nodes. If necessary, the Leader will resend the data block to these enterprise headquarters nodes for secondary verification. If there are still nodes that fail, the majority will be required. If more than a certain percentage of enterprise headquarters nodes pass the verification of the data block, the data block will be loaded into the consortium blockchain as described in (4). At the same time, the Leader will further analyze the verification results of the enterprise headquarters nodes that have failed verification to determine whether these enterprise headquarters nodes have engaged in malicious behavior. Malicious enterprise headquarters nodes will be dealt with in a timely manner to promptly detect and remove illegal and malicious enterprise headquarters nodes, thereby ensuring the safe and stable operation of the system.

[0158] Specific application example: The following is an application example of the present invention with reference to the accompanying drawings:

[0159] With attachment Figure 6 and Figure 7 For example, we can build the Conflux public chain in an enterprise-level composite chain oriented towards the business environment.

[0160] In the Conflux public blockchain, transactions are composed of key values ​​corresponding to the original enterprise data in the off-chain Level DB database. Each transaction has a unique ID generated by a cryptographic digest function to ensure its integrity. A block consists of a list of transactions, for example... Figure 6 Block B contains 4 transactions and reference links to previous blocks, for example, in Figure 6 In the DAG state, B is linked to the previous two blocks, forming a chain. Each block also has a unique ID generated by a cryptographic digest function to ensure data integrity. Conflux starts with a predefined genesis block to determine the initial state of the blockchain. All blocks and edges constitute a DAG structure. Due to network latency, the DAG structure content of each node may differ for short periods. The ultimate goal of Conflux is to maintain consistency among nodes. All participating nodes in Conflux are connected via a Gossip network. Whenever a node initiates a transaction, it broadcasts the transaction to all other nodes via the Gossip network, for example, ... Figure 6 In Tx9, whenever a node generates a new block, it also broadcasts this block to all other nodes across the network, for example, Figure 6 Block B in the middle.

[0161] In Conflux, each node maintains a pool of pending transactions. This pool contains all transactions that have been broadcast and received by the node but have not yet been included in any block. Whenever a node receives a new transaction from the Gossip network, it adds that transaction to its pool; for example, adding Tx9 to its pool. Figure 6 In the transaction pool. Whenever a node discovers a new block, whether by generating a block or receiving a block from another node, that node removes all transactions from its pending transaction pool. For example, in Figure 6 In Conflux, after generating block B, a node removes Tx1, Tx2, Tx3, and Tx5 from its pool. Due to network latency and malicious nodes, concurrent blocks may contain duplicate or conflicting transactions, which will be resolved by the consensus protocol. Each node in Conflux runs a block generator to produce valid new blocks to package pending transactions. Each node maintains a local state containing all blocks that the node is aware of through broadcast. Whenever a node discovers a new block, whether by generating or receiving it, the node updates its local DAG state accordingly.

[0162] In Conflux, apart from the genesis block, each block has an outgoing parent edge. Figure 7 The solid arrows in the diagram represent voting relationships between blocks. For example, there is a parent edge from C to A. Each block can have multiple out-degree reference edges. Figure 7 The dashed arrows in the diagram represent the order in which blocks are generated. For example, an edge from E to D indicates that D was generated before E. All parent edges in a Directed Acyclic Graph (DAG) together form a parental tree, with the genesis block as the root. Within the parent tree, Conflux selects a chain from the genesis block to one of its leaf blocks as the main chain. Unlike the longest chain, Conflux uses the Ghost protocol to select the main chain, starting from the Genesis block, calculating the subtree size of each node, and choosing the node with the largest subtree as a node in the main chain. Figure 7 In Conflux, Genesis, A, C, E, and H are selected as the main chain, instead of Genesis, B, F, J, I, and K. This is because A has more child nodes than B.

[0163] Whenever a node generates a new block, it first computes the main chain in its local DAG state and sets the last block in the main chain as the parent block of the new block. Then, it searches the DAG for all end blocks without in-degree edges and creates referencing edges from the new block to each end block. For example, in... Figure 7 In the algorithm, when a new block N is generated, a node selects H as the parent block of N and creates a reference edge from N to K. Given a pivotchain that starts from the genesis block and contains only parent edges, the sorting algorithm uses the pivotchain to divide all blocks in the DAG into epochs, with each block on the pivotchain corresponding to one epoch. For example, in... Figure 7 In this context, J belongs to epoch H because J can be reached from H but not from previous main chain blocks. When determining the overall block order through consensus, Conflux first sorts the blocks according to their corresponding epochs, and then sorts the blocks within each epoch according to their topological order. Figure 7 The total order obtained by Conflux from the local DAG is as follows: Genesis, A, B, C, D, F, E, G, J, I, H, and K.

[0164] Because the enterprise-level composite blockchain construction method for the business environment proposed in this invention considers the collaborative methods of on-chain and off-chain data in storing the original enterprise data, the enterprise-level composite blockchain construction method for the business environment has high read / write performance and storage efficiency.

Claims

1. A method for constructing an enterprise-level composite blockchain for the business environment, characterized in that: Includes the following steps: Step 1: Construct an enterprise-grade composite blockchain architecture: The enterprise-grade composite blockchain architecture consists of a Level DB database, a public blockchain, and a consortium blockchain; Step 2: Encryption Calculation of Enterprise Original Data: The improved hash function SHA256 algorithm is used to encrypt the enterprise's original data. This is used to verify whether the enterprise's original data has been tampered with when data needs to be queried for business environment evaluation. The SHA256 algorithm described uses six logical functions and a set of constants. The input is a 512-bit message block. Then divide it into 16 groups of 32-bit words. The output is a 256-bit message digest. When improving the SHA256 algorithm, firstly, 16 operations are added to the hash operation of each 512-bit data block so that each bit of the message can affect more bits. Then, the complexity of the SHA256 algorithm logic and compression function is increased to accelerate the differential diffusion of the message, making the recursive process more random and eliminating the compliance conditions of local collisions. Step 3: Construct an off-chain Level DB storage model based on NVM: After encryption calculation using the improved hash function SHA256 algorithm, the hash value of the enterprise's original data is encrypted and used as the key value, and the original data is used as the value value, which are then stored in the off-chain key-value database Level DB. The original LSM-tree architecture The layer is placed on NVM. Layer to The layer is stored on an SSD to solve the write latency problem during data merging, and also... The layer's files introduce a learning index, enabling... The layers of files are ordered and read latency is reduced, improving data retrieval speed. The speed of the position in the layer file; Step 4: Construct the Conflux public chain in the enterprise-grade composite blockchain: Starting from the special structure of the Directed Acyclic Graph (DAG), the Conflux consensus protocol based on the backbone chain is adopted to construct the Conflux public chain; the public chain responsible for transactions in the on-chain enterprise-grade composite blockchain stores the key values ​​corresponding to the original enterprise data in the enterprise's Level DB database; Step 5: Constructing a Hyperledger Fabric consortium blockchain within an enterprise-grade composite blockchain: Select a certain number of verified pre-selected nodes to build the consortium blockchain. These pre-selected nodes will be used to implement consensus algorithms, public verification, and secure data storage. The Hyperledger Fabric framework will be used to implement the consortium blockchain module. The consortium blockchain responsible for state storage will store the enterprise's state data. This architecture enables on-chain and off-chain data collaboration. On-chain computing and storage capabilities can be expanded through off-chain connections, and off-chain and on-chain interfaces can share heterogeneous information.

2. The enterprise-level composite blockchain construction method for the business environment according to claim 1, characterized in that, The improved SHA256 algorithm is as follows: Step 2.1) For message blocks The following loop will be performed: Step 2.1.1) Prepare the message list : ， ； ， Step 2.1.2) Initialize working variables: In the formula, This represents 8 working variables, each with a length of 32 bits. This represents the hash value from the previous calculation. hour, The initial value is a constant, randomly selected value, and based on the unmodified SHA256 algorithm, it is set as follows: 2.2) When At that time, the following compression function is executed: In the formula, As an intermediate variable, the compression function used 80 32-bit words. constant sequence, ; The improved SHA256 algorithm uses six logical functions that operate on 32-bit words. The result of each logical function is a new 32-bit word, as defined below: An improved hash function, SHA256, is used to encrypt the enterprise's original data and generate a corresponding hash value, which is then used as the key value in the off-chain Level DB database for subsequent storage operations.

3. The enterprise-level composite blockchain construction method for the business environment according to claim 1, characterized in that, The specific method in step three is as follows: NVMTable is divided into three types of blocks according to its stored content: Super Block, Meta Block, and Entry Block. The Super Block is the first block of each NVMTable and is responsible for storing the file's metadata. Its attribute fields are shown in Table 1. The Entry Block is responsible for storing key-value pairs or pointer pairs. The Meta Block is responsible for storing bitmap information on whether 1024 key-value pairs are inline, which is used to mark whether a key or value in the Entry Block stores actual data or a pointer; Table 1: Storage Field Reference Table When Minor Compaction occurs, data is written to NVMTable, at which point NVMTable and Container files will be created; When performing a data write operation, first determine if the length of the key and value of the key-value pair to be written is shorter than 32 bytes. If so, it is inline data and is written directly to the Entry Block. Otherwise, write the corresponding data pointer from the Container file into the Entry Block. Then, while writing data to the Entry Block, create a Meta Block in memory until NVMTable stops writing data. Append the Meta Block in memory to the end of the file, and finally update the Super Block at the beginning of the file to complete the write operation. Using a learned index at the NVM layer, the learned model is used to predict the location of data. The learned index is then used to find... The position of a key in the layer; first, each NVMTable needs to learn an index model separately, and then establish an approximate mapping from the key to the data location; then, starting from the position of the approximate mapping, it is compared with the target key, and the correct position is determined by linear search forward or backward; The PGM index is chosen for location positioning. The PGM index is a multi-level structure, where each level represents a piecewise simple linear regression with different lower bounds on the error rate. The piecewise linear regression divides the data into... A segment, which contains a set of points The entire piecewise linear regression can be represented as the following piecewise function: In the first level of the PGM index, the data is divided into three partitions, each partition consisting of a simple linear model. This means that each linear model can use a pre-defined error value to predict the corresponding key value within its respective partition. Then, it uses the partition boundary of the first layer as its own sorted dataset to calculate another piecewise linear regression with bounded error. This process is repeated until the top-level PGM becomes sufficiently small. The PGM index is built from the lower layer to the upper layer. First, an error boundary is selected, and then a minimum linear piecewise model is used to reach this error boundary. This step is repeated until the piecewise model is less than a threshold. Each regression in the PGM index uses a fixed error bound, which is regarded as an approximate index and is applied recursively. First, a piecewise regression model is constructed using the bottom-level data, and then another piecewise regression with a fixed error is constructed using the partition point of the first regression. Key lookup is to search for each regression model until the bottom-level data is found.

4. The enterprise-level composite blockchain construction method for the business environment according to claim 1, characterized in that, The specific method in step four is as follows: Transactions in Conflux consist of key values ​​corresponding to the original enterprise data in the off-chain Level DB database, and each transaction has a unique ID generated by a cryptographic digest function; A block consists of a list of transactions and reference links to previous blocks. Each block also has a unique ID generated by a cryptographic digest function. Conflux starts from a predefined genesis block, and all blocks and edges form a DAG structure. Due to network latency, the DAG structure content of each node is different for a short period of time. All participating nodes in Conflux are connected through a Gossip network. Whenever a node initiates a transaction, it broadcasts the transaction to all other nodes through the Gossip network. Whenever a node generates a new block, it also broadcasts this block to all other nodes through the network. In Conflux, each node maintains a pool of pending transactions. The pool contains all transactions that have been broadcast and received by the node but have not yet been included in any block. Whenever a node receives a new transaction from the Gossip network, it adds the transaction to its pool. Whenever a node discovers a new block, it removes all transactions from its pool of pending transactions. Due to network latency and malicious nodes, concurrent blocks may contain duplicate or conflicting transactions, which will be resolved by the consensus protocol. Each node in Conflux runs a block generator to produce valid new blocks to package pending transactions. Each node maintains a local state containing all the blocks that the node has become aware of through broadcast. Whenever a node discovers a new block, it updates its local DAG state accordingly. The underlying block data structure of the Conflux public blockchain adopts a tree graph form, which accelerates the block generation speed of the entire blockchain through parallel processing and does not reduce its security due to forks. This allows each enterprise to upload transactions in parallel, i.e., the hash value corresponding to the enterprise's original data, ultimately enabling the entire system to process blocks and transactions efficiently. The Conflux public blockchain operates using a novel consensus protocol that optimistically handles concurrent blocks, without discarding any concurrent blocks as forks. In Conflux, apart from the genesis block, each block has an outgoing parent edge representing the voting relationship between blocks. All parent edges in the DAG together form a parental tree, with the genesis block as the root. Within the parental tree, Conflux selects a chain from the genesis block to one of the leaf blocks as the main chain. Starting from the Genesis block, it calculates the subtree size of each node, and the node with the largest subtree becomes a node in the main chain. Whenever a node generates a new block, it first computes the main chain in its local DAG state and sets the last block in the main chain as the parent block of the new block. Then, it searches for all end blocks in the DAG without in-degree edges and creates reference edges from the new block to each end block. Given a main chain pivotchain starting from the genesis block and containing only parent edges, the sorting algorithm uses the main chain to divide all blocks in the DAG into epochs. Each block on the main chain corresponds to an epoch, and the blocks in each epoch have the following constraints: 1) They are reached from the corresponding block on the main chain through a combination of parent edges and reference edges; 2) They are not included in previous epochs. When determining the overall block order through consensus, Conflux first sorts the blocks according to their corresponding epochs, and then sorts the blocks within each epoch according to their topological order. When determining the transaction order, the order of transactions is determined by the Block Total Order of the block containing the transaction. If two transactions are in the same block, they are sorted according to the order in which they appear. During sorting, Conflux checks for transaction conflicts. If two transactions conflict, Conflux discards the second transaction. If a transaction appears in multiple blocks, Conflux retains only the first transaction and discards all other transactions. Following the above process, the key values ​​corresponding to the raw data uploaded by the enterprise are processed for on-chain data storage.

5. The enterprise-level composite blockchain construction method for the business environment according to claim 1, characterized in that, The specific method in step five is as follows: The Hyperledger Fabric architecture mainly consists of four modules: member management service, blockchain service, smart contracts, and event stream. Member management services ensure the identity mechanism for accessing the Fabric platform, providing services for member registration, management, and verification; blockchain services, as the core architecture of Fabric, provide services for the P2P protocol for inter-node communication, the distributed ledger of nodes, the database for ledger storage, and the consensus mechanism management of the ledger; smart contract services mainly include clients implementing corresponding business logic operations by calling functions in the chaincode; event streams provide asynchronous communication functions for various components in Fabric. Once the triggering conditions for contract execution are met, the smart contract automatically accesses and shares data, and performs data output and sharing operations according to the defined constraints. The operation of the consortium blockchain responsible for storing state data mainly includes the storage function of state data. The symbols used in the storage process and their meanings are shown in Table 2. Table 2: Symbol Content Comparison Table The specific execution process of storing the state data includes: Step 5.1) System Initialization: First, each enterprise node needs to be authenticated by the regulatory agency node. After successful authentication, it becomes a legitimate consortium blockchain network node; then, it obtains... These represent the public and private key pairs used for encrypting data and their certificates, respectively; finally, the system initialization is performed, and the enterprise node downloads the current consortium blockchain's block data storage location index table from the record pool of the neighboring enterprise headquarters node; Step 5.2) Status data upload: First, the enterprise node... To local corporate headquarters nodes Send an upload request, the request includes Currently in use and digital signatures To ensure the reliability and authenticity of the data source; then, Receive and verify The request and identity information are used to verify its legitimacy and respond accordingly; finally, Use the public key from the current public / private key pair For state data Encrypt the state data and send it along with its digital signature to [the relevant authority]. , Through its public key right The sent record data is encrypted to obtain the final uploaded data. The formal language description of the above process is as follows: in, , ; Step 5.3) Upload Data Collection: Local Enterprise Headquarters Node For uploaded Verify the data; if it is secure and valid, store it in the local record pool; otherwise, ignore it. Step 5.4) Proof of Workload for Local Enterprise Headquarters Node: After each cycle , Will All valid data collected internally is merged into a single dataset. And perform data signature on it; first find a valid proof of work. The right to record this data block is granted, and a corresponding reward is received; valid proof-of-work refers to... Based on random numbers And the previous block , The Merkle tree root value is used to calculate the current block. ,this Must meet , Used for adjustment Calculation correct The difficulty of the speed of value recording; the acquisition of accounting rights The current and calculated The value is broadcast to other enterprise headquarters nodes for verification and validation; if the verification by other enterprise headquarters nodes passes, the fastest calculation is... The value of the work proof, Will They are merged into a new data block and stored in the consortium blockchain, while receiving corresponding system rewards. Step 5.5) Block consensus process among enterprise headquarters nodes: Enterprise headquarters nodes that calculate valid proof-of-work in the shortest possible time. The consortium blockchain becomes the master node in the current consensus process, while other enterprise headquarters nodes act as slave nodes. It employs a Byzantine fault tolerance consensus mechanism, and the consensus process is as follows: Step 5.5.1) First, Collect all of And integrate it into a new data block, while attaching Digital signatures and new data blocks For inspection; then, To each The newly generated data block is broadcast to await verification by other nodes; the formal language description of the above process is as follows: in, , ; Step 5.5.2) After receiving the data block, The sent block Verify the digital signature information and the verification result. Broadcast your own digital signature to others ; Step 5.5.3) A certain Receive and summarize other The verification results are compared with my own verification results, and then the verification is performed. Send a reply ,Should include Self-verification results All received verification results The final conclusion of the verification and comparison and the corresponding digital signature; the formal language description of the above process is as follows: in, , ; Step 5.5.4) Collect and summarize all The verification response, if all All have verified the correctness and legality of the current block. Integrate the data block and participate in the verification Certificate set ( ) and the corresponding digital signature and send it to all Afterward, the data block will be stored in the consortium blockchain in chronological order. They also receive system rewards from this process. The formal language description of the above process is as follows: in, , ; Step 5.5.1) If some enterprise headquarters nodes fail to pass the current verification result, The verification results from these corporate headquarters nodes will be analyzed and verified. If any verification content sent does not match the initial verification content received, The data block will be resent to these enterprise headquarters nodes for secondary verification. If any node still fails, the majority will prevail. If a certain percentage of enterprise headquarters nodes pass the verification, the data block will be loaded into the consortium blockchain as described in 5.4). We will further analyze the verification results of unverified corporate headquarters nodes to determine whether these corporate headquarters nodes have engaged in malicious behavior, and promptly deal with malicious corporate headquarters nodes.

Images