CN114239044B - A decentralized traceable shared access system - Google Patents

Abstract

The invention provides a decentralised traceable shared access system, comprising: an authentication node and a consensus node; the authentication node is used for realizing management of users, management of document data and business and maintenance of data access information based on each function module deployed on the node; the consensus node is used for carrying out safety management on users accessing the node based on each functional module deployed on the node, initiating a data sharing request and providing data sharing service according to the data sharing request, the shared access system of the invention is based on the block chain technology, ensures the authenticity of data and contract execution force, realizes decentralization and realizes the safe data management of data sharing.

Description

A decentralized traceable shared access system

Technical Field

The present invention relates to the field of data security technology, and in particular to a decentralized traceable shared access system.

Background Art

During the operation of the management information system, a large amount of data is generated. These data involve multiple subsystems associated with the management information system. When these data are managed systematically or even shared externally, the legitimacy of data sharing must be addressed. For example, data in corporate audits may involve special circumstances of departments. When faced with uncertain risks or regulations, how to share the data? The security and rights of the data must be addressed: when the data is used by the target user, there may be risks of being copied, retained, or tampered with, and the data cannot be guaranteed. If data is not shared, each user or business system will form an information island, which will bring additional workload to the management information system.

The data management mode of the management information system generally includes data hosting mode and data aggregation mode. In the hosting mode, the data is hosted in the central database of a specific business system, and the central database is responsible for unified management and operation. In the aggregation mode, the data of different business systems are connected through the API interface, and the data transfer system interacts with the data owner and returns the query results.

However, the disadvantage of the hosting model is that the data security is not high, and the users and usage rights all depend on the integrity of the hosting system. While the aggregation model seems to manage the data of different business systems independently, the final data aggregation is fully capable of and has the opportunity to retain the data of each business system.

Summary of the invention

In order to solve the problems existing in the prior art, the present invention provides a decentralized traceable shared access system, including an authentication node and a consensus node;

The authentication node is used to manage users, manage document data and services, and maintain data access information based on various functional modules deployed on the authentication node;

The consensus node is used to perform security management on users accessing the consensus node, initiate data sharing requests, and provide data sharing services according to the data sharing requests based on the various functional modules deployed on the consensus node;

wherein the consensus node is further configured to receive a statistical profile, wherein the statistical profile includes a network location of the consensus node and a performance specification of the consensus node, and wherein the shared access system implements a decentralized architecture comprising multiple types of peer connections layered on a CDN network, the CDN network having a plurality of CDN servers for providing a first set of segments of the document data to the consensus node;

wherein, when the CDN server receives a cache instruction sent by a consensus node, the CDN server returns a subset of the first group of segments of the document data, wherein the cache instruction is generated based on the statistical profile;

When a data user in the shared access system sends a request for accessing multiple target fragments of document data to the CDN server, the CDN server extracts the content type of the requested document data and the network location of the data user from the received request; selects multiple consensus nodes from the currently active consensus nodes in the shared access system to provide access to the multiple target fragments of the document data, generates a cache list, wherein the multiple consensus nodes are selected based on the network location of the data user user, the network location of the consensus nodes, and the content type of the requested document data; and transmits the generated cache list to the data user user.

Preferably, the authentication node further determines an optimal distribution state of the plurality of segments of the document data to more than two consensus nodes of the network;

The optimal distribution state defines that each of the two or more consensus nodes needs to download identifiers of multiple fragments of the document data from the CDN server; multiple consensus nodes in the cache list cache multiple target fragments of the document data;

The cache instruction is further generated based on the content priority of the document data;

In response to receiving the identification request from the user, the consensus node transmits the identification to the user for use in the shared access system.

Preferably, before the consensus nodes in the cache list are authorized to share document data with data user users, they confirm receipt of the payment authorization certificate of the authentication node, and after the user receives multiple target fragments of document data from multiple consensus nodes, the consensus node receives a service response signed by the data user user, and then sends an updated off-chain transaction to the multiple consensus nodes, and the off-chain transaction accumulates the total payment amount to determine the payment amount in the multiple target fragments including the document data.

Preferably, the functional modules deployed on the authentication node and the consensus node include: a physical module, a smart contract module, a dynamic module, a front-end module and an application module;

The physical module is used to encapsulate all infrastructures that support the implementation of smart contracts;

The smart contract module is used to encapsulate static contract data;

The dynamic module is used to encapsulate dynamic operations on static contract data in the smart contract module;

The front-end module is used to encapsulate the protocol and voting mechanism;

The application module is used to encapsulate various scenarios and applications in the business flow.

Preferably, the physical module includes: a distributed ledger, a development environment and an oracle;

The distributed ledger is used to record all data processing process data on the shared access system;

The development environment includes a startup node based on computer code implementation, contract deployment, and contract invocation;

The oracle performs security management on the data source of the encrypted storage system based on the security rules of the blockchain.

Preferably, the initiating a data sharing request includes:

When a data user needs to use information about a project involved in a business, he or she first searches the blockchain to see if there is a corresponding index.

If so, the data user initiates a data request to the data owner based on the blockchain; otherwise, the data user initiates a data request based on the blockchain.

Preferably, providing a data sharing service according to a data sharing request includes:

After the data owner extracts the public key information and confirms that the data user is a legitimate role, the data that meets the standard requirements is encrypted using the public key and signed with the private key to generate an encrypted data packet, which is sent based on the blockchain.

Preferably, the confirming that the data user is a legitimate role includes: confirming that the data user is a legitimate user.

Preferably, the management of users includes: reviewing the roles and attributes of users joining the blockchain.

Preferably, the maintenance data access information includes:

Review the data information in the blockchain and send and store the data certificate;

Creating and storing index information for the data information in the blockchain;

It stores data sharing requests initiated by data users and data sharing services provided by data owners.

Compared with the prior art, the present invention has the following beneficial effects:

1. The shared access system constructed by the present invention is based on blockchain technology, which ensures the authenticity of data and the execution of contracts, realizes decentralization, and realizes a data management method for data sharing;

2. The shared access system constructed by the present invention is applied to the business system to realize the effective management of enterprise document data. The document data is securely shared by the business subsystem, the process is open and transparent, and the overall process ensures the integrity, verifiability and traceability of the data;

3. The judgment of legal roles in the technical solution provided by the present invention includes data flow legitimacy verification and data usage authority verification. This double verification ensures the security of data use and complies with the business's stricter security restrictions on data.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of the structure of a decentralized traceable shared access system of the present invention;

FIG2 is a diagram showing the structure of a smart contract model of the present invention;

FIG3 is a flow chart of a data management implementation method of the present invention;

FIG4 is data index information provided by the present invention;

FIG. 5 is a diagram showing the system operation process of the present invention.

DETAILED DESCRIPTION

The present invention utilizes the decentralized data management model provided by the blockchain to establish multiple business systems of the management information system and alliance chains of external users, establishes smart contracts on the blockchain through a predetermined identification mechanism, automatically identifies the rationality of user audit behavior in the entire audit process, and generates blocks through consensus among multiple parties on the alliance chain and uploads them to the chain. The application and processing of data by each user form data blocks and are automatically authenticated. Each data block contains a batch of network interaction information, which can prevent document data from being tampered with or forged, and can realize traceability of document data access records to verify the validity of its information.

Due to the characteristics of trustlessness, decentralization, collective maintenance and reliable database based on blockchain technology, when building a shared access system and applying it to the data management of the management information system, all relevant business system users can participate in the entire process of data management, making the workflow transparent and supervised, and all operations are recorded in an unalterable manner.

In order to better understand the present invention, the content of the present invention is further described below in conjunction with the accompanying drawings and examples.

Embodiment 1:

The present invention provides a decentralized traceable shared access system, which adopts blockchain technology, as shown in Figure 1, and is composed of multiple nodes, which are used to connect multiple business systems, and their main functions include receiving messages from business systems; completing blockchain generation and submission of own data information; and ensuring the security of the communication process. It includes authentication nodes and consensus nodes.

1) Public area on the chain: The main business system is used as a public area. Through the organization of the user authority system, the connection between personnel is realized, and the management of the original members and new members is realized through the authentication mechanism. (The principle of multiple votes is adopted. For example, when adding new members to the chain, the existing personnel on the chain need to confirm. After the majority confirmation, it means that the addition is legal. Similarly, other member operations, such as deletion and change of authority, are also the same.) By maintaining the public record block chain, the data change process is recorded, and data specifications, usage rules and data traceability are formulated. The authentication node is responsible for this, and the authentication node is elected or directly designated by the members on the chain.

2) On-chain member area: Each member will keep a backup of the public record blockchain, supervise the correctness of the blockchain data records in the main business process, and maintain its own document data for sharing, which is implemented by each consensus node.

wherein the consensus node is further configured to receive a statistical profile, wherein the statistical profile includes a network location of the consensus node and a performance specification of the consensus node, and wherein the shared access system implements a decentralized architecture comprising multiple types of peer connections layered on a CDN network, the CDN network having a plurality of CDN servers for providing a first set of segments of the document data to the consensus node;

wherein, when the CDN server receives a cache instruction sent by a consensus node, the CDN server returns a subset of the first group of segments of the document data, wherein the cache instruction is generated based on the statistical profile;

When a data user in the shared access system sends a request for accessing multiple target fragments of document data to the CDN server, the CDN server extracts the content type of the requested document data and the network location of the data user from the received request; selects multiple consensus nodes from the currently active consensus nodes in the shared access system to provide access to the multiple target fragments of the document data, generates a cache list, wherein the multiple consensus nodes are selected based on the network location of the data user user, the network location of the consensus nodes, and the content type of the requested document data; and transmits the generated cache list to the data user user.

The authentication node further determines an optimal distribution state of the plurality of segments of the document data to more than two consensus nodes of the network;

The optimal distribution state defines that each of the two or more consensus nodes needs to download identifiers of multiple fragments of the document data from the CDN server; multiple consensus nodes in the cache list cache multiple target fragments of the document data;

The cache instruction is further generated based on the content priority of the document data;

In response to receiving the identification request from the user, the consensus node transmits the identification to the user for use in the shared access system.

Before being authorized to share document data with data user users, the consensus nodes in the cache list confirm receipt of the payment authorization certificate of the authentication node, and after the user receives multiple target fragments of document data from multiple consensus nodes, the consensus node receives a service response signed by the data user user, and then sends an updated off-chain transaction to the multiple consensus nodes, and the off-chain transaction accumulates the total payment amount to determine the payment amount in the multiple target fragments including the document data.

In the preprocessing stage of the consensus process, the consensus node collects transactions in the transaction memory pool, packages the transactions into blocks and broadcasts them to other nodes for consensus. The current consensus node broadcasts the <precons, h, dig, block, s> pre-consensus message to other nodes, where: precons represents the message type is a pre-consensus message; h represents the block height; dig represents the summary of the block, that is, the block hash value, and block is the content of the entire block, including the collected transactions and the signatures of all transactions.

When all other consensus nodes receive the precons message sent by the current consensus node, they will first verify the message, check the validity of the summary, block height and signature, and then verify all transactions in it. After the verification is correct, the signed message <convs, h, dig, i> will be sent to the current consensus node. convs indicates that the message type is a consensus-ready message.

When listening to the convs message sent by each consensus node, the current consensus node verifies each convs message, and collects it if it passes the verification. Once the master node collects 2f+1 signatures, it verifies the batch of signatures and aggregates the verified signatures into one signature, broadcasts a <h, d, asign, n> submission message, asign is the signature synthesized after aggregation, n refers to the ID list of all consensus nodes participating in the aggregated signature, and f is the number of all consensus nodes; the nodes that receive the submission message later can use the public key of the nodes participating in the signature to verify whether the signature is correct. At this time, after each consensus node receives the aggregated signature of the current consensus node, if the verification is correct, it will link the block to the end of the blockchain chain to complete the synchronization, so that each consensus node can verify the authenticity of the aggregated signature based on the public key of the nodes participating in the signature without the need for full broadcast communication.

In the final confirmation phase, in order to send information to the next round of consensus master nodes, a timeout threshold t is set. If the next round of nodes have received more than half of the confirmation messages before t, it proves that most nodes are ready and can enter the consensus process of the next block in advance. If more than half of the nodes have not received messages within the timeout threshold t, the completed consensus results will be resent to the remaining consensus nodes, and then the next round of consensus process will be carried out.

To prevent a consensus node from deliberately not responding, if each consensus node does not receive a response from the current consensus node within the specified time t, it is considered that the current consensus node has failed, and a new node for the next round of consensus is selected. The node of the next round of consensus continuously monitors the messages sent by each consensus node to verify whether the block height in the message is consistent. After collecting 2f+1 messages, the signature of the message is verified, and the signatures that have passed the verification are summarized into a summary signature. The consensus node change message <next, v, h, asign, n> is encapsulated and broadcast to each consensus node. n refers to the list of all nodes participating in the summary signature, which is convenient for each consensus node to verify. Next indicates that the message type is a message that the consensus node is changed to the next round of consensus nodes. Finally, each consensus node verifies the summary signature after receiving the next message sent by the next round of consensus nodes. After the verification is completed, a verification response message is sent to the next round of master nodes to indicate that the verification is passed, and the next round of master nodes begins to pack blocks and start a new round of block consensus.

Embodiment 2:

Each node on the blockchain adopts a smart contract solution, which is implemented using the smart contract model shown in Figure 2, specifically including:

Physical module: encapsulates all infrastructure supporting the implementation of smart contracts, including distributed ledgers, development environments, and oracles.

Distributed ledger: The execution and interaction of smart contracts need to rely on consensus algorithms, communication networks and other technologies, and the final execution results will be recorded in a distributed ledger maintained by all nodes. In the present invention, a distributed ledger is used to record the data content of the shared access system.

Development environment: Smart contracts can be seen as computer programs running on the blockchain. As a computer program, development, deployment and debugging involve the development environment. The present invention also undertakes functions such as starting nodes, deploying contracts, and calling contracts.

Oracle: To ensure the security of the blockchain network, smart contracts generally run in an isolated sandbox execution environment. Oracles can provide trusted sandbox external data sources for contract queries or trigger contract execution. At the same time, in order to keep the contract execution results of distributed nodes consistent, smart contracts also achieve randomness by querying the oracle. In the present invention, the oracle is the data source that ensures a trusted encrypted storage system.

Smart contract module: encapsulates static contract data, including contract terms and audit methods agreed upon by all parties to the contract, coded scenario-response rules, and interaction rules between the contract and the outside world and between contracts specified by the contract creator. The smart contract module can be regarded as a static database of smart contracts, encapsulating all smart contract call, execution, and communication rules.

Dynamic module: encapsulates a series of dynamic operations on static contract data in the smart contract module, including mechanism design, formal verification, security check, etc. The application of smart contracts usually concerns the interests of various departments of an enterprise. Malicious, erroneous, and vulnerable smart contracts will bring huge losses. Dynamic modules are the key to ensuring that smart contracts can run correctly, safely, and efficiently according to the designer's wishes.

Front-end module: encapsulates the specific manifestation of smart contracts in the application of the present invention. Including decentralized applications (DApp) and decentralized autonomous organizations (DAO); decentralized applications are based on the transaction protocol defined by Ethereum, and are executed according to the conditions set on the blockchain. A decentralized organization is a node-based voting mechanism used in the present invention.

Application module: encapsulates the application scenarios of smart contracts in the present invention and shares the access system.

During the execution phase of the smart contract, the authentication node first records the current version of the first smart contract locally; after using multiple parameters to execute the current version of the first smart contract, the first authentication data in the authentication node is retrieved, the multiple parameters identify the authentication node to be retrieved and the first authentication data, and the second smart contract is configured to include the authentication data from the authentication node, the authentication data from the authentication node is based on the access transaction of the authentication node and based on the attributes of the blockchain ledger entry address, thereby implementing the access transaction of the second smart contract based on the first authentication data from the authentication node and based on the blockchain ledger entry address, wherein the blockchain ledger entry address identifies a candidate authentication node different from the current authentication node.

In a preferred embodiment, executing the current version of the first smart contract further includes: cyclically monitoring a plurality of consensus nodes for a plurality of data accessor user-specified documents of interest, wherein the plurality of data accessor user-specified documents of interest include asset transfers of a digital wallet specified by the data accessor user; and transmitting the result of the access transaction of the second smart contract to the plurality of consensus nodes based on the first authentication data from the authentication node and based on the blockchain ledger entry address. The result of the second smart contract is transmitted to an encrypted digital wallet, the digital wallet being configured to receive a portion of a dedicated encrypted token.

During the execution of the current version of the first smart contract, only when the predefined credibility indication reaches a threshold, the access transaction of the second smart contract is cyclically executed, and the document information of interest specified by multiple requesting users of multiple consensus nodes is cyclically monitored, wherein the document information of interest specified by the multiple data accessor users includes transactions belonging to a digital wallet specified by the data accessor user.

After executing the current version of the first smart contract, an access transaction for the second smart contract is transmitted to the candidate authentication node.

Embodiment 3:

There are three types of users in the present invention: data users and data service providers are other business systems, and data owners are the main business system.

1) Data owner: The data of each business system is maintained by document data for sharing, provides external data query services, and tracks the data usage process on demand.

2) Data users: Business systems initiate data usage requirements and obtain the right to use the marked data.

3) Data service provider: serves both the owner and the user by recording the data flow process, maintaining the flow order, and recording relevant situations.

As shown in FIG3 , another aspect of the present invention provides a data management implementation method, comprising:

Step 1: The business system implements and deploys the system and publishes the system's public key, data access rules, access content, access methods, and standard format for data sharing.

Step 2: Relevant business system users join the blockchain and are approved.

Step 3: Send the data certificate to the business system.

Step 4: Submit data index information. FIG4 shows an example diagram of data index information.

Step 5: Verify all received index information, summarize the verified records, and add them to the block to form a blockchain.

Embodiment 4:

Based on this, the operation process of the shared access system of the present invention is as follows:

1. When a data user needs to use the project information of a business, first search whether there is a corresponding index on the blockchain without obtaining the actual data content. If it exists, obtain all the information of this index, including information description, key information (public key and private key), signature, etc. The encryption algorithms used for the private key in the present invention include: DES, 3DES, TDEA, Blowfish, Scr2, Scr4, Scr5, IDEA, PKIPJACK, AES, etc.; the encryption algorithms used for the public key include: RSA, Elgamal, backpack algorithm, Rabin, D-H, ECC, etc.;

2. The data user initiates a data request through the main business system. The data request contains the HASH value of the data business main keyword generated by the hash algorithm, key information, request requirements, etc. If the corresponding index exists, it is sent to the department that needs to provide data. If the corresponding index does not exist, the request is initiated and waits for the data owner user to complete the business before responding to the request.

3. After the data owner user extracts the public key information and confirms that the data user is a legitimate role (the legitimate role here includes: the confirmed data user is a legitimate user), the data that meets the standard requirements is encrypted using the public key and signed with the private key to generate an encrypted data packet and send it to the main business system.

4. The main business system extracts the public key, verifies its legitimacy, decrypts the record with the private key and checks whether it is the requested HASH value. If so, the data is used to form a transaction record. The process is shown in Figure 5. In Figure 5, Block1 represents a distributed block; Header represents the main key information index, Body represents the information content, and Signature is a signature, which represents personal information. The data user specifies the user for the data service, including: determining the project information based on the main keyword of the data service, extracting relevant users from the user information list of the data service that is pre-stored in the service, and determining whether the data accessor user belongs to the relevant user. If so, the data user is considered to be the designated user of the data service. The role verification of the present invention includes dual verification of the legitimacy of the data process and the data usage authority verification, which ensures the security of data use on the basis of ensuring the security of the audit process.

In the present invention, after public key encryption and private key signature, an encrypted data packet is generated.

In a preferred embodiment, the authentication node of the shared access system and the business main system jointly generate the key SK and the re-encryption key based on a smart contract; the data related to the user attributes is sent to the business main system and the shared access system, and the re-encryption is completed using the decentralized shared access system.

First, the business main system generates a system public key and sends it to the data owner. The data owner uses the system public key and access policy to encrypt the data and upload it to the shared access system. The data owner returns the data identifier and access policy to the business main system, which writes it into the blockchain.

The data accessor sends a registration request to the system, the authentication node verifies its attributes and sends the user key, and then writes the attribute set into the block; the business main system reads the users and their attribute sets in the block, and sends the attribute key to the corresponding user; the business main system compares the data identifier and access policy in the block, and sends the re-encryption key to the shared access system; the data accessor downloads the re-encrypted ciphertext stored on the shared access system and performs decryption operations.

The node identity is described in a tree structure, and the identity is verified by a certificate chain. The smart contract code running on the node is involved in the authentication and authorization of blockchain operations. The node identity certificate consists of three parts: [Scr, psk, ppk], namely the self-signed certificate Scr, the system private key psk and the system public key ppk. Scr contains a document with attributes related to the certificate holder and a digital signature encrypted by psk. PPK is used to verify the validity of the root certificate.

HGN[i, j] can take the value of 1 or 0. When its value is 0, it means that the organization in the i-th row does not have the permission of the j-th column in its channel, otherwise it has the permission.

Embodiment 5:

The shared access system of the present invention further includes a data supervision process. The supervision content includes the standardization and quality of the data provided by the data owner user, whether the business system is used maliciously, and whether there is a risk of data leakage in the process. The preferred process is as follows:

The data owner first interacts with the authentication node and obtains the global authentication parameters. Then, the data owner generates a finite field and a distribution function F. Then the data owner initializes the hierarchical structure of the business system users and assigns a two-dimensional tensor (A _i , B _i ) to each business system user. Finally, by operating the tensor with the distribution function F, the data owner calculates the connection matrix in the global authentication parameters. The product of each business system user's tensor B _i and the corresponding public tensor is its corresponding encryption key. If two business systems do not have a hierarchical relationship, the product of the tensors associated with the two is zero. If they have a hierarchical relationship, the encryption key of the user of the business system at the next level can be calculated through the tensor of the user of the business system at the previous level.

The connection matrix is obtained by the following process:

The data owner randomly selects tensors A _i = (a _{i, 1} , a _{i, 2} ) and B _i = (b _i , ₁ , b _{i, 2} ) for business system user V _i , and maps all tensors A _i to a new tensor W _i through a distribution function F .

The data owner converts _Bi into an n-dimensional tensor _Γi . _γi,1 = _bi,1 , γi _,2 = bi _,i, and for j≠1,i, γi _,j = 0; the set of n-dimensional tensors _Γ1 = ( _γ1,1 , _γ1,2 , 0, ..., 0); _Γ2 = ( _γ2,1 , _γ2,2 , 0, ..., 0); _Γn = (γn _,1 , 0, ..., 0, γn _,n );

Calculating the Matrix

Determine whether the tensors Γ ₁ , Γ ₂ …Γ _n are related. If so, reselect B ₁ , B ₂ …B _n . Otherwise, select an encryption key for each class and calculate the connection matrix A. That is, for each business system user V _i , the data owner randomly selects his own encryption key

definition And Φ=[Φ ₁ ,...,Φ _n ] ^T , then Γ×A=Φ;

Solve the equations in the above steps to obtain A = Γ ^-1 × Φ;

The data owner sends Send it to the business system user V _i , and send F and A to the authentication node.

The method of the present invention can produce the following beneficial effects:

1) All information on the index chain contains specific business system keys and the original text cannot be exported, so there is no risk of leakage.

2) Data requests and responses between the operating system and the data owner, without the involvement of a third party, and no risk of leakage in the process.

3) Only the private key of the business system can decrypt the data packet, and there is no risk of third-party leakage.

4) The final usage results of the data are generated into the transaction chain of the business system, leaving traces and being traceable.

Obviously, the described embodiments are only some embodiments of the present invention, but not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on a plurality of computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program codes.

The present application is described with reference to the flowchart and/or block diagram of the method, device (system) and computer program product according to the embodiment of the present application. It should be understood that each process and/or box in the flowchart and/or block diagram, and the combination of the process and/or box in the flowchart and/or block diagram can be realized 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 produce a device for realizing the function specified in one process or multiple processes in the flowchart and/or one box or multiple boxes in the block diagram.

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 a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions may 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, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

The above are merely embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention are included in the scope of the claims of the present invention to be approved.

Claims (10)

1. A decentralized traceable shared access system, characterized by including authentication nodes and consensus nodes; The authentication node is used to manage users, manage document data and services, and maintain data access information based on various functional modules deployed on the authentication node; The consensus node is used to perform security management on users accessing the consensus node, initiate data sharing requests, and provide data sharing services according to the data sharing requests based on the various functional modules deployed on the consensus node; wherein the consensus node is further configured to receive a statistical profile, wherein the statistical profile includes a network location of the consensus node and a performance specification of the consensus node, and wherein the shared access system implements a decentralized architecture comprising multiple types of peer connections layered on a CDN network, the CDN network having a plurality of CDN servers for providing a first set of segments of the document data to the consensus node; wherein, when the CDN server receives a cache instruction sent by a consensus node, the CDN server returns a subset of the first group of segments of the document data, wherein the cache instruction is generated based on the statistical profile; When a data user in the shared access system sends a request for accessing multiple target fragments of document data to the CDN server, the CDN server extracts the content type of the requested document data and the network location of the data user from the received request; selects multiple consensus nodes from the currently active consensus nodes in the shared access system to provide access to the multiple target fragments of the document data, generates a cache list, wherein the multiple consensus nodes are selected based on the network location of the data user user, the network location of the consensus nodes, and the content type of the requested document data; and transmits the generated cache list to the data user user. 2. The system of claim 1, wherein the authentication node further determines an optimal distribution state of the plurality of segments of the document data to more than two consensus nodes of the network; The optimal distribution state defines that each of the two or more consensus nodes needs to download identifiers of multiple fragments of the document data from the CDN server; the multiple consensus nodes in the cache list cache multiple target fragments of the document data; The cache instruction is further generated based on the content priority of the document data; In response to receiving the identification request from the user, the consensus node transmits the identification to the user for use in the shared access system. 3. The system as described in claim 1 is characterized in that the consensus nodes in the cache list confirm receipt of the payment authorization certificate of the authentication node before being authorized to share document data with the data user user, and after the user receives multiple target fragments of document data from multiple consensus nodes, the consensus node receives a service response signed by the data user user, and then sends an updated off-chain transaction to the multiple consensus nodes, and the off-chain transaction accumulates the total payment amount to determine the payment amount in the multiple target fragments including the document data. 4. The system according to claim 1, characterized in that the functional modules deployed on the authentication node and the consensus node include: a physical module, a smart contract module, a dynamic module, a front-end module and an application module; The physical module is used to encapsulate all infrastructures that support the implementation of smart contracts; The smart contract module is used to encapsulate static contract data; The dynamic module is used to encapsulate dynamic operations on static contract data in the smart contract module; The front-end module is used to encapsulate the protocol and voting mechanism; The application module is used to encapsulate various scenarios and applications in the business flow. 5. The system of claim 4, wherein the physical module comprises: a distributed ledger, a development environment, and an oracle; The distributed ledger is used to record all data processing process data on the shared access system; The development environment includes a startup node based on computer code implementation, contract deployment, and contract invocation; The oracle performs security management on the data source of the encrypted storage system based on the security rules of the blockchain. 6. The system according to claim 5, wherein the initiating a data sharing request comprises: When a data user needs to use information about a project involved in a business, he or she first searches the blockchain to see if there is a corresponding index. If so, the data user initiates a data request to the data owner based on the blockchain; otherwise, the data user initiates a data request based on the blockchain. 7. The system according to claim 5, wherein providing a data sharing service according to a data sharing request comprises: After the data owner extracts the public key information and confirms that the data user is a legitimate role, the data that meets the standard requirements is encrypted using the public key and signed with the private key to generate an encrypted data packet, which is sent based on the blockchain. 8. The system as claimed in claim 7, characterized in that the confirming that the data user is a legitimate role includes: confirming that the data user is a legitimate user. 9. The system as claimed in claim 5, characterized in that the management of users includes: reviewing the roles and attributes of users joining the blockchain. 10. The system of claim 5, wherein the maintenance data access information comprises: Review the data information in the blockchain and send and store the data certificate; Creating and storing index information for the data information in the blockchain; It stores data sharing requests initiated by data users and data sharing services provided by data owners.