A blockchain-based cross-network data security exchange system and method

Abstract

The application discloses a cross-network data security exchange system and method based on a blockchain, the system is deployed in a physically isolated network environment, and comprises blockchain nodes, proxy components and an FTP server deployed on a network isolation device, which belong to different networks; cross-network interconnection of the blockchain nodes is realized through a unique reverse proxy mechanism; a connection request of the blockchain node is forwarded to a peer end by a local proxy component through the FTP server, a TCP connection is actively established to an internal blockchain node of the peer end by the peer end proxy component, and therefore, establishment of a reverse proxy channel is transparently completed; in addition, key timeout parameters of a practical Byzantine fault tolerance (PBFT) consensus algorithm are specifically optimized, and stability of a consensus process is effectively guaranteed. The application solves technical problems that the blockchain P2P protocol cannot directly communicate between isolated networks and a consensus is prone to timeout, and realizes safe exchange and full-process credible tracing of cross-network data.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of data security exchange, in particular to a cross-network data security exchange scheme. BACKGROUND

[0002] Currently, the following four methods are mainly used for cross-network data security exchange between physically isolated network domains: 1) offline data replication relying on mobile storage devices; 2) data conversion between different networks through special hardware cards; 3) data exchange method based on cache reuse, which is used for data interaction between internal network of a server and external application terminals; and 4) one-way gateways, monitoring gateways and other secure channel methods.

[0003] On the basis of the above four methods, many scholars continue to carry out related research on cross-network data security transmission. In order to meet the needs of cross-network data transmission in e-government systems, such as the scheme disclosed in the paper “A Cross-network Information Interaction Scheme for E-government System in Accordance with Security Specifications”, the data exchange module adopts the security strategy of internal and external front-end machine authentication and double one-way optical gate; or such as the scheme disclosed in the paper “Design and Implementation of a Cross-network Gate Data Transmission System”, a communication protocol is defined on the basis of the UDP transmission protocol to ensure real-time performance and data integrity in the transmission process. Although the above methods meet the needs of cross-network data transmission, their security metrics are still questionable. These technologies can achieve basic data ferrying, but there are deficiencies in the aspects of trusted audit and full-process traceability in the data exchange process.

[0004] In order to realize full-process traceability of cross-network data exchange, technical personnel further carry out a series of research on cross-network log audit. For example, the paper “Cross-network Log Audit and User Behavior Traceability Research” proposes a cross-network log audit system framework. The framework sets up a unique entity identifier in two networks, and synchronizes the logs exchanged by cross-network applications to the log audit system of each network regularly.

[0005] Blockchain technology has played a role in data storage and sharing in many fields due to its non-tamperable and traceable characteristics. However, there are two inherent technical obstacles to directly applying blockchain to a cross-network environment:

[0006] One is the P2P network connectivity obstacle. Blockchain nodes rely on point-to-point (P2P) protocol for direct communication, while physically isolated networks prohibit such direct network layer connection, resulting in the inability to form a cross-network blockchain network.

[0007] The second is the consensus algorithm timeliness obstacle: blockchain consensus algorithms (such as PBFT) rely on strict timeout mechanisms to ensure activity. In a cross-network high-delay environment, the standard configuration parameters will cause messages to fail to reach an agreement before the timeout, causing the system to frequently enter a recovery state and fail to reach consensus.

[0008] In the prior art, patent document CN120111123A discloses a cross-network data exchange system which transmits data through a proxy component and a file server. This scheme is specifically used to solve the general cross-network communication problem between heterogeneous networks and different application layer protocol business systems, and cannot solve the cross-network communication problem between physically isolated networks. At the same time, in the specific scheme composition, FTP servers need to be directly deployed in different networks to form cross-network devices. Moreover, such schemes are mostly general request-response proxy modes and are not designed for the P2P communication semantics of blockchains, and cannot solve the first obstacle faced by blockchains when directly applied to cross-network environments. More importantly, all existing cross-network data exchange schemes do not involve the second obstacle, that is, they do not make any adaptive optimization to the blockchain consensus algorithm, resulting in the fact that blockchains are not usable in cross-network environments.

[0009] Therefore, how to construct a data security exchange scheme that can adapt to the P2P communication model of blockchains and solve the consensus failure problem under high delay in cross-networks is the key to realizing cross-network trusted data exchange and full-process traceability based on blockchains. SUMMARY

[0010] The purpose of the present application is to overcome the above-mentioned shortcomings of the prior art, make use of the characteristics of blockchains such as data being difficult to tamper with and being traceable, and provide a cross-network data security exchange scheme based on blockchains. This scheme connects physically isolated networks through an innovative reverse proxy architecture and optimizes the parameters of the blockchain consensus algorithm specifically, thereby solving the problems of blockchains being unable to form networks and consensus failure in cross-network environments, and realizing the secure exchange of data and full-process trusted traceability.

[0011] To achieve the above-mentioned purpose, in a first aspect, the present application provides a cross-network data security exchange system based on blockchains, which is deployed in at least two physically isolated networks of network isolated devices, and is composed of at least one first blockchain node and a first proxy component deployed in a first network, at least one second blockchain node and a second proxy component deployed in a second network, and a group of file transfer protocol (FTP) servers deployed on a network isolated device.

[0012] The first proxy component is in communication connection with the first blockchain node and is connected with the FTP servers deployed on the network isolated device through the FTP protocol. The second proxy component is in communication connection with the second blockchain node and is connected with the FTP servers deployed on the network isolated device through the FTP protocol.

[0013] The first proxy component is configured to receive a connection request initiated by the first blockchain node and directed to the second blockchain node, and encapsulate the connection request as a first file and send the first file to the second proxy component through the FTP server.

[0014] The second proxy component is configured to obtain the first file from the FTP server, parse the connection request, and based on the connection request, actively initiate and establish a TCP connection with the second blockchain node, so that the first blockchain node can transmit data to the second blockchain node through the first proxy component, the FTP server and the second proxy component, thereby realizing reverse proxy access.

[0015] The timeout parameter of the practical Byzantine fault tolerance (PBFT) consensus algorithm used by the first blockchain node and the second blockchain node is set to be extended.

[0016] Further, the first proxy component and the first blockchain node, and the second proxy component and the second blockchain node are connected based on the gRPC protocol, and the service interface of the gRPC protocol is configured to support bidirectional streaming of P2P communication between blockchain nodes.

[0017] Further, three second blockchain nodes are deployed in the second network, and the three second blockchain nodes are interconnected in a point-to-point manner through the gRPC protocol to form an intra-domain consensus cluster.

[0018] Further, the FTP server deployed on the network isolation device simultaneously establishes a bidirectional connection with the first proxy component and the second proxy component through the FTP protocol.

[0019] Further, the first proxy component and the second proxy component each include:

[0020] A TCP layer configured to establish and maintain a long connection with a blockchain node in the network to receive and transmit data;

[0021] An FTP layer configured to interact with the FTP server in the form of files based on the FTP protocol;

[0022] The TCP layer encapsulates the data from the blockchain node in the network into a file and uploads the file to the FTP server after the FTP layer encapsulates the data from the blockchain node in the network into a file; the FTP layer decapsulates the file downloaded from the FTP server and forwards the data to the TCP layer for forwarding to the blockchain node in the network.

[0023] Further, the system is also configured to upload key event information in the cross-network data transmission process to the first and / or second blockchain nodes for trusted notarization.

[0024] To achieve the above-mentioned purposes, in a second aspect, the present application also provides a cross-network data secure exchange method based on blockchain, which is applied to the above-mentioned system and comprises:

[0025] Connection establishment: the first blockchain node initiates a connection request to the second blockchain node to the first proxy component; the first proxy component encapsulates the connection request as a first file and uploads it to the FTP server through the FTP protocol; the second proxy component downloads the first file from the FTP server and parses the connection request; the second proxy component initiates and establishes a TCP connection to the second blockchain node based on the parsed connection request, completing the establishment of the reverse proxy connection channel;

[0026] Data exchange: after the establishment of the connection channel, the data to be transmitted by the first blockchain node is forwarded to the second blockchain node through the first proxy component, the FTP server and the second proxy component;

[0027] Consensus algorithm optimization: the timeout parameters of the practical Byzantine fault tolerance (PBFT) consensus algorithm adopted by the first and second blockchain nodes are extended to adapt to the cross-network communication delay; wherein, the node state synchronization interval is adjusted from the standard 1 second to 2 seconds, the checkpoint confirmation waiting time is adjusted from the standard 5 seconds to 7 seconds, the view replacement timeout length is adjusted from the standard 8 seconds to 16 seconds, and the interval time for re-sending the view replacement request is adjusted from the standard 10 seconds to 18 seconds.

[0028] Further, the data exchange step comprises: the first proxy component receives the gRPC message from the TCP layer of the first blockchain node, and then uploads it to the FTP server after being encapsulated as a second file by the FTP layer of the first proxy component; the second proxy component downloads the second file from the FTP server through the FTP layer, and then converts it to a gRPC message through the TCP layer and sends it to the second blockchain node after being decapsulated.

[0029] Further, the method further comprises a traceable notarization step: uploading the key event information in the connection establishment step and / or the data exchange step to the blockchain for notarization.

[0030] Further, the service interface of the gRPC protocol between the proxy component and the blockchain node is configured to support the bidirectional streaming transmission of P2P communication between the blockchain nodes.

[0031] The scheme provided by the application has the following beneficial effects relative to the prior art:

[0032] First, the cross-network P2P connection problem of the blockchain is innovatively solved, the mode of "proxy component + FTP server" and a unique reverse proxy connection establishment mechanism (initiative connection establishment by the opposite end proxy to the opposite end node) are used, and the P2P communication of the blockchain nodes between physically isolated networks is transparently realized, so that the blockchain network can be formed in a cross-network environment.

[0033] Second, the cross-network consensus failure problem is solved in a targeted manner, the key timeout parameters of the PBFT consensus algorithm are specifically optimized, the high-delay cross-network environment is adapted, the frequent view replacement and consensus failure caused by network delay are effectively avoided, and the stable operation of the cross-network blockchain system is ensured.

[0034] Third, the unification of secure exchange and trusted traceability is realized, on the basis of solving the cross-network communication and consensus, the natural implementation of the trusted evidence and traceability of the whole process (such as connection establishment and file transmission) of data exchange is realized by using the non-tamperable characteristics of the blockchain, and the security and credibility of cross-network data exchange are improved. BRIEF DESCRIPTION OF DRAWINGS

[0035] The application will be further described below in combination with the drawings and specific embodiments.

[0036] Figure 1 The figure is a schematic diagram of the architecture of the cross-network data security exchange system based on the blockchain in the application.

[0037] Figure 2 The figure is a schematic diagram of the architecture of the cross-network data security exchange system based on the blockchain in the application.

[0038] Figure 3 The figure is a schematic diagram of the architecture of the cross-network data security exchange system based on the blockchain in the application.

[0039] Figure 4 The figure is a schematic diagram of the architecture of the cross-network data security exchange system based on the blockchain in the application. DETAILED DESCRIPTION

[0040] In order to make the technical means, creative features, purposes and effects realized by the application easy to understand, the application will be further described below in combination with specific drawings.

[0041] In view of the demand and characteristics of cross-network data security exchange between physically isolated network domains, the application provides a cross-network data security exchange scheme based on the blockchain. The cross-network data security exchange scheme not only can realize cross-network data security exchange and whole-process traceability, but also can solve two major problems of the blockchain in a cross-network scenario: 1. P2P protocol cannot directly communicate, and 2. standard consensus algorithm is prone to failure under high delay.

[0042] The blockchain-based cross-network data security exchange scheme provided by the application first constructs a blockchain-based data security exchange system architecture for a cross-network environment, and further constructs a blockchain cross-network reverse proxy mechanism based on the FTP protocol on this basis.

[0043] The blockchain cross-network reverse proxy mechanism is deployed in a physically isolated network domain formed by a network isolation device, wherein only corresponding blockchain nodes and proxy components are deployed in the physically isolated network, no corresponding FTP server is deployed, and only a set of FTP servers are deployed in the network isolation device; on this basis, the blockchain node in the local network initiates a connection request through the proxy component in the local network, the request is encapsulated by the FTP layer of the proxy component deployed in the local network, and is directly transmitted to the proxy component deployed in the opposite network through the FTP server deployed in the network isolation device; the proxy component in the opposite network actively establishes a connection with the blockchain node in the same network with its own identity after obtaining the request, thereby completing the "reverse proxy", and finally realizing the secure cross-network transmission of the data of the local blockchain node. The "reverse proxy" behavior is the key to adapting the blockchain P2P communication semantics, so that the source node does not need and cannot directly connect to the opposite node, while realizing the cross-network exchange of data and strictly maintaining the network isolation.

[0044] Reference Figure 1 which shows an example of a blockchain-based cross-network data security exchange system architecture formed by the scheme.

[0045] Based on the diagram, the blockchain-based cross-network data security exchange system 100 formed by the scheme of the application is deployed in a cross-network environment.

[0046] In this embodiment, the cross-network environment is composed of network A and network B formed by a network isolation device. The specific structure of the network isolation device is not limited.

[0047] Correspondingly, the cross-network data security exchange system 100 of the application is mainly composed of a plurality of blockchain nodes 110, a plurality of proxy components 120 and a set of FTP servers 130.

[0048] Among them, a set of FTP servers 130 in the system are deployed on the network isolation device, and the FTP server 130 is a centrally deployed centralized file storage and transfer service, which simultaneously establishes a bidirectional connection with the proxy components belonging to network A and network B through the FTP protocol.

[0049] The FTP server 130 receives the file uploaded by any network agent component, which contains cross-network exchange data, and listens to and downloads the corresponding file from the designated directory by the agent component of the opposite network, thereby realizing the safe ferry of data between physically isolated networks.

[0050] The blockchain nodes 110 in the system are respectively deployed in the physically isolated network A and network B. The blockchain nodes deployed in the physically isolated network A and network B constitute an independent consensus unit in each network based on specific deployment settings, and can interconnect with other blockchain nodes in the same network through a P2P mode, communicate based on gRPC protocol, maintain the distributed ledger of the network, and execute the consensus algorithm to process intra-domain transactions and business logic.

[0051] To adapt to cross-network data exchange, the communication module of each blockchain node in the system is configured to be able to stably interact with the agent component of the network through the gRPC protocol, and submit data to be transmitted across the network to the agent component.

[0052] Further, in this embodiment, four blockchain nodes are used for network A and network B: node A is deployed in network A, and nodes B, C, and D are deployed in network B. The three nodes in network B are directly interconnected in a point-to-point (P2P) manner through the gRPC protocol, forming an intra-domain consensus cluster, and together with node A of network A, they form a cross-network blockchain system.

[0053] The agent components 120 in the system are also respectively deployed in the physically isolated network A and network B, for establishing a connection with the blockchain nodes 110 deployed in the network (i.e. the current network where the agent component 120 is deployed, such as network A or network B), and establishing a connection with the FTP server 130 deployed on the network isolation device, and being configured to be able to proxy forward cross-network data based on the FTP protocol.

[0054] Specifically, the agent component 120 here is a component that independently runs based on TCP connection management and FTP protocol design to realize cross-network function of blockchain. The agent component 120 is an independently running process, which is deployed and runs in the physically isolated network, and establishes a connection with the blockchain nodes 110 in the network based on the gRPC protocol. Compared with the simple request-response mode, the gRPC protocol service interface used here is specially configured to support the semantics and mode of P2P communication between blockchain nodes, such as supporting bidirectional streaming.

[0055] At the same time, the agent component 120 establishes a connection with the FTP server 130 based on the FTP protocol.

[0056] In combinationFigure 2 As shown, the proxy component 120 in the system scheme is implemented as a whole architecture mainly including a TCP layer 121 and an FTP layer 122.

[0057] The TCP layer 121 is configured to establish and maintain a long connection with the blockchain nodes 110 in the network, and can provide a stable and reliable communication channel for the blockchain nodes 110 in the network (such as network A or network B).

[0058] Further, the TCP layer 121 is configured to listen to the connection request of the blockchain node deployed in the network and establish a TCP connection with it, accept and format the data submitted by the blockchain node deployed in the network and need to be transmitted across the network, and be responsible for delivering the data to the FTP layer 122 in the same component for subsequent encapsulation and cross-network ferry. Correspondingly, when the FTP layer 122 in the same component obtains data from the opposite network, the TCP layer 121 can accurately send the unpacked data back to the designated target blockchain node in the network.

[0059] As a further setting, the TCP layer 121 is configured to maintain a long connection with the blockchain nodes 110 deployed in the network, and can adjust the transmission control parameters (such as adjusting the retransmission timeout threshold) according to the cross-network delay characteristics, and synchronize the optimization to adapt to the specific requirements of the timeliness of cross-network data exchange, so as to ensure the reliability of the communication within the domain while effectively supporting the stable operation of the cross-network data exchange link.

[0060] As an example, the TCP layer 121 can establish a connection with the blockchain nodes 110 in the network domain through the gRPC protocol.

[0061] The FTP layer 122 is configured to establish a connection with the FTP server 130 deployed on the network isolation device for data interaction, and realize cross-network transmission of message data.

[0062] Specifically, the FTP layer 122 is configured as a protocol conversion and security ferry engine for cross-network data exchange. The FTP layer 122 is configured to establish and maintain a data connection with the FTP server 130 deployed on the network isolation device based on the FTP protocol, and realize cross-network transmission in the form of files; at the same time, the FTP layer 122 can receive data (such as encapsulated GRPC messages or protocol data units) delivered from the TCP layer 121 in the same proxy component, process and encapsulate it into a file format conforming to the FTP standard, and then upload it to the specified directory of the FTP server 130 through the FTP protocol.

[0063] The FTP layer 122 is also set to be able to synchronize continuous monitoring or query the data file uploaded by the opposite network proxy component on the FTP server 130, and after downloading, it is unpacked and the payload is sent back to the TCP layer in the same proxy component.

[0064] Further, the logical cooperation between the FTP layer 122 and the TCP layer 121 in the same proxy component is in layered protocol conversion and relay transmission, that is, the TCP layer 121 is only responsible for reliable gRPC communication with the blockchain node 110 in the network, and the FTP layer 122 is only responsible for file-level ferry outside the network through the FTP protocol, and the data delivery and forwarding between the two is realized through the internal interface.

[0065] Thus, in the proxy component 120 formed, the TCP layer 121 delivers the data or request from the blockchain node in the network to the FTP layer 122 for encapsulation and uploading to the FTP server 130; at the same time, the FTP layer 122 unpacks the opposite data file downloaded from the FTP server 130 and delivers it to the TCP layer 121 in the same component to convert it into a gRPC message and distribute it to the corresponding blockchain node in the network. Through the cooperation of the internal TCP layer and the FTP layer, the proxy component 120 completes the protocol conversion and relay transmission between the gRPC message and the FTP file, thereby realizing the secure exchange of data across the network.

[0066] On the basis of the above system architecture, the application realizes communication through a blockchain cross-network reverse proxy mechanism based on the FTP protocol. The working process of the mechanism mainly includes two stages of connection establishment and message exchange, and the core innovation point is the "reverse proxy" establishment mode of the opposite proxy actively initiating internal connection.

[0067] That is, the blockchain node in the network initiates a connection request through the proxy component deployed in the network, and the request information is encapsulated by the FTP layer of the proxy component and transmitted to the proxy component in the opposite network through the FTP server deployed on the network isolation device; after obtaining the request information, the proxy component in the opposite network actively establishes a connection with the blockchain node in the same network with its own identity, thereby realizing reverse proxy access to the internal services of the opposite network, and finally realizing the secure cross-network transmission of the data of the blockchain node in the network.

[0068] On the basis of the above scheme, the application further gives an optimization scheme, which optimizes the cross-network blockchain consensus algorithm configuration and optimizes the standard parameters of the consensus algorithm, solves the problem of frequent entry into the Recovery state of the cross-network blockchain under the default consensus algorithm configuration, and ensures the normal processing of the cross-network blockchain, such as chain, request, etc.

[0069] Specifically, the key timeout parameters of the PBFT consensus algorithm adopted by the deployed blockchain nodes in the scheme are adaptively optimized and configured, including the corresponding extension of the node state synchronization interval, checkpoint confirmation waiting time, view change timeout and retransmission interval, to match the high delay characteristics of cross-network communication, avoid frequent entry of the system into the recovery state due to consensus timeout, and thus guarantee the stable operation of the blockchain system in the cross-network environment.

[0070] As a further illustration, in the scheme, the interval time for the deployed blockchain nodes to confirm their latest state is adjusted from the standard 1 second to 2 seconds, the waiting time for collecting checkpoint information of the statutory number of nodes is adjusted from the standard 5 seconds to 7 seconds, the timeout length of view change is adjusted from the standard 8 seconds to 16 seconds, and the interval time for retransmitting the view change request is adjusted from the standard 10 seconds to 18 seconds. Such optimization configuration extends the key timeout threshold in the consensus process to adapt to the higher network delay caused by cross-network data exchange, effectively avoids the frequent entry of the blockchain into the recovery state due to communication timeout, and thus guarantees the normal completion of the consensus process and the stable operation of the system in the cross-network environment.

[0071] The following will further illustrate the implementation process of cross-network data security exchange and full-process traceability based on the cross-network data security exchange system based on blockchain given in the present application through specific implementation.

[0072] The cross-network environment in the present example is specifically composed of network A and network B separated by a network isolation device.

[0073] For the physically isolated network A and network B, a cross-network data security exchange system is deployed therein, wherein an FTP server is deployed in the network isolation device, only blockchain node A and proxy component PA are deployed in network A, the blockchain node A and the proxy component PA establish a connection based on the gRPC protocol, and the proxy component PA establishes a connection with the FTP server based on the FTP protocol;

[0074] Meanwhile, only blockchain nodes B, C and D and proxy component PB are deployed in network B, the blockchain nodes B, C and D can respectively establish a connection with the proxy component PB based on the gRPC protocol, and the proxy component PB establishes a connection with the FTP server based on the FTP protocol.

[0075] On this basis, a blockchain cross-network bidirectional proxy mechanism based on the FTP protocol is constructed in the cross-network environment to cooperate with the deployed cross-network data security exchange system to realize cross-network secure transmission of message data between network A and network B.

[0076] In combination with Figure 3 and Figure 4As shown, the cross-network data security exchange system realizes the cross-network secure transmission of message data between network A and network B under the cross-network bidirectional proxy mechanism based on the FTP protocol, mainly including two stages of reverse proxy connection establishment and cross-network message security exchange.

[0077] Firstly, the cross-network connection establishment based on the reverse proxy mechanism, combined with Figure 3 As shown, the connection establishment is realized through the following flow steps:

[0078] S11, the blockchain node A sends a connection establishment request to the TCP port of the proxy component PA in network A, and waits for the physical connection establishment.

[0079] S12, after the proxy component PA listens to the TCP connection establishment, it generates and forwards to the FTP layer, including the P2P port exposed by the blockchain node B.

[0080] S13, after the FTP layer of the proxy component PA receives, the FTP layer will be converted into a file and sent to the FTP server.

[0081] S14, after the FTP layer of the proxy component PB in network B listens to and obtains the file from the FTP server, it will be parsed and sent to the TCP layer.

[0082] S15, according to the instruction, the TCP layer of the proxy component PB initiates and establishes TCP / gRPC connection to the blockchain node B in the same network. Thus, a transparent reverse proxy channel from the blockchain node A to the blockchain node B is established.

[0083] Next, after the connection establishment, enter the cross-network message security exchange stage.

[0084] Here, taking the sending of a message from the blockchain node A in network A to the blockchain node B in network B as an example, combined with Figure 4 , the cross-network message security exchange process will be described in detail.

[0085] S21, the blockchain node A in network A writes the message to be forwarded into the TCP connection established by the proxy component PA.

[0086] S22, after the TCP layer of the proxy component PA listens to and obtains, it is encapsulated with a connection identifier and sent to the FTP layer.

[0087] S23, after the FTP layer of the proxy component PA receives, it will be converted into a file and sent to the FTP server.

[0088] S24, after the FTP layer of the proxy component PB listens to and obtains the file from the FTP server, it will be parsed and sent to the TCP layer of PB.

[0089] S25, the TCP layer of the proxy component PB identifies the identifier, writes the message into the bound connection, that is, the blockchain node B, and the message sending and receiving process ends.

[0090] In the above cross-network data security exchange process, the hash values of key transmission events such as file uploading and downloading operations are recorded on the chain in combination with the non-tamperability of the blockchain and the distributed ledger technology, and the consensus mechanism is used to ensure the authenticity of the log, thereby providing traceability for the whole process.

[0091] The above-mentioned FTP protocol-based blockchain cross-network bidirectional proxy mechanism effectively solves the problem that the blockchain cross-network domain cannot communicate through the P2P protocol, but the corresponding blockchain still works according to the default consensus algorithm configuration, and the blockchain will frequently enter the Recovery state, indicating that the blockchain system cannot complete the consensus.

[0092] To solve the consensus timeout problem caused by cross-network high delay, the key timeout parameters of the practical Byzantine fault tolerance (PBFT) consensus algorithm used are specifically optimized to adapt to the cross-network communication delay and avoid the system frequently entering the Recovery state.

[0093] Specifically, the standard parameters of the PBFT consensus algorithm include Sync_state, Checkpoint, View_change, and Resend_viewchange. In this example, each standard parameter is innovatively optimized to ensure that the cross-network blockchain can normally process chain, request and other work. The specific optimization scheme is as follows:

[0094] (1) Sync_state, the interval time for the consensus node to initiate a request to confirm the latest state of itself, and the quorum nodes are required to be collected within the specified time to judge whether the state of itself is correct, and the standard value of 1 second is adjusted to 2 seconds.

[0095] (2) Checkpoint, the waiting time for collecting the checkpoint information of the quorum nodes when a transaction occurs, which is adjusted from the standard value of 5 seconds to 7 seconds.

[0096] (3) View_change, the timeout length of a view change, which is adjusted from the standard value of 8 seconds to 16 seconds.

[0097] (4) Resend_viewchange, the interval time for resending a view change request, which is adjusted from the standard value of 10 seconds to 18 seconds.

[0098] Through the above targeted extension of the parameters, the tolerance time of each stage of the consensus process is significantly increased, effectively ensuring the stable consensus and normal operation of the blockchain system in the cross-network environment.

[0099] The foregoing is considered as illustrative only of the principles of the application. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the application to the exact construction and practice described. Accordingly, all such variations and modifications are intended to be included within the scope of the application as defined in the following claims and the equivalents thereof.

Claims

1.A blockchain-based cross-network data security exchange system deployed in at least two physically isolated networks of network-isolated devices, characterized in that, The system is composed of at least one first blockchain node and a first proxy component deployed in a first network, at least one second blockchain node and a second proxy component deployed in a second network, and a set of FTP servers deployed on a network isolation device; The FTP server is a separately deployed centralized file storage and transfer service, which simultaneously establishes a bidirectional connection with the proxy components in the first network and the second network through the FTP protocol, can receive files uploaded by the proxy components in any network, which contain cross-network exchange data, and listen to and download corresponding files from the specified directory by the proxy components in the opposite network, to safely ferry data between physically isolated networks; The first proxy component is in communication connection with the first blockchain node and is connected with the FTP server deployed on the network isolation device through the FTP protocol; the second proxy component is in communication connection with the second blockchain node and is connected with the FTP server deployed on the network isolation device through the FTP protocol; The first proxy component is configured to receive a connection request initiated by the first blockchain node and directed to the second blockchain node, and encapsulate the connection request as a first file to send to the second proxy component through the FTP server; The second proxy component is configured to obtain the first file from the FTP server, parse the connection request, and based on the connection request, actively initiate and establish a TCP connection to the second blockchain node, so that the first blockchain node can safely transmit data to the second blockchain node through the first proxy component, the FTP server and the second proxy component through the established connection channel, thereby realizing reverse proxy access; The timeout parameters of the PBFT consensus algorithm used by the first blockchain node and the second blockchain node are set to be extended. 2.The blockchain-based cross-network data security exchange system of claim 1, wherein, The connection between the first proxy component and the first blockchain node, and the connection between the second proxy component and the second blockchain node are established based on the gRPC protocol, and the service interface of the gRPC protocol is configured to support bidirectional streaming of P2P communication between blockchain nodes. 3.The blockchain-based cross-network data security exchange system of claim 1, wherein, Three second blockchain nodes are deployed in the second network, and the three second blockchain nodes are interconnected in a point-to-point manner through the gRPC protocol to form an intra-domain consensus cluster. 4.The blockchain-based cross-network data security exchange system of claim 1, wherein, The FTP server deployed on the network isolation device simultaneously establishes a bidirectional connection with the first proxy component and the second proxy component through the FTP protocol. 5.The blockchain-based cross-network data security exchange system of claim 1, wherein, The first proxy component and the second proxy component each include: A TCP layer configured to establish and maintain a long connection with a blockchain node in the same network to receive and transmit data; An FTP layer configured to interact with the FTP server in the form of files based on the FTP protocol; The TCP layer encapsulates the data received from the blockchain node in the local network into a file and uploads the file to the FTP server; the FTP layer decapsulates the file downloaded from the FTP server and forwards the data to the TCP layer for transmission to the blockchain node in the local network. 6.The blockchain-based cross-network data security exchange system of claim 1, wherein, The system is also configured to upload key event information during cross-network data transmission to the first blockchain node and / or the second blockchain node for trusted notarization. 7.A blockchain-based cross-network data security exchange method, characterized in that, The method is applied to the cross-network data security exchange system according to any one of claims 1-6 and includes: Connection establishment: the first blockchain node initiates a connection request to the second blockchain node to the first proxy component; the first proxy component encapsulates the connection request into a first file and uploads the first file to the FTP server through the FTP protocol; the second proxy component downloads the first file from the FTP server and parses the connection request; the second proxy component initiates and establishes a TCP connection to the second blockchain node based on the parsed connection request, completing the establishment of the reverse proxy connection channel; Data exchange: after the establishment of the connection channel, the data to be transmitted by the first blockchain node is forwarded to the second blockchain node through the first proxy component, the FTP server and the second proxy component; Consensus algorithm optimization: the timeout parameters of the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm used by the first blockchain node and the second blockchain node are extended to adapt to the cross-network communication delay; wherein the node state synchronization interval is adjusted to 2 seconds, the checkpoint confirmation waiting time is adjusted to 7 seconds, the view change timeout length is adjusted to 16 seconds, and the interval time for retransmitting the view change request is adjusted to 18 seconds. 8.The blockchain-based cross-network data security exchange method of claim 7, wherein, The data exchange step includes: the first proxy component encapsulates the gRPC message received by its TCP layer from the first blockchain node into a second file through its FTP layer and uploads the second file to the FTP server; the second proxy component downloads the second file from the FTP server through its FTP layer, decapsulates the second file and converts the second file into a gRPC message through its TCP layer and sends the gRPC message to the second blockchain node. 9.The blockchain-based cross-network data security exchange method of claim 7, wherein, The method further includes a traceable notarization step: uploading key event information in the connection establishment step and / or the data exchange step to the blockchain for notarization. 10.The blockchain-based cross-network data security exchange method of claim 7, wherein, The service interface of the gRPC protocol between the proxy component and the blockchain node is configured to support bidirectional streaming of P2P communication between blockchain nodes.

Images