Consensus parameter adjustment method, apparatus, device, medium, and program product

Abstract

Embodiments of the present application provide a consensus parameter adjustment method, device, equipment, medium and program product. The method comprises: obtaining transaction feature data of a transaction in a blockchain network; dynamically adjusting a consensus mechanism parameter of the blockchain network based on the transaction feature data to obtain an adjusted consensus mechanism parameter; and running a consensus process of the blockchain network based on the adjusted consensus mechanism parameter. The method is used to improve the efficiency of the blockchain consensus mechanism.

Description

Technical Field

[0001] This application relates to the field of blockchain, and in particular to a consensus parameter adjustment method, apparatus, device, medium, and program product. Background Technology

[0002] In financial transaction scenarios, blockchain needs to handle high-frequency low-value transactions (such as small payments) and low-frequency high-value transactions (such as cross-border transfers).

[0003] In existing technologies, blockchain consensus mechanisms can be categorized into public blockchain and consortium blockchain scenarios. Public blockchains, represented by Proof of Work (PoW) and Proof of Stake (PoS), rely on computing power or staked resources to allocate consensus rights. Consortium blockchains primarily use Practical Byzantine Fault Tolerance (PBFT) and Reliable, Available, and Fault-Tolerant (RAFT) protocols, relying on a pre-defined set of nodes to achieve consensus. These methods suffer from rigid consensus mechanisms, failing to detect changes in transaction characteristics (such as low-value transactions consuming high computing power), leading to resource waste.

[0004] Therefore, improving the efficiency of blockchain consensus mechanisms is an urgent problem to be solved. Summary of the Invention

[0005] This application provides a consensus parameter adjustment method, apparatus, device, medium, and program product to improve the efficiency of blockchain consensus mechanisms.

[0006] In a first aspect, embodiments of this application provide a consensus parameter adjustment method, the method comprising:

[0007] Obtain transaction characteristic data of transactions conducted in the blockchain network;

[0008] Based on the transaction feature data, the consensus mechanism parameters of the blockchain network are dynamically adjusted to obtain the adjusted consensus mechanism parameters.

[0009] The consensus process of the blockchain network is run based on the adjusted consensus mechanism parameters.

[0010] In one possible implementation, dynamically adjusting the consensus mechanism parameters of the blockchain network based on the transaction feature data to obtain the adjusted consensus mechanism parameters includes:

[0011] Extract the transaction risk score, transaction value density, and transaction load type from the transaction feature data;

[0012] The transaction risk score, the transaction value density, and the transaction load type are input into a preset consensus parameter dynamic decision-maker to obtain the adjusted consensus mechanism parameters.

[0013] In one possible implementation, the consensus parameter dynamic decision maker is configured to perform at least one of the following steps:

[0014] When the transaction risk score is greater than or equal to a preset score threshold, the adjusted consensus mechanism parameters are used to characterize the activation of the hybrid consensus mechanism;

[0015] When the transaction value density is greater than or equal to a preset value density threshold, the adjusted consensus mechanism parameters include: the consensus algorithm after type switching;

[0016] When the transaction load type is a preset target type, the adjusted consensus mechanism parameters include: the adjusted block size.

[0017] In one possible implementation, extracting the transaction risk score from the transaction feature data includes:

[0018] Based on the graph network model, identify the MEV attack behavior features with the maximum extractable value in the transaction feature data;

[0019] Based on a time series model, the fluctuation characteristics of transaction fee data in the transaction feature data are detected;

[0020] Based on the anomaly detection model, abnormal transaction behavior features are identified in the transaction feature data;

[0021] The transaction risk score is obtained based on the characteristics of the MEV attack behavior, the fluctuation characteristics of the transaction data, and the characteristics of the abnormal transaction behavior.

[0022] In one possible implementation, the consensus process includes multiple consensus verification nodes, and before running the consensus process of the blockchain network based on the adjusted consensus mechanism parameters, the method further includes:

[0023] Based on the historical verification accuracy rate, abnormal transaction detection rate, and network response latency of the consensus verification node, the participation weight of the consensus verification node in the consensus process is determined.

[0024] The consensus process of running the blockchain network based on the adjusted consensus mechanism parameters includes:

[0025] Based on the adjusted consensus mechanism parameters and the weights of the participants in the consensus process, the consensus process of the blockchain network is executed.

[0026] In one possible implementation, the method is applied to a blockchain system, wherein acquiring transaction characteristic data of transactions conducted in the blockchain network includes:

[0027] The transaction feature data is extracted using a lightweight data feature extraction model deployed in the edge nodes of the blockchain system.

[0028] In one possible implementation, after running the consensus process of the blockchain network based on the adjusted consensus mechanism parameters, the method further includes:

[0029] Based on the historical consensus mechanism parameter change trend of the blockchain network, the consensus mechanism parameters at the future target time are predicted.

[0030] At the target future time, the consensus process of the blockchain network is executed based on the consensus mechanism parameters at the target future time.

[0031] In one possible implementation, the consensus mechanism parameters include at least one of the following: consensus algorithm type, number of block-producing nodes, block size, transaction verification depth, and transaction confirmation time.

[0032] Secondly, embodiments of this application provide a consensus parameter adjustment device, comprising:

[0033] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0034] The memory stores computer-executed instructions;

[0035] The processor executes computer execution instructions stored in the memory, causing the processor to perform the method described in any of the first aspects above.

[0036] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in any of the first aspects above.

[0037] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the first aspects above.

[0038] This application provides a consensus parameter adjustment method, apparatus, device, medium, and program product. By acquiring blockchain network transaction characteristic data, it dynamically adjusts consensus mechanism parameters and runs the consensus process, enabling real-time adaptation of the consensus mechanism to transaction characteristics. Compared to traditional blockchain consensus mechanisms that use static parameter configuration and cannot distinguish the resource requirements of high-frequency, low-value transactions versus low-frequency, high-value transactions, this application optimizes resource allocation efficiency and reduces computing power waste by driving parameter adjustment through transaction characteristic data. Attached Figure Description

[0039] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0040] Figure 1 A flowchart illustrating a consensus parameter adjustment method provided in an embodiment of this application;

[0041] Figure 2 A schematic diagram illustrating a process for extracting transaction risk scores, provided as an embodiment of this application;

[0042] Figure 3 A schematic diagram of a dynamic consensus engine provided in an embodiment of this application;

[0043] Figure 4 A schematic diagram of an AI feature analysis engine provided in an embodiment of this application;

[0044] Figure 5 A schematic diagram of a consensus parameter adjustment device provided in this application;

[0045] Figure 6 This is a schematic diagram of the structure of an electronic device provided in this application.

[0046] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0047] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0048] In this application, the term "comprising" and its variations can refer to non-limiting inclusion; the term "or" and its variations can refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0049] In financial transaction scenarios, blockchain technology is gradually permeating various business processes, becoming an important force driving financial innovation and efficiency improvement. However, financial transactions themselves are diverse and complex, and different types of transactions have vastly different performance requirements for blockchain systems.

[0050] Specifically, blockchain needs to efficiently process two main types of transactions: one is high-frequency, low-value transactions, typically represented by small payments and daily consumer settlements. These transactions occur extremely frequently, with relatively small individual transaction amounts, but they have extremely high requirements for real-time performance and throughput. The blockchain system needs to be able to process a large number of transaction requests in a short period of time to ensure a smooth user experience.

[0051] Another type is low-frequency, high-value transactions, such as cross-border transfers and large-value asset transactions. Although these transactions occur less frequently, the amount of each transaction is huge, and the requirements for security and consistency are extremely high. The blockchain system needs to provide a strict verification mechanism and tamper-proof transaction records to ensure the safety of funds for both parties in the transaction.

[0052] However, existing blockchain consensus mechanisms often struggle to adapt flexibly to these two types of transactions, leading to unreasonable resource allocation and impacting overall transaction efficiency and cost-effectiveness.

[0053] Within the existing technological framework, blockchain consensus mechanisms are mainly divided into two categories: public blockchains and consortium blockchains. In public blockchains, Proof of Work (PoW) and Proof of Stake (PoS) are two of the most representative consensus mechanisms. The PoW mechanism requires nodes to solve complex mathematical problems to compete for the right to record transactions, relying on computing power to allocate consensus rights. While this ensures the decentralization and security of the system, its high energy consumption and low efficiency are becoming increasingly prominent, especially when processing high-frequency, low-value transactions, where the waste of computing power is particularly severe.

[0054] The Proof-of-Stake (PoS) mechanism allocates the right to record transactions based on the number of tokens held by nodes and the duration of their holdings, which reduces energy consumption. However, it may lead to a "rich get richer" phenomenon and still lacks the ability to dynamically adjust for low-value transactions.

[0055] In consortium blockchain scenarios, Practical Byzantine Fault Tolerance (PBFT) and Reliable, Available, and Fault-Tolerant (RAFT) protocols have become mainstream. PBFT ensures system consistency and fault tolerance through multiple rounds of voting and state synchronization, but it has high communication overhead, a limited number of nodes, and is difficult to adapt to large-scale, high-frequency transaction scenarios.

[0056] The RAFT protocol simplifies the consensus process by electing a leader, which improves efficiency, but it also suffers from the problem of the leader becoming a single point of bottleneck and lacks the ability to perceive changes in transaction characteristics.

[0057] In summary, existing blockchain consensus mechanisms suffer from problems such as rigidity and inability to detect changes in transaction characteristics when dealing with the diverse needs of financial transaction scenarios, leading to unreasonable resource allocation. There is an urgent need for a more flexible and efficient consensus mechanism to optimize resource utilization and improve transaction efficiency.

[0058] Therefore, this application embodiment, by acquiring blockchain network transaction characteristic data, dynamically adjusting consensus mechanism parameters, and running the consensus process, can achieve real-time adaptation of the consensus mechanism to transaction characteristics. Compared to traditional blockchain consensus mechanisms that use static parameter configuration and cannot distinguish the resource requirements of high-frequency, low-value transactions versus low-frequency, high-value transactions, this application embodiment optimizes resource allocation efficiency and reduces computing power waste by driving parameter adjustments through transaction characteristic data.

[0059] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0060] It should be noted that the executing entity of this application can be any electronic device with processing capabilities, such as a user terminal or a server, for example, a computer.

[0061] Figure 1 This is a flowchart illustrating a consensus parameter adjustment method provided in an embodiment of this application. Figure 1 As shown, the method includes:

[0062] S101. Obtain transaction characteristic data of transactions conducted in the blockchain network.

[0063] Optionally, the blockchain network can be a decentralized network composed of multiple nodes, maintaining the consistency of the transaction ledger through a consensus mechanism. Transaction characteristic data can be any one or more of the key indicators describing transaction attributes, such as transaction frequency (number of transactions per unit of time), transaction amount (value of a single transaction), transaction type (small payment / cross-border transfer), and address characteristics of the initiator and recipient.

[0064] Alternatively, electronic devices can capture transaction data in real time through the monitoring module built into the blockchain node, or pull transaction records from full nodes / light nodes through the Application Programming Interface (API).

[0065] Optionally, electronic devices can clean and feature-engineer the raw transaction data, such as counting the number of transactions (frequency) within a unit time window, calculating the median / variance of transaction amounts (value distribution), and identifying the proportion of high-frequency low-value transactions (such as small payments) and low-frequency high-value transactions (such as cross-border transfers), thereby obtaining transaction characteristic data for transactions conducted in the blockchain network.

[0066] In one implementation, when applied to a blockchain system, the electronic device can extract transaction feature data through a lightweight data feature extraction model deployed in the edge nodes of the blockchain system.

[0067] Optionally, edge nodes can be lightweight computing nodes located at the edge of the blockchain network. They can be deployed close to the data source (such as terminal devices) to undertake some data processing tasks and reduce the load on the core chain. The lightweight data feature extraction model can be a machine learning or statistical model designed based on the edge nodes to efficiently extract key features from the raw transaction data.

[0068] Optionally, edge nodes can obtain raw transaction data by communicating with a blockchain light client or directly with a full node. A lightweight data feature extraction model can clean the raw transaction data and extract the transaction feature data.

[0069] This application embodiment extracts transaction feature data through a lightweight edge node model. Compared with the prior art, which requires full node synchronization of original transaction data, the lightweight edge node model can reduce the load pressure of data collection on the core chain by compressing features.

[0070] S102. Based on transaction feature data, dynamically adjust the consensus mechanism parameters of the blockchain network to obtain the adjusted consensus mechanism parameters.

[0071] Optionally, the consensus mechanism parameters can be core variables that control the operation of the consensus algorithm, and can include any one or more of the above-mentioned PoW, PoS, PBFT, RAFT, etc.

[0072] Optionally, electronic devices can dynamically adjust the consensus mechanism parameters of the blockchain network according to preset rules; for example, parameters can be automatically modified according to preset rules.

[0073] Electronic devices can also dynamically adjust the consensus mechanism parameters of a blockchain network through machine learning. For example, they can train a predictive model using historical transaction feature data to dynamically predict future transaction features and adjust the parameters in advance.

[0074] Electronic devices can also respond to changes in transaction characteristics through on-chain smart contracts. For example, when a surge in small payment transactions is detected, a "lightweight consensus mode" is automatically triggered to achieve on-chain autonomous adjustment of parameters.

[0075] In one implementation, consensus mechanism parameters may include one or more of the following: consensus algorithm type, number of block-producing nodes, block size, transaction verification depth, and transaction confirmation time. The consensus algorithm type can be a set of core rules in the blockchain network used to ensure that all nodes reach a consensus on the ledger state; it determines how nodes collaborate to generate new blocks and verify the validity of transactions. For example, the consensus algorithm type may include one or more of PoW, PoS, etc.

[0076] The number of block-producing nodes refers to the number of nodes that actually participate in block creation within a single consensus cycle (such as the time window for generating a block). The number of block-producing nodes directly affects the degree of decentralization and efficiency of the blockchain: the more block-producing nodes there are, the higher the degree of decentralization of the system (because more nodes have the right to generate blocks), but the consensus-reaching speed may be slower (it is necessary to coordinate the opinions of more nodes); conversely, the fewer block-producing nodes there are, the higher the consensus efficiency, but decentralization may be sacrificed (power is concentrated in a few nodes).

[0077] Block size is the maximum amount of data that a single block can hold, and it directly limits the throughput of the blockchain. The larger the block, the more transactions can be packaged in a single block, and the higher the system throughput.

[0078] Transaction verification depth can be defined as the number of historical blocks or the length of the transaction chain that a blockchain node needs to trace when confirming a transaction. It is used to ensure that the validity of a transaction has not been tampered with by subsequent blocks. The deeper the transaction verification depth, the more historical data the node needs to check, making it more difficult for the transaction to be reversed, but the verification process takes longer. Conversely, the shallower the verification depth, the faster the transaction confirmation speed, but security may be reduced.

[0079] Transaction confirmation time can be the time required from the initiation of a transaction to its recognition as "irreversible" by the blockchain network. Transaction confirmation time can be determined by factors such as consensus mechanism, network latency, block generation interval (e.g., Bitcoin 10 minutes / block) and verification depth.

[0080] This application embodiment defines specific types of consensus mechanism parameters, including consensus algorithm type, number of block-producing nodes, block size, transaction verification depth, and transaction confirmation time, which can provide fine-grained adjustment dimensions and improve the flexibility of consensus mechanism parameters.

[0081] S103. Based on the adjusted consensus mechanism parameters, run the consensus process of the blockchain network.

[0082] Alternatively, the consensus process can be the core process by which blockchain nodes achieve ledger consistency through collaboration. Electronic devices can first read adjusted parameters from a configuration center or on-chain storage, and then execute consensus logic based on the new parameters to run the consensus process of the blockchain network.

[0083] In one implementation, the consensus process includes multiple consensus verification nodes. Before running the consensus process of the blockchain network based on the adjusted consensus mechanism parameters, the electronic device can first determine the consensus verification node's participation weight in the consensus process based on the node's historical verification accuracy, abnormal transaction detection rate, and network response latency. Then, based on the adjusted consensus mechanism parameters and the consensus process participation weights, the blockchain network's consensus process is run.

[0084] Optionally, a consensus validator node can be a node participating in the consensus process, responsible for validating transactions, packaging blocks, or voting to confirm the validity of blocks. The historical verification accuracy of a consensus validator node can be the proportion of transactions or blocks correctly verified in past consensus processes. The abnormal transaction detection rate can be the ability of a consensus validator node to detect abnormal transactions, typically measured as the ratio of detected abnormal transactions to the total number of actual abnormal transactions. Network response latency can be the time required for a node to process consensus requests (such as receiving transactions or broadcasting blocks).

[0085] Optionally, the participation weight of a verification node in the consensus process can be a dynamically allocated weight value based on the historical verification accuracy, abnormal transaction detection rate, and network response latency of the consensus verification node. This weight determines the node's voice in the consensus process; the higher the weight, the greater the node's influence on the consensus result.

[0086] Optionally, the electronic device can determine the participation weight of consensus verification nodes in the consensus process based on a preset weight allocation model or machine learning model. The electronic device can then run the consensus process of the blockchain network according to the adjusted consensus mechanism parameters and the participation weights in the consensus process. For example, nodes with higher weights verify more transactions.

[0087] This application's embodiments introduce a consensus verification node participation weighting mechanism, allocating weights based on historical verification accuracy, abnormal transaction detection rate, and network response latency, which can optimize the reliability of the consensus process.

[0088] This application embodiment achieves real-time adaptation of the consensus mechanism to transaction characteristics by acquiring blockchain network transaction feature data, dynamically adjusting consensus mechanism parameters, and running the consensus process. Compared to traditional blockchain consensus mechanisms that use static parameter configuration and cannot distinguish the resource requirements of high-frequency, low-value transactions versus low-frequency, high-value transactions, this application embodiment optimizes resource allocation efficiency and reduces computational waste by driving parameter adjustments based on transaction feature data.

[0089] The following section provides a detailed explanation of how electronic devices can dynamically adjust the consensus mechanism parameters of a blockchain network based on transaction characteristic data to obtain the adjusted consensus mechanism parameters.

[0090] Electronic devices can first extract transaction risk scores, transaction value densities, and transaction load types from transaction feature data, and then input the transaction risk scores, transaction value densities, and transaction load types into a preset consensus parameter dynamic decision-maker to obtain adjusted consensus mechanism parameters.

[0091] Optionally, the transaction risk score can be calculated using a machine learning model or rule engine to characterize the risk score of a transaction. Transaction value density can be the economic value carried by a unit of transaction data, used to measure the efficiency of a transaction in utilizing system resources. Transaction load type can be a classification of the resource requirements of the blockchain network or underlying system (such as compute-intensive, storage-intensive, network bandwidth-intensive). For example, smart contract calls may be compute-intensive, while large file storage is storage-intensive.

[0092] The consensus parameter dynamic decision-maker can be an algorithm- or rule-based logical module that generates optimal consensus mechanism parameters in real time based on the input transaction feature data. Optionally, the consensus parameter dynamic decision-maker can employ one or more methods such as rule engines, machine learning models, and optimization algorithms.

[0093] Optionally, electronic devices can capture raw data from transaction data sources (such as blockchain nodes, transaction databases, or external risk control systems) through data acquisition modules (such as API interfaces, log parsers, or sensors), and then extract transaction risk scores, transaction value density, and transaction load types through feature engineering.

[0094] Optionally, the electronic device can transmit the extracted transaction feature data in a structured format to the input interface of the consensus parameter dynamic decision-maker. The consensus parameter dynamic decision-maker runs preset logic (rule engine, machine learning model, or optimization algorithm) based on the input data to generate adjusted consensus mechanism parameters.

[0095] The embodiments of this application can refine the dynamic adjustment process. By extracting transaction risk scores, value density, and load type, and inputting them into the consensus parameter dynamic decision-maker to generate adjustment parameters, a quantitative mapping relationship between transaction characteristics and consensus parameters is constructed, enabling the consensus mechanism to accurately match transaction characteristics and avoid the limitations of adjusting a single parameter.

[0096] Taking the consensus parameter dynamic decision-maker as an example, which runs the rule engine based on the input data to generate adjusted consensus mechanism parameters, this paper explains how the consensus parameter dynamic decision-maker obtains the adjusted consensus mechanism parameters.

[0097] The consensus parameter dynamic decision maker can adjust the consensus mechanism parameters to characterize the activation of the hybrid consensus mechanism when the transaction risk score is greater than or equal to a preset score threshold.

[0098] Optionally, the preset scoring threshold can be pre-stored in the consensus parameter dynamic decision-maker. A hybrid consensus mechanism can be a composite consensus scheme combining the advantages of multiple consensus algorithms. It can improve the flexibility of the consensus parameter dynamic decision-maker by dynamically switching or running different algorithms in parallel (such as PoW+PoS, PBFT+PoS). For example, in high-risk scenarios, the hybrid mechanism may simultaneously enable PoW (tamper-proof) and PoS (fast verification) to balance security and efficiency.

[0099] The consensus parameter dynamic decision maker can adjust the consensus mechanism parameters when the transaction value density is greater than or equal to the preset value density threshold. The adjusted parameters include the consensus algorithm after type switching.

[0100] Optionally, the preset value density threshold can be pre-stored in the consensus parameter dynamic decision maker. For example, high value density transactions (such as large transfers) require more stringent verification (such as increasing the block size to accommodate more signatures), while low value density transactions (such as small micropayments) can optimize storage and processing efficiency, such as switching from resource-intensive PoW to lightweight PoS.

[0101] The consensus parameter dynamic decision maker can adjust the consensus mechanism parameters, including the adjusted block size, when the transaction load type is a preset target type.

[0102] Optionally, the preset target type can be the type of load that the consensus parameter dynamic decision-maker expects to prioritize (such as compute-intensive). When the transaction load type matches this, the block size is adjusted (such as increasing the block size to accommodate more computational tasks) or the allocation of node resources is optimized. For example, the preset target type can also be high load, which is a state in the blockchain network where the demand for system resources by transactions exceeds a preset threshold.

[0103] This application embodiment defines specific rules for the consensus parameter dynamic decision-maker, including risk scoring triggering hybrid consensus, value density triggering algorithm switching, and load type triggering block size adjustment, which can achieve scenario-based adaptation of the consensus mechanism.

[0104] The following provides a detailed explanation of how electronic devices extract transaction risk scores from transaction feature data. Figure 2 This application provides a schematic diagram of a process for extracting transaction risk scores, as illustrated in the embodiments of this application. Figure 2 As shown, the process may include:

[0105] S201. Based on the graph network model, identify the maximum extractable value (MEV) attack behavior characteristics in transaction feature data.

[0106] Alternatively, the graph network model can be a data analysis model based on graph structure (nodes and edges), which constructs a transaction network through nodes (representing entities, such as transactions, accounts, and contracts) and edges (representing relationships, such as fund flows and call relationships) to uncover hidden association patterns.

[0107] MEV attacks refer to the actions of attackers who manipulate the order of blockchain transactions or insert malicious transactions to gain additional economic benefits from user transactions. Characteristics of MEV attacks can be described by typical patterns or indicators, such as high-frequency trading, dependence on specific transaction orders, abnormal fee bidding, and clustering of related accounts, among others.

[0108] Optionally, electronic devices can first extract transaction feature data from blockchain data sources (such as node logs and transaction pools), then construct a transaction graph, using transactions as nodes and fund flows or call relationships as edges to form a directed graph or multi-layer graph, and then train a graph network model to classify the graph and identify subgraphs or node clusters related to MEV attacks.

[0109] S202. Based on the time series model, detect the fluctuation characteristics of transaction fee data in transaction feature data.

[0110] Optionally, time series models can be used to analyze data arranged in chronological order (such as transaction fees over time) to capture trends, seasonality, periodicity, or anomalous fluctuations. Transaction fee data can be fee data generated during the transaction process, and the fluctuation characteristics of transaction fee data can be any one or more of the statistical properties describing the changes in transaction fee data over time, such as volatility (standard deviation), peaks, troughs, periodicity (such as daily peaks), and abrupt changes (such as sudden increases in fees). For example, the fluctuation characteristic of transaction fee data can be Gas (the fee that users pay to execute transactions or smart contracts).

[0111] Optionally, electronic devices can extract transaction fee data from blockchain data sources, sort it by timestamp to form a time series, and input it into a time series model to detect the fluctuation characteristics of transaction fee data in the transaction feature data.

[0112] S203. Based on the anomaly detection model, identify abnormal transaction behavior features in transaction feature data.

[0113] Optionally, the anomaly detection model can be a machine learning or statistical model used to identify data points (outliers) that deviate significantly from the normal pattern. Abnormal trading behavior characteristics can be behaviors that do not conform to normal trading patterns, such as abnormal amounts, abnormal frequency, abnormal counterparties, etc., any one or more of these. Abnormal trading behavior characteristics can also be quantitative indicators describing abnormal transactions, such as the degree to which the transaction amount deviates from the mean, the transaction time outside of working hours, clusters of related accounts, etc., any one or more of these.

[0114] Optionally, the electronic device can input transaction feature data into the anomaly detection model, which extracts multi-dimensional features from the transaction feature data and identifies abnormal transaction behavior features in the transaction feature data based on its own algorithm.

[0115] S204. Based on the characteristics of MEV attack behavior, the fluctuation characteristics of transaction data, and the characteristics of abnormal transaction behavior, a transaction risk score is obtained.

[0116] Optionally, the electronic device can normalize the characteristics of MEV attack behavior, the fluctuation characteristics of transaction data, and the characteristics of abnormal transaction behavior, assign weights according to business priorities, and then obtain a transaction risk score based on weighted summation.

[0117] This application proposes a method for extracting transaction risk scores. It uses a graph network model to identify MEV attack characteristics, a time series model to detect transaction fee fluctuations, and an anomaly detection model to identify abnormal behavior. By comprehensively generating a risk score, a multi-dimensional risk assessment system is constructed, providing a reliable basis for adjusting consensus parameters and reducing consensus interruptions caused by misjudgments.

[0118] After running the consensus process of the blockchain network based on the adjusted consensus mechanism parameters, the embodiments of this application can first predict the consensus mechanism parameters at a future target time based on the historical trend of consensus mechanism parameter changes in the blockchain network. Secondly, at the future target time, the consensus process of the blockchain network is run based on the consensus mechanism parameters at that future target time.

[0119] Optionally, the historical consensus mechanism parameter change trend of the blockchain network can be the law of change of historical consensus mechanism parameters over time, such as any one or more of the following: linear growth / decline, periodic fluctuations, and sudden events. The future target time can be a specific point in time that is predicted or planned.

[0120] Optionally, the electronic device can extract historical parameter change records from blockchain explorers, node logs, or monitoring systems, analyze the historical consensus mechanism parameter change trends based on one or more of the following models: time series model or causal inference model, and predict the consensus mechanism parameters at a future target time. Based on the consensus mechanism parameters at the future target time, the consensus process of running the blockchain network is similar to S103 above, and will not be repeated here.

[0121] This application's embodiments predict future parameters based on historical parameter change trends and run at the target time, enabling advance optimization of the consensus mechanism. Compared to traditional parameter adjustments that passively respond and are prone to short-term performance fluctuations, this application's embodiments can adapt to the cyclical fluctuations in financial trading scenarios.

[0122] For example, the Dynamic Consensus Engine (DCE) provided in this application embodiment can use AI to extract features and recognize patterns from real-time transaction streams, and dynamically adjust the six parameters of the consensus mechanism:

[0123] 1. Consensus algorithm type (PoW / PoS / PBFT switching).

[0124] 2. Number of block-producing nodes.

[0125] 3. Block size and gas limit.

[0126] 4. Transaction verification depth.

[0127] 5. Node staking weight coefficient.

[0128] 6. Duration of final confirmation.

[0129] Figure 3 This is a schematic diagram of a dynamic consensus engine provided in an embodiment of this application, as shown below. Figure 3As shown, this dynamic consensus engine first obtains transaction characteristic data of transactions conducted in the blockchain network from the transaction pool. Then, an AI feature analysis engine extracts transaction risk scores, transaction value densities, and transaction load types from the transaction characteristic data. These data are then input into a preset consensus parameter dynamic decision-maker to obtain adjusted consensus mechanism parameters. The adjusted consensus mechanism parameters are executed by the consensus execution layer and fed back to the blockchain network.

[0130] Figure 4 This is a schematic diagram of an AI feature analysis engine provided in an embodiment of this application. The graph neural network identifies the maximum extractable value (MEV) attack behavior features in the transaction feature data based on transaction topology analysis; the time series model detects the fluctuation features of transaction transaction data in the transaction feature data based on gas fluctuation; and the anomaly monitoring model identifies abnormal transaction behavior features in the transaction feature data based on attack identification.

[0131] For example, the key algorithms of the embodiments of this application are described below.

[0132] 1. Quantitative model of transaction characteristics.

[0133] Input dimensions:

[0134] ① Transaction value density (transaction amount per unit of Gas);

[0135] ② Associated address complexity entropy (a measure of transaction graph complexity);

[0136] ③ Deviation of historical behavior (compared to the normal address pattern).

[0137] Output: Transaction feature vector, which can be represented by TxFeature, with values ​​between 0 and 1.

[0138] 2. Consensus parameter decision tree.

[0139] def consensus_adjust(TxFeature):

[0140] if TxFeature.risk_score > 0.8: # High-risk transaction

[0141] activate_hybrid_consensus(PBFT+PoS, node_count=50) # Activate the validator nodes

[0142] set_block_finality(10) # 10-level finality confirmation

[0143] elif TxFeature.value_density > 0.7: # High-value transaction

[0144] switch_to(PoS, staking_ratio=0.3) # Increase the staking threshold

[0145] reduce_block_time(2s) # Speed ​​up block production

[0146] else: # Regular transactions

[0147] maintain_default()

[0148] 3. Dynamic Proof of Stake (PoS).

[0149] The node weight formula is as follows:

[0150] Weight = α * Staked_Amount + β * AI_Reputation_Score

[0151] Among them, `Staked_Amount` represents the staked amount, that is, the number of tokens locked by a node to participate in network consensus or governance. `AI_Reputation_Score` represents the AI ​​reputation score, which is a dynamic reputation indicator generated based on the node's historical behavior (such as transaction verification accuracy, proposal participation, community contribution, etc.). The AI ​​reputation score can be calculated based on any one or more of the following: historical verification accuracy rate, abnormal transaction detection rate, and network response latency.

[0152] In summary, compared to traditional consensus mechanisms that require fixed block intervals, unified verification rules across all nodes, MEV protection relying on the application layer, and energy consumption being unrelated to transaction value, the embodiments of this application can achieve energy conservation based on elastic adjustment of transaction load, hierarchical verification (multi-round consensus for high-value transactions), real-time path blocking at the consensus layer, and AI-optimized resource allocation.

[0153] The above are the method embodiments provided in this application. The apparatus provided in this application will be described below.

[0154] Figure 5 A schematic diagram of a consensus parameter adjustment device provided in this application is shown below. Figure 5 As shown, the consensus parameter adjustment device 400 provided in this embodiment includes: an acquisition module 401, an adjustment module 402, and an operation module 403. Optionally, the consensus parameter adjustment device 400 may further include a processing module 404.

[0155] The acquisition module 401 is used to acquire transaction feature data of transactions conducted in the blockchain network.

[0156] The adjustment module 402 is used to dynamically adjust the consensus mechanism parameters of the blockchain network based on transaction feature data, so as to obtain the adjusted consensus mechanism parameters.

[0157] Run module 403 is used to run the consensus process of the blockchain network based on the adjusted consensus mechanism parameters.

[0158] Optionally, the adjustment module 402 is specifically used to extract the transaction risk score, transaction value density, and transaction load type from the transaction feature data. The transaction risk score, transaction value density, and transaction load type are input into a preset consensus parameter dynamic decision-maker to obtain the adjusted consensus mechanism parameters.

[0159] For example, a consensus parameter dynamic decision maker is used to perform at least one of the following steps: when the transaction risk score is greater than or equal to a preset score threshold, the adjusted consensus mechanism parameters are used to characterize the activation of the hybrid consensus mechanism. When the transaction value density is greater than or equal to a preset value density threshold, the adjusted consensus mechanism parameters include: the consensus algorithm after type switching. When the transaction load type is a preset target type, the adjusted consensus mechanism parameters include: the adjusted block size.

[0160] In one implementation, the adjustment module 402 is specifically used to identify the maximum extractable value (MEV) attack behavior features in the transaction feature data based on a graph network model; detect transaction transaction data fluctuation features in the transaction feature data based on a time series model; identify abnormal transaction behavior features in the transaction feature data based on an anomaly detection model; and obtain a transaction risk score based on the MEV attack behavior features, transaction transaction data fluctuation features, and abnormal transaction behavior features.

[0161] Optionally, the consensus process includes multiple consensus verification nodes. Before the running module 403 runs the consensus process of the blockchain network based on the adjusted consensus mechanism parameters, the processing module 404 determines the consensus verification node's participation weight in the consensus process based on the historical verification accuracy, abnormal transaction detection rate, and network response latency of the consensus verification nodes. Specifically, the running module 403 runs the consensus process of the blockchain network based on the adjusted consensus mechanism parameters and the consensus process participation weights.

[0162] Optionally, the device is applied to a blockchain system, and the acquisition module 401 is specifically used to extract transaction feature data of the transaction through a lightweight data feature extraction model deployed in the edge nodes of the blockchain system.

[0163] Optionally, the running module 403, after running the consensus process of the blockchain network based on the adjusted consensus mechanism parameters, then the processing module 404 specifically uses the historical trend of consensus mechanism parameter changes in the blockchain network to predict the consensus mechanism parameters at a future target time. At the future target time, based on the consensus mechanism parameters at the future target time, the consensus process of the blockchain network is run.

[0164] Optionally, the consensus mechanism parameters include at least one of the following: consensus algorithm type, number of block-producing nodes, block size, transaction verification depth, and transaction confirmation time.

[0165] The consensus parameter adjustment device provided in this embodiment can execute the methods provided in any of the above method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0166] Figure 6 This is a schematic diagram of the structure of an electronic device provided in this application. Figure 6 As shown, the electronic device 500 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the device 500 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0167] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0168] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0169] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0170] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0171] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0172] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0173] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0174] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0175] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0176] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0177] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0178] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0179] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0180] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0181] Finally, it should be noted that other embodiments of this application will readily conceive of by those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes may be made without departing from its scope.

Claims

1. A consensus parameter adjustment method, characterized in that, The method includes: Obtain transaction characteristic data of transactions conducted in the blockchain network; Based on the transaction feature data, the consensus mechanism parameters of the blockchain network are dynamically adjusted to obtain the adjusted consensus mechanism parameters. The consensus process of the blockchain network is run based on the adjusted consensus mechanism parameters.

2. The consensus parameter adjustment method according to claim 1, characterized in that, The process of dynamically adjusting the consensus mechanism parameters of the blockchain network based on the transaction feature data to obtain the adjusted consensus mechanism parameters includes: Extract the transaction risk score, transaction value density, and transaction load type from the transaction feature data; The transaction risk score, the transaction value density, and the transaction load type are input into a preset consensus parameter dynamic decision-maker to obtain the adjusted consensus mechanism parameters.

3. The consensus parameter adjustment method according to claim 2, characterized in that, The consensus parameter dynamic decision-maker is used to perform at least one of the following steps: When the transaction risk score is greater than or equal to a preset score threshold, the adjusted consensus mechanism parameters are used to characterize the activation of the hybrid consensus mechanism; When the transaction value density is greater than or equal to a preset value density threshold, the adjusted consensus mechanism parameters include: the consensus algorithm after type switching; When the transaction load type is a preset target type, the adjusted consensus mechanism parameters include: the adjusted block size.

4. The consensus parameter adjustment method according to claim 2 or 3, characterized in that, Extracting the transaction risk score from the transaction feature data includes: Based on the graph network model, identify the MEV attack behavior features with the maximum extractable value in the transaction feature data; Based on a time series model, the fluctuation characteristics of transaction fee data in the transaction feature data are detected; Based on the anomaly detection model, abnormal transaction behavior features are identified in the transaction feature data; The transaction risk score is obtained based on the characteristics of the MEV attack behavior, the fluctuation characteristics of the transaction data, and the characteristics of the abnormal transaction behavior.

5. The consensus parameter adjustment method according to any one of claims 1-3, characterized in that, The consensus process includes multiple consensus verification nodes. Before running the consensus process of the blockchain network based on the adjusted consensus mechanism parameters, the method further includes: Based on the historical verification accuracy rate, abnormal transaction detection rate, and network response latency of the consensus verification node, the participation weight of the consensus verification node in the consensus process is determined. The consensus process of running the blockchain network based on the adjusted consensus mechanism parameters includes: Based on the adjusted consensus mechanism parameters and the weights of the participants in the consensus process, the consensus process of the blockchain network is executed.

6. The consensus parameter adjustment method according to any one of claims 1-3, characterized in that, The method is applied to a blockchain system, wherein obtaining transaction feature data of transactions conducted in the blockchain network includes: The transaction feature data is extracted using a lightweight data feature extraction model deployed in the edge nodes of the blockchain system.

7. The consensus parameter adjustment method according to any one of claims 1-3, characterized in that, After running the consensus process of the blockchain network based on the adjusted consensus mechanism parameters, the method further includes: Based on the historical consensus mechanism parameter change trend of the blockchain network, the consensus mechanism parameters at the future target time are predicted. At the target future time, the consensus process of the blockchain network is executed based on the consensus mechanism parameters at the target future time.

8. The consensus parameter adjustment method according to any one of claims 1-3, characterized in that, The consensus mechanism parameters include at least one of the following: consensus algorithm type, number of block-producing nodes, block size, transaction verification depth, and transaction confirmation time.

9. A consensus parameter adjustment device, characterized in that, The device includes: The acquisition module is used to acquire transaction characteristic data of transactions conducted in the blockchain network; The adjustment module is used to dynamically adjust the consensus mechanism parameters of the blockchain network based on the transaction feature data, so as to obtain the adjusted consensus mechanism parameters. The running module is used to run the consensus process of the blockchain network based on the adjusted consensus mechanism parameters.

10. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-8.

12. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-8.

Images