Blockchain hierarchical architecture based on functional decoupling and cross-component communication optimization method

Abstract

This invention provides a layered blockchain architecture based on functional decoupling and an optimized cross-component communication method, relating to the field of blockchain technology. By dividing the blockchain system into functionally independent storage, consensus, and communication components, this modular design decouples the various functional modules. Each component can be independently developed, upgraded, and replaced according to actual needs, reducing system coupling. By distinguishing between external and internal RPCs, the interface decoupling between external services and internal component collaboration is achieved, facilitating the independent deployment, upgrading, and replacement of specific modules without affecting the overall system operation. This significantly improves system maintainability and version evolution capabilities. Furthermore, this invention optimizes inter-module communication paths by introducing an asynchronous RPC mechanism, effectively avoiding the blocking and latency issues of traditional synchronous communication. A lightweight protocol format is used for internal node communication, avoiding the computational burden caused by multi-layer encapsulation / decapsulation.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, specifically to a layered blockchain architecture based on functional decoupling and a method for optimizing cross-component communication. Background Technology

[0002] As blockchain technology continues to evolve, its application scenarios in areas such as digital finance, supply chain traceability, and government governance are becoming increasingly complex. As a distributed trust infrastructure, blockchain systems must simultaneously meet diverse requirements such as high throughput, low latency, and flexible scalability. However, current mainstream blockchain architectures generally adopt a vertically integrated design pattern, with deep coupling between core modules such as consensus mechanisms, network layers, and smart contract execution environments. This leads to key bottlenecks such as difficulties in functional iteration, low resource utilization, and limited cross-module communication efficiency. How to achieve module decoupling and a simple and efficient system collaboration mechanism is a problem that urgently needs to be solved.

[0003] Existing blockchain architecture improvement solutions mainly revolve around the modular design concept. Consortium blockchain frameworks, represented by Hyperledger Fabric, have initially decoupled some functions by dividing node roles into logical units such as Peers and Orderers. Ethereum 2.0, on the other hand, explores modular expansion paths through the hierarchical division of beacon chains and sharding chains. While these practices have improved the configurability and maintainability of the system to some extent, rigid constraints still exist in the interaction and collaboration between modules. Specifically, this manifests in the following aspects: First, insufficient component flexibility due to architectural coupling. Current blockchain systems often employ tightly coupled functional modules. When developers attempt to replace or upgrade core functional modules (such as consensus modules and storage modules), they must simultaneously adjust the interaction logic of multiple related modules, resulting in high system complexity and maintenance costs. Second, performance bottlenecks exist in cross-module interaction. During data exchange between modules within the system, each functional module often uses custom data formats and communication methods. This heterogeneous interaction pattern necessitates multiple format conversions and protocol adaptations during data transmission, resulting in lengthy communication paths and low resource utilization. Thirdly, system scalability is limited; adding new functional modules requires invasive modifications to the core architecture, making plug-and-play functionality difficult. Existing blockchain platforms typically require modifications to the core layer's message routing mechanism and state synchronization logic, and may even necessitate adjustments to the underlying data structure, when introducing new features. This deeply coupled architectural design necessitates system-level upgrades and deployments for functional expansion, hindering independent module installation and dynamic loading, severely restricting the blockchain system's ability to quickly adapt to diverse application scenarios.

[0004] The existing technical solutions have the following main limitations:

[0005] (1) Traditional blockchain systems adopt a rigid architecture design, with strong dependencies between functional modules (such as consensus, storage, and network). The interface specifications between modules lack standardized design, which means that when a specific module is replaced or upgraded, the interaction logic of the entire system must be re-adapted, which not only increases the development difficulty but also prolongs the system iteration cycle;

[0006] (2) Inefficient cross-module interaction and limited system performance. The heterogeneous data formats and interaction protocols used by each functional module result in frequent format conversions and protocol adaptations during data exchange. This redundant data processing flow not only wastes computing resources but also creates a significant performance bottleneck, severely restricting the improvement of system throughput and response speed;

[0007] (3) The current modular solution is difficult to support the independent deployment and dynamic expansion of functional modules. New functional modules must be deeply bound to the existing architecture, which cannot achieve true on-demand expansion and limits the adaptability of the blockchain system in complex application scenarios. Summary of the Invention

[0008] To address the shortcomings of existing technologies, the present invention aims to propose a blockchain layered architecture based on functional decoupling and a cross-component communication optimization method, including:

[0009] Step 1: Construct a functionally decoupled blockchain layered architecture, which includes a user access layer, a unified gateway layer, and a core service layer. The core service layer includes a blockchain node group, which includes ordinary nodes and componentized nodes. The ordinary nodes include an Evidence Reactor, a Consensus Reactor, a State Reactor, a Blockchain Reactor, a Mempool Reactor, and a PEX Reactor. The componentized nodes include communication components, consensus components, and storage components.

[0010] Step 2: The user access layer receives the transaction request sent by the user and sends the transaction request to the unified gateway layer. The unified gateway layer packages the transaction request into a transaction.

[0011] Step 3: Randomly select a node from the blockchain node group of the core service layer. Based on the selected node, the unified gateway layer sends the packaged transaction to the selected node and broadcasts the packaged transaction to all nodes in the blockchain node group except the selected node through the selected node.

[0012] Step 4: All nodes in the blockchain node group reach a consensus on the packaged transaction and obtain a consensus result. If the consensus result indicates that the consensus has passed, proceed to step 5. If the consensus result indicates that the consensus has failed, do not process the packaged transaction.

[0013] Step 5: For each node in the blockchain node group, process the packaged transaction to obtain the processed transaction information. All nodes synchronize the processed transaction information and broadcast the status to obtain the broadcast transaction information.

[0014] Step 6: Each node in the blockchain node group packages the broadcast transaction information into a block and adds the block to the blockchain.

[0015] Optionally, step 3 specifically includes:

[0016] Step 3.1: Randomly select a node from the blockchain node group of the core service layer, and determine whether the selected node is a normal node. If the selected node is a component node, proceed to step 3.2; if the selected node is a normal node, proceed to step 3.3.

[0017] Step 3.2: Through external remote procedure call (RPC), the unified gateway layer sends the packaged transaction to the communication component in the selected componentized node. This communication component broadcasts the packaged transaction to the communication components of all other componentized nodes in the blockchain node group through a P2P peer-to-peer communication mechanism, and also broadcasts the packaged transaction to the PEXReactor of all ordinary nodes in the blockchain node group. At the same time, this communication component broadcasts the packaged transaction to the storage component and consensus component in the selected componentized node through an internal remote procedure call (RPC) communication mechanism, and then proceeds to step 4.

[0018] Step 3.3: Through external remote procedure call (RPC), the unified gateway layer sends the packaged transaction to the PEX Reactor of the selected ordinary node. The PEX Reactor in the selected ordinary node broadcasts the packaged transaction to the PEX Reactors of all other ordinary nodes in the blockchain node group through the P2P peer-to-peer communication mechanism. At the same time, it broadcasts the packaged transaction to the communication components of all componentized nodes in the blockchain node group. The communication component of the componentized node that receives the packaged transaction broadcasts the packaged transaction to the storage component and consensus component in the selected componentized node through the internal remote procedure call (RPC) communication mechanism, and then executes Step 4.

[0019] Optionally, step 4 specifically includes:

[0020] For each component node in the blockchain node group, a consensus component votes on the packaged transactions and broadcasts the voting results to all other nodes except the component node via a P2P peer-to-peer communication mechanism. For each ordinary node in the blockchain node group, a Consensus Reactor votes on the packaged transactions and broadcasts the voting results to all other nodes except the ordinary node via a P2P peer-to-peer communication mechanism. The voting results of all nodes are counted, and the proportion of votes representing agreement is calculated. If the proportion is greater than or equal to two-thirds, the consensus result indicates that the consensus has passed; if the proportion is less than two-thirds, the consensus result indicates that the consensus has failed.

[0021] Optionally, step 5 specifically includes:

[0022] For ordinary nodes in a blockchain node cluster, the PEX Reactor in an ordinary node broadcasts completed transaction information to the PEX Reactors of all other ordinary nodes in the cluster via a P2P peer-to-peer communication mechanism, and also broadcasts completed transaction information to the communication components of all componentized nodes in the cluster. For componentized nodes in a blockchain node cluster, the communication component of a componentized node broadcasts completed transaction information to the communication components of all other componentized nodes in the cluster via a P2P peer-to-peer communication mechanism, and also broadcasts completed transaction information to the PEX Reactors of all ordinary nodes in the cluster. Simultaneously, this communication component broadcasts completed transaction information to the storage and consensus components of the componentized node via an internal remote call RPC communication mechanism.

[0023] Optionally, step 6 specifically includes:

[0024] For ordinary nodes in a blockchain node cluster, the Blockchain Reactor of the ordinary node packages the broadcast transaction information into a block and adds the block to the blockchain. For componentized nodes in a blockchain node cluster, the storage component of the componentized node packages the broadcast transaction information into a block and adds the block to the blockchain.

[0025] Optional, also includes:

[0026] Step 7: When the transaction request is a storage request, the unified gateway layer receives the packaged original data of the transaction, extracts features from the original data to obtain structured key features, which are used to represent the semantics or content summary of the original data. The original data is stored in the off-chain database in a sharded manner, and the key features are stored in the on-chain database.

[0027] Optionally, in step 7, feature extraction is performed on the original data to obtain structured key features, including:

[0028] The original data is formatted, denoised, and aligned to obtain preprocessed data. In-depth analysis is then performed on the preprocessed data to obtain structured key features.

[0029] The beneficial effects of adopting the above technical solution are as follows:

[0030] This invention divides the blockchain system into functionally independent storage, consensus, and communication components. This modular design decouples the various functional modules, allowing each component to be independently developed, upgraded, and replaced according to actual needs. This reduces system coupling and makes subsequent maintenance and functional expansion more flexible and efficient. By distinguishing between external and internal RPCs, the interface decoupling between external services and internal component collaboration is achieved. This facilitates the independent deployment, upgrading, and replacement of specific modules without affecting the overall system operation, significantly improving system maintainability and version evolution capabilities, and shortening the development and deployment cycle. Furthermore, this invention optimizes the communication path between modules by introducing an asynchronous RPC mechanism, effectively avoiding the blocking and latency issues of traditional synchronous communication. A lightweight protocol format is used for internal node communication, avoiding the computational burden caused by multi-layer encapsulation / decapsulation. Through bidirectional optimization of interfaces and protocols, the overall data transmission efficiency is improved. Attached Figure Description

[0031] Figure 1 This is a schematic diagram of the layered blockchain architecture based on functional decoupling in an embodiment of the present invention;

[0032] Figure 2 This is an overall architecture diagram of the blockchain layered architecture and cross-component communication optimization method based on functional decoupling in this embodiment of the invention;

[0033] Figure 3 This is an architecture diagram of the communication components and communication method in an embodiment of the present invention;

[0034] Figure 4 This is an architecture diagram of the consensus component and communication method in an embodiment of the present invention. Detailed Implementation

[0035] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and are not intended to limit the scope of the invention.

[0036] To address the problems existing in the prior art, this invention provides a layered blockchain architecture based on functional decoupling and a cross-component communication optimization method to solve the problems of high development difficulty, long system iteration cycle, low operation and maintenance efficiency caused by the tightly coupled structure design of traditional blockchain systems, as well as the significant performance loss in inter-module communication in existing systems.

[0037] Combination Figure 1 and Figure 2 The blockchain layered architecture and cross-component communication optimization method based on functional decoupling provided by this invention may include the following steps:

[0038] Step 1: Construct a functionally decoupled blockchain layered architecture, which includes a user access layer, a unified gateway layer, and a core service layer. The core service layer includes a blockchain node group, which includes ordinary nodes and componentized nodes. The ordinary nodes include an Evidence Reactor, a Consensus Reactor, a State Reactor, a Blockchain Reactor, a Mempool Reactor, and a PEX Reactor. The componentized nodes include communication components, consensus components, and storage components.

[0039] The user access layer is the front end of the blockchain multimodal data management system, through which users can send requests. The unified gateway layer can package user requests into transactions and send them to the core service layer for processing. The core service layer consists of a blockchain node group, which completes the consensus and processing of transactions.

[0040] The unified gateway layer includes storage and query services, specifically covering key services such as on-chain and off-chain collaborative storage, trusted complex queries, and trusted traceability queries. This ensures that the blockchain node cluster can not only perform complex on-chain data retrieval tasks but also guarantee the efficient execution of transactions and consensus. This design significantly enhances the system's data processing capabilities and network security, guaranteeing the authenticity and immutability of data. Specifically, it includes the following services:

[0041] (1) Integrating high-performance caching mechanism

[0042] A Redis caching system is connected outside the blockchain node cluster to temporarily cache high-frequency transaction data and query requests. When a client or component node requests a complex query or data verification operation, the system first accesses the Redis cache to improve query response efficiency. The Redis cache can also serve as a temporary state cache in the consensus process for data buffering and fast read / write under high concurrency conditions.

[0043] (2) Implement a trusted complex query and trusted traceability query mechanism

[0044] To address the need for verifiable retrieval of multimodal sequence data in blockchain, a verifiable DSTree index structure is designed. Based on this structure, the following functions are implemented: trusted complex queries (supporting multi-condition joint queries) and trusted traceability queries (quickly reconstructing the data source path and storage process), ensuring the verifiability of the results. The query process, combined with the immutability of on-chain data, ensures that the returned results can be verified at both the logical and physical levels.

[0045] The core service layer mainly consists of a blockchain node cluster, which facilitates consensus and processing of transactions. Within this cluster, there are ordinary nodes and componentized nodes. Componentized nodes are derived from ordinary nodes through modularization. Ordinary nodes are normal blockchain nodes in the blockchain network, while componentized nodes are nodes derived from modularized ordinary nodes based on a functionally decoupled blockchain layered architecture.

[0046] Componentized nodes include storage components, consensus components, and communication components. In this architecture, each node in the blockchain multimodal data management system can be divided into storage components, consensus components, and communication components. Based on resource consumption characteristics, if I / O resources account for a high proportion, the component is called a storage component; if computing resources account for a high proportion, the component is called a consensus component; and if network resources account for a high proportion, the component is called a communication component.

[0047] The Evidence Reactor is used to process evidence of malicious nodes, the Consensus Reactor is responsible for voting and proposals in the consensus process, the State Reactor and the Blockchain Reactor are used for blockchain state management and block data synchronization, respectively, the Mempool Reactor is used to maintain the pool of transactions awaiting consensus, and the PEX Reactor is used for node discovery and network topology. The reactor modules work together through an internal messaging mechanism to ensure the consistency of the state and the timeliness of the response of the consensus components.

[0048] Step 2: The user access layer receives the transaction request sent by the user and sends the transaction request to the unified gateway layer. The unified gateway layer packages the transaction request into a transaction.

[0049] Step 3: Randomly select a node from the blockchain node group of the core service layer. Based on the selected node, the unified gateway layer sends the packaged transaction to the selected node and broadcasts the packaged transaction to all nodes in the blockchain node group except the selected node through the selected node.

[0050] Step 3.1: Randomly select a node from the blockchain node group of the core service layer, and determine whether the selected node is a normal node. If the selected node is a component node, proceed to step 3.2; if the selected node is a normal node, proceed to step 3.3.

[0051] Step 3.2: Combining Figure 3 The unified gateway layer sends the packaged transaction to the communication component in the selected componentized node via an external remote procedure call (RPC). This communication component broadcasts the packaged transaction to the communication components of all other componentized nodes in the blockchain node group via a P2P peer-to-peer communication mechanism, and also broadcasts the packaged transaction to the PEX Reactor of all ordinary nodes in the blockchain node group. At the same time, this communication component broadcasts the packaged transaction to the storage component and consensus component in the selected componentized node via an internal remote procedure call (RPC) communication mechanism, and then executes step 4.

[0052] External RPC is primarily responsible for handling communication between the system and the outside world, such as data exchange between clients and servers. This includes user permission management and block information visualization management, information monitoring, and permission management. Internal RPC, on the other hand, is used for communication between component nodes within the system's various modular nodes. It optimizes communication protocols and data formats to reduce latency and improve efficiency.

[0053] The P2P peer-to-peer communication mechanism allows the communication component to directly connect with external nodes. This design ensures network flexibility and scalability while simplifying node management. Simultaneously, the communication component maintains an active list of all external nodes, including metadata such as node addresses and status. As node status changes, the communication component dynamically updates this list, ensuring information consistency among nodes throughout the network.

[0054] The internal PRC communication mechanism specifically involves RPC communication, primarily used for basic data transmission within the node. By using RPC communication, a highly decoupled system design can be achieved, allowing different components, such as consensus and storage components, to interact through well-defined interfaces without needing to understand each other's internal implementation details. Specifically, internal node communication is implemented via Remote Procedure Call (RPC). Internal RPC calls are made between different components within the same node. This mechanism ensures logical decoupling between components, relying only on interfaces and not on implementation details. A typical use case is as follows: the consensus component queries the storage component for a specified block via RPC, requesting block data; after a new block is added, the consensus component notifies the storage component to update the database via RPC.

[0055] The RPC mechanism has the following characteristics: well-defined interfaces that support structured data interaction; support for asynchronous call mode to improve throughput and avoid performance bottlenecks caused by request blocking; and can be extended to advanced use cases such as event subscription and status push to form a stable event-driven communication mechanism.

[0056] In summary, the storage and consensus components do not communicate directly with external nodes, but they need to obtain the latest network status (such as the availability of external nodes). The communication component provides a unified interface that allows the storage and consensus components to call and obtain information on currently active external nodes at any time. When the network status changes (such as a new node joining or an existing node leaving), the communication component will broadcast an update notification through internal RPC. The storage and consensus components will then adjust their transaction processing and data storage behavior accordingly to achieve a rapid response to changes in the external status.

[0057] The communication component also maintains a real-time list of external nodes, which includes metadata such as node address, current communication status (online, offline, abnormal, etc.), recent interaction time, and role identifier. This list is dynamically updated based on changes in nodes within the network, ensuring accuracy and timeliness. When a new external node wants to join the blockchain node group, it must first establish a P2P connection with a communication component. The specific process is as follows:

[0058] 1) An external node sends a connection request to the communication component in this componentized node;

[0059] 2) The communication component verifies its identity and status to determine whether to allow it to join;

[0060] 3) If the verification is successful, the node will be added to the list of active external nodes. The communication component will broadcast the connection information, including the node's certificate, ID, public key, etc., to other nodes in the blockchain network through the P2P peer-to-peer communication mechanism, so that other nodes can verify the identity.

[0061] Step 3.3: Through external remote procedure call (RPC), the unified gateway layer sends the packaged transaction to the PEX Reactor of the selected ordinary node. The PEX Reactor in the selected ordinary node broadcasts the packaged transaction to the PEX Reactors of all other ordinary nodes in the blockchain node group through the P2P peer-to-peer communication mechanism. At the same time, it broadcasts the packaged transaction to the communication components of all componentized nodes in the blockchain node group. The communication component of the componentized node that receives the packaged transaction broadcasts the packaged transaction to the storage component and consensus component in the selected componentized node through the internal remote procedure call (RPC) communication mechanism, and then executes Step 4.

[0062] Among them, the P2P peer-to-peer communication mechanism relies on the P2P protocol, which allows ordinary nodes to establish connections and communicate with other nodes in the blockchain network.

[0063] Step 4: All nodes in the blockchain node group reach a consensus on the packaged transaction and obtain a consensus result. If the consensus result indicates that the consensus has passed, proceed to step 5. If the consensus result indicates that the consensus has failed, do not process the packaged transaction.

[0064] Combination Figure 4 For each component node in the blockchain node group, a consensus component votes on the packaged transactions and broadcasts the voting results to all other nodes except the component node via a P2P peer-to-peer communication mechanism. For each ordinary node in the blockchain node group, a Consensus Reactor votes on the packaged transactions and broadcasts the voting results to all other nodes except the ordinary node via a P2P peer-to-peer communication mechanism. The voting results of all nodes are counted, and the proportion of votes representing agreement is calculated. If the proportion is greater than or equal to two-thirds, the consensus result indicates that the consensus has passed; if the proportion is less than two-thirds, the consensus result indicates that the consensus has not passed.

[0065] Step 5: For each node in the blockchain node group, process the packaged transaction to obtain the processed transaction information. All nodes synchronize the processed transaction information and broadcast the status to obtain the broadcast transaction information.

[0066] For ordinary nodes in a blockchain node cluster, the PEX Reactor in an ordinary node broadcasts completed transaction information to the PEX Reactors of all other ordinary nodes in the cluster via a P2P peer-to-peer communication mechanism, and also broadcasts completed transaction information to the communication components of all componentized nodes in the cluster. For componentized nodes in a blockchain node cluster, the communication component of a componentized node broadcasts completed transaction information to the communication components of all other componentized nodes in the cluster via a P2P peer-to-peer communication mechanism, and also broadcasts completed transaction information to the PEX Reactors of all ordinary nodes in the cluster. Simultaneously, this communication component broadcasts completed transaction information to the storage and consensus components of the componentized node via an internal remote call RPC communication mechanism.

[0067] Specifically, the processing of packaged transactions can be based on the requests executed by the packaged transactions. For example, if the packaged transaction is a query request, it can be processed based on the query service in the unified gateway layer and the query result can be returned. If the request is to change the value 1 stored in a certain block to 2, then each node directly modifies the value.

[0068] Step 6: Each node in the blockchain node group packages the broadcast transaction information into a block and adds the block to the blockchain.

[0069] For ordinary nodes in a blockchain node cluster, the Blockchain Reactor of the ordinary node packages the broadcast transaction information into a block and adds the block to the blockchain. For componentized nodes in a blockchain node cluster, the storage component of the componentized node packages the broadcast transaction information into a block and adds the block to the blockchain.

[0070] Step 7: When the transaction request is a storage request, the unified gateway layer receives the packaged original data of the transaction, extracts features from the original data to obtain structured key features, which are used to represent the semantics or content summary of the original data. The original data is stored in the off-chain database in a sharded manner, and the key features are stored in the on-chain database.

[0071] The blockchain layered architecture based on functional decoupling establishes two types of data storage channels during initialization: an on-chain database and an off-chain database. The off-chain database stores raw data, such as unstructured or semi-structured information like images, text, and audio. The on-chain database records key feature summaries, index information, or hash values ​​of the data. The key feature summaries refer to feature information that uniquely identifies the core attributes or content of the raw data. The off-chain and on-chain databases establish a data interaction path through storage modules, achieving hybrid data storage management.

[0072] The raw data includes different types of data such as raw images, audio, and text.

[0073] This involves feature extraction from the original data to obtain structured key features, including:

[0074] The raw data is standardized, denoised, and aligned to ensure a unified processing foundation and storage structure, facilitating subsequent management and retrieval. This yields preprocessed data, which is then analyzed in depth by the feature calculation module to obtain structured key features. These extracted key features include data fingerprints, content summaries, timestamps, and index information, providing support for efficient indexing, verification, and cross-modal queries in the blockchain.

[0075] The fragmentation method involves dividing a complete data file into several smaller blocks, or data fragments, to improve the distributed nature and security of data storage. Optionally, erasure coding technology is used to redundantly encode the data, encoding it into n data blocks, which are then distributed and stored on multiple off-chain nodes to improve fault tolerance.

[0076] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0077] (1) This invention significantly improves the modular management and scalability of the blockchain system by dividing it into functionally independent storage, consensus, and communication components. The modular design decouples the various functional modules, facilitating customization and optimization for different business needs and reducing development difficulty. Each component can be independently developed, upgraded, and replaced according to actual needs, reducing system coupling and making subsequent maintenance and functional expansion more flexible and efficient.

[0078] (2) This invention proposes a layered component-based communication architecture. Each core module (such as communication component, storage component, consensus component) interacts through standardized interfaces, which gets rid of the strong dependency between modules in the traditional tightly coupled architecture. By distinguishing between external RPC and internal RPC, the interface decoupling between the system's external services and internal component collaboration is realized. This makes it easy to independently deploy, upgrade, and replace specific modules (such as consensus algorithms or storage backends) without affecting the overall operation of the system. This significantly improves the maintainability and version evolution capability of the system and shortens the development and deployment cycle.

[0079] (3) The present invention optimizes the communication path between modules and introduces an asynchronous RPC mechanism, which effectively avoids the blocking delay problem in traditional synchronous communication. It adopts a lightweight protocol format for communication within nodes to avoid the computational burden caused by multi-layer encapsulation / decapsulation. Compared with the inefficient processing of complex data by the general serialization methods in the prior art (such as JSON and Protobuf), the present invention improves the overall data transmission efficiency through bidirectional optimization of interfaces and protocols.

[0080] (4) This invention enhances the network self-healing capability in a distributed environment while ensuring system consistency, which is significantly better than the traditional static connection structure. The communication component can dynamically maintain the list of active status of external nodes through the embedded P2P mechanism and node discovery module, and realize the automatic topology reconstruction of the network. The storage component and consensus component obtain real-time updated external node information through the communication component, automatically adapt to network changes, and ensure the stable operation of data storage and transaction processing.

[0081] In summary, this invention provides a layered blockchain architecture based on functional decoupling and an optimized method for cross-component communication. This can solve the problems of high difficulty in component deployment and development, long system iteration cycles, low operation and maintenance efficiency caused by the tightly coupled structural design of traditional blockchain systems, as well as the significant performance loss in inter-module communication in existing systems.

[0082] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A blockchain layered architecture based on functional decoupling and a cross-component communication optimization method, characterized in that, include: Step 1: Construct a functionally decoupled blockchain layered architecture, which includes a user access layer, a unified gateway layer, and a core service layer. The core service layer includes a blockchain node group, which includes ordinary nodes and componentized nodes. The ordinary nodes include an Evidence Reactor, a Consensus Reactor, a State Reactor, a Blockchain Reactor, a Mempool Reactor, and a PEX Reactor. The componentized nodes include communication components, consensus components, and storage components. Step 2: The user access layer receives the transaction request sent by the user and sends the transaction request to the unified gateway layer. The unified gateway layer packages the transaction request into a transaction. Step 3: Randomly select a node from the blockchain node group of the core service layer. Based on the selected node, the unified gateway layer sends the packaged transaction to the selected node and broadcasts the packaged transaction to all nodes in the blockchain node group except the selected node through the selected node. Step 3.1: Randomly select a node from the blockchain node group of the core service layer, and determine whether the selected node is a normal node. If the selected node is a component node, proceed to step 3.2; if the selected node is a normal node, proceed to step 3.

3. Step 3.2: Through external remote procedure call (RPC), the unified gateway layer sends the packaged transaction to the communication component in the selected componentized node. This communication component broadcasts the packaged transaction to the communication components of all other componentized nodes in the blockchain node group through a P2P peer-to-peer communication mechanism, and also broadcasts the packaged transaction to the PEX Reactor of all ordinary nodes in the blockchain node group. At the same time, this communication component broadcasts the packaged transaction to the storage component and consensus component in the selected componentized node through an internal remote procedure call (RPC) communication mechanism, and then executes step 4. Step 3.3: Through external remote procedure call (RPC), the unified gateway layer sends the packaged transaction to the PEX Reactor of the selected ordinary node. The PEX Reactor in the selected ordinary node broadcasts the packaged transaction to the PEX Reactors of all other ordinary nodes in the blockchain node group through the P2P peer-to-peer communication mechanism. At the same time, it broadcasts the packaged transaction to the communication components of all componentized nodes in the blockchain node group. The communication component of the componentized node that receives the packaged transaction broadcasts the packaged transaction to the storage component and consensus component in the selected componentized node through the internal remote procedure call (RPC) communication mechanism, and then executes step 4. Step 4: All nodes in the blockchain node group reach a consensus on the packaged transaction and obtain a consensus result. If the consensus result indicates that the consensus has passed, proceed to step 5. If the consensus result indicates that the consensus has failed, do not process the packaged transaction. Step 5: For each node in the blockchain node group, process the packaged transaction to obtain the processed transaction information. All nodes synchronize the processed transaction information and broadcast the status to obtain the broadcast transaction information. Step 6: Each node in the blockchain node group packages the broadcast transaction information into a block and adds the block to the blockchain.

2. The blockchain layered architecture and cross-component communication optimization method based on functional decoupling as described in claim 1, characterized in that, Step 4 specifically includes: For each component node in the blockchain node group, a consensus component votes on the packaged transactions and broadcasts the voting results to all other nodes except the component node via a P2P peer-to-peer communication mechanism. For each ordinary node in the blockchain node group, a Consensus Reactor votes on the packaged transactions and broadcasts the voting results to all other nodes except the ordinary node via a P2P peer-to-peer communication mechanism. The voting results of all nodes are counted, and the proportion of votes representing agreement is calculated. If the proportion is greater than or equal to two-thirds, the consensus result indicates that the consensus has passed; if the proportion is less than two-thirds, the consensus result indicates that the consensus has failed.

3. The blockchain layered architecture and cross-component communication optimization method based on functional decoupling as described in claim 1, characterized in that, Step 5 specifically includes: For ordinary nodes in a blockchain node cluster, the PEX Reactor in an ordinary node broadcasts completed transaction information to the PEX Reactors of all other ordinary nodes in the cluster via a P2P peer-to-peer communication mechanism, and also broadcasts completed transaction information to the communication components of all componentized nodes in the cluster. For componentized nodes in a blockchain node cluster, the communication component of a componentized node broadcasts completed transaction information to the communication components of all other componentized nodes in the cluster via a P2P peer-to-peer communication mechanism, and also broadcasts completed transaction information to the PEX Reactors of all ordinary nodes in the cluster. Simultaneously, this communication component broadcasts completed transaction information to the storage and consensus components of the componentized node via an internal remote call RPC communication mechanism.

4. The blockchain layered architecture and cross-component communication optimization method based on functional decoupling as described in claim 1, characterized in that, Step 6 specifically includes: For ordinary nodes in a blockchain node cluster, the Blockchain Reactor of the ordinary node packages the broadcast transaction information into a block and adds the block to the blockchain. For componentized nodes in a blockchain node cluster, the storage component of the componentized node packages the broadcast transaction information into a block and adds the block to the blockchain.

5. The blockchain layered architecture and cross-component communication optimization method based on functional decoupling according to claim 1, characterized in that, Also includes: Step 7: When the transaction request is a storage request, the unified gateway layer receives the packaged original data of the transaction, extracts features from the original data to obtain structured key features, which are used to represent the semantics or content summary of the original data. The original data is stored in the off-chain database in a sharded manner, and the key features are stored in the on-chain database.

6. The blockchain layered architecture and cross-component communication optimization method based on functional decoupling according to claim 5, characterized in that, Step 7 involves feature extraction from the original data to obtain structured key features, including: The original data is formatted, denoised, and aligned to obtain preprocessed data. In-depth analysis is then performed on the preprocessed data to obtain structured key features.

Images