A dynamic role endorsement method and system for an alliance chain for air travel tax-free

Abstract

Embodiments of the present application disclose a kind of alliance chain dynamic role endorsement method and system for air travel duty-free. The method comprises: analyzing the business stage identifier in transaction proposal;With the identifier as index, read the corresponding dynamic role endorsement rule set and business data mode constraint;Verify whether the current node's own role label for endorsing the transaction proposal has been registered as a valid role on the chain;According to the data mode constraint and the current state of the on-chain business object, check whether the format, content and state transition of the business data are legal;Only after passing the check, execute chain code logic and sign endorsement, through state transition rule table and on-chain historical state comparison, realize that endorsement strategy dynamically switches with business stage, endorsement result contains role type information, it is convenient for the role attribute of verification party to identify the role attribute of endorsement source, improve the compliance and reliability of business process on the alliance chain.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a method and system for dynamic role endorsement in a consortium blockchain for duty-free travel, as well as storage media and electronic devices. Background Technology

[0002] With the rapid development of the travel duty-free business, multi-party collaboration among passengers, duty-free retailers, port and customs regulatory agencies, as well as civil aviation information service providers, airlines, airports, ports, railways, and other travel service providers has become a new basic business model. Consortium blockchain technology, due to its decentralized trust and immutability, is increasingly being applied to travel duty-free business scenarios. In a consortium blockchain, the endorsement mechanism is a crucial link in ensuring the legality of transactions; a transaction must be simulated and signed by a designated endorser node before it can be submitted and ranked on the blockchain.

[0003] The duty-free travel business is characterized by strong regulation, multiple participants, and irreversible processes. When existing consortium blockchain endorsement mechanisms are applied to this multi-stage, multi-party scenario, the following shortcomings exist: The endorsement strategy of existing consortium blockchain platforms is statically written during chaincode deployment, making the strategy statically fixed. Its syntax only supports logical combinations of node numbers. The duty-free travel business involves multiple stages, including authorization and itinerary verification, duty-free sales and pickup, and customs verification upon departure from the island / exit. Each stage has drastically different requirements for the endorsement participants. Existing mechanisms cannot apply differentiated endorsement rules to different stages within the same chaincode, nor can they adapt to the differentiated regulatory role requirements at different stages. Existing mechanisms treat endorsement nodes as equivalent counting units. Endorsements from regulatory nodes and duty-free retail nodes are logically equivalent, without distinguishing roles. There is no distinction of rights and responsibilities between regulatory endorsements and those from duty-free operators, failing to highlight the characteristics of each role. The existing mechanism only verifies the legality of the transaction format, without a mandatory verification mechanism for business status, and does not impose constraints on the business data structure written on the chain. If the participating parties have inconsistent understandings of the field definitions, the on-chain data may become invalid due to the inconsistent structure when it flows across institutions. This can easily lead to violations such as illegal rollback of order status and duplicate verification, and cannot meet the regulatory compliance requirements for duty-free shopping on Hainan Island.

[0004] To address the aforementioned issues, existing research has proposed solutions such as dynamic endorsement scheduling based on node performance, role-based access control, and on-chain governance. However, these solutions largely focus on single dimensions such as load balancing, system permission management, or configuration change processes. Therefore, how to ensure that the endorsement mechanism is fully adaptable to the travel and duty-free business scenario while maintaining the decentralized trust advantages of consortium blockchains has become a pressing technical challenge in this field. Summary of the Invention

[0005] The purpose of this application is to at least address one of the aforementioned technical deficiencies, particularly the technical deficiencies in the prior art such as static and fixed endorsement strategies, missing role semantics, rules that can be unilaterally tampered with, lack of structural constraints on data, and lack of endorsement guarantees for state transitions.

[0006] Firstly, this application provides a method for dynamic role endorsement via consortium blockchain for duty-free travel, including the following steps performed on the endorsement node of the consortium blockchain: Receive a transaction proposal initiated by the client that contains data on duty-free travel services, and parse the business stage identifier from the transaction proposal; Using the business stage identifier as an index, the dynamic role endorsement rule set and business data pattern constraints corresponding to the business stage identifier are read from the on-chain state database. Verify whether the current node endorsing the transaction proposal has already registered its own role label as a valid role on the chain; if so, continue; otherwise, reject the endorsement. Based on the business data pattern constraints, verify whether the format and content of the travel duty-free business data carried in the transaction proposal conform to the constraints; and read the current state of the business object associated with the transaction proposal from the on-chain state database to determine whether the transformation of the target state requested in the transaction proposal relative to the current state is legal. When the verification of the role and data mode both pass, the smart contract business logic corresponding to the transaction proposal is executed to generate a read-write set and endorse the read-write set.

[0007] In one embodiment, the dynamic role endorsement rule set is stored on the blockchain in a versioned data structure, which includes at least: business stage identifier, required role label and minimum endorsement node threshold, total endorsement node threshold, and referenced business data mode version. In one embodiment, the transaction proposal includes a business stage identifier and a travel duty-free business data payload; the travel duty-free business data payload includes at least one of the following: a business object identifier, used to associate a business object already stored on the chain; and a target state field, used to request that the state of the business object be changed to a target value.

[0008] In one embodiment, the data pattern constraint includes a state transition rule table; the state transition rule table is associated with the business stage identifier, and different business stage identifiers correspond to different state transition rule tables; the state transition rule table defines allowed single-step state transitions, and each single-step state transition includes at least the current state and the target state; each single-step state transition may also include preconditions and mutual exclusion constraints.

[0009] In one embodiment, using the business stage identifier as an index, the dynamic role endorsement rule set and business data pattern constraints corresponding to the business stage identifier are read from the on-chain state database, including: using the business stage identifier as a key, reading the dynamic role endorsement rule set that is in effect corresponding to the business stage identifier from the on-chain state database; extracting the referenced business data pattern version identifier from the dynamic role endorsement rule set; and using the business data pattern version identifier as a key, reading the corresponding business data pattern constraints from the on-chain state database.

[0010] In one embodiment, determining whether the transition of the target state requested in the transaction proposal relative to the current state is valid includes: When the business object identifier in the transaction proposal does not exist on the chain, verify whether the target state is a valid initial state defined in the state transition rule table; if so, the verification passes, otherwise the verification fails. When the business object identifier already exists on the chain, the following steps are performed: using the business object identifier as the key, read the current state field value of the business object from the on-chain state database as the current state; extract the target state field value of the request from the transaction proposal as the target state; determine whether the transition from the current state to the target state belongs to the allowed single-step state transition defined in the state transition rule table; if it does not belong, the verification fails; if it does belong, the verification succeeds.

[0011] In one embodiment, the endorsing node returns the endorsement response after signing to the client, so that the client can perform global aggregation and verification of all collected endorsement responses according to the dynamic role endorsement rule set, and submit the transaction after confirming that the constraints are met.

[0012] Secondly, this application provides a consortium blockchain system, including multiple endorsing nodes, each of which is configured with a dynamic role endorsement engine. The engine is embedded in the smart contract execution environment of the endorsing node. The engine includes: a phase-aware scheduler, a strategy loader, a role verifier, a data pattern verifier, and an endorsement signer. Optionally, it also includes an on-chain governance unit and a state transition verification submodule.

[0013] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the steps of any of the above method embodiments.

[0014] Fourthly, this application provides a computer device including one or more processors and a memory, wherein the memory stores computer-readable instructions, which, when executed by the one or more processors, implement the steps of any of the above-described method embodiments.

[0015] As can be seen from the above technical solutions, the embodiments of this application have the following advantages: Based on any of the above embodiments, this application introduces a business stage identifier as the core context, enabling the automatic application of differentiated role rules and pattern constraints to the same smart contract at different business stages. Compared to traditional static endorsement strategies, this eliminates the need to split and deploy multiple sets of chaincode. Simultaneously, introducing node role tags into the endorsement process imbues the endorsement results with business authority semantics, ensuring that the endorsement responsibilities of regulatory nodes, operational nodes, and data source nodes are distinguishable and traceable, meeting the stringent compliance audit requirements of the travel and duty-free scenario. Furthermore, mandatory data pattern verification and state transition legality verification are performed during the endorsement stage, and the verification results are locked through the node's endorsement signature. By comparing the state transition rule table with historical on-chain states, non-compliant transactions such as illegal state jumps, irregular rollbacks, and mutually exclusive state conflicts are prevented, significantly reducing regulatory risks in the travel and duty-free business.

[0016] This invention binds stage awareness, role semantics, data pattern verification, and state transition legality verification to the endorsement stage, enabling the endorsement strategy to switch dynamically with the business stage and the endorsement results to include role type information. This facilitates the verifier in identifying the role attributes of the endorsement source and improves the compliance, reliability, and regulatory traceability of the travel and duty-free business process on the consortium blockchain.

[0017] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0018] The above and other objects, features, and advantages of the present invention will become more apparent from the more detailed description of the embodiments of the invention in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same parts or steps.

[0019] Figure 1 This is a flowchart illustrating an exemplary embodiment of the present invention for a consortium blockchain dynamic role endorsement method for duty-free travel.

[0020] Figure 2 This is a schematic diagram of the structure of a consortium blockchain dynamic role endorsement engine for duty-free travel provided by an exemplary embodiment of the present invention. Detailed Implementation

[0021] Hereinafter, exemplary embodiments according to the present invention will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments of the present invention. It should be understood that the present invention is not limited to the exemplary embodiments described herein.

[0022] It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of the invention.

[0023] Those skilled in the art will understand that the terms "first," "second," etc., in the embodiments of the present invention are only used to distinguish different steps, devices, or modules, and do not represent any specific technical meaning, nor do they indicate a necessary logical order between them.

[0024] It should also be understood that in the embodiments of the present invention, "multiple" can refer to two or more, and "at least one" can refer to one, two or more.

[0025] It should also be understood that any component, data or structure mentioned in the embodiments of the present invention can generally be understood as one or more unless explicitly defined or given contrary instructions in the context.

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0027] The method and system for dynamic role endorsement in a consortium blockchain for duty-free travel provided in this application can be deployed in a consortium blockchain network for duty-free travel businesses. This consortium blockchain network typically includes a regulator node (RegulatorOrg), a sales node (RetailerOrg), and a data source node (DataSOrg). Depending on business needs, it can also be expanded to include a platform regulator node (PlatformOrg), a payment institution node, etc.

[0028] When passengers initiate duty-free shopping trips to / from Hainan Island, including verifying their eligibility for the trip, placing and paying for duty-free orders, and customs verification, a consortium blockchain endorsement mechanism is needed to ensure the legality and compliance of the transactions. Existing technologies suffer from static and fixed endorsement strategies, lack of role awareness, the possibility of unilateral rule tampering, unstructured data constraints, and a lack of state transition verification, making efficient and reliable execution of multi-stage processes difficult. This application effectively solves these problems by introducing business stage identifiers, a role tagging system, an on-chain governance rule set, and data pattern constraints with state transition verification, and by integrating these mechanisms into the endorsement stage.

[0029] During the startup phase of the consortium blockchain network, business role tags are registered for each participating node. In this embodiment, the Hyperledger Fabric platform is used, and a custom registerRole chaincode function is used to write the mapping between node identity and role tags into the on-chain state database. Specifically: 1. RetailerOrg: For example, a duty-free shop, registered as ROLE_OPERATOR, is responsible for executing business operations such as authorization, sales, and pickup of duty-free goods.

[0030] 2. Regulatory nodes (RegulatorOrg) are registered as ROLE_AUTHORITY, including customs, ports and other regulatory nodes, which undertake policy supervision functions and have the authority to endorse compliance in key links such as qualification verification and departure verification.

[0031] 3. Data source nodes (DataSOrg) are registered as ROLE_DATA_SOURCE, including transportation hub nodes such as civil aviation, ferries, and railways. They provide authentic data sources such as passenger itinerary information and provide credible data endorsement during the itinerary verification and customs inspection stages. It should be understood that in this invention, data source nodes (DataSOrg) broadly refer to participants such as civil aviation information service providers, airlines, airports, ports, and railways that provide passenger itinerary data. Their role label is ROLE_DATA_SOURCE, and they are responsible for providing credible endorsement of itinerary information during the itinerary verification and departure / departure customs inspection stages.

[0032] Once a role tag is written to the on-chain state database, it is persistently stored and includes a version number. Subsequent changes are all recorded on the chain for auditing and traceability.

[0033] Firstly, this application provides a consortium blockchain dynamic role endorsement method for duty-free travel. Please refer to [link / reference]. Figure 1 This includes steps S11 to S15.

[0034] S11. Receive a transaction proposal from a client containing travel and duty-free business data, and parse the business phase identifier from the transaction proposal. The client initiates a transaction proposal containing travel and duty-free business data, which carries a business phase identifier (PhaseTag). The business phase identifier is determined by the client based on the current business phase status and filled in according to the list of valid phase identifiers configured on the chain. After receiving the proposal, the endorsing node parses out the business phase identifier. If the identifier is missing or does not belong to the set of valid phase identifiers on the chain, the endorsement is rejected.

[0035] Specifically, in the duty-free travel business, the following business stage identifiers can be defined: AUTH_PHASE (trusted authorization), VERIFY_PHASE (trip verification), SALE_PHASE (sales pickup), and VERIFY_EXIT_PHASE (departure customs verification). These are uniformly configured by the on-chain governance of the consortium blockchain, and illegal identifiers will directly reject the transaction. In the transaction proposal of each stage, the PhaseTag field is set to the corresponding value to inform the endorsing node of the current business stage of the transaction.

[0036] In this invention, the transaction proposal comprises two parts: a business stage identifier and a travel and duty-free business data payload. The business stage identifier, a mandatory field represented by the PhaseTag field, informs the endorsing node of the current business stage of the transaction. If this identifier is missing, the endorsing node directly rejects the endorsement and terminates the process without executing subsequent steps. The travel and duty-free business data payload contains the actual business data processed in the transaction, and its structure includes, but is not limited to: a business object identifier such as order_id, used to associate with business objects already stored on the chain and serving as the key for querying historical states during state transition verification; a target state field, used to request changing the state of the business object to the target value and serving as the judgment object for state transition legality verification; and other fields related to the travel and duty-free business, such as passenger identity certificate number (credential_id), flight number or itinerary number (transport_no), departure point (departure), destination (destination), travel date (travel_date), passenger authorization and itinerary verification result (verify_flag), sales time (order_time), port code (port_code), and verification result (verify_exit_flag), etc. The data payload for duty-free travel services also includes tracking identifiers such as `trace_id` and status fields such as `status`. The tracking identifier remains unchanged throughout a complete business process, from passenger authorization and itinerary verification, order placement and pickup of goods, to departure / departure customs verification, and is used to connect multiple transactions of the same business object at different stages. The status field is used to identify the current stage of the process, such as `AUTH_PASS`, `SALE_COMPLETED`, `EXIT_VERIFIED`, etc. Together, they record the complete status history of a business transaction from passenger authorization and itinerary verification, order placement and pickup of goods, to departure / departure customs verification. The specific combination and format requirements of the above fields are defined by the data schema bound to the corresponding business stage and are verified in the data schema verification step of the endorsement node. For example, the format of the tracking identifier `trace_id` is verified as correct, the status field `status` is verified as an allowed enumeration value, and the legality of status transitions are verified to ensure data consistency across stages and process traceability.

[0037] S12. Using the business phase identifier as an index, read the dynamic role endorsement rule set and business data pattern constraints corresponding to the business phase identifier from the on-chain state database. Specifically, the endorsing node uses the parsed business phase identifier (PhaseTag) as the query key and reads the corresponding dynamic role endorsement rule set from the state database through the chaincode's GetState interface. The read rule set contains a schemaRef field, which references a business data pattern version identifier. The endorsing node uses the value of the schemaRef field as the query key and again reads the corresponding business data pattern constraints from the state database through the GetState interface. The dynamic role endorsement rule set and data pattern constraints are pre-written into the on-chain state database by consortium members through the on-chain governance mechanism and set to the active state. Based on this, the endorsing node uses the parsed business phase identifier as an index to read the dynamic role endorsement rule set and business data pattern constraints corresponding to that identifier and in the active state from the on-chain state database. In the Hyperledger Fabric environment, Go language goroutines can be used to call the GetState interface to implement the query, thereby reducing the total time consumption. If the business stage identifier is not found in the on-chain state database, or if the data pattern version referenced in the rule set does not exist, the endorsing node will refuse to endorse and return an error message indicating that the business stage has not been configured with a valid endorsement strategy or the referenced data pattern version is invalid.

[0038] The dynamic role endorsement rule set is stored on-chain in a versioned data structure, and it includes at least: business stage identifier, required role label and minimum endorsement node threshold, total endorsement node threshold, and referenced business data mode version. The dynamic role endorsement rule set limits the required endorsement roles and quantity thresholds for each business stage, enabling the endorsement strategy to switch dynamically with the business process, which is different from the traditional static chaincode endorsement strategy.

[0039] The following is an example of a JSON-formatted rule set: { "phaseTag": "VERIFY_PHASE", "roleRule": { "ROLE_DATA_SOURCE": 1, "total": 2}, "schemaRef": "verify_schema_v1.0" } In the example above: the phaseTag field has a value of "VERIFY_PHASE", indicating that this rule set applies to the "trip verification" business phase. This field value is matched with the business phase identifier carried in the client transaction proposal. When the match is successful, the rule set is loaded. The roleRule field is a key-value pair object, where the key "ROLE_DATA_SOURCE" indicates that the node role type required to participate in the endorsement is the data source party, and the value 1 indicates that at least one valid endorsement of this role type is required. The key "total" indicates the minimum total number of endorsement signatures required for this phase, and the value 2 indicates that at least two endorsement signatures from different nodes are required. The schemaRef field has a value of "verify_schema_v1.0", indicating the data schema version number referenced by this rule set. Endorsing nodes use this field to locate and load the corresponding data schema constraints.

[0040] S13. Verify whether the role label of the current node endorsing the transaction proposal has been registered as a valid role on the chain; if yes, continue; otherwise, reject the endorsement. The role label is a mapping relationship established for the network identity of a node through permission-controlled chaincode functions during consortium chain initialization or node joining, and is persistently stored in the on-chain state database. Specifically, each endorsing node, in its local chaincode execution environment, uses its own network identity as the query key to query the role registry from the on-chain state database through the chaincode's GetState interface to obtain its own role label. If the query result is empty or the role label has been revoked, the endorsement signature is directly rejected and subsequent steps are terminated. If a valid role label is obtained, the node is deemed qualified to participate in the endorsement, and subsequent steps are allowed to continue.

[0041] Specifically, within the Air Travel Duty-Free Alliance, the following roles can be registered: ROLE_OPERATOR (Duty-free shop operator, generally referring to duty-free operators operating in locations such as cities, airports, and ports, held by the RetailerOrg node), ROLE_AUTHORITY (Duty-free regulator, generally referring to customs, regulatory enforcement agencies, port auxiliary coordination agencies, etc., held by the RegulatoryOrg node), and ROLE_DATA_SOURCE (Transportation hub data provider, generally referring to participants providing passenger travel data such as civil aviation information service providers, airlines, airports, ferries, and railways, held by the DataSOrg node). These roles are exemplary roles for core participants in the air travel duty-free business scenario. In actual deployment, alliance members can also extend and define other role types according to business needs, such as the ROLE_ADMIN system management role. The registration method for extended roles is consistent with the above roles, i.e., writing to the on-chain state database through permission-controlled chaincode functions.

[0042] S14. Based on the business data pattern constraints, verify whether the format and content of the travel duty-free business data carried in the transaction proposal conform to the constraints; and, using the current state of the business object associated with the transaction proposal read from the on-chain state database as the verification benchmark, determine whether the transformation of the target state requested in the transaction proposal relative to the current state is legal. The data pattern verification includes regular checks on field types, required fields, formats, and enumerated values, as well as state transformation legality verification.

[0043] Here, state transition refers to a one-time change in which a business object changes from its current state stored on the blockchain to the target state requested in the transaction proposal. In the travel duty-free business scenario of this invention, the business object is a duty-free order, and its state includes at least the following types: AUTH_PASS: Authorization approved status, indicating that the passenger's identity and purchase eligibility have passed the initial verification, and the order is ready to enter the sales process; SALE_COMPLETED: This status indicates that the duty-free goods have completed the ordering, payment, and final pickup process, and the passenger has successfully purchased the goods and the order has been fulfilled. EXIT_VERIFIED: Departure / Departure verification passed, indicating that the passenger has completed the final customs verification upon departure / departure, and the order has been fully monitored in a closed loop. CANCELLED: This status indicates that the order has been cancelled due to reasons such as passenger request, return, or administrative operation. This status is final.

[0044] The transitions between the states described above must follow the definition of the state transition rule table.

[0045] In a typical embodiment of the present invention, allowed single-step state transitions include: AUTH_PASS → SALE_COMPLETED: After the passenger authorization and itinerary verification are approved, the order enters the sales completion status; SALE_COMPLETED → EXIT_VERIFIED: After the sale and pickup are completed, the order enters the departure / departure customs verification status; * → CANCELLED: Allows transition from any state to the canceled state, where * is a wildcard indicating that any current state can transition to CANCELLED, but the corresponding preconditions must be met.

[0046] The above state types and transition rules are merely illustrative examples. Those skilled in the art will understand that the state types and transition rules under different consortium blockchain business scenarios can be customized and extended by consortium members through on-chain governance mechanisms.

[0047] The legality of state transitions is defined by a state transition rule table, which is associated with the business stage identifier. Different stages can correspond to different rule tables. Each item in the rule table defines a permissible single-step state transition, including the current state and the target state. Each single-step state transition may also include one or more of the following additional constraints: (1) Preconditions, which are on-chain data condition expressions that must be satisfied before the state transition. These expressions are dynamically evaluated in the chaincode execution environment of the endorsing node and support field comparison operations (such as >, <, ==), logical operations (such as AND, OR), and on-chain data query function calls (such as GetState). The preconditions are satisfied when the expression evaluation result is true; (2) Mutual exclusion constraints, which are rules that prohibit two or more specific states from existing at the same time. The verification method is to use the globally unique key associated with the business object identifier as an index to query whether there is a state record in the on-chain state database that satisfies the mutual exclusion condition. If it exists, the verification fails. For example, when the constraint that SALE_COMPLETED and EXIT_VERIFIED cannot coexist for the same passenger is met, the verification logic is as follows: using the credential_id (passenger identity credential number) in the transaction proposal as the key, query the on-chain state database to see if there is an order record associated with that passenger with an order status of SALE_COMPLETED that has not yet been marked as EXIT_VERIFIED; if it exists, and the current proposal requests to change the status of another order for that passenger to EXIT_VERIFIED, then the verification fails and the endorsement is rejected. This constraint ensures that the same passenger will not simultaneously have two contradictory order statuses, "sold but not verified" and "verified," in the same duty-free trip, preventing passengers from using inconsistencies in different order statuses to engage in illegal operations. It should be noted that the verification dimension of the mutual exclusion constraint is defined by specific business rules and is not limited to the order level or passenger level. Alliance members can customize the mutual exclusion conditions and their associated key fields through the on-chain governance mechanism.

[0048] The following is an example of a state transition rule: { "phaseTag": "SALE_PHASE", "initialState": "AUTH_PASS", "rules": [ {"from": "AUTH_PASS", "to": "SALE_COMPLETED", "precondition": "order_time>auth_time"}, {"from": "SALE_COMPLETED", "to": "EXIT_VERIFIED", "precondition": "exit_time>order_time"}, {"from": "*", "to": "CANCELLED", "precondition": "caller.role == 'ADMIN'"} ], "mutexConstraints": ["Under the same passenger identity, orders with a status of SALE_COMPLETED and orders with a status of EXIT_VERIFIED are not allowed to coexist simultaneously."] } In the example above: the phaseTag field is set to "SALE_PHASE", which means that this state transition rule table is associated with the "sales phase". That is, this rule table is only loaded and takes effect in transactions where PhaseTag is "SALE_PHASE".

[0049] The `initialState` field takes the value "AUTH_PASS", defining the valid initial state of the order's business object type. When the business object involved in the transaction proposal does not yet exist on the chain, the verification logic skips the "read current state" comparison step and checks whether the target state matches `initialState`; if they match, creation is allowed; otherwise, the verification fails.

[0050] The `rules` field is an array where each rule entry defines a permissible single-step state transition. Each entry contains three subfields: `from` represents the current state (the state value already stored on the chain), `to` represents the target state (the state value requested to be changed in the transaction proposal), and `precondition` is a precondition expression, which is dynamically evaluated in the chaincode execution environment of the endorsing node. For example, the rule entry `{"from": "AUTH_PASS", "to": "SALE_COMPLETED","precondition": "order_time>auth_time"}` means: when the current order state is `AUTH_PASS`, it is allowed to change to `SALE_COMPLETED`, but the precondition requires the sales time to be later than the authorization time. If the precondition is not met, the transition will be rejected even if the `(from, to)` path is valid. The `*` in `"from": "*"` is a wildcard, indicating that any current state can transition to the target state specified by `to`, but the corresponding precondition must be met. All state transitions in this application are single-step transitions; that is, a single transaction only allows the state to change from one value to another, and multi-step transitions are not permitted. In the `rules` field, `precondition` is the precondition expression. In this expression, `caller` refers to the client that initiated the transaction proposal. Its role label can be extracted from the identity certificate carried in the transaction proposal or from the signed and verified transaction proposal payload. For example, `precondition: "caller.role == 'ROLE_ADMIN'"` means that changing the order status to `CANCELLED` is only allowed if the transaction initiator has the `ROLE_ADMIN` role. In this example, `ROLE_ADMIN` is an optional extended role, representing the consortium blockchain's system administrator or a participant with special management permissions, such as an account responsible for performing management operations like order cancellation. In the core scenario of the travel and duty-free business, common roles include `ROLE_OPERATOR` (duty-free shop operator), `ROLE_AUTHORITY` (port / customs supervisor), and `ROLE_DATA_SOURCE` (transportation hub data provider). Extended roles such as `ROLE_ADMIN` can be customized by consortium members through on-chain governance mechanisms according to actual business needs. The evaluation of the precondition expression is achieved as follows: When the endorsing node loads the data pattern constraints, it calls the embedded expression parser to parse the precondition field and generate an Abstract Syntax Tree (AST). During evaluation, the field values ​​in the transaction proposal payload and the on-chain query results are bound to the variable nodes of the AST, and then the AST is evaluated via a post-order traversal. A timeout protection is set for expression evaluation; if the timeout occurs, the precondition is determined to be unmet.If an expression has a syntax error or the referenced field does not exist, the parser returns an explicit error message and terminates the validation. Those skilled in the art can implement the above expression parser using mature parser generation tools such as ANTLR and JavaCC, or convert the expression into a scripting language of the target platform, such as JavaScript or Lua, for execution in a sandbox environment.

[0051] The `mutexConstraints` field defines mutual exclusion constraints. For example, in the example above, "Under the same passenger identity, it is not allowed to have orders in the SALE_COMPLETED state and orders in the EXIT_VERIFIED state simultaneously" means that for a set of orders associated with the same passenger identity, it is prohibited to have order records in both the SALE_COMPLETED and EXIT_VERIFIED states at the same time. The mutual exclusion constraint is verified by: using the credential_id (passenger identity credential number) in the transaction proposal as an index, querying the on-chain state database to see if there is a state record associated with the passenger that meets the mutual exclusion condition; if so, the verification fails.

[0052] The specific process of state transition verification is as follows: (1) When the business object involved in the transaction proposal does not exist on the chain, i.e., when it is created for the first time, the verification logic skips the comparison step of "reading the current state" and directly verifies whether the target state is a legal initial state of the business object type, defined by the initialState field; if the target state matches the initialState, the verification passes and creation is allowed; otherwise, the verification fails. (2) When the business object involved in the transaction proposal already exists on the chain, the current state field value of the business object is read from the on-chain state database using the business object identifier in the transaction proposal, such as order_id, as the key; the target state field value of the request is extracted from the transaction proposal as the target state; the state transition rule table associated with the current stage is queried to determine whether the transition from the current state to the target state belongs to the allowed state transition defined in the rule table; if it does not belong to the allowed state transition, the verification fails; if it belongs to the allowed state transition, the preconditions attached to the transition are further verified to see if they are met; if they are not met, the verification fails; after the state transition path and preconditions are verified to pass, the target state is further verified to see if it conflicts with the mutual exclusion constraints in the state transition rule table; if there is a mutual exclusion conflict, the verification fails. The state transition path check and the mutual exclusion constraint check are independent of each other. The state transition check is considered successful only if both pass.

[0053] If the state transition verification fails, the endorsement node returns structured error information, which includes at least: the business stage identifier of the failed verification, the data schema version, the business object identifier, the current state value, the requested target state value, and a list of target state values ​​that are allowed to transition from the current state.

[0054] S15. When both the role verification step and the data pattern verification step are passed, execute the smart contract business logic corresponding to the transaction proposal, generate a read-write set, and sign and endorse the read-write set.

[0055] Specifically, after both the role verification and data pattern verification steps pass, the endorsing node calls the chaincode to execute the business logic corresponding to the transaction proposal. In the duty-free travel scenario, the business logic may include updating the order status from AUTH_PASS to SALE_COMPLETED, recording sales information, and updating the passenger's duty-free allowance. After execution, the chaincode generates a read-write set (RWSet). The read-write set includes a read set and a write set: the read set records all keys and their version numbers read from the on-chain state database during execution, and the write set records all keys and their new values ​​to be written to the state database during execution.

[0056] After generating the read-write set, the endorsing node signs the read-write set using its own private key to generate an endorsement signature. This signature is a joint signature of the endorsing node's identity, the read-write set, and the verification result, possessing cryptographic non-repudiation, thereby ensuring that the role verification result and data pattern verification result of this invention are locked through the endorsement signature.

[0057] In one exemplary embodiment, the endorsing node may use the Elliptic Curve Digital Signature Algorithm (ECDSA) to sign the read-write set. The process includes: the endorsing node performing a hash operation on the proposal response data containing the read-write set to generate a digest; subsequently, the endorsing node using its private key to digitally sign the digest information according to the ECDSA algorithm, generating an endorsement signature. Correspondingly, the verifier uses the endorsing node's public key to verify the endorsement signature to confirm that the read-write set originates from the endorsing node and has not been tampered with. It should be understood that the ECDSA algorithm is merely an example; in specific implementations, those skilled in the art can also use any digital signature algorithm with cryptographic non-repudiation, such as the RSA digital signature algorithm, the SM2 digital signature algorithm, or the EdDSA digital signature algorithm, to implement the above signature function.

[0058] The endorsing node packages the generated read-write set, endorsement signature, and its own role tag and identity information into an endorsement response and returns it to the client. The read-write set includes a read set and a write set: the read set records all keys and their version numbers read from the on-chain state database during execution, and the write set records all keys and their new values ​​to be written to the state database during execution.

[0059] After broadcasting a transaction proposal to multiple endorsing nodes, the client collects the endorsement responses returned by each node. If any endorsing node fails role verification or data pattern verification, that node does not generate a read-write set or endorsement signature, and directly returns an error response containing the reason for the failure. Based on this, the client determines that the transaction cannot obtain sufficient valid endorsements and terminates the subsequent process. If all selected endorsing nodes pass the verification and return valid endorsement responses, the client performs global aggregation verification on all received valid endorsement responses based on the dynamic role endorsement rule set read from the blockchain.

[0060] The global aggregation verification specifically includes: the client extracts the role tags and signature information of the endorser nodes from each endorsement response; according to the role requirements defined in the rule set, it counts the number of valid endorsements that meet the requirements of each role type; and verifies whether all threshold conditions in the rule set are met simultaneously—including the minimum number of endorser nodes for each specified role type (e.g., ROLE_DATA_SOURCE ≥ 1) and the total number of endorser nodes (e.g., total ≥ 2). For example, if the rule set requires ROLE_DATA_SOURCE ≥ 1 and the total number of endorsements to be no less than 2, the client needs to confirm that at least one endorsement signature from the ROLE_DATA_SOURCE role is included in the collected endorsement signatures, and the total number of endorsement signatures is no less than 2. Only when all threshold conditions are met will the client submit the transaction proposal along with all collected endorsement signatures to the sorting node for on-chain processing; if any threshold condition is not met, the client will abandon submitting the transaction, will not forward any data to the sorting node, and may return a structured error message to the initiator containing the difference between the expected role type and the actual endorser role type.

[0061] The role verification on the node side and the global aggregation verification on the client side together constitute a complete endorsement policy execution mechanism.

[0062] It should be noted that the minimum and total number of endorsing nodes thresholds, such as ROLE_DATA_SOURCE: 1 and total: 2 in roleRule, are stored in the rule set as configuration parameters of the endorsement strategy. Their verification is not performed by a single endorsing node during chaincode execution, but rather by the client performing a global aggregation verification after collecting all endorsement responses. That is, each endorsing node only performs role type matching (S13) and data pattern verification (S14) and independently generates an endorsement signature. After receiving all endorsement responses, the client counts the number of valid endorsement signatures that meet the role requirements of the rule set, confirming whether both the minimum and total endorsement thresholds are met simultaneously. Only when all threshold conditions are met will the client submit the transaction to the sorting node.

[0063] It should be understood that the role verification of this invention adopts a layered design: the first layer is on the endorsement node side: each endorsement node only verifies in S13 whether it has a registered valid role tag, ensuring that all nodes participating in the endorsement are legally registered nodes; the second layer is on the client side: after collecting all endorsement responses, the client performs a global aggregation verification of the role type and quantity of the endorsement signatures in S15 to confirm that the complete policy defined by the rule set is met. Through this layered design, each endorsement node does not need to be aware of the endorsement status of other nodes, reducing the processing complexity of a single node; the client is responsible for the final verification of the global policy, ensuring that the endorsement result meets the requirements of the rule set.

[0064] The following examples, using specific scenarios of duty-free travel services, illustrate the complete execution process of the above method in actual operation. This scenario involves "passengers shopping at duty-free shops on outlying islands / departure points and completing customs verification for departure / departure," involving three types of participating nodes: the regulator (RegulatorOrg, holding ROLE_AUTHORITY), the retailer (RetailerOrg, holding ROLE_OPERATOR), and the data source (DataSOrg, holding ROLE_DATA_SOURCE). It covers the business cycle from passenger authorization and itinerary verification, order creation and pickup, status changes to final verification.

[0065] The following examples one through six correspond to the specific execution methods of the aforementioned steps S11 through S15 at different business stages.

[0066] Example 1: Passenger Authorization and Itinerary Verification Phase (VERIFY_PHASE).

[0067] Assume the consortium blockchain has completed initialization and registered the following roles: DataSOrg nodes are ROLE_DATA_SOURCE, RetailerOrg nodes are ROLE_OPERATOR, and RegulatorOrg nodes are ROLE_AUTHORITY. The consortium, through on-chain governance voting, has written the rule set for the VERIFY_PHASE phase: ROLE_DATA_SOURCE ≥ 1 and total endorsements ≥ 2, and has bound data mode v1.0. Data mode v1.0 contains a state transition rule table, allowing AUTH_PASS → SALE_COMPLETED.

[0068] The client constructs a trip verification transaction proposal, PhaseTag = "VERIFY_PHASE", with the following business data payload: { "trace_id": "TRACE20260001", "order_id": "ORD1001", "credential_id": "ID123456", "transport_no": "CA1234", "status": "SALE_COMPLETED" } In the JSON payload above: trace_id is the trace identifier, used to link multiple transactions of the same business object at different stages; order_id is the unique identifier of the business object, such as a duty-free order, and the endorsing node uses this field as the key to read the current status of the order from the on-chain state database; credential_id is the passenger identity credential number, used to associate the passenger's identity information and duty-free allowance; transport_no is the flight number or itinerary number, and the itinerary data provided by the data source node is used as the verification basis; the status field is the target status to be changed, in this embodiment, the request is to change the order status to SALE_COMPLETED.

[0069] Assume that order ORD1001 already exists on the chain, and its current state is AUTH_PASS.

[0070] Each endorsement node (DataSOrg, RetailerOrg, RegulatorOrg) executes the following: Phase awareness: Parse VERIFY_PHASE.

[0071] Policy loading: Reads the VERIFY_PHASE rule set and data pattern v1.0.

[0072] Role verification: DataSOrg holds ROLE_DATA_SOURCE (valid), RetailerOrg holds ROLE_OPERATOR (valid), and RegulatorOrg holds ROLE_AUTHORITY (valid), all of which passed.

[0073] Data pattern validation: Check that the formats of fields such as trace_id, order_id, and credential_id are correct; read the current state AUTH_PASS on the chain, request the target state SALE_COMPLETED, query the rule table to confirm that it is allowed, and if the preconditions are met, the validation passes.

[0074] Endorsement execution: Execute the chaincode logic, update the order status to SALE_COMPLETED, generate a read / write set, and sign it.

[0075] After the client collects three endorsement responses, it counts the roles: there is ROLE_DATA_SOURCE from DataSOrg, and the total number of endorsements is 3, which meets the rule set requirements. Therefore, it submits the transaction and endorsement signature to the sorting node and finally puts it on the chain.

[0076] Example 2: The first creation of a new business object.

[0077] For clarity, this invention distinguishes between two types of transactions involving business objects. The first type is the creation transaction, which corresponds to the transaction when the business object identifier (order_id) in the transaction proposal does not yet exist on the chain. In the creation transaction, because the current state does not exist, a state transition relationship cannot be formed. The verification logic skips the comparison step of "reading the current state" and directly verifies whether the requested target state is equal to the value of the initialState field defined in the data schema constraint; if they match, creation is allowed; otherwise, it is rejected. For example, if a client initiates a new order creation transaction with PhaseTag = "SALE_PHASE" and requests a target state of AUTH_PASS, since the order does not yet exist on the chain and AUTH_PASS matches the initialState, the verification passes and the order is successfully created; if the client incorrectly sets the target state to EXIT_VERIFIED, since this state is not a valid initial state, the verification fails and the transaction is rejected.

[0078] The second type is update transactions, which correspond to transactions where the business object identifier already exists on the chain. In update transactions, the verification logic reads the current state value stored on the chain, combines it with the target state value in the transaction proposal, and queries the rules array of the state transition rule table to determine whether the transition path from the current state to the target state is allowed. If there are preconditions, it verifies whether the preconditions are met. For example, if the current state of the same order ORD1001 is AUTH_PASS, and the client initiates a transaction to update the state to SALE_COMPLETED, the verification logic reads the current state AUTH_PASS, queries the state transition rule table to confirm that there is a allowed transition from AUTH_PASS to SALE_COMPLETED, and if the preconditions are met, the verification passes.

[0079] The two types of transactions described above are initiated and endorsed independently. Those skilled in the art should understand that transaction creation is not subject to validation using the `rules` array in the state transition rule table, but only to `initialState` validation; while transaction update must satisfy the complete validation of the state transition rule table. This distinction ensures that business objects undergo complete endorsement validation from creation to each state change.

[0080] Example 3: Illegal state transition, refuse endorsement.

[0081] Suppose that the current state of the same order ORD1001 is SALE_COMPLETED, and the client mistakenly initiates a transaction proposal to change the state to AUTH_PASS. During data schema validation, the state transition validation query table finds that there is no allowed transition from SALE_COMPLETED to AUTH_PASS, therefore the validation fails, and the endorsing node returns a structured error message. After receiving this error, the client can correct the target state in the transaction proposal and re-initiate the transaction.

[0082] When an illegal state transition occurs, the endorsing node refuses to sign. The client cannot obtain enough valid endorsements, and the transaction terminates.

[0083] Example 4: Verification of status transition during the customs inspection stage for leaving the island / departure (VERIFY_EXIT_PHASE).

[0084] After passengers collect their duty-free goods, customs must verify the departing duty-free order and change its status from SALE_COMPLETED to EXIT_VERIFIED. The client constructs a proposal, PhaseTag = "VERIFY_EXIT_PHASE", with the payload containing fields such as trace_id, order_id, credential_id, port_code, result, and checker_id. After the endorsing node performs role verification, during data pattern verification: it reads the current on-chain status SALE_COMPLETED, the target status EXIT_VERIFIED, queries the departure stage status transition rule table (which should contain SALE_COMPLETED → EXIT_VERIFIED), and then verifies the preconditions such as exit_time > order_time; if these are met, the transaction passes. If someone attempts to revert the status to AUTH_PASS or change it back from EXIT_VERIFIED to SALE_COMPLETED, the verification fails, and the transaction is rejected.

[0085] Example 5: On-chain governance and dynamic updates of policy rule sets.

[0086] Alliance members use an on-chain governance mechanism to vote on, enact, and repeal the dynamic role endorsement rule sets for each stage of the duty-free travel business. In this embodiment, the alliance stipulates that the enactment of any rule set requires the approval of more than two-thirds (≥2 / 3) of the members.

[0087] After consensus is reached within the consortium, the rule sets for the following four business phases are written onto the blockchain and set to the ACTIVE state: The AUTH_PHASE (Trusted Authorization) phase requires ROLE_OPERATOR ≥ 1 and total endorsements ≥ 2; the VERIFY_PHASE (Trip Verification) phase requires ROLE_DATA_SOURCE ≥ 1 and total endorsements ≥ 2; the SALE_PHASE (Business Execution / Sales) phase requires ROLE_OPERATOR ≥ 1 and total endorsements ≥ 2; and the VERIFY_EXIT_PHASE (Departure Verification) phase requires ROLE_AUTHORITY ≥ 1. Simultaneously, each phase is bound to a corresponding business data mode version and state transition rule table.

[0088] Suppose the alliance decides to strengthen supervision of the departure / departure verification stage, requiring platform regulators to participate in endorsement in addition to customs. Alliance members invoke the on-chain governance unit to initiate a change proposal, updating the VERIFY_EXIT_PHASE rule set to ROLE_AUTHORITY ≥ 1 AND ROLE_PLATFORM ≥ 1. The on-chain governance unit is used for the pre-configuration and dynamic updating of the rule set, providing a data source for the policy loading of endorsing nodes. Members vote, and once a 2 / 3 majority vote is received, the new rule set is automatically written to the chain and set to ACTIVE state, while the old rule set is marked as DEPRECATED. Complete voting details and effective timestamps are stored on the chain and cannot be tampered with. The data schema version referenced by the new rule set is marked as locked and cannot be deleted or modified while a valid rule set reference exists, but creating new versions and updating references is allowed to achieve the upgrade. Subsequent departure verification transactions will automatically adopt the new rules and must include endorsement signatures for both ROLE_AUTHORITY and ROLE_PLATFORM.

[0089] Example 6: Versioned storage and upgrade of data schemas The rule set in step S12 references the data schema through the schemaRef field. The state transition rule table in step S14 is a core component of the data schema. To fully demonstrate the overall structure of the referenced data schema and how the data schema is versioned and upgraded independently of the rule set, a complete data schema example is given below. The relationship between this example and the rule set in S12 is as follows: when the schemaRef of the rule set points to "verify_schema_v1.0", the endorsement node loads the data schema definition shown below. The business data schema is represented in JSON Schema format and extends the state transition rule table. The data schema and its associated state transition rule table are stored on-chain in a versioned manner and referenced through the schemaRef field in the rule set. The following is an example of the data schema and state transition rule table associated with the SALE_PHASE stage: { "phaseTag": "SALE_PHASE", "schemaVersion": "v1.0", "initialState": "AUTH_PASS", "fields": { "trace_id": {"type": "string", "required": true},

[0090] "credential_id": {"type": "string", "required": true}, "order_time": {"type": "string", "required": true, "format": "yyyy-MM-dd HH:mm:ss"}, "status": {"type": "string", "required": true, "enum": ["AUTH_PASS","SALE_COMPLETED", "EXIT_VERIFIED", "CANCELLED"]} }, "stateTransitionRules": { "objectType": "Order", "rules": [ {"from": "AUTH_PASS", "to": "SALE_COMPLETED", "precondition": "order_time>auth_time"}, {"from": "SALE_COMPLETED", "to": "EXIT_VERIFIED", "precondition": "exit_time>order_time"}, {"from": "*", "to": "CANCELLED", "precondition": "caller.role == 'ROLE_ADMIN'"} ], "mutexConstraints": ["Under the same passenger identity, orders with a status of SALE_COMPLETED and orders with a status of EXIT_VERIFIED are not allowed to coexist simultaneously."] } } In the JSON format example above: The phaseTag field has a value of "SALE_PHASE", which means that this data pattern is associated with the "sales phase". In other words, this data pattern is only loaded and effective in transactions where PhaseTag is "SALE_PHASE".

[0091] The schemaVersion field takes the value "v1.0", representing the version number of this data schema. Data schemas are stored on the blockchain in a versioned manner, and each modification generates a new version, which is referenced through the schemaRef field in the rule set.

[0092] The `initialState` field, with a value of `AUTH_PASS`, defines the valid initial state of this business object type and should remain consistent across all data schema versions of the same business object type. It should be understood that the `initialState` field defines the valid initial state of this business object type and should remain consistent across all data schema versions of the same business object type. When consortium members create new versions of data schemas through on-chain governance mechanisms, they must ensure that `initialState` is consistent with the business object type. If inconsistencies in `initialState` occur in data schemas referenced at different stages due to governance errors, the `initialState` defined in the data schema loaded when the business object was first created shall prevail.

[0093] When the business object identifier such as order_id carried in the transaction proposal does not yet exist on the chain, the verification logic directly compares whether the target state of the request is consistent with the initialState; if they are consistent, creation is allowed, otherwise it is rejected.

[0094] The `fields` field defines the field-level format constraints for business data in the transaction proposal: `trace_id` is a string type, required, and serves as a global tracking identifier throughout the entire business process; `order_id` is a string type, required, and must match a regular expression. The field should begin with "ORD" followed by 4 digits; credential_id is a string and is required; order_time is a string and is required, and must conform to the format "yyyy-MM-dd HH:mm:ss"; status is a string and is required, and its value must be a member of the enumeration list ["AUTH_PASS", "SALE_COMPLETED", "EXIT_VERIFIED", "CANCELLED"].

[0095] The `stateTransitionRules` field defines the state transition rule table: `objectType` is "Order" indicating that this rule table applies to business objects of the order type; each entry in the `rules` array defines a allowed single-step state transition—`from` represents the current state (i.e., the value already stored on the chain), `to` represents the target state (i.e., the proposal request value), and `precondition` is the precondition expression, which is dynamically evaluated in the chaincode execution environment. For example, the rule `{"from": "AUTH_PASS", "to": "SALE_COMPLETED", "precondition": "order_time>auth_time"}` means: when the current order state is `AUTH_PASS`, it is allowed to change to `SALE_COMPLETED`, but the sales time must be later than the authorization time; the `*` in `"from":"*"` is a wildcard, indicating that any current state that meets the precondition can transition to the target state specified by `to`.

[0096] The `mutexConstraints` field defines mutual exclusion constraints. For example, under the same passenger identity, it is not allowed for orders with a status of `SALE_COMPLETED` and orders with a status of `EXIT_VERIFIED` to exist simultaneously. This means that for a set of orders associated with the same passenger identity, it is prohibited for order records to exist in both the `SALE_COMPLETED` and `EXIT_VERIFIED` states at the same time. The verification method for the mutual exclusion constraint is as follows: using the `credential_id` (passenger identity credential number) in the transaction proposal as an index, query the on-chain state database to see if there is a state record associated with the passenger that meets the mutual exclusion condition. If it exists, the verification fails. It should be noted that the verification dimension of the mutual exclusion constraint is defined by the specific business scenario and business rules. Those skilled in the art can flexibly adjust the verification dimension of the mutual exclusion constraint according to actual business needs by configuring the association key field in the mutual exclusion condition, such as replacing the index field from `credential_id` with the product inventory identifier or itinerary number. All of the above extended examples are within the protection scope of the technical solutions disclosed in this invention.

[0097] Data schema versions referenced by rule sets that are currently in effect are marked as locked and cannot be deleted or modified during the rule set's validity period. When business rules change, such as adding allowed transition paths or adjusting preconditions, consortium members can create new data schema versions through on-chain governance voting and update the `stateTransitionRules` field in the new version. After the new data schema version takes effect, subsequent transactions automatically adopt the new data schema and state transition rules by updating the `schemaRef` reference in the rule set. Data schema versions referenced by old rule sets are marked as "deprecated" after being replaced, but on-chain historical data is unaffected and can still be queried and audited through historical versions.

[0098] Secondly, please refer to Figure 2 This application provides a consortium blockchain dynamic role endorsement engine for duty-free travel. The engine is embedded in the smart contract execution environment of the endorsing node. The engine includes: a stage-aware scheduler 201, a strategy loader 202, a role verifier 203, a data pattern verifier 204, and an endorsement signer 205. Optionally, it also includes an on-chain governance unit and a state transition verification submodule. The functions of each module correspond one-to-one with the steps in the above method embodiments, and will not be repeated here.

[0099] Specifically, the phase-aware scheduler 201 receives and parses transaction proposals initiated by clients that contain travel duty-free business data, and obtains the business phase identifier within them. The strategy loader 202, coupled with the phase-aware scheduler, reads the corresponding dynamic role endorsement rule set and business data pattern constraints from the on-chain state database, using the business phase identifier as an index. The role validator 203 verifies whether the current node endorsing the transaction proposal has its own role tag registered as a valid role on the chain; if so, it continues; otherwise, it rejects the endorsement. The data pattern validator 204 verifies whether the format and content of the travel duty-free business data carried in the transaction proposal conforms to the constraints, based on the business data pattern constraints; and, using the current state of the business object associated with the transaction proposal read from the on-chain state database as a verification benchmark, determines whether the transformation of the target state requested in the transaction proposal relative to the current state is legal. The endorsement signer 205 executes the smart contract business logic corresponding to the transaction proposal only when both the role validator and the data pattern validator pass verification, generates a read-write set, and signs and endorses the read-write set.

[0100] Furthermore, the on-chain governance unit is used to receive change proposals regarding the dynamic role endorsement rule set submitted by alliance members, manage the voting process of alliance members, and automatically update the dynamic role endorsement rule set that is in effect on-chain when the number of affirmative votes reaches a preset threshold. The on-chain governance unit is also used to mark the data pattern version referenced by the old rule set as locked.

[0101] Furthermore, the state transition verification submodule is used to: read the current state of the business object from the on-chain state database using the business object identifier in the transaction proposal as the key, query the state transition rule table in the data pattern constraint, and determine whether the transition from the current state to the target state is legal; for the business object created for the first time, it directly verifies whether the target state matches the predefined initial state.

[0102] Thirdly, the application provides a consortium blockchain system, including multiple endorsement nodes, each of which is configured with the aforementioned dynamic role endorsement engine.

[0103] It should be noted that each module in the above system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the endorsement node in hardware form or independently of it, or stored in the memory of the endorsement node in software form, so that the processor can call and execute the operations corresponding to each module. The module division in this embodiment is illustrative and only represents one logical functional division; in actual implementation, there may be other division methods.

[0104] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the steps of any of the above method embodiments.

[0105] Fifthly, this application provides a computer device including one or more processors and a memory, wherein the memory stores computer-readable instructions, which, when executed by the one or more processors, implement the steps of any of the above-described method embodiments.

[0106] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0107] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they largely correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0108] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0109] The methods and apparatus of this disclosure may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the methods is for illustrative purposes only, and the steps of the methods of this disclosure are not limited to the order specifically described above unless otherwise specifically stated. Furthermore, in some embodiments, this disclosure may also be implemented as a program recorded on a recording medium, the program including machine-readable instructions for implementing the methods according to this disclosure. Thus, this disclosure also covers recording media storing programs for performing the methods according to this disclosure.

[0110] It should also be noted that in the apparatus, devices, and methods of this disclosure, the components or steps are decomposable and / or recombinable. Such decomposition and / or recombination should be considered equivalent to the present disclosure. The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0111] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A consortium blockchain dynamic role endorsement method for duty-free travel, characterized in that, This includes the following steps performed on the endorsing nodes of the consortium blockchain: The system receives transaction proposals from clients that contain data related to duty-free travel services. It verifies whether the business stage identifier in the transaction proposal exists and belongs to the set of valid stage identifiers pre-configured on-chain. If it is missing or invalid, the endorsement is rejected directly. If it is valid, the business stage identifier is parsed out. Using the business stage identifier as an index, the dynamic role endorsement rule set and business data pattern constraints corresponding to the business stage identifier are read from the on-chain state database. Verify whether the current node endorsing the transaction proposal has already registered its own role label as a valid role on the chain; if so, continue; otherwise, reject the endorsement. Based on the business data pattern constraints, verify whether the format and content of the travel duty-free business data carried in the transaction proposal conform to the constraints; and read the current state of the business object associated with the transaction proposal from the on-chain state database to determine whether the transformation of the target state requested in the transaction proposal relative to the current state is legal. When the verification of the role and data mode both pass, the smart contract business logic corresponding to the transaction proposal is executed to generate a read-write set and endorse the read-write set.

2. The method according to claim 1, characterized in that, The dynamic role endorsement rule set includes at least: business stage identifier, required role label and minimum endorsement node threshold, total endorsement node threshold, and referenced business data mode version.

3. The method according to claim 1, characterized in that, The transaction proposal includes a business stage identifier and a travel duty-free business data payload; the travel duty-free business data payload includes at least one of the following information: a business object identifier, used to associate with a business object already stored on the chain; and a target status field, used to request that the status of the business object be changed to a target value.

4. The method according to claim 1, characterized in that, The data pattern constraints include a state transition rule table; the state transition rule table is associated with the business stage identifier, and different business stage identifiers correspond to different state transition rule tables; the state transition rule table defines allowed single-step state transitions, and each single-step state transition includes at least the current state and the target state; each single-step state transition may also include preconditions and mutual exclusion constraints.

5. The method according to claim 1, characterized in that, Using the business stage identifier as an index, the dynamic role endorsement rule set and business data pattern constraints corresponding to the business stage identifier are read from the on-chain state database, including: using the business stage identifier as a key, reading the dynamic role endorsement rule set that is in effect corresponding to the business stage identifier from the on-chain state database; extracting the referenced business data pattern version identifier from the dynamic role endorsement rule set; and using the business data pattern version identifier as a key, reading the corresponding business data pattern constraints from the on-chain state database.

6. The method according to claim 1, characterized in that, The determination of whether the transition from the target state requested in the transaction proposal to the current state is valid includes: When the business object identifier in the transaction proposal does not exist on the chain, verify whether the target state is a valid initial state defined in the state transition rule table; if so, the verification passes, otherwise the verification fails. When the business object identifier already exists on the chain, the following steps are performed: using the business object identifier as the key, read the current state field value of the business object from the on-chain state database as the current state; extract the target state field value of the request from the transaction proposal as the target state; determine whether the transition from the current state to the target state belongs to the allowed single-step state transition defined in the state transition rule table; if it does not belong, the verification fails; if it does belong, the verification succeeds.

7. The method according to claim 1, characterized in that, The endorsing node returns the endorsement response after signing and endorsing to the client, so that the client can perform global aggregation and verification of all collected endorsement responses according to the dynamic role endorsement rule set, and submit the transaction after confirming that the constraints are met.

8. A consortium blockchain system for duty-free travel, characterized in that, It includes multiple endorsing nodes, each of which is configured with a dynamic role endorsement engine. The engine is embedded in the smart contract execution environment of the endorsing node, and the engine includes: The phase-aware scheduler is used to receive and parse transaction proposals initiated by clients that contain data on duty-free travel services, and to obtain the business phase identifiers within them; The strategy loader, coupled with the stage-aware scheduler, is used to read the corresponding dynamic role endorsement rule set and business data pattern constraints from the on-chain state database using the business stage identifier as an index. A role validator is used to verify whether the current node endorsing the transaction proposal has already registered its own role label as a valid role on the chain; if so, the process continues, otherwise the endorsement is rejected. A data pattern validator is used to verify whether the format and content of the travel duty-free business data carried in the transaction proposal conform to the constraints according to the business data pattern constraints; and to read the current state of the business object associated with the transaction proposal from the on-chain state database and determine whether the transformation of the target state requested in the transaction proposal relative to the current state is legal. The endorsement signer is used to execute the smart contract business logic corresponding to the transaction proposal only when both the role validator and the data pattern validator pass the verification, generate a read-write set, and sign and endorse the read-write set.

9. The system according to claim 8, characterized in that, It also includes an on-chain governance module, which is used to receive rule change proposals from alliance members, execute voting, update the on-chain effective rule set when the number of votes in favor reaches a preset threshold, and lock the version of the referenced data pattern.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the method according to any one of claims 1 to 7.

11. A computer device comprising one or more processors and a memory, characterized in that, The memory stores computer-readable instructions that, when executed by the one or more processors, implement the steps of the method according to any one of claims 1 to 7.

Images