A data sharing system and ledger database based on ledger database network
Through the combination of ledger database network and trusted storage devices, trust verification and proof storage in large-scale data sharing scenarios are realized, trust problems and storage waste in data sharing are solved, and data sharing is ensured security and transparency.
Patent Information
- Application Number
- CN202210501759.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-04-28
- Publication Date
- 2025-08-19
- Estimated Expiration
- 2042-04-28
AI Technical Summary
The prior art cannot effectively solve the trust problems and waste of data storage overhead in data sharing scenarios, especially in large-scale data sharing scenarios, credible problems of all parties have not been solved.
A data sharing system based on the ledger database network is adopted to store data requests and data summary through trusted storage devices, and use trusted timestamps to provide data immutability and traceability, so as to realize trust verification and evidence storage in the data sharing process.
It solves the trust problem in the data sharing process, reduces data storage overhead, provides traceability and tamper-proofness of data operations, and ensures the security and transparency of data sharing.
Smart Images

Figure CN114880399B_ABST
Abstract
Description
Technical Field
[0001] The embodiments of this specification belong to the field of data processing technology, and more particularly, to a data sharing system and a ledger database based on an account database network. Background Art
[0002] The rapid development of informatization has led to the problem of information silos. Each entity possesses a vast amount of data, but due to the difficulty in establishing full trust between these entities, data sharing is hindered. Consequently, the data held by each entity cannot be aggregated to generate greater value. Existing solutions to the problem of information silos aim to address data connectivity, but they still fail to resolve the trust issues inherent in data sharing. Summary of the Invention
[0003] The object of the present invention is to provide a data sharing system and an account book database based on an account book database network.
[0004] In a first aspect, the present disclosure provides a data sharing system based on a ledger database network. The system includes a first device, a second device, a ledger database network, and a trusted storage device.
[0005] The first device is used to send a data request and a signature corresponding to the data request to the ledger database network. The data request is used to request first data from the second device, and the signature corresponding to the data request includes a signature for the data request generated by the first device.
[0006] The ledger database network is configured to store the data request and the signature corresponding to the data request in the trusted storage device, and to send the data request and the signature corresponding to the data request to the second device;
[0007] The second device is configured to send the first data and the signature corresponding to the first data to the ledger database network when it is determined that the signature corresponding to the data request has been verified successfully.
[0008] The ledger database network is further configured to store the first data and the signature corresponding to the first data in the trusted storage device, and to send the first data and the signature corresponding to the first data to the first device.
[0009] A second aspect of this specification provides a data sharing method, performed by a ledger database in a ledger database network. The method comprises:
[0010] receiving a data request and a signature corresponding to the data request, where the data request and the signature corresponding to the data request are sent by a first device, the data request being used to request first data from a second device, and the signature corresponding to the data request including a signature generated by the first device for the data request;
[0011] storing the data request and the signature corresponding to the data request in a trusted storage device, and sending the data request and the signature corresponding to the data request to the second device, or sending the data request and the signature corresponding to the data request to the second device via another ledger database;
[0012] receiving the first data and a signature corresponding to the first data, where the first data and the signature corresponding to the first data are sent by the second device according to the data request and the signature corresponding to the data request;
[0013] The first data and the signature corresponding to the first data are stored in the trusted storage device, and the first data and the signature corresponding to the first data are sent to the first device.
[0014] A third aspect of this specification provides an account book database, including:
[0015] a receiving module, configured to receive a data request and a signature corresponding to the data request, wherein the data request and the signature corresponding to the data request are sent by a first device, the data request being used to request first data from a second device, and the signature corresponding to the data request including a signature generated by the first device for the data request;
[0016] a sending module, configured to store the data request and the signature corresponding to the data request in a trusted storage device, and send the data request and the signature corresponding to the data request to the second device, or send the data request and the signature corresponding to the data request to the second device via another ledger database;
[0017] a receiving module, further configured to receive the first data and a signature corresponding to the first data, wherein the first data and the signature corresponding to the first data are sent by the second device according to the data request and the signature corresponding to the data request;
[0018] The sending module is further configured to store the first data and the signature corresponding to the first data in the trusted storage device, and send the first data and the signature corresponding to the first data to the first device.
[0019] A fourth aspect of this specification provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the method described in the second aspect above.
[0020] A fifth aspect of this specification provides a computing device including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in the second aspect is implemented. BRIEF DESCRIPTION OF THE DRAWINGS
[0021] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.
[0022] Figure 1 This is a structural diagram of a data sharing system based on an account database network provided in an embodiment of this specification;
[0023] Figure 2 This is an interactive diagram of a data sharing system based on a ledger database network to achieve data sharing, provided in one embodiment of this specification;
[0024] Figure 3 This is an interaction diagram for implementing data sharing in another data sharing system based on a ledger database network provided in an embodiment of this specification;
[0025] Figure 4 This is a schematic diagram of the structure of an account database provided in an embodiment of this specification. DETAILED DESCRIPTION
[0026] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall fall within the scope of protection of this specification.
[0027] Participants in data sharing typically include data providers, data requesters, and network providers. In some small-scale, narrow-scope data sharing scenarios, such as data sharing between departments within an enterprise, all participants are assumed to be secure and trustworthy. Therefore, implementation solutions for these scenarios focus solely on the data transfer process from provider to requester, without considering the security and trustworthiness of each participant. However, in larger, more comprehensive data sharing scenarios, such as data sharing between different enterprises, the trustworthiness of all parties becomes a crucial issue for data security.
[0028] For example, in one embodiment, the trust issue in data sharing scenarios can be resolved by appending summary information to the data. Specifically, in a data download sharing scenario, the data provider will append summary information to the data and send the data itself and the data summary to the data requester via the network. After receiving the data and the data summary, the data requester verifies whether the received data has been lost using the data summary. This solution can address data-level security, but it still has certain flaws. For example, because the solution does not save the operations of the parties in the data sharing scenario, it cannot resolve disputes between the data provider and / or the data requester regarding the operations of the parties in the data sharing scenario, such as whether the data requester has sent a data request and / or whether the data provider has provided data.
[0029] For another example, in one implementation, blockchain technology can be used to address trust issues in data sharing scenarios. Specifically, data providers can store their data in a blockchain, and data requesters can access the data provider's data from the blockchain. Blockchain nodes also store the actions of each participant, such as the data requester's request for data and the data provider's provision of data. Blockchain's immutable data and transaction storage properties can address data security issues and resolve disputes among participants in data sharing scenarios. However, in this solution, the data provider's data is transmitted to every node in the blockchain, meaning each node stores a copy of the data, resulting in significant storage overhead.
[0030] Based on the above analysis, in data sharing scenarios, how to resolve data security and disputes among various participants in the scenario is a problem that needs to be solved in this field.
[0031] To this end, the embodiments of this specification provide a data sharing system and method based on a ledger database network to solve the mutual trust problem in data sharing scenarios. Before specifically introducing the embodiments of this specification, the following is a brief introduction to some of the terms that appear in the embodiments of this specification.
[0032] A ledger database is a centralized and trusted storage system that uses a trusted storage device as a root of trust. It periodically or on demand writes all or part of the data to the trusted storage device, thereby ensuring that the data in the ledger database cannot be tampered with and that operations cannot be denied. In practice, the ledger database typically writes a summary of all or part of the data to the trusted storage device.
[0033] A ledger database network is a decentralized network consisting of multiple ledger databases. Each ledger database in the network can be referred to as a node or network node. Each node in the network can provide storage and communication services to users, thereby enabling the network to offer trusted data sharing services to all users.
[0034] A trusted timestamp is an electronic certificate issued by a timestamp service center for an electronic file. It verifies the exact time the electronic file was created, and can be used to prevent tampering and prevent subsequent repudiation. Specifically, a trusted timestamp may include a summary of the electronic file, the time the electronic file was received, and the digital signature of the timestamp service center.
[0035] The following is a detailed introduction to a data sharing system based on an account book database network provided in an embodiment of this specification.
[0036] Figure 1 This is a structural diagram of a data sharing system based on an account book database network provided in an embodiment of this specification.
[0037] See Figure 1 The data sharing system 100 includes multiple devices and a ledger database network. The multiple devices may include multiple terminal devices (such as a first device 111 and a second device 112), a third device 113, and a trusted storage device 114. The third device 113 is used to provide a trusted timestamp service to each terminal device, and the trusted storage device 114 is used to provide a proof service for the ledger database network.
[0038] The ledger database network can provide communication services for terminal devices to enable data sharing between terminal devices. It can also store user data of each terminal device and use the trusted storage device 114 to store data exchanged between terminal devices in data sharing scenarios to support future verification and traceability. For example, when the first device 111 sends a data request to the device 112 via the ledger database network, or the second device 112 can send data to the first device 111 via the ledger database network, the ledger database network can store the data request and / or data summary between the first device 111 and the second device 112 in the trusted storage device 114.
[0039] Specifically, the ledger database network may include multiple nodes (such as node 121-node 124). Each of the multiple nodes can be connected to one or more terminal devices, and can also be connected to other nodes in the multiple nodes to realize the functions of the aforementioned ledger database network. For example, node 121 can be connected to the first device 111, node 123 can be connected to the second device 112, and node 121 is connected to node 122, node 123 and node 124. Thus, node 121 and node 123 can respectively store user data of the first device 111 and user data of the second device 112, transmit data requests or data between device 111 and device 112, and store data requests or data between the first device 111 and the second device 112 in the trusted storage device 114. Among them, each node in the ledger database network can be implemented as a device, server or device cluster with computing and processing capabilities.
[0040] The third device 113 can specifically provide a trusted timestamp for each terminal device when data is shared between terminal devices. For example, when the first device 111 sends a data request or data to the second device 112 via the node 121, the data request or data summary can be sent to the third device 113. Accordingly, the third device 113 generates a trusted timestamp based on the received data request or data summary and the time of receipt, and returns it to the first device 111. The third device 113 can also be implemented as a computing device, server, or device cluster.
[0041] Trusted storage device 114 can also provide evidence storage services to terminal devices. For example, when first device 111 sends a data request to node 121, node 121 can store the data request in trusted storage device 114. For another example, when second device 112 receives a data request from first device 111, it can store the received data request in trusted storage device 114. Trusted storage device 114 can also be implemented as a device, server, or device cluster with storage capabilities.
[0042] Understandably, Figure 1 The number of terminal devices and the number of nodes in the ledger database network shown are merely examples of the data sharing system in the embodiments of this specification. In specific applications, the terminal devices and nodes in the data sharing system are not limited to the structures and numbers shown in the embodiments of this specification.
[0043] The following is combined with Figure 2 , a process in which the terminal device 111 requests the terminal device 112 to share data in the embodiment of this description is described in detail.
[0044] like Figure 2As shown, the process in which the terminal device 111 requests the terminal device 112 to share data may include the following steps S201 to S229.
[0045] In step S201 , the first device 111 requests the third device 113 for a trusted timestamp corresponding to the data request.
[0046] When the first device 111 needs to request the first data in the second device 112, it generates a data request and requests a trusted timestamp corresponding to the data request from the third device 113. Specifically, after generating the data request, the first device 111 calculates a hash value of the data request and sends a timestamp request to the third device 113, where the timestamp request includes the hash value of the data request.
[0047] After receiving the timestamp request from the first device 111, the third device 113 uses its private key to sign the hash value of the data request and the time information of receiving the timestamp request in the timestamp request, thereby obtaining a signature for the data request. The third device 113 then generates a trusted timestamp corresponding to the data request based on the hash value of the data request, the time information of receiving the timestamp request, and the signature of the data request, and sends the trusted timestamp corresponding to the data request to the first device 111.
[0048] In step S203 , the first device 111 sends a data request and a signature corresponding to the data request to the node 121 .
[0049] The signature corresponding to the data request may include the signature for the data request generated by the first device 111 and / or the signature for the data request generated by the third device 113 .
[0050] Specifically, after receiving the trusted timestamp corresponding to the data request, the first device 111 parses the trusted timestamp corresponding to the data request and obtains the signature for the data request generated by the third device 113. Furthermore, the user of the first device 111 can sign the data request using their own private key within the first device 111, obtaining the signature for the data request generated by the first device 111. The first device 111 then sends the data request, the signature for the data request generated by the first device 111, and the signature for the data request generated by the third device 113 to the node 121.
[0051] In step S205 , the node 121 stores the data request and the signature corresponding to the data request in the trusted storage device 114 .
[0052] In other embodiments, after receiving the data request and its signature, node 121 may directly send it to node 123, which then attests the data request and its corresponding signature. Accordingly, after receiving the data request and its corresponding signature, node 123 stores the data request and its corresponding signature in trusted storage device 114.
[0053] In step S207 , the node 121 sends the data request and the signature corresponding to the data request to the second device 112 via the node 123 .
[0054] After storing the data request and its corresponding signature, node 121 sends the data request and its corresponding signature to node 123. After receiving the data request and its corresponding signature, node 123 sends the data request and its corresponding signature to second device 112. In other embodiments, node 123 may also store the data request and its corresponding signature in trusted storage device 114 before sending the data request and its corresponding signature.
[0055] In step S209 , the second device 112 verifies the signature corresponding to the data request. After the signature corresponding to the data request is verified, the second device 112 stores the data request and the signature corresponding to the data request in the trusted storage device 114 .
[0056] The second device 112 may use the public key of the user of the first device 111 to verify the signature of the data request generated by the first device 111 in the second device 112 .
[0057] After the signature verification of the data request generated by the first device 111 is successful, the second device 112 can verify the signature of the data request generated by the third device 113. Specifically, the second device 112 parses the data request to obtain the time information therein, and uses the public key provided by the third device 113 to parse the signature of the data request generated by the third device 113, thereby obtaining the time information when the third device 113 received the data request. The second device 112 then compares the two time information to determine whether the signature verification of the data request generated by the third device 113 is successful. For example, when the time information obtained from the data request is before the time information obtained from the signature of the data request generated by the third device 113, the signature verification of the data request generated by the third device 113 is successful.
[0058] In step S211 , the second device 112 requests the third device 113 for a trusted timestamp corresponding to the first data.
[0059] After successfully verifying the signature corresponding to the data request, the second device 112 determines the first data and requests a trusted timestamp corresponding to the first data from the third device 113. Specifically, the second device 112 may determine the first data based on the data identifier parsed from the data request, calculate a hash value of the first data, thereby obtaining a digest of the first data, and then send a timestamp request to the third device 113, where the timestamp request includes the digest of the first data.
[0060] After receiving the timestamp request from the second device 112, the third device 113 uses the private key to sign the digest of the first data and the time when the timestamp request was received, thereby obtaining a signature for the first data. The third device 113 then generates a trusted timestamp corresponding to the first data based on the digest of the first data, the time when the timestamp request was received, and the signature for the first data, and sends the trusted timestamp corresponding to the first data to the second device 112.
[0061] In step S213 , the second device 112 sends the first data and the signature corresponding to the first data to the node 123 according to the trusted timestamp corresponding to the first data.
[0062] The signature corresponding to the first data may include a signature of the first data generated by the second device 112 and / or a signature of the first data generated by the third device 113 .
[0063] Specifically, after receiving the trusted timestamp corresponding to the first data, the second device 112 parses the timestamp corresponding to the first data to obtain the signature of the first data generated by the third device 113. Then, the user of the second device 112 can sign the first data using the private key in the second device 112, and then send the first data, the signature of the first data generated by the second device 112, and the signature of the first data generated by the third device 113 to the node 123.
[0064] In step S215 , the node 123 stores the digest of the first data and the signature corresponding to the first data in the trusted storage device 114 .
[0065] The node 123 receives the first data and its corresponding signature, calculates a hash value of the first data to determine a digest of the first data, and stores the digest of the first data and the signature corresponding to the first data in the trusted storage device 114 .
[0066] In other embodiments, after receiving the first data and its corresponding signature, node 123 may also directly send it to node 121, and node 121 may store the first data and its corresponding signature. Accordingly, after receiving the first data and its corresponding signature, node 121 stores the first data and its corresponding signature in trusted storage device 114.
[0067] In step S217 , the node 123 sends the first data and its corresponding signature to the first device 111 via the node 121 .
[0068] After storing the first data and its corresponding signature, node 123 sends the first data and its corresponding signature to node 121. After receiving the first data and its corresponding signature, node 121 sends the first data and its corresponding signature to first device 111. In other embodiments, node 121 may also store the first data and its corresponding signature in trusted storage device 114 before sending the first data and its corresponding signature.
[0069] In step S219 , the first device 111 verifies the signature corresponding to the first data. After the signature corresponding to the first data is verified, the first data and its corresponding signature are stored in the trusted storage device 114 .
[0070] The first data 111 may verify, in the second device 111 , the signature of the first data generated by the second device 112 using the public key of the user of the second device 112 .
[0071] After the signature generated by the second device 112 for the first data is successfully verified, the first device 111 can verify the signature generated by the third device 113 for the first data. Specifically, the first device 111 obtains time information from the first data and uses the public key provided by the third device 113 to parse the signature generated by the third device 113 for the first data, thereby obtaining the time information of the digest of the first data received by the third device 113. The first device 111 then compares the two time information to determine whether the signature generated by the third device 113 for the first data is successfully verified. For example, if the time information obtained from the first data is before the time information obtained from the signature generated by the third device 113 for the first data, the signature generated by the third device 113 for the first data is successfully verified.
[0072] In step S221 , the first device 111 requests the third device 113 for a trusted timestamp corresponding to the data receipt.
[0073] After the first device 111 successfully verifies the signature of the first data, it generates a data receipt and requests a trusted timestamp corresponding to the data receipt from the third device 113. Specifically, after generating the data receipt, the first device 111 calculates a hash value of the data receipt and sends the timestamp to the third device 113. The timestamp request includes the hash value of the data receipt.
[0074] After receiving the timestamp request from the first device 111, the third device 113 uses its private key to sign the hash value of the data receipt in the timestamp request and the time information of receiving the timestamp request, thereby obtaining a signature for the data receipt. The third device 113 then generates a trusted timestamp corresponding to the data receipt based on the hash value of the data receipt, the time information of receiving the timestamp request, and the signature of the data receipt, and sends the trusted timestamp corresponding to the data receipt to the first device 111.
[0075] In step S223 , the first device 111 sends the data receipt and the signature corresponding to the data receipt to the node 121 .
[0076] Likewise, the signature corresponding to the data receipt may include the signature for the data receipt generated by the first device 111 and / or the signature for the data receipt generated by the third device 113 .
[0077] Specifically, after receiving the trusted timestamp corresponding to the data receipt, the first device 111 parses the trusted timestamp corresponding to the data receipt and obtains the signature of the data receipt generated by the third device 113. Furthermore, the user of the first device 111 can sign the data receipt using their own private key within the first device 111, obtaining the signature of the data receipt generated by the first device 111. The first device 111 then sends the data receipt, the signature of the data receipt generated by the first device 111, and the signature of the data receipt generated by the third device 113 to the node 121.
[0078] In step S225 , the node 121 stores the data receipt and the signature corresponding to the data receipt in the trusted storage device 114 .
[0079] Similarly, in other embodiments, after receiving the data receipt and its signature, node 121 may directly send it to node 123, which then stores the data receipt and its corresponding signature. Accordingly, after receiving the data receipt and its corresponding signature, node 123 stores the data receipt and its corresponding signature in trusted storage device 114.
[0080] In step S227 , node 121 sends the data receipt and the signature corresponding to the data receipt to the second device 112 via node 123 .
[0081] After storing the data receipt and its corresponding signature, node 121 sends the data receipt and its corresponding signature to node 123. After receiving the data receipt and its corresponding signature, node 123 sends the data receipt and its corresponding signature to the second device 112.
[0082] In other embodiments, the node 123 may further store the data receipt and its corresponding signature in the trusted storage device 114 before sending the data receipt and its corresponding signature.
[0083] In step S229 , the second device 112 verifies the signature corresponding to the data receipt. After the signature corresponding to the data receipt is verified, the second device 112 stores the data receipt and the signature corresponding to the data receipt in the trusted storage device 114 .
[0084] The second device 112 may use the public key of the user of the first device 111 to verify the signature of the data receipt generated by the first device 111 in the second device 112 .
[0085] After the signature verification of the data receipt generated by the first device 111 is successful, the second device 112 can verify the signature of the data receipt generated by the third device 113. Specifically, the second device 112 parses the data receipt to obtain the time information therein, and uses the public key provided by the third device 113 to parse the signature of the data receipt generated by the third device 113, thereby obtaining the time information when the third device 113 received the data receipt. The second device 112 then compares the two time information to determine whether the signature verification of the data receipt generated by the third device 113 is successful. For example, if the time information obtained from the data receipt is before the time information obtained from the signature of the data receipt generated by the third device 113, the signature verification of the data receipt generated by the third device 113 is successful.
[0086] In one embodiment, Figure 3 As shown, when the first device 111 and the second device 112 are both served by the same node (node 121) in the ledger database network, node 121 can directly forward the data request, data, or data receipt of one device to the other device without forwarding it through other nodes in the network. For example, after storing the data request and its signature from the first device 111, node 121 directly sends the data request and its signature to the second device 112.
[0087] In the above scheme, the data in the sharing scenario is stored in the user's device (such as the second device 112) and is not stored in any node in the ledger database network, thereby solving the problem of high data storage overhead in the prior art. In the above scheme, the ledger database network stores the data request, the summary of the first data, the data receipt and the corresponding signatures generated in the data sharing process through a trusted storage device, thereby solving the trust problem in the data sharing process. Under this scheme, when any participant or other third party raises an objection to the operation in the data sharing, the previously stored information can be read from the trusted storage device to complete the evidence. The signature of the above scheme includes the signature of the trusted timestamp provider, which can prove the time when the data request, the first data and the data receipt were generated, prevent them from being tampered with and subsequently denied, and can also solve the trust problem in data sharing.
[0088] Based on the above Figure 2 The data sharing method embodiment shown in the present specification also provides an account database to perform the above Figure 2 Steps executed by the ledger database.
[0089] Figure 4 This is a schematic diagram of the structure of an account database provided in an embodiment of this specification.
[0090] like Figure 4 As shown, the account book database 400 includes: a receiving module 401 and a sending module 403.
[0091] The receiving module 401 is used to receive a data request and a signature corresponding to the data request, the data request and the signature corresponding to the data request are sent by the first device, and the data request is used to request the first data from the second device.
[0092] The sending module 403 is configured to store the data request and the signature corresponding to the data request in a trusted storage device and send the data request and the signature corresponding to the data request to the second device, or send the data request and the signature corresponding to the data request to the second device via another ledger database.
[0093] The receiving module 401 receives the first data and the signature corresponding to the first data, where the first data and the signature corresponding to the first data are sent by the second device according to the data request and the signature corresponding to the data request;
[0094] The sending module 403 is further configured to store the digest of the first data and the signature corresponding to the first data in the trusted storage device, and send the first data and the signature corresponding to the first data to the first device.
[0095] In this embodiment, the receiving module 401 is further configured to receive a data receipt and a signature corresponding to the data receipt, where the data receipt and the signature corresponding to the data receipt are sent by the first device according to the signature corresponding to the first data.
[0096] In this embodiment, the sending module 403 is further used to store the data receipt and the signature corresponding to the data receipt in the trusted storage device, and send the data receipt and the signature corresponding to the data receipt to the second device, or send the data receipt and the signature corresponding to the data receipt to the second device via another ledger database.
[0097] It should be understood that each module in the above-mentioned ledger database 400 can be pre-set in the ledger database, or can be loaded into the ledger database by downloading, etc. The corresponding module in the above-mentioned ledger database can cooperate with other devices to realize the functions of the above-mentioned modules.
[0098] The above description of the ledger database embodiment is merely illustrative, wherein the modules described as separate components may or may not be physically separate, i.e., they may be located in one location or distributed across multiple units. Some or all of these modules may be selected based on actual needs to achieve the objectives of the embodiments described herein. Those skilled in the art will be able to understand and implement these modules without inventive effort.
[0099] The embodiment of this specification also provides a computer-readable storage medium, which stores a computer program, which can be used to execute the above Figure 2 Method steps in the illustrated embodiment.
[0100] The embodiment of this specification also provides a computing device, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the above Figure 2 It should be understood that the computing device can be the above-mentioned Figure 2 Any one of the terminal device 111, the terminal device 112, the node 121 and the node 123 involved in the illustrated embodiment.
[0101] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures such as diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to hire a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.
[0102] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.
[0103] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude that with the future development of computer technology, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
[0104] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any particular order.
[0105] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing one or more of the present specifications, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.
[0106] The present invention is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.
[0107] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.
[0108] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.
[0109] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.
[0110] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.
[0111] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.
[0112] Those skilled in the art will appreciate that one or more embodiments of this specification may be provided as a method, system, or computer program product. Thus, one or more embodiments of this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0113] One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In distributed computing environments, program modules may be located in local and remote computer storage media, including storage devices.
[0114] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced across them. Each embodiment focuses on the differences from the other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, their description is relatively simple. For relevant parts, reference can be made to the description of the method embodiments. Throughout this specification, reference to the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate the different embodiments or examples, and features of different embodiments or examples, described in this specification, without conflict.
[0115] The foregoing is merely an example of one or more embodiments of this specification and is not intended to limit the one or more embodiments of this specification. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification shall be included within the scope of the claims.
Claims
1. A data sharing system comprising a first device, a second device, a decentralized ledger database network consisting of multiple ledger databases, and a trusted storage device; The first device is configured to send a data request and a signature corresponding to the data request to the ledger database network, wherein the data request is used to request first data from the second device, and the signature corresponding to the data request includes a signature generated by the first device for the data request; The ledger database network is used to store the data request and the signature corresponding to the data request in the trusted storage device, and send the data request and the signature corresponding to the data request to the second device; The second device is configured to send the first data and the signature corresponding to the first data to the ledger database network when determining that the signature corresponding to the data request passes verification; The ledger database network is further configured to store a digest of the first data and a signature corresponding to the first data in the trusted storage device, and to send the first data and the signature corresponding to the first data to the first device.
2. The system according to claim 1, wherein the second device is further configured to store the data request and the signature corresponding to the data request in the trusted storage device if it is determined that the signature corresponding to the data request passes verification; The first device is further configured to store the first data and the signature corresponding to the first data in the trusted storage device when it is determined that the signature corresponding to the first data passes verification.
3. The system according to claim 1, wherein the first device is further configured to, upon determining that the signature corresponding to the first data has passed verification, send a data receipt and a signature corresponding to the data receipt to the ledger database network; The ledger database network is further configured to store the data receipt and the signature corresponding to the data receipt in the trusted storage device, and to send the data receipt and the signature corresponding to the data receipt to the second device; The second device is further configured to store the data receipt and the signature corresponding to the data receipt in the trusted storage device when it is determined that the signature corresponding to the data receipt has passed verification.
4. The system according to any one of claims 1-3, further comprising a third device, wherein the third device is configured to provide a trusted timestamp, and the signature corresponding to the data request further comprises a signature for the data request generated by the third device, and the signature for the data request generated by the third device comprises time information provided by the third device.
5. A data sharing method, performed by a ledger database in a decentralized ledger database network, the method comprising: receiving a data request and a signature corresponding to the data request, the data request and the signature corresponding to the data request being sent by a first device, the data request being used to request first data from a second device, the signature corresponding to the data request including a signature generated by the first device for the data request; storing the data request and the signature corresponding to the data request in a trusted storage device, and sending the data request and the signature corresponding to the data request to the second device, or sending the data request and the signature corresponding to the data request to the second device via another ledger database; receiving the first data and a signature corresponding to the first data, where the first data and the signature corresponding to the first data are sent by the second device according to the data request and the signature corresponding to the data request; The digest of the first data and the signature corresponding to the first data are stored in the trusted storage device, and the first data and the signature corresponding to the first data are sent to the first device.
6. The method according to claim 5, further comprising: receiving a data receipt and a signature corresponding to the data receipt, wherein the data receipt and the signature corresponding to the data receipt are sent by the first device according to the signature corresponding to the first data; The data receipt and the signature corresponding to the data receipt are stored in the trusted storage device, and the data receipt and the signature corresponding to the data receipt are sent to the second device, or the data receipt and the signature corresponding to the data receipt are sent to the second device via another ledger database.
7. According to the method according to claim 5 or 6, the data request includes first time information provided by a third device, and the signature corresponding to the data request also includes a signature of the data request generated by the third device, and the third device is used to provide a trusted timestamp.
8. A ledger database comprising: a receiving module, configured to receive a data request and a signature corresponding to the data request, wherein the data request and the signature corresponding to the data request are sent by a first device, the data request being used to request first data from a second device, and the signature corresponding to the data request including a signature generated by the first device for the data request; a sending module, configured to store the data request and the signature corresponding to the data request in a trusted storage device, and send the data request and the signature corresponding to the data request to the second device, or send the data request and the signature corresponding to the data request to the second device via another ledger database; a receiving module, further configured to receive the first data and a signature corresponding to the first data, wherein the first data and the signature corresponding to the first data are sent by the second device according to the data request and the signature corresponding to the data request; The sending module is further configured to store the digest of the first data and the signature corresponding to the first data in the trusted storage device, and send the first data and the signature corresponding to the first data to the first device.
9. The ledger database according to claim 8, wherein the receiving module is further configured to receive a data receipt and a signature corresponding to the data receipt, wherein the data receipt and the signature corresponding to the data receipt are sent by the first device according to the signature corresponding to the first data; The sending module is further configured to store the data receipt and the signature corresponding to the data receipt in the trusted storage device, and to send the data receipt and the signature corresponding to the data receipt to the second device, or to send the data receipt and the signature corresponding to the data receipt to the second device via another ledger database.
10. The ledger database according to claim 8 or 9, wherein the data request includes first time information provided by a third device, and the signature corresponding to the data request further includes a signature for the data request generated by the third device.
11. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method according to any one of claims 5 to 7.
12. A computing device comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method according to any one of claims 5 to 7 is implemented.
Citation Information
Patent Citations
Data circulation method based on block chain
CN113051343A
Data sharing system and method based on block chain and electronic equipment
CN113297625A
Data storage method, device and system based on trusted account book database
CN113434603A