A wine warehouse blockchain service system and data processing method based on a hierarchical elastic scaling architecture

Abstract

This invention relates to the field of blockchain data processing technology, and particularly to a wine warehouse blockchain service system and data processing method based on a layered elastic scaling architecture. The method includes: constructing a layered elastic scaling architecture based on wine warehouse blockchain service demand information; establishing an elastic scaling pool containing blockchain nodes and IoT gateways; performing data conversion on the wine warehouse on-chain data obtained from the device access layer; preprocessing the converted wine warehouse on-chain data; generating a storage contract matching the data blocks to be uploaded to the blockchain based on a pluggable smart contract template library, and verifying the identity of the corresponding node roles in the data blocks to be uploaded; performing transaction verification analysis on the data blocks to be uploaded to the blockchain, and uploading the data blocks that meet the preset transaction verification analysis conditions to the blockchain. This invention achieves distributed data storage and elastic scaling through blockchain, efficiently integrating multi-source heterogeneous data in the wine warehouse, and significantly improving the efficiency of uploading high-frequency data from the wine warehouse to the blockchain.

Description

Technical Field

[0001] This invention relates to the field of blockchain data processing technology, and in particular to a wine cellar blockchain service system and data processing method based on a layered elastic scaling architecture. Background Technology

[0002] Against the backdrop of accelerated digital transformation in the wine industry, digital wine warehouse management systems have become a core hub connecting the entire chain of production, quality inspection, distribution, and blending. Currently, the system utilizes tools such as IoT sensors and ERP software to achieve basic functions such as traceability of brewing raw materials, monitoring of the fermentation process, analysis of wine components, warehouse inventory management, and optimization of distribution routes, significantly improving industry operational efficiency. For example, in the production stage, key indicators such as fermentation temperature and humidity can be monitored in real time; in the quality inspection stage, standardized test reports are generated based on technologies such as spectral analysis; and in the distribution stage, the logistics management module tracks the transportation trajectory of the wine.

[0003] However, with the expansion of the wine market and the increasing complexity of the supply chain, digital wine warehouse management systems are gradually revealing deep-seated technical bottlenecks, especially when integrated with blockchain technology. On the one hand, the challenge of integrating multi-source, heterogeneous data stems from the fragmentation of the data ecosystem. Wine warehouse data encompasses IoT device logs from the production end (such as sensor data from fermentation tanks), laboratory analysis reports from the quality inspection end (such as alcohol concentration and ester content), logistics GPS tracks and order data from the distribution end, and confidential formula parameters from the blending process. This data comes from different entities such as industrial equipment, testing instruments, and third-party logistics systems, exhibiting both structured (such as numerical test results) and unstructured (such as formula documents and image-based quality inspection reports) data. Furthermore, data standards at each stage are independently set by enterprises, lacking unified industry standards, leading to incompatible data formats and semantic incompatibility, making it difficult for traditional centralized databases to achieve efficient association and integration. On the other hand, the root cause of the insufficient adaptability of blockchain technology lies in the limitations of its underlying architecture. Blockchain's distributed evidence storage relies on node consensus mechanisms. However, high-frequency data from wine cellars (such as real-time inventory changes and logistics node updates) needs to be uploaded to the chain within seconds. Existing mainstream blockchain consensus algorithms (Proof-of-Work (PoW) and Proof-of-Stake (PoS)) suffer from low transaction throughput (only a few dozen transactions per second) and long confirmation delays, making it difficult to handle the real-time writing requirements of high-frequency data. Furthermore, elastic scaling is limited by the rigid architecture of blockchain: adding or removing nodes in traditional blockchain networks requires a complex consensus process, making it impossible to dynamically adjust storage and computing resources according to peak and off-peak periods in wine cellar operations (such as a surge in data volume due to a surge in orders during peak seasons). When the data volume exceeds a preset threshold, on-chain storage congestion can easily occur, further reducing on-chain efficiency.

[0004] Chinese Patent Publication No. CN114091858A discloses a wine management method and system based on blockchain technology. The system includes a central server, with connected terminals for a production line module, a detection module, a goods allocation module, and a distribution module. The detection module includes a production status detection unit, an inventory expiration detection unit, and a goods accumulation detection unit. The goods allocation module includes a regional allocation unit and a storage warning unit. The distribution module includes a reservation unit for existing customers and a reservation unit for new customers. While this solution can achieve wine production supervision, quality inspection, distribution, and allocation, it cannot achieve distributed data storage and elastic expansion through blockchain. It also struggles to efficiently integrate multi-source heterogeneous data from wine warehouses, resulting in reduced efficiency in uploading high-frequency data from wine warehouses to the blockchain. Summary of the Invention

[0005] To address this, the present invention provides a wine cellar blockchain service system and data processing method based on a hierarchical elastic scaling architecture, in order to overcome the problems in the prior art where distributed data storage and elastic scaling cannot be achieved through blockchain, and it is difficult to efficiently integrate multi-source heterogeneous data in the wine cellar, resulting in reduced efficiency of uploading high-frequency data from the wine cellar to the blockchain.

[0006] To achieve the above objectives, this invention provides a data processing method for a wine warehouse blockchain service based on a layered elastic scaling architecture, comprising the following steps:

[0007] S1. Construct a layered elastic scaling architecture based on the blockchain service demand information of the wine cellar. The layered elastic scaling architecture includes an infrastructure layer and a core engine layer. The core engine layer includes a device access layer, a data processing layer, and a blockchain service layer.

[0008] S2. Deploy a Docker containerized cluster based on the infrastructure layer, and establish an elastic expansion pool containing blockchain nodes and IoT gateways through a preset dynamic resource allocation mechanism and the Docker containerized cluster.

[0009] S3. Based on the protocol conversion rules in the elastic expansion pool and the device access layer, the wine warehouse on-chain data obtained by the device access layer is converted to obtain the wine warehouse on-chain data after data conversion.

[0010] S4. According to the preset data processing rules, the wine warehouse data after data conversion is preprocessed in the data processing layer to obtain a preprocessed dataset that conforms to the message middleware transmission mechanism. The preprocessed dataset is then sent to the blockchain service layer through the message middleware to obtain the data block to be uploaded to the chain.

[0011] S5. Generate a notarization contract that matches the data block to be uploaded to the blockchain based on the pluggable smart contract template library, and verify the identity of the corresponding node role in the data block to be uploaded to the blockchain according to the notarization contract and the dynamic alliance mechanism, and add the node role that meets the preset identity verification conditions to the blockchain service network to obtain the dynamic alliance network.

[0012] S6. Through a layered consensus mechanism and a dynamic alliance network, transaction verification and analysis are performed on the data blocks to be added to the chain, and the data blocks that meet the preset transaction verification and analysis conditions are added to the chain.

[0013] Compared with the prior art, the beneficial effects of this application are as follows:

[0014] 1. This application constructs a layered elastic scaling architecture comprising an infrastructure layer and a core engine layer, and establishes an elastic scaling pool based on a Docker containerized cluster and a preset dynamic resource allocation mechanism. It integrates blockchain nodes and IoT gateways into dynamically scaling resources. Compared to existing technologies that rely on centralized management by a central server, this application breaks through the limitations of fixed resource allocation in traditional systems. It can dynamically adjust computing resources according to the data traffic of the wine warehouse, automatically expanding resources when data is uploaded to the chain at high frequency and shrinking resources when traffic is low. This not only ensures the reliability of blockchain distributed evidence storage, but also solves the problem of insufficient scalability caused by fixed resources in existing technologies through the elastic scaling mechanism. It achieves synergistic optimization of distributed evidence storage and elastic scaling, and improves the system's ability to process high-frequency data from the wine warehouse.

[0015] 2. This application sets protocol conversion rules at the device access layer, which can uniformly convert device data with different protocols in the wine cellar. At the same time, the converted data is preprocessed by the preset data processing rules of the data processing layer. After the data processing layer completes the preprocessing, it can send the preprocessed dataset to the message middleware and continue to process other tasks without blocking and waiting for the blockchain service layer to finish processing the data. This avoids the long-term blocking that may occur in synchronous communication, improves the system's concurrent processing capability and resource utilization, and thus achieves efficient data transmission. Compared with the existing technology that simply collects statistics through a central server, this application can achieve full-process standardization from data collection to preprocessing, ensuring that multi-source heterogeneous data has uniformity and usability before entering the blockchain, avoiding on-chain delays or errors caused by chaotic data formats, and significantly improving the efficiency of high-frequency data integration and on-chain processing in the wine cellar.

[0016] 3. This application generates a notarized contract based on a pluggable smart contract template library and verifies the identity of node roles through a dynamic alliance mechanism, allowing only qualified nodes to join the blockchain service network, reducing the participation of irrelevant nodes. At the same time, it adopts a layered consensus mechanism to verify and analyze transactions. Compared with the existing technology that lacks a blockchain architecture and has low data upload efficiency, this application can reduce the computation and communication overhead of the consensus process by dynamically screening effective nodes and selecting consensus algorithms in a layered manner, enabling high-frequency data from the wine warehouse to quickly complete transaction verification and upload to the blockchain.

[0017] Furthermore, S1 includes the following steps:

[0018] S11. Based on the blockchain service requirements of the wine cellar, analyze the storage capacity, the scale of IoT device access and the dynamic expansion requirements of blockchain nodes, and determine the hardware resource allocation strategy of the infrastructure layer and the functional module division scheme of the core engine layer.

[0019] S12. Based on the hardware resource allocation strategy and functional module division scheme, determine the resource call interface between the infrastructure layer and the core engine layer, as well as the data interaction interface between the device access layer, data processing layer and blockchain service layer within the core engine layer.

[0020] S13. Through the resource call interface and data interaction interface, establish a dynamic resource allocation and data flow mechanism between layers to form a layered elastic expansion architecture.

[0021] In this solution, storage capacity refers to the space required to store data in the wine cellar blockchain service; IoT device access scale refers to the number of IoT devices that can access the wine cellar blockchain service system. For example, there are various IoT devices such as temperature sensors, humidity sensors, and cameras in the wine cellar, and the access scale is the upper limit of the total number of these devices; dynamic expansion requirement of blockchain nodes refers to the need to add or remove blockchain nodes as the wine cellar business develops to meet the requirements of system performance, reliability, etc. For example, when the business volume increases, nodes need to be added to improve processing capacity, and when the business volume decreases, nodes can be reduced to reduce costs; hardware resource allocation strategy refers to the strategy for allocating hardware resources in the infrastructure layer based on storage capacity, IoT device access scale, and dynamic expansion requirement of blockchain nodes; functional module division scheme refers to the scheme of dividing the core engine layer into different functional modules, each module undertaking a specific function; dynamic resource allocation and data flow mechanism refers to the mechanism of dynamically allocating hardware resources between layers according to actual needs through resource call interfaces and data interaction interfaces, and realizing the orderly flow of data between different layers.

[0022] By analyzing storage capacity requirements based on the blockchain service demand information of the wine cellar, the allocation of hardware storage resources can be determined. Analyzing the scale of IoT device access based on the same information allows for the allocation of hardware computing and communication resources. Furthermore, analyzing the dynamic expansion requirements of blockchain nodes reveals the reservation and scalability of hardware resources. This leads to the determination of hardware resource allocation strategies and functional module partitioning schemes, as well as the identification of resource call interfaces and data interaction interfaces. Ultimately, a dynamic resource allocation and data flow mechanism is established, forming a layered, elastic expansion architecture. This architecture allows for flexible allocation of hardware resources based on storage capacity, IoT device access scale, and the dynamic expansion requirements of blockchain nodes, enabling efficient collaboration among functional modules at each layer. It facilitates rapid and accurate data flow between different layers, effectively improving system performance, reliability, and scalability, and meeting the ever-changing needs of the wine cellar business.

[0023] Furthermore, S2 includes the following steps:

[0024] S21. Quantitatively evaluate the computing resources, storage resources and network resources of the infrastructure layer to obtain a resource evaluation parameter set, and configure the runtime environment parameters of the Docker containerized cluster based on the resource evaluation parameter set to obtain the configured Docker runtime environment.

[0025] S22. Based on the resource threshold parameters in the configured Docker runtime environment, determine the initial number and type distribution of container instances for blockchain nodes and IoT gateways, and deploy container instances in the configured Docker runtime environment according to the initial number and type distribution of container instances to form an initial Docker containerized cluster.

[0026] S23. Based on the load threshold algorithm in the preset dynamic resource allocation mechanism, the node load parameters of the initial Docker containerized cluster are monitored in real time, a resource demand prediction model is generated, and the dynamic scaling triggering conditions of the container instance are set according to the resource demand prediction model, and the resource scaling rule set is determined based on the dynamic scaling triggering conditions.

[0027] S24. Based on the resource scaling rule set, elastically scale the container instances in the initial Docker containerized cluster to form an elastic scaling pool containing dynamically adjustable blockchain node containers and IoT gateway containers.

[0028] In this solution, a Docker containerized cluster refers to a system collection that organizes multiple Docker containers together to collaboratively complete specific tasks. For example, in the wine warehouse blockchain service scenario, multiple Docker containers carrying blockchain nodes and IoT gateway functions are integrated. The Docker containerized cluster shares infrastructure and resources, enabling more efficient processing of wine warehouse data interaction, blockchain transactions, and other businesses, achieving centralized management and flexible scheduling of resources. Resource threshold parameters refer to the upper limits set for various resources in the configured Docker runtime environment. The preset dynamic resource allocation mechanism refers to a pre-defined rule system that dynamically adjusts resource allocation based on the real-time status of the system. The load threshold algorithm refers to a calculation method used to determine whether the node load has reached the level that needs adjustment. For example, when the average CPU utilization of a blockchain node container continuously exceeds 70% for a period of time, it is determined that the load is too high. The resource demand prediction model refers to a model that predicts the resource demand for a future period of time based on real-time monitoring data of node load parameters. The dynamic scaling trigger condition refers to the conditions set according to the resource demand prediction model that trigger the addition or removal of container instances. The resource scaling rule set refers to the specific rules that specify how to add or remove container instances when the dynamic scaling trigger condition is met.

[0029] By quantitatively evaluating infrastructure layer resources to obtain a set of resource evaluation parameters, a suitable Docker runtime environment is configured to lay the foundation for subsequent operations. Initial container instances are determined based on resource threshold parameters to form an initial cluster. The load threshold algorithm in the preset dynamic resource allocation mechanism is used to monitor node load in real time, generate a resource demand prediction model, and set dynamic scaling trigger conditions and resource scaling rule sets. Ultimately, dynamic scaling of container instances is achieved, enabling the Docker containerized cluster in the wine warehouse blockchain service to flexibly adjust resources according to actual load and improve resource utilization.

[0030] Furthermore, S3 includes the following steps:

[0031] S31. Based on the general IoT protocol conversion module in the device access layer, determine the communication protocol that is compatible with the external monitoring device, and collect raw multi-source heterogeneous data from the external monitoring device according to the communication protocol, and input the raw multi-source heterogeneous data into the elastic expansion pool. The raw multi-source heterogeneous data includes wine cellar environmental data and monitoring data of the digital wine cellar integrated management system.

[0032] S32. The original multi-source heterogeneous data is converted using the protocol conversion rules in the device access layer to obtain the converted wine warehouse on-chain data.

[0033] In this scheme, the protocol conversion rule refers to the rule used to convert data from one communication protocol to data from another communication protocol.

[0034] By using a general IoT protocol conversion module at the device access layer to determine the compatible communication protocol, it can smoothly collect raw multi-source heterogeneous data from external monitoring devices and input it into the elastic expansion pool. Then, according to the protocol conversion rules, the raw multi-source heterogeneous data is converted so that the data can adapt to different protocol requirements, ensuring the compatibility and interoperability of data between different systems and devices.

[0035] Furthermore, S4 includes the following steps:

[0036] S41. In the data processing layer, the wine warehouse on-chain data after data conversion is preprocessed based on preset data processing rules, and a preprocessed dataset conforming to the message middleware transmission mechanism is output. The preset data processing rules include data field mapping rules, outlier filtering thresholds, and data format conversion protocols. According to the data field mapping rules, the original fields in the wine warehouse on-chain data after data conversion are mapped and adjusted with the target fields in the blockchain to obtain mapped data. According to the outlier filtering thresholds, the mapped data is range-detected to filter out outliers that exceed the preset data range to obtain filtered data. According to the data format conversion protocol, the filtered data is converted into a data format conforming to the message middleware transmission mechanism.

[0037] S42. The preprocessed dataset is sent to the data receiving port of the blockchain service layer through the message middleware, and the blockchain service layer performs transaction verification, timestamp appending and Merkel tree node calculation on the preprocessed dataset to generate a data block to be added to the chain containing a data hash value pointer and a reference to the previous block.

[0038] In this solution, the preset data processing rules refer to the criteria pre-defined at the data processing layer for processing the converted wine warehouse data on the blockchain. These include data field mapping rules, which define the correspondence between fields in different data sources, such as mapping the temperature field collected by external devices to a uniformly defined temperature field within the system; outlier filtering thresholds, which set standards for judging whether data is abnormal, such as judging temperature data as abnormal if it exceeds the normal storage temperature range by a certain percentage; data format conversion protocols, which specify the requirements for converting data to a specific format, such as uniformly converting date data to the "YYYY-MM-DD" format; and message middleware transmission mechanisms, which are mechanisms that convert filtered data into data that can be recognized, transmitted, and communicated by message middleware according to the data format conversion protocols. The target field in the blockchain refers to the standard field defined within the blockchain system for storing and processing data. The preset data range refers to a range of data values ​​defined by the outlier filtering threshold. The data hash value pointer refers to the unique identifier value obtained after hashing the data in the data block to be added to the blockchain. The previous block reference refers to recording information such as the hash value of the previous block when generating a new data block to be added to the blockchain.

[0039] By preprocessing the wine warehouse data on the blockchain according to preset data processing rules at the data processing layer, the data format can be unified, outliers can be filtered, and data quality can be improved. The preprocessed dataset is accurately sent to the blockchain service layer using message middleware, ensuring the stability and timeliness of data transmission. The blockchain service layer performs transaction verification, adds timestamps, and calculates Merkel tree nodes on the preprocessed dataset to generate a data block to be uploaded to the blockchain containing data hash pointers and references to previous blocks, ensuring the immutability and traceability of the data.

[0040] Furthermore, S5 includes the following steps:

[0041] S51. Perform structured parsing on the data block to be uploaded to the chain to obtain a set of feature parameters. Input the set of feature parameters into the pluggable smart contract template library for analysis and generate a notarization contract that matches the data block to be uploaded to the chain.

[0042] S52. Parse the evidence storage contract to obtain the evidence storage contract parsing result, and determine the various identity verification dimensions of the node roles in the dynamic alliance mechanism and the weight allocation rules corresponding to each identity verification dimension based on the evidence storage contract parsing result.

[0043] S53. Perform structured parsing on the data block to be uploaded to the chain to obtain the corresponding node role information, wherein the node role information includes the attribute values ​​corresponding to each node role in each identity verification dimension in the dynamic alliance mechanism.

[0044] S54. Obtain the attribute values ​​corresponding to each authentication dimension in the node role information, map the attribute values ​​corresponding to each authentication dimension to a preset value range, obtain the standardized attribute values ​​corresponding to each authentication dimension, and determine the weight coefficient of each authentication dimension according to the weight allocation rules.

[0045] S55. Calculate the overall identity verification score S for the node role based on the standardized attribute values ​​corresponding to each identity verification dimension and the weighting coefficients of each identity verification dimension. The mathematical expression for the overall identity verification score S is: In the formula, n represents the number of authentication dimensions obtained. This represents the standardized attribute value of the i-th authentication dimension. , This represents the weight coefficient of the i-th authentication dimension. , ;

[0046] S56. The overall identity verification score S is compared with the preset overall identity verification score threshold S0. Based on the comparison result, the identity verification status of each node role is judged, and a dynamic alliance network is obtained based on the judgment result, wherein:

[0047] When S≥S0, the identity verification status of the node role is determined to be satisfactory, and the node role whose identity verification status is deemed satisfactory is added to the dynamic alliance network.

[0048] When S < S0, the authentication status of the node role is determined to be unqualified, and the authentication status of the node role that is determined to be unqualified is re-authenticated until S ≥ S0.

[0049] In this solution, the pluggable smart contract template library refers to a collection of smart contract templates of various types. The evidence storage contract refers to a contract generated by the pluggable smart contract template library after analyzing the data block to be uploaded to the chain, used to record and prove the relevant information of the data block to be uploaded to the chain. The dynamic alliance mechanism refers to a mechanism that specifies the identity verification dimensions of node roles in the alliance and the weight allocation rules corresponding to each dimension. The preset numerical range refers to a pre-set numerical range for standardizing the attribute values ​​corresponding to each identity verification dimension of the node role. For example, the attribute values ​​are mapped to the range of 0-1. The preset identity verification comprehensive score threshold S0 refers to the standard value used to judge whether the identity verification of the node role meets the standard, such as 85.

[0050] Through a pluggable smart contract template library, matching evidence storage contracts can be quickly generated for data blocks to be uploaded to the blockchain, improving the efficiency and accuracy of contract generation. The evidence storage contracts provide clear rules for data evidence storage, and the dynamic alliance mechanism clarifies the dimensions and weight rules for node role identity verification, making verification more scientific and reasonable. By pre-setting numerical ranges, attribute values ​​are standardized for easy calculation, and the preset comprehensive identity verification score threshold can accurately determine the identity verification status of node roles. Qualified nodes are added to the dynamic alliance network, while unqualified nodes are re-verified, ensuring the reliability and security of node identities in the dynamic alliance network and ensuring the efficiency and stability of data evidence storage and alliance network operation in the wine storage blockchain service.

[0051] Furthermore, S6 includes the following steps:

[0052] S61. Through the basic layer consensus nodes in the hierarchical consensus mechanism, the format standardization and digital signature validity of the data block to be uploaded to the chain are initially verified, and the first verification result is generated.

[0053] S62. Based on the role and permission rules in the dynamic alliance network and the business relevance of the node role identity in the first verification result, a second verification result is generated. The role and permission rules include the business participation scope and operation permissions of the node role in the dynamic alliance network.

[0054] S63. Through the application layer consensus node in the hierarchical consensus mechanism, combined with the second verification result and the real-time node status of the dynamic alliance network, the final transaction verification of the data block to be uploaded to the chain is performed. When the preset transaction verification analysis conditions are met, the data block to be uploaded to the chain structure of the blockchain service layer is added to the chain structure of the blockchain service layer.

[0055] In this scheme, the role permission rules refer to the rules that define the scope of business participation and operation permissions of node roles in the dynamic alliance network. The preset transaction verification analysis conditions refer to the pre-set conditions used to determine whether the data block to be uploaded to the chain meets the final transaction verification requirements, including data block format specifications, valid digital signature, correct business relevance, and compliant node role permissions.

[0056] Through the basic consensus nodes in the layered consensus mechanism, the format specifications and digital signature validity of the data blocks to be uploaded to the chain are initially verified. This quickly filters out data blocks that obviously do not meet the requirements, improving verification efficiency. Secondary verification is performed based on role and permission rules and the first verification result, which ensures the accuracy of the business relevance of the data blocks and prevents invalid or erroneous business data from entering the blockchain. Finally, the application layer consensus nodes, combined with the second verification result and the real-time node status of the dynamic alliance network, perform final transaction verification. Based on preset transaction verification analysis conditions, it is determined whether to add the data block to the chain structure, ensuring the authenticity, integrity, and business compliance of the data on the blockchain. By utilizing the layered consensus mechanism and role and permission rules, the data upload process is rigorous and orderly, significantly improving the efficiency of high-frequency data integration and upload to the chain.

[0057] Furthermore, S63 includes the following steps:

[0058] S631. By performing correlation analysis between the second verification result and the real-time node status of the dynamic alliance network through the application layer consensus node, a set of verification input information is obtained.

[0059] S632. Based on the verification input information set, perform final transaction verification on the consistency of transaction logic of the data block to be uploaded to the chain, the matching of node permissions and real-time node status, and generate verification conclusions.

[0060] S633. Compare the verification conclusion with the preset transaction verification analysis conditions, and add the data blocks to be uploaded to the blockchain service layer that meet the preset transaction verification analysis conditions to the chain structure of the blockchain service layer using the Merkle tree algorithm.

[0061] In this scheme, the verification input information set is obtained by analyzing the second verification result of the application layer consensus node association and the real-time node status of the dynamic alliance network. This comprehensively considers various factors required for data transaction verification. Based on this verification input information set, the final transaction verification is carried out to ensure that the transaction logic is consistent and the node permissions match the real-time status. After comparing the verification conclusion with the preset transaction verification analysis conditions, the Merkle tree algorithm is used to add the data blocks that meet the preset transaction verification analysis conditions to the chain structure. This can ensure the authenticity and reliability of the data in the blockchain service layer chain structure and significantly improve the data on-chain efficiency of the wine warehouse blockchain.

[0062] This invention also provides a wine warehouse blockchain service system based on a layered, elastically scalable architecture, comprising:

[0063] A layered elastic scaling architecture construction module is used to build a layered elastic scaling architecture based on the service demand information of the wine cellar blockchain. The layered elastic scaling architecture includes an infrastructure layer and a core engine layer. The core engine layer includes a device access layer, a data processing layer, and a blockchain service layer.

[0064] The elastic expansion pool creation module is used to deploy Docker containerized clusters based on the infrastructure layer, and to create an elastic expansion pool containing blockchain nodes and IoT gateways through a preset dynamic resource allocation mechanism and Docker containerized clusters.

[0065] The data conversion module is used to convert the wine warehouse on-chain data obtained from the device access layer based on the protocol conversion rules in the elastic expansion pool and the device access layer, so as to obtain the wine warehouse on-chain data after data conversion.

[0066] The data sending module is used to preprocess the wine warehouse data after data conversion in the data processing layer according to the preset data processing rules, to obtain a preprocessed dataset that conforms to the message middleware transmission mechanism, and to send the preprocessed dataset to the blockchain service layer through the message middleware to obtain the data block to be uploaded to the chain.

[0067] The dynamic alliance network construction module is used to generate a notarization contract that matches the data block to be uploaded to the blockchain based on the pluggable smart contract template library, and to verify the identity of the corresponding node role in the data block to be uploaded to the blockchain according to the notarization contract and the dynamic alliance mechanism, and to add the node role that meets the preset identity verification conditions to the blockchain service network to obtain the dynamic alliance network.

[0068] The data upload module is used to perform transaction verification and analysis on the data blocks to be uploaded to the blockchain through a layered consensus mechanism and a dynamic consortium network, and to upload the data blocks to the blockchain that meet the preset transaction verification and analysis conditions. Attached Figure Description

[0069] Figure 1This is a flowchart illustrating the data processing method for a wine warehouse blockchain service based on a layered elastic scaling architecture, according to an embodiment of the present invention.

[0070] Figure 2 This is a schematic diagram of the structure of the wine warehouse blockchain service system based on a layered elastic scaling architecture, according to an embodiment of the present invention. Detailed Implementation

[0071] The following detailed description illustrates the specific implementation method:

[0072] Please see Figure 1 The diagram shown is a flowchart illustrating the data processing method for a wine warehouse blockchain service based on a layered elastic scaling architecture according to an embodiment of the present invention, including the following steps:

[0073] S1. Based on the blockchain service demand information of the wine cellar, a layered elastic scaling architecture is constructed. The layered elastic scaling architecture includes an infrastructure layer and a core engine layer. The core engine layer includes a device access layer, a data processing layer, and a blockchain service layer.

[0074] S2. Deploy a Docker containerized cluster based on the infrastructure layer, and establish an elastic expansion pool containing blockchain nodes and IoT gateways through a preset dynamic resource allocation mechanism and the Docker containerized cluster.

[0075] S3. Based on the protocol conversion rules in the elastic expansion pool and the device access layer, the wine warehouse on-chain data obtained by the device access layer is converted to obtain the wine warehouse on-chain data after data conversion.

[0076] S4. According to the preset data processing rules, the wine warehouse data after data conversion is preprocessed in the data processing layer to obtain a preprocessed dataset that conforms to the message middleware transmission mechanism. The preprocessed dataset is then sent to the blockchain service layer through the message middleware to obtain the data block to be uploaded to the chain.

[0077] S5. Generate a notarization contract that matches the data block to be uploaded to the blockchain based on the pluggable smart contract template library, and verify the identity of the corresponding node role in the data block to be uploaded to the blockchain according to the notarization contract and the dynamic alliance mechanism, and add the node role that meets the preset identity verification conditions to the blockchain service network to obtain the dynamic alliance network.

[0078] S6. Through a layered consensus mechanism and a dynamic alliance network, transaction verification and analysis are performed on the data blocks to be added to the chain, and the data blocks that meet the preset transaction verification and analysis conditions are added to the chain.

[0079] Specifically, S1 includes the following steps:

[0080] S11. Based on the blockchain service requirements of the wine cellar, analyze the storage capacity, the scale of IoT device access and the dynamic expansion requirements of blockchain nodes, and determine the hardware resource allocation strategy of the infrastructure layer and the functional module division scheme of the core engine layer.

[0081] S12. Based on the hardware resource allocation strategy and functional module division scheme, determine the resource call interface between the infrastructure layer and the core engine layer, as well as the data interaction interface between the device access layer, data processing layer and blockchain service layer within the core engine layer.

[0082] S13. Establish a dynamic resource allocation and data flow mechanism between layers through resource call interfaces and data interaction interfaces to form a layered elastic scaling architecture.

[0083] In this embodiment, the following in-depth analysis of the blockchain service requirements for the wine cellar is conducted: Storage capacity requirements: By analyzing historical data growth trends (such as wine cellar temperature and humidity records, blockchain transaction volume) and future business plans, the initial storage scale and expansion threshold (such as a storage expansion strategy for a 20% quarterly growth) are determined. IoT device access scale: The number of current sensors, smart locks, and other devices is counted, and combined with the wine cellar distribution density (such as 5 devices deployed per 100 square meters), the maximum concurrent access volume and peak load (such as 1000 devices simultaneously uploading data in a single area) are calculated. Blockchain node dynamic expansion requirements: Based on the transaction frequency (such as 10 orders uploaded per second) and the performance requirements of the consensus mechanism (such as PoA or PBFT), the linear relationship between the number of nodes and hardware resources is determined (such as the need to allocate an additional 2 CPU cores and 4GB of memory for each additional node).

[0084] Based on the requirements analysis, a containerized resource pooling technology (such as Kubernetes) is adopted to build the infrastructure layer. Physical servers are divided into compute resource pools, storage resource pools, and network resource pools, and virtualization technology (such as OpenStack) is used to achieve dynamic resource allocation. When the storage capacity utilization rate exceeds 80%, expansion is automatically triggered, or when the device access request queue length exceeds a threshold, container instances are added.

[0085] Based on requirements, the core engine layer is broken down into three logical layers: Device Access Layer: An MQTT protocol gateway is used to handle IoT device connections, supporting breakpoint resumption and device authentication (e.g., X.509 certificates), and a message queue (e.g., Kafka) is designed to buffer high-concurrency data. Data Processing Layer: A stream processing engine (e.g., Flink) is deployed to clean, aggregate, and detect anomalies in raw data, while a data cache (e.g., Redis) is set up to reduce blockchain write latency. Blockchain Service Layer: A modular blockchain framework (e.g., Hyperledger Fabric) is selected to decouple consensus, ledger, and smart contracts, supporting the dynamic addition of sorting nodes or peer nodes.

[0086] Infrastructure Layer and Core Engine Layer Interfaces: Define RESTful APIs or gRPC interfaces for the core engine layer to request computing resources on demand (e.g., calling the ` / api / v1 / scale` interface to increase the number of container replicas). Core Engine Layer Internal Interfaces: Device Access Layer → Data Processing Layer: Asynchronously transmits device data via Kafka topics, supporting horizontal scaling of consumer groups. Data Processing Layer → Blockchain Service Layer: Adopts an event-driven architecture, encapsulating processed data into blockchain transactions for submission using a publish / subscribe pattern (such as NATS).

[0087] Deploy a monitoring agent (such as Prometheus) at the infrastructure layer to collect metrics such as CPU, memory, and disk I / O in real time, and trigger automatic scaling based on preset rules (such as when memory usage is >70% for 5 minutes). The core engine layer implements traffic management through a service mesh (such as Istio), for example, when the data processing layer is overloaded, automatically route some requests to newly added stream processing instances.

[0088] Data flow optimization includes: Device access layer: Implementing device heartbeat detection and connection pool management to ensure the stability of long-term connections for millions of devices. Data processing layer: Employing backpressure mechanisms (such as Kafka's max.poll.records parameter) to prevent data backlog, while using Bloom filters to remove duplicate and redundant data. Blockchain service layer: Designing a batch on-chain strategy to merge multiple transactions within one second into a single block proposal, improving throughput.

[0089] Establish a feedback control loop: When the performance of the blockchain service layer degrades (e.g., block confirmation delay > 2 seconds), request additional node resources from the infrastructure layer via an interface, and simultaneously notify the data processing layer to reduce the frequency of non-critical data being uploaded to the chain. Introduce chaos engineering testing: Simulate peak device access or node failures to verify the architecture's self-healing capabilities (e.g., automatically migrating data from failed nodes to new nodes).

[0090] Specifically, S2 includes the following steps:

[0091] S21. Quantitatively evaluate the computing resources, storage resources and network resources of the infrastructure layer to obtain a resource evaluation parameter set, and configure the runtime environment parameters of the Docker containerized cluster based on the resource evaluation parameter set to obtain the configured Docker runtime environment.

[0092] S22. Based on the resource threshold parameters in the configured Docker runtime environment, determine the initial number and type distribution of container instances for blockchain nodes and IoT gateways, and deploy container instances in the configured Docker runtime environment according to the initial number and type distribution of container instances to form an initial Docker containerized cluster.

[0093] S23. Based on the load threshold algorithm in the preset dynamic resource allocation mechanism, the node load parameters of the initial Docker containerized cluster are monitored in real time, a resource demand prediction model is generated, and the dynamic scaling triggering conditions of container instances are set according to the resource demand prediction model. Based on the dynamic scaling triggering conditions, the resource scaling rule set is determined.

[0094] S24. Based on the resource scaling rule set, elastically scale the container instances in the initial Docker containerized cluster to form an elastic scaling pool containing dynamically adjustable blockchain node containers and IoT gateway containers.

[0095] In this embodiment, infrastructure layer resource quantification and Docker environment configuration include establishing a three-dimensional resource evaluation model encompassing computing (number of CPU cores, clock speed, vector instruction set), storage (IOPS, throughput, latency), and network (bandwidth, packet loss rate, number of connections). By collecting hardware specifications, benchmark data, and historical load characteristics, a weighted scoring algorithm is used to generate a comprehensive resource evaluation parameter set, with computing resources accounting for 45%, storage for 30%, and network for 25%. A Docker Swarm cluster configuration template is constructed based on this resource evaluation parameter set. An adaptive parameter mapping algorithm is used to convert physical resource parameters into container runtime environment parameters: a dedicated CPU core binding strategy is allocated to compute-intensive nodes, local volume mount parameters are configured for storage-intensive nodes, and host network mode is enabled for network-intensive nodes. Dynamic parameter configuration is achieved through an environment variable injection mechanism, forming a differentiated runtime environment that includes resource limits, reserved values, and QoS policies.

[0096] The initial cluster deployment and node distribution include establishing a resource threshold parameter matrix, encompassing key metrics such as CPU utilization (80%), memory usage (75%), and disk I / O (90%). A mixed-integer programming algorithm is employed, combining the resource requirements of blockchain nodes (consensus nodes, full nodes, and light nodes) and IoT gateways (edge ​​gateways and fog gateways) to determine the initial CPU / memory ratio of container instances (e.g., consensus nodes configured at 2:8, and edge gateways at 1:4). A two-layer deployment architecture is designed, with the bottom layer using the Kubernetes scheduler for basic resource allocation, and the upper layer using a custom controller for business logic orchestration. Based on the node type distribution strategy, statefulsets (blockchain nodes) and deployments (IoT gateways) are created in the configured Docker environment. Affinity rules ensure that blockchain consensus nodes are deployed across fault domains, and IoT gateways are deployed in geographically partitioned areas.

[0097] A monitoring system was constructed, incorporating the Prometheus time-series database, the Telegraf data collector, and the Grafana visualization panel. Node load parameters collected included: transaction processing rate and block synchronization latency of blockchain nodes, and device connection count and message throughput of IoT gateways. A sliding window algorithm was used to calculate load indices for 1 minute, 5 minutes, and 15 minutes. A two-stage resource demand prediction model was built based on the monitoring data. The first stage used the Seasonal Decomposition (STL) algorithm to identify load cycle patterns, and the second stage applied an LSTM neural network for trend prediction. Cross-validation was used to determine the optimal parameter combination (time window = 30 periods, number of hidden layers = 2), generating a prediction result set containing resource demand and demand time windows. A three-level dynamic scaling trigger system was designed: a first-level threshold (resource utilization ≥ 85% for 5 minutes) triggers an alert; a second-level threshold (≥ 90% for 2 minutes) initiates the expansion process; and a third-level threshold (≤ 30% for 10 minutes) triggers scaling down. A fuzzy logic algorithm was used to optimize the trigger conditions by integrating secondary indicators such as CPU queue length and memory fragmentation rate. A three-tiered elastic architecture is established, comprising a rapid scaling layer (pre-launched container pool), a standard scaling layer (on-demand building), and an emergency scaling layer (cloud burst). The rapid scaling layer maintains a golden mirror container pool for blockchain nodes and IoT gateways, ensuring 30% pre-launched resources through a health check mechanism. Prefetch resource allocation based on a predictive model is implemented. When the predictive model identifies a 40% increase in resource demand within 30 minutes, the system automatically selects the optimal image from the elastic scaling pool to launch a new instance, prioritizing the reuse of local resource pools. Any excess resources are handled through a hybrid cloud interface that calls public cloud services. An improved ant colony algorithm is used for container rescheduling, comprehensively considering resource utilization (weight 0.4), network latency (0.3), and energy consumption (0.3). Load balancing is performed every 15 minutes, and container migration dynamically converges cluster resource utilization to the target range of 65%-75%. A blockchain node container template library with 10 typical configurations and an IoT gateway template library with 5 configurations are built, supporting dynamic adjustment of consensus algorithm parameters, device protocol stacks, and other configurations through environment variables. The extended pool maintains an automatic cleanup mechanism that reclaims resources from containers that have been idle for more than 24 hours.

[0098] Specifically, S3 includes the following steps:

[0099] S31. Based on the general IoT protocol conversion module in the device access layer, determine the communication protocol that is compatible with the external monitoring device, and collect raw multi-source heterogeneous data from the external monitoring device according to the communication protocol, and input the raw multi-source heterogeneous data into the elastic expansion pool. The raw multi-source heterogeneous data includes wine cellar environmental data and monitoring data of the digital wine cellar integrated management system.

[0100] S32. The original multi-source heterogeneous data is converted using the protocol conversion rules in the device access layer to obtain the converted wine warehouse on-chain data.

[0101] In this embodiment, the external monitoring equipment includes a base liquor warehouse management system. The base liquor storage environment sensor network data collection and analysis module in the base liquor warehouse management system collects wine warehouse environmental data through Internet of Things devices. The wine warehouse environmental data includes ambient temperature data, air humidity data, air alcohol concentration data, and other environmental data information and records them.

[0102] Data transformation of raw multi-source heterogeneous data according to protocol transformation rules includes: dynamically selecting protocol transformation containers based on the container distribution of blockchain nodes and IoT gateways in the elastic expansion pool. If the wine cellar environment data needs to be converted to JSON format supported by Hyperledger Fabric, idle IoT gateway containers are prioritized for transformation. If the digital wine cellar management system data needs to be converted to the MQTT protocol, a container instance with a pre-loaded MQTT protocol stack is selected. Raw multi-source heterogeneous data (such as CSV, binary) is converted into intermediate datasets (such as JSON / XML), and protocol metadata fields are added. Based on the protocol transformation rule library (stored in the configuration storage of the elastic expansion pool), business fields are mapped to semantics understandable by blockchain smart contracts. Frequently used protocol transformation rules (such as Modbus→JSON) are cached locally to reduce inter-container communication overhead. When the elastic expansion pool expands, new containers automatically synchronize cached rules from the master node. If protocol transformation fails (e.g., due to incompatibility with the target protocol version), the elastic expansion pool dynamically adjusts according to the resource scaling rule set: when resources are sufficient, a backup container instance is started to try other protocol paths. When resources are scarce: write data to a local queue and return a portion of the transformation results, marking them as "pending manual processing".

[0103] The on-chain data for wine cellars includes monitoring data from the digital wine cellar integrated management system, as shown in Table 1.

[0104] Table 1 Monitoring Data Table in Base Wine Warehouse Management System

[0105]

[0106] Specifically, S4 includes the following steps:

[0107] S41. In the data processing layer, the wine warehouse on-chain data after data conversion is preprocessed based on preset data processing rules, and a preprocessed dataset conforming to the message middleware transmission mechanism is output. The preset data processing rules include data field mapping rules, outlier filtering thresholds and data format conversion protocols. According to the data field mapping rules, the original fields in the wine warehouse on-chain data after data conversion are matched and adjusted with the target fields in the blockchain to obtain mapped data. According to the outlier filtering thresholds, the mapped data is range-checked to filter out outliers that exceed the preset data range to obtain filtered data. According to the data format conversion protocol, the filtered data is converted into a data format conforming to the message middleware transmission mechanism.

[0108] S42. The preprocessed dataset is sent to the data receiving port of the blockchain service layer through the message middleware, and the blockchain service layer performs transaction verification, timestamp appending and Merkel tree node calculation on the preprocessed dataset to generate a data block to be added to the chain containing a data hash value pointer and a reference to the previous block.

[0109] In this embodiment, when constructing a layered, elastically scalable architecture to process wine warehouse data on the blockchain, the design and coordination of the data processing layer and the blockchain service layer need to be emphasized. The architecture adopts a modular, layered design, with each layer having independent scalability. Through standardized interface interaction, it supports horizontal scaling and fault isolation.

[0110] The data processing layer adopts a microservice architecture, breaking down the preset data processing rules into independent services: based on the data field mapping rules, the original fields in the wine warehouse on-chain data after data transformation are mapped and adjusted to the target fields in the blockchain. For example, the wine warehouse on-chain data uses "origin code" to represent the wine's origin information, while the blockchain target field may specify storing it as "origin name". Therefore, it is necessary to map and convert the "origin code" to the corresponding "origin name" to obtain the mapped data; and then perform range detection on the mapped data according to the outlier filtering threshold. Suppose a data field specifies that its value range should be between 1 and 100. If a value of 150 is detected, this data is determined as an outlier and filtered out, resulting in filtered data. The preset data range is determined based on historical data statistics: analyzing the historical records of wine warehouse on-chain data over a period of time, statistically analyzing the value distribution of each data field. Taking wine sales price as an example, by statistically analyzing wine sales price data over the past year, calculating the average price, standard deviation, and other statistical measures, then determining a reasonable price range based on these statistical measures, such as the average plus or minus 3 times the standard deviation. Prices outside this range are considered outliers. According to the data format conversion protocol, the filtered data is converted into a data format that conforms to the message middleware transmission mechanism. The message middleware requires data to be transmitted in a specific encoding format (such as UTF-8) and a specific data structure (such as JSON or XML format). For example, if the message middleware specifies that data should be transmitted in JSON format, then the filtered data needs to be organized and encapsulated according to the JSON syntax rules, ultimately forming a preprocessed dataset that conforms to the message middleware transmission mechanism. This data processing layer adopts a stateless design and achieves elastic scaling through containerized deployment. Based on Kubernetes' HPA mechanism, it automatically adjusts the number of instances according to traffic.

[0111] The blockchain service layer is designed with a dual-cluster architecture: the verification cluster is responsible for transaction verification and timestamp services, using a load balancer to distribute requests, and verification nodes reach consensus through the Raft protocol; the computing cluster focuses on Merkel tree construction and hash calculation, using a MapReduce architecture to process large-scale data in parallel. The data processing layer and the blockchain service layer are decoupled through a message middleware, and the message queue uses a partitioned replication mechanism to ensure high availability, supporting sequential consumption and transactions.

[0112] The elastic scaling mechanism is achieved through multi-level caching and asynchronous processing: a distributed cache cluster is placed in front of the data processing layer to intercept hot data and reduce processing pressure; the blockchain service layer uses pre-write logging and pre-computation technology to convert time-consuming operations into asynchronous tasks, and introduces an intelligent routing layer to dynamically allocate processing resources based on data characteristics, enabling high-performance processing channels for high-value data. The overall architecture achieves dynamic configuration through service registration and discovery and a configuration center, supporting canary releases and A / B testing to ensure smooth system scaling when data volume surges.

[0113] Specifically, S5 includes the following steps:

[0114] S51. Perform structured parsing on the data block to be uploaded to the chain to obtain a set of feature parameters. Input the set of feature parameters into the pluggable smart contract template library for analysis and generate a notarization contract that matches the data block to be uploaded to the chain.

[0115] S52. Parse the evidence storage contract to obtain the evidence storage contract parsing result, and determine the various identity verification dimensions of the node roles in the dynamic alliance mechanism and the weight allocation rules corresponding to each identity verification dimension based on the evidence storage contract parsing result.

[0116] S53. Perform structured parsing on the data block to be uploaded to the chain to obtain the corresponding node role information. The node role information includes the attribute values ​​of each node role in each identity verification dimension in the dynamic alliance mechanism.

[0117] S54. Obtain the attribute values ​​corresponding to each authentication dimension in the node role information, map the attribute values ​​corresponding to each authentication dimension to a preset value range, obtain the standardized attribute values ​​corresponding to each authentication dimension, and determine the weight coefficient of each authentication dimension according to the weight allocation rules.

[0118] S55. Calculate the overall authentication score S for the node role based on the standardized attribute values ​​corresponding to each authentication dimension and the weighting coefficients of each authentication dimension. The mathematical expression for the overall authentication score S is: In the formula, n represents the number of authentication dimensions obtained. This represents the standardized attribute value of the i-th authentication dimension. , This represents the weight coefficient of the i-th authentication dimension. , ;

[0119] S56. Compare the overall identity verification score S with the preset overall identity verification score threshold S0. Based on the comparison result, determine the identity verification status of each node role, and obtain the dynamic consortium network based on the determination result, wherein:

[0120] When S≥S0, the identity verification status of the node role is determined to be satisfactory, and the node role whose identity verification status is deemed satisfactory is added to the dynamic alliance network.

[0121] When S < S0, the authentication status of the node role is determined to be unqualified, and the authentication status of the node role that is determined to be unqualified is re-authenticated until S ≥ S0.

[0122] Preset numerical ranges are typically determined by combining the characteristics of the identity verification dimension, historical data, and industry experience. If the dimension measures the computing power of a node, a linear transformation is used to map it to a range such as [0,1], referring to the actual capability range. A reasonable range is determined based on the data distribution, referring to the mean and extreme values ​​of historical data statistical attribute values. Industry experience is used to ensure that the range setting conforms to the standards of similar scenarios, guaranteeing data comparability. This unifies the attribute values ​​of each identity verification dimension to a comparable range, facilitating subsequent calculations.

[0123] The determination of the preset identity verification comprehensive score threshold takes into account the alliance's goals, security requirements, historical data, simulation tests, business needs, and expert opinions. High-security alliances are assigned a high threshold, while general alliances can have a lower threshold. The relationship between node scores and performance in historical data is analyzed, and alliance operation under different thresholds is simulated. Based on business requirements for node quality, experts are invited to evaluate and discuss the process to comprehensively determine a reasonable threshold that ensures the alliance's performance, security, and stability.

[0124] Specifically, S6 includes the following steps:

[0125] S61. Through the basic layer consensus nodes in the hierarchical consensus mechanism, the format standardization and digital signature validity of the data block to be uploaded to the chain are initially verified, and the first verification result is generated.

[0126] S62. Based on the role and permission rules in the dynamic alliance network and the node role identity in the first verification result, perform a second verification on the business relevance of the data block to be uploaded to the chain, and generate a second verification result. The role and permission rules include the business participation scope and operation permissions of the node role in the dynamic alliance network.

[0127] S63. Through the application layer consensus node in the hierarchical consensus mechanism, combined with the second verification result and the real-time node status of the dynamic alliance network, the final transaction verification of the data block to be uploaded to the chain is performed. When the preset transaction verification analysis conditions are met, the data block to be uploaded to the chain structure of the blockchain service layer is added to the chain structure of the blockchain service layer.

[0128] Specifically, S63 includes the following steps:

[0129] S631. By performing correlation analysis between the second verification result and the real-time node status of the dynamic alliance network through the application layer consensus node, a set of verification input information is obtained.

[0130] S632. Based on the verification input information set, perform final transaction verification on the consistency of transaction logic of the data block to be uploaded to the chain, the matching of node permissions and real-time node status, and generate verification conclusions.

[0131] S633. Compare the verification conclusion with the preset transaction verification analysis conditions, and add the data blocks to be uploaded to the blockchain service layer that meet the preset transaction verification analysis conditions to the chain structure of the blockchain service layer using the Merkle tree algorithm.

[0132] In this embodiment, when step S6 is implemented, a hierarchical consensus node network is first built, and the basic layer consensus nodes deploy a data format verification module and a signature verification engine. Format compliance verification uses a preset data template library, comparing the field types, lengths, and nesting structures of the data to be uploaded to the chain through field mapping to see if they match. For example, it verifies the UTC format of the timestamp in IoT device data and the 16-bit character rule of the sensor ID. Digital signature verification calls an asymmetric encryption tool, decrypts the data signature with the corresponding public key in the node's public key pool, and then compares it with the hash value of the original data. If they do not match, they are marked as invalid, thereby generating a first verification result containing format compliance and signature validity.

[0133] The secondary verification of the dynamic consortium network relies on role-based permission smart contracts. These contracts pre-store the business boundaries of each role. Combined with the node role identifier from the first verification result, a business tag matching algorithm checks whether the business type tag of the data to be uploaded to the chain is within the role's permission list. If they don't match, the business is deemed irrelevant, generating a second verification result containing business relevance. The application-layer consensus node integrates a real-time node status monitoring module, capturing real-time status data such as node online time, transaction response speed over the past 30 minutes, and historical error rate. The second verification result is fused with this status data through an association model, forming a verification input information set including dimensions such as business matching degree and node health value. In the final transaction verification, transaction logic consistency is checked by a rule engine; for example, the product of order amount and shipment quantity in supply chain data must match the total amount payable. The matching of node permissions and real-time status checks whether role permissions are compatible with the current node status; for example, temporarily restricted nodes cannot initiate approval-type transactions.

[0134] The preset transaction verification and analysis conditions include: 1) format and signature verification are completely passed; 2) the business type is within the node role's permission range; 3) the transaction logic rule matching degree is ≥95%; 4) the node is online in real time and the error rate in the past hour is <5%; 5) the data hash value has no conflict when constructing the Merkle tree. Data that meets all conditions is used to generate a block root hash through the Merkle tree algorithm, which is then concatenated with the hash of the previous block and written into the blockchain service layer chain structure.

[0135] The base layer consensus node is responsible for performing preliminary verification of the format specifications and digital signature validity of the data blocks to be uploaded to the blockchain within the layered consensus mechanism. The base layer consensus node deploys a data format verification module and a signature verification engine. It verifies the format specifications of the field types, lengths, and nested structures of the data to be uploaded to the blockchain using a pre-defined data template library, and invokes asymmetric encryption tools to decrypt the data signature using the corresponding public key in the node's public key pool to verify the validity of the digital signature, thereby generating the first verification result. For example, when a batch of liquor storage environment data is uploaded by a temperature sensor in a liquor warehouse, the base layer consensus node uses a preset data template library to check the data fields of the liquor storage environment data. The preset data template library defines the conditions that the data fields of the liquor storage environment data must meet, including: liquor data field type, length and nesting structure (e.g., temperature readings must be floating-point numbers), humidity values ​​must be in percentage format, timestamps must conform to UTC format, and sensor IDs must be 16 characters. Digital signature verification calls an asymmetric encryption tool to decrypt the data signature according to the corresponding public key in the liquor warehouse node's public key pool, and then compares it with the hash value of the original data. If the field type of the liquor storage environment data does not conform to the preset data template library, or the digital signature is invalid, the base layer consensus node generates the first verification result and marks it as non-compliant format or invalid signature, preventing the data from entering the second verification. If the data fields of the liquor storage environment data conform to the preset data template library and the signature comparison is consistent, the base layer consensus node generates the first verification result and marks it as compliant format and valid signature.

[0136] Application-layer consensus nodes are nodes in a hierarchical consensus mechanism responsible for performing final transaction verification on the data blocks to be added to the blockchain based on the second verification result and the real-time node status of the dynamic consortium network. Application-layer consensus nodes integrate a real-time node status monitoring module, generate a verification input information set through correlation analysis, and perform final transaction verification based on the consistency of the transaction logic of the data blocks to be added to the blockchain, the matching of node permissions with the real-time node status, and the pre-set transaction verification analysis conditions. They then generate verification conclusions according to these pre-set conditions and add the data blocks to be added to the blockchain service layer's chain structure using a Merkle tree algorithm. For example, for a data block of outbound application, the application layer consensus node first associates the second verification result (e.g., the application node role is "warehouse manager") with the real-time node status monitoring data of the dynamic consortium network (e.g., the node's current online status, recent transaction error rate). Then, based on the fused verification input information set, the node verifies the consistency of the transaction logic: such as whether the batch quantity of outbound wine matches the inventory record, and whether the outbound instruction is associated with the electronic bill of lading; simultaneously, it verifies the matching of node permissions with the real-time node status: such as whether the "warehouse manager" role has the permission to execute the outbound operation for that batch if the current node's historical error rate is below 5% and it is online. Only after all the preset transaction verification analysis conditions are met does the application layer consensus node add the outbound application data block to the chain structure of the blockchain service layer using the Merkle tree algorithm.

[0137] Please see Figure 2 As shown, it is a schematic diagram of the structure of the wine warehouse blockchain service system based on a layered elastic scaling architecture according to an embodiment of the present invention, including:

[0138] The layered elastic scaling architecture building module is used to build a layered elastic scaling architecture based on the blockchain service demand information of the wine cellar. The layered elastic scaling architecture includes an infrastructure layer and a core engine layer. The core engine layer includes a device access layer, a data processing layer, and a blockchain service layer.

[0139] The elastic expansion pool creation module is used to deploy Docker containerized clusters based on the infrastructure layer, and to create an elastic expansion pool containing blockchain nodes and IoT gateways through a preset dynamic resource allocation mechanism and Docker containerized clusters.

[0140] The data conversion module is used to convert the wine warehouse on-chain data obtained from the device access layer based on the protocol conversion rules in the elastic expansion pool and the device access layer, so as to obtain the wine warehouse on-chain data after data conversion.

[0141] The data sending module is used to preprocess the wine warehouse data after data conversion in the data processing layer according to the preset data processing rules, to obtain a preprocessed dataset that conforms to the message middleware transmission mechanism, and to send the preprocessed dataset to the blockchain service layer through the message middleware to obtain the data block to be uploaded to the chain.

[0142] The Dynamic Alliance Network Construction Module is used to generate a notarization contract that matches the data block to be uploaded to the blockchain based on the pluggable smart contract template library, and to verify the identity of the corresponding node role in the data block to be uploaded to the blockchain according to the notarization contract and the dynamic alliance mechanism, and to add the node role that meets the preset identity verification conditions to the blockchain service network to obtain the dynamic alliance network.

[0143] The data upload module is used to perform transaction verification and analysis on the data blocks to be uploaded to the blockchain through a layered consensus mechanism and a dynamic consortium network, and to upload the data blocks to the blockchain that meet the preset transaction verification and analysis conditions.

[0144] The above are merely embodiments of the present invention. Commonly known structures and characteristics are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are aware of all existing technologies in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can, under the guidance of this application, improve and implement this solution in combination with their own capabilities. Some typical known structures or methods should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention. These should also be considered within the scope of protection of the present invention, and will not affect the effectiveness of the implementation of the present invention or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. A data processing method for a wine warehouse blockchain service based on a layered, elastic scaling architecture, characterized in that: Includes the following steps: S1. Construct a layered elastic scaling architecture based on the blockchain service demand information of the wine cellar. The layered elastic scaling architecture includes an infrastructure layer and a core engine layer. The core engine layer includes a device access layer, a data processing layer, and a blockchain service layer. S2. Deploy a Docker containerized cluster based on the infrastructure layer, and establish an elastic expansion pool containing blockchain nodes and IoT gateways through a preset dynamic resource allocation mechanism and the Docker containerized cluster. S3. Based on the protocol conversion rules in the elastic expansion pool and the device access layer, the wine warehouse on-chain data obtained by the device access layer is converted to obtain the wine warehouse on-chain data after data conversion. S4. According to the preset data processing rules, the wine warehouse data after data conversion is preprocessed in the data processing layer to obtain a preprocessed dataset that conforms to the message middleware transmission mechanism. The preprocessed dataset is then sent to the blockchain service layer through the message middleware to obtain the data block to be uploaded to the chain. S5. Generate a notarization contract that matches the data block to be uploaded to the blockchain based on the pluggable smart contract template library, and verify the identity of the corresponding node role in the data block to be uploaded to the blockchain according to the notarization contract and the dynamic alliance mechanism, and add the node role that meets the preset identity verification conditions to the blockchain service network to obtain the dynamic alliance network. S6. Through a layered consensus mechanism and a dynamic alliance network, transaction verification and analysis are performed on the data blocks to be added to the chain, and the data blocks to be added to the chain that meet the preset transaction verification and analysis conditions are added to the chain. S2 includes the following steps: S21. Quantitatively evaluate the computing resources, storage resources and network resources of the infrastructure layer to obtain a resource evaluation parameter set, and configure the runtime environment parameters of the Docker containerized cluster based on the resource evaluation parameter set to obtain the configured Docker runtime environment. S22. Based on the resource threshold parameters in the configured Docker runtime environment, determine the initial number and type distribution of container instances for blockchain nodes and IoT gateways, and deploy container instances in the configured Docker runtime environment according to the initial number and type distribution of container instances to form an initial Docker containerized cluster. S23. Based on the load threshold algorithm in the preset dynamic resource allocation mechanism, the node load parameters of the initial Docker containerized cluster are monitored in real time, a resource demand prediction model is generated, and the dynamic scaling triggering conditions of the container instance are set according to the resource demand prediction model, and the resource scaling rule set is determined based on the dynamic scaling triggering conditions. S24. Based on the resource scaling rule set, elastically scale the container instances in the initial Docker containerized cluster to form an elastic scaling pool containing dynamically adjustable blockchain node containers and IoT gateway containers. S5 includes the following steps: S51. Perform structured parsing on the data block to be uploaded to the chain to obtain a set of feature parameters. Input the set of feature parameters into the pluggable smart contract template library for analysis and generate a notarization contract that matches the data block to be uploaded to the chain. S52. Parse the evidence storage contract to obtain the evidence storage contract parsing result, and determine the various identity verification dimensions of the node roles in the dynamic alliance mechanism and the weight allocation rules corresponding to each identity verification dimension based on the evidence storage contract parsing result. S53. Perform structured parsing on the data block to be uploaded to the chain to obtain the corresponding node role information, wherein the node role information includes the attribute values ​​corresponding to each node role in each identity verification dimension in the dynamic alliance mechanism. S54. Obtain the attribute values ​​corresponding to each authentication dimension in the node role information, map the attribute values ​​corresponding to each authentication dimension to a preset value range, obtain the standardized attribute values ​​corresponding to each authentication dimension, and determine the weight coefficient of each authentication dimension according to the weight allocation rules. S55. Calculate the overall identity verification score S for the node role based on the standardized attribute values ​​corresponding to each identity verification dimension and the weighting coefficients of each identity verification dimension. The mathematical expression for the overall identity verification score S is: In the formula, n represents the number of authentication dimensions. This represents the standardized attribute value of the i-th authentication dimension. , This represents the weight coefficient of the i-th authentication dimension. , ; S56. The overall identity verification score S is compared with the preset overall identity verification score threshold S0. Based on the comparison result, the identity verification status of each node role is judged, and a dynamic alliance network is obtained based on the judgment result, wherein: When S≥S0, the identity verification status of the node role is determined to be satisfactory, and the node role whose identity verification status is deemed satisfactory is added to the dynamic alliance network. When S < S0, the authentication status of the node role is determined to be unqualified, and the authentication status of the node role that is determined to be unqualified is re-authenticated until S ≥ S0. S6 includes the following steps: S61. Through the basic layer consensus nodes in the hierarchical consensus mechanism, the format standardization and digital signature validity of the data block to be uploaded to the chain are initially verified, and the first verification result is generated. S62. Based on the role and permission rules in the dynamic alliance network and the business relevance of the node role identity in the first verification result, a second verification result is generated. The role and permission rules include the business participation scope and operation permissions of the node role in the dynamic alliance network. S63. Through the application layer consensus node in the hierarchical consensus mechanism, combined with the second verification result and the real-time node status of the dynamic alliance network, the final transaction verification of the data block to be uploaded to the chain is performed. When the preset transaction verification analysis conditions are met, the data block to be uploaded to the chain structure of the blockchain service layer is added to the chain structure of the blockchain service layer.

2. The data processing method for a wine warehouse blockchain service based on a hierarchical elastic scaling architecture according to claim 1, characterized in that: S1 includes the following steps: S11. Based on the blockchain service requirements of the wine cellar, analyze the storage capacity, the scale of IoT device access and the dynamic expansion requirements of blockchain nodes, and determine the hardware resource allocation strategy of the infrastructure layer and the functional module division scheme of the core engine layer. S12. Based on the hardware resource allocation strategy and functional module division scheme, determine the resource call interface between the infrastructure layer and the core engine layer, as well as the data interaction interface between the device access layer, data processing layer and blockchain service layer within the core engine layer. S13. Through the resource call interface and data interaction interface, establish a dynamic resource allocation and data flow mechanism between layers to form a layered elastic expansion architecture.

3. The data processing method for a wine warehouse blockchain service based on a hierarchical elastic scaling architecture according to claim 1, characterized in that: S3 includes the following steps: S31. Based on the general IoT protocol conversion module in the device access layer, determine the communication protocol that is compatible with the external monitoring device, and collect raw multi-source heterogeneous data from the external monitoring device according to the communication protocol, and input the raw multi-source heterogeneous data into the elastic expansion pool. The raw multi-source heterogeneous data includes wine cellar environmental data and monitoring data of the digital wine cellar integrated management system. S32. The original multi-source heterogeneous data is converted using the protocol conversion rules in the device access layer to obtain the converted wine warehouse on-chain data.

4. The data processing method for a wine warehouse blockchain service based on a hierarchical elastic scaling architecture according to claim 1, characterized in that: S4 includes the following steps: S41. In the data processing layer, the wine warehouse on-chain data after data conversion is preprocessed based on preset data processing rules, and a preprocessed dataset conforming to the message middleware transmission mechanism is output. The preset data processing rules include data field mapping rules, outlier filtering thresholds, and data format conversion protocols. According to the data field mapping rules, the original fields in the wine warehouse on-chain data after data conversion are mapped and adjusted with the target fields in the blockchain to obtain mapped data. According to the outlier filtering thresholds, the mapped data is range-detected to filter out outliers that exceed the preset data range to obtain filtered data. According to the data format conversion protocol, the filtered data is converted into a data format conforming to the message middleware transmission mechanism. S42. The preprocessed dataset is sent to the data receiving port of the blockchain service layer through the message middleware, and the blockchain service layer performs transaction verification, timestamp appending and Merkel tree node calculation on the preprocessed dataset to generate a data block to be added to the chain containing a data hash value pointer and a reference to the previous block.

5. The data processing method for a wine warehouse blockchain service based on a hierarchical elastic scaling architecture according to claim 1, characterized in that: S63 includes the following steps: S631. By performing correlation analysis between the second verification result and the real-time node status of the dynamic alliance network through the application layer consensus node, a set of verification input information is obtained. S632. Based on the verification input information set, perform final transaction verification on the consistency of transaction logic of the data block to be uploaded to the chain, the matching of node permissions and real-time node status, and generate verification conclusions. S633. Compare the verification conclusion with the preset transaction verification analysis conditions, and add the data blocks to be uploaded to the blockchain service layer that meet the preset transaction verification analysis conditions to the chain structure of the blockchain service layer using the Merkle tree algorithm.

6. A wine cellar blockchain service system based on a hierarchical elastic scaling architecture, applied to the wine cellar blockchain service data processing method based on a hierarchical elastic scaling architecture as described in any one of claims 1-5, characterized in that: include: A layered elastic scaling architecture construction module is used to build a layered elastic scaling architecture based on the service demand information of the wine cellar blockchain. The layered elastic scaling architecture includes an infrastructure layer and a core engine layer. The core engine layer includes a device access layer, a data processing layer, and a blockchain service layer. The elastic expansion pool creation module is used to deploy Docker containerized clusters based on the infrastructure layer, and to create an elastic expansion pool containing blockchain nodes and IoT gateways through a preset dynamic resource allocation mechanism and Docker containerized clusters. The data conversion module is used to convert the wine warehouse on-chain data obtained from the device access layer based on the protocol conversion rules in the elastic expansion pool and the device access layer, so as to obtain the wine warehouse on-chain data after data conversion. The data sending module is used to preprocess the wine warehouse data after data conversion in the data processing layer according to the preset data processing rules, to obtain a preprocessed dataset that conforms to the message middleware transmission mechanism, and to send the preprocessed dataset to the blockchain service layer through the message middleware to obtain the data block to be uploaded to the chain. The dynamic alliance network construction module is used to generate a notarization contract that matches the data block to be uploaded to the blockchain based on the pluggable smart contract template library, and to verify the identity of the corresponding node role in the data block to be uploaded to the blockchain according to the notarization contract and the dynamic alliance mechanism, and to add the node role that meets the preset identity verification conditions to the blockchain service network to obtain the dynamic alliance network. The data upload module is used to perform transaction verification and analysis on the data blocks to be uploaded to the blockchain through a layered consensus mechanism and a dynamic consortium network, and to upload the data blocks to the blockchain that meet the preset transaction verification and analysis conditions.

Images