A blockchain multi-modal transaction packaging method based on dynamic load balancing

Abstract

The application discloses a kind of based on dynamic load balancing's blockchain multi-modal transaction packing method, it is related to blockchain technology field.The method includes: user initiates multi-modal data request to ordinary node, ordinary node carries out standardization processing to its received original multi-modal data, and processing result is encapsulated as standardization transaction object;Ordinary node carries out weight calculation to standardization transaction, and standardization transaction and its corresponding weight value are encapsulated as a whole, and submitted to transaction pool;Packing node obtains transaction data from transaction pool and packs transaction based on the weight value of transaction and the load dynamic scheduling of packing node.The method significantly improves the comprehensive performance of blockchain system in multi-modal data processing scene.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and specifically to a method for packaging multimodal blockchain transactions based on dynamic load balancing. Background Technology

[0002] Blockchain technology, as a decentralized distributed ledger technology, has been successfully applied in many fields such as financial transactions and supply chain management. However, with the continuous expansion of application scenarios, especially the increasing demand for on-chain processing of multimodal data (such as text, images, and videos), traditional blockchain systems face significant challenges in processing this type of data. Multimodal data transactions vary significantly in terms of data size and computational complexity, leading to problems such as low transaction processing efficiency, network congestion, and uneven resource allocation.

[0003] The Gas mechanism proposed in the Ethereum Yellow Paper (2014) is its core technical solution. It requires users to set a Gas price and cap when initiating a transaction. Ordinary nodes prioritize packaging transactions with higher Gas prices. The system deducts the corresponding Gas in real time based on the operation type (e.g., arithmetic operations, storage operations). If Gas is insufficient, execution is interrupted and rolled back without refunding consumed Gas. While this mechanism effectively limits the computational complexity of transactions, it relies solely on Gas price to adjust transaction priority, failing to fully consider the differences between transaction size and computational complexity. Furthermore, Gas costs are 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). This means that video processing transactions and simple payments may be assigned similar gas costs, leading to delays in processing large transactions (such as uploading video data to the blockchain) due to excessively high gas costs, while small transactions (such as simple payments) may accumulate indefinitely due to improperly set gas prices. Finally, this economic model suffers from imbalance. While high gas fees can prevent spam transactions, they also lead to excessively high processing costs for large transactions, creating unfairness in data uploading to the blockchain and severely restricting the widespread application of multimodal data on the blockchain.

[0004] Hyperledger Fabric, a typical example of a consortium blockchain, employs the PBFT consensus algorithm and channel isolation mechanism to improve transaction processing efficiency. Its transaction packaging uses a block production strategy with fixed block size or fixed time intervals. 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 transaction into blocks according to a first-come, first-served principle. Finally, the blocks are broadcast to all nodes for execution via 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, which may cause large transactions to occupy too much block space, while small transactions may be forced to wait for a long time; Second, this strategy leads to low resource utilization. The first-come, first-served processing mechanism ignores the urgency of transactions and the differences in resource requirements. Experimental data shows that in mixed-size transaction scenarios, the block space utilization is usually less than 70%, far below the theoretical maximum value; Most importantly, this strategy completely lacks the assessment of transaction computational complexity, which may cause nodes to process multiple high-complexity transactions at the same time and become overloaded. This defect is particularly evident in scenarios such as smart contract execution.

[0005] In other network systems, load balancing technology has been widely applied and achieved significant results: Content Delivery Networks (CDNs) dynamically allocate user requests through 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 the excellent performance of these load balancing technologies in other network systems, due to the decentralized and immutable characteristics of blockchain, these technologies exhibit significant incompatibility in blockchain scenarios, particularly in handling multimodal data transactions. They cannot be directly ported to applications, mainly in three aspects: First, architectural differences create technical barriers. The load balancing technologies of CDNs and cloud computing platforms rely on centralized or semi-centralized global decision-making mechanisms, while the decentralized nature of blockchain leads to a lack of global load information collection mechanisms, an inability to implement centralized scheduling strategies, and difficulty in real-time coordination of resource allocation between nodes; second, performance metrics are misaligned. The throughput and response time that traditional systems focus on cannot meet the requirements of blockchain. Summary of the Invention

[0006] In view of the shortcomings of the existing technology, the purpose of this 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 for addressing the uneven load problem caused by differences in data volume and transaction complexity during the multimodal data uploading process. By breaking through the inherent limitations of traditional blockchain systems, a new processing mechanism capable of adapting to the heterogeneity of data 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 allocation of various transactions and balanced utilization of node resources through dynamic scheduling strategies.

[0007] The technical solution of this invention is:

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

[0009] Step 1: The user initiates a multimodal data request to a regular node. The regular node performs standardization processing on the raw multimodal data it receives and encapsulates the processing result into a standardized transaction object.

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

[0011] Step 3: The packaging node retrieves transaction data from the transaction pool and dynamically schedules transactions for packaging based on the transaction weight value and the 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 involves performing structured transformation and feature extraction on different types of raw data, including:

[0013] A. For text data, firstly, 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.

[0014] B. Image data processing includes parsing metadata and standardizing it into a JSON structure, combining color histograms and CNN models to generate 128-dimensional visual feature vectors, and finally using WebP format to compress the quality in order to balance image quality and file size.

[0015] C. The video data is divided into keyframe sequences, and each frame undergoes the same feature extraction and compression process as the image, while video meta-parameters are extracted.

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

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

[0018] First, ordinary nodes perform multi-dimensional parameter extraction and complex quantification on the feature values ​​based on four types of standardized transactions; the parameters include:

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

[0020] (2) Transaction complexity C: It needs to be calculated by category. The differentiated calculation formula is designed based on the feature values ​​of the four types of data 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 formulas, Length represents the length of the text data, Word Frequency represents the word frequency of the text data, and IDF represents the inverse document frequency; Pixel represents the pixel count of the image data, Image Depth represents the image depth, and Sturation represents the image saturation; Duration represents the duration of the video data, Frame Rate represents the frame rate of the video data, and Frame Rate represents the bit rate of the video data; Sample Rate represents the sampling rate of the audio data, Bit Depth represents the bit depth of the audio data, and Distortion represents the distortion of the audio data; Current Timestamp represents the current time, obtained using the node's local time, while the timestamp is taken from the time field recorded when the standard transaction was generated;

[0027] Then, for each standardized transaction, the ordinary node calculates a weight value W based on its transaction size, transaction complexity, and transaction wait time.

[0028]

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

[0030] Furthermore, according to the blockchain multimodal transaction packaging method, the transaction storage structure in the transaction pool consists 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 "already packaged".

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

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

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

[0034] Step 3.2: The packaging node combines the transaction weight and its own node load status to determine the packaging strategy and thus the packaging mode;

[0035] The packaging mode includes two types: capacity priority mode and quantity priority mode. The capacity priority mode packages as many transactions as possible with the total transaction size as the upper limit. The quantity priority mode packages a fixed number of transactions to ensure the response latency of high-frequency, low-load services.

[0036] The packaging node determines the packaging strategy based on the following logic, combining transaction weights and its own node load status:

[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 remain in effect until the next round of packaging node load status broadcasts and the packaging strategy is re-determined.

[0040] 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;

[0041] The transaction scheduling strategy includes:

[0042] (1) In capacity-first mode, the packaging nodes extract transactions in order of transaction weight until the cumulative transaction size does not exceed C. max Until; C maxTo dynamically determine the maximum total size that can be packaged based on the current resource usage of the packaging node, the calculation formula is as follows:

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

[0044] Where C0 represents the baseline capacity coefficient, which is the set theoretical maximum packaging capacity baseline value, representing the maximum amount of transaction data that a node can package under ideal conditions; U cpu Indicates CPU utilization; C abs This indicates the absolute upper limit for packaging, which is the defined maximum packaging capacity limit. No matter how idle the node is, it cannot package more than this limit.

[0045] (2) In quantity priority mode, set the packaging limit N. max Select the top N transactions in order of their weights. max Each transaction is encapsulated into a block, eliminating the need to consider size limitations;

[0046] (3) To improve fairness, the system also sets a maximum waiting protection threshold T. max Transactions with waiting times exceeding this threshold are forcibly 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 publication mechanism is as follows: each packaging node periodically collects and broadcasts its current operating load status, including CPU utilization, memory usage, network IO, the packaging time of the previous round, and the average transaction processing latency; 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.

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

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

[0050] This invention significantly improves the overall performance of blockchain systems in multimodal data processing scenarios through an innovative dynamic scheduling mechanism. In terms of system throughput, the intelligent hybrid packaging strategy achieves a substantial increase in processing efficiency; the load balancing mechanism effectively reduces the resource utilization differences between nodes, fundamentally avoiding hotspot issues caused by uneven processing capacity; and optimized processing of low-priority transactions significantly shortens their waiting time, enhancing the overall fairness of the system. Particularly noteworthy is the excellent environmental adaptability of this solution. Whether under fluctuating network conditions or limited computing resources, the system maintains a stable and reliable operating state, demonstrating good robustness. These performance improvements collectively constitute an efficient, fair, and stable multimodal data processing solution. Attached Figure Description

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

[0052] Figure 2 This is a schematic diagram illustrating the multimodal data requests that users can initiate according to the present invention;

[0053] Figure 3 This is a schematic diagram of the storage structure of transactions in the transaction pool of this invention;

[0054] Figure 4 This is a flowchart illustrating the dynamic transaction packaging based on load according to the present invention. Detailed Implementation

[0055] To facilitate understanding of this application, a more comprehensive description of this application will be provided below with reference to the accompanying drawings.

[0056] Figure 1 This is a flowchart of the blockchain multimodal transaction packaging method based on dynamic load balancing in this implementation method. For example... 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 regular node. After receiving the raw multimodal data submitted by the user, the regular node performs standardized processing on the raw multimodal data and encapsulates the processing result into a standardized transaction object.

[0058] like Figure 2As shown, in this embodiment, a user can initiate four types of multimodal data requests to a regular node: text, image, video, and audio data. This invention will also use these four types of multimodal data requests initiated by a user to a regular node as examples to describe in detail a 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 a blockchain multimodal transaction packaging method based on dynamic load balancing.

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

[0060] A. For text data, firstly, 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 parsing and standardizing metadata into a JSON structure, combining color histograms and CNN models to generate 128-dimensional visual feature vectors, and finally using WebP format to compress quality, balancing image quality and file size.

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

[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 as needed for identification and indexing.

[0064] All processing results are encapsulated into 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 weights of standardized transaction objects formed from multimodal data and submit them to the transaction pool.

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

[0069] First, ordinary nodes perform multi-dimensional parameter extraction and complex metric normalization on the feature values ​​based on four types of standardized transactions. The following three parameters are mainly required:

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

[0071] (4) Transaction complexity (C): Requires categorized calculation, with differentiated calculation formulas designed based on the feature values ​​of the four types of data:

[0072] Text data:

[0073] Image data:

[0074] Video data:

[0075] Audio data:

[0076] In the above formulas, 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 number of pixels in the image data, Image Depth refers to the image depth, and Satruration refers to the image saturation. Duration refers to the duration of the video data, Frame Rate refers to the frame rate of the video data, and Bitrate refers to the bitrate of the video data. Sample Rate refers to the sampling rate of the audio data, Bit Depth refers to the bit depth of the audio data, and Distortion refers to the distortion of the audio data. These parameters all correspond to the standardized transaction format formed in step 1.

[0077] (4) Waiting time (T) calculation: T = Current Timestamp - timestamp

[0078] Here, Current Timestamp refers to the current time obtained using the node's local time, while timestamp is taken from the time field recorded when a standard transaction is generated.

[0079] Subsequently, ordinary nodes calculate a weight value for each standardized transaction based on its transaction size, complexity, and waiting time. The weight value is designed to comprehensively measure the transaction's resource consumption, processing complexity, and urgency, thus providing a quantitative basis for subsequent transaction selection by the packaging nodes. Let the weight of each standardized transaction be W, then its calculation formula can be defined as:

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

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

[0082] After weight calculation, ordinary nodes encapsulate standardized transactions and their corresponding weight values ​​into a single package and submit it to the transaction pool to support unified transaction scheduling and management. The transaction storage structure in the transaction pool is as follows: Figure 3 As shown, it consists of a data type identifier, a standardized transaction format, a weight value, a source node ID, and a status label. The data type identifier identifies the type of data. 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 ID of the ordinary node that submitted this transaction. There are two types of status tags: pending packaging and packaged.

[0083] It is also worth mentioning the maintenance strategy for the transaction pool, which typically includes the following: transactions should be sorted according to their weight values, and transactions that have timed out or expired should be periodically removed; 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 standardized multimodal transactions complete weight calculations and enter the transaction pool, the packaging nodes in the blockchain system will trigger the packaging process at a certain frequency to construct new blocks. To achieve a balance between system load balancing and transaction processing efficiency, this step designs a dynamic scheduling mechanism based on transaction weights and node loads. It also introduces an intelligent judgment and switching mechanism between "capacity priority mode" and "quantity priority mode" to achieve adaptive optimization of the block construction strategy. The flowchart for this part is as follows: Figure 4 As shown, it mainly includes the following three key steps:

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

[0087] Each packaging node periodically collects and broadcasts its current operational load status, including CPU utilization, memory usage, network I / O, the time taken for the previous packaging round, and average transaction processing latency. This information is then synchronized to all nodes in the network via lightweight hash broadcasting, 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 determines the strategy 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 (up to the maximum total transaction size), suitable for nodes with abundant network resources but slow processing speeds. Quantity-first mode prioritizes packaging a fixed number of transactions, ensuring response latency for high-frequency, low-load services, suitable for high-TPS scenarios. The packaging node executes the following decision logic based on factors such as current operating load, average transaction size, network I / O bandwidth, and CPU availability:

[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 remain in effect until the next round of packaging node load status broadcast and a new determination is made.

[0093] Step 3.3: Adaptive Packaging Capacity Control and Dynamic Block Building Mechanism;

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

[0095] In capacity-first mode, the packaging nodes extract transactions sequentially according to transaction weight until the cumulative transaction size does not exceed C. max Until then. C max To dynamically determine the maximum total size that can be packaged based on the current resource usage of the packaging node, the calculation formula is as follows:

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

[0097] Among them U cpu C0 represents CPU utilization; C0 refers to the baseline capacity coefficient, which is the theoretical maximum packing capacity baseline value. It represents the maximum amount of transaction data that a node can pack under ideal conditions (such as CPU load of 0), and the unit is usually KB or MB. abs This refers to the absolute upper limit of the block size, which is the defined maximum block size limit. No matter how idle a node is, it cannot block more than this limit to prevent problems such as slow network propagation and slow verification caused by excessively large blocks.

[0098] In quantity-priority mode, set the maximum number of packages N. max For example, a maximum of 100 transactions can be packaged per round. The top N transactions are selected in order of their weights. max Each transaction is encapsulated into a block, eliminating the need to consider size limitations.

[0099] Meanwhile, to improve fairness, the system also sets a maximum waiting protection threshold T. max Transactions with waiting times exceeding this threshold are forcibly packaged first to avoid long-term transaction starvation.

[0100] Once the packaging node completes the selection of multimodal transactions and block construction, the system immediately broadcasts the new block through the blockchain network. First, the packaging node performs structured encapsulation and digital signature on the new block to ensure the integrity and trustworthiness of the block data. Then, the block is sent to its directly connected neighboring nodes via a P2P network protocol. Upon receiving the new block, these neighboring nodes quickly verify the legality of the transactions, the block structure, and the pre-hash linking. After successful verification, the node then continues to broadcast the block to its neighboring nodes, thus achieving a layered, diffusion-like propagation of the block throughout the network.

[0101] At this point, the multimodal data submitted by the user has been standardized, weighted, and packaged into transactions, and the packaged blocks will be broadcast to all nodes of the blockchain system.

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

Claims

1. A method for multi-modal transaction packaging of a blockchain based on dynamic load balancing, characterized in that, The method comprises the following steps: Step 1: the user initiates a multimodal data request to the ordinary node, and the ordinary node standardizes the original multimodal data received by it and encapsulates the processing result as a standardized transaction object; the multimodal data includes text, image, video and audio data; Step 2: the ordinary node calculates the weight of the standardized transaction and encapsulates the standardized transaction and its corresponding weight value into one, and submits it to the transaction pool; The common node calculates the weight value of each standardized transaction according to the transaction size, the transaction complexity, the transaction latency and the transaction waiting time of the standardized transaction The weight value of each standardized transaction is :​​ ； wherein , , denotes a dynamic weight coefficient, satisfying ; Step 3: 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; The step 3 comprises the following steps: Step 3.1: design a packaging node load detection and state publishing mechanism; Step 3.2: the packaging node determines the packaging mode by combining the transaction weight and the node load state; the packaging mode includes: capacity priority mode and quantity priority mode; The packaging node determines the packaging strategy according to the following judgment logic by combining the transaction weight and the node load state: ; wherein represents a CPU load threshold value; represents an upper limit of transaction average size; It should be noted that once the packaging mode is switched, it will continue until the next round of packaging node load state broadcast and the packaging strategy is re-determined; Step 3.3: according to the packaging mode determined in step 3.2, the packaging node will execute the corresponding transaction scheduling strategy to schedule the transaction for packaging; The transaction scheduling strategy includes: (1) In the capacity priority mode, the packing node extracts transactions in order of transaction weight ordering until the cumulative size of transactions does not exceed ; To dynamically determine the maximum packable total size according to the current packing node resource usage, the calculation formula is as follows: ; wherein represents the reference capacity coefficient, i.e., the set theoretical maximum packing capacity reference value, representing the maximum amount of transaction data that the node can pack in an ideal state; represents the CPU utilization rate; represents the absolute packing upper limit, i.e., the defined absolute maximum packing capacity limit, i.e., no matter how idle the node is, it cannot pack more than this upper limit; (2) In the quantity priority mode, set the upper limit of packaging ; Select the first transaction packaging into the block according to the transaction weight order, without considering the volume limit; (3) To improve fairness, the system also sets a maximum waiting protection threshold Transactions whose waiting time exceeds this threshold are forced to be packaged first to avoid long transaction starvation.

2. The blockchain multi-modal transaction packaging method of claim 1, wherein, The standardization processing is to perform structured conversion and feature extraction on different types of original data, including: 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 check, then extract key feature words and construct a semantic feature vector according to the TF-IDF weight; B. Image data processing includes metadata analysis and standardization to JSON structure, combined with color histogram and CNN model to generate 128-dimensional visual feature vector, finally use WebP format compression quality to balance picture quality and volume; C. Video data is divided into key frame sequence, each frame performs the same feature extraction and compression process as image, and video meta parameters are extracted; D. For audio data, first extract its acoustic parameters, and calculate audio fingerprint for identification and indexing as needed.

3. The blockchain multi-modal transaction packaging method of claim 2, wherein, The method for the ordinary node to calculate the weight of the standardized transaction object is as follows: First, the ordinary node extracts multi-dimensional parameters and complexity from the feature values based on the four types of standardized transactions; the parameters include: (1) Transaction size : Obtained directly from the metadata of the standardized transaction, i.e. the 'Data size' field; (2) Transaction complexity : need to classify the calculation, based on four categories of data feature value design differential calculation formula as follows: Text data: ; Image data: ; Video data: ; Audio data: ; (3) Latency : ; In the above formula represents the length of the text data, represents the word frequency of the text data, represents the inverse document frequency; represents the pixel of the picture data, represents the depth of the image data, represents the saturation of the image data; represents the duration of the video data, represents the frame rate of the video data, represents the code rate of the video data; represents the sampling rate of the audio data, represents the bit depth of the audio data, represents the distortion of the audio data; represents the current time, using the node local time to obtain, while is taken from the time field recorded when the standard transaction is generated.

4. The blockchain multi-modal transaction packaging method of claim 2, wherein, The transaction storage structure in the transaction pool is composed of data type identifier, standardized transaction format, weight value, source node ID and state label; the state label includes to be packaged and packaged.

5. The blockchain multi-modal transaction packaging method of claim 2, wherein, The maintenance strategy of the transaction pool includes the following contents: the transactions need to be sorted according to the weight value, and the transactions that are overdue or invalid are periodically proposed; concurrent reading is supported to provide scheduling for multiple packaging nodes.

6. The blockchain multi-modal transaction packaging method of claim 1, wherein, The packaging node load detection and state publishing mechanism is that each packaging node periodically collects and broadcasts its current running load state, including CPU usage, memory occupancy, network IO, last round packaging time and average transaction processing delay; And the above information is synchronized to all nodes in the entire network through lightweight hash broadcast, and other nodes obtain real-time packaged node load state data accordingly.

7. The blockchain multi-modal transaction packaging method of claim 1, wherein, The capacity priority mode is to package as many transactions as possible with the total transaction size as the upper limit; and the quantity priority mode is to package a fixed number of transactions, thereby guaranteeing the response delay of high-frequency low-load services.

Images