Dynamic management and control method for data access authority in agricultural product tracing alliance chain

Abstract

The invention relates to the technical field of block chains, and discloses a data access permission dynamic management and control method in an agricultural product tracing alliance chain, and the method comprises the steps: binding a permission occurrence automaton for a data record on a chain, and abstracting an access permission into a group of discrete states which are transferred by a business event triggering state; when an alliance internal access request is received, authorization judgment is carried out according to the real-time state of the automaton and the role of a requester; when cross-domain entrustment is processed, the promise hash of the permission plaintext is chained and recorded by an owner, and the external entity needs to pass two-stage verification of state fusing and promise comparison during access. According to the invention, deep coupling and automatic synchronization of the authority and the business state are realized, and on-chain commitment and off-chain distribution mechanisms are adopted, so that commercial privacy is protected while authorization traceability and dynamic revocation are ensured, and safe, flexible and refined authority control is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchain, in particular to a data access permission dynamic management and control method in an agricultural product traceability alliance chain. BACKGROUND

[0002] In an agricultural product traceability system constructed by using an alliance chain technology, how to accurately, dynamically and safely control the access of traceability data throughout the complete life cycle (from planting, processing, quality inspection, logistics to final sales) of a product is a key technical problem to ensure the effectiveness and credibility of the system.

[0003] Currently, the access control mechanism in the blockchain system, the permission model of which is usually statically configured in the system deployment phase. For example, the role-based access control (RBAC) model, which predefines the roles of "manufacturer", "logistics company", "regulatory agency" and their fixed permission sets. However, the state of agricultural products is continuously evolving in the actual circulation process, for example, a product will change from "in stock" to "in transit" or from "to be inspected" to "quality inspection qualified". The static permission model of the prior art cannot be linked with the actual business state of the product asset. When the product state changes and the data access permission needs to be adjusted accordingly, it often needs to rely on manual, off-chain permission change operations by administrators. This management method is not only inefficient and prone to errors, but more importantly, it causes a delay and disconnection between the permission state of the on-chain data and the physical world state of the asset, which cannot meet the real-time and automated adjustment requirements of the permission in complex traceability scenarios.

[0004] In addition, the business chain of agricultural product traceability often needs to interact with external entities that are not members of the alliance chain, for example, providing quality inspection reports to potential bulk purchasers for decision-making or showing core traceability information to end consumers. The prior art faces difficulties in handling such cross-domain permission delegation. If the external entity is absorbed as a formal member of the alliance chain, the process is complex, costly, and brings unnecessary system risks and privacy exposure. If a traditional off-chain authentication and authorization method (such as API key) is used, it completely deviates from the trust system of the blockchain itself, the authorization behavior itself is not transparent and traceable, and it cannot achieve dynamic risk management and control based on the real-time state on the chain. Once the authorization is issued, it is difficult to quickly and reliably revoke it in the event of an accident (such as a quality dispute over a product), which poses a significant security risk.

[0005] Further, when performing the above-mentioned permission delegation, the prior art also lacks privacy protection of the authorized content and the authorized behavior. Directly recording specific authorization strategies (for example, which entity is authorized, which data field is authorized to access, and how long the authorization is valid) on the chain exposes sensitive business cooperation. Moreover, the granularity of authorization is often not fine enough, and operators are often forced to choose between "not sharing at all" and "sharing too much information", making it difficult to achieve precise authorization for specific data items with a time limit, which greatly limits the application value of traceability data in business cooperation and marketing. SUMMARY

[0006] In view of the deficiencies of the prior art, the present application provides a data access permission dynamic management method in a farm product traceability alliance chain, which solves the problems of the existing farm product traceability alliance chain data access control method, such as rigid permission model, inability to respond to dynamic traceability events, and centralized management risk and privacy leakage risk when performing cross-domain authorization.

[0007] To achieve the above-mentioned purpose, the first aspect of the present application provides a data access permission dynamic management method in a farm product traceability alliance chain, which comprises:

[0008] For one or more traceability data records to be managed in the alliance chain, an independent permission automaton is created and bound. The permission automaton is a smart contract on the chain, which has a set of permission states and one or more state transition functions driven by on-chain events defined in advance. The permission state of the permission automaton can automatically change within the set of permission states according to the state transition function and the received on-chain event.

[0009] Based on a real-time permission state of the permission automaton after the transition, the received data access request is processed, which includes:

[0010] If the access request is an intra-alliance access request, the real-time permission state is obtained, and a preset access control decision function is used to output an authorization decision result according to the user role of the access requester and the real-time permission state;

[0011] If the access request is a cross-domain permission delegation request, and the real-time permission state is a preset delegable state, the generation and verification process of a permission commitment ticket is executed, which includes: preparing a permission plaintext containing authorization content off-chain, calculating a commitment hash of the permission plaintext and recording it in the permission automaton, and then distributing the permission plaintext through an off-chain channel.

[0012] In an embodiment of the present application, the permission assignment automaton can be formally defined as a quadruple PGA D =(S,E,δ,s init ), wherein:

[0013] S is a set of permission states, whose elements are the permission states that the provenance data record can be in;

[0014] E is a set of on-chain events, whose elements are on-chain verified events that can trigger state transitions;

[0015] δ is a state transition function, whose input is the current permission state and the triggered on-chain event, and whose output is the next permission state;

[0016] s init is the initial permission state of the permission assignment automaton at creation, s init ∈S.

[0017] In an embodiment of the present application, in the process of generating the permission commitment ticket, the step of calculating the commitment hash is specifically: using a preset cryptographic hash function to operate on the permission plaintext to generate the commitment hash. The calculation formula is:

[0018] C hash =H(ID ext ||P spec ||T exp ||N);

[0019] Wherein, C hash is the commitment hash; H is the cryptographic hash function; ID ext is the external entity identity; P spec is the specific permission range; T exp is the expiration timestamp; N is a random number; || is the normalized byte splicing operator.

[0020] In an embodiment of the present application, the step of verifying the permission commitment ticket comprises:

[0021] performing a first-stage verification, which obtains the real-time permission state of the permission assignment automaton and judges whether the real-time permission state is still the delegable state; if the judgment result is no, the process is aborted and the result of access denied is output;

[0022] If the judgment result of the first-stage verification is yes, a second-stage verification is performed, which receives the permission plaintext submitted by the external entity, recalculates a verification commitment hash using the permission plaintext and the cryptographic hash function, and compares the verification commitment hash with the commitment hash recorded in the permission assignment automaton;

[0023] The authorized access result is output if and only if the comparison result of the second stage verification is consistent.

[0024] A second aspect of the present invention provides a dynamic data access control system for an agricultural product traceability consortium blockchain, the system comprising:

[0025] The permission model establishment module is configured to create and bind an independent permission automaton for one or more traceable data records to be managed in the consortium blockchain. The permission automaton is an on-chain smart contract, which predefines a set of permission states and one or more state transition functions driven by on-chain events so that its permission states can evolve automatically.

[0026] The authorization decision module is configured to classify and process different types of access requests based on a real-time permission state evolved from the permission automaton. The authorization decision module includes:

[0027] The in-chain adjudication unit is configured to obtain the real-time permission status for access requests within the consortium, and output the authorization judgment result by combining the user role of the access requester through a preset access control decision function.

[0028] The cross-domain delegation unit is configured to address the need for cross-domain permission delegation. When the real-time permission status is a preset delegateable status, it executes the generation and verification process of permission commitment tickets. The generation process includes preparing permission plaintext containing authorization content off-chain, calculating the commitment hash of the permission plaintext and recording it in the permission fuzzy automaton, and then distributing the permission plaintext through an off-chain channel.

[0029] This invention provides a method for dynamic control of data access permissions in an agricultural product traceability alliance chain.

[0030] It has the following beneficial effects:

[0031] 1. This invention creates and binds an independent permission automaton containing a state transition function to each traceability data record, and uses on-chain events to drive the automatic transition of its permission state, directly linking the lifecycle of data permissions with the actual events occurring in the traceability process. This transforms permission configuration from post-event manual static management to in-event automated dynamic response, reducing the lag and operational complexity of permission management.

[0032] 2, The application sets the first stage verification step of checking the real-time state of the permission assignment automaton first when verifying the permission commitment ticket, establishes a control mechanism of on-chain state to off-chain certificate, and if the state of the permission assignment automaton is out of the preset delegable state due to the triggering of on-chain events, any permission commitment ticket based on the delegable state will be invalidated when verified, forming a decentralized revocation and fuse function, and improving the security of cross-domain delegation authorization.

[0033] 3, The application adopts the technical means of recording the commitment hash of the permission plaintext on the chain and distributing the permission plaintext itself through an off-chain channel. This design separates the specific content of the authorization from the on-chain public data, and only uses the blockchain for existence and integrity verification. This way, while realizing trusted delegation, it avoids the public disclosure of commercial sensitive information on the chain, protecting the privacy of the data owner. BRIEF DESCRIPTION OF DRAWINGS

[0034] Figure 1 The method flowchart of the application;

[0035] Figure 2 The system architecture diagram of the application.

[0036] Among them, 10, permission model establishment module; 20, authorization decision module; 21, on-chain decision unit; 22, cross-domain delegation unit. DETAILED DESCRIPTION

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

[0038] Embodiment:

[0039] Please refer to the drawings Figure 1 The embodiment of the application provides a data access permission dynamic management and control method in an agricultural product traceability alliance chain, which comprises the following steps:

[0040] S100: Initialization and construction of the permission model. For one or more traceability data records to be managed and controlled in the alliance chain, an independent permission assignment automaton is created and bound respectively.

[0041] The execution of this embodiment begins with a pre-defined step: deploying a permissioned automaton factory contract on the consortium blockchain network. This factory contract is a singleton contract, and its address is known internally within the system. Internally, the contract stores the standard contract bytecode template for the permissioned automaton and provides an externally callable creation function.

[0042] When a consortium blockchain participant successfully creates a new traceability data record D through the main traceability contract, the main traceability contract generates a unique identifier ID for that data record. D Subsequently, the main traceability contract or its associated backend services will use the ID. D As a parameter, initiate a transaction to the deployed PGAFactory contract and call its createPGA function.

[0043] After receiving the call request, the PGAFactory contract performs the following operations: First, using its internally stored bytecode template, it deploys a new, independent PGA contract instance on the consortium blockchain, denoted as PGA. D And obtain the unique on-chain address Addr(PGA) of the new contract. D Next, the PGAFactory contract updates an internal mapping-type state variable that stores the mapping between profiling data record identifiers and PGA contract addresses. Specifically, it updates key-value pairs (IDs). D Addr(PGA) D This is written into the mapping state variable, thereby completing the permanent binding between the traceability data record and its exclusive permission automaton.

[0044] Each created PGA D Each contract instance includes a complete set of formal definitions for implementing its quadruple PGA. D =(S,E,δ,s) init The logic and data structure of ).

[0045] The permission state set S is implemented internally as an enumeration type or a set of integer constants within the contract. In a specific agricultural product traceability scenario, this set S can include the following states:

[0046] In the initial state, only the creator's address (owner) of the data record has the right to read or modify the associated data.

[0047] Once a product enters the circulation phase within the alliance, the data can be read by the address of a member with a specific on-chain role (such as a logistics provider or warehouse keeper).

[0048] The system has entered a review state as required by regulators, and only addresses with regulatory roles can read the data.

[0049] In the event of a quality dispute or data lockout, all access is prohibited except at a designated arbitration address.

[0050] The on-chain event set E corresponds to the PGA. D A set of functions with specific access permissions within a contract. External events trigger state transitions by calling these functions. For example:

[0051] event PGA is invoked via the certified logistics provider address. D The contract's startLogistics() function is used to trigger it.

[0052] event After receiving a qualified test report from an offline laboratory through a registered oracle service, it invokes the PGA. D The contract's reportQCPass() function is used to trigger this.

[0053] event PGA accessed via regulatory address D The contract's raiseDispute() function is used to trigger it.

[0054] The state transition function δ is the PGA D The core logic of a contract is encoded in one or more internal functions. For example, a contract might have an internal function called `updateStateOnEvent` that takes the event type as input and contains a set of conditional statements.

[0055] When the startLogistics() function is successfully invoked, it calls updateStateOnEvent.

[0056] This function checks if the current state `currentState` is `PRIVATE`. If it is, it updates the value of `currentState` to `INTERNAL`. This operation is... The programmatic implementation.

[0057] Similarly, when `raiseDispute()` is called, regardless of the current state value, the function will forcibly update `currentState` to `Lockep`. The implementation of.

[0058] Initial permission state s init It is PGA DThe contract is created by the PGA Factory contract, whose constructor assigns an initial value to its internal currentState state variable. In this embodiment, s init is set to PRIVATE, ensuring that the newly created provenance data record has the highest access isolation in the initial stage.

[0059] This contract is responsible for registering, deregistering, and querying the addresses of the alliance members and their corresponding roles (e.g., logistics, regulatory agencies). Before making a decision, the access control gateway will first call this contract to verify the validity of the role R U of the requesting party U. This makes the role system itself decentralized and auditable.

[0060] S200: In-chain access request decision based on permission model. When receiving an access request within the alliance, the real-time permission state of the permission assignment automaton is used to make an authorization decision.

[0061] This process is initiated by an authorized user U within the alliance, who has an authenticated on-chain role R U . User U initiates a read request for a specific provenance data record D to an access control gateway of the system, which includes the unique identifier ID D of the data record.

[0062] Upon receiving the request, the access control gateway first performs a PGA discovery operation. It queries the address mapping table deployed in the PGA Factory contract in step S100 using ID D as the key. Through this query, the gateway obtains the on-chain address Addr(PGA D ) of the PGA D contract instance PGA D that is uniquely bound to data record D.

[0063] After successfully locating PGA D , the access control gateway initiates a read-only call to address Addr(PGA D ) to read the value of its internally stored current permission state variable currentState. This operation does not produce a state change and is only used to obtain the real-time permission state of the data record, denoted as s curr .

[0064] Subsequently, the access control gateway executes an access control decision function ACL(R U , s curr ) to make an authorization decision. This decision function is implemented as a pre-set query table that records the mapping relationship between user roles and permission states.

[0065] The query table defines a set of access control rules, each of which is a triple (Role, State, Permission), where:

[0066] Role is a pre-defined user role identifier in the consortium;

[0067] State is a permission state in the set of permission automaton states S;

[0068] Permission is a Boolean value (true or false), true means authorized, false means denied.

[0069] In a specific embodiment, part of the rules in the query table can be defined as follows:

[0070] (Logistics, INTERNAL, true), (Warehouse, INTERNAL, true), (Regulatory, AUDITABLE, true), (Logistics, AUDITABLE, false), (Consumer, DELEGABLE, false).

[0071] In another embodiment, the access control decision function can also be implemented as a separate logic contract deployed on the chain. The access control gateway calls the logic contract with the requestor role and data real-time state as parameters, and the contract directly returns a Boolean decision result through the internally solidified conditional logic. This way can make the decision logic itself support online upgrade.

[0072] The access control gateway takes the requestor role R U and the data real-time state s curr as input and matches them in the query table. If a rule is found that completely matches (R U , s curr ), the Permission value in the rule is taken as the decision result of this access request. If no matching rule is found, the default output is the decision result of denying access.

[0073] Finally, the access control gateway performs subsequent operations according to the decision result. If the result is true, the gateway continues to perform the operation of obtaining the traceability data record D from the backend storage system (such as IPFS or database) and returning it to the user U. If the result is false, the gateway aborts the data acquisition process and returns a response to the user U that access is denied.

[0074] S300: Cross-domain permission delegation and verification based on permission model. When the real-time permission state of the permission automaton is the pre-set delegable state, the generation and verification process of the permission commitment ticket is performed to handle the cross-domain permission delegation request.

[0075] This phase is initiated by the owner of the provenance data record D. First, the owner interacts with the permission assignment automaton contract PGA D bound to the data record D through a client, reading its current permission state s curr . The system performs a precondition check to determine whether s curr is in the preset delegable state.

[0076] If the precondition is satisfied, the owner constructs a permission plaintext P d on the off-chain client. The permission plaintext is a structured data set containing the following fields:

[0077] ID ext : the unique identity of the authorized off-chain external entity.

[0078] P spec : the specific permission scope description.

[0079] actions: which precisely defines the accessible data fields and allowed operation types.

[0080] T exp : a Unix timestamp defining the expiration time of the permission delegation.

[0081] N: a one-time random number used to ensure the uniqueness of each generated permission plaintext.

[0082] After construction, the client calculates a commitment hash based on the preset cryptographic hash function H and the normalized byte concatenation operator || for the content of each field of the permission plaintext P d . The calculation formula is:

[0083] C hash = H(ID ext || P spec || T exp || N);

[0084] The owner signs a transaction, calls a specific function in the PGA D contract, and passes the calculated C hash as a parameter. When the PGA D contract executes the function, it will again verify that the current state is DELEGABLE, and after verification, it will store the received C hash in a state variable of the contract.

[0085] In an embodiment, in order to support multiple delegations of the same data record to different external entities, the PGA DThe state variable of the contract can be a map whose keys are external entity identities ID ext and values are corresponding commitment hashes C hash When a new commitment hash is submitted, a key-value pair is written or updated in this map.

[0086] After the commitment hash is successfully recorded on-chain, the owner distributes the complete permission plaintext P d to the external entity identified by ID ext through a secure off-chain channel, such as an API interface encrypted using the Transport Layer Security protocol.

[0087] Verification phase of the permission commitment ticket:

[0088] This phase is executed by an entry gateway node of the consortium chain upon receiving an access request from an external entity. The external entity provides the complete permission plaintext P d received by it in the request. The gateway node performs a two-stage verification process:

[0089] First-stage verification: The gateway node first parses the identifier ID D of the provenance data record from the request and locates the corresponding PGA D contract. Then, the gateway node reads the real-time permission state s D of the PGA curr contract. The gateway node determines whether s curr is still DELEGABLE. If s curr has transitioned to another state due to on-chain events, the first-stage verification fails, and the entire verification process is immediately aborted, and a response denying access is returned to the external entity.

[0090] Second-stage verification: This stage is only executed when the first-stage verification passes. The gateway node uses the fields in the permission plaintext P d submitted by the external entity to locally recalculate a verification commitment hash C′ hash using the same hash function H and concatenation logic as in the generation phase. Then, the gateway node reads the original commitment hash C D stored in the PGA hash contract and performs a byte-by-byte comparison between C hash′ and C hash .

[0091] Finally, the gateway node determines that the current access request is effectively authorized only when the first-stage verification passes and the comparison result of the second-stage verification is completely consistent. At this time, the gateway also checks the expiration timestamp T d in the permission plaintext P expIs it later than the current block timestamp? If all checks pass, the gateway node will proceed according to P. spec The permission scope defined in the field retrieves the corresponding data from the backend data storage and returns it to the external entity.

[0092] See attached document Figure 2 Another embodiment of the present invention discloses a dynamic data access control system in an agricultural product traceability consortium blockchain, which may include:

[0093] The permission model establishment module 10 is configured to execute step S100 in the aforementioned method, that is, to create and bind an independent permission automaton for each traceability data record to be managed.

[0094] The authorization decision module 20 is configured to process received access requests based on the real-time permission status of the permission automaton established by the permission model establishment module 10. The authorization decision module 20 may further include:

[0095] The in-chain adjudication unit 21 is configured to perform step S200 in the aforementioned method, namely, to process access requests from within the consortium.

[0096] And the cross-domain delegation unit 22, which is configured to perform step S300 in the aforementioned method, namely, to process the cross-domain permission delegation request and execute the generation and verification process of the permission commitment ticket.

[0097] In one specific embodiment of the present invention, the functions of the permission model establishment module 10, the intra-chain adjudication unit 21, and the cross-domain delegation unit 22 can be implemented by executing one or more computer programs on a computing device. These modules communicate and exchange data through a preset interface to collaboratively complete the entire dynamic management process of data access permissions.

[0098] 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 method for dynamically managing access rights to data in an agricultural product traceability consortium chain, characterized in that, The method comprises the following steps: For each traceability data record to be managed in the alliance chain, an independent permission automaton is created and bound, which is an on-chain smart contract that defines a set of permission states and state transition functions driven by on-chain events, so that the permission state can evolve automatically; Based on the real-time permission state evolved by the permission automaton, different types of access requirements are classified and processed: For access requests within the alliance, the real-time permission state is obtained, and a preset access control decision function is used to make authorization decisions in combination with the user role of the access requester; In addition, for the demand of cross-domain permission delegation, when the real-time permission state is a preset delegable state, authorization is performed by generating and verifying a permission commitment ticket, the generation process includes preparing a permission plaintext off-chain, committing the hash on-chain in the permission automaton, and distributing the permission plaintext through a secure off-chain channel. 2.The method of claim 1, wherein, The permission assignment automaton is formally defined as a four tuple PGA D = (S, E, δ, s init ); wherein S is a set of permission states; E is a set of on-chain events; δ is a state transition function for determining a next permission state according to a current permission state and a triggered on-chain event; s init assigns an initial permission state to the permission automaton. 3.The method of claim 2, wherein, The set of permission states at least includes: Private state accessible only by data creator, internal state accessible to specific roles within the alliance, review state open to regulatory agencies, and delegable state allowing the generation of permission commitment tickets.

4. The method of claim 1, wherein the method further comprises: The commitment hash is generated by a cryptographic hash function operating on the permission plaintext, and its calculation formula is: C hash = H(ID ext || P spec || T exp || N); where C hash is a commitment hash; H is a cryptographic hash function; ID ext is an external entity identity; P spec is a specific permission scope; T exp is an expiration timestamp; N is a nonce; and || is a canonical byte concatenation operator.

5. The method of claim 1, wherein the method further comprises: The steps of verifying the permission commitment ticket include: First stage verification: Obtain the real-time permission state of the permission automaton and determine whether it is still in the delegable state; if not, access is denied; Second stage verification: If yes, recalculate the commitment hash using the permission plaintext submitted by an external entity and compare it with the commitment hash recorded in the permission automaton; Only when both the first stage verification and the second stage verification pass, the cross-domain access is authorized.

6. The method of claim 5, wherein the method further comprises: The first stage verification constitutes a fuse mechanism, that is, when the real-time permission state of the permission automaton changes due to the response to new on-chain events and is no longer in the delegable state, all permission commitment tickets generated based on the previous state are invalidated immediately.

7. The method of claim 1, wherein the method further comprises: The steps of creating and binding a permission automaton for a traceability data record are as follows: Deploy a permission automaton factory contract on the alliance chain; When a new traceability data record is created, the factory contract creates a permission automaton instance and binds the unique identifier of the traceability data record to the contract address of the permission automaton instance through an on-chain mapping relationship. 8.The method of claim 1, wherein, The on-chain events include: Internet of Things device data verified and submitted by an oracle, or on-chain transactions initiated by specific identity participants in the alliance chain. 9.The method of claim 1, wherein, The preset access control decision function is implemented as an on-chain or off-chain query table that records the mapping relationship between user roles and permission states and the corresponding Boolean access permissions.

10. A system for dynamically managing data access permissions in an agricultural product traceability consortium chain, according to any one of claims 1-9. It includes: The permission model establishment module is configured to create and bind an independent permission assignment automaton for each traceability data record to be managed in the alliance chain, the permission assignment automaton being a smart contract on the chain, and the internal definition of the permission assignment automaton including a set of permission states and a state transition function driven by on-chain events, so that the permission state of the permission assignment automaton can evolve automatically. The authorization decision module is configured to classify and process different types of access demands based on the real-time permission state of the evolved permission assignment automaton, and the authorization decision module includes: The in-chain arbitration unit is configured to obtain the real-time permission state for access requests within the alliance, and make an authorization decision by combining a preset access control decision function and a user role of an access requester. The cross-domain delegation unit is configured to generate and verify a permission commitment ticket for authorization when the real-time permission state is a preset delegable state, and the generation process includes preparing a permission plaintext off-chain, committing a hash of the permission plaintext on-chain and recording the permission assignment automaton, and distributing the permission plaintext through a secure off-chain channel.

Images