Database synchronization system in a high-security area using blockchain

Abstract

Systems and methods are provided for a database synchronization system in a high-security zone using blockchain. Service providers such as electronic payment providers can maintain data stores across different zones that can require synchronization of data across the zones. Accordingly, the subject technology uses InterPlanetary File System (IPFS) technology in conjunction with blockchain technology to provide data storage to create a secure, scalable, and reliable data synchronization system. IPFS can be implemented as a data storage layer and blockchain can be implemented as a transaction management system, where IPFS addresses and synchronization points for data files are stored in a distributed ledger. In various aspects, integration of the IPFS network with the fabric network can enhance the IPFS with the fabric network to create a more secure file sharing platform, improving data transfer and database synchronization between different zones.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Application No. 16 / 908,259, filed June 22, 2020, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application generally relates to enterprise storage systems, and more specifically to database synchronization systems in high-security zones using blockchain. Background Technology

[0004] Electronic payment providers can offer users electronic transaction processing services that can be used to send and receive funds with other entities. Some of these electronic payment providers may have multiple regions divided by a network. These individual regions may have their own data storage, which may need to be synchronized between different regions. Attached Figure Description

[0005] Figure 1 A simplified block diagram of a networked multi-zone storage system suitable for implementing the process described herein is shown, according to the implementation method.

[0006] Figure 2 A detailed block diagram of a networked multi-zone storage system suitable for implementing the process described herein is shown, according to the implementation method.

[0007] Figure 3 A flowchart illustrating push transactions for transferring data between different regions, based on the implementation method, is shown.

[0008] Figure 4 A flowchart illustrating a pull transaction for transferring data between different regions, based on its implementation, is shown; and

[0009] Figure 5 The appropriate implementation is shown based on the implementation method. Figure 1 A block diagram of a computer system consisting of one or more components;

[0010] The implementations of this disclosure and their advantages can be best understood by referring to the following detailed description. It should be understood that similar reference numerals are used to identify similar elements shown in one or more of the figures, wherein the contents shown in the figures are for illustrative purposes only and not for limiting the implementations of this disclosure. Detailed Implementation

[0011] Technological advancements in computer technology and telecommunications have enabled businesses and end-users to participate in electronic activities more extensively than ever before. For example, progress has been made in peer-to-peer (P2P) hypermedia protocols designed to make the internet faster, more secure, and more open. Furthermore, blockchain technologies, such as Hyperledger Fabric networks, have advanced to enhance the security of electronic transactions.

[0012] A blockchain system can comprise blocks linked together using cryptography. Each block can individually consist of a subset of records. Compared to conventional secure storage systems, blockchain systems are more resistant to modification of the data stored in the blocks. A blockchain system is a decentralized data management platform that is not easily altered or changed. Generally, there are two types of blockchains: permissionless and permission-managed. Permissionless blockchain networks (e.g., Ethereum, Bitcoin) are open to the public, and every transaction is verified by each participant or a majority of participants. Permission-managed blockchain networks are private networks where certified users can join. For example, Hyperledger Networks is a permission-managed blockchain technology. Hyperledger Networks are private because certified users in a Hyperledger Networks network know each other, and certified users are permitted to join. In some respects, verification in this type of blockchain network is performed by a set of certified nodes. Therefore, permission-managed blockchain networks typically achieve higher performance than permissionless blockchain networks.

[0013] In peer-to-peer networks such as the InterPlanetary File System (IPFS), if one node fails, other nodes in the IPFS network can provide the necessary files. IPFS can be used to share files on private networks or over the Internet via IPFS gateways. IPFS enables users to share large files because it uses local hosting, which reduces the bandwidth requirements typically associated with sharing large files over a network. When a file is uploaded to IPFS, all nodes with hashed addresses can access the content and download and view it locally.

[0014] A method for database synchronization systems in high-security zones using blockchain is provided. Systems suitable for implementing the methods disclosed herein are also provided. Service providers such as electronic payment providers may maintain data storage across different regions, which may require data synchronization across these regions. Therefore, the subject matter technology uses a combination of IPFS and blockchain technology to provide data storage, creating a more secure, scalable, and reliable data synchronization system. IPFS can be implemented as a data storage layer, and blockchain can be implemented as a transaction management system, where the IPFS addresses and synchronization points of data files are stored in a distributed ledger. In various respects, the integration of the IPFS network with the Hyperledger Infrastructure network can be termed "BlockIPFS". BlockIPFS can enhance IPFS through the Hyperledger Infrastructure network to create a more secure file-sharing platform, improving data transfer and database synchronization between different regions.

[0015] Topic technology offers several benefits in enterprise storage systems, such as allowing nodes to become individual servers that can provide content to others within the IPFS network, significantly reducing the need for additional bandwidth on the network. The IPFS network can partition data and use content addressing to store related data items, enabling the transmission of large amounts of data over the network without a significant increase in network bandwidth. Hyperledger Fabric networks may not incur high storage or network overhead because the amount of metadata stored in a Hyperledger Fabric network is significantly smaller than the raw data stored in an IPFS network. For efficient searching, the ledger data maintained within a Hyperledger Fabric network can be indexed. Topic technology provides additional security using a Hyperledger Fabric network with a set of trusted nodes that can access and modify data. Topic technology also scales to synchronize increasing amounts of data storage and different types of data storage.

[0016] In some implementations of this subject matter, a service provider server, such as an electronic transaction server, may receive a request at a first data computing engine in a first region to transfer a data item from a source database in the first region to a target database in a second region, distinct from the first region, via an encrypted communication channel associated with a distributed ledger network. In some aspects, the service provider server may host the source and target databases in different regions. In some examples, the distributed ledger network may refer to a Hyperledger Fabric network utilizing blockchain technology. The first data computing engine may use a database client in response to the request to retrieve the data item from the source database via a database connection connected to the source database. The first data computing engine may use a peer-to-peer storage client to generate a hash address from the content of the data item using a hash algorithm. The first data computing engine may use a peer-to-peer storage client to store the data item in a data structure of at least one of a plurality of first node devices associated with a peer-to-peer distributed file storage network in the first region. In some examples, the peer-to-peer distributed file storage network may refer to an IPFS network. The first data computing engine can use a distributed ledger client to store configuration information and hash addresses associated with data items into a ledger on at least one of a plurality of second node devices associated with a distributed ledger network in the first region. The first data computing engine can use the distributed ledger client to send queries to update the ledger on each of the plurality of second node devices with status information indicating a push transaction corresponding to storing the data item in the distributed file storage network, thereby synchronizing the target database with the source database based on the push and pull transactions for the data item. In various respects, pull transactions are initiated by the second data computing engine in the second region and are determined according to their function.

[0017] Figure 1 A simplified block diagram of a networked multi-region storage system 100, adapted to implement the processes described herein, is shown. The networked multi-region storage system 100 includes a service provider server 110, an IPFS node 130, a blockchain node 140, a blockIPFS node 150, a source database 160, and a communication device 170, all communicatively coupled to each other via a network 190. The networked multi-region storage system 100 also includes a service provider server 120, a target database 162, and a communication device 180, all communicatively coupled to each other via a network 192. The networked multi-region storage system 100 further includes IPFS nodes 130, blockchain nodes 140, and blockIPFS nodes 150 communicatively coupled to the service provider server 120 via network 192.

[0018] In some implementations, the networked multi-region storage system 100 also includes networks 194 and 196. In some examples, network 194 may refer to the IPFS network and network 196 may refer to the Hyperledger Infrastructure network. In this respect, IPFS node 130 may be communicatively coupled to networks 190 and 192 via network 194. Similarly, blockchain node 140 may be communicatively coupled to networks 190 and 192 via network 196. blockIPFS node 150 may be communicatively coupled to networks 190 and 192 via either network 194 or network 196, because blockIPFS node 150 has clients that support access to IPFS networks (e.g., 194) and Hyperledger Infrastructure networks (e.g., 196). As discussed above, network 194 may be a decentralized file system network operating with faster and more efficient data storage capabilities compared to conventional storage systems. Network 194 allows compute nodes such as IPFS node 130 and / or blockIPFS node 150 to share files and information over network 194. Network 194 can manage the storage of large files that may consume or require significant bandwidth for uploading and / or downloading over network 194. In some respects, network 194 can operate on top of different protocols such as File Transfer Protocol (FTP) and Hypertext Transfer Protocol (HTTP).

[0019] In one implementation, each of networks 190 and 192 can be implemented as a single network or a combination of multiple networks. For example, in various implementations, each of networks 190 and 192 can include the Internet and / or one or more intranets, terrestrial networks, wireless networks, and / or other suitable types of communication networks. In another example, each of networks 190 and 192 can include a wireless telecommunications network (e.g., a cellular telephone network) suitable for communicating with other communication networks such as the Internet. In some examples, network 190 can refer to a first trusted area and network 192 can refer to a second trusted area. In some aspects, the first trusted area can correspond to a first geographical area and the second trusted area can correspond to a second geographical area (the second geographical area is different from the first geographical area). In other aspects, the first trusted area can correspond to a first network barrier and the second trusted area can correspond to a second network barrier (the second network barrier is different from the first network barrier). In still other aspects, the first trusted area can correspond to a network with a first access level and the second trusted area can correspond to a network with a second access level (the second access level is different from the first access level).

[0020] In one implementation, the service provider server 110 may be maintained by a transaction processing entity or electronic service provider that can provide electronic services (e.g., selling goods, purchasing goods, executing electronic transactions, authenticating transactions, etc.). Therefore, the service provider server 110 may include a service application 111 adapted to interact with communication equipment 170 via network 190 to facilitate searching, selecting, purchasing items and / or other services offered by the service provider server 110, and making payments for items and / or other services offered by the service provider server 110. In one example, the service provider server 110 may be provided by PayPal® Inc. of San Jose, California, USA, and / or one or more financial institutions or corresponding intermediaries that may provide multiple points of sale in various locations to facilitate transaction paths between merchants and, for example, financial institutions. In various implementations, the service provider server 110 may also include a data processing engine 110-A, a web interface 115, a configuration repository or table 116, a historical process repository or table 117, and a workflow engine 118. The data computing engine 110-A includes a database client 112, an IPFS client 113, and a structure client 114.

[0021] In some implementations, service application 111 is suitable for processing the purchase and / or payment of financial transactions between users and merchants. In one implementation, service application 111 assists in resolving financial transactions through verification, delivery, and settlement. Thus, service application 111 resolves debts between users and merchants, where accounts can directly and / or automatically debit and / or credit monetary funds in a banking-acceptable manner.

[0022] Database client 112 is adapted to interact with source database 160 using a database communication protocol via a dedicated communication channel to source database 160. Database client 112 can perform various data storage operations on source database 160, such as read operations, write operations, and / or erase operations. As used herein, a read operation may be referred to as a "pull operation," and a write operation may be referred to as a "push operation."

[0023] IPFS client 113 is adapted to interact with IPFS node 130 and / or blockIPFS node 150 via network 194 using IPFS-specific communication protocols. IPFS client 113 can perform various data storage operations, such as read or write operations, with IPFS node 130 and / or blockIPFS node 150 according to the IPFS-specific communication protocols. In some aspects, IPFS client 113 includes a hash algorithm module (not shown) for performing hash operations on data items to generate content-based hash addresses for IPFS storage location indexing. In this respect, IPFS client 113 can provide the content-based hash address along with the data item to be stored to IPFS node 130.

[0024] Structure client 114 is adapted to interact with blockchain node 140 and / or blockIPFS node 150 via network 196 using a Hyperledger structure-specific communication protocol. Structure client 114 can perform different ledger operations, such as read operations (e.g., to obtain metadata stored in the ledger) or write operations (e.g., to store metadata in the ledger), according to the Hyperledger structure-specific communication protocol. In the Hyperledger structure network (e.g., 196), each of blockchain node 140 and blockIPFS node 150 can be responsible for managing metadata related to data items stored in the IPFS network (e.g., 194) and the blockchain ledger (e.g., the ledger may store transaction-related metadata).

[0025] Web interface 115 may include a client-side interface to allow communication device 170 to interact with service provider server 110. For example, web interface 115 may include software programs executable by the processor of service provider server 110, such as a graphical user interface (GUI), adapted to be a user interface associated with communication device 170. Web interface 115 may include a browser application that supports data connections between service provider server 110 and communication device 170. Web interface 115 may be adapted to receive user input, such as requests to initiate push operations to synchronize source database 160 and target database 162 between network 190 and network 192. For example, user input may include channel configuration indicating whether to use the same channel between the data source and the data destination or to use different channels between the data source and the data destination. In some aspects, channels are formed based on the presence of source databases and / or target databases. In some implementations, each source database having a data connection to a unique target database may operate on a different channel.

[0026] Configuration repository 116 may be a repository suitable for storing configuration information input via web interface 115. Configuration information may include database identifiers (e.g., identifying source database 160), table identifiers (e.g., identifying a data structure containing one or more data items), user identifiers, column identifiers (e.g., identifying a specified area in a data structure containing a list of entities that store data items in the network), scheduling frequency, and channel identifiers (e.g., identifying a channel between source database 160 and target database 162).

[0027] Historical process repository 117 may be a repository suitable for storing a list of push transactions that are identified in the network 190 of the networked multi-region storage system 100. For example, each new push transaction that synchronizes and / or transfers data from source database 160 to target database 162 is stored in (or recorded thereon) historical process repository 117.

[0028] Workflow engine 118 may include software programs executable by the processor of service provider server 110, adapted to initiate processes based on the availability of data computing engine 110-A. Workflow engine 118 may be implemented as a process management system coordinating the operation (or execution) of all processes. In some aspects, workflow engine 118 retrieves details from configuration information stored in configuration store 116. For example, workflow engine 118 may retrieve details from configuration information and initiate (or invoke) client processes on data computing engine 110-A. In various aspects, workflow engine 118 manages the channels formed between source database 160 and target database 162. In some aspects, if a channel does not exist (or has not yet been created), workflow engine 118 creates a channel based on configuration information. In some implementations, the channel may include a dedicated encrypted channel to provide secure data communication between source database 160 and target database 162.

[0029] In various implementations, the service provider server 110 includes at least one network interface component 119, which is adapted to communicate with IPFS node 130, blockchain node 140, blockIPFS node 150, and / or other entities via network 190. In various implementations, the network interface component 119 may include a modem, Ethernet device, broadband device, satellite device, and / or various other types of wired and / or wireless network communication devices, including microwave, radio frequency (RF), and infrared (IR) communication devices.

[0030] IPFS node 130 includes IPFS client 132 and IPFS daemon 134. IPFS client 132 is adapted to interact with IPFS client 113 in data computation engine 110A within service provider server 110 via network 194 (e.g., the IPFS network) and network 190 (e.g., a first trusted zone) using IPFS-specific communication protocols. IPFS daemon 134 may be a background process facilitating operations performed by IPFS client 132. In some aspects, IPFS client daemon 132 may perform various local data storage operations, such as storing the raw content of data items in the local memory of IPFS node 130. In some aspects, IPFS client 132 includes a hash algorithm module (not shown) for performing a hash operation on data items to generate a content-based hash address for IPFS storage location indexing. On IPFS, data items are content-addressed, not location-addressed. When a data item is added to the network, IPFS client 132 can create a multi-hash address for the data item based on its content and node identifier (ID), ensuring that no two data items share the same multi-hash address. The node ID can be a cryptographic hash of the node's public key (e.g., IPFS node 130, blockIPFS node 150). To allow other nodes (e.g., IPFS node 130, blockIPFS node 150) to access the data item, the multi-hash address can be stored in a ledger maintained by nodes of the Hyperledger Fabric network (e.g., blockchain node 140, blockIPFS node 150). In some respects, IPFS node 130 using IPFS client 132 (or blockIPFS node 150 using IPFS client 152) can search for data items by their content identifier (CID) rather than by their location. For example, any IPFS client 132 with a hash address of content (obtained from the ledger stored in the Hyperledger Structure network) can search for a specific data item on network 194, and any IPFS client 132 with a matching data item can serve it. Therefore, data items on network 194 can be served as long as there is an IPFS node capable of serving them. Network 194 can eliminate content duplication by ensuring that data items with the same content uploaded by a specific IPFS node are stored only once. Although Figure 1 An instance of IPFS node 130 is shown, but multiple instances of IPFS node 130 can exist to form a network of IPFS nodes within network 194.

[0031] Blockchain node 140 includes a structure client 142, chaincode 144, and a ledger 146. Structure client 142 is adapted to interact with structure client 114 in the data computation engine 110-A of service provider server 110 via networks 196 and 190 using a Hyperledger structure-specific communication protocol. Structure client 142 can perform various ledger operations according to the Hyperledger structure-specific communication protocol, such as read operations (e.g., to obtain metadata stored in ledger 146) or write operations (e.g., to store transaction-related metadata in ledger 146). In network 196, structure client 142 may be responsible for managing metadata related to data items stored in network 194. Chaincode 144 may be a software program and / or logic implementing a defined interface for initializing and managing ledger state through transactions submitted by structure client 114 at data computation engine 110-A. For example, chaincode 144 may record ledger state indicating a push state, where data items stored in network 194 are intended to be pushed to target database 162 based on network 192. In some respects, chaincode 144 can be referred to as a "smart contract." Ledger 146 can be a decentralized data structure distributed across different nodes in network 196. Ledger 146 can have a complete history and trusted record of data items stored in network 194, such as which entity created the data item and when, which entity accessed the data item and how, and which entity (or which entities) can access which file. Raw data is stored in storage devices managed by IPFS node 130 and / or blockIPFS node 150, rather than blockchain node 140. The blockchain also provides an additional means of sharing multi-hash addresses based on the content of data items. Once a data item is added to network 194 and a multi-hash address is added to ledger 146, all members of network 196 can access that hash address. However, in various aspects, IPFS operations and their associated metadata storage are synchronized across the Hyperledger Fabric network based on network 196 to ensure continuity. Despite Figure 1 An instance of blockchain node 140 is shown, but multiple instances of blockchain node 140 may exist to form a network of blockchain nodes within network 196.

[0032] The blockIPFS node 150 includes an IPFS client 152 and a structure client 154. In some implementations, IPFS client 152 can be similar to IPFS client 132, and structure client 154 can be similar to structure client 142. Although Figure 1 An instance of blockIPFS node 150 is shown, but multiple instances of blockIPFS node 150 may exist to form a network of blockIPFS nodes coexisting in network 194 and network 196.

[0033] like Figure 1 The service provider server 120, as depicted, also includes a service application 121, a database client 122, an IPFS client 123, a schema client 124, a web interface 125, a configuration repository 126, a history repository 127, a workflow engine 128, and a network interface component 129. For simplicity, the service provider server 120 may include components similar to those in the service provider server 120. For example, service application 121 may be similar to service application 111. Database client 122 may be similar to database client 112. IPFS client 123 may be similar to IPFS client 113. Schema client 124 may be similar to schema client 114. Web interface 125 may be similar to web interface 115. Configuration table 126 may be similar to configuration table 116. History repository 127 may be similar to history repository 117. Workflow engine 128 may be similar to workflow engine 118. Network interface component 119 may be similar to web interface component 129.

[0034] In various implementations, communication device 170 (depicted as "communication device A") can be implemented using any suitable combination of hardware and / or software configured to perform wired and / or wireless communication over network 190. In various implementations, communication device 180 (depicted as "communication device B") can be implemented using any suitable combination of hardware and / or software configured to perform wired and / or wireless communication over network 192. For example, in one embodiment, each of communication devices 170 and 180 can be implemented as: a personal computer (PC), a smartphone, a smartphone with additional hardware such as an NFC chip, BLE hardware, etc., a wearable device with similar hardware configuration such as a gaming device, a virtual reality headset, or a hardware configuration that interacts with a smartphone with a unique hardware configuration and running appropriate software, a laptop computer, and / or other types of computing devices capable of transmitting and / or receiving data.

[0035] Communication device 170 can install and execute client-side service application 172 received from transaction processing server 110 to facilitate one or more transaction processes (e.g., peer-to-peer payments). Client-side service application 172 can allow a user to send a transaction request to service provider server 110, which includes communication of data or information such as funding source information required to complete the request.

[0036] Communication device 170 may include push configuration module 174, which can be used, for example, to initiate a database synchronization mechanism. For instance, a user associated with communication device 170 may use an IPFS system with enhanced security to initiate a request to transfer data from source database 160 to target database 162 via a Hyperledger Fabric network. In other aspects, the request to initiate data transfer may be invoked by an authentication operation as part of an electronic service transaction process.

[0037] Communication device 180 can install and execute client-side service application 182 received from transaction processing server 110 to facilitate one or more transaction processes (e.g., peer-to-peer payments). In some aspects, client-side service application 182 can collaborate with client-side service application 172 of communication device 170 to facilitate transactions between source database 160 and target database 162. Communication device 180 may include pull configuration module 184, which can be used, for example, to perform database synchronization mechanisms. For example, a user associated with communication device 180 can use an IPFS system with increased security provided by a Hyperledger Fabric network to initiate a request to retrieve data being transferred from source database 160 to target database 162. In some aspects, pull configuration 184 can manage requests to pull data from IPFS nodes (e.g., 130) for storage at target database 162.

[0038] Figure 2 A detailed block diagram of a networked multi-region storage system 200, adapted to implement the processes described herein, is shown. For the sake of brevity, the networked multi-region storage system 200 can be similar to... Figure 1 A networked multi-region storage system, such that the components in the networked multi-region storage system 200 correspond to Figure 1 Components in a networked multi-region storage system. Therefore, Figure 2 The discussion will refer to Figure 1 The components described in the networked multi-region storage system are used.

[0039] like Figure 2The depicted networked multi-zone storage system 200 includes service provider server 110 and service provider server 120 communicatively coupled to network 194 (e.g., an IPFS network) and network 196 (e.g., a Hyperledger Fabric network). The networked multi-zone storage system 200 can facilitate database synchronization between trusted (or highly secure) zones using blockchain and IPFS storage systems. For example, service provider server 110 can act as a sender of data from source databases (e.g., 160-1, 160-2), and service provider server 120 can act as a receiver of transmitted data for storage in target databases (e.g., 162-1, 162-2). Service provider server 110 may have multiple client devices, such as client 110-A1 (depicted as "sender client A") and client 110-A2 (depicted as "sender client B"), to facilitate push transactions of data to source databases 160-1 and 160-2 via corresponding interfaces. In each respect, each of clients 110-A1 and 110-A2 corresponds to data computing engine 110-A. Similarly, service provider server 120 may have multiple client devices, such as client 120-B1 (described as "receiving client A") and client 120-B2 (described as "receiving client B"), to facilitate pull transactions of data through corresponding interfaces to target databases 162-1 and 162-2. In each respect, each of clients 120-B1 and 120-B2 corresponds to data computing engine 120-B.

[0040] For the purpose of explanation, the following description will refer to push transactions from the perspective of network 190 as the first trusted area (where network 192 is the second trusted area).

[0041] Users associated with communication device 170 (e.g., network administrators) can interact with service provider server 110 via web interface 115. In some aspects, users can provide configuration to service provider server 110 to manage push transactions to target database 162 via traversing networks 190 to 196. For example, a web application module using web interface 115 of communication device 170 can receive a configuration file including configuration information (or metadata). In some aspects, the configuration information may include one or more of the following: a database identifier (e.g., object namespace) identifying target database 162, a table identifier (e.g., UID column name) identifying a location within a data structure of target database 162, a unique identifier (e.g., UID value) indicating the epoch column providing the synchronization point to source database 160, and / or a channel identifier indicating an encrypted communication channel between source database 160 and target database 162. Web interface 115 can initiate write operations with a first data store to store configuration table 116 in a data structure of the first data store. The web interface 115 can also interface to the workflow engine 118, and the first data storage is communicatively coupled to the web application module.

[0042] Workflow engine 118 can obtain a configuration file from configuration table 116 in a data store, which includes configuration information. The data store is communicatively coupled to workflow engine 118. Workflow engine 118 can then determine if a channel identifier exists in the configuration information. In some aspects, the channel identifier may indicate the existence of a dedicated communication channel between source database 160 and target database 162. In some aspects, when the channel identifier does not exist in the configuration information, the workflow engine establishes an encrypted communication channel. Otherwise, workflow engine 118 can locate and utilize existing communication channels to facilitate database synchronization and / or data transfer between different trusted areas.

[0043] Workflow engine 118 can then initiate one or more client processes, each corresponding to a data transfer process for transferring data from network 190 (e.g., a first trusted zone) to network 192 (e.g., a second trusted zone). For example, workflow engine 118 can initiate a client process on each of clients 110-A1 and 110-A2. In some aspects, workflow engine 118 can access a second data store and record each data transfer process in the corresponding data transfer process in a history process table 117 in the second data store, which is communicatively coupled to workflow engine 118, before initiating a client process. In some implementations, workflow engine 118 can select client 110-A1 or client 110-A2 based on the available resources of clients 110-A1 and 110-A2. In some aspects, workflow engine 118 selects the client with the most available resources. In other respects, workflow engine 118 can select client 110-A1 or client 110-A2 based on other aspects of network resource allocation.

[0044] In some implementations, a first data computation engine in a first region, such as client 110-A1 in network 190, can receive a request from workflow engine 118 to transfer data items from source database 160-1 in the first region to a target database 162-1 in a second region via an encrypted communication channel associated with a distributed ledger network such as network 196. In this regard, client 110-A1 can connect to source database 160-1 via a dedicated database connection. In some implementations, a database client (e.g., 112) of client 110-A1 can, in response to the request, retrieve the data items from source database 160-A1 via a dedicated database connection to source database 160-A1. In some aspects, client 110-A1 uses the database client to record the time when data items are retrieved from source database 150-1. In this regard, synchronization points are generated to indicate the time when the data items were last refreshed (or updated) at source database 150-1. In some aspects, the location of the data item retrieved within the source database 160-1 can be obtained to update the configuration information, enabling the data item to be stored at the corresponding location in the target database 162-1 (e.g., via a table identifier). In other aspects, the data item is retrieved at the location corresponding to the configuration information within the source database 160-1. In some implementations, the distributed ledger network includes a proprietary blockchain network comprising multiple second-node devices (e.g., 140-1, 140-2, 150-1, 150-2), each of which is an authenticated node device (or a permitted member of network 196).

[0045] In some implementations, the distributed storage client 110-A1 (e.g., IPFS client 113) can generate a hash address from the content of a data item using a hash algorithm. In some implementations, the hash address includes an encoded representation of the content of the data item. In some implementations, the distributed storage client can use a cryptographic hash function to create a fingerprint. In some aspects, the distributed storage client can implement a tamper-proof SHA256 hash algorithm to ensure the security and authenticity of files added to network 194. In some examples, the content of the data item can be represented using a multi-hash format and base58 encoding. In some implementations, the distributed storage client takes the original content of the data item and runs it through a hash function to produce a digest. This digest can be cryptographically unique for the content of the data item. If an entity modifies the data item, even by a single bit, the hash address may become completely different. In some aspects, the distributed file storage client can generate a hash address from the content of a data item using a hash algorithm. When generating a hash address, the distributed file storage client can process the content of the data item using the first hash function of the hash algorithm to generate a digest that is unique to the content of the data item, and then convert the digest into a hash address using the second hash function of the hash algorithm.

[0046] Once a hash address has been generated, an IPFS node can store the original content of a data item within the IPFS network. In some implementations, the distributed storage client 110-A1 can store the data item in a data structure of at least one of a plurality of first node devices associated with a distributed file storage network (e.g., network 194) in a first region. For example, client 110-A1 can access one of the nodes associated with network 194, such as node 130-1 and / or node 150-1, via the distributed storage client to perform local storage operations at one of the IPFS nodes. In some aspects, node 130-1 includes an IPFS client (similar to IPFS client 132), and node 150-1 includes an IPFS client (similar to IPFS client 152) and a structure client (similar to structure client 154). In some aspects, node 130-1 may be associated with network 194 (e.g., the IPFS network), while node 150-1 may be associated with both network 194 and network 196 (e.g., the Hyperledger Structure Network).

[0047] Once a data item is stored in the IPFS network, the Hyperledger Structure Network can store the hash address in the ledger to add security and tracking capabilities to the data item stored in IPFS. In some implementations, the distributed ledger client of client 110-A1 (e.g., structure client 114) can store configuration information and the hash address associated with the data item in the ledger on at least one of a plurality of second node devices associated with the distributed ledger network (e.g., network 196) in the first region. For example, client 110-A1 can access one of the nodes associated with network 196, such as node 140-1 and / or node 150-1, via the distributed ledger client to store the hash address in the ledger at one of the blockchain nodes (e.g., ledger 146). In some aspects, node 140-1 includes a structure client (similar to structure client 142), and node 150-1 includes a structure client (similar to structure client 154). In some respects, node 140-1 can be associated with network 196 (e.g., the Hyperledger Structure network), while node 150-1 can be associated with both network 194 and network 196.

[0048] In some implementations, client 110-A1 can utilize a distributed ledger client to generate metadata for data items. This metadata may include a hash address of the target database 162, a UID column name, a UID value, and an object namespace (or namespace identifier). In some aspects, the metadata indicates the transaction history of the data item. In some implementations, the distributed ledger client can encode the metadata into encoded metadata accessible to each of the multiple second-node devices (e.g., nodes 140-1, 140-2, 150-1, 150-2). The distributed ledger client can initiate a storage operation to store the encoded metadata as ledger data in ledger 146 on at least one of the multiple second-node devices.

[0049] Once the hash address has been securely stored in the ledger of one of the blockchain nodes, the blockchain node's structure client can update the ledger state, notifying and / or providing access to other blockchain nodes (e.g., certified members of network 196) in the first trusted area (e.g., network 190) and the second trusted area (e.g., network 192). In some implementations, the distributed ledger client of client 110-A1 can send queries to update the ledger on each of a plurality of second node devices (e.g., 140-1, 140-2, 150-1, 150-2) with state information indicating a first type of transaction (e.g., a push transaction) corresponding to storing data items in the distributed file storage network (e.g., network 196), so as to synchronize the target database 162 with the source database 160 based on the first type of transaction and the second type of transaction (e.g., a pull transaction) of the data item. In this regard, to complete database synchronization, push and pull transactions are required to ensure that the target database 162 successfully receives the data items and synchronization information, thereby successfully synchronizing its content with the source database 160. In some aspects, data items can be stored in the target database 162-1 based on the synchronization point and table identifier included in the configuration information stored in configuration table 116. Therefore, a push transaction can include an indication of which target database stores the data items and, within that target database, where the data items are stored.

[0050] In some implementations, the status information prompts the second data computation engine (e.g., client 120-B1, client 120-B2) in the second region to retrieve data items from at least one of the multiple first node devices (e.g., node 130-2, node 150-2) in the second region associated with the distributed ledger network, based on a hash address obtained from at least one of the multiple second node devices (e.g., node 140-2, node 150-2) in the second region associated with the distributed ledger network; and to store the data items in a data structure of the target database 162. For example, updates to the ledger status information, such as indicating that a push transaction has occurred within network 196, prompt the updated status information to notify nodes in network 192 (e.g., nodes in the second trusted region) of the push transaction. In this regard, client 120-B1 may be invoked, for example, to facilitate pull transactions by traversing push transactions to retrieve data items. Therefore, the hash address can be obtained from one of the structure clients (e.g., structure client 140-2), and the hash address can be used to locate the IPFS node storing the data item (e.g., 130-1, 130-2).

[0051] In some implementations, generating a hash address includes: using a distributed file storage client with a first data computation engine to divide a data item into multiple data chunks of a predetermined size based on configuration information; using the distributed file storage client with the first data computation engine to process each of the multiple data chunks using a first hash function of a hash algorithm to generate a digest unique to the content of the data chunk; using the distributed file storage client with the first data computation engine to convert the digest of each of the multiple data chunks into a corresponding content identifier among multiple content identifiers using a second hash function of a hash algorithm; and using the distributed file storage client with the first data computation engine to combine the multiple content identifiers into a hierarchical data structure to compute a hash address.

[0052] Users associated with communication device 180 (e.g., network administrators) can interact with service provider server 120 via web interface 125. In some aspects, users can provide configuration to service provider server 120 to manage pull transactions to target database 162 via traversing networks 192 to 196. For example, a web application module using web interface 125 of communication device 180 can receive a configuration file including configuration information (or metadata). In some aspects, the configuration information may include one or more of the following: a database identifier identifying target database 162, a table identifier identifying a location within a data structure of target database 162, a unique identifier indicating the epoch column providing the synchronization point to source database 160, a channel scan frequency, and / or a channel identifier indicating an encrypted communication channel between source database 160 and target database 162. In some implementations, the configuration file in network 190 may be similar to the configuration file in network 192 to facilitate collaboration in database synchronization between network 190 and network 192. In some respects, the web interface 125 can initiate write operations with the first data store to store the configuration table 126 in the data structure of the first data store, which is communicatively coupled to the web application module. The web interface 125 can also interface to the workflow engine 128.

[0053] For the purpose of explanation, the following description will refer to pull transactions from the perspective of network 192 as the first trusted region (where network 190 is now the second trusted region).

[0054] Workflow engine 128 can obtain a configuration file from configuration table 126 in a data store, which includes configuration information, and the data store is communicatively coupled to workflow engine 128. Workflow engine 128 can then initiate one or more client processes, each corresponding to a data transfer process for transferring data from network 190 (e.g., a first trusted zone) to network 192 (e.g., a second trusted zone). For example, workflow engine 128 can initiate a client process on each of clients 120-B1 and 120-B2. In some aspects, workflow engine 128 can access a second data store and record each data transfer process in the corresponding data transfer process in a history process table 127 in the second data store, which is communicatively coupled to workflow engine 128, before initiating the client process. In some implementations, workflow engine 128 can select client 120-B1 or client 120-B2 based on the available resources of clients 120-B1 and 120-B2.

[0055] In some implementations, a first data computation engine in a first region, such as client 120-B2 in network 192, can receive status information indicating a first type of transaction (e.g., a push transaction) of data items sent from a source database (e.g., source database 160-1) in a second region (e.g., network 190) to a target database (e.g., target database 162-1) in a first region (e.g., network 192) via an encrypted communication channel associated with a distributed ledger network (e.g., network 196), which is different from the first region.

[0056] In some implementations, the distributed ledger client of client 120-B1 (e.g., structural client 124) can determine that a first type of transaction (e.g., a pull transaction) can be accessed by network 192 via an encrypted communication channel from at least one of a plurality of first node devices (e.g., nodes 140-2, 150-2) associated with the distributed ledger network in the first region. For example, if the last ledger state indicates that a push transaction has occurred, client 120-B1 can use the distributed ledger client to check the encrypted communication channel used for the push transaction.

[0057] In some implementations, the distributed ledger client of client 120-B1 can obtain metadata (e.g., push transaction metadata) of data items from at least a portion of a first type of transaction in a ledger stored on at least one of the multiple first node devices. In some implementations, the distributed ledger client of client 120-B1 can receive metadata from the ledger via chaincode hosted on at least one of the multiple first node devices. For example, the distributed ledger client of client 120-B1 can access ledger state information from chaincode 144 of at least one of the multiple first node devices associated with network 196. In some aspects, the distributed ledger client of client 120-B1 can recover the hash address of a data item from the metadata. In recovering the hash address, the distributed ledger client can apply decoding functionality.

[0058] Once the hash address is obtained, the distributed storage client of client 120-B1 (e.g., IPFS client 123) can retrieve data items from at least one of the multiple second node devices (e.g., nodes 130-2, 150-2) associated with the distributed file storage network in the second region based on the hash address.

[0059] Once the data item is retrieved by the IPFS client of client 120-B2, the database client of client 120-B2 is invoked. In some implementations, the database client of client 120-B1 (e.g., database client 123) may store the data item in the data structure of the target database 162-1 based on the namespace identifier of the target database 162-1 from the metadata. In some aspects, the data item may be stored in one or more memory locations of the synchronization point in the data structure of the target database 162-1 following the source database 160-1. In this respect, client 120-B1 uses the database client to identify the synchronization point in the data structure of the target database 162-1 that corresponds to at least a portion of the data structure in the source database 160-1 based on the metadata.

[0060] In some implementations, the distributed ledger client 120-B1 can send queries to update the ledger on each of a plurality of first node devices with status information indicating a second type of transaction (e.g., a pull transaction) corresponding to the retrieval of data items from the distributed file storage network and the storage of the data items in the target database 162-1. In some aspects, the target database 162-1 is synchronized with the source database 160-1 based on the first type of transaction (e.g., a push transaction) and the second type of transaction (e.g., a pull transaction) of the data items.

[0061] Figure 3A flowchart illustrating a push transaction for transferring data between different regions, depending on the implementation, is shown. One or more steps 302 through 308 of process 300 may be implemented, at least in part, in the form of executable code stored on a non-transitory tangible machine-readable medium, which, when run by one or more processors, causes one or more processors to perform one or more steps 302 through 308. Some examples of computing devices, such as computing system 500, may include a non-transitory tangible machine-readable medium containing executable code that, when run by one or more processors (e.g., processor 512), causes one or more processors to perform the steps of process 300. As shown, process 300 includes a number of enumerated steps, but various aspects of process 300 may include additional steps before, after, and between the enumerated steps. In some aspects, one or more of the enumerated steps may be omitted or performed in a different order.

[0062] Process 300 begins at step 302, where a first data computation engine in the first region can receive a request to transfer data items from a source database in the first region to a target database in a second region, which is different from the first region, via an encrypted communication channel associated with the distributed ledger network.

[0063] Next, in step 304, the database client of the first data computing engine can respond to the request and retrieve data items from the source database through a database connection to the source database.

[0064] Subsequently, in step 306, the distributed storage client of the first data computing engine can generate a hash address from the content of the data item using a hash algorithm.

[0065] Next, in step 308, the distributed storage client of the first data computing engine can store the data item in the data structure of at least one of the multiple first node devices associated with the distributed file storage network in the first region.

[0066] Subsequently, in step 310, the distributed ledger client of the first data computing engine can store the configuration information and hash address associated with the data item into the ledger on at least one of the multiple second node devices associated with the distributed ledger network in the first region.

[0067] Next, in step 312, the distributed ledger client of the first data computing engine can send a query to update the ledger on each of the multiple second node devices with status information indicating the first type of transaction corresponding to storing data items in the distributed file storage network, thereby synchronizing the target database with the source database based on the first type of transaction and the second type of transaction of the data item.

[0068] Figure 4 A flowchart illustrating a pull transaction for transferring data between different regions, depending on the implementation, is shown. One or more steps 402 to 408 of process 400 may be implemented, at least in part, in the form of executable code stored on a non-transitory tangible machine-readable medium, which, when run by one or more processors, causes one or more processors to perform one or more steps 402 to 408. Some examples of computing devices, such as computing system 500, may include a non-transitory tangible machine-readable medium containing executable code that, when run by one or more processors (e.g., processor 512), causes one or more processors to perform the steps of process 400. As shown, process 400 includes a number of enumerated steps, but various aspects of process 400 may include additional steps before, after, and between the enumerated steps. In some aspects, one or more of the enumerated steps may be omitted or performed in a different order.

[0069] Process 400 begins at step 402, where a first data computation engine in a first region can receive status information indicating a first type of transaction of data items sent from a source database in a second region to a target database in the first region via an encrypted communication channel associated with a distributed ledger network, the second region being different from the first region.

[0070] Next, in step 404, the distributed ledger client of the first data computing engine can determine that: the first type of transaction can be accessed by the system through an encrypted communication channel from at least one of the multiple first node devices associated with the distributed ledger network in the first region.

[0071] Subsequently, in step 406, the distributed ledger client of the first data computing engine can obtain metadata of data items from at least a portion of a first type of transaction in the ledger stored on at least one of the multiple first node devices.

[0072] Next, in step 408, the distributed ledger client of the first data computing engine can recover the hash address of the data item from the metadata.

[0073] Subsequently, in step 410, the distributed storage client of the first data computing engine can retrieve data items from at least one of a plurality of second node devices associated with the distributed file storage network in the second region based on the hash address.

[0074] Next, in step 412, the database client of the first data computing engine can store data items in the data structure of the target database based on the namespace identifier from the target database of the metadata.

[0075] Subsequently, in step 414, the distributed ledger client of the first data computing engine can send a query to update the ledger on each of the multiple first node devices with status information of the second type of transaction corresponding to the retrieval of data items from the distributed file storage network and the storage of the data items in the target database, wherein the target database is synchronized with the source database based on the first type of transaction and the second type of transaction of the data items.

[0076] Figure 5 It depends on the suitability of the implementation method. Figure 1 A block diagram of a computer system 500 comprising one or more components. In various implementations, the computing device may include a personal computing device capable of communicating with a network, such as a smartphone, tablet, personal computer, laptop, wearable computing device (such as glasses or a watch, Bluetooth device, key fob, badge, etc.). The service provider server 110 may utilize a network computing device (e.g., a web server) capable of communicating with a network 180. It should be understood that each of the devices used by the user and the service provider may be implemented as part of the computer system 500.

[0077] Computer system 500 includes a bus 502 or other communication mechanisms for transmitting information, data, signals, and information between various components of computer system 500. Components include input / output (I / O) components 504, which process user actions such as keypad / keyboard selection keys, selecting one or more buttons, images or links, and / or moving one or more images, and send corresponding signals to bus 502. I / O components 504 may also include output components such as a display 511 and cursor controls 513 (such as a keyboard, keypad, mouse, etc.). Optional audio input / output components 505 may also be included to allow the user to input information using voice by converting audio signals. Audio I / O components 505 allow the user to hear audio. A transceiver or network interface 506 transmits and receives signals between computer system 500 and other devices such as another communication device, service device, or service provider server via network 180. In one implementation, the transmission is wireless, but other transmission media and methods may also be suitable. One or more processors 512 may be microcontrollers, digital signal processors (DSPs), or other processing units that process these various signals, such as for display on computer system 500 or for transmission to other devices via communication link 518. Processor 512 may also control the transmission of information such as cookies or IP addresses to other devices.

[0078] The computer system 500 also includes a system memory component 514 (e.g., RAM), a static storage component 516 (e.g., ROM), and / or a disk drive 517. The computer system 500 performs specific operations by executing one or more sequences of instructions contained in the system memory component 514 via a processor 512 and other components. The logic may be encoded in a computer-readable medium, which can refer to any medium that participates in providing instructions to the processor 512 for execution. Such a medium can take many forms, including but not limited to non-volatile media, volatile media, and transmission media. In various implementations, non-volatile media include optical discs or magnetic disks, volatile media include dynamic memory such as the system memory component 514, and transmission media include coaxial cables, copper wires, and optical fibers, including wires containing bus 502. In one implementation, the logic is encoded in a non-transitory computer-readable medium. In one example, the transmission medium may take the form of sound waves or light waves, such as those generated during radio waves, optical, and infrared data communications.

[0079] Some common forms of computer-readable media include, for example, floppy disks, floppy disks, hard disks, magnetic tapes, any other magnetic media, CD-ROMs, any other optical media, punched cards, paper tapes, any other physical media with a perforated pattern, RAM, PROMs, EEPROMs, FLASH-EEPROMs, any other memory chips or cassette tapes, or any other media that a computer is adapted to read from.

[0080] In various implementations of this disclosure, the execution of the instruction sequence for practicing this disclosure can be performed by computer system 500. In various other implementations of this disclosure, multiple computer systems 500 coupled to a network (e.g., such as a LAN, WLAN, PTSN, and / or various other wired or wireless networks, including telecommunications, mobile, and cellular telephone networks) via communication link 518 can execute instruction sequences to practice this disclosure in a coordinated manner.

[0081] Where applicable, the various implementations provided in this disclosure may be implemented using hardware, software, or a combination of hardware and software. Furthermore, where applicable, without departing from the spirit of this disclosure, the various hardware and / or software components described herein may be combined into composite components comprising software, hardware, and / or both. Where applicable, without departing from the scope of this disclosure, the various hardware and / or software components described herein may be divided into sub-components comprising software, hardware, or both. Furthermore, where applicable, it is contemplated that software components may be implemented as hardware components, and vice versa.

[0082] Software such as program code and / or data according to this disclosure can be stored on one or more computer-readable media. It is also contemplated that the software identified herein can be implemented using one or more general-purpose or special-purpose computers and / or computer systems (networked and / or otherwise). Where applicable, the order of the various steps described herein can be changed, combined into compound steps, and / or separated into sub-steps to provide the features described herein.

[0083] The various features and steps described herein can be implemented as a system comprising one or more memories storing the various information described herein, and one or more processors coupled to one or more memories and a network, wherein one or more processors are operable to perform the steps as described herein, as a non-transitory machine-readable medium comprising a plurality of machine-readable instructions which, when executed by one or more processors, are adapted to cause one or more processors to perform a method comprising the steps described herein, and a method executed by one or more devices such as a hardware processor, user equipment, server, and other devices described herein.

[0084] The foregoing disclosure is not intended to limit this disclosure to the precise form or particular field of use disclosed. Therefore, various alternative implementations and / or modifications of this disclosure, whether expressly described or implied herein, are contemplated in light of this disclosure. Having so described implementations of this disclosure, those skilled in the art will recognize that changes in form and detail may be made without departing from the scope of this disclosure. Therefore, this disclosure is limited only by the claims.

Claims

1. A method for ensuring secure data transmission between databases in different regions, the method comprising: A request is received at a first data computing engine in a first region to transfer data items from a source database in the first region to a target database in a second region, which is different from the first region, via an encrypted communication channel associated with a distributed ledger network. The database client of the first data computing engine responds to the request and retrieves the data item from the source database through a database connection connected to the source database; The distributed storage client of the first data computing engine generates a hash address from the content of the data item using a hash algorithm. The data item is stored in the data structure of at least one of a plurality of first node devices associated with the distributed file storage network in the first region through the distributed storage client of the first data computing engine. The configuration information associated with the data item and the hash address are stored in the ledger on at least one of the multiple second node devices associated with the distributed ledger network in the first region through the distributed ledger client of the first data computing engine. as well as The distributed ledger client of the first data computing engine sends a query to update the ledger on each of the plurality of second node devices by using status information of a first type of transaction corresponding to storing the data item in the distributed file storage network, thereby synchronizing the target database with the source database based on the first type of transaction and the second type of transaction of the data item.

2. The method according to claim 1, wherein, The status information prompts the second data computing engine in the second region to: obtain the data item from at least one of the plurality of first node devices associated with the distributed file storage network in the second region based on the hash address obtained from at least one of the plurality of second node devices associated with the distributed ledger network in the second region, and store the data item in the data structure of the target database.

3. The method according to claim 1, wherein, The configuration information includes one or more of the following: a database identifier that identifies the target database, a table identifier that identifies a position within the data structure of the target database, a unique identifier that indicates the epoch column providing the synchronization point to the source database, or a channel identifier that indicates the encrypted communication channel between the source database and the target database.

4. The method according to claim 3, further comprising: The workflow engine obtains a configuration file from a configuration table in a first data store, the configuration file including the configuration information, and the first data store is communicatively coupled to the workflow engine. The workflow engine is used to determine whether the channel identifier exists in the configuration information; as well as When the channel identifier does not exist in the configuration information, the workflow engine is used to establish the encrypted communication channel.

5. The method according to claim 4, further comprising: The workflow engine is used to initiate one or more client processes, which correspond to a data transfer process for transferring data from the first region to the second region. as well as The workflow engine records each data transmission process in the corresponding data transmission process into a history table in a second data store, which is communicatively coupled to the workflow engine.

6. The method according to claim 1, further comprising: A web application module that interfaces with a user device receives a configuration file including metadata, wherein the metadata includes one or more of the following: a database identifier identifying the target database, a table identifier identifying a position within the data structure of the target database, a unique identifier indicating the epoch column providing the synchronization point to the source database, or a channel identifier indicating the encrypted communication channel between the source database and the target database; and The configuration file is stored in a configuration table of a data storage library, which is communicatively coupled to the web application module.

7. The method according to claim 1, wherein, The hash address includes an encoded representation of the contents of the data item.

8. A system for ensuring secure data transmission between databases in different regions, the system comprising: Non-temporary memory; as well as One or more hardware processors, coupled to the non-transitory memory and configured to read instructions from the non-transitory memory to cause the system to perform operations, said operations including: Status information is received in a first region, the status information indicating a first type of transaction of data items sent from a source database in a second region to a target database in the first region via an encrypted communication channel associated with a distributed ledger network, the second region being different from the first region; It is determined that the first type of transaction can be accessed by the system through the encrypted communication channel from at least one of a plurality of first node devices associated with the distributed ledger network in the first region; Metadata of the data item is obtained from at least a portion of the first type of transactions in a ledger stored on at least one of the plurality of first node devices; Recover the hash address of the data item from the metadata; The data item is obtained from at least one of a plurality of second node devices associated with a distributed file storage network in the second region based on the hash address; The data item is stored in the data structure of the target database based on the namespace identifier from the metadata of the target database; and A query is sent to update the ledger on each of the plurality of first node devices using status information of a second type of transaction corresponding to retrieving the data item from the distributed file storage network and storing the data item in the target database, wherein the target database is synchronized with the source database based on the first type of transaction and the second type of transaction of the data item.

9. The system according to claim 8, wherein, The operation also includes: A web application module that interfaces with a user device receives a configuration file including metadata, wherein the metadata includes one or more of the following: a database identifier identifying the target database, a table identifier identifying a position within the data structure of the target database, a unique identifier indicating the epoch column providing the synchronization point to the source database, or a channel identifier indicating the encrypted communication channel between the source database and the target database; and The configuration file is stored in a configuration table of a data storage library, which is communicatively coupled to the web application module.

10. The system according to claim 8, wherein, Storing the data items in the data structure of the target database includes: Based on the metadata, identify synchronization points in the target database's data structure that correspond to at least a portion of the data structure in the source database; and The data item is stored in one or more storage locations in the data structure following the synchronization point.

11. The system according to claim 8, wherein, The plurality of first node devices include: a first group of first node devices in the first region capable of accessing corresponding target databases in a plurality of target databases in the first region, and a second group of first node devices in the second region capable of accessing corresponding source databases in a plurality of source databases in the second region.

12. The system according to claim 8, wherein, The distributed ledger network includes a proprietary blockchain network, which includes the plurality of first node devices, wherein each of the plurality of first node devices is an authenticated node device.

13. The system according to claim 8, wherein, Obtaining the metadata includes receiving the metadata from the ledger via chaincode hosted on at least one of the plurality of first node devices.

14. The system according to claim 8, wherein, The distributed file storage network includes the InterPlanetary File System (IPFS) network.

15. A non-transitory machine-readable medium storing machine-readable instructions that are executable to cause a machine to perform an operation, the operation including: In response to a request to transfer a data item from a source database in the first region to a target database in a second region different from the first region via an encrypted communication channel associated with a distributed ledger network, the database client of the first data computing engine in the first region retrieves the data item from the source database via a database connection connected to the source database. The data item is stored in the data structure of at least one of the multiple first node devices associated with the distributed file storage network in the first region through the distributed file storage client of the first data computing engine. The hash address of the data item and the configuration information associated with the data item are stored in the ledger on at least one of the multiple second node devices associated with the distributed ledger network in the first region through the distributed ledger client of the first data computing engine. as well as A query is sent via the distributed ledger client of the first data computing engine to update the ledger on each of the plurality of second node devices using status information indicating a first type of transaction corresponding to storing the data item in the distributed file storage network. The status information prompts the second data computing engine in the second region to retrieve the data item from at least one of the plurality of first node devices associated with the distributed file storage network in the second region based on the hash address obtained from at least one of the plurality of second node devices associated with the distributed ledger network in the second region, and to store the data item in the data structure of the target database, thereby synchronizing the target database with the source database based on the first type of transaction and the second type of transaction of the data item.

16. The non-transitory machine-readable medium of claim 15, further comprising: The distributed ledger client is used through the first data computing engine to generate metadata for the data item, wherein the metadata indicates the transaction history of the data item; The distributed ledger client, through the first data computing engine, encodes the metadata into encoded metadata accessible to each of the plurality of second node devices; and The distributed ledger client utilizes the first data computing engine to store the encoded metadata as ledger data in the ledger on at least one of the plurality of second node devices.

17. The non-transitory machine-readable medium of claim 15, further comprising: The distributed file storage client of the first data computing engine generates a hash address from the content of the data item using a hash algorithm, wherein generating the hash address includes: The distributed file storage client utilizes the first data processing engine to process the content of the data item using the first hash function of the hash algorithm, thereby generating a digest unique to the content of the data item; and The first data computing engine utilizes the distributed file storage client to convert the digest into the hash address using the second hash function of the hash algorithm.

18. The non-transitory machine-readable medium according to claim 17, wherein, Generating the hash address includes: The first data computing engine utilizes the distributed file storage client to divide the data item into multiple data blocks with a predetermined block size based on the configuration information; The distributed file storage client utilizes the first data computing engine to process each of the plurality of data blocks using the first hash function of the hash algorithm, thereby generating a unique digest for the content of the data block. The distributed file storage client utilizes the first data computing engine to convert the digest of each data block in the plurality of data blocks into a corresponding content identifier among the plurality of content identifiers using the second hash function of the hash algorithm; and The distributed file storage client utilizes the first data computing engine to combine the multiple content identifiers into a layered data structure to calculate the hash address.

19. The non-transitory machine-readable medium of claim 15, further comprising: The workflow engine selects the first data computing engine from the first group of data computing engines in the first region based on the available resources of the first data computing engine, wherein the second data computing engine relates to the second group of data computing engines in the second region, and the second group of data computing engines is different from the first group of data computing engines.

20. The non-transitory machine-readable medium according to claim 15, wherein, The distributed ledger network includes a proprietary blockchain network, which includes the plurality of second node devices, wherein each of the plurality of second node devices is an authenticated node device.

Images