Blockchain-based technology service supply chain credible storage system

Abstract

This application relates to the field of blockchain evidence storage technology and discloses a blockchain-based trusted evidence storage system for a technology service supply chain. The system includes: a permission information storage module for storing the identity identifiers of each participant in the technology service supply chain, the unique identifiers of data resources, and the division rules for each stage of the contract lifecycle. The permission information storage module pre-sets basic permission mapping relationships, and the contract stage perception module captures stage transition events in real time. The permission rule engine module dynamically calculates actual access permissions using a weighted algorithm, ensuring that the access permissions of participants to data resources at different contract stages accurately match the business scenario. The blockchain evidence storage interaction module hashes all data, including permission configuration, stage determination, and access records, onto the blockchain, solving the problems of untraceable permission changes and easily tampered data in traditional evidence storage models, and providing a verifiable trust foundation for supply chain participants.

Description

Technical Field

[0001] This invention relates to the field of blockchain evidence storage technology, specifically a blockchain-based trusted evidence storage system for the technology service supply chain. Background Technology

[0002] As a core link connecting technology demanders, service providers, and related support institutions, the efficient operation of the technology service supply chain depends on the reliable flow of data throughout the entire process and precise access control.

[0003] In existing technologies, data storage in the technology service supply chain largely relies on centralized platforms (such as third-party electronic evidence storage systems or enterprise private databases). Data is stored and evidence certificates are generated through centralized servers, and the trust mechanism heavily depends on the platform's own security and credibility. Access control typically adopts a static configuration model, allocating permissions through pre-defined access control lists (ACLs) or role-based permission matrices. Permission adjustments require manual applications and multi-level approvals, making it difficult to adapt to the dynamic business needs of different stages in the supply chain (such as requirement confirmation, R&D implementation, and acceptance delivery). In some scenarios, evidence storage data and permission configurations are stored separately, and data access records are not linked to the evidence storage process, resulting in a lack of effective traceability for permission changes.

[0004] However, static access control cannot automatically adjust the access scope according to the contract stage, which can easily lead to problems such as "excessive permissions" (e.g., access to sensitive technical documents in non-critical stages) or "insufficient permissions" (e.g., inability to access necessary acceptance data during the acceptance stage). Furthermore, the lack of linkage between the permission change process and the evidence storage system makes it difficult to ensure the compliance and traceability of permission adjustments, and fails to meet the dual requirements of data credibility and dynamic permissions in the technology service supply chain. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a blockchain-based trusted evidence storage system for the technology service supply chain, which solves the problem of difficulty in ensuring the compliance and traceability of permission adjustments.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a blockchain-based trusted evidence storage system for technology service supply chains, comprising:

[0007] Permission information storage module: used to store the identity identifiers of each participating entity in the technology service supply chain, the unique identifiers of data resources, the division rules of each stage of the contract life cycle, the definition rules of contract status identifiers, the preset conditions for smart contract triggering events, and the basic access permission mapping relationship between participating entities and data resources at each stage;

[0008] Contract Stage Awareness Module: Based on the contract status identifier definition rules and smart contract trigger event preset conditions stored in the permission information storage module, it listens to on-chain data through the blockchain node interface and parses the contract status identifier or trigger event in real time based on the contract status identifier definition rules and smart contract trigger event preset conditions stored in the permission information storage module.

[0009] Permission rule engine module: Receives the current contract stage information output by the contract stage perception module, calls the basic access permission mapping relationship between participating entities and data resources in the permission information storage module, and calculates the actual access permissions of each participating entity to the target data resource in the current stage by combining the preset dynamic adjustment algorithm.

[0010] Permission execution module: Receives the actual access permissions output by the permission rule engine module, verifies the data resource access requests initiated by participating entities, and only allows requests that pass the verification to obtain the access key or decryption permission for the corresponding data resource;

[0011] The blockchain evidence storage and interaction module stores the identity identifiers of each participating entity, the unique identifier of the data resource, the division rules for each stage of the contract's entire lifecycle, the definition rules for the contract status identifier, the preset conditions for smart contract trigger events and the basic access permission mapping relationship stored in the permission information storage module, the current stage information and judgment timestamp output by the contract stage perception module, the actual access permission calculation results output by the permission rule engine module, and the access records generated by the permission execution module on the blockchain in hash form, ensuring that the permission configuration and change process is traceable.

[0012] Preferably, the "basic access permission mapping relationship between participating entities and data resources" in the permission information storage module specifically includes: the role attributes of participating entities determined based on their functional responsibilities in the supply chain, the sensitive attributes of data resources determined based on the leakage risk level, and the matching permission values ​​of the role attributes and sensitive attributes corresponding to each contract stage, wherein the range of the matching permission values ​​is 0 to 1.

[0013] Preferably, the dynamic adjustment algorithm used by the permission rule engine module is a permission coefficient weighting algorithm based on the contract stage, used to calculate the actual access permission value of the participating entity to the target data resource in the current stage, as shown in the following formula:

[0014]

[0015] Participating entities During the contract stage Data resources The actual access permission value ranges from 0 to 1, where 0 indicates no access permission and 1 indicates full access permission.

[0016] The total number of stages in the entire contract lifecycle;

[0017] : No. The weighting coefficients for each stage are agreed upon in advance by the participating entities and satisfy the following conditions: ;

[0018] Participating entities In the preset number Stage of data resources The basic permission value ranges from 0 to 1.

[0019] : Stage matching function, when the current stage With the When the stages are consistent, =1; when the current stage With the When the stages are inconsistent, =0.

[0020] Preferably, the dynamic adjustment algorithm further includes a temporary permission correction coefficient. The The value range is 0 to 0.2, used to handle temporary adjustments to permissions beyond the preset conditions. The formula for the corrected actual access permission value is:

[0021]

[0022] in, The validity of the agreement requires the signature confirmation of multiple parties involved in the contract, and the signature information and correction records are stored on the blockchain through the blockchain evidence storage interaction module. The signature confirmation of multiple parties involved must include the digital signatures of the data resource owner, the contract supervisor, and the responsible party at the current stage.

[0023] Preferably, the "rules for dividing each stage of the contract's entire lifecycle" in the permission information storage module include the start and end conditions for each stage, the trigger thresholds for stage transitions, and the stage identifier coding rules. These division rules are jointly confirmed by the participating parties during contract initialization and are solidified on the blockchain through the blockchain evidence storage and interaction module. The trigger thresholds for stage transitions are used to dynamically adjust the weighting coefficients. .

[0024] Preferably, when verifying an access request, the permission execution module needs to submit a verification transaction to the blockchain node, and the smart contract compares the actual permission value stored on the chain. The verification result is then returned.

[0025] Preferably, the permission execution module includes a permission freezing module, which is further used to detect abnormal access. When an abnormal access is detected, the module automatically invokes a smart contract to change the actual access permissions of the corresponding participating entity to the target data resource. The value is reset to 0, and an audit process is triggered. The criteria for determining abnormal access are stored in the permission information storage module.

[0026] Preferably, the sensitive attributes of the data resources are dynamically adjusted according to the contract stage, and the adjustment rules are automatically executed by the smart contract during stage transition. The role attributes support inheritance, and child roles automatically acquire the basic permission values ​​of the parent role at the same stage. .

[0027] This invention provides a blockchain-based trusted evidence storage system for the technology service supply chain. It offers the following advantages:

[0028] 1. This invention uses a permission information storage module to pre-set basic permission mapping relationships, combined with a contract stage perception module to capture stage transition events in real time. The permission rule engine module dynamically calculates actual access permissions using a weighted algorithm, ensuring that the access permissions of participating entities to data resources at different contract stages accurately match the business scenario. Simultaneously, the blockchain evidence storage and interaction module hashes all data—including permission configuration, stage determination, and access records—onto the blockchain, solving the problems of untraceable permission changes and easily tampered data in traditional evidence storage models, and providing a verifiable trust foundation for supply chain participants.

[0029] 2. This invention introduces a temporary permission correction coefficient and a role attribute inheritance mechanism. This ensures the compliance of temporary permission adjustments through multi-party signature confirmation and on-chain evidence storage, while simplifying the permission configuration process for complex supply chains by automatically inheriting parent role permissions from child roles. Furthermore, the permission execution module utilizes a real-time verification mechanism based on blockchain smart contracts, combined with the abnormal access response function of the permission freezing module. This effectively reduces the risk of permission abuse while meeting the protection requirements for sensitive intellectual property data in technology services, and enhances the system's adaptability to complex business scenarios. Attached Figure Description

[0030] Figure 1 This is a system block diagram of the present invention. Detailed Implementation

[0031] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0032] Example:

[0033] Please see the appendix Figure 1 This invention provides a blockchain-based trusted evidence storage system for the technology service supply chain, comprising:

[0034] Permission information storage module: used to store the identity identifiers of each participating entity in the technology service supply chain, the unique identifiers of data resources, the division rules of each stage of the contract life cycle, the definition rules of contract status identifiers, the preset conditions for smart contract triggering events, and the basic access permission mapping relationship between participating entities and data resources at each stage;

[0035] Furthermore, the identity identifier is stored in a decentralized identifier (DID) format conforming to the W3C standard, containing verifiable public key information and verification methods. The unique identifier of the data resource is implemented using a content-addressed identifier (CID) or a universally unique identifier (UUID). The basic access permission mapping relationship is stored in the form of a structured database table, whose fields include at least the participant identifier, data resource identifier, contract phase identifier, and basic permission value (P0).

[0036] The basic access permission mapping relationship between participating entities and data resources specifically includes: the role attributes of participating entities determined based on their functional responsibilities in the supply chain, the sensitive attributes of data resources determined based on predefined leakage risk levels, and the matching permission values ​​(i.e., basic permission value P0) of the role attributes and sensitive attributes corresponding to each contract stage; the matching permission value ranges from 0 to 1, and this value is automatically generated and stored by the system during contract initialization based on the preset role attribute and sensitive attribute matching rule table.

[0037] Contract Stage Awareness Module: Based on the contract status identifier definition rules and smart contract trigger event preset conditions stored in the permission information storage module, it listens to on-chain data through the blockchain node interface and parses the contract status identifier or trigger event in real time based on the contract status identifier definition rules and smart contract trigger event preset conditions stored in the permission information storage module.

[0038] Furthermore, the monitoring of on-chain data is implemented using an event subscription mechanism. The module subscribes to specific smart contract event logs related to the contract state through the API provided by the blockchain node. The real-time parsing process performs pattern matching and parameter extraction on the monitored event logs according to pre-stored rules, identifies valid contract state change information or preset trigger events, and outputs the current contract stage identifier (c) and the judgment timestamp.

[0039] Permission rule engine module: Receives the current contract stage information output by the contract stage perception module, calls the basic access permission mapping relationship between participating entities and data resources in the permission information storage module, and calculates the actual access permissions of each participating entity to the target data resource in the current stage by combining the preset dynamic adjustment algorithm.

[0040] Permission execution module: Receives the actual access permissions output by the permission rule engine module, verifies the data resource access requests initiated by participating entities, and only allows requests that pass the verification to obtain the access key or decryption permission for the corresponding data resource;

[0041] The verification process is as follows: When the permission execution module receives an access request, it generates a verification request data packet containing the request subject identifier, the target data resource identifier, and the current timestamp, and submits a verification transaction to the blockchain network. This transaction calls the permission verification smart contract deployed on the blockchain. The contract reads the latest valid actual access permission value (Pa,c,d or Pa,c,d') record stored on the chain and matches it with the subject and resource identifier in the verification request. If the match is successful and the permission value is greater than the preset access threshold, a verification pass result is returned; otherwise, a rejection result is returned.

[0042] Only upon receiving a successful verification result from the blockchain, the permission enforcement module provides the requester with a short-lived data resource access token or partial decryption key via a secure communication channel. Detailed information and verification / authorization results for all access requests are logged.

[0043] The blockchain evidence storage and interaction module stores the identity identifiers of each participating entity, the unique identifier of the data resource, the division rules for each stage of the contract's entire lifecycle, the definition rules for the contract status identifier, the preset conditions for smart contract trigger events and the basic access permission mapping relationship stored in the permission information storage module, the current stage information and judgment timestamp output by the contract stage perception module, the actual access permission calculation results output by the permission rule engine module, and the access records generated by the permission execution module on the blockchain in hash form, ensuring that the permission configuration and change process is traceable.

[0044] Furthermore, the on-chain evidence preservation process is as follows: For the data item to be preserved or its structured digest, a hash digest value is calculated using a cryptographic hash function (such as SHA-256); the hash digest value, the evidence preservation data type identifier, the associated contract identifier, and the timestamp are packaged into evidence preservation transaction data; this evidence preservation transaction is submitted to the blockchain network for consensus verification and recorded in the distributed ledger. The original data or verifiable credentials can be stored in an off-chain distributed storage system (such as IPFS), and their content identifier (CID) is included in the evidence preservation transaction data and uploaded to the blockchain together.

[0045] In this embodiment, the "basic access permission mapping relationship between participating entities and data resources" in the permission information storage module specifically includes: the role attributes of participating entities determined based on their functional responsibilities in the supply chain, the sensitive attributes of data resources determined based on the leakage risk level, and the matching permission values ​​of the role attributes and sensitive attributes corresponding to each contract stage, with the matching permission values ​​ranging from 0 to 1.

[0046] In this embodiment, the dynamic adjustment algorithm used by the permission rule engine module is a permission coefficient weighting algorithm based on the contract stage, which is used to calculate the actual access permission value of the participating entity to the target data resource in the current stage. The formula is as follows:

[0047]

[0048] Participating entities During the contract stage Data resources The actual access permission value ranges from 0 to 1, where 0 indicates no access permission and 1 indicates full access permission.

[0049] The total number of stages in the entire contract lifecycle;

[0050] : No. The weighting coefficients for each stage are agreed upon in advance by the participating entities and satisfy the following conditions: ;

[0051] Participating entities In the preset number Stage of data resources The basic permission value ranges from 0 to 1.

[0052] : Stage matching function, when the current stage With the When the stages are consistent, =1; when the current stage With the When the stages are inconsistent, =0.

[0053] In this embodiment, the dynamic adjustment algorithm also includes a temporary permission correction coefficient. , The value range is 0 to 0.2, used to handle temporary adjustments to permissions beyond the preset conditions. The formula for the corrected actual access permission value is:

[0054]

[0055] in, The validity of the agreement requires the signature confirmation of multiple parties involved in the contract, and the signature information and correction records are stored on the blockchain through the blockchain evidence storage interaction module. The signature confirmation of multiple parties involved must include the digital signatures of the data resource owner, the contract supervisor, and the responsible party at the current stage.

[0056] In this embodiment, the "rules for dividing each stage of the contract's entire lifecycle" in the permission information storage module include the start and end conditions for each stage, the trigger thresholds for stage transitions, and the stage identification coding rules. The start and end conditions clearly define the on-chain event or data state conditions that must be met for each stage to begin and end. The trigger thresholds for stage transitions define the key indicator values ​​that trigger stage state transitions. The stage identification coding rules define the unique coding format for each stage. The division rules are jointly confirmed by the participating parties during contract initialization and are solidified on the blockchain through the blockchain evidence storage and interaction module. The achievement of the stage transition trigger thresholds serves as an input parameter and can be used to dynamically adjust the weight coefficient W of subsequent related stages. k This adjustment logic is pre-configured in the permission rules engine module.

[0057] In this embodiment, when verifying an access request, the permission execution module needs to submit a verification transaction to the blockchain node, and the smart contract compares the actual permission value stored on the chain. The verification result is then returned.

[0058] In this embodiment, the permission execution module includes a permission freezing module. The permission freezing module is also used to detect abnormal access. When an abnormal access is determined, the smart contract is automatically invoked to change the actual access permission value of the corresponding participating entity to the target data resource. The value is reset to 0, and an audit process is triggered. The criteria for determining abnormal access are stored in the permission information storage module.

[0059] In this embodiment, the sensitive attribute values ​​of data resources are dynamic throughout the contract lifecycle, and their adjustment rules are predefined and stored in the permission information storage module. When the contract phase awareness module detects a contract phase transition event, it triggers the execution of the smart contract logic corresponding to the adjustment rule. This smart contract automatically updates the sensitive attribute values ​​of the corresponding data resources in the permission information storage module.

[0060] The role attributes of participating entities support inheritance. Unless explicitly defined to override permissions, child roles automatically inherit their parent roles' base permission values ​​for the same data resource d at the same contract stage k. .

[0061] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A blockchain-based trusted evidence storage system for technology service supply chains, characterized in that, include: Permission information storage module: used to store the identity identifiers of each participating entity in the technology service supply chain, the unique identifiers of data resources, the division rules of each stage of the contract life cycle, the definition rules of contract status identifiers, the preset conditions for smart contract triggering events, and the basic access permission mapping relationship between participating entities and data resources at each stage; Contract Stage Awareness Module: Based on the contract status identifier definition rules and smart contract trigger event preset conditions stored in the permission information storage module, it listens to on-chain data through the blockchain node interface and parses the contract status identifier or trigger event in real time based on the contract status identifier definition rules and smart contract trigger event preset conditions stored in the permission information storage module. The permission rule engine module receives the current contract stage information output by the contract stage perception module, calls the basic access permission mapping relationship between participating entities and data resources in the permission information storage module, and calculates the actual access permissions of each participating entity to the target data resources in the current stage in combination with the preset dynamic adjustment algorithm. When the contract stage changes, the permission rule engine module dynamically updates the weight coefficient based on the stage change trigger threshold. Permission execution module: Receives the actual access permissions output by the permission rule engine module, verifies the data resource access requests initiated by participating entities, and only allows requests that pass the verification to obtain the access key or decryption permission for the corresponding data resource; The blockchain evidence storage and interaction module stores the identity identifiers of each participating entity, the unique identifier of the data resource, the division rules for each stage of the contract's entire lifecycle, the definition rules for the contract status identifier, the preset conditions for smart contract triggering events and the basic access permission mapping relationship stored in the permission information storage module, the current stage information and judgment timestamp output by the contract stage perception module, the actual access permission calculation results output by the permission rule engine module, and the access records generated by the permission execution module on the blockchain in hash form to ensure that the permission configuration and change process is traceable.

2. The blockchain-based trusted evidence storage system for technology service supply chains according to claim 1, characterized in that, The "basic access permission mapping relationship between participating entities and data resources" in the permission information storage module specifically includes: the role attributes of participating entities determined based on their functional responsibilities in the supply chain, the sensitive attributes of data resources determined based on the leakage risk level, and the matching permission values ​​of the role attributes and sensitive attributes corresponding to each contract stage, wherein the range of the matching permission values ​​is 0 to 1.

3. The blockchain-based trusted evidence storage system for technology service supply chains according to claim 1, characterized in that, The permission rule engine module uses a dynamic adjustment algorithm based on the contract phase's permission coefficient weighting algorithm to calculate the actual access permissions of participating entities to the target data resources in the current phase. The formula is as follows: Participating entities During the contract stage Data resources The actual access permission value ranges from 0 to 1, where 0 indicates no access permission and 1 indicates full access permission. The total number of stages in the entire contract lifecycle; : No. The weighting coefficients for each stage are agreed upon in advance by the participating entities and satisfy the following conditions: ; Participating entities In the preset number Stage of data resources The basic permission value ranges from 0 to 1; : Stage matching function, when the current stage With the When the stages are consistent, =1; when the current stage With the When the stages are inconsistent, =0.

4. The blockchain-based trusted evidence storage system for technology service supply chains according to claim 3, characterized in that, The dynamic adjustment algorithm also includes a temporary permission correction coefficient. The The value range is 0 to 0.2, used to handle temporary adjustments to permissions beyond the preset conditions. The formula for the corrected actual access permission value is: in, The validity of the agreement requires the signature confirmation of multiple parties involved in the contract, and the signature information and correction records are stored on the blockchain through the blockchain evidence storage interaction module. The signature confirmation of multiple parties involved must include the digital signatures of the data resource owner, the contract supervisor, and the responsible party at the current stage.

5. A blockchain-based trusted evidence storage system for technology service supply chains according to claim 3, characterized in that, The "rules for dividing each stage of the contract's entire lifecycle" in the permission information storage module include the start and end conditions for each stage, the trigger thresholds for stage transitions, and the stage identification coding rules. These division rules are jointly confirmed by the participating parties during contract initialization and are solidified on the blockchain through the blockchain evidence storage and interaction module. The trigger thresholds for stage transitions are used to dynamically adjust the weighting coefficients. .

6. A blockchain-based trusted evidence storage system for technology service supply chains according to claim 1, characterized in that, When verifying an access request, the permission execution module needs to submit a verification transaction to the blockchain node, and the smart contract compares the actual permission value stored on the chain. The verification result is then returned.

7. A blockchain-based trusted evidence storage system for technology service supply chains according to claim 1, characterized in that, The permission execution module includes a permission freezing module, which is also used to detect abnormal access. When an abnormal access is detected, the module automatically invokes a smart contract to change the actual access permissions of the corresponding participating entity to the target data resource. The value is reset to 0, and an audit process is triggered. The criteria for determining abnormal access are stored in the permission information storage module.

8. A blockchain-based trusted evidence storage system for technology service supply chains according to claim 2, characterized in that, The sensitive attributes of the data resources are dynamically adjusted according to the contract stage. The adjustment rules are automatically executed by the smart contract during stage transitions. The role attributes support inheritance, and child roles automatically acquire the basic permission values ​​of their parent roles at the same stage. .

Images