Electronic license stream storage method fused with block chain smart contract

Abstract

The invention relates to the technical field of block chains and information security, and particularly discloses an electronic license stream storage method fused with a block chain smart contract, which comprises the following steps: firstly, converting a natural language service strategy into a multi-dimensional strategy matrix executable on a chain, and introducing a scene attribute certificate endorsed by an authority; and the strong binding between the identity and the environment context is realized. In the circulation process, the intelligent contract serves as a strategy decision point, adaptive calculation is carried out on a multi-dimensional attribute vector of a requester through a strategy tensor projection and continuous environment factor correction algorithm, and a permission field mask containing refined permission is generated in real time. Finally, based on the mask, a temporary authorization token with timeliness is generated, and through an audit log closed loop which cannot be tampered on a chain, the traceability of the whole process of minimization disclosure and circulation of the electronic license data in a complex service scene is ensured.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchain and information security, and more specifically, to an electronic license circulation and storage method fusing a blockchain smart contract. BACKGROUND

[0002] With the deepening of one-network handling of digital government affairs and construction of smart cities, electronic licenses have gradually replaced traditional physical licenses and become core trust credentials in cross-department government services, supply chain finance and social applications. In order to solve the problem of anti-counterfeiting and anti-tampering of electronic licenses in the circulation process, using the decentralized, tamper-proof and traceable characteristics of blockchain technology for storage and verification has become the mainstream direction of current technology development. Such technology aims to build a multi-party consensus trusted data exchange network to ensure the secure transmission and audit of license data between the issuing party, the license holder and the verification party.

[0003] However, the existing electronic license circulation technology based on blockchain smart contracts has significant limitations in the dynamic nature of circulation authorization and the precision of policy execution. The current access control logic of smart contracts is mostly based on static identity white lists (such as the RBAC model), which mainly relies on the wallet address of the requester to determine data access permissions. This mechanism essentially separates the on-chain digital identity from the off-chain actual business scenario, and cannot automatically adjust the disclosure strategy according to the specific context at the time of circulation (such as window handling in the service hall and sudden verification on the road). This results in either overly broad permissions leading to privacy leaks or overly strict permissions affecting business efficiency. Further, in the face of complex business rules, existing technologies often rely on simple Boolean logic to combine multiple strategies, lack the ability to resolve conflicts (such as the coexistence of high-privilege roles and restrictive states), and cannot effectively handle dynamic constraints such as geographic location distance and other continuous environmental factors. This discrete and rigid authorization mechanism cannot achieve real-time physical environment-aware risk quantification and field-level adaptive control, and cannot meet the stringent requirements of minimal disclosure and precise authorization of electronic licenses in high-security scenarios.

[0004] Therefore, an optimized electronic license circulation and storage solution is desired. SUMMARY

[0005] To solve the above technical problems, the present application is proposed. The embodiments of the present application provide an electronic license circulation and storage method fusing a blockchain smart contract, which includes: obtaining an original natural language business policy and a full-quantity field list of the license; performing on-chain initialization and deployment of a multi-dimensional strategy matrix on the original natural language business policy and the full-quantity field list of the license to obtain a strategy index of the on-chain strategy matrix; Generate context attribute credentials based on the requester's digital identity, environmental data, and authoritative private key; The dynamic access request vector is constructed and uploaded to the chain for the context attribute certificate, the policy index of the on-chain policy matrix, and the target certificate identifier to obtain the dynamic authorization application transaction to be processed; Based on the strategy index of the on-chain strategy matrix, the dynamic authorization application transaction to be processed is adaptively calculated by the on-chain ABAC strategy engine to obtain the permission field mask; Generate a temporary authorization token based on the permission field mask, requester ID, and target certificate ID; Based on an off-chain encrypted certificate database, a token-based controlled data acquisition and auditing loop is performed on temporary authorization tokens to obtain de-identified certificate data.

[0006] Compared with existing technologies, this application proposes a real-time calculation method for massive indicators based on distributed dynamic dependency graphs and state-aware incremental methods. It transforms complex business rules into multi-dimensional policy matrices or tensors stored on-chain. Upon initiation of a transaction, it generates attribute credentials by combining the requester's identity with a real-time environmental context endorsed by an authoritative institution. Smart contracts quantify and resolve conflicts among multiple policies using tensor projection and weighted aggregation algorithms, and introduce a dynamic penalty function based on continuous environmental factors, mapping physical constraints such as geographical location to attenuation coefficients of authorization scores. Based on this, it automatically calculates and generates field-level permission masks and temporary authorization tokens with lifecycles, guiding off-chain gateways to perform precise data anonymization. This solution achieves a leap from static identity verification to dynamic scenario awareness, effectively solving the problems of balancing policy conflicts in complex transaction scenarios and the lack of fine-grained control over continuous physical environmental factors, ensuring the security, compliance, and traceability of certificate data throughout its entire lifecycle. Attached Figure Description

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

[0008] Figure 1 The flowchart below shows a method for electronic certificate transfer and storage that integrates blockchain smart contracts according to an embodiment of this application. Figure 2 This is a schematic diagram of data flow in the electronic certificate transfer and storage method integrating blockchain smart contracts according to the embodiments of this application; Figure 3A flowchart of generating a context attribute credential based on a requester digital identity, environmental data, and an authoritative private key for the electronic license circulation and storage method of the fusion blockchain smart contract according to the embodiment of the present application; Figure 4 A flowchart of constructing a dynamic access request vector for a context attribute credential, a policy index of an on-chain strategy matrix, and a target license identifier and on-chaining to obtain a dynamic authorization application transaction to be processed for the electronic license circulation and storage method of the fusion blockchain smart contract according to the embodiment of the present application; Figure 5 A flowchart of performing adaptive calculation of an on-chain ABAC policy engine based on a policy index of an on-chain strategy matrix for the dynamic authorization application transaction to be processed to obtain a permission field mask for the electronic license circulation and storage method of the fusion blockchain smart contract according to the embodiment of the present application; Figure 6 A flowchart of performing adaptive mask calculation on the verified attribute feature vector and the target strategy vector to obtain a permission field mask for the electronic license circulation and storage method of the fusion blockchain smart contract according to the embodiment of the present application; DETAILED DESCRIPTION

[0009] Hereinafter, example embodiments according to the present application will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only a part of embodiments of the present application, and are not all embodiments of the present application. It should be understood that the present application is not limited to the example embodiments described herein.

[0010] As shown in the present application and claims, unless the context clearly indicates otherwise, the words “one”, “an”, “a”, and / or “the” do not mean to specify a single number, but can include a plurality or a whole number. Generally, the terms “comprise” and “include” only indicate the inclusion of the steps and elements explicitly identified, and these steps and elements do not constitute an exclusive list, and the method or device can also include other steps or elements.

[0011] Although the present application makes various references to certain modules in the system according to the embodiments of the present application, however, any number of different modules can be used and run on the user terminal and / or server. The modules are only illustrative, and different aspects of the system and method can use different modules.

[0012] Flowcharts are used in the present application to illustrate the operations performed by the system according to the embodiments of the present application. It should be understood that the preceding or following operations are not necessarily performed in sequence. On the contrary, various steps can be processed in reverse order or simultaneously as needed. Meanwhile, other operations can be added to these processes, or one or more steps of operations can be removed from these processes.

[0013] The existing electronic certificate circulation technology based on the blockchain relies on a static identity whitelist for access control and cannot dynamically adjust the authorization strategy according to the real-time context of the circulation scene. Moreover, simple Boolean logic cannot effectively resolve complex policy conflicts or handle the constraints of continuous environmental factors, resulting in a difficult balance between privacy protection and business efficiency. Therefore, in the technical solution of the present application, an electronic certificate circulation and storage method is proposed, which fuses a blockchain smart contract. The method realizes fine-grained dynamic authorization of electronic certificate data by constructing an on-chain policy decision-making and off-chain trusted perception dual-dimensional collaborative mechanism. Specifically, the present solution first converts complex business rules into a multi-dimensional policy matrix or tensor deployed on the blockchain, and introduces context attribute credentials signed by an authoritative agency to credibly bind the requester's identity and real-time environmental data. The smart contract, as a policy engine, uses a weighted aggregation algorithm to handle conflicts between different priority policies and combines a dynamic penalty model based on continuous environmental factors to real-time correct the authorization score, thereby accurately calculating the field-level permission mask that meets the current scene. Subsequently, the system generates a temporary authorization token containing time limit and transaction fingerprint based on the mask, and cooperates with the off-chain gateway for controlled data retrieval and dynamic desensitization, and hashes the access log back to the chain, thereby forming an irrefutable closed-loop audit record while ensuring the principle of minimum disclosure.

[0014] Figure 1 A flowchart of the electronic certificate circulation and storage method fusing a blockchain smart contract according to an embodiment of the present application. Figure 2 A data flow diagram of the electronic certificate circulation and storage method fusing a blockchain smart contract according to an embodiment of the present application. As shown in Figure 1 and Figure 2 The electronic certificate circulation and storage method fusing a blockchain smart contract according to an embodiment of the present application includes: S100, obtaining an original natural language business policy and a full-quantity field list of a certificate; S200, performing on-chain initialization and deployment of a multi-dimensional policy matrix on the original natural language business policy and the full-quantity field list of the certificate to obtain a policy index of the on-chain policy matrix; S300, generating a context attribute credential based on a requester digital identity, environmental data, and an authoritative private key; S400, constructing and uploading a dynamic access request vector based on the context attribute credential, the policy index of the on-chain policy matrix, and a target certificate identifier to obtain a to-be-processed dynamic authorization application transaction; S500, performing adaptive calculation of an on-chain ABAC policy engine on the to-be-processed dynamic authorization application transaction based on the policy index of the on-chain policy matrix to obtain a permission field mask; S600, generating a temporary authorization token based on the permission field mask, a requester ID, and a target certificate ID; and S700, performing controlled data acquisition and audit closed loop based on the token based on an off-chain encrypted certificate database to obtain desensitized certificate data.

[0015] Specifically, in step S100, the original natural language business policy and the full list of fields of the electronic certificate are obtained. It should be noted that since the administrative regulations and privacy protection regulations in the real world are mostly in the form of unstructured natural language, and the data field structures contained in different types of electronic certificates differ greatly, if there is a lack of standardized initialization input, the blockchain smart contract will be difficult to directly understand the complex business logic or locate the specific data resources, resulting in a disconnection between the access control policy and the actual compliance requirements. Based on this, the technical scheme of the present application first performs the operation of obtaining the original natural language business policy and the full list of fields of the electronic certificate, so as to establish the logical reference and data boundary of subsequent policy digital mapping, and to convert the abstract administrative management intention into digital input that can be processed by a computer program. Through the above processing, the semantic gap between business compliance requirements and underlying technology implementation can be effectively eliminated, ensuring the source accuracy of the certificate circulation rules, and laying a solid data foundation for building a high-precision on-chain policy matrix.

[0016] More specifically, in one specific example of the present application, through a pre-set administrator interactive interface or a standardized API interface, the original natural language business policy input by the business manager is received. The business policy describes in detail the data access compliance requirements under a specific organizational structure in the form of text, for example, it is stipulated that traffic police are only allowed to view the desensitized driving license information in the road enforcement scene, and are allowed to view the full amount of plaintext information in the internal environment of the police workstation. At the same time, by reading the metadata definition file of the electronic certificate database or calling the data dictionary service, the full list of fields of the electronic certificate is parsed and loaded. The list enumerates all structured data items contained in the electronic certificate file, covering specific field names and attribute definitions such as the name of the certificate holder, the ID number, the residence address, and the type of vehicle. The received policy text and the field list are formatted and cleaned to remove redundant characters and verify the integrity of the data, and then they are loaded into the memory as basic input data for subsequent processing.

[0017] Specifically, in step S200, the original natural language business policy and the full-quantity field list of license are initialized and deployed on the chain to obtain the policy index of the on-chain policy matrix. It should be pointed out that the business policy described in natural language has the characteristics of unstructured and semantic ambiguity, which cannot be directly executed by the deterministic logic of the blockchain smart contract, and the full-quantity expanded permission matrix often occupies a huge on-chain storage space, resulting in low execution efficiency and high transaction cost. Based on this, the technical scheme of the present application further initializes and deploys the original natural language business policy and the full-quantity field list of license on the chain to obtain the policy index of the on-chain policy matrix, so as to convert the ambiguous administrative rules into a compact data structure that can be read and calculated by the smart contract. Through the above processing, the heterogeneous problem between the legal text and the code logic can be effectively solved, and the on-chain storage overhead is reduced, so that the license transfer policy can be accurately executed and efficiently searched in the decentralized network.

[0018] More specifically, in one specific example of the present application, the original natural language business policy and the full-quantity field list of license are initialized and deployed on the chain to obtain the policy index of the on-chain policy matrix, including: performing business rule semantic analysis and structured mapping on the original natural language business policy and the full-quantity field list of license to obtain an attribute-permission mapping table; performing sparse matrix transformation and space compression on the attribute-permission mapping table to obtain a sparse policy matrix; performing smart contract state storage and index generation on the sparse policy matrix to obtain the policy index of the on-chain policy matrix.

[0019] That is, more specifically, first, the original natural language business policy and the full field list of license are subjected to business rule semantic analysis and structured mapping to obtain the attribute-right mapping table. The input business policy text is subjected to entity extraction and relationship modeling using natural language processing algorithm, the subject attribute, environment attribute and resource object are identified, and these attributes are combined with each field in the full field list of license for logical matching, thereby constructing the attribute-right mapping table defining the visibility of each field in different scenarios. Subsequently, the attribute-right mapping table is subjected to sparse matrix conversion and space compression to obtain the sparse policy matrix. The above mapping table is converted into a two-dimensional matrix in mathematical sense, wherein the row represents the scenario attribute combination, the column represents the license field index, and the matrix element value represents the authorization state. In view of the fact that the accessible fields in a specific scenario in actual business are far less than the full fields, the matrix exhibits sparse characteristics, and the compressed row storage format is adopted for its serialization processing, only the data and index of non-zero elements are retained, thereby generating the sparse policy matrix with high compression ratio. Finally, the sparse policy matrix is subjected to smart contract state storage and index generation to obtain the policy index of the on-chain policy matrix. The administrator account calls the policy management contract through the blockchain transaction instruction, writes the sparse policy matrix as a parameter into the persistent state tree of the blockchain. After the smart contract completes the data solidification, the unique fingerprint of the matrix data is calculated as the policy index using the hash algorithm, and is broadcasted outward through the event log, so as to be accurately positioned and called in the subsequent flow verification link.

[0020] In particular, in order to express both the allow and deny control relationships, in one implementation, the multi-dimensional policy structure can adopt the form of a double matrix of allow matrix plus deny matrix; in another implementation, the above double matrix can also be equivalently represented as a three-dimensional policy tensor with the third dimension being the action type (Allow / Deny). The following description is made in the form of tensor representation, but this is not a limitation.

[0021] Specifically, in step S300, a context attribute credential is generated based on the requester digital identity, the environment data and the authoritative private key. It should be noted that, in view of the fact that the traditional blockchain identity verification mechanism usually only checks whether the private key signature of the requester is valid, and cannot perceive the dynamic context information such as the physical location, device environment and task state when the requester initiates the request, this kind of identity-environment split verification mode is extremely easy to cause the user with a legal identity to illegally obtain sensitive data in a non-office place or non-duty time. Based on this, the technical scheme of the present application further generates a context attribute credential based on the requester digital identity, the environment data and the authoritative private key, so as to bind the static digital identity of the requester and the real-time environment data such as the current GPS coordinate and terminal device fingerprint in a cryptographic manner, and endorse the authenticity and timeliness of the combined data through the digital signature of the authoritative agency such as the dispatch center. Through the above processing, a scene-based access evidence with anti-repudiation and authoritative timestamp can be effectively constructed, so as to ensure that the authorized judgment of the electronic certificate flow is no longer dependent on who you are, but is upgraded to the stereoscopic verification of where you are and what task you are doing, thereby completely eliminating the risk of data abuse of the legal identity in the illegal scene.

[0022] Figure 3 A flowchart of generating a context attribute credential based on a requester digital identity, environment data and an authoritative private key for the electronic certificate flow method of the fusion blockchain smart contract according to the electronic certificate flow method of the fusion blockchain smart contract according to the embodiment of the present application. As shown in Figure 3 S300, step S300 further includes: S310, encapsulating the requester digital identity and the environment data to obtain a context verification request package; S320, performing authoritative agency state checking and time anchoring on the context verification request package to obtain a to-be-verified data block and a current timestamp; S330, based on the authoritative private key and the current timestamp, performing authoritative private key signing and credential synthesis on the to-be-verified data block to obtain a context attribute credential.

[0023] In step S310, the requester digital identity and environment data are encapsulated to obtain a context verification request package. It should be noted that since the physical environment data collected by the front end and the user digital identity are multi-source heterogeneous and loosely coupled information in the original collection stage, if they are not integrated and directly transmitted to the authoritative institution through the network, they are extremely vulnerable to man-in-the-middle attacks in the communication link, which can enable attackers to maliciously combine legitimate identity information with fake geographic locations or device fingerprints, thereby destroying the authenticity of the evidence. Based on this, the technical solution of the present application further encapsulates the requester digital identity and environment data to obtain a context verification request package, so as to complete the logical strong binding of the subject identity and the space-time environment at the data source side as soon as possible, and convert the discrete data stream into a standardized transmission object. Through the above processing, the atomicity and integrity of the request data can be effectively guaranteed, the risk of data tampering in the transmission process can be eliminated, and the analysis complexity of the subsequent verification node can be greatly reduced.

[0024] More specifically, in one specific example of the present application, multi-dimensional perception data is first read in parallel through the underlying hardware interface of the trusted terminal device. This operation includes calling the positioning module to obtain the current high-precision latitude and longitude coordinates, reading the device physical fingerprint in the secure chip and the task instruction hash value in the current application memory, and aggregating these data into an original environment data set. At the same time, the public key address or unique identity identifier of the requester is extracted from the key management module or digital certificate storage area of the terminal. Subsequently, using a predefined serialization protocol, such as ProtocolBuffers or RLP encoding standard, the above environment data set and the requester digital identity are structured and assembled in strict field order. In the encapsulation process, the combined data is binary serialized, and a locally generated random number is appended to prevent replay attacks, finally forming a compact and tamper-proof context verification request package. This request package is prepared as a single entity object and is sent to the background context authority for subsequent verification and signature through a secure communication channel.

[0025] In step S320, the context verification request package is subjected to authority state checking and time anchoring to obtain a to-be-verified data block and a current timestamp. It should be noted that since the user terminal device is in an uncontrolled open network environment, the geographical position and time information reported by the user terminal device is at risk of being tampered with or forged, and the validity of the simple digital identity of the requester cannot reflect whether the requester is currently in a legal on-duty state or an authorized operation area. Based on this, the technical solution of the present application further subjects the context verification request package to authority state checking and time anchoring to obtain a to-be-verified data block and a current timestamp, so as to introduce a business compliance checking logic in a trusted server and forcibly inject an unforgeable server atomic time as a time effectiveness reference. Through the above processing, it is possible to effectively eliminate a violation request of a user who is off-duty, on leave, or outside a geographical fence, and to provide an authority time endorsement with anti-replay attack capability for subsequent credential generation.

[0026] More specifically, in one specific example of the present application, the server of the context authority first receives and deserializes the context verification request package, restores the identity of the requester and the environmental data. Subsequently, the server queries an internal personnel scheduling database and a state registry in real time to check whether the requester is in an active or on-duty state at the current time, and uses an electronic fence algorithm to check whether the reported GPS coordinates fall within the preset legal jurisdiction range. If the above business logic checking is passed, the system calls a high-precision network time protocol interface to obtain the current server atomic time, and generates an accurate current timestamp. Finally, the system splices and encapsulates the verified identity information, environmental data, and the current timestamp according to a predetermined byte sequence to form a to-be-verified data block for subsequent signature steps.

[0027] In step S330, the to-be-verified data block is subjected to authority private key signing and credential synthesis based on the authority private key and the current timestamp to obtain a context attribute credential. It should be noted that if the verified data block is directly transmitted in plaintext form to the blockchain network, it is extremely easy to be intercepted and tampered with by malicious attackers, or to be forged by unauthorized subjects to cheat the smart contract, so that the real state of the off-chain physical world cannot be mapped to the on-chain in a trusted manner. Based on this, the technical solution of the present application further performs the operation of subjecting the to-be-verified data block to authority private key signing and credential synthesis based on the authority private key and the current timestamp to obtain a context attribute credential, so as to use asymmetric encryption technology to impose a digital endorsement of the authority on the data carrier containing the space-time information, and to ensure the authenticity of the data source and the integrity of the content. Through the above processing, it is possible to effectively construct a digital credential with legal effect, so that the subsequent smart contract can verify the credibility of the off-chain scene data through a public key signature verification mechanism without relying on the intervention of a third party, thereby realizing the secure anchoring of on-chain and off-chain data.

[0028] More specifically, in one specific example of the present application, a secure hash algorithm (such as SHA-256) is first used to calculate a digest of the data block to be verified, generating a fixed-length message fingerprint, which ensures that any slight data change will result in a significant difference in the fingerprint. Subsequently, the authoritative private key stored in the hardware security module or high-security level key library is called to perform a digital signature operation on the generated hash digest, generating a corresponding signature value. Finally, the digital signature and the original data block to be verified (including the requester's identity, environmental data, and current timestamp) are encapsulated and synthesized according to the predefined credential data structure to construct a context attribute credential. This credential serves as a complete encryption container, containing the data block hash (or attribute commitment value) to be verified and its corresponding signature value for on-chain verification; without affecting the signature verification, the environmental data involving sensitive privacy can be processed in a way of being saved only off-chain after being hashed / desensitized / encrypted.

[0029] Specifically, in step S400, the context attribute credential, the policy index of the on-chain strategy matrix, and the target license identifier are constructed into a dynamic access request vector and uploaded to obtain a dynamic authorization application transaction to be processed. It should be noted that, since the context attribute credential generated off-chain usually contains unstructured semantic information and a digital signature, it cannot be efficiently processed by the matrix operation engine inside the smart contract, and if there is no explicit reference to a specific policy version, the contract will have difficulty in accurately locating the matching rules in a multi-version coexisting policy space. Based on this, the technical solution of the present application further constructs a dynamic access request vector of the context attribute credential, the policy index of the on-chain strategy matrix, and the target license identifier and uploads it to obtain a dynamic authorization application transaction to be processed, so as to map discrete identity and environmental attributes into a mathematical vector form suitable for on-chain algebraic operation, and encapsulate the vector, the cryptographic evidence, and the target resource handle into an atomized transaction instruction conforming to the blockchain protocol. Through the above processing, the logical conversion from the off-chain semantic space to the on-chain computing space can be effectively completed, ensuring that the smart contract receives a computing request with a specified format, solid evidence, and clear direction, thereby triggering an unforgeable on-chain authorization judgment process.

[0030] Figure 4 The flowchart of the process of constructing a dynamic access request vector of the context attribute credential, the policy index of the on-chain strategy matrix, and the target license identifier and uploading it to obtain a dynamic authorization application transaction to be processed according to the electronic license transfer and storage method of the fusion blockchain smart contract of the present application. As shown in FIG. 4, the process includes the following steps: Figure 4As shown, step S400 includes: S410, attribute feature extraction and vector initialization are performed on the context attribute credential and the policy index to obtain an attribute feature vector; S420, transaction load packaging and ABI encoding are performed on the context attribute credential, the attribute feature vector, and the target license identifier to obtain a data load; and S430, the data load is digitally signed and transaction broadcast is performed based on a requester private key to obtain a dynamic authorization application transaction to be processed.

[0031] In step S410, attribute feature extraction and vector initialization are performed on the context attribute credential and the policy index to obtain an attribute feature vector. It should be noted that the context attribute credential generated off-chain contains concrete key-value pair data (such as role: traffic police), and the policy matrix stored on-chain is a mathematical model based on abstract indexes. There is a dimensional mismatch between the two in terms of data form, which causes the smart contract to be unable to directly use the original credential as an arithmetic input for efficient matrix matching operations. Based on this, the technical solution of the present application further performs attribute feature extraction and vector initialization on the context attribute credential and the policy index to obtain an attribute feature vector, thereby converting unstructured semantic attributes into a digital feature vector that is strictly aligned with the dimension of the on-chain policy matrix, and specifying the policy version applicable to the vector. Through the above processing, dimensional reduction mapping from the off-chain semantic space to the on-chain algebraic space can be effectively realized, the computational complexity and Gas fee consumption of the smart contract are reduced, and the accuracy and efficiency of subsequent authorization calculations are ensured.

[0032] More specifically, in one specific example of the present application, the requester client first uses a pre-installed decoder to parse and verify the context attribute credential held locally, confirms the integrity of the credential data, and extracts key fields such as subject identity attributes (such as role, rank) and environmental context attributes (such as current location area, task status, time window). Subsequently, the system calls a hash mapping algorithm consistent with the construction logic of the on-chain policy matrix to convert each concrete attribute key-value pair extracted above into a corresponding numerical index or hash value. Then, according to the column definition structure of the on-chain policy matrix pointed to by the policy index, a zero-based reference vector is initialized, and the value of the attribute index corresponding position is set to a specific identification bit (such as binary 1 or a specific weight value), thereby constructing an attribute feature vector that can accurately represent the current request scenario. Finally, the vector and the policy index are packaged to serve as basic parameters for subsequent transaction construction.

[0033] In step S420, the context attribute credential, the attribute feature vector, and the target license identifier are transaction load packaged and ABI encoded to obtain a data load. It should be noted that since the smart contract running environment (such as Ethereum Virtual Machine, EVM) cannot directly identify or process serialized heterogeneous data objects, and different on-chain function interfaces have strict underlying specification requirements for the byte arrangement order and encoding format of input parameters, directly transmitting original data objects will cause contract call failure or parameter parsing error. Based on this, the technical solution of the present application further packages and ABI encodes the context attribute credential, the attribute feature vector, and the target license identifier to obtain a data load, so as to standardize the multi-source heterogeneous business parameters into a compact hexadecimal bytecode stream that conforms to the smart contract application binary interface specification. Through the above processing, the format compatibility barrier between off-chain data structure and on-chain execution environment can be effectively eliminated, ensuring that the smart contract can accurately identify the target function and correctly parse the input parameters, thereby guaranteeing the atomicity and stability of transaction execution.

[0034] More specifically, in one specific example of the present application, first, the attribute feature vector, the context attribute credential, and the target license identifier are assembled into an ordered parameter tuple according to the parameter arrangement order of the pre-defined authorization request function interface in the smart contract. Then, the hash value of the target function signature is calculated using a cryptographic hash algorithm (such as Keccak-256), and the first 4 bytes are intercepted as the function selector, which is used to accurately locate the specific logical code segment called during on-chain execution. Next, the parameter tuple is serialized using a standard ABI encoding algorithm, and the attribute feature vector and the license identifier are aligned with 32-byte zero padding, and the offset and actual length of the context attribute credential are calculated, and all encoded data segments are compactly concatenated. Finally, the function selector and the serialized parameter data stream are merged to generate the final transaction data load, which is a string of binary instruction code that can be directly parsed and executed by the blockchain node.

[0035] In step S430, the data load is digitally signed based on the requester private key and the transaction is broadcast to obtain a dynamic authorization application transaction to be processed. It should be noted that since the blockchain network is a decentralized open environment, the simple data load lacks a verifiable identity anchoring mechanism. If not digitally signed and directly transmitted, the blockchain node cannot confirm the true identity of the transaction initiator, thereby making the system face the risk of identity impersonation and malicious tampering. At the same time, the transaction data generated locally must be diffused to all network nodes through a network propagation mechanism, so as to be captured by the consensus node and included in the block, otherwise the request cannot trigger the execution of the on-chain smart contract. Based on this, the technical solution of the present application further performs the operation of digitally signing the data load based on the requester private key and broadcasting the transaction to obtain a dynamic authorization application transaction to be processed, so as to use the asymmetric encryption technology to impose an irrefutable identity endorsement on the transaction instruction and push it to the pending pool of the blockchain network. Through the above processing, the authenticity and integrity of the transaction source can be effectively guaranteed, the man-in-the-middle attack and replay attack can be prevented, and the guarantee of the timely response and processing of the distributed network to the guarantee flow transfer request can be ensured.

[0036] More specifically, in one specific example of the present application, the requester client first constructs an unsigned original transaction object according to the protocol specification of the current blockchain network, which not only encapsulates the ABI encoded data load generated in the previous stage, but also contains the address of the target smart contract, the upper limit of the fuel fee to be paid this time, and a strictly increasing random number Nonce value bound to the requester address. Subsequently, the system calls the requester private key stored in the local secure wallet or hardware security module, and performs an encryption operation on the hash digest of the original transaction object using the elliptic curve digital signature algorithm to generate an encrypted signature containing three components r, s, and v. Then, the system serializes and splices the original transaction field and the above digital signature using the recursive length prefix encoding standard to generate the final signed transaction binary stream. Finally, the client connects to the blockchain node through the remote procedure call interface and broadcasts the signed transaction to the peer-to-peer network, so that it can quickly spread and reside in the transaction memory pool of all network nodes, waiting to be verified and packaged by the miner node and chained.

[0037] Specifically, in step S500, based on the policy index of the on-chain policy matrix, adaptive calculation of the on-chain ABAC policy engine is performed on the dynamic authorization application transaction to be processed to obtain a permission field mask. It should be noted that, since the traditional smart contract access control logic is often limited to simple static rule matching or rigid Boolean operation, it is difficult to effectively resolve conflicts between multi-dimensional policies, such as contradictions between high-privilege roles and restrictive states, and lacks mathematical perception ability for continuous environmental variables such as physical distance, resulting in the authorization result often having the drawbacks of excessive or insufficient permissions due to the inability to accurately adapt to real-time scenarios. Based on this, the technical solution of the present application further performs adaptive calculation of the on-chain ABAC policy engine on the dynamic authorization application transaction to be processed based on the policy index of the on-chain policy matrix to obtain a permission field mask, so as to utilize the smart contract as a trusted policy decision point, on the basis of verifying the authenticity and timeliness of the context certificate, execute a quantitative evaluation model that combines policy weights and environmental dynamic penalty factors, and thus solve the access permission state for each specific field in real time. Through the above processing, accurate conversion from complex discrete business rules and continuously changing physical environments to a determined binary authorization result can be effectively realized, ensuring that the on-site verification requirements are met while strictly following the principle of minimizing disclosure, and completely solving the dynamic and compliance problems in the flow authorization process.

[0038] Figure 5 For the policy index based on the on-chain policy matrix of the electronic certificate flow storage method according to the electronic certificate flow storage method of the fusion block chain smart contract of the embodiment of the present application, the adaptive calculation of the on-chain ABAC policy engine is performed on the dynamic authorization application transaction to be processed to obtain a permission field mask. As shown in Figure 5 S500, S510, based on the policy index of the on-chain policy matrix, transaction unpacking and security pre-checking are performed on the dynamic authorization application transaction to be processed to obtain an attribute feature vector after verification; S520, on-chain retrieval is performed on the policy index to obtain a target policy vector; S530, adaptive mask calculation is performed on the attribute feature vector after verification and the target policy vector to obtain a permission field mask.

[0039] In step S510, based on the policy index of the on-chain policy matrix, the transaction unpacking and security pre-checking are performed on the dynamic authorization application transaction to be processed to obtain the attribute feature vector after checking. It should be noted that although the transaction on the block chain has been verified by the basic signature of the network layer, the business data in the load, especially the context certificate involving sensitive permissions, may still have deep security risks such as logical level forgery, expired replay, or version mismatch. If the smart contract directly performs complex policy calculation on the data without deep checking, not only the valuable on-chain computing resources will be wasted, but also the malicious attacker may use the expired legal certificate to cheat the instant authorization. Based on this, the technical scheme of the present application further performs the operation of transaction unpacking and security pre-checking on the dynamic authorization application transaction to be processed based on the policy index of the on-chain policy matrix to obtain the attribute feature vector after checking, so as to build a strict firewall before consuming a large amount of computing resources to execute the core policy engine, and ensure that all data flowing into the computing logic have authenticity, timeliness and logical consistency. Through the above processing, the replay attack and the forged certificate attack can be effectively blocked, and the system is ensured to respond only to the legal and compliant requests within the effective time window, thereby greatly improving the overall security and operation efficiency of the system.

[0040] More specifically, in one specific example of the present application, the smart contract first receives and parses the incoming dynamic authorization application transaction to be processed, restores the transaction load into independent business parameters such as attribute feature vector, context attribute certificate and target certificate identifier using the built-in ABI decoder. Then, the contract calls the underlying cryptography primitives, extracts the digital signature in the context attribute certificate, and uses the pre-set authority public key to verify the signature, to ensure that the data is issued by a legal dispatch center or authentication agency and has not been tampered with. After the signature verification is passed, the contract immediately reads the timestamp of the current block, and compares it with the generation timestamp recorded in the certificate to calculate the time difference. If the difference exceeds the system preset effective time window (for example, five minutes), the contract will determine that the request is an expired replay attack and automatically roll back the transaction. Finally, the contract performs consistency checking on the attribute feature vector obtained by decoding and the original attribute hash in the certificate, and verifies whether the strategy index version carried by the vector matches the current on-chain effective policy matrix version. Only when all the checking steps are passed, the attribute feature vector after checking marked as trusted is output for subsequent steps.

[0041] In step S520, the policy index is searched on-chain to obtain the target policy vector. It should be noted that due to the extremely limited state storage space of the blockchain and the positive correlation between the fuel cost of read-write operations and data volume, if the full amount of business policy library is linearly traversed or fully loaded at each authorization request, it will lead to an unacceptable increase in transaction costs and verification delay, and it is difficult to quickly locate the specific rule set currently in effect in a complex environment with multiple policies coexisting. Based on this, the technical solution of the present application further searches the policy index on-chain to obtain the target policy vector, and uses the hash index technology to accurately locate and extract the compressed policy data that uniquely matches the current request context in the persistent storage area of the decentralized ledger. Through the above processing, it can effectively realize time complexity policy addressing, avoiding invalid loading of irrelevant data, thereby reducing the consumption of on-chain computing resources while ensuring the accuracy of policy execution.

[0042] More specifically, in one specific example of the present application, the smart contract first extracts the policy index in the transaction payload that has passed the verification through the previous steps as a key value, and performs addressing operation on the persistent state mapping table maintained inside the contract. This mapping table establishes a direct indexing relationship between the policy fingerprint and the storage location, pointing to the sparse policy matrix data structure pre-deployed on the chain. Subsequently, the contract locates the specific storage slot according to the index and reads the policy data block in the compressed row storage format or binary bitmap form at this location. Then, using the attribute feature vector carried in the request as the row selector or offset parameter, the binary row data or weight value sequence that defines all field access permissions in the current scenario is extracted from the compressed data block, i.e. the target policy vector. This vector accurately describes the initial authorization status of the full amount of fields under the current identity and environment combination, providing direct arithmetic input for subsequent mask calculation.

[0043] In step S530, the checked attribute feature vector and the target policy vector are adaptively masked to obtain a permission field mask. It should be noted that, in view of the fact that the policy merging mechanism based on simple Boolean operation (such as bit or / bit and) in the prior art lacks flexibility in dealing with complex scenarios, cannot effectively eliminate the logical conflicts between high-privilege roles (such as police) and restrictive states (such as on leave), and cannot perceive the dynamic constraints of continuous environmental context such as physical distance, resulting in that the authorization result often causes privacy leakage or hinders normal performance due to the coarse granularity. Based on this, the technical solution of the present application further adaptively masks the checked attribute feature vector and the target policy vector to obtain a permission field mask, thereby upgrading the static discrete policy to a quantitative decision model based on tensor projection and weighted aggregation, and introducing a dynamic penalty correction mechanism based on continuous environmental factors to adjust the authorization score in real time. Through the above processing, intelligent arbitration of policy mutual exclusion relationship and dynamic priority can be effectively realized, and the spatial constraints of the off-chain physical world are smoothly converted into an executable mathematical probability model on the chain, thereby generating a fine-grained access control result highly adapted to the current complex business scenario.

[0044] Figure 6 The flowchart of the adaptive mask calculation of the checked attribute feature vector and the target policy vector to obtain the permission field mask according to the electronic certificate circulation and storage method of the fusion blockchain smart contract of the electronic certificate circulation method according to the embodiment of the present application. As shown in Figure 6 S530, S531, based on the policy tensor space, the checked attribute feature vector and the target policy vector are projected and weighted aggregated to obtain an initial field score vector; S532, based on the environmental context data, the initial field score vector is dynamically penalized based on the continuous environmental factors to obtain a modified score vector; S533, based on the global security threshold, the modified score vector is threshold determined to obtain the permission field mask.

[0045] In step S531, the attribute feature vector after verification and the target policy vector are projected and weighted aggregated based on the policy tensor space to obtain an initial field score vector. It should be pointed out that the smart contract ABAC mask extraction mechanism in the prior art has inherent limitations when dealing with complex electronic certificate circulation scenarios. This mechanism relies on the combination of simple bit operations on multiple static policies (such as role = traffic police and time = late night). This processing method lacks the necessary robustness and flexibility in practical applications. In particular, when a high-privilege role (such as a police officer) policy and a restrictive state (such as on vacation) policy are activated at the same time, simple bit operations cannot effectively resolve conflicts. This neglect of policy mutual exclusion and dynamic priority is a flaw in the original mechanism that makes it difficult to balance between security and efficiency. Based on this, the technical solution of the present application further projects and weighted aggregates the attribute feature vector after verification and the target policy vector based on the policy tensor space to obtain an initial field score vector, to perform the projection and weighted aggregation step of the multi-dimensional policy tensor, to upgrade the simple Boolean logic to a quantitative weight decision model, thereby accurately processing the complex conflict relationship between policies. Through the above processing, it can effectively ensure that when the priorities of different attributes (such as identity, state, and time) in real business rules differ, weights are introduced to quantify their importance, so that the smart contract has the decision-making ability to simulate special handling in human society under special circumstances.

[0046] More specifically, in one specific example of the present application, instead of using the traditional two-dimensional policy matrix for simple logical judgment, all relevant policy slices are extracted from a three-dimensional policy tensor space preloaded on the chain according to the attribute features activated by the requester. The dimensions of this tensor space are (rule, field, action type), where the action type clearly distinguishes between allowed and prohibited. Subsequently, for each field in the certificate , the positive authorization score and the negative prohibition score are calculated respectively by a weighted summation algorithm. The specific calculation logic follows the following formula: wherein, represents the field index, represents the activated rule index, represents the activated rule index set, is the weight value of the th rule obtained from the attribute weight vector, is the control value (1 or 0) of the rule for the field recorded in the policy tensor, and the superscripts Allow and Deny correspond to the control values of the allowed and prohibited levels, and are the positive authorization score and the negative prohibition score, respectively. In this way, the high and low scores intuitively reflect the strength of authorization and prohibition, and ultimately generate an initial field score vector containing the permission and prohibition score pairs of each field, providing a quantitative basis for dynamic correction in the next step. For example, in a specific police enforcement scene, assume that the police role strategy grants access to the driver's license number field (control value 1), but its associated regular weight is set to 0.4; while the vacation state strategy prohibits access to the field (control value 1), and due to the high compliance requirements of privacy protection, its associated veto weight is set to 0.9. In the calculation process, although the positive authorization score of the police role accumulates 0.4, the negative prohibition score of the vacation state is as high as 0.9. Since the prohibition score is significantly higher than the authorization score, a high-weight vacation state can effectively offset the authorization effect brought by a low-weight administrator role, thereby enforcing the business rule of strictly prohibiting privacy intrusion during non-duty hours at the mathematical level, and avoiding the risk of privacy leakage in the non-duty state due to simply having a police identity under traditional logic.

[0047] In step S532, based on the environmental context data, the initial field score vector is dynamically penalized and corrected based on continuous environmental factors to obtain a modified score vector. It should be noted that, since the authorization logic in the existing method is completely based on a discretized, pre-defined attribute matrix, it lacks the ability to perceive continuous environmental context. For example, for highly sensitive fields such as address, access permission should not only depend on the requester's identity, but also be strongly related to their real-time physical location. The original mechanism cannot handle such continuous value-based dynamic constraints that can only be viewed within a 100-meter range of the target address, resulting in a coarse granularity of authorization strategies that cannot meet the on-site verification requirements of high security levels. Based on this, the technical solution of the present application further dynamically penalizes and corrects the initial field score vector based on continuous environmental factors based on environmental context data to obtain a modified score vector, thereby performing a dynamic penalty correction step based on continuous environmental factors, aiming to use the physical environment and other continuous variables in which the requester is located as a dynamic factor for authorization calculation, to solve the shortcoming of the original mechanism that cannot perceive the context of the real world. Through the above processing, it can effectively convert the spatial constraints of the off-chain physical world into an on-chain executable, smooth mathematical probability model, thereby realizing the transition of authorization logic from discrete to continuous, and improving the scene adaptability and security of the system.

[0048] More specifically, in one specific example of the present application, the environment context data contained in the smart contract acquisition request, such as the physical distance between the requester's current GPS location and the target resource. For fields sensitive to geographical location (such as home address), a distance decay algorithm based on the Sigmoid function is applied to calculate the dynamic correction coefficient. The specific calculation formula is as follows: wherein, is the final correction coefficient acting on the field authorization score, whose value range is between 0 and 1, represents the actual physical distance, is the preset compliance distance threshold, and controls the steepness of the decay curve. Then, the correction coefficient is used to punish the forward authorization score obtained in the previous stage, and the calculation formula is: wherein, and are the corrected allowed score and the original forbidden score, respectively. Through this process, a corrected score vector that integrates the influence of continuous environmental variables is generated. For example, in a high-sensitive scenario that requires on-site verification of home address, the preset compliance distance threshold is 50 meters. Assuming that a police officer with high authority (initial authorization score 0.9) initiates a query request at a distance of 500 meters from the target location. Since the actual distance (500 meters) is much greater than the threshold, the correction coefficient will tend to 0 (e.g., 0.01) after calculation by the Sigmoid function. At this time, the final score after correction will become . Even if the police officer is legitimate, since the requester is far away from the scene, increases, tends to 0, and even if he has the highest authority, his positive authorization score will be greatly weakened, thus achieving the control effect of non-site visit.

[0049] In step S533, a threshold determination is performed on the modified score vector based on a global security threshold to obtain the permission field mask. It should be noted that, given that the previous steps generated a modified score vector that includes the influence of continuous environmental variables, resulting in continuous numerical results, and that the final data access control requires a clear, black-and-white binary instruction, simply comparing numerical values ​​could easily lead to misauthorization risks in the ambiguous zone where both allowed and prohibited scores are low and nearly identical. Therefore, the technical solution of this application further performs a threshold determination on the modified score vector based on a global security threshold to obtain the permission field mask, thereby integrating all calculation results to produce a final, directly executable binary authorization mask. Through this processing, misauthorization can be effectively prevented in the ambiguous zone where both allowed and prohibited scores are low and nearly identical, ensuring that access is only granted when the modified allowed score is not only strictly higher than the prohibited score but also meets the system's preset minimum trust standard, thus guaranteeing the rigor and security of the authorization decision.

[0050] More specifically, in a particular example of this application, the smart contract iterates through each field of the certificate. The final mask bits are calculated using a dual-judgment logic that prioritizes negation and requires a passing score. The specific calculation formula is as follows: in, It is the first in the permission field mask Bit, This is an indicator function that outputs 1 when the condition inside the parentheses is true, and 0 otherwise. and These are the revised allowed scores and the original prohibited scores, respectively. This is the system's preset global security threshold. It should be noted that access permission for a field is granted if and only if its modified allowed score is not only significantly higher than its prohibited score (negation priority principle), but its own strength must also meet a minimum credible standard. Ultimately, the judgment results for all fields... These fields are combined into a fixed-length binary string, which is the final permission field mask. It precisely defines which fields are visible and which need to be hidden in this request. Continuing with the scenario of a police officer querying a home address, let's assume the system has a preset global security threshold. The score is 0.6. Because the officer was far from the target location, his adjusted positive authorization score is [not specified]. It has decayed to 0.009, while its original prohibited score due to vacation status has decreased. The value is 0.9. Substituting this into the formula, the following checks are performed: First, 0.009 is not greater than 0.9, failing the negation priority check; second, 0.009 is much less than the threshold of 0.6, failing the safety threshold check. Indicator function Output 0, i.e. the mask bit is 0. This means that although the police officer has a legal police identity, due to the physical distance being too far and being on leave, the mask generated by the smart contract will force the shielding of the home address field, thus strictly implementing the minimum disclosure and scene compliance principle at the code level.

[0051] Specifically, in step S600, a temporary authorization token is generated based on the permission field mask, the requester ID and the target license ID. It should be pointed out that since the permission field mask calculated by the smart contract is only a temporary logical state in memory, it lacks independent flow attribute and anti-tampering mechanism, and if a strict time window and identity binding are not set, the permission can be easily intercepted by malicious users and replayed or transferred to unauthorized subjects, resulting in invalid security boundaries. Based on this, the technical solution of the present application further generates a temporary authorization token based on the permission field mask, the requester ID and the target license ID, so as to fix the abstract permission bitmap into a digital certificate with a unique fingerprint, a clear life cycle and a strong identity binding. Through the above processing, the permission can be effectively implemented as read-once and exclusive use, ensuring that each data access authorization can be accurately tracked and cannot be illegally transferred.

[0052] More specifically, in one specific example of the present application, based on the permission field mask, the requester ID and the target license ID, a temporary authorization token is generated, including: setting a life cycle parameter and Hash binding of the permission field mask, the requester ID and the target license ID to obtain a token identifier and a token expiration time; and performing token structure body encapsulation of the token identifier, the token expiration time, the permission field mask and the target license ID to obtain the temporary authorization token.

[0053] Further, the permission field mask, the requester ID and the target license ID are first subjected to life cycle parameter setting and Hash binding to obtain a token identifier and a token expiration time. The smart contract reads the timestamp of the current block as a reference time, superimposes a preset valid time length to calculate the absolute invalidation time point of the token, thereby defining the life cycle of the authorization. Subsequently, the hash value of the current transaction is extracted as a random entropy source, which is byte-level spliced with the permission field mask, the requester account address, the target license unique identifier and the calculated invalidation time point. A one-way operation is performed on the spliced data stream using a cryptographic hash algorithm to generate a fixed-length hash digest as the token identifier, ensuring that the identifier corresponds to a specific transaction context and authorization content one by one, and any slight tampering of the parameters will cause the identifier to change. Next, the token identifier, the token expiration time, the permission field mask and the target license ID are encapsulated into a token structure to obtain a temporary authorization token. A standardized data structure is instantiated in the memory space of the smart contract, with the generated token identifier as the index key, and the corresponding expiration time, specific field permission mask and target resource handle are filled in. The structure serves as the final authorization carrier and is written into the contract storage mapping, and the token identifier and expiration time are output through the event log; the requester client can obtain the token identifier from the transaction receipt to call the gateway off-chain in the future.

[0054] Specifically, in step S700, based on the off-chain encrypted license database, the token-based controlled data acquisition and audit closed loop of the temporary authorization token is performed to obtain desensitized license data. It should be noted that, since the temporary authorization token on the blockchain is only a digitalized voucher of the permission, and the real electronic license data is stored in the centralized database off-chain, if there is a lack of strict person-credential verification and field-level filtering mechanism in the data extraction link, it is easy to cause the legal token to be used for illegal unauthorized access, or the data gateway to directly return full-amount plaintext data containing sensitive privacy due to logical loopholes, resulting in the failure of the fine-grained authorization strategy on the blockchain in the last mile; at the same time, the lack of closed-loop audit records will lead to the inability to trace the responsibility subject after data leakage. Based on this, the technical solution of the present application further performs the operation of token-based controlled data acquisition and audit closed loop of the temporary authorization token based on the off-chain encrypted license database to obtain desensitized license data, so as to build a mandatory policy enforcement checkpoint at the off-chain data export, ensure that the output of physical data is strictly limited to the permission boundary defined by the on-chain token, and simultaneously generate irrefutable access evidence. Through the above processing, the safe mapping of on-chain logical permissions and off-chain physical data can be effectively realized, the risk of excessive disclosure of data is eliminated, and a complete cross-domain flow evidence chain is formed.

[0055] More specifically, in one specific example of the present application, based on the off-chain encrypted credential database, the token-based controlled data acquisition and audit closed loop of the temporary authorization token is performed to obtain the desensitized credential data, including: performing token authenticity and validity verification on the temporary authorization token to obtain a verification pass signal and a permission field mask; based on the off-chain encrypted credential database, dynamically desensitizing the permission field mask and the target credential ID to obtain the desensitized credential data.

[0056] That is, more specifically, the credential data service gateway first performs token authenticity and validity verification on the received temporary authorization token to obtain a verification pass signal and a permission field mask. This process queries the corresponding token state (whether it exists / is expired / is revoked) on the blockchain through the token identifier, and checks whether the requester address bound to the token is consistent with the caller identity this time to confirm that it is indeed generated and recorded by legal contract logic. At the same time, the atomic time in the gateway local and the expiration timestamp in the token are compared to verify whether it is within the valid life cycle, and the authorization event log on the blockchain is further queried to confirm that the token has not been revoked. After confirming the authenticity and validity of the token, the gateway parses the binary permission field mask carried therein. Then, based on the off-chain encrypted credential database, the permission field mask and the target credential ID are dynamically desensitized to obtain the desensitized credential data. The gateway retrieves the corresponding ciphertext data from the encrypted database in the high-security area according to the target credential ID, and decrypts and restores it in the trusted memory area. Subsequently, the full-quantity fields of the credential are traversed, and the permission field mask and the field index are used for bit operation matching. For the sensitive fields (such as home address or identity card number unnecessary bits) identified as prohibited by the mask bit, desensitization processing such as character replacement or null filling is performed, and finally only the allowed field plaintext is retained, which is recombined into a standardized data view and returned to the requester. At the same time, an audit log containing the access metadata this time is generated and hashed on the chain, completing the circulation closed loop.

[0057] In summary, the electronic credential circulation and storage method fusing a blockchain smart contract according to the embodiments of the present application is clarified, which structures the business rules into a multi-dimensional policy tensor on the chain, and introduces an authority-signed context attribute certificate, so that the smart contract can parse the multi-dimensional attribute characteristics of the requester in real time. The weighted aggregation algorithm is used to resolve conflicts of different priority policies, and a dynamic penalty model based on continuous environmental factors is combined to convert real constraints such as physical distance into real-time correction of authorization scores, so as to accurately generate a field-level permission mask that meets the current scene. On this basis, the system generates a temporary authorization token bound with time limit and transaction fingerprint, and cooperates with the controlled extraction of the off-chain gateway and the on-chain audit writeback, realizing the leap from static identity verification to dynamic scene perception, and ensuring the fine-grained authorization and trusted storage of credential data in complex circulation environment.

[0058] As described above, the electronic certificate circulation and storage method of the fusion blockchain smart contract according to the embodiments of the present application can be implemented in various trusted computing and government service infrastructures, such as a blockchain alliance chain node server, a government cloud data exchange center, a mobile law enforcement handheld terminal, or a cross-institution identity authentication gateway, etc. In one possible implementation, the electronic certificate circulation and storage method of the fusion blockchain smart contract according to the embodiments of the present application can be integrated into a smart city public service platform or a supply chain financial data verification system as a software module or a hardware module. For example, the electronic certificate circulation and storage method of the fusion blockchain smart contract can be an independent storage and audit application program running on a government blockchain network, or it can be a privacy protection plug-in and dynamic authorization function module of an existing network office platform, or it can be a bottom trust service deployed in an electronic certificate sharing middle platform and pushing desensitized data to a business handling terminal through API; of course, the multi-dimensional strategy matrix mapping, on-chain ABAC adaptive calculation and context attribute certificate generation module in the method can also be fixed in a hardware security module, a trusted execution environment chip or a domestic cryptographic card, as one of the privacy computing security bases or real-time circulation verification hardware modules of the electronic certificate system.

[0059] The above has described various embodiments of the present disclosure, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes are obvious to those skilled in the art without departing from the scope and spirit of the described embodiments. The choice of terms used herein is intended to best explain the principles, practical application, or improvement of technology in the market of the embodiments, or to enable other ordinary skilled persons in the art to understand the embodiments disclosed herein.

Claims

1. A method for electronic certificate transfer and storage integrating blockchain smart contracts, characterized in that, include: Obtain the original natural language business strategy and the full list of certificate fields; On-chain initialization and deployment of a multi-dimensional strategy matrix are performed on the original natural language business strategy and the full list of certificate fields to obtain the strategy index of the on-chain strategy matrix; Generate context attribute credentials based on the requester's digital identity, environmental data, and authoritative private key; The dynamic access request vector is constructed and uploaded to the chain for the context attribute certificate, the policy index of the on-chain policy matrix, and the target certificate identifier to obtain the dynamic authorization application transaction to be processed; Based on the strategy index of the on-chain strategy matrix, the dynamic authorization application transaction to be processed is adaptively calculated by the on-chain ABAC strategy engine to obtain the permission field mask; Generate a temporary authorization token based on the permission field mask, requester ID, and target certificate ID; Based on an off-chain encrypted certificate database, a token-based controlled data acquisition and auditing loop is performed on temporary authorization tokens to obtain de-identified certificate data.

2. The method for electronic certificate circulation and storage integrating blockchain smart contracts according to claim 1, characterized in that, The original natural language business strategy and the full list of certificate fields are initialized and deployed on-chain as a multi-dimensional strategy matrix to obtain the strategy index of the on-chain strategy matrix, including: Perform semantic parsing and structured mapping of the original natural language business strategy and the full list of certificate fields to obtain the attribute-permission mapping table; The attribute-permission mapping table is transformed into a sparse matrix and compressed in space to obtain a sparse policy matrix. The sparse policy matrix is ​​stored in smart contract state and indexed to generate the policy index of the on-chain policy matrix.

3. The method for electronic certificate transfer and storage integrating blockchain smart contracts according to claim 1, characterized in that, Environmental data includes GPS coordinates, terminal device fingerprints, and task instruction hashes.

4. The method for electronic certificate circulation and storage integrating blockchain smart contracts according to claim 3, characterized in that, Based on the requester's digital identity, environmental data, and authoritative private key, generate context attribute credentials, including: Encapsulate the requester's digital identity and environmental data to obtain a context-verified request packet; Perform authoritative status verification and time anchoring on the context verification request packet to obtain the data block to be verified and the current timestamp; Based on the authoritative private key and the current timestamp, the data block to be verified is signed with the authoritative private key and the credentials are combined to obtain the context attribute credentials.

5. The method for electronic certificate circulation and storage integrating blockchain smart contracts according to claim 1, characterized in that, The dynamic access request vector is constructed and uploaded to the chain based on the context attribute credentials, the policy index of the on-chain policy matrix, and the target certificate identifier to obtain the dynamic authorization application transaction to be processed, including: Attribute feature extraction and vector initialization are performed on context attribute credentials and policy indexes to obtain attribute feature vectors; The context attribute credential, attribute feature vector, and target certificate identifier are encapsulated in transaction payload and ABI encoded to obtain the data payload. Based on the requester's private key, the data payload is digitally signed and the transaction is broadcast to obtain the dynamic authorization request transaction to be processed.

6. The method for electronic certificate circulation and storage integrating blockchain smart contracts according to claim 1, characterized in that, Based on the policy index of the on-chain policy matrix, the dynamic authorization request transaction to be processed undergoes adaptive calculation by the on-chain ABAC policy engine to obtain the permission field mask, including: Based on the strategy index of the on-chain strategy matrix, the dynamic authorization application transaction to be processed is unpacked and security pre-verification is performed to obtain the verified attribute feature vector. Perform on-chain retrieval on the policy index to obtain the target policy vector; An adaptive mask calculation is performed on the verified attribute feature vector and target policy vector to obtain the permission field mask.

7. The method for electronic certificate circulation and storage integrating blockchain smart contracts according to claim 1, characterized in that, Generate a temporary authorization token based on the permission field mask, requester ID, and target certificate ID, including: Set lifecycle parameters for the permission field mask, requester ID, and target certificate ID and bind them with a hash to obtain the token identifier and token expiration time; A temporary authorization token is obtained by encapsulating the token identifier, token expiration time, permission field mask, and target certificate ID into a token structure.

8. The method for electronic certificate circulation and storage integrating blockchain smart contracts according to claim 1, characterized in that, Based on an off-chain encrypted certificate database, a controlled data acquisition and auditing loop is performed on temporary authorization tokens to obtain de-identified certificate data, including: The temporary authorization token is verified for authenticity and validity to obtain a verification pass signal and a permission field mask; Based on an off-chain encrypted certificate database, dynamic data anonymization is performed on the permission field mask and the target certificate ID to obtain anonymized certificate data.

9. The method for electronic certificate transfer and storage integrating blockchain smart contracts according to claim 6, characterized in that, An adaptive mask calculation is performed on the verified attribute feature vector and target policy vector to obtain the permission field mask, including: Based on the policy tensor space, the verified attribute feature vector and the target policy vector are projected and weighted to obtain the initial field score vector. Based on environmental context data, the initial field score vector is dynamically penalized and corrected based on continuous environmental factors to obtain a corrected score vector; Based on a global security threshold, a threshold determination is performed on the modified score vector to obtain the permission field mask.

Images