Computer data transaction method and device based on block chain, equipment and medium

Abstract

The invention relates to a computer data transaction method and device based on a block chain, equipment and a medium. The method comprises the following steps: acquiring transaction data of computer data in a block chain network; the transaction data comprises storage data, transmission data, verification data and execution data; distributing the storage data to a storage layer, distributing the transmission data to a network layer, distributing the verification data to a consensus layer, and distributing the execution data to an application layer to obtain a hierarchical architecture model; obtaining a real-time transaction load from the block chain network and updating operation parameters of the hierarchical architecture model to obtain a dynamic optimization parameter set; and based on the dynamic optimization parameter set, performing parameter updating operation in a distributed manner to obtain a transaction scheme. By adopting the method, the transaction sub-channel processing efficiency can be improved, the disk utilization rate can be reduced, the network bandwidth waste can be reduced, the peak throughput can be improved, the transaction delay and the transaction failure rate can be reduced, and the success rate of complex contract execution can be improved.

Description

Technical Field

[0001] The present invention belongs to the field of data processing technology, and in particular relates to a computer data transaction method, device, equipment and medium based on blockchain. Background Art

[0002] Blockchain technology, at the core of distributed data management, is profoundly transforming the way data is traded. Its decentralization, transparency, and security provide a crucial foundation for building a trusted trading environment. In the field of computer data transactions, blockchain applications can ensure data authenticity and transaction reliability, playing a key role in driving the data economy and digital transformation. However, existing data trading methods still face significant limitations. Many solutions rely on centralized platforms, making data privacy difficult to guarantee, and transaction efficiency is constrained by the processing power of central nodes. Furthermore, while some blockchain solutions achieve decentralization, they still suffer from complex system architectures, high inter-module coupling, difficulty in independent optimization, and limited scalability. These shortcomings make it difficult to strike a balance between security, efficiency, and flexibility in data transactions, necessitating a more optimized technical architecture.

[0003] The core challenge in blockchain-based computer data transactions lies in achieving modular design and efficient collaboration. Data transactions involve multiple stages, including storage, transmission, verification, and execution. A lack of clear functional separation among these stages leads to a surge in system complexity and high maintenance and upgrade costs. Furthermore, the lack of modularity makes it difficult to independently optimize each stage. For example, encryption mechanisms for data storage struggle to adapt to the privacy requirements of different scenarios, while consensus mechanisms for transaction verification may become less efficient as the network scales. The collaboration challenges caused by this lack of modularity further exacerbate performance bottlenecks in high-concurrency transaction scenarios, limiting the widespread application of blockchain in data transactions.

[0004] Therefore, how to design a layered architecture to divide the data transaction process into different levels according to functions and permissions, and achieve independent optimization and efficient collaboration of each module has become a key issue that needs to be urgently solved in blockchain-based computer data transaction methods. Summary of the Invention

[0005] Based on this, it is necessary to provide a blockchain-based computer data transaction method, device, equipment and medium that can improve transaction efficiency in response to the above technical problems.

[0006] In a first aspect, the present application provides a computer data transaction method based on blockchain, comprising:

[0007] Obtain transaction data of computer data in the blockchain network; transaction data includes storage data, transmission data, verification data, and execution data;

[0008] Assign storage data to the storage layer, transmission data to the network layer, verification data to the consensus layer, and execution data to the application layer, resulting in a layered architecture model.

[0009] Obtain real-time transaction load from the blockchain network and update the operating parameters of the layered architecture model to obtain a dynamically optimized parameter set;

[0010] Based on the dynamically optimized parameter set, the parameter update operation is executed in a distributed manner to obtain the trading plan.

[0011] In one embodiment, the consensus layer includes a hybrid consensus model, which includes:

[0012] The input preprocessing layer receives raw transaction data, extracts transaction feature vectors, and assigns transactions to verification channels based on a dynamic clustering algorithm.

[0013] The weight calculation layer is used to calculate the dynamic weight of nodes through the hybrid PoS-FBFT mechanism and generate the verification node topology map;

[0014] Consensus execution layer, used to dynamically adjust consensus thresholds;

[0015] The state synchronization layer is used to verify the consistency of cross-layer states;

[0016] Output layer, used to aggregate channel verification results.

[0017] In one embodiment, obtaining transaction data of computer data in a blockchain network includes:

[0018] Through the preset blockchain node scanning program, the nodes in the blockchain network are traversed and scanned to identify the smart contract code segments and database connection configuration information related to data storage as storage data; the communication protocol code and network interface definition used for data transmission between nodes are identified as transmission data; the consensus algorithm code and signature verification logic used to verify the legitimacy of the transaction are identified as verification data; the business processing code and status update logic used to execute the transaction logic are identified as execution data.

[0019] In one embodiment, real-time transaction load is obtained from the blockchain network and operating parameters of the layered architecture model are updated to obtain a dynamically optimized parameter set, including:

[0020] Monitor the number of transactions, data transmission volume, and verification request volume in the blockchain network in real time and obtain monitoring results;

[0021] Calculate the load indicators of the storage layer, network layer, consensus layer, and application layer based on the monitoring results; load indicators include storage load, transmission load, verification load, and execution load;

[0022] According to the load indicators, the operating parameters of the storage layer, network layer, consensus layer and application layer are updated according to the preset parameter update rules to obtain a dynamically optimized parameter set.

[0023] In one embodiment, the storage load is calculated using the following formula:

[0024]

[0025] Among them, L storage is the storage load, K is the number of data blocks currently being stored, and D j is the data volume of the jth data block, S current is the current storage capacity;

[0026] The transmission load is obtained using the following formula:

[0027]

[0028] Among them, L transfer is the transmission load, L is the number of transactions being transmitted at the current moment, T k is the data volume of the kth transaction, B current is the current transmission bandwidth;

[0029] The validation load is obtained using the following formula:

[0030]

[0031] Among them, L validation To verify the load, T window is the preset time window length, N validation In the preset time window T window The number of verification requests received within C i is the complexity factor of the i-th verification request;

[0032] The execution load is obtained using the following formula:

[0033]

[0034] Among them, L execution To execute the load, T window is the preset time window length, N execution In the preset time window T window The number of execution requests received within E j is the complexity factor of the j-th execution request.

[0035] In one embodiment, the parameter update rules include:

[0036] When the storage load is greater than the preset storage load threshold, the storage capacity is increased to γ ​​times the original storage capacity. storage times; where γ storage is the storage capacity adjustment factor;

[0037] When the transmission load is greater than the preset transmission load threshold, the transmission bandwidth is increased to γ ​​times the original transmission bandwidth. transfer times; where γ transfer is the transmission bandwidth adjustment coefficient;

[0038] When the verification load is greater than the preset verification load threshold, the verification threshold is lowered to γ ​​times the original verification threshold. validation times; where γ validation To verify the threshold adjustment coefficient;

[0039] When the execution load is greater than the preset execution load threshold, the execution delay threshold is increased to γ ​​times the original execution delay threshold. execution times, where γ execution Adjusts the execution delay threshold.

[0040] In one embodiment, based on a dynamically optimized parameter set, a parameter update operation is distributedly executed to obtain a trading solution, including:

[0041] Broadcast the dynamically optimized parameter set to each node of the blockchain network;

[0042] Each node independently performs parameter update operations based on the received dynamic optimization parameter set, updating the operating parameters of the local storage layer, network layer, consensus layer, and application layer;

[0043] Each node completes the data transaction based on the updated operating parameters and obtains the transaction plan.

[0044] In a second aspect, the present application also provides a computer data transaction device based on blockchain, comprising:

[0045] A data acquisition module is used to obtain transaction data of computer data in the blockchain network. Transaction data includes storage data, transmission data, verification data, and execution data.

[0046] A layered architecture model building module is used to allocate storage data to the storage layer, transmission data to the network layer, verification data to the consensus layer, and execution data to the application layer to obtain a layered architecture model;

[0047] Dynamic optimization parameter module, used to obtain real-time transaction load from the blockchain network and update the operating parameters of the layered architecture model to obtain a dynamic optimization parameter set;

[0048] The update operation module is used to perform distributed parameter update operations based on the dynamic optimization parameter set to obtain a trading plan.

[0049] In a third aspect, the present application further provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the method described in the first aspect when executing the computer program.

[0050] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which implements the steps of the method described in the first aspect when the computer program is executed by a processor.

[0051] The aforementioned blockchain-based computer data transaction method, apparatus, device, and medium divide transaction data into four functional categories: storage, transmission, verification, and execution, and map them to the storage, network, consensus, and application layers, respectively. This creates a highly cohesive, low-coupling layered architecture model, achieving a modular design that allows each layer to focus on core functions and support independent upgrades and maintenance, improving resource utilization efficiency. The storage layer focuses on data persistence management, the network layer optimizes transmission links, the consensus layer enhances verification efficiency, and the application layer unlocks business logic flexibility, enhancing architectural scalability. The system captures blockchain network transaction load in real time, dynamically updates operating parameters at each layer to form an optimized parameter set, and leverages a distributed mechanism to drive synchronized parameter tuning across all nodes in the network, achieving flexible resource allocation and load balancing. Computing power is automatically scaled up during high concurrency to avoid single bottlenecks, while intelligently scaled down during low load to reduce energy consumption. The distributed execution architecture provides the system with strong fault tolerance, allowing node failures to be automatically compensated through redundancy mechanisms. The parallel processing of parameter updates, combined with the pipelined processing of the layered architecture, improves overall transaction processing efficiency, reduces transaction latency, and enhances resource utilization, enabling stable transactions under fluctuating network loads. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0053] Figure 1 Schematic diagram of an application environment of a blockchain-based computer data transaction method in one embodiment;

[0054] Figure 2 1 is a flowchart of a computer data transaction method based on blockchain in one embodiment;

[0055] Figure 3 1 is a schematic structural diagram of a blockchain-based computer data transaction device in one embodiment;

[0056] Figure 4 A schematic diagram of the computer device structure for blockchain-based computer data transactions in one embodiment. DETAILED DESCRIPTION

[0057] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0058] The present invention provides a computer data transaction method based on blockchain, which can be applied to Figure 1 In the application environment shown, the transaction initiator terminal 101 and the transaction recipient terminal 102 communicate with the blockchain 103 via the blockchain network to obtain or store blockchain resources. The terminal devices may include, but are not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices may include smart speakers, smart TVs, smart air conditioners, and smart car devices. Portable wearable devices may include smart watches, smart bracelets, and head-mounted devices.

[0059] In an exemplary embodiment, Figure 2 As shown, a computer data transaction method based on blockchain is provided, which is applied to Figure 1 Taking the transaction initiator terminal 101 in FIG. 1 as an example, the process includes the following steps S201 to S204:

[0060] S201, obtaining transaction data of computer data in the blockchain network; transaction data includes storage data, transmission data, verification data and execution data.

[0061] For example, the transaction initiator's terminal connects to the node through a blockchain wallet and calls an interface to obtain pending transaction data. The terminal then parses the transaction structure and categorizes the data by purpose: storing data such as file hashes that need to be permanently preserved in storage data, node addresses required for network transmission in transmission data, digital signatures and other verification data in verification data, and execution instructions such as smart contract code in execution data.

[0062] S202, allocate storage data to the storage layer, allocate transmission data to the network layer, allocate verification data to the consensus layer, and allocate execution data to the application layer to obtain a layered architecture model.

[0063] Exemplarily, the transaction initiator terminal assigns the data to the corresponding layer for processing according to the data type: storage data is written to the local database and a hash value is generated, transmission data is encapsulated into a network packet and transmission parameters are set, verification data is signed and compared with the Merkle tree, and execution data is loaded into the virtual machine for execution; each layer works together through message passing to build a layered processing model that includes a storage layer, a network layer, a consensus layer, and an application layer.

[0064] S203, obtaining real-time transaction load from the blockchain network and updating the operating parameters of the layered architecture model to obtain a dynamically optimized parameter set.

[0065] For example, the transaction initiator's terminal monitors the blockchain network status in real time and collects operational metrics at each layer, such as network bandwidth utilization, block confirmation time, database read and write latency, and contract execution time. Based on these metrics, an adaptive algorithm is used to dynamically adjust parameters at each layer: the network layer adjusts transmission rates and retransmission strategies, the consensus layer optimizes verification thresholds and block sizes, the storage layer adjusts caching strategies and indexing methods, and the application layer allocates computing resources and memory space. Through continuous optimization, a dynamic parameter set is generated.

[0066] S204: Based on the dynamic optimization parameter set, a distributed parameter update operation is executed to obtain a transaction plan.

[0067] For example, the transaction initiator's terminal broadcasts the optimized parameter set to other nodes via a peer-to-peer network. After confirmation by a majority of nodes, each node synchronously updates its own parameters. The storage layer adjusts the data storage structure, the network layer optimizes routing paths, the consensus layer updates validation rules, and the application layer adjusts execution strategies. Through distributed parameter updates, the terminal generates an optimal transaction plan, including transaction sequencing, resource allocation, and execution paths, ensuring efficient transaction processing within the network.

[0068] In the above-mentioned blockchain-based computer data transaction method, the construction of a layered architecture model realizes functional decoupling and improves the system maintainability and scalability; dynamic parameter optimization enables the system to automatically adapt to network changes, improves transaction processing speed and resource utilization; distributed execution ensures network consistency and reliability; reduces the delay in processing transactions, improves throughput, reduces resource consumption, and at the same time enhances the security and fault tolerance of transactions.

[0069] Optionally, the consensus layer includes a hybrid consensus model, which includes:

[0070] The input preprocessing layer is used to receive raw transaction data and extract transaction feature vectors, and assign transactions to verification channels based on the dynamic clustering algorithm.

[0071] For example, the input preprocessing layer receives raw transaction data from the network and uses data mining techniques to extract key transaction feature vectors from information such as transaction amount, addresses of both parties, and timestamps to form a data profile. Subsequently, a dynamic clustering algorithm is used to assign transactions to different verification channels based on the similarity of transaction feature vectors. For example, small-value, high-frequency transactions can be grouped together for a fast verification channel, while large-value, low-frequency transactions can be grouped for a strict verification channel, improving verification efficiency.

[0072] The weight calculation layer is used to calculate the dynamic weight of nodes through the hybrid PoS-FBFT mechanism and generate the verification node topology map.

[0073] For example, the weight calculation layer is used to calculate the dynamic weight of each node by combining Proof of Stake (PoS) and Federated Byzantine Fault Tolerance (FBFT) mechanisms, taking into account factors such as the number of tokens staked by the node, the accuracy of historical transaction verification, and the length of time the node is online. Nodes with higher weights have greater influence in the verification process. A verification node topology is constructed based on weights, clarifying the collaboration and verification relationships between nodes and optimizing the consensus process.

[0074] The consensus execution layer is used to dynamically adjust the consensus threshold.

[0075] For example, the consensus execution layer monitors the blockchain network's transaction load, number of online nodes, network latency, and other conditions in real time. When network load is low, the consensus threshold is appropriately lowered to speed up transaction confirmation. When the network is congested, the threshold is raised to ensure the accuracy and security of transaction verification. This dynamic adjustment ensures efficient consensus execution in different network environments.

[0076] The state synchronization layer is used to verify the consistency of cross-layer states.

[0077] For example, the state synchronization layer verifies the consistency of states across layers, including the storage layer, network layer, and application layer. By comparing key information such as data hash values ​​and state version numbers across each layer, if state inconsistencies are detected, data synchronization and repair mechanisms are triggered promptly to prevent transaction errors and system disruptions caused by state deviations.

[0078] Output layer, used to aggregate channel verification results.

[0079] For example, the output layer collects verification results from each verification channel, aggregates, verifies, and integrates them. Valid verification results are packaged into blocks, timestamped, and digitally signed. Ultimately, a consensus result is output that can be recognized by all network nodes, driving blockchain ledger updates.

[0080] Optionally, obtaining transaction data of computer data in the blockchain network further includes the following steps:

[0081] S1001, through a preset blockchain node scanning program, traverse and scan the nodes in the blockchain network, and identify smart contract code segments and database connection configuration information related to data storage as storage data.

[0082] For example, the transaction initiator's terminal uses a preset blockchain node scanner to traverse all nodes in the network. Using regular expression matching and abstract syntax tree (AST) analysis techniques, it identifies code segments in smart contracts related to data persistence, such as mapping and struct definitions in Solidity, and where the storage keyword is used. Furthermore, by parsing the node configuration file, it extracts database connection strings (such as MongoDB URIs or IPFS gateway addresses) and marks them as stored data. This stored data is then used to build a distributed data storage solution at the storage layer.

[0083] S1002, identifying a communication protocol code and a network interface definition for data transmission between nodes as transmission data.

[0084] For example, the transaction initiator's terminal uses a scanning program to analyze the underlying inter-node communication protocol, identify the configuration code of communication frameworks such as libp2p and gRPC, and extract information such as the protocol version, port number, and encryption transmission parameters (such as the TLS certificate path). At the same time, by parsing the network layer code, it obtains the node discovery mechanism (such as Kademlia DHT) and data sharding transmission logic to form transmission data, which is used to optimize data transmission paths and improve transmission efficiency at the network layer.

[0085] S1003, identifying the consensus algorithm code and signature verification logic used to verify the legitimacy of the transaction as verification data.

[0086] For example, the transaction initiator's terminal identifies the core logic of the consensus algorithm (such as PoS or PBFT) and extracts code snippets such as block generation rules, voting mechanisms, and Byzantine fault tolerance thresholds. Simultaneously, it analyzes the transaction signature verification logic, including the implementation details of elliptic curve cryptography (such as ECDSA) and the public key verification process, to form verification data. This verification data is then used to build a trusted transaction verification system at the consensus layer.

[0087] S1004: Identify the business processing code and status update logic used to execute the transaction logic as execution data.

[0088] For example, the transaction initiator's terminal analyzes the execution environment configuration of the smart contract virtual machine (such as EVM or Wasm) to extract the business logic processing code, including conditional judgments, state transition rules, and external call logic. Simultaneously, it identifies state update mechanisms, such as Ethereum's World State Tree update logic, and constructs execution data. This execution data is used to ensure the correct execution of transaction logic and maintain state consistency at the application layer.

[0089] Optionally, obtaining real-time transaction load from the blockchain network and updating the operating parameters of the layered architecture model to obtain a dynamically optimized parameter set includes the following steps:

[0090] S2001, monitor the number of transactions, data transmission volume and verification request volume in the blockchain network in real time to obtain monitoring results.

[0091] The transaction initiator's terminal deploys a monitoring program within the blockchain network nodes to continuously collect key data from the network. Specifically, the monitoring program counts the number of transactions within newly generated blocks every second, obtains the byte size of data transferred between nodes to determine data throughput, and records the number of transaction requests awaiting verification at the consensus layer. This data is aggregated and stored in a local database in real time. After data cleaning and format conversion, it ultimately generates structured monitoring results containing information such as timestamps, data types, and specific values, providing basic data support for subsequent analysis.

[0092] S2002, calculate the load indicators of the storage layer, network layer, consensus layer and application layer based on the monitoring results; the load indicators include storage load, transmission load, verification load and execution load.

[0093] For example, based on the monitoring results, the transaction initiator's terminal uses a specific calculation formula to evaluate the load at each layer. For the storage layer, the storage load is calculated by combining the frequency of database write operations and the remaining disk space. The network layer determines the transmission load based on bandwidth usage and the number of active connections. The consensus layer calculates the verification load by comparing the number of pending transactions with the processing power of the consensus nodes. The application layer determines the execution load based on the frequency of smart contract execution and virtual machine resource usage. These load indicators are presented as percentages, intuitively reflecting the current workload of each layer and providing a quantitative basis for parameter adjustment.

[0094] S2003: Based on the load indicators and the preset parameter update rules, the operating parameters of the storage layer, network layer, consensus layer, and application layer are updated to obtain a dynamically optimized parameter set.

[0095] For example, the transaction initiator's terminal matches the calculated load indicator with the preset parameter update rules. If the storage load is too high, the rules may trigger operations such as increasing the database cache size and optimizing the index structure. If the network load is too large, the parameters of the data transmission protocol will be adjusted and the node connection strategy will be optimized. If the verification load exceeds the standard, the consensus algorithm threshold will be modified and the verification node task allocation will be adjusted. If the execution load is too high, the resource allocation of the smart contract execution environment will be adjusted. Through a series of targeted parameter updates, a set of dynamically optimized parameters that adapt to the current network load conditions will be formed, achieving performance optimization of the layered architecture model.

[0096] Optionally, the method further includes the following steps:

[0097] For S3001, the storage load is obtained using the following formula:

[0098]

[0099] Among them, L storage is the storage load, K is the number of data blocks currently being stored, and D j is the data volume of the jth data block, S current The current storage capacity.

[0100] In the above storage load calculation formula, the numerator is the sum of the sizes of all data blocks being stored, and the denominator is the total storage capacity; among them, the storage load is used to calculate the storage pressure of the current storage layer, reflect the saturation of the storage system, and trigger expansion decisions; for example, if there are currently three data blocks (10MB, 20MB, 30MB) and the total storage capacity is 100MB, then the storage load is 60%.

[0101] S3002, the transmission load is obtained using the following formula:

[0102]

[0103] Among them, L transfer is the transmission load, L is the number of transactions being transmitted at the current moment, T k is the data volume of the kth transaction, B current The current transmission bandwidth.

[0104] In the above transmission load calculation formula, the numerator is the sum of all transaction data currently being transmitted, and the denominator is the total bandwidth. The transmission load is used to measure network pressure and guide dynamic bandwidth allocation. For example, if five transactions (each 2MB) are transmitted simultaneously and the total bandwidth is 20MB / s, the transmission load is 50%.

[0105] S3003, verification load is obtained using the following formula:

[0106]

[0107] Among them, L validation To verify the load, T window is the preset time window length, N validation In the preset time window T window The number of verification requests received within C i is the complexity factor of the i-th verification request.

[0108] In the above verification load calculation formula, the numerator is the weighted sum of the complexity of all verification requests within the time window, and the denominator is the time window. The verification load is used to assess the pressure on the consensus layer and dynamically adjust the verification strategy. For example, if 10 normal requests and 5 multi-signature requests are received within 10 seconds, the total verification load is 2.5.

[0109] S3004, the execution load is obtained using the following formula:

[0110]

[0111] Among them, L execution To execute the load, T window is the preset time window length, N execution In the preset time window T window The number of execution requests received within E j is the complexity factor of the j-th execution request.

[0112] In the above execution load calculation formula, the numerator is the weighted sum of the complexity of all execution requests within the time window, and the denominator is the time window. Among them, the execution load is used to calculate the application layer pressure and guide resource scheduling. For example, if 20 simple queries and 3 complex contracts are executed within 30 seconds, the total execution load is 1.17.

[0113] Optionally, the parameter update rule includes:

[0114] When the storage load is greater than the preset storage load threshold, the storage capacity is increased to γ ​​times the original storage capacity. storage times; where γ storage is the storage capacity adjustment factor.

[0115] For example, when the transaction initiator terminal detects that the storage load of the blockchain network (i.e., the ratio of the total amount of data blocks currently being stored to the total storage capacity) exceeds a preset threshold (e.g., 80%), the expansion process will be automatically triggered. The transaction initiator terminal first calculates the target capacity after expansion, i.e., the original storage capacity multiplied by the storage capacity adjustment coefficient γ storage(Usually 1.5). For example, if the current storage capacity is 100GB, the target capacity is 150GB. The terminal initiates a capacity expansion request by calling the cloud service provider's API and waits for the expansion to complete. Once the expansion is complete, the transaction initiator's terminal modifies the database configuration file, adjusting the parameters to match the new capacity. To ensure synchronized updates across all nodes in the network, the transaction initiator creates a special storage parameter update transaction and writes the new parameters to the blockchain via a smart contract. When other nodes synchronize this block, they each perform their own local capacity expansion operations, ultimately achieving network-wide consensus through the storage parameter version number in the block header.

[0116] When the transmission load is greater than the preset transmission load threshold, the transmission bandwidth is increased to γ ​​times the original transmission bandwidth. transfer times; where γ transfer is the transmission bandwidth adjustment factor.

[0117] For example, when the transaction initiator terminal detects that the network transmission load (i.e., the ratio of the current data transmission rate to the total bandwidth) exceeds a preset threshold (e.g., 70%), the transaction initiator terminal will immediately initiate the bandwidth upgrade process. The transaction initiator terminal dynamically adjusts the bandwidth allocation through a load balancer (e.g., NGINX or Alibaba Cloud SLB), multiplying the original bandwidth by the transmission bandwidth adjustment coefficient γ transfer (Usually 2). For example, if the current bandwidth is 100Mbps, it will be adjusted to 200Mbps. Simultaneously, the transaction initiator's terminal updates the network layer configuration to optimize node discovery efficiency. To avoid network jitter, a gradual adjustment strategy is adopted, increasing the bandwidth by 25% at a time until the demand is met. After the adjustment is complete, the transaction initiator's terminal broadcasts the new network parameters to the entire network via the Gossip protocol, ensuring that all nodes are synchronized within 3 seconds.

[0118] When the verification load is greater than the preset verification load threshold, the verification threshold is lowered to γ ​​times the original verification threshold. validation times; where γ validation Adjustment factor for validation threshold.

[0119] For example, when the transaction initiator terminal detects that the verification load (i.e., the number of complex verification requests per unit time) exceeds a preset threshold (e.g., 90%), the transaction initiator terminal will automatically reduce the verification difficulty to improve processing efficiency. Specifically, the transaction initiator terminal multiplies the original verification threshold (e.g., 67% of nodes need to reach consensus in the PBFT consensus algorithm) by the verification threshold adjustment coefficient γ validation(usually 0.8), resulting in a new threshold of 53.6%. The transaction initiator's terminal modifies the consensus layer configuration file, updates the parameters, and notifies other nodes via the consensus parameter version number in the block header. To prevent malicious exploitation, the transaction initiator's terminal sets a lower threshold (e.g., no less than 50%) and automatically restores the original threshold after the load decreases. This reduction in verification difficulty is achieved by reducing the number of signatures required, but all key operations still require confirmation from at least half of the nodes to ensure security.

[0120] When the execution load is greater than the preset execution load threshold, the execution delay threshold is increased to γ ​​times the original execution delay threshold. execution times, where γ execution Adjusts the execution delay threshold.

[0121] For example, when the transaction initiator terminal detects that the execution load exceeds a preset threshold (such as 85%), the system will extend the execution timeout limit to avoid frequent failures. The transaction initiator terminal multiplies the original execution delay threshold (such as 2 seconds) by the execution delay threshold adjustment coefficient γ execution (typically 1.2), resulting in a new threshold of 2.4 seconds. This adjustment is achieved by modifying parameters in the configuration file. At the same time, the transaction initiator's terminal will pre-allocate more computing resources for complex contracts (for example, increasing the virtual machine heap memory from 128MB to 256MB) and use a priority queue scheduling mechanism to ensure that high-value transactions receive more execution time. To prevent long-running transactions from clogging the queue, transaction sharding technology has been implemented, splitting complex calculations into multiple subtasks for parallel processing. When the execution load decreases, the transaction initiator's terminal will automatically restore the original delay threshold to ensure normal transaction response speed.

[0122] Optionally, based on the dynamic optimization parameter set, a distributed parameter update operation is performed to obtain a trading plan, including the following steps:

[0123] S4001, broadcast the dynamic optimization parameter set to each node of the blockchain network.

[0124] For example, the transaction initiator encapsulates the dynamic optimization parameter set as a special type of blockchain transaction and broadcasts it via the P2P network using the Gossip protocol. This parameter set includes adjustment parameters such as storage capacity, transmission bandwidth, and verification thresholds. It uses a Merkle tree structure to ensure integrity and node private key signatures to ensure the authenticity of the source. After receiving the parameter set, each node forwards it to a random subset of its connected nodes, ensuring that it is disseminated throughout the network within a certain time complexity. For example, in the Ethereum network, the parameter set is encoded in RLP format and sent through the corresponding interface. The transaction type field is marked as "PARAM_UPDATE", ensuring that all nodes in the network can quickly and reliably receive the latest optimization parameters.

[0125] S4002: Each node independently performs parameter update operations based on the received dynamic optimization parameter set to update the operating parameters of the local storage layer, network layer, consensus layer, and application layer.

[0126] For example, after receiving a parameter set, each node first verifies its integrity through a Merkle proof and compares the locally calculated parameter set hash value to ensure consistency with the broadcast. Subsequently, the parameters are updated independently according to a layered architecture: the storage layer calls the cloud storage API to dynamically expand disk capacity and adjust the database cache size; the network layer modifies the libp2p configuration and optimizes parameters; the consensus layer updates the PBFT algorithm's view change timeout parameters and gas price prediction model; and the application layer dynamically allocates Wasm virtual machine resources and optimizes contract execution queue scheduling. The entire update process utilizes a two-phase commit protocol, ensuring that all layer parameters are either successfully updated or rolled back to avoid inconsistent states.

[0127] S4003: Each node completes the data transaction based on the updated operating parameters and obtains a transaction plan.

[0128] For example, after the parameter update is complete, each node independently generates a transaction plan based on the new parameters. The network layer selects the optimal transmission path based on the optimized bandwidth parameters, the storage layer pre-allocates space at a certain proportion of the optimized capacity, the consensus layer adjusts transaction packaging priorities based on verification thresholds, and the application layer optimizes contract execution strategies to improve the efficiency of complex computations. These plans incorporate information such as transaction routing, resource allocation, and execution strategies, achieving network-wide consensus through consensus algorithms such as PBFT. For example, under high load, the transaction initiator's terminal may split a cross-chain transaction into multiple subtasks, assigning them to different nodes for parallel processing, and ultimately merging the results through state channels to achieve second-level confirmation, ensuring efficient transaction execution within the optimized network environment.

[0129] In this blockchain-based computer data transaction method, at the data acquisition level, data identification, storage, transmission, verification, and execution are implemented, laying the foundation for layered processing. The various layers of the hybrid consensus model work together to improve the efficiency of transaction channel processing and enhance attack resistance. Dynamic load monitoring and parameter tuning mechanisms enable the system to reduce disk usage and network bandwidth waste in terms of resource utilization. Performance-wise, they improve peak throughput and reduce transaction latency. Parameter update rules and distributed execution strategies enhance the system's adaptability. Operations such as automatic storage expansion and dynamic bandwidth adjustment reduce transaction failure rates and increase the success rate of complex contract execution.

[0130] It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the instructions of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the various embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0131] Based on the same inventive concept, the embodiments of the present application also provide a blockchain-based computer data transaction device for implementing the aforementioned blockchain-based computer data transaction method. The implementation solution provided by this device is similar to the implementation solution described in the aforementioned method. Therefore, the specific limitations of one or more blockchain-based computer data transaction device embodiments provided below can be found in the above-mentioned limitations of the blockchain-based computer data transaction method, and will not be repeated here.

[0132] In an exemplary embodiment, Figure 3 As shown, a computer data transaction device 300 based on blockchain is provided, comprising:

[0133] Data acquisition module 301, used to obtain transaction data of computer data in the blockchain network, transaction data includes storage data, transmission data, verification data and execution data;

[0134] A layered architecture model construction module 302 is configured to allocate storage data to the storage layer, transmission data to the network layer, verification data to the consensus layer, and execution data to the application layer, thereby obtaining a layered architecture model.

[0135] A dynamic optimization parameter module 303 is used to obtain real-time transaction load from the blockchain network and update the operating parameters of the layered architecture model to obtain a dynamic optimization parameter set;

[0136] The update operation module 304 is used to perform a distributed parameter update operation based on the dynamic optimization parameter set to obtain a trading plan.

[0137] Furthermore, the consensus layer includes a hybrid consensus model, which includes:

[0138] The input preprocessing layer receives raw transaction data, extracts transaction feature vectors, and assigns transactions to verification channels based on a dynamic clustering algorithm.

[0139] The weight calculation layer is used to calculate the dynamic weight of nodes through the hybrid PoS-FBFT mechanism and generate the verification node topology map;

[0140] Consensus execution layer, used to dynamically adjust consensus thresholds;

[0141] The state synchronization layer is used to verify the consistency of cross-layer states;

[0142] Output layer, used to aggregate channel verification results.

[0143] Furthermore, the data acquisition module 301 is further configured to:

[0144] Through the preset blockchain node scanning program, the nodes in the blockchain network are traversed and scanned to identify the smart contract code segments and database connection configuration information related to data storage as storage data;

[0145] identifying a communication protocol code and a network interface definition for data transmission between nodes as transmission data;

[0146] Identify the consensus algorithm code and signature verification logic used to verify the legitimacy of the transaction as verification data;

[0147] Business processing code and status update logic used to execute transaction logic are identified as execution data.

[0148] Furthermore, the dynamic optimization parameter module 303 includes:

[0149] The monitoring module is used to monitor the number of transactions, data transmission volume, and verification request volume in the blockchain network in real time and obtain monitoring results;

[0150] The load indicator calculation module is used to calculate the load indicators of the storage layer, network layer, consensus layer, and application layer based on the monitoring results; the load indicators include storage load, transmission load, verification load, and execution load;

[0151] The dynamic optimization parameter set module is used to update the operating parameters of the storage layer, network layer, consensus layer and application layer according to the load indicators and the preset parameter update rules to obtain a dynamic optimization parameter set.

[0152] Furthermore, the load index calculation module is also used to:

[0153] The storage load is obtained using the following formula:

[0154]

[0155] Among them, L storage is the storage load, K is the number of data blocks currently being stored, and D jis the data volume of the jth data block, S current is the current storage capacity;

[0156] The transmission load is obtained using the following formula:

[0157]

[0158] Among them, L transfer is the transmission load, L is the number of transactions being transmitted at the current moment, T k is the data volume of the kth transaction, B current is the current transmission bandwidth;

[0159] The validation load is obtained using the following formula:

[0160]

[0161] Among them, L validation To verify the load, T window is the preset time window length, N validation In the preset time window T window The number of verification requests received within C i is the complexity factor of the i-th verification request;

[0162] The execution load is obtained using the following formula:

[0163]

[0164] Among them, L execution To execute the load, T window is the preset time window length, N execution In the preset time window T window The number of execution requests received within E j is the complexity factor of the j-th execution request.

[0165] Furthermore, the dynamic optimization parameter set module 303 is further configured to:

[0166] When the storage load is greater than the preset storage load threshold, the storage capacity is increased to γ ​​times the original storage capacity. storage times; where γ storage is the storage capacity adjustment factor;

[0167] When the transmission load is greater than the preset transmission load threshold, the transmission bandwidth is increased to γ ​​times the original transmission bandwidth. transfer times; where γ transfer is the transmission bandwidth adjustment coefficient;

[0168] When the verification load is greater than the preset verification load threshold, the verification threshold is lowered to γ ​​times the original verification threshold. validationtimes; where γ validation To verify the threshold adjustment coefficient;

[0169] When the execution load is greater than the preset execution load threshold, the execution delay threshold is increased to γ ​​times the original execution delay threshold. execution times, where γ execution Adjusts the execution delay threshold.

[0170] Furthermore, the update operation module 304 is further configured to:

[0171] Broadcast the dynamically optimized parameter set to each node of the blockchain network;

[0172] Each node independently performs parameter update operations based on the received dynamic optimization parameter set, updating the operating parameters of the local storage layer, network layer, consensus layer, and application layer;

[0173] Each node completes the data transaction based on the updated operating parameters and obtains the transaction plan.

[0174] In one embodiment, Figure 4 A computer device 400 is provided, comprising:

[0175] at least one processor 401;

[0176] and a memory 402 communicatively connected to at least one of the processors 401;

[0177] The memory stores application code that can be executed by at least one of the processors. The application code is executed by at least one of the processors to enable at least one of the processors to perform the steps of the blockchain-based computer data transaction method as described above.

[0178] The computer device may further include a transceiver 403 .

[0179] The processor 401, the memory 402 and the transceiver 403 may be connected via a bus 404 or other means. In the figure, the bus 404 is used as an example. Figure 4 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0180] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0181] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely illustrative, wherein the components described as separate parts may or may not be physically separated, and the parts displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the disclosed solution. A person of ordinary skill in the art can understand and implement it without expending creative work.

[0182] The above-described embodiments merely represent several implementation methods of the embodiments of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that a person skilled in the art may make various modifications and improvements without departing from the concept of the embodiments of the present application, and these modifications and improvements fall within the scope of protection of the embodiments of the present application.

Claims

1. A computer data transaction method based on blockchain, characterized in that: The method comprises: Obtaining transaction data of computer data in a blockchain network; the transaction data includes storage data, transmission data, verification data, and execution data; Allocating the stored data to the storage layer, allocating the transmitted data to the network layer, allocating the verification data to the consensus layer, and allocating the execution data to the application layer to obtain a layered architecture model; Obtaining real-time transaction load from the blockchain network and updating operating parameters of the layered architecture model to obtain a dynamically optimized parameter set; Based on the dynamic optimization parameter set, a parameter update operation is executed in a distributed manner to obtain a trading plan.

2. The method according to claim 1, characterized in that The consensus layer includes a hybrid consensus model, which includes: The input preprocessing layer receives raw transaction data, extracts transaction feature vectors, and assigns transactions to verification channels based on a dynamic clustering algorithm. The weight calculation layer is used to calculate the dynamic weight of nodes through the hybrid PoS-FBFT mechanism and generate the verification node topology map; Consensus execution layer, used to dynamically adjust consensus thresholds; The state synchronization layer is used to verify the consistency of cross-layer states; Output layer, used to aggregate channel verification results.

3. The method according to claim 1, characterized in that The obtaining of transaction data of computer data in the blockchain network includes: Through the preset blockchain node scanning program, the nodes in the blockchain network are traversed and scanned to identify the smart contract code segments and database connection configuration information related to data storage as storage data; the communication protocol code and network interface definition used for data transmission between nodes are identified as transmission data; the consensus algorithm code and signature verification logic used to verify the legitimacy of the transaction are identified as verification data; the business processing code and status update logic used to execute the transaction logic are identified as execution data.

4. The method according to claim 1, wherein The method of obtaining the real-time transaction load from the blockchain network and updating the operating parameters of the layered architecture model to obtain a dynamically optimized parameter set includes: Monitor the number of transactions, data transmission volume, and verification request volume in the blockchain network in real time and obtain monitoring results; Calculate the load indicators of the storage layer, network layer, consensus layer and application layer based on the monitoring results; the load indicators include storage load, transmission load, verification load and execution load; According to the load index, the operating parameters of the storage layer, network layer, consensus layer and application layer are updated according to the preset parameter update rules to obtain a dynamically optimized parameter set.

5. The method according to claim 4, characterized in that , The storage load is obtained using the following formula: Among them, L storage is the storage load, K is the number of data blocks currently being stored, and D j is the data volume of the jth data block, S current is the current storage capacity; The transmission load is obtained using the following formula: Among them, L transfer is the transmission load, L is the number of transactions being transmitted at the current moment, T k is the data volume of the kth transaction, B current is the current transmission bandwidth; The verification load is obtained using the following formula: Among them, L validation To verify the load, T window is the preset time window length, N validation In the preset time window T window The number of verification requests received within C i is the complexity factor of the i-th verification request; The execution load is obtained using the following formula: Among them, L execution To execute the load, T window is the preset time window length, N execution In the preset time window T window The number of execution requests received within E j is the complexity factor of the j-th execution request.

6. The method according to claim 4, characterized in that The parameter update rules include: When the storage load is greater than the preset storage load threshold, the storage capacity is increased to γ ​​times the original storage capacity. storage times; where γ storage is the storage capacity adjustment factor; When the transmission load is greater than the preset transmission load threshold, the transmission bandwidth is increased to γ ​​times the original transmission bandwidth. transfer times; where γ transfer is the transmission bandwidth adjustment coefficient; When the verification load is greater than the preset verification load threshold, the verification threshold is lowered to γ ​​times the original verification threshold. validation times; where γ validation To verify the threshold adjustment coefficient; When the execution load is greater than the preset execution load threshold, the execution delay threshold is increased to γ ​​times the original execution delay threshold. execution times, where γ execution Adjusts the execution delay threshold.

7. The method according to claim 1, characterized in that The distributed execution of parameter update operations based on the dynamic optimization parameter set to obtain a transaction plan includes: Broadcasting the dynamic optimization parameter set to each node of the blockchain network; Each node independently performs parameter update operations based on the received dynamic optimization parameter set, updating the operating parameters of the local storage layer, network layer, consensus layer, and application layer; Each node completes the data transaction based on the updated operating parameters and obtains the transaction plan.

8. A computer data transaction device based on blockchain, characterized in that: The device comprises: A data acquisition module is used to acquire transaction data of computer data in the blockchain network, wherein the transaction data includes storage data, transmission data, verification data, and execution data; A layered architecture model construction module is used to allocate the storage data to the storage layer, allocate the transmission data to the network layer, allocate the verification data to the consensus layer, and allocate the execution data to the application layer to obtain a layered architecture model; A dynamic optimization parameter module, configured to obtain real-time transaction load from the blockchain network and update the operating parameters of the layered architecture model to obtain a dynamic optimization parameter set; The update operation module is used to perform a distributed parameter update operation based on the dynamic optimization parameter set to obtain a trading plan.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images