Consensus method and system based on data assets

Abstract

The invention discloses a consensus method and system based on data assets, and the method comprises the steps: receiving a data asset transaction request in a distributed network, and generating a group of initial data block sets based on the transaction request; performing feature mapping on the initial data block set, constructing a block feature vector set, and decomposing feature vectors in the block feature vector set into a plurality of sub-feature vectors to capture different features of the data assets; performing multi-objective optimization on the sub-feature vectors by using an improved Bitcoin-NG consensus mechanism to generate an optimized data block set; and verifying and confirming the optimized data block set by applying a distributed consistency algorithm, and determining a plurality of final data blocks as a consensus result of the corresponding data asset transaction request. According to the embodiment of the invention, the efficiency and safety of data asset consensus can be improved.

Description

Technical Field

[0001] The present invention belongs to the field of data asset technology, and in particular to a consensus method and system based on data assets. Background Art

[0002] With the rapid development of blockchain technology, efficient transactions and secure consensus on data assets have become core challenges for distributed networks. Traditional consensus mechanisms (such as Proof-of-Work and Proof-of-Stake) face performance bottlenecks in data asset transactions, struggling to balance high throughput, low latency, and adaptability to multi-dimensional data characteristics. For example, while the Bitcoin-NG protocol improves transaction processing speed through microblocks, its native design fails to consider the complex characteristics of data assets (such as ownership, timeliness, and privacy), making it difficult to balance consensus efficiency and data security. Furthermore, existing solutions often employ a single optimization objective, failing to dynamically adapt to the diverse characteristics of data assets, potentially leading to fork risks and wasted resources. Summary of the Invention

[0003] The purpose of this invention is to provide a consensus method and system based on data assets to address the deficiencies in the existing technology and to improve the efficiency and security of data asset consensus.

[0004] An embodiment of the present application provides a consensus method based on data assets, the method comprising: Receiving a data asset transaction request in a distributed network, and generating a set of initial data blocks based on the transaction request, wherein each initial data block is associated with a characteristic dimension of the data asset; Perform feature mapping on the initial data block set, construct a block feature vector set, and decompose the feature vectors in the block feature vector set into several sub-feature vectors to capture the different characteristics of the data assets, where each feature vector represents the multi-dimensional feature attributes of the corresponding initial data block; Performing multi-objective optimization on the sub-feature vectors using an improved Bitcoin-NG consensus mechanism to generate an optimized data block set, wherein the improved Bitcoin-NG consensus mechanism confirms leaders through main chain blocks and processes transactions in micro-blocks, and combines with the PoW chain to ensure the security and immutability of data assets; A distributed consistency algorithm is applied to the optimized data block set for verification and confirmation, and several final data blocks are determined as the consensus results of the corresponding data asset transaction request.

[0005] Optionally, receiving a data asset transaction request in a distributed network and generating a set of initial data blocks based on the transaction request, wherein each initial data block is associated with a characteristic dimension of the data asset, including: Receive data asset transaction requests through distributed network nodes, parse the asset type, digital signatures of both parties in the request, and the underlying asset identifier, use elliptic curve encryption algorithm to verify the validity of the signature, filter out malicious requests with invalid signatures, and output a list of valid transaction requests; For each request in the valid transaction request list, extract the characteristic dimensions of the corresponding data asset, including data size, generation time, ownership chain length, encryption level, and circulation frequency. Eliminate dimensional differences through feature standardization and output a data asset characteristic dimension table. Based on the data asset feature dimension table, a clustering algorithm is used to group transaction requests by feature similarity. Each group corresponds to a feature dimension combination. A unique initial block identifier is assigned to each group, and a block-feature dimension mapping table is output. According to the block-feature dimension mapping table, the detailed information of each set of transaction requests is packaged into an initial data block, and the corresponding feature dimension label is embedded in the header of each block to generate an initial data block set.

[0006] Optionally, feature mapping is performed on the initial data block set to construct a block feature vector set, and the feature vectors in the block feature vector set are decomposed into a number of sub-feature vectors to capture different characteristics of the data asset, wherein each feature vector represents a multi-dimensional feature attribute of the corresponding initial data block, including: Traverse the initial data block set, extract the specific value corresponding to the feature dimension label for each block, and construct the original feature matrix by combining the derived features of the block including transaction throughput and verification time. The original feature matrix is ​​normalized using maximum and minimum normalization to eliminate the dimensional influence of different feature dimensions. The variance inflation factor is used to detect and remove multicollinearity features, and the de-redundant normalized feature matrix is ​​output. Based on the de-redundant normalized feature matrix, a deep learning embedding model is used to map the multi-dimensional features of each block into a high-dimensional vector. Each dimension of the vector corresponds to an abstract expression of the feature, and the block feature vector set is output. Apply a non-negative matrix factorization algorithm to the set of block feature vectors, set the decomposition dimension according to the core characteristics of the data asset, decompose each high-dimensional feature vector into multiple sub-feature vectors, each corresponding to the quantitative expression of a single characteristic, and output the initial sub-feature vector set; Calculate the mutual information value of the initial sub-feature vector set, remove redundant sub-vectors with mutual information higher than the threshold, verify the independence of the sub-vectors through principal component analysis, and output the optimized sub-feature vector set.

[0007] Optionally, the improved Bitcoin-NG consensus mechanism is used to perform multi-objective optimization on the sub-feature vectors to generate an optimized data block set, wherein the improved Bitcoin-NG consensus mechanism confirms the leader and processes transactions in micro-blocks through the main chain block, and combines with the PoW chain to ensure the security and immutability of data assets, including: Extract the security sub-vector from the sub-feature vector set, combine it with the node computing power value to construct a comprehensive score, elect the main chain block leader through computing power competition, and output the leader node identifier and hash record of the election process; The leader node generates the main chain block based on the security sub-vector. The block header contains the root hash of the sub-feature vector set, the leader's public key, and term information. The main chain block mining is completed through the PoW mechanism, and the main chain block with PoW proof is output. The leader node sorts transaction requests based on the liquidity sub-vector and prioritizes packaging high-liquidity requests into micro-blocks. Each micro-block contains the transaction summary corresponding to the sub-feature vector and the leader's signature. A micro-block sequence is generated in the order of transactions, and an unverified micro-block set is output. The network node performs PoW chain verification on the unverified micro-block set, calculates the hash value of each micro-block and compares it with the root hash of the main chain block. The verified micro-blocks are included in the temporary transaction pool. At the same time, the node synchronously updates the verification status of the local sub-feature vector and outputs the verified micro-block pool; Based on the value stability sub-vector, multi-objective optimization weights are set, the main chain blocks and the verified micro-block pool are integrated, the blocks that meet the weight threshold are screened out, and integrated into the optimized data block set by timestamp.

[0008] Optionally, applying a distributed consistency algorithm to the optimized data block set to verify and confirm, and determining a number of final data blocks as the consensus results corresponding to the data asset transaction request, includes: The optimized data block set is broadcast to all consensus nodes in the distributed network. Each node calls the smart contract to locally execute the transaction logic in the block, checks the consistency of the block hash value and the sub-feature vector, and outputs the node's local verification result. A practical Byzantine fault-tolerant algorithm is used to collect local verification results from all nodes. When the proportion of nodes that agree to pass the verification exceeds 2 / 3, the consensus confirmation process is triggered, and the list of nodes that agree on each block and the reasons for rejection of the dissenting nodes are recorded, and the consensus confirmation certificate is output; Based on the consensus confirmation certificate, the final hash chain verification is performed on the passed blocks to ensure the consistency and immutability between blocks, filter out abnormal blocks with broken hash chains, and output the candidate block sequence that has passed the verification; The candidate block sequence is arranged in ascending order by transaction timestamp to generate a final data blockchain containing the complete ownership chain, transaction records and sub-feature vector labels as the consensus result of the corresponding data asset transaction request.

[0009] Another embodiment of the present application provides a consensus system based on data assets, the system comprising: A receiving module, configured to receive a data asset transaction request in a distributed network, and generate a set of initial data blocks based on the transaction request, wherein each initial data block is associated with a characteristic dimension of the data asset; A construction module is used to perform feature mapping on the initial data block set, construct a block feature vector set, and decompose the feature vectors in the block feature vector set into several sub-feature vectors to capture different characteristics of the data asset, where each feature vector represents a multi-dimensional feature attribute of the corresponding initial data block; an optimization module for performing multi-objective optimization on the sub-feature vectors using an improved Bitcoin-NG consensus mechanism to generate an optimized data block set, wherein the improved Bitcoin-NG consensus mechanism confirms leaders through main chain blocks and processes transactions in micro-blocks, and combines with the PoW chain to ensure the security and immutability of data assets; The verification module is used to apply a distributed consistency algorithm to verify and confirm the optimized data block set, and determine several final data blocks as the consensus results of the corresponding data asset transaction request.

[0010] Yet another embodiment of the present application provides a storage medium, wherein the storage medium stores a computer program, wherein the computer program is configured to execute any of the above methods when run.

[0011] Yet another embodiment of the present application provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute any of the above methods.

[0012] Compared with the existing technology, the present invention provides a consensus method based on data assets, which receives data asset transaction requests in a distributed network and generates a set of initial data block sets based on the transaction requests; performs feature mapping on the initial data block set to construct a block feature vector set, and decomposes the feature vectors in the block feature vector set into several sub-feature vectors to capture the different characteristics of the data assets; uses the improved Bitcoin-NG consensus mechanism to perform multi-objective optimization on the sub-feature vectors to generate an optimized data block set; applies a distributed consistency algorithm to the optimized data block set for verification and confirmation, and determines several final data blocks as the consensus results of the corresponding data asset transaction requests, thereby improving the efficiency and security of the data asset consensus. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 A hardware structure block diagram of a computer terminal for a data asset-based consensus method provided by an embodiment of the present invention; Figure 2 A flowchart of a consensus method based on data assets provided by an embodiment of the present invention; Figure 3 A schematic diagram of the structure of a data asset-based consensus system provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0014] The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and are not to be construed as limiting the present invention.

[0015] The embodiment of the present invention first provides a consensus method based on data assets, which can be applied to electronic devices such as computer terminals, specifically ordinary computers.

[0016] The following describes it in detail by taking running on a computer terminal as an example. Figure 1 The hardware structure block diagram of a computer terminal for a consensus method based on data assets provided by an embodiment of the present invention. Figure 1 As shown, the computer device includes a processor, a memory, and a network interface connected via a system bus, wherein the memory may include a non-volatile storage medium and an internal memory.

[0017] The non-volatile storage medium can store an operating system and a computer program. The computer program includes program instructions that, when executed, cause the processor to execute any consensus method based on data assets.

[0018] The processor is used to provide computing and control capabilities and support the operation of the entire computer equipment.

[0019] The internal memory provides an environment for the operation of computer programs in non-volatile storage media. When the computer program is executed by the processor, it can enable the processor to execute any consensus method based on data assets.

[0020] The network interface is used for network communication, such as sending assigned tasks, etc. Those skilled in the art will understand that Figure 1 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0021] It should be understood that the processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0022] See also Figure 2 , an embodiment of the present invention provides a consensus method based on data assets, which may include the following steps: S201, receiving a data asset transaction request in a distributed network, and generating a set of initial data blocks based on the transaction request, wherein each initial data block is associated with a characteristic dimension of the data asset; Specifically, it can receive data asset transaction requests through distributed network nodes, parse the asset type, digital signatures of both parties in the request, and the underlying asset identifier, use elliptic curve encryption algorithm to verify the validity of the signature, filter out malicious requests with invalid signatures, and output a list of valid transaction requests; A distributed network consists of multiple nodes, distributed across different physical locations, communicating via peer-to-peer (P2P) protocols and collectively maintaining records of data asset transactions. When a data asset transaction request is initiated, it is broadcast to all nodes in the network, each of which is capable of receiving and initially processing the request. For example, a node might receive a data asset transaction request from an enterprise user transferring a customer behavior dataset, or from individual users sharing intellectual property data.

[0023] When parsing a transaction request, three core elements must be extracted: the asset type, the digital signatures of both parties, and the underlying asset identifier. The asset type distinguishes the category of data assets, such as "structured transaction data," "unstructured document," or "encryption algorithm model." Different asset types require different processing logic. The digital signatures of both parties are encrypted strings generated by the transaction initiator and recipient using their respective private keys, proving the authenticity and non-repudiation of the transaction. The underlying asset identifier is a unique identifier for the data asset, such as the hash value "a1b2c3d4...", which can be used to locate the specific asset within the network.

[0024] Elliptic Curve Cryptography (ECC) is a key technology for verifying the validity of digital signatures. Based on the mathematical principles of elliptic curves, it offers shorter key lengths than RSA at the same security level (e.g., 256-bit ECC is comparable to 3072-bit RSA) and is computationally more efficient. The verification process consists of three steps: First, the public keys of both parties are extracted from the transaction request (the public key is the public counterpart of the private key and is used to verify the signature). Second, a SHA-256 hash is performed on the core information in the transaction request (such as the asset type, underlying asset identifier, and transaction timestamp) to produce a message digest (e.g., "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"). Finally, the digital signature is decrypted using the sender's public key, resulting in a decrypted hash value. This hash value is then compared with the message digest. If they match, the signature is valid; otherwise, it is invalid.

[0025] For example, user A initiates a data asset transaction with user B and signs the transaction information with their private key, generating a signature called "SigA." After receiving the request, the node extracts user A's public key, "PubA," calculates a hash of the transaction information to obtain "Hash1," and decrypts "SigA" with "PubA" to obtain "Hash2." If "Hash1" and "Hash2" are identical, the signature is valid, confirming that the transaction was initiated by user A and has not been tampered with. If they are inconsistent, the request is considered malicious (possibly a forged signature or tampered information) and is filtered out.

[0026] After filtering out malicious requests, the remaining requests form a list of valid transaction requests. Each request in this list contains complete transaction information: asset type (e.g., "Medical Imaging Dataset"), transaction IDs of both parties (e.g., "UserID1001," "UserID1002"), underlying asset identifier (e.g., "AssetHash789"), transaction timestamp (e.g., "2025-07-25 15:30:00"), and signature verification result ("Valid"). This list provides the foundational data for subsequent generation of the initial data block, ensuring that all transaction requests entering the system are authentic and legitimate.

[0027] For each request in the valid transaction request list, extract the characteristic dimensions of the corresponding data asset, including data size, generation time, ownership chain length, encryption level, and circulation frequency. Eliminate dimensional differences through feature standardization and output a data asset characteristic dimension table. The characteristic dimensions of data assets are key indicators that describe their properties. These indicators directly influence the subsequent block generation and consensus process. For each request in the valid transaction request list, five core characteristic dimensions are extracted one by one: data size, generation time, ownership chain length, encryption level, and circulation frequency.

[0028] Data scale refers to the size of data assets, usually measured in bytes (B), reflecting the storage and processing costs of assets. For example, the size of a customer data set is 5GB (5×1024 3 B); Generation Time is the timestamp of the first creation of the data asset, such as "2024-03-15 09:20:00", which is used to determine the timeliness of the asset; Ownership Chain Length refers to the number of ownership transfers from the asset's creation to the current transaction. For example, if an asset is transferred from creator A to creator B and then to creator C, the ownership chain length is 2, reflecting the complexity of the asset's circulation history; Encryption Level is a rating of the asset's encryption strength, divided into levels 1-5 (level 1 is the weakest and level 5 is the strongest). For example, assets encrypted with AES-256 are rated level 5; Circulation Frequency refers to the number of transactions of an asset in the past 30 days. For example, the circulation frequency of a popular dataset is 12 times, reflecting the activity level of the asset.

[0029] These feature dimensions have significant dimensional differences (e.g., data size is measured in GB, while circulation frequency is measured in times). Directly using these features for analysis will result in large-value features like "data size" dominating the results, while smaller-value features like "ownership chain length" will be ignored. Therefore, feature normalization is necessary. Using the min-max normalization method, all features are mapped to the [0, 1] range using the formula: Normalized value = (original value - minimum value) / (maximum value - minimum value).

[0030] For example, in a batch of transaction requests, the minimum data size is 1GB and the maximum is 10GB. The original size of an asset is 5GB. The normalized value is (5-1) / (10-1)≈0.44. The minimum length of the ownership chain is 0 and the maximum is 5. The length of the chain of an asset is 2. The normalized value is (2-0) / (5-0)=0.4. The encryption level is 1-5. When normalized, the minimum value is 1 and the maximum value is 5. The asset is level 3. The normalized value is (3-1) / (5-1)=0.5. Through normalization, all features are comparable at the same scale, preventing dimensional differences from interfering with subsequent processing.

[0031] The data asset characteristic dimension table integrates the above information. Each record corresponds to a valid transaction request and includes the request ID, asset type, raw characteristic values ​​(data size, generation time, etc.), and normalized characteristic values. For example, a record might read: "Request ID 001, asset type 'Financial Transaction Data', data size 2GB (normalized 0.11), generation time '2024-05-20' (normalized 0.6), ownership chain length 3 (0.6), encryption level 4 (0.75), circulation frequency 8 (0.67)." This table clearly presents the characteristic attributes of each data asset, providing a quantitative basis for subsequent clustering and grouping.

[0032] Based on the data asset feature dimension table, a clustering algorithm is used to group transaction requests by feature similarity. Each group corresponds to a feature dimension combination. A unique initial block identifier is assigned to each group, and a block-feature dimension mapping table is output. Clustering algorithms are used to group transaction requests with similar characteristics, ensuring high consistency in data asset characteristics within each group. This facilitates the subsequent generation of targeted initial data blocks. A commonly used clustering algorithm is K-means, which divides data into K clusters, ensuring high similarity within a cluster and low similarity between clusters.

[0033] The K value (number of clusters) should be determined based on the diversity of the data asset's characteristic dimensions. This can be selected using the elbow method: Calculate the intra-cluster sum of squared errors (SSE) for different K values. The SSE decreases as K increases. When K reaches a certain value, the SSE decreases sharply, indicating the optimal K value. For example, when K=3, SSE=100; when K=4, SSE=80; when K=5, SSE=78; and when K=6, SSE=77. The elbow occurs at K=4, so K=4 is selected to divide the transaction requests into four groups.

[0034] The feature similarity is calculated using Euclidean distance. For the standardized feature vectors of two transaction requests (e.g., vector A = [0.44, 0.6, 0.6, 0.75, 0.67], vector B = [0.55, 0.5, 0.7, 0.8, 0.7]), the Euclidean distance formula is: The smaller the distance, the higher the similarity. The K-means algorithm iteratively updates the cluster center (the mean of each cluster's feature vector) until the cluster center stabilizes (the change in cluster center between two iterations is less than 0.01), ultimately resulting in four clusters, each representing a feature dimension combination.

[0035] For example, Cluster 1 is characterized by "small data size (normalized 0.1-0.3), short ownership chain (0.1-0.4), and high encryption level (0.6-0.9)," and includes small-value financial cryptoasset transactions. Cluster 2 is characterized by "large data size (0.7-0.9) and high circulation frequency (0.7-1.0)," and includes large, frequently circulated datasets. The characteristic dimension combination of each cluster is represented by the eigenvector at the cluster center. For example, the center vector of Cluster 1 is [0.2, 0.5, 0.3, 0.8, 0.4], representing the typical characteristics of this cluster.

[0036] Each group is assigned a unique initial block identifier in the format "BlockInit-XXXXX," where "XXXXX" is a five-digit number (00001-99999) to ensure uniqueness. For example, cluster 1 is assigned "BlockInit-00001," cluster 2 is assigned "BlockInit-00002," and so on. The initial block identifiers correspond one-to-one with the feature dimension combinations within the group and are recorded in the block-feature dimension mapping table.

[0037] The block-feature dimension mapping table contains the initial block identifier, cluster center feature vector, feature dimension combination description, and a list of included request IDs. For example, a record might be: "BlockInit-00001, cluster centers [0.2, 0.5, 0.3, 0.8, 0.4], feature dimension combination 'small scale, short chain, high encryption', request ID list [ID001, ID003, ID005]." This table establishes a correlation between the initial block and the data asset feature dimensions, clearly defining the transaction request scope and feature attributes corresponding to each block, and providing a grouping basis for subsequent packaging of initial data blocks.

[0038] According to the block-feature dimension mapping table, the detailed information of each set of transaction requests is packaged into an initial data block, and the corresponding feature dimension label is embedded in the header of each block to generate an initial data block set.

[0039] The packaging of the initial data blocks must strictly adhere to the block-feature dimension mapping table, ensuring that each block contains only transaction requests within the corresponding group and that the block header clearly marks its feature dimensions. The block structure is divided into two parts: the block header and the block body. The block header contains metadata, and the block body contains transaction details.

[0040] The fields of the block header include: initial block identifier (such as "BlockInit-00001"), feature dimension label (a string converted from the cluster center feature vector, such as "small scale_short chain_high encryption"), previous block hash (if it is the first block, it is "000000"), timestamp (block creation time, such as "2025-07-25 16:00:00"), transaction number (the number of transaction requests in the group, such as 5), Merkle root (the hash value of all transaction hashes in the block body, used to quickly verify transaction integrity).

[0041] The block body contains detailed information about all transaction requests within the group. Each transaction record includes: the transaction ID (which matches the ID in the valid transaction request list), the IDs of the two parties to the transaction, the identifier of the underlying asset, the transaction amount (if any), the digital signature, and the transaction status ("pending"). For example, the block body of BlockInit-00001 contains three transaction records: ID001, ID003, and ID005, each of which describes the corresponding asset transaction in detail.

[0042] Embedding feature dimension labels converts the "feature dimension combination descriptions" in the block-feature dimension mapping table into machine-readable labels. Labels are formatted as key-value pairs, such as "data size = small, ownership chain = short, encryption level = high," to facilitate rapid extraction of block attribute characteristics during subsequent feature mapping. These labels are written into a specific field in the block header and bound to the initial block identifier, ensuring that each block's feature dimensions are directly readable.

[0043] During the packaging process, integrity verification is performed to calculate the Merkle root of the block body: first, a SHA-256 hash is calculated for each transaction record to obtain a transaction hash list. Then, the hash list is paired and the hash of each pair is calculated. This process is repeated until a root hash, known as the Merkle root, is obtained. For example, if the hashes of three transactions are H1, H2, and H3, H12 is first calculated as hash (H1+H2), and then the Merkle root is calculated as hash (H12+H3). This is then written into the block header to ensure that the transaction information in the block body has not been tampered with (any modification of a transaction will cause the Merkle root to change).

[0044] The initial data block set is the collection of all completed initial blocks. Each block conforms to the structure described above and is individually associated with the characteristic dimensions of the data asset. For example, the set includes four blocks, BlockInit-00001 through BlockInit-00004, corresponding to four sets of transaction requests. Each block header has a clear characteristic dimension label, and the block body contains complete transaction details. This set provides the basic data unit for subsequent feature mapping and consensus processing, ensuring that each block accurately reflects the characteristics of its corresponding data asset.

[0045] S202, performing feature mapping on the initial data block set, constructing a block feature vector set, and decomposing the feature vectors in the block feature vector set into a number of sub-feature vectors to capture different characteristics of the data asset, wherein each feature vector represents a multi-dimensional feature attribute of the corresponding initial data block; Specifically, we can traverse the initial data block set, extract the specific value corresponding to the feature dimension label for each block, and combine the derived features of the block including transaction throughput and verification time to construct the original feature matrix; The initial data block set contains multiple blocks associated with data asset feature dimensions. The traversal process requires parsing each block's feature dimension labels and transaction details one by one to extract the basic and derived features required to construct the original feature matrix. Each initial data block has feature dimension labels embedded in its header, such as "Data size = 0.3, Generation time = 0.6, Ownership chain length = 0.5, Encryption level = 0.8, Circulation frequency = 0.4." The specific values ​​corresponding to these labels are standardized feature values ​​from the block-feature dimension mapping table, directly reflecting the core attributes of the data asset.

[0046] When extracting the specific values ​​of the feature dimension labels, they must accurately match the label fields in the block header. For example, if the feature dimension labels for BlockInit-0001 are "Data Size = 0.2, Generation Time = 0.5, Ownership Chain Length = 0.3, Encryption Level = 0.9, Circulation Frequency = 0.2," the specific values ​​extracted are [0.2, 0.5, 0.3, 0.9, 0.2], corresponding to the five basic features: data size, generation time, ownership chain length, encryption level, and circulation frequency. These values ​​are rounded to two decimal places to ensure accuracy and avoid data redundancy.

[0047] Derived features are extracted based on the block's transaction data. Core derived features include transaction throughput and verification time. Transaction throughput refers to the number of transactions processed per unit time. The calculation formula is "Transaction throughput = Total number of transactions in a block / Block generation interval," where the block generation interval is the difference in timestamps between the current block and the previous block (in seconds). For example, if BlockInit-0001 contains 8 transactions with a generation timestamp of 1627230000 and a previous block timestamp of 1627229980, with a 20-second interval, the transaction throughput is 8 / 20, or 0.4 transactions per second. Verification time refers to the average time from when a block is received by a network node to when preliminary verification is completed. By taking the average of the verification times of 5 random nodes, for example, if node A takes 0.8 seconds, node B takes 1.2 seconds, node C takes 0.9 seconds, node D takes 1.1 seconds, and node E takes 1.0 second, then verification time = (0.8+1.2+0.9+1.1+1.0) / 5 = 1.0 second.

[0048] The original feature matrix is ​​a two-dimensional matrix that integrates the basic features and derived features. The number of rows in the matrix is ​​equal to the number of initial data blocks, and the number of columns is equal to the total number of features (5 basic features + 2 derived features = 7). For example, if the initial data block set contains 3 blocks, then the original feature matrix will have 3 rows and 7 columns, with each row corresponding to the feature vector of a block: The first row (BlockInit-0001) is [0.2, 0.5, 0.3, 0.9, 0.2, 0.4, 1.0]; The second row (BlockInit-0002) is [0.7, 0.3, 0.8, 0.5, 0.9, 1.2, 0.5]; The third row (BlockInit-0003) is [0.5, 0.7, 0.6, 0.7, 0.6, 0.8, 0.8]. Each element in the matrix is ​​a specific value, clearly showing the performance of each block in the seven feature dimensions, providing the raw data foundation for subsequent feature processing.

[0049] When constructing the original feature matrix, a data integrity check is performed to ensure that all seven features of each block are present. If the "verification time" for a block is not collected due to a node failure, it is filled in with the average verification time of blocks in the same group (for example, if the average verification time for the group containing BlockInit-0004 is 0.9 seconds, 0.9 seconds is filled in). Furthermore, outliers are processed. For example, if a block's transaction throughput is 5.0 transactions per second (much higher than the group average of 1.0 transactions per second), it is identified as an outlier and replaced with the 95th percentile value within the group (e.g., 1.5 transactions per second) to prevent the outlier from interfering with subsequent feature processing.

[0050] The original feature matrix is ​​normalized using maximum and minimum normalization to eliminate the dimensional influence of different feature dimensions. The variance inflation factor is used to detect and remove multicollinearity features, and the de-redundant normalized feature matrix is ​​output. Although the features in the original feature matrix have undergone preliminary normalization, the value ranges of different features still vary (for example, transaction throughput ranges from 0.4-1.2, and verification time ranges from 0.5-1.0). These dimensional differences can lead to unbalanced feature weights (for example, features with large value ranges have a disproportionately high weight in the calculation). Maximum-minimum normalization maps all features to the range [0,1], completely eliminating dimensionality effects. The calculation formula is: Normalized value = (original value - feature minimum value) / (feature maximum value - feature minimum value), where the feature minimum and maximum values ​​are the global minimum and maximum values ​​of that feature in the original feature matrix.

[0051] For example, if the minimum value of "Transaction Throughput" in the original feature matrix is ​​0.4 and the maximum value is 1.2, and the original value of a block is 0.8, then the normalized value is (0.8-0.4) / (1.2-0.4)=0.4 / 0.8=0.5. If the minimum value of "Verification Time" is 0.5 and the maximum value is 1.0, and the original value of a block is 0.8, then the normalized value is (0.8-0.5) / (1.0-0.5)=0.3 / 0.5=0.6. Through this process, the values ​​of all features are compressed to [0,1], ensuring that each feature has equal weight in subsequent analysis.

[0052] After normalization, it is necessary to detect multicollinearity between features, that is, multiple features are highly correlated (for example, "circulation frequency" and "transaction throughput" may be highly correlated because they both reflect asset activity). This will lead to a decrease in the model's ability to explain the features and unstable parameter estimation. Variance inflation factor (VIF) is a commonly used indicator to measure multicollinearity. Its calculation formula is: VIF_i=1 / (1-R_i 2 ), where R_i 2is the coefficient of determination obtained by linear regression of the i-th feature on all other features, R_i 2 The closer it is to 1, the stronger the collinearity between the feature and other features, and the larger VIF_i is.

[0053] When calculating VIF, it is necessary to perform linear regression on each feature: take "circulation frequency" as the dependent variable and the other 6 features as independent variables, and fit the regression equation by the least squares method to obtain R 2 =0.9, then VIF=1 / (1-0.9)=10; take "encryption level" as the dependent variable and other characteristics as independent variables, and get R 2 =0.3, then VIF=1 / (1-0.3)≈1.43. The VIF threshold is usually set to 10. When the VIF of a feature is greater than 10, it is determined that there is severe multicollinearity and it needs to be removed from the feature matrix.

[0054] For example, after calculation, the VIF of "circulation frequency" was 12 (>10), and its correlation coefficient with "transaction throughput" was 0.85 (high correlation), so "circulation frequency" was removed. Other features with VIFs less than 10 (such as "data size" VIF = 2.1 and "generation time" VIF = 3.5) were retained. After removing redundant features, the original feature matrix was reduced from 7 columns to 6, including "data size, generation time, ownership chain length, encryption level, transaction throughput, and verification time."

[0055] The de-redundant normalized feature matrix is ​​a matrix that has been normalized and de-collinearized. For example, the original 3-row, 7-column matrix becomes 3-row, 6-column: the first row is [0.2, 0.5, 0.3, 0.9, 0.5, 0.6], the second row is [0.7, 0.3, 0.8, 0.5, 1.0, 0.0], and the third row is [0.5, 0.7, 0.6, 0.7, 0.75, 0.6]. The features in this matrix eliminate dimensional differences and avoid multicollinearity interference, providing high-quality input data for subsequent feature mapping.

[0056] To ensure the rationality of redundancy removal, it is necessary to calculate the feature variance explanation rate before and after feature removal (calculated through principal component analysis). If the total variance explanation rate drops by no more than 5% after removal (for example, from 90% to 88%), it means that the removed feature is redundant and the treatment is effective. If the drop exceeds 10%, it is necessary to re-evaluate the VIF threshold or select other features for removal to balance feature reduction and information retention.

[0057] Based on the de-redundant normalized feature matrix, a deep learning embedding model is used to map the multi-dimensional features of each block into a high-dimensional vector. Each dimension of the vector corresponds to an abstract expression of the feature, and the block feature vector set is output. While the features in the de-redundant normalized feature matrix are optimized, they are still low-dimensional, explicit features (six dimensions), making it difficult to capture complex nonlinear relationships between features (such as the implicit correlation between "encryption level" and "verification time"). Deep learning embedding models can map these low-dimensional features into high-dimensional vectors (e.g., 256 dimensions), with each dimension representing an abstract combination of features, thereby more comprehensively characterizing the characteristic properties of a block.

[0058] A commonly used deep learning embedding model is the autoencoder, whose structure includes an input layer, a hidden layer (encoding layer), a bottleneck layer (embedding layer), a hidden layer (decoding layer), and an output layer. The number of neurons in the input layer is equal to the dimension of the de-redundant features (6); the encoding layer gradually compresses features through two hidden layers (e.g., 128 neurons, 64 neurons); the bottleneck layer is the embedding layer, the number of neurons is equal to the dimension of the high-dimensional vector (256), and the output is the high-dimensional embedding vector of the block; the decoding layer reconstructs the input features through a structure symmetrical to the encoding layer (64 neurons, 128 neurons), and the output layer has the same dimension as the input layer (6).

[0059] The goal of model training is to minimize the reconstruction error between the decoding layer output and the input layer features, using mean square error (MSE) as the loss function: Loss = Σ(output features - input features) 2 / number of samples. The training data consists of a de-redundant normalized feature matrix. Stochastic gradient descent is used to optimize parameters, with a learning rate of 0.001 and 1000 iterations. Training is terminated when the loss function changes by less than 1e-5 after 100 consecutive iterations. For example, the input features of a block are [0.2, 0.5, 0.3, 0.9, 0.5, 0.6]. After encoding, the embedding layer outputs a 256-dimensional vector [0.12, 0.35, ..., 0.28] (omitting intermediate dimensions). The reconstructed features at the decoding layer are [0.21, 0.49, 0.32, 0.89, 0.51, 0.59] with an MSE of 0.0001, indicating good reconstruction results.

[0060] Each dimension of a high-dimensional vector has no clear physical meaning, but rather represents an abstract representation of complex relationships between features. For example, the 10th dimension might reflect the combination of "high encryption level and long verification time," while the 50th dimension might correspond to "large data volume and high transaction throughput." These abstract dimensions can capture implicit correlations that low-dimensional features cannot capture (such as the nonlinear relationship between "ownership chain length" and "transaction throughput").

[0061] The block feature vector set is the set of high-dimensional embedding vectors for all blocks. For example, in a set containing three blocks, each block corresponds to a 256-dimensional vector, with each element in the interval [0, 1]. (Because the input features are normalized, the embedding layer uses a sigmoid activation function.) The vectors in this set retain the key information of the original features while enhancing the distinguishability of the features through mapping them in high-dimensional space (blocks of different types are further apart in high-dimensional space). For example, the cosine similarity of the embedding vectors of financial data blocks and medical data blocks in high-dimensional space is 0.2 (low similarity), while the similarity of similar blocks is 0.8 (high similarity).

[0062] To evaluate the embedding effect, the intra-class similarity and inter-class similarity of high-dimensional vectors can be calculated: the intra-class similarity is the average vector similarity of blocks in the same feature group (such as 0.75), and the inter-class similarity is the average vector similarity of blocks in different groups (such as 0.3). When the intra-class similarity is significantly higher than the inter-class similarity (difference > 0.4), it means that the embedding model has effectively captured the feature differences of the blocks, and the block feature vector set can be output for subsequent processing.

[0063] Apply a non-negative matrix factorization algorithm to the set of block feature vectors, set the decomposition dimension according to the core characteristics of the data asset, decompose each high-dimensional feature vector into multiple sub-feature vectors, each corresponding to the quantitative expression of a single characteristic, and output the initial sub-feature vector set; While high-dimensional vectors (e.g., 256 dimensions) within a block's feature vector set can comprehensively characterize a block, their dimensionality is too high and abstract to be directly linked to the core characteristics of data assets (such as security, liquidity, and value stability). The non-negative matrix factorization (NMF) algorithm decomposes high-dimensional vectors into multiple low-dimensional sub-feature vectors, each of which corresponds to a quantitative expression of a core characteristic. The principle is to decompose a high-dimensional matrix V (n×m, where n is the number of blocks and m is the dimension of the high-dimensional vector) into two non-negative matrices W (n×k) and H (k×m), such that V ≈ W×H, where k is the decomposition dimension (the number of core characteristics). Each row of W represents the k sub-feature vectors of a block.

[0064] The core characteristics of data assets typically include security, liquidity, and value stability. Therefore, the decomposition dimension k is set to 3. Security reflects the tamper-proof and encryption protection capabilities of data asset transactions and is related to the "encryption level" and "length of the ownership chain." Liquidity reflects the asset's trading activity and circulation efficiency and is related to "transaction throughput" and "verification time." Value stability reflects the volatility of the asset's value and is related to "generation time" and "data size." The setting of the decomposition dimension k should be tailored to the business scenario. If cross-border transactions are involved, the "compliance" feature can be added, setting k to 4.

[0065] The iterative process of the NMF algorithm is as follows: initialize W and H as non-negative random matrices (element values ​​are in [0,1]); calculate the reconstruction error ||VW×H|| 2 (Frobenius norm); update W and H using the multiplicative update rule (the update formula for W is W_ij = W_ij × (V×H^T)_ij / (W×H×H^T)_ij, and the update formula for H is similar); repeat the iteration until the reconstruction error is less than a threshold (such as 1e-3) or the maximum number of iterations (such as 1000) is reached.

[0066] For example, if the matrix V of a block feature vector set is 3×256 and the decomposition dimension k=3, then W is 3×3 (each row is the three sub-feature vectors of a block), and H is 3×256 (each column is the weight of the core characteristics to the high-dimensional vector dimension). After decomposition, the first column of W corresponds to the security sub-vector (higher values ​​indicate greater security), the second column corresponds to the liquidity sub-vector, and the third column corresponds to the value stability sub-vector. The sub-feature vectors of a financial block are [0.85, 0.6, 0.7], indicating high security (0.85), medium liquidity (0.6), and high value stability (0.7).

[0067] Each sub-eigenvector has a value range of [0, 1] (because NMF requires the matrix to be non-negative), with higher values ​​indicating stronger corresponding characteristics. For example, a security sub-vector value of 0.9 indicates that asset transactions in that block are highly encrypted (high encryption level) and have a clear chain of ownership (tamper-proof); a liquidity sub-vector value of 0.2 indicates low transaction throughput and long verification times (inactive circulation); and a value of 0.5 indicates moderate asset value volatility (relatively recent generation time and stable data size).

[0068] The initial sub-feature vector set is the collection of sub-feature vectors for all blocks. For example, in a set of three blocks, each block contains three sub-vectors (security, liquidity, and value stability). The set format is one row for each block, and each row contains three values ​​(such as [0.85, 0.6, 0.7], [0.7, 0.9, 0.5], [0.6, 0.7, 0.8]). This set transforms high-dimensional abstract features into quantitative indicators directly related to core characteristics, facilitating subsequent multi-objective optimization (such as electing a leader based on the security sub-vector and sorting transactions based on the liquidity sub-vector).

[0069] The decomposition effect is evaluated through reconstruction error and feature correlation: the reconstruction error must be less than a preset threshold (such as 1e-3) to ensure that the decomposition retains the key information of the high-dimensional vector; feature correlation refers to the correlation coefficient between the sub-feature vector and the corresponding core feature indicator (such as the correlation coefficient between the security sub-vector and the encryption level > 0.7). When the correlation coefficients of all sub-vectors and the corresponding features are > 0.6, it means that the decomposition is effective and the initial set of sub-feature vectors can be output.

[0070] Calculate the mutual information value of the initial sub-feature vector set, remove redundant sub-vectors with mutual information higher than the threshold, verify the independence of the sub-vectors through principal component analysis, and output the optimized sub-feature vector set.

[0071] The subvectors (security, liquidity, and value stability) in the initial sub-feature vector set may be redundant, meaning that different subvectors have strong dependencies (for example, the subvectors for liquidity and value stability are highly correlated). This can lead to repeated calculations of feature weights during subsequent optimization. The mutual information value measures the degree of dependency between two subvectors. A higher value indicates greater redundancy. The calculation formula is: I (X;Y) = ΣΣp (x,y) log (p (x,y) / (p (x) p (y))), where p(x,y) is the joint probability distribution of subvectors X and Y, and p(x) and p(y) are marginal probability distributions. The mutual information value ranges from [0 to log (min (|X|,|Y|))].

[0072] Calculate the mutual information value for each pair of subvectors in the initial sub-feature vector set. For example, the mutual information between security (X) and liquidity (Y) is I (X;Y) = 0.3, the mutual information between liquidity (Y) and value stability (Z) is I (Y;Z) = 0.6, and the mutual information between security and value stability is I (X;Z) = 0.2. Set the mutual information threshold to 0.5 (the threshold is set based on the business's independence requirements; higher requirements lead to lower thresholds). If I (Y;Z) = 0.6 > 0.5, redundancy is determined between the liquidity and value stability subvectors.

[0073] The removal of redundant sub-vectors should be based on business priorities, retaining those that are more important to the core objectives. For example, in data asset consensus, if liquidity takes precedence over value stability, the value stability sub-vector should be removed, while retaining security and liquidity. If the two priorities are equal, the correlation between the sub-vectors and the objective function (such as the correlation coefficient with consensus efficiency) can be calculated to retain the sub-vector with the higher correlation (for example, if the correlation coefficient of the liquidity sub-vector is 0.7 > 0.5 for value stability, then value stability should be removed).

[0074] Assume that after removing the value stability subvector, the remaining security and liquidity subvectors are verified for independence through principal component analysis (PCA). PCA projects the subvectors onto a new coordinate system, ensuring that the covariance between the principal components is zero (complete independence). Calculate the variance explained by the two projected principal components. If the first principal component explains 90% of the variance of the security subvector and the second explains 85% of the variance of the liquidity subvector, and their covariance is 0.02 (close to 0), the subvectors are highly independent and lack significant redundancy.

[0075] The optimized set of sub-feature vectors is the set of sub-vectors after redundancy has been removed. For example, the set of sub-vectors retaining security and liquidity is [[0.85, 0.6], [0.7, 0.9], [0.6, 0.7]]. The dimension of each sub-vector is determined by the number of remaining core features (e.g., 2 dimensions), and the mutual information value between sub-vectors is less than 0.5, and the covariance verified by PCA is less than 0.1. This ensures that each sub-vector corresponds to an independent core feature and can be used for subsequent multi-objective optimization of the improved Bitcoin-NG consensus mechanism.

[0076] To ensure the rationality of the optimization, it is necessary to re-evaluate the information retention rate of the sub-vectors for the original high-dimensional features (through NMF reconstruction error comparison, the reconstruction error does not increase by more than 10% after removing redundancy) and verify the performance of the sub-vectors in downstream tasks (for example, the efficiency of consensus based on the optimized sub-vectors is improved by 15%). When the information retention rate and task performance meet the requirements, the optimized sub-feature vector set is output.

[0077] S203, performing multi-objective optimization on the sub-feature vectors using an improved Bitcoin-NG consensus mechanism to generate an optimized data block set, wherein the improved Bitcoin-NG consensus mechanism confirms the leader through the main chain block and processes transactions in the micro-block, and combines with the PoW chain to ensure the security and immutability of data assets; Specifically, the security sub-vector can be extracted from the sub-feature vector set, and a comprehensive score can be constructed by combining the node computing power value. The main chain block leader is elected through a computing power competition, and the leader node identifier and hash record of the election process are output; The sub-feature vector set includes multiple sub-vectors reflecting the core characteristics of data assets. Among them, the security sub-vector is a key indicator for measuring the tamper-resistance and cryptographic protection level of data asset transactions. The extraction of the security sub-vector must be correlated with characteristics such as the data asset's encryption level and the length of the ownership chain. For example, in a given sub-feature vector set, the security sub-vector's value ranges from [0, 1], with higher values ​​indicating greater security. Specifically, the security sub-vector is calculated as "normalized encryption level × 0.5 + normalized ownership chain length × 0.3 + reversed value of historical tamper records × 0.2," where the reversed value of historical tamper records is "1 - number of tampering attempts / total number of transactions," ensuring a multi-dimensional reflection of security. For example, if the encryption level of a data asset is 0.9, the length of the ownership chain is 0.8, and there are no historical tampering records (reverse value 1.0), then the security sub-vector value is 0.9×0.5 + 0.8×0.3 + 1.0×0.2 = 0.45 + 0.24 + 0.2 = 0.89, which is high security.

[0078] The node computing power value is an indicator to measure the computing power of network nodes, usually expressed as hash rate (the number of hash calculations completed per second), with the unit of H / s (hash / second). Common units include TH / s (terahash / second, 1TH / s=10 12 H / s), PH / s (Hash / second, 1PH / s=10 15 H / s). For example, the computing power of node A is 5TH / s, node B is 3TH / s, and node C is 8TH / s. The higher the computing power, the stronger the node's ability to handle encryption calculations and verification tasks, and the more suitable it is to serve as the main chain block leader.

[0079] The construction of the comprehensive score requires balancing the security subvector and the node's computing power. The calculation formula is "Comprehensive score = Security subvector value × 0.6 + Normalized node computing power value × 0.4", where the normalized node computing power value is "Node computing power value / Total network computing power value", ensuring a reasonable computing power ratio. For example, if Node C has a security subvector value of 0.89 and a total network computing power of 20 TH / s, its normalized computing power value is 8 / 20 = 0.4, then the comprehensive score is 0.89 × 0.6 + 0.4 × 0.4 = 0.534 + 0.16 = 0.694. Node A's comprehensive score is 0.8 × 0.6 + (5 / 20) × 0.4 = 0.48 + 0.1 = 0.58. Node C has a higher score and is more competitive.

[0080] The hashing competition is a core component of leader election. Essentially, nodes compete for the right to package blocks by solving cryptographic puzzles, following a "first to solve" rule. The puzzle requires nodes to calculate a random number (nonce) such that the hash value of the block header (including the security subvector, node public key, timestamp, etc.) and the nonce meets a predefined condition (such as a prefix of 18 consecutive zeros). For example, if the block header contains "security subvector = 0.89, public key = PubC, timestamp = 1627230000," node C exhaustively enumerates the nonce, and when nonce = 123456, it calculates the SHA-256 hash of "000000000000000000a1b2c3d4e5f6...", which meets the 18-zero prefix condition and successfully solves the puzzle.

[0081] The hash record of the campaign process is used to verify the fairness of the election. The record includes the public keys of all participating nodes, the submitted nonce, the calculated hash value, and the solution timestamp. Each record item is concatenated into a Merkle chain using a SHA-256 hash, ultimately generating a root hash of the campaign process. For example, the root hash is "f0e4c2f76c58916ec258f246851be44c55a94f567c0e78e5a0c6f44c8d4aa4." This root hash is stored in the distributed network, allowing any node to verify whether there was any cheating during the competition (such as tampering with the solution time).

[0082] The leader node is identified by the winning node's unique identifier (e.g., "NodeC-789"), which is bound to the election root hash and announced to the entire network via broadcast. If no node solves the puzzle within a preset time (e.g., 10 minutes), the difficulty of the puzzle is increased (reducing the number of prefix 0s to 17) and the competition is restarted to ensure efficient leader election.

[0083] The leader node generates the main chain block based on the security sub-vector. The block header contains the root hash of the sub-feature vector set, the leader's public key, and term information. The main chain block mining is completed through the PoW mechanism, and the main chain block with PoW proof is output. The leader node's process for generating mainchain blocks must be based on the security subvector, ensuring that the block content meets the security requirements of data assets. The mainchain block structure consists of a block header and a block body. The block body contains selected core transaction records (transactions highly correlated with the security subvector, such as those with an encryption level ≥ 0.8), while the block header stores metadata and is the key carrier of the PoW mechanism.

[0084] The root hash of the sub-feature vector set is the core field of the block header and is obtained by calculating the Merkle root of all sub-feature vectors. For example, the sub-feature vector set contains 3 vectors [S1=0.89, S2=0.75, S3=0.92]. First, calculate the hash of each vector H1=hash (S1), H2=hash (S2), H3=hash (S3), and then calculate , root hash = , the final root hash is “e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855”, which is embedded in the block header to verify the integrity of the sub-vector set.

[0085] The leader's public key is the public key of the leader node (e.g., "PubC"). It is used to authenticate the legitimacy of a block. Any node can verify that a block was generated by the elected leader using the public key. The term specifies the validity period of the leader's authority, typically 30 minutes. During the term, the leader has the right to package microblocks. After the term expires, a new election is required to prevent a single node from maintaining a monopoly over a long period of time. For example, a term of "start = 1627230000, end = 1627231800" clearly defines the timeframe within which the leader's authority and responsibilities are valid.

[0086] The core of the PoW mechanism for mining mainchain blocks is to ensure the immutability of blocks through the investment of computing power. The mining process is similar to the leader election computing race, but with a higher degree of difficulty (e.g., prefix containing 20 zeros). After generating a block, the leader node combines the block header information (root hash, public key, term, previous block hash, etc.) with a random number (nonce) and calculates the hash value until the target condition is met. For example, if the previous block hash is "a1b2c3d4...", the leader node calculates the target hash "000000000000000000000f1e2d3c4b5a6..." after performing a trillion hash calculations. When the nonce = 987654, the leader node obtains the target hash "000000000000000000000f1e2d3c4b5a6...", completing the PoW proof.

[0087] The PoW proof includes the target hash value, the nonce used, and the computation time (e.g., 2 minutes). It is bound to the block header to form a complete main chain block. For example, the main chain block header with a PoW proof is "Root Hash = e3b0c442..., Public Key = PubC, Term = 30 minutes, Pre-order Hash = a1b2c3d4..., PoW Proof = (Nonce = 987654, Target Hash = 000000000000000000000f1e2d3..., Computation Time = 120s)", and the block body contains 50 high-security transaction records.

[0088] During the mining process, the PoW difficulty is dynamically adjusted based on the network's hashrate, every 2016 blocks, to ensure a stable average mining time of approximately 10 minutes. For example, if the average mining time for the last 2016 blocks is 8 minutes (hashrate is too high), the difficulty is increased (increasing the number of prefix 0s to 21); if the average time is 12 minutes (hashrate is too low), the difficulty is reduced (to 19) to maintain network stability.

[0089] The leader node sorts transaction requests based on the liquidity sub-vector and prioritizes packaging high-liquidity requests into micro-blocks. Each micro-block contains the transaction summary corresponding to the sub-feature vector and the leader's signature. A micro-block sequence is generated in the order of transactions, and an unverified micro-block set is output. The liquidity subvector reflects the activity and efficiency of data asset transactions. Its core parameters include transaction throughput (transaction volume per unit time), verification time (transaction confirmation speed), and circulation frequency (historical transaction count). These parameters are normalized and integrated into a value between 0 and 1, with higher values ​​indicating greater liquidity. For example, a transaction request with a liquidity subvector value of 0.9 indicates high transaction throughput (1.2 transactions / second), short verification time (0.5 seconds), and high circulation frequency (10 transactions / month), making it a highly liquid transaction.

[0090] The leader node sorts transaction requests based on descending liquidity subvector values, prioritizing requests with higher liquidity to improve overall network transaction efficiency. This sorting maintains fairness. If the difference in liquidity subvector values ​​between two transactions is less than 0.05 (e.g., 0.85 and 0.83), they are sorted in ascending order by transaction initiation timestamp to avoid queue jumping. For example, if a transaction list contains request A (liquidity 0.9, timestamp = 1627230001), request B (0.85, 1627230002), and request C (0.85, 1627230000), the resulting sorting would be A, C, B, prioritizing higher liquidity while maintaining chronological order for transactions of the same level.

[0091] Microblocks are lightweight data units used to process high-frequency transactions. Each microblock is limited to 1MB (containing approximately 200 transactions) and consists of a microblock header and a microblock body. The microblock header contains the block number (e.g., "Micro-001"), the parent block hash (the main chain block hash), the number of transactions, and a timestamp. The microblock body contains a transaction summary and a leader signature. The transaction summary is a compressed representation of each transaction's key information (transaction ID, public keys of both parties, underlying asset identifier, and hash value), such as "Transaction ID = Tx123, Hash = h1; Tx124, Hash = h2..." The leader signature is the signature of the leader's private key on the microblock header, ensuring the authenticity of the microblock.

[0092] For example, the microblock header for Micro-001 is "Sequence Number = 001, Parent Hash = Main Chain Hash, Number of Transactions = 150, Timestamp = 1627230060." The microblock body contains a summary of all 150 transactions, and the leader signature is "SigC = Private Key C Signature (Microblock Header)." After each microblock is generated, the leader node immediately broadcasts it to the network and records it in its local microblock sequence.

[0093] Microblocks are arranged in ascending order by generation timestamp, forming a continuous chain of transaction processing. Each microblock has an increasing sequence number, and the parent block hash always points to the main chain block to ensure its relevance. For example, the sequence is Micro-001 (1627230060) → Micro-002 (1627230120) → Micro-003 (1627230180). Each microblock is separated by approximately 60 seconds, which meets the processing requirements of high-liquidity transactions.

[0094] An unverified microblock set is the collection of all generated but unverified microblocks by network nodes. This collection contains the complete microblock data, generation time, leader signature, and corresponding liquidity subvector value. The leader node packages and broadcasts this unverified microblock set every 10 microblocks (or every 5 minutes) to facilitate batch verification by network nodes. For example, an unverified microblock set includes Micro-001 through Micro-010, along with the set's root hash "d1e2f3a4b5c6..." for node integrity verification.

[0095] Flow control is required when generating micro-blocks. If there is a surge in high-liquidity transactions in a short period of time (e.g., 1,000 transactions per second), the leader node will activate a dynamic micro-block size adjustment mechanism, temporarily increasing the micro-block size to 2MB while increasing the generation frequency (one every 30 seconds) to avoid transaction congestion. If the transaction flow is lower than the threshold (e.g., 10 transactions per second), the size will be reduced to 0.5MB to reduce network redundancy.

[0096] The network node performs PoW chain verification on the unverified micro-block set, calculates the hash value of each micro-block and compares it with the root hash of the main chain block. The verified micro-blocks are included in the temporary transaction pool. At the same time, the node synchronously updates the verification status of the local sub-feature vector and outputs the verified micro-block pool; Network nodes are non-leader nodes that participate in verification within the distributed network. Each node maintains a complete copy of the main chain blocks and a set of sub-feature vectors, and is capable of independently verifying microblocks. The verification process utilizes a combination of parallel and serial methods. Nodes first verify the root hash of the unverified microblock set (to ensure the set is complete), and then perform PoW chain verification on each microblock individually.

[0097] The hash value of each microblock is calculated using the SHA-256 algorithm, with the complete microblock content (microblock header + microblock body) as input. The output hash value must satisfy the association check with the root hash of the main chain block. The last 8 bits of the microblock hash must match the last 8 bits of the main chain root hash, ensuring that the microblock belongs to the current branch of the main chain and is not an isolated block. For example, if the last 8 bits of the main chain root hash are "a1b2c3d4", the hash of microblock Micro-001 is "...e5f6a1b2c3d4", and the last 8 bits match, passing the association check.

[0098] Verification also includes the validity of the leader's signature (decrypted with the leader's public key and compared with the microblock header hash), the integrity of the transaction digest (the hash of each transaction digest must be consistent with the transaction hash recorded locally by the node), and the continuity of the microblock sequence numbers (e.g., Micro-001 should be followed by Micro-002, without skipping numbers). For example, when a node verifies Micro-001, it finds that the decrypted leader signature matches the microblock header hash, the transaction digest hashes match the local record, and the sequence numbers are continuous, thus passing verification.

[0099] The temporary transaction pool is a temporary storage space for nodes to store verified microblocks. It uses a FIFO (first-in, first-out) strategy and has a capacity of 100 microblocks. When the capacity is exceeded, the oldest microblocks are written to the local disk for archiving. Microblocks in the temporary transaction pool are marked with the verification timestamp and the verification node ID, for example, "Micro-001, verification time = 1627230065, verification nodes = NodeA, NodeB, NodeD." This records the verification results of multiple nodes and enhances credibility.

[0100] The verification status of local sub-feature vectors tracks the trustworthiness of each sub-vector, with statuses ranging from "pending verification," "partially verified," to "fully verified." When a microblock passes verification, the number of validating nodes for its corresponding sub-feature vector (such as the liquidity sub-vector) increases. When the number of validating nodes is ≥3, the status changes from "pending verification" to "partially verified." When verification is passed by ≥10 nodes and no nodes raise objections, the status changes to "fully verified." For example, after three nodes pass verification for the liquidity sub-vector 0.9, its status changes to "partially verified." As more nodes verify, it eventually becomes "fully verified."

[0101] The verified microblock pool is the collection of all microblocks with a status of "partially verified" or higher, sorted in ascending order by microblock number. Each microblock is accompanied by multiple nodes' verification signatures (node ​​public key + verification time). For example, the microblock pool may contain Micro-001 (verified by 5 nodes) and Micro-002 (verified by 8 nodes). The collection of verification signatures for each microblock forms a "verification consensus," which provides the basis for subsequent integration.

[0102] Micro-blocks that fail verification (such as hash mismatch or invalid signature) will be marked as "invalid" and the reason for failure will be recorded (such as "leader signature forgery" or "last 8 digits of hash mismatch"). The micro-blocks will be broadcast to the entire network to alert other nodes and trigger the leader node to regenerate the micro-block to ensure that transactions are not lost.

[0103] Based on the value stability sub-vector, multi-objective optimization weights are set, the main chain blocks and the verified micro-block pool are integrated, the blocks that meet the weight threshold are screened out, and integrated into the optimized data block set by timestamp.

[0104] The value stability subvector measures the volatility of a data asset's value. Key parameters include generation time (newer, more stable), data size (larger, more stable), and value volatility (the rate of change in historical value). These parameters are normalized to a 0-1 scale, with higher values ​​indicating greater value stability. For example, a data asset with a value stability subvector of 0.8 indicates that it was recently generated (within a month), has a large data size (10GB), and has low value volatility (monthly fluctuation ≤5%), making it a highly stable asset.

[0105] Multi-objective optimization weights are used to balance the three key characteristics of security, liquidity, and value stability. Weightings should be tailored to the business scenario. For example, in financial data asset transactions, security is weighted at 0.4, liquidity at 0.3, and value stability at 0.3. In social data asset transactions, liquidity can be weighted up to 0.5. The weights must sum to 1, and each weight must be ≥ 0.1 to avoid overlooking any particular characteristic. For example, the weights for this optimization are [Security 0.4, Liquidity 0.3, Stability 0.3].

[0106] The process of integrating the mainchain block and microblock pool involves calculating a comprehensive score for each block using the formula "Comprehensive score = Security subvector × Security weight + Liquidity subvector × Liquidity weight + Stability subvector × Stability weight." The mainchain block's comprehensive score is calculated based on the core transactions it contains, while the microblock's comprehensive score is the average score of all transactions within it. For example, a mainchain block with a Security subvector of 0.89, Liquidity 0.7, and Stability 0.8 would have a Comprehensive score of 0.89 × 0.4 + 0.7 × 0.3 + 0.8 × 0.3 = 0.356 + 0.21 + 0.24 = 0.806. The average score for a microblock is 0.78, both exceeding the weight threshold of 0.7.

[0107] When screening blocks that meet the weight threshold, a passing score of ≥0.7 is set. Blocks with scores below this value (e.g., 0.65) are marked as "pending optimization" and require reassessment of their characteristics to ensure compliance. The screening process also checks for logical consistency between blocks, such as whether transactions between mainchain blocks and microblocks conflict (e.g., duplicate transactions of the same asset). If conflicts exist, transactions in the mainchain blocks are prioritized (due to their higher security).

[0108] Timestamp consolidation involves sorting the filtered main chain blocks and micro blocks in ascending order of their generation timestamps to form a coherent set of optimized data blocks. The main chain block serves as the "anchor," and the micro blocks follow in sequence. Each micro block points to the hash of the main chain block, forming a hierarchical structure of "main chain + micro chain." For example, the order of the consolidation set is: main chain block (timestamp = 1627230000) → Micro-001 (1627230060) → Micro-002 (1627230120), with continuous timestamps and a clear structure.

[0109] Each block in the optimized data block set is accompanied by a composite score and the number of validating nodes, such as the main chain block (score 0.806, verified by 20 nodes) and Micro-001 (0.78, verified by 15 nodes), ensuring traceability of the set's quality. Simultaneously, the set's root hash (the Merkle root of all block hashes) is calculated and broadcasted for network-wide verification of the integrity of the integration. If a node's root hash matches the broadcast value, the optimized set is accepted; otherwise, the data is resynchronized to ensure network-wide data consistency.

[0110] During the integration process, if duplicate transactions are found (the same transaction ID appears in multiple micro-blocks), the one with the earliest timestamp will be retained, and the rest will be marked as "invalid duplicates" to avoid double trading of assets. If there is an error in the calculation of the transaction amount (if any) (such as violating the "payment amount = unit price × quantity"), the exchange's comprehensive score in the micro-block will be deducted by 0.1. If it is still ≥ 0.7 after the deduction, it will be retained; otherwise, it will be eliminated to ensure the accuracy of the optimized set.

[0111] S204: Apply a distributed consistency algorithm to verify and confirm the optimized data block set, and determine several final data blocks as the consensus results of the corresponding data asset transaction request.

[0112] Specifically, the optimized data block set can be broadcast to all consensus nodes in the distributed network. Each node calls the smart contract to locally execute the transaction logic in the block, check the consistency of the block hash value and the sub-feature vector, and output the node local verification result; The optimized data block set consists of mainchain blocks and microblocks that have undergone multi-objective optimization. Its broadcast is implemented using the gossip protocol. Upon receiving the set, each consensus node immediately forwards it to 3-5 randomly selected neighboring nodes. This process repeats until all consensus nodes in the network (typically 5-20 nodes, adjusted dynamically based on network scale) have received the complete set. During the broadcast process, each block is accompanied by a digital signature (signed with the leader's private key). Receiving nodes first verify the validity of the signature (decrypted using the leader's public key) to ensure that the block has not been tampered with. For example, after receiving the optimized set, node A verifies the signature using the leader's public key, PubC, to confirm that the signature matches the block hash before proceeding.

[0113] Consensus nodes are trusted nodes that participate in final verification. They must meet pre-defined qualifications (e.g., computing power ≥ 1 TH / s, node uptime ≥ 90%) and be registered through a Distributed Identity (DID) system, with identifiers such as "Consensus-Node1" and "Consensus-Node2." Each node maintains an independent local database, storing a copy of the blockchain, smart contract code, and sub-feature vectors, providing comprehensive verification capabilities.

[0114] Smart contracts are predefined, automated execution codes that encapsulate the business logic of data asset transactions, such as "ownership transfer rules" (which require digital signature confirmation from the original owner), "transaction limit verification" (single transaction amount ≤ 1 million yuan), and "compliance checks" (cross-border transactions must include compliance identification). When a smart contract is invoked, the node takes the transaction details in the block (IDs of both parties, underlying asset identifiers, transfer amount, etc.) as input, executes the contract code, and outputs a "valid" or "invalid" logical verification result. For example, if the ownership chain of the underlying asset in a transaction shows that the current owner is User A, but the transaction was initiated by User B (without User A's authorized signature), the smart contract will output "invalid" after execution, marking the transaction as a logical violation.

[0115] The consistency check between the block hash and the sub-feature vector is a core part of the verification process. The block hash is calculated using SHA-256 from the block header (which includes the sub-feature vector, timestamp, and previous block hash). For example, if the block header contains "sub-feature vector = [0.8, 0.7, 0.9], timestamp = 1627230000, and previous hash = H0," the calculated hash value is H1 = SHA-256 (header information). The consistency check verifies two key points: first, whether the hash value recorded in the block is consistent with the H1 recalculated by the node (to prevent tampering); and second, whether the hash value contains the characteristics of the sub-feature vector. For example, a specific algorithm (such as normalizing the sub-feature vector as part of the hash input) is used to ensure the binding between the hash and the sub-feature. If the recalculated hash deviates from the recorded value by more than 0.0001 (hexadecimal difference), the hash is considered inconsistent.

[0116] The node's local verification result consists of three parts: transaction logic verification (valid / invalid), hash consistency verification (consistent / inconsistent), and comprehensive verification conclusion (pass / fail). The comprehensive conclusion is determined as follows: only when the transaction logic is "valid" and the hash is "consistent" is the conclusion considered "passed"; otherwise, it is considered "failed." For example, node 1's verification result for block A is "transaction logic valid, hash consistent → pass"; node 2's result is "transaction logic valid, hash inconsistent → fail" and the specific discrepancy is recorded (for example, if the hash is H1' and the calculated H1 is H1, the discrepancy is in the 8th bit).

[0117] Verification results must be accompanied by a node signature and timestamp to verify their authenticity and timeliness. For example, the result signature for node 1 is "Sig-Node1 = Private Key 1 Signature (Result + Timestamp)", with timestamp accuracy to the millisecond (e.g., 1627230001.123). Local verification results for all nodes will be temporarily stored in a local result pool, awaiting collection using the Byzantine Fault Tolerance algorithm. The average verification time must be kept within 10 seconds to ensure consensus efficiency.

[0118] A practical Byzantine fault-tolerant algorithm is used to collect local verification results from all nodes. When the proportion of nodes that agree to pass the verification exceeds 2 / 3, the consensus confirmation process is triggered, and the list of nodes that agree on each block and the reasons for rejection of the dissenting nodes are recorded, and the consensus confirmation certificate is output; The Practical Byzantine Fault Tolerance (PBFT) algorithm is a consensus algorithm designed to mitigate malicious nodes in distributed networks (such as those sending incorrect information or failing to respond). Its core principle is to ensure consensus can be reached even when the proportion of malicious nodes does not exceed 1 / 3 through a three-phase protocol (pre-prepare, prepare, and confirm). For example, consider a distributed network with four consensus nodes (Node1-Node4), with a maximum of one malicious node allowed. Consensus requires the agreement of at least three nodes (a minimum of 2 / 3).

[0119] The pre-prepare phase of PBFT is initiated by the master node (usually the leader node or rotating node in step 1). The master node collects the local verification results of all nodes, groups them by block, and generates a pre-prepare message for each block. This message contains the block hash, the master node's signature, and a verification result summary (e.g., "3 passed, 1 failed"). For example, the master node generates a pre-prepare message for block A: "Pre-Prepare = Block A hash + H0, Signature = PubC, Summary = 3 / 1" and broadcasts it to all consensus nodes.

[0120] During the preparation phase, each node receives the pre-prepare message and verifies its legitimacy (masternode signature, block hash match). If valid, it broadcasts the prepare message to the entire network, including an "agree / disagree" flag and supporting evidence (such as the hash calculation process from the local verification result). For example, if Node1 approves block A, the prepare message would read "Prepare=Node1, Block A, Approve, Evidence=Hash Calculation Record." Node4, a malicious node, sends a "disagree" message without providing evidence, and its message will be ignored.

[0121] The confirmation phase is the final stage of consensus. A node collects prepare messages from other nodes. When it receives "Agree" prepare messages from more than two-thirds of the nodes (with valid evidence), it broadcasts a confirmation message to the entire network. If it receives "Disagree" messages from more than one-third of the nodes, it broadcasts a disapproval confirmation message. For example, if Node1 receives agree prepare messages from Node2 and Node3 (including its own, a total of three agrees, with a 3 / 4 > 2 / 3 ratio), it will broadcast the confirmation message "Commit = Node1, Block A, Agree."

[0122] When the number of confirmation messages for a block exceeds 2 / 3 of the nodes, the consensus confirmation process is triggered. For example, if Block A receives confirmation messages from Node1-Node3 (3 / 4 > 2 / 3), it is considered passed. However, Block B receives confirmation messages only from Node1-Node2 (2 / 4 < 2 / 3), and is considered failed. For failed blocks, the rejection reasons of the dissenting nodes need to be analyzed. Common reasons include "transaction logic violations (e.g., ownership transfer without the original owner's signature)," "hash inconsistency (difference between recorded and calculated values)," and "sub-feature vector mismatch (the hash does not contain feature information)." For example, Node4's rejection of Block A was due to a "discrepancy between the calculated and recorded hashes at bit 8 (0x3 vs. 0x5)."

[0123] When recording the list of consenting nodes, the node ID, signature, and confirmation timestamp must be included. For example, the consent list for block A is "Node1 (Sig1, 1627230002.123), Node2 (Sig2, 1627230002.145), Node3 (Sig3, 1627230002.156)". In addition to the node ID, the dissenting node list must also record the reasons for rejection and evidence in detail (such as hash calculation comparison tables and screenshots of transaction logic violations), for example, "Node4: Hash difference (record H1'=...3..., calculate H1=...5...), evidence = Attachment 1".

[0124] The consensus confirmation certificate is a structured document containing the consensus results of all blocks. Its format is: block ID + consensus result (pass / fail) + list of consenting nodes + list of dissenting nodes + certificate root hash. The certificate root hash is calculated by concatenating the consensus result hashes of all blocks. For example, if the result hash of block A is HA and that of block B is HB, the root hash is SHA-256 (HA+HB), ensuring that the certificate cannot be tampered with. After the certificate is generated, it is jointly signed by all consenting nodes and stored in the distributed ledger, where it can be retrieved and verified by any node.

[0125] For blocks that fail to pass, the consensus confirmation process will trigger a secondary verification mechanism: the rejection reasons of the dissenting nodes will be extracted, and the master node will organize 3 random nodes to form a review team to re-verify the block. If the review result is "passed" (2 / 3 of the review nodes agree), the consensus result will be updated to "passed". Otherwise, it will be marked as an "invalid block" and must be returned to the data block set optimization stage for reprocessing to ensure that all transaction requests can be handled reasonably.

[0126] Based on the consensus confirmation certificate, the final hash chain verification is performed on the passed blocks to ensure the consistency and immutability between blocks, filter out abnormal blocks with broken hash chains, and output the candidate block sequence that has passed the verification; Hash chain verification is a key step in ensuring the consistency and immutability of blockchains. Its core principle is that "each block's hash value contains the hash value of the previous block," forming a "chain structure." Any tampering with a historical block will invalidate the hash values ​​of subsequent blocks, thus being detected. For example, the blockchain sequence is Block0 → Block1 → Block2, where Block1's hash H1 contains Block0's hash H0, and Block2's hash H2 contains H1. Therefore, H1 = SHA-256 (Block1 content + H0), and H2 = SHA-256 (Block2 content + H1).

[0127] Based on the consensus confirmation certificate, first filter out the "passed" blocks. Assume that the passed blocks are Block0 (H0), Block1 (H1), Block2 (H2), and Block3 (H3). They need to be sorted by timestamp (make sure to verify in the generation order). After sorting, it is Block0 (t0) → Block1 (t1) → Block2 (t2) → Block3 (t3), where t0 <t1<t2<t3。

[0128] The specific process of hash chain verification is as follows: starting from the first block (Block0), record its hash H0; verify whether the hash H1 of the second block (Block1) contains H0, that is, extract the "previous hash" field from the block header of Block1, check whether it is equal to H0, and recalculate H1'=SHA-256 (Block1 content + H0). If H1'=H1 and the previous hash = H0, then Block1 passes the verification; then use H1 to verify Block2, and repeat the above process until all passed blocks are verified.

[0129] For example, the pre-order hash field of Block1 is recorded as H0, and the recalculated H1'=SHA-256 (Block1 content + H0)=H1 is consistent with the recorded H1 and passes the verification; the pre-order hash field of Block2 is recorded as H1, but the recalculated H2'=SHA-256 (Block2 content + H1)=H2''≠H2, and the recorded H2 does not contain H1 (hash analysis shows that the pre-order hash field has been tampered with to H1'), so Block2's hash chain is determined to be broken and it is an abnormal block.

[0130] Immutability verification requires a combination of historical hash records. After each block's hash value is generated, it is broadcast to all nodes in the network and written to the local hash library. Verification involves comparing the current block hash with the historical record in the hash library. If the difference exceeds a preset threshold (e.g., a 1-digit difference in hexadecimal), it is determined to have been tampered with. For example, if the historical hash library record for Block0 is H0, and the current calculation is H0', a comparison reveals that H0' differs from H0 at the 10th bit (0x7 vs. 0x3), Block0 is determined to have been tampered with, and all subsequent blocks (which rely on H0) are marked as abnormal.

[0131] Abnormal block filtering follows the "break, eliminate" principle: If a block's hash chain is broken (e.g., Block 2), that block and all subsequent blocks (Block 3) are eliminated, retaining only valid blocks before the break (Block 0 and Block 1). If a block has been tampered with (e.g., Block 0), all blocks are eliminated, and the process returns to the initial stage to regenerate the block. After filtering, the cause of the abnormality must be recorded, such as "Block 2: Hash calculation inconsistency, preceding hash field tampering" or "Block 0: Dissimilar to historical hash library records, suspected tampering," to provide a basis for subsequent tracing.

[0132] The candidate block sequence that has passed verification is a set of blocks with a complete and untampered hash chain, arranged in ascending timestamp order. Each block is accompanied by a verification identifier (such as "Verification Passed_Hash Chain Complete"), a verification node signature (at least three node signatures), and a verification timestamp. For example, the candidate block sequence is [Block0 (t0, Verification Passed), Block1 (t1, Verification Passed)]. This sequence ensures consistency from the initial block to the current block. The hash of each block can be traced back to its source, laying the foundation for the final consensus result.

[0133] To improve verification efficiency, hash chain verification adopts a parallel computing mode. Each node is responsible for verifying part of the blocks (for example, 4 nodes are divided into 10 blocks for verification, and each node verifies 2-3 blocks). The verification results are synchronized through the P2P network and finally summarized by the master node to form a global verification result. The average verification time is controlled within 30 seconds to avoid affecting the overall efficiency of the consensus process.

[0134] The candidate block sequence is arranged in ascending order by transaction timestamp to generate a final data blockchain containing the complete ownership chain, transaction records and sub-feature vector labels as the consensus result of the corresponding data asset transaction request.

[0135] Although the candidate block sequence has passed the hash chain verification, it may contain timestamp disorder (for example, the timestamp of a later generated block is earlier than that of the previous block). Therefore, it must be sorted in ascending order by transaction timestamp to ensure the timing consistency of the blockchain. The transaction timestamp is the time record of each transaction initiation (accurate to milliseconds). The timestamp of a block is the earliest transaction timestamp contained in it. The block timestamp is used as the basis for sorting. If the timestamp difference between two blocks is less than 1 second (possibly caused by network latency), the blocks are sorted in lexicographic order by hash value (lower hash value first).

[0136] For example, in the candidate block sequence, the timestamp of Block0 is 1627230000.123, and that of Block1 is 1627230000.098 (due to network latency, the timestamp is slightly earlier). The difference between the two block timestamps is 0.025 seconds, less than 1 second. Arranged in lexicographical order by hash: Block1 hash is "a1b2c3...", and Block0 is "b1c2d3...". Because "a" is earlier than "b" in the lexicographical order, the order is [Block1, Block0], ensuring the relative rationality of the time sequence.

[0137] The integration of a complete ownership chain requires tracing the ownership transfer history of each data asset. From the initial owner to the current owner, each transfer record must include the signature of the previous owner, the signature of the subsequent owner, the transfer timestamp, and the underlying asset identifier, forming a complete chain of "Owner A → Owner B → Owner C." For example, the ownership chain of a data asset records "Initial Owner = UserA" in Block0 and "UserA → UserB (Signature Verification Passed)" in Block1. After integration, the ownership chain is "UserA (t0) → UserB (t1)", ensuring that the transfer of asset ownership is traceable.

[0138] The consolidated transaction record must include detailed information for each transaction: transaction ID, transacting party IDs, underlying asset identifier, transaction amount (if any), transaction status ("Confirmed"), digital signature, and corresponding sub-feature vector label (e.g., "Security = 0.9, Liquidity = 0.8, Value Stability = 0.7"). For example, the consolidated transaction record for Block 1 would be "Tx001: UserA→UserB, Asset ID = Asset123, Amount = 500 RMB, Status = Confirmed, Signature = SigA+SigB, Sub-feature Label = Security 0.9_Liquidity 0.8_Stability 0.7."

[0139] The embedding of sub-feature vector labels must correspond one-to-one with each block. Each block header contains a set of sub-feature vectors for the transactions processed by that block (e.g., [0.9, 0.8, 0.7]). The labels are key-value pairs of "feature type = value," facilitating subsequent queries of the core characteristics of transactions in that block. For example, the sub-feature labels for Block0 are "Security = 0.85, Liquidity = 0.7, Value Stability = 0.8," while the labels for Block1 are "Security = 0.9, Liquidity = 0.8, Value Stability = 0.7," clearly reflecting the changing characteristics of transactions at different stages.

[0140] The final data blockchain is a complete chain integrating the above information. Its structure includes: a block header (block identifier, timestamp, pre-order hash, sub-feature tags, and transaction count), a block body (transaction record list, ownership chain fragment, and consensus confirmation certificate summary), and a block trailer (verifier node signature and hash value). For example, the first block of the final blockchain, Block 0, contains the initial transaction record and the starting point of ownership. Subsequent blocks are connected in sequence, forming a complete closed loop of "transaction initiation → verification → consensus → confirmation".

[0141] This blockchain, as the consensus result of the data asset transaction request, will be written into the distributed ledger and broadcast to the entire network. Both parties to the transaction can query the blockchain using the underlying asset identifier to obtain the final status and complete record of the transaction. At the same time, the blockchain hash value is synchronized to multiple backup nodes to ensure data durability and resilience. Any node failure or data loss will not affect the validity of the consensus result.

[0142] It can be seen that a data asset transaction request is received in a distributed network, and a set of initial data block sets is generated based on the transaction request; feature mapping is performed on the initial data block set to construct a block feature vector set, and the feature vectors in the block feature vector set are decomposed into several sub-feature vectors to capture the different characteristics of the data assets; the sub-feature vectors are multi-objective optimized using the improved Bitcoin-NG consensus mechanism to generate an optimized data block set; the optimized data block set is verified and confirmed by applying a distributed consistency algorithm to determine several final data blocks as the consensus results of the corresponding data asset transaction request, thereby improving the efficiency and security of the data asset consensus.

[0143] Another embodiment of the present invention provides a consensus system based on data assets, see Figure 3 , the system may include: A receiving module 301 is configured to receive a data asset transaction request in a distributed network and generate a set of initial data blocks based on the transaction request, wherein each initial data block is associated with a characteristic dimension of the data asset; Construction module 302 is used to perform feature mapping on the initial data block set, construct a block feature vector set, and decompose the feature vectors in the block feature vector set into a number of sub-feature vectors to capture different characteristics of the data asset, where each feature vector represents a multi-dimensional feature attribute of the corresponding initial data block; an optimization module 303 for performing multi-objective optimization on the sub-feature vectors using an improved Bitcoin-NG consensus mechanism to generate an optimized data block set, wherein the improved Bitcoin-NG consensus mechanism confirms leaders through main chain blocks and processes transactions in micro-blocks, and combines with the PoW chain to ensure the security and immutability of data assets; The verification module 304 is used to apply a distributed consistency algorithm to verify and confirm the optimized data block set, and determine a number of final data blocks as the consensus results of the corresponding data asset transaction request.

[0144] An embodiment of the present invention further provides a storage medium storing a computer program, wherein the computer program is configured to execute the steps of any one of the above method embodiments when running.

[0145] An embodiment of the present invention further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any one of the above method embodiments.

[0146] Specifically, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0147] The above describes in detail the structure, features and effects of the present invention based on the embodiments shown in the drawings. The above is only a preferred embodiment of the present invention, but the scope of implementation of the present invention is not limited to what is shown in the drawings. Any changes made in accordance with the concept of the present invention, or modifications to equivalent embodiments with equivalent changes, which do not exceed the spirit covered by the description and drawings, should be within the scope of protection of the present invention.

Claims

1. A consensus method based on data assets, characterized in that: The method comprises: Receiving a data asset transaction request in a distributed network, and generating a set of initial data blocks based on the transaction request, wherein each initial data block is associated with a characteristic dimension of the data asset; Perform feature mapping on the initial data block set, construct a block feature vector set, and decompose the feature vectors in the block feature vector set into several sub-feature vectors to capture the different characteristics of the data assets, where each feature vector represents the multi-dimensional feature attributes of the corresponding initial data block; Performing multi-objective optimization on the sub-feature vectors using an improved Bitcoin-NG consensus mechanism to generate an optimized data block set, wherein the improved Bitcoin-NG consensus mechanism confirms leaders through main chain blocks and processes transactions in micro-blocks, and combines with the PoW chain to ensure the security and immutability of data assets; A distributed consistency algorithm is applied to the optimized data block set for verification and confirmation, and several final data blocks are determined as the consensus results of the corresponding data asset transaction request.

2. The method according to claim 1, characterized in that The receiving of a data asset transaction request in a distributed network and generating a set of initial data blocks based on the transaction request, wherein each initial data block is associated with a characteristic dimension of the data asset, including: Receive data asset transaction requests through distributed network nodes, parse the asset type, digital signatures of both parties in the request, and the underlying asset identifier, use elliptic curve encryption algorithm to verify the validity of the signature, filter out malicious requests with invalid signatures, and output a list of valid transaction requests; For each request in the valid transaction request list, extract the characteristic dimensions of the corresponding data asset, including data size, generation time, ownership chain length, encryption level, and circulation frequency. Eliminate dimensional differences through feature standardization and output a data asset characteristic dimension table. Based on the data asset feature dimension table, a clustering algorithm is used to group transaction requests by feature similarity. Each group corresponds to a feature dimension combination. A unique initial block identifier is assigned to each group, and a block-feature dimension mapping table is output. According to the block-feature dimension mapping table, the detailed information of each set of transaction requests is packaged into an initial data block, and the corresponding feature dimension label is embedded in the header of each block to generate an initial data block set.

3. The method according to claim 2, characterized in that The feature mapping is performed on the initial data block set to construct a block feature vector set, and the feature vectors in the block feature vector set are decomposed into a number of sub-feature vectors to capture different characteristics of the data asset, wherein each feature vector represents a multi-dimensional feature attribute of the corresponding initial data block, including: Traverse the initial data block set, extract the specific value corresponding to the feature dimension label for each block, and construct the original feature matrix by combining the derived features of the block including transaction throughput and verification time. The original feature matrix is ​​normalized using maximum and minimum normalization to eliminate the dimensional influence of different feature dimensions. The variance inflation factor is used to detect and remove multicollinearity features, and the de-redundant normalized feature matrix is ​​output. Based on the de-redundant normalized feature matrix, a deep learning embedding model is used to map the multi-dimensional features of each block into a high-dimensional vector. Each dimension of the vector corresponds to an abstract expression of the feature, and the block feature vector set is output. Apply a non-negative matrix factorization algorithm to the set of block feature vectors, set the decomposition dimension according to the core characteristics of the data asset, decompose each high-dimensional feature vector into multiple sub-feature vectors, each corresponding to the quantitative expression of a single characteristic, and output the initial sub-feature vector set; Calculate the mutual information value of the initial sub-feature vector set, remove redundant sub-vectors with mutual information higher than the threshold, verify the independence of the sub-vectors through principal component analysis, and output the optimized sub-feature vector set.

4. The method according to claim 3, characterized in that The improved Bitcoin-NG consensus mechanism is used to perform multi-objective optimization on the sub-feature vectors to generate an optimized data block set, wherein the improved Bitcoin-NG consensus mechanism confirms the leader and processes transactions in micro-blocks through the main chain block, and combines the PoW chain to ensure the security and immutability of data assets, including: Extract the security sub-vector from the sub-feature vector set, combine it with the node computing power value to construct a comprehensive score, elect the main chain block leader through computing power competition, and output the leader node identifier and hash record of the election process; The leader node generates the main chain block based on the security sub-vector. The block header contains the root hash of the sub-feature vector set, the leader's public key, and term information. The main chain block mining is completed through the PoW mechanism, and the main chain block with PoW proof is output. The leader node sorts transaction requests based on the liquidity sub-vector and prioritizes packaging high-liquidity requests into micro-blocks. Each micro-block contains the transaction summary corresponding to the sub-feature vector and the leader's signature. A micro-block sequence is generated in the order of transactions, and an unverified micro-block set is output. The network node performs PoW chain verification on the unverified micro-block set, calculates the hash value of each micro-block and compares it with the root hash of the main chain block. The verified micro-blocks are included in the temporary transaction pool. At the same time, the node synchronously updates the verification status of the local sub-feature vector and outputs the verified micro-block pool; Based on the value stability sub-vector, multi-objective optimization weights are set, the main chain blocks and the verified micro-block pool are integrated, the blocks that meet the weight threshold are screened out, and integrated into the optimized data block set by timestamp.

5. The method according to claim 4, characterized in that The application of a distributed consistency algorithm to the optimized data block set to verify and confirm, and determine a number of final data blocks as the consensus results of the corresponding data asset transaction request, includes: The optimized data block set is broadcast to all consensus nodes in the distributed network. Each node calls the smart contract to locally execute the transaction logic in the block, checks the consistency of the block hash value and the sub-feature vector, and outputs the node's local verification result. A practical Byzantine fault-tolerant algorithm is used to collect local verification results from all nodes. When the proportion of nodes that agree to pass the verification exceeds 2 / 3, the consensus confirmation process is triggered, and the list of nodes that agree on each block and the reasons for rejection of the dissenting nodes are recorded, and the consensus confirmation certificate is output; Based on the consensus confirmation certificate, the final hash chain verification is performed on the passed blocks to ensure the consistency and immutability between blocks, filter out abnormal blocks with broken hash chains, and output the candidate block sequence that has passed the verification; The candidate block sequence is arranged in ascending order by transaction timestamp to generate a final data blockchain containing the complete ownership chain, transaction records and sub-feature vector labels as the consensus result of the corresponding data asset transaction request.

6. A consensus system based on data assets, characterized by: The system comprises: A receiving module, configured to receive a data asset transaction request in a distributed network, and generate a set of initial data blocks based on the transaction request, wherein each initial data block is associated with a characteristic dimension of the data asset; A construction module is used to perform feature mapping on the initial data block set, construct a block feature vector set, and decompose the feature vectors in the block feature vector set into several sub-feature vectors to capture different characteristics of the data asset, where each feature vector represents a multi-dimensional feature attribute of the corresponding initial data block; an optimization module for performing multi-objective optimization on the sub-feature vectors using an improved Bitcoin-NG consensus mechanism to generate an optimized data block set, wherein the improved Bitcoin-NG consensus mechanism confirms leaders through main chain blocks and processes transactions in micro-blocks, and combines with the PoW chain to ensure the security and immutability of data assets; The verification module is used to apply a distributed consistency algorithm to verify and confirm the optimized data block set, and determine several final data blocks as the consensus results of the corresponding data asset transaction request.

7. The system according to claim 6, characterized in that The receiving module is specifically configured to: Receive data asset transaction requests through distributed network nodes, parse the asset type, digital signatures of both parties in the request, and the underlying asset identifier, use elliptic curve encryption algorithm to verify the validity of the signature, filter out malicious requests with invalid signatures, and output a list of valid transaction requests; For each request in the valid transaction request list, extract the characteristic dimensions of the corresponding data asset, including data size, generation time, ownership chain length, encryption level, and circulation frequency. Eliminate dimensional differences through feature standardization and output a data asset characteristic dimension table. Based on the data asset feature dimension table, a clustering algorithm is used to group transaction requests by feature similarity. Each group corresponds to a feature dimension combination. A unique initial block identifier is assigned to each group, and a block-feature dimension mapping table is output. According to the block-feature dimension mapping table, the detailed information of each set of transaction requests is packaged into an initial data block, and the corresponding feature dimension label is embedded in the header of each block to generate an initial data block set.

8. The system according to claim 7, characterized in that The building blocks are specifically used for: Traverse the initial data block set, extract the specific value corresponding to the feature dimension label for each block, and construct the original feature matrix by combining the derived features of the block including transaction throughput and verification time. The original feature matrix is ​​normalized using maximum and minimum normalization to eliminate the dimensional influence of different feature dimensions. The variance inflation factor is used to detect and remove multicollinearity features, and the de-redundant normalized feature matrix is ​​output. Based on the de-redundant normalized feature matrix, a deep learning embedding model is used to map the multi-dimensional features of each block into a high-dimensional vector. Each dimension of the vector corresponds to an abstract expression of the feature, and the block feature vector set is output. Apply a non-negative matrix factorization algorithm to the set of block feature vectors, set the decomposition dimension according to the core characteristics of the data asset, decompose each high-dimensional feature vector into multiple sub-feature vectors, each corresponding to the quantitative expression of a single characteristic, and output the initial sub-feature vector set; Calculate the mutual information value of the initial sub-feature vector set, remove redundant sub-vectors with mutual information higher than the threshold, verify the independence of the sub-vectors through principal component analysis, and output the optimized sub-feature vector set.

9. A storage medium, characterized in that: The storage medium stores a computer program, wherein the computer program is configured to execute the method according to any one of claims 1 to 5 when executed.

10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to run the computer program to perform the method according to any one of claims 1 to 5.

Images