Block chain multi-mode transaction packaging method based on dynamic load balancing

Abstract

The invention discloses a block chain multi-mode transaction packaging method based on dynamic load balancing, and relates to the technical field of block chains. The method comprises the following steps: a user initiates a multi-modal data request to a common node, and the common node performs standardization processing on received original multi-modal data and encapsulates a processing result into a standardized transaction object; performing weight calculation on the standardized transactions by the common nodes, packaging the standardized transactions and corresponding weight values into a whole, and submitting the standardized transactions and the corresponding weight values into a transaction pool; and the packaging node obtains the transaction data from the transaction pool and dynamically schedules the transaction for packaging based on the weight value of the transaction and the load of the packaging node. According to the method, the comprehensive performance of the block chain system in a multi-modal data processing scene is remarkably improved.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a blockchain multimodal transaction packaging method based on dynamic load balancing. Background Art

[0002] Blockchain technology, a decentralized distributed ledger, has been successfully applied in numerous fields, including financial transactions and supply chain management. However, with the continuous expansion of its application scenarios, and particularly the growing demand for multimodal data (such as text, images, and video) to be uploaded to blockchains, traditional blockchain systems face significant challenges in processing this data. Multimodal data transactions exhibit significant variations in data size and computational complexity, leading to inefficient transaction processing, network congestion, and uneven resource allocation.

[0003] The Ethereum Yellow Paper (2014) proposed a gas mechanism as its core technical solution. It requires users to set a gas price and upper limit when initiating a transaction. Ordinary nodes prioritize high-gas-price transactions. The system deducts the corresponding gas in real time according to the operation type (such as arithmetic operations, storage operations, etc.). If the gas is insufficient, the execution is interrupted and rolled back without refunding the consumed gas. Although this mechanism can effectively limit the computational complexity of transactions, it only relies on the single dimension of gas price to adjust the transaction priority, and fails to fully consider the differences in transaction size and computational complexity. Secondly, the gas cost is only roughly estimated. The calculation steps fail to accurately reflect the actual resource consumption differences between different types of data (such as text and video), resulting in video processing transactions and simple payments being assigned similar gas costs. As a result, large transactions (such as video data on-chain) may be delayed due to excessively high gas costs, while small transactions (such as simple payments) may accumulate for a long time due to improper gas price settings. Finally, this economic model is unbalanced. Although high gas fees can prevent junk transactions, they also lead to excessively high costs for large transaction processing, resulting in unfair data on-chain and seriously restricting the widespread application of multimodal data on the blockchain.

[0004] Hyperledger Fabric, a representative example of consortium blockchains, uses the PBFT consensus algorithm and channel isolation mechanism to improve transaction processing efficiency. Its transaction packaging adopts a fixed block size or fixed time interval block generation strategy. The specific implementation process is as follows: the client first submits the transaction to the endorsing node for verification. Verified transactions are then sent to the ordering service node, which packages the transactions into blocks on a first-come, first-served basis. Finally, the blocks are broadcast to all nodes for execution through the PBFT consensus protocol. However, this packaging strategy has certain limitations: First, its static strategy is obviously rigid, and the fixed-size block packaging method lacks flexibility and cannot adapt to the dynamic characteristics of multimodal data, resulting in large transactions occupying too much block space and small transactions being forced to wait for a long time; Second, this strategy leads to low resource utilization, and the first-come, first-served processing mechanism ignores the urgency of transactions and differences in resource requirements. Experimental data shows that in mixed-size transaction scenarios, block space utilization is usually less than 70%, far below the theoretical maximum; Most importantly, this strategy completely lacks an assessment of the computational complexity of transactions, resulting in nodes being overloaded by processing multiple high-complexity transactions at the same time. This defect is particularly evident in scenarios such as smart contract execution.

[0005] Load balancing technologies have been widely used in other network systems and achieved significant success. Content delivery networks (CDNs) dynamically distribute user requests across geographically distributed edge server clusters, effectively alleviating network congestion. Cloud computing platforms employ elastic resource allocation mechanisms to dynamically adjust computing resources based on real-time load conditions, ensuring service quality and resource utilization. However, despite their excellent performance in other network systems, these load balancing technologies exhibit significant incompatibility in blockchain scenarios due to the decentralized and immutable nature of blockchain. This is particularly true when processing multimodal data transactions, making them difficult to directly migrate and apply. This is primarily due to three key technical barriers: First, architectural differences create technical barriers. Load balancing technologies in CDNs and cloud computing platforms rely on the global decision-making mechanisms of centralized or semi-centralized architectures. However, the decentralized nature of blockchains results in a lack of global load information collection mechanisms, making it impossible to implement centralized scheduling strategies and to coordinate resource allocation between nodes in real time. Second, performance metrics are misaligned: the throughput and response time priorities of traditional systems cannot meet the requirements of blockchains. Summary of the Invention

[0006] In view of the above-mentioned shortcomings of the existing technology, the purpose of the present invention is to provide a blockchain multimodal transaction packaging method based on dynamic load balancing, aiming to build an innovative blockchain dynamic load balancing framework specifically to address the problem of uneven load caused by data volume differences and transaction complexity during the process of multimodal data on-chain. By breaking through the inherent limitations of traditional blockchain systems, a new processing mechanism that can adapt to the characteristics of data heterogeneity is established. A multi-dimensional transaction evaluation system is established, comprehensively considering key factors such as transaction size and computational complexity, to achieve accurate quantitative evaluation of different types of transactions; secondly, an intelligent resource allocation mechanism is designed to achieve a reasonable ratio of various types of transactions and balanced utilization of node resources through dynamic scheduling strategies.

[0007] The technical solution of the present invention is:

[0008] A blockchain multimodal transaction packaging method based on dynamic load balancing, the method comprising the following steps:

[0009] Step 1: The user initiates a multimodal data request to a common node. The common node standardizes the received raw multimodal data and encapsulates the processing results into a standardized transaction object.

[0010] Step 2: Ordinary nodes calculate the weight of standardized transactions, encapsulate the standardized transactions and their corresponding weight values, and submit them to the transaction pool;

[0011] Step 3: The packaging node obtains transaction data from the transaction pool and dynamically schedules transactions for packaging based on the transaction weight value and packaging node load.

[0012] Furthermore, according to the blockchain multimodal transaction packaging method, the multimodal data includes text, image, video, and audio data; the standardization processing is to perform structured conversion and feature extraction on different types of raw data, including:

[0013] A. For text data, we first unify its encoding format to UTF-8 to ensure character compatibility and calculate the SHA-256 hash value for integrity verification. We then extract key feature words and construct semantic feature vectors based on their TF-IDF weights.

[0014] B. Image data processing includes metadata parsing and standardizing it into a JSON structure, combining color histograms with a CNN model to generate a 128-dimensional visual feature vector, and ultimately using the WebP format for compression, balancing image quality and size.

[0015] C. The video data is divided into a sequence of key frames, and each frame undergoes the same feature extraction and compression process as the image, while also extracting video meta-parameters;

[0016] D. For audio data, first extract its acoustic parameters and calculate the audio fingerprint for identification and indexing as needed.

[0017] Furthermore, according to the blockchain multimodal transaction packaging method, the method for the ordinary node in step 2.1 to calculate the weight of the standardized transaction object is as follows:

[0018] First, common nodes extract multidimensional parameters and quantify the complexity of the characteristic values based on four types of standardized transactions; the parameters include:

[0019] (1) Transaction size S: This can be directly obtained from the metadata of the standardized transaction, i.e., the 'data size' field;

[0020] (2) Transaction complexity C: requires classification calculation. Based on the characteristic values of four types of data, a differentiated calculation formula is designed as follows:

[0021] Text data:

[0022] Image data:

[0023] Video data:

[0024] Audio data:

[0025] (3) Waiting time T: T = Current Timestamp - timestamp

[0026] In the above formula, Length represents the length of text data, Word Frequency represents the word frequency of text data, and IDF represents the inverse document frequency; Pixel represents the pixel of image data, Image Depth represents the depth of image data, and Sturation represents the saturation of image data; Duration represents the duration of video data, Frame Rate represents the frame rate of video data, and Frame Rate represents the bit rate of video data; Sample Rate represents the sampling rate of audio data, Bit Depth represents the bit depth of audio data, and Distortion represents the distortion of audio data; Current Timestamp represents the current time, which is obtained using the local time of the node, and the timestamp is taken from the time field recorded when the standard transaction is generated.

[0027] Then, ordinary nodes calculate the weight value of each standardized transaction based on its transaction size, transaction complexity, and transaction waiting time, and obtain the weight value of each standardized transaction as W:

[0028]

[0029] Where α, β, and γ represent dynamic weight coefficients, satisfying α+β+γ=1.

[0030] Furthermore, according to the blockchain multimodal transaction packaging method, the transaction storage structure in the transaction pool is composed of a data type identifier, a standardized transaction format, a weight value, a source node ID, and a status label; the status label includes to be packaged and packaged.

[0031] Furthermore, according to the blockchain multimodal transaction packaging method, the transaction pool maintenance strategy includes the following: transactions need to be sorted according to weight values, and timed-out or invalid transactions are regularly proposed; concurrent reading is supported for scheduling by multiple packaging nodes.

[0032] Furthermore, according to the blockchain multimodal transaction packaging method, step 3 includes the following steps:

[0033] Step 3.1: Design a packaging node load detection and status publishing mechanism;

[0034] Step 3.2: The packaging node determines the packaging strategy based on the transaction weight and its own node load status, and determines the packaging mode;

[0035] There are two packaging modes: capacity-first mode and quantity-first mode. The capacity-first mode prioritizes packaging as many transactions as possible, with the total transaction size as the upper limit. The quantity-first mode prioritizes packaging a fixed number of transactions to ensure response delays for high-frequency, low-load services.

[0036] The packaging node determines the packaging strategy based on the transaction weight and its own node load status according to the following judgment logic:

[0037]

[0038] Where θ1 represents the CPU load threshold; θ2 represents the upper limit of the average transaction size;

[0039] It should be noted that once the packaging mode is switched, it will continue until the next round of packaging node load status broadcast and the packaging strategy will be re-determined;

[0040] According to the packaging mode determined in step 3.2, the packaging node will execute the corresponding transaction scheduling strategy to schedule transactions for packaging;

[0041] The transaction scheduling strategy includes:

[0042] (1) In the capacity priority mode, the packaging node extracts transactions in order according to the transaction weight until the cumulative size of the transaction does not exceed C max Until; C maxIn order to dynamically determine the maximum total package size based on the current packaging node resource usage, the calculation formula is as follows:

[0043] C max =min{C0·(1-U cpu ),C abs}

[0044] Where C0 represents the baseline capacity coefficient, that is, the theoretical maximum packaging capacity baseline value, which represents the maximum transaction data volume that the node can package under ideal conditions; U cpu Indicates CPU utilization; C abs Indicates the absolute packaging limit, that is, the defined absolute maximum packaging capacity limit. That is, no matter how idle the node is, the packaging cannot exceed this limit;

[0045] (2) In quantity priority mode, set the upper limit N for packaging max ; Select the top N in order of transaction weight max Transactions are encapsulated into blocks without considering size restrictions;

[0046] (3) To improve fairness, the system also sets the maximum waiting protection threshold T max , transactions whose waiting time exceeds this threshold are forced to be packaged first to avoid long-term transaction starvation.

[0047] Furthermore, according to the blockchain multimodal transaction packaging method, the packaging node load detection and status publishing mechanism is as follows: each packaging node periodically collects and broadcasts its current operating load status, including CPU usage, memory occupancy, network IO, the time taken for the previous round of packaging, and the average transaction processing delay; and synchronizes the above information to all nodes in the entire network through lightweight hash broadcast, so that other nodes can obtain real-time packaging node status data based on this.

[0048] Furthermore, according to the blockchain multimodal transaction packaging method, the capacity priority mode is to prioritize packaging as many transactions as possible with the total transaction size as the upper limit; the quantity priority mode is to prioritize packaging a fixed number of transactions to ensure the response delay of high-frequency and low-load services.

[0049] Compared with the prior art, the present invention has the following beneficial effects:

[0050] This invention significantly improves the comprehensive performance of the blockchain system in multimodal data processing scenarios through an innovative dynamic scheduling mechanism. In terms of system throughput, the intelligent hybrid packaging strategy achieves a significant improvement in processing efficiency; the load balancing mechanism effectively reduces the resource utilization differences between nodes, fundamentally avoiding hot spots caused by uneven processing capabilities; the optimized processing of low-priority transactions significantly shortens their waiting time, enhancing the overall fairness of the system. It is particularly worth noting that the solution demonstrates excellent environmental adaptability. Regardless of whether network conditions fluctuate or computing resources are tight, the system can maintain a stable and reliable operating state, demonstrating good robustness. These performance improvements together constitute an efficient, fair, and stable multimodal data processing solution. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 This is a flowchart of a blockchain multimodal transaction packaging method based on dynamic load balancing in this embodiment;

[0052] Figure 2 Schematic diagram of a multimodal data request that can be initiated by a user of the present invention;

[0053] Figure 3 Schematic diagram of the storage structure of transactions in the transaction pool of the present invention;

[0054] Figure 4 This is a flow chart of the present invention for dynamically packaging transactions based on load. DETAILED DESCRIPTION

[0055] To facilitate understanding of the present application, the present application will be described more comprehensively below with reference to the relevant drawings.

[0056] Figure 1 This is a flow chart of the blockchain multimodal transaction packaging method based on dynamic load balancing in this embodiment. Figure 1 As shown, the multimodal blockchain transaction packaging method based on dynamic load balancing includes the following steps:

[0057] Step 1: The user initiates a multimodal data request to a common node. The common node receives the original multimodal data submitted by the user, performs standardization on the original multimodal data, and encapsulates the processing results into a standardized transaction object.

[0058] like Figure 2As shown, in this embodiment, users can initiate four types of multimodal data requests to ordinary nodes: text, image, video, and audio data. This invention also uses the following four types of multimodal data requests initiated by users to ordinary nodes as examples to explain in detail the blockchain multimodal transaction packaging method based on dynamic load balancing. Of course, those skilled in the art will readily understand that other types of multimodal data requests besides these four types are also applicable to the blockchain multimodal transaction packaging method based on dynamic load balancing.

[0059] During the data standardization phase, structured transformation and feature extraction are performed on different types of raw data:

[0060] A. For text data, first unify its encoding format to UTF-8 to ensure character compatibility, and calculate the SHA-256 hash value for integrity verification. Then, extract key feature words and construct semantic feature vectors based on their TF-IDF weights.

[0061] B. Image data processing includes metadata parsing and standardizing it into a JSON structure, combining color histograms with a CNN model to generate a 128-dimensional visual feature vector, and ultimately using the WebP format for compression to balance image quality and size.

[0062] C. The video data is divided into a sequence of key frames (one frame is extracted every 5 seconds). Each frame undergoes the same feature extraction and compression process as the image, and video metadata parameters are extracted at the same time, including resolution, frame rate, bit rate, duration, and dynamic range.

[0063] D. For audio data, first extract its acoustic parameters, including sampling rate, bit depth, number of channels, distortion, and response rate, and calculate audio fingerprints such as MFCC for identification and indexing as needed.

[0064] All processing results are encapsulated as standardized transaction objects. The four types of standardized transaction formats formed after processing are shown in Table 1.

[0065] Table 1 Four types of standardized transaction formats

[0066]

[0067] Step 2: Ordinary nodes calculate the weight of the standardized transaction objects formed by multimodal data and submit them to the transaction pool.

[0068] Step 2.1: Ordinary nodes calculate the weight of the transaction:

[0069] First, common nodes extract multidimensional parameters and quantify the complexity of the characteristic values based on four types of standardized transactions. The following three parameters are mainly required:

[0070] (3) Transaction size (S): can be directly obtained from the standardized transaction metadata, i.e., the ‘data size’ field;

[0071] (4) Transaction complexity (C): Requires classified calculations, and differentiated calculation formulas are designed based on the characteristic values of four types of data:

[0072] Text data:

[0073] Image data:

[0074] Video data:

[0075] Audio data:

[0076] In the above formula, Length refers to the length of the text data, WordFrequency refers to the word frequency of the text data, and IDF refers to the inverse document frequency. Pixel refers to the pixels in the image data, ImageDepth refers to the depth of the image data, and Satruration refers to the saturation of the image data. Duration refers to the duration of the video data, FrameRate refers to the frame rate of the video data, and Bitrate refers to the bitrate of the video data. SampleRate refers to the sampling rate of the audio data, BitDepth refers to the bit depth of the audio data, and Distortion refers to the distortion of the audio data. These parameters correspond to the standardized transaction format created in step 1.

[0077] (4) Calculation of waiting time (T): T = Current Timestamp - timestamp

[0078] Among them, Current Timestamp refers to the current time obtained using the node local time, and timestamp is taken from the time field recorded when the standard transaction is generated.

[0079] Afterwards, ordinary nodes calculate the weight of each standardized transaction based on its transaction size, transaction complexity, and transaction waiting time. The weight is designed to comprehensively measure the transaction's occupation of system resources, processing complexity, and urgency, thereby providing a quantitative basis for the packaging node to select subsequent transactions. Assuming the weight of each standardized transaction is W, its calculation formula can be defined as:

[0080] Where α, β, and γ refer to dynamic weight coefficients, satisfying α+β+γ=1; S refers to the transaction size; C refers to the transaction complexity; and T refers to the transaction waiting time.

[0081] Step 2.2: Ordinary nodes submit weight calculation results to the transaction pool:

[0082] After completing the weight calculation, the common node packages the standardized transaction and its corresponding weight value into one, and submits it to the transaction pool to be packaged to support the unified scheduling management of transactions. The transaction storage structure in the transaction pool is as follows: Figure 3 As shown, it consists of data type identification, standardized transaction format, weight value, source node ID, and status label. Among them, the data type identification is the identification data belongs to Figure 2 Which of the four types of data is it? The standardized transaction format is the relevant content contained in Table 1. The weight value W is the weight result calculated for each transaction in step 2.1. The source node ID is mainly to ensure the traceability of the blockchain system, and it is necessary to record the common node ID that submitted this transaction. There are two types of status tags: to be packaged and packaged.

[0083] It is also worth mentioning the transaction pool maintenance strategy, which usually includes the following: transactions should be sorted according to weight values, and timed-out or invalid transactions should be regularly raised; concurrent reading should be supported for scheduling by multiple packaging nodes.

[0084] Step 3: The packaging node collects transaction data from the transaction pool and dynamically schedules transactions for packaging based on transaction weight and packaging node load.

[0085] After the standardized multimodal transaction completes weight calculation and enters the transaction pool, the packaging node in the blockchain system will trigger the packaging process at a certain frequency to build a new block. In order to achieve the unity of system load balancing and transaction processing efficiency, this step designs a dynamic scheduling mechanism based on transaction weight and node load, and introduces the intelligent judgment and switching mechanism of "capacity priority mode" and "quantity priority mode" to achieve adaptive optimization of block building strategy. The flowchart of this part is as follows Figure 4 As shown, it mainly includes the following three key links:

[0086] Step 3.1: Design a packaging node load detection and status publishing mechanism;

[0087] Each packaging node periodically collects and broadcasts its current operational load status, including CPU usage, memory utilization, network I / O, the time taken for the last packaging round, and average transaction processing latency. This information is then synchronized to all nodes in the network via lightweight hash broadcasts, allowing other nodes to obtain real-time packaging node status data. This mechanism provides a global view to support subsequent task allocation and packaging decisions.

[0088] Step 3.2: The packaging node makes a policy decision based on the transaction weight and its own node load status:

[0089] To adapt to diverse business scenarios, the system supports two packaging strategies: capacity-first mode and quantity-first mode. Capacity-first mode prioritizes packaging as many transactions as possible (upper limit based on total transaction size), which is suitable for nodes with abundant network resources but slow processing speeds. Quantity-first mode prioritizes packaging a fixed number of transactions to ensure response delays for high-frequency, low-load businesses, and is suitable for high TPS scenarios. The packaging node executes the following decision logic based on factors such as the current operating load, average transaction size, network IO bandwidth, and CPU headroom:

[0090]

[0091] Where: θ1 represents the CPU load threshold (e.g., 80%); θ2 represents the upper limit of the average transaction size (e.g., 500KB);

[0092] It should be noted that once the mode is switched, it will continue until the next round of packaging node load status broadcast and then be re-determined.

[0093] Step 3.3: Adaptive packaging capacity control and dynamic block construction mechanism;

[0094] According to the packaging mode determined in step 3.2, the packaging node will execute the corresponding transaction scheduling strategy:

[0095] In the capacity priority mode, the packaging node extracts transactions in order according to the transaction weight until the cumulative size of the transaction does not exceed C max Until now. C max In order to dynamically determine the maximum total package size based on the current packaging node resource usage, the calculation formula is as follows:

[0096] C max =min{C0·(1-U cpu ),C abs}

[0097] Among them U cpu Indicates CPU utilization; C0 refers to the baseline capacity coefficient, which is the theoretical maximum packaging capacity baseline value set, indicating the maximum transaction data volume that the node can package under ideal conditions (such as CPU load is 0), and the unit is generally KB or MB. abs Refers to the absolute packaging limit, that is, the defined absolute maximum packaging capacity limit. That is, no matter how idle the node is, it cannot pack more than this limit to prevent problems such as slow network propagation and slow verification due to overly large blocks.

[0098] In quantity priority mode, set the packaging limit N max , for example, each round can only pack 100 transactions at most. Select the top N transactions in order of transaction weight. max Transactions are encapsulated into blocks without considering size limitations.

[0099] At the same time, in order to improve fairness, the system also sets the maximum waiting protection threshold T max , transactions whose waiting time exceeds this threshold are forced to be packaged first to avoid long-term transaction starvation.

[0100] Once a packaging node completes the selection and block construction of a multimodal transaction, the system immediately broadcasts the new block through the blockchain network. First, the packaging node performs structured packaging and digital signatures on the new block to ensure the integrity of the block data and its trusted source. The block is then sent to its directly connected neighboring nodes via the P2P network protocol. Upon receiving the new block, these neighboring nodes quickly verify the legitimacy of the transactions, block structure, and previous hash links. Once verified, the node then broadcasts the block to its neighboring nodes, achieving a layered diffusion of the block throughout the network.

[0101] At this point, the multimodal data submitted by users has been standardized, weighted, and packaged, and the packaged blocks will be broadcast to each node of the blockchain system.

[0102] It should be understood that, inspired by the technical concept of the present invention, those skilled in the art may make various improvements or changes based on the above content without departing from the content of the present invention, which still fall within the scope of protection of the present invention.

Claims

1. A blockchain multimodal transaction packaging method based on dynamic load balancing, characterized in that: The method comprises the following steps: Step 1: The user initiates a multimodal data request to a common node. The common node standardizes the received raw multimodal data and encapsulates the processing results into a standardized transaction object. Step 2: Ordinary nodes calculate the weight of standardized transactions, encapsulate the standardized transactions and their corresponding weight values, and submit them to the transaction pool; Step 3: The packaging node obtains transaction data from the transaction pool and dynamically schedules transactions for packaging based on the transaction weight value and packaging node load.

2. The blockchain multimodal transaction packaging method according to claim 1 is characterized in that: The multimodal data includes text, images, videos, and audio data; the standardization process is to perform structured transformation and feature extraction on different types of raw data, including: A. For text data, we first unify its encoding format to UTF-8 to ensure character compatibility and calculate the SHA-256 hash value for integrity verification. We then extract key feature words and construct semantic feature vectors based on their TF-IDF weights. B. Image data processing includes metadata parsing and standardizing it into a JSON structure, combining color histograms with a CNN model to generate a 128-dimensional visual feature vector, and ultimately using the WebP format for compression, balancing image quality and size. C. The video data is divided into a sequence of key frames, and each frame undergoes the same feature extraction and compression process as the image, while also extracting video meta-parameters; D. For audio data, first extract its acoustic parameters and calculate the audio fingerprint for identification and indexing as needed.

3. The blockchain multimodal transaction packaging method according to claim 2 is characterized in that: The method for ordinary nodes to calculate the weight of standardized transaction objects is as follows: First, common nodes extract multidimensional parameters and quantify the complexity of the characteristic values based on four types of standardized transactions; the parameters include: (1) Transaction size S: This can be directly obtained from the metadata of the standardized transaction, i.e., the 'data size' field; (2) Transaction complexity C: requires classification calculation. Based on the characteristic values of four types of data, a differentiated calculation formula is designed as follows: Text data: Image data: Video data: Audio data: (3) Waiting time T: T = Current Timestamp - timestamp In the above formula, Length represents the length of text data, Word Frequency represents the word frequency of text data, and IDF represents the inverse document frequency; Pixel represents the pixel of image data, Image Depth represents the depth of image data, and Saturation represents the saturation of image data; Duration represents the duration of video data, Frame Rate represents the frame rate of video data, and Bitrate represents the bit rate of video data; Sample Rate represents the sampling rate of audio data, Bit Depth represents the bit depth of audio data, and Distortion represents the distortion of audio data; Current Timestamp represents the current time, which is obtained using the node local time. The timestamp is taken from the time field recorded when the standard transaction is generated. Then, ordinary nodes calculate the weight value of each standardized transaction based on its transaction size, transaction complexity, and transaction waiting time, and obtain the weight value of each standardized transaction as W: Where α, β, and γ represent dynamic weight coefficients, satisfying α+β+γ=1.

4. The blockchain multimodal transaction packaging method according to claim 2, characterized in that: The transaction storage structure in the transaction pool is composed of a data type identifier, a standardized transaction format, a weight value, a source node ID, and a status tag; the status tag includes "to be packaged" and "packaged".

5. The blockchain multimodal transaction packaging method according to claim 2 is characterized in that: The transaction pool maintenance strategy includes the following: transactions must be sorted according to weight values, and timed-out or invalid transactions are regularly raised; concurrent reading is supported for scheduling by multiple packaging nodes.

6. The blockchain multimodal transaction packaging method according to claim 1 or 3, characterized in that: The step 3 comprises the following steps: Step 3.1: Design a mechanism for detecting and publishing the load of packaging nodes; Step 3.2: The packaging node determines the packaging strategy based on the transaction weight and its own node load status, and determines the packaging mode; the packaging mode includes: capacity priority mode and quantity priority mode; The packaging node determines the packaging strategy based on the transaction weight and its own node load status according to the following judgment logic: Where θ1 represents the CPU load threshold; θ2 represents the upper limit of the average transaction size; It should be noted that once the packaging mode is switched, it will continue until the next round of packaging node load status broadcast and the packaging strategy will be re-determined; Step 3.3: Based on the packaging mode determined in step 3.2, the packaging node will execute the corresponding transaction scheduling strategy to schedule transactions for packaging; The transaction scheduling strategy includes: (1) In the capacity priority mode, the packaging node extracts transactions in order according to the transaction weight until the cumulative size of the transaction does not exceed C max Until; C max In order to dynamically determine the maximum total size that can be packaged based on the current packaging node resource usage, the calculation formula is as follows: C max =min{C0·(1-U cpu ),C abs } Where C0 represents the baseline capacity coefficient, that is, the theoretical maximum packaging capacity baseline value, which represents the maximum transaction data volume that the node can package under ideal conditions; U cpu Indicates CPU utilization; C abs Indicates the absolute packaging limit, that is, the defined absolute maximum packaging capacity limit. That is, no matter how idle the node is, the packaging cannot exceed this limit; (2) In quantity priority mode, set the upper limit N for packaging max ; Select the top N in order of transaction weight max Transactions are encapsulated into blocks without considering size restrictions; (3) To improve fairness, the system also sets the maximum waiting protection threshold T max , transactions whose waiting time exceeds this threshold are forced to be packaged first to avoid long-term transaction starvation.

7. The blockchain multimodal transaction packaging method according to claim 6 is characterized in that: The packaging node load detection and status publishing mechanism is as follows: each packaging node periodically collects and broadcasts its current operating load status, including CPU usage, memory occupancy, network IO, the time taken for the last packaging round, and the average transaction processing delay; The above information is synchronized to all nodes in the entire network through lightweight hash broadcasting, and other nodes can obtain real-time packaging node load status data based on it.

8. The blockchain multimodal transaction packaging method according to claim 6 is characterized in that: The capacity priority mode is to prioritize packaging as many transactions as possible with the total transaction size as the upper limit; the quantity priority mode is to prioritize packaging a fixed number of transactions to ensure the response delay of high-frequency, low-load services.

Images