Cross-department collaborative examination and approval digital processing method based on blockchain and smart contract

Abstract

The application discloses a cross-department collaborative approval digital processing method based on a blockchain and a smart contract, relates to the technical field of blockchains, and comprises the following steps: submitting approval materials through a front-end application, converting the approval materials into standardized JSON format data and generating data fingerprints, writing the data fingerprints into a blockchain and generating NFTs with a state of being to be pre-approved, searching for a department list participating in the approval according to an approval type field in the standardized JSON format data, verifying the validity of NFTs of the approval rights of the departments, and generating an encrypted pre-examination task package, and encrypting the encrypted pre-examination task package by using a full-homomorphic encryption algorithm.The application generates a risk analysis request package after collecting threshold signatures by means of a smart contract, performs real-time risk analysis by means of a neural network model deployed in the smart contract, outputs a risk disposal report or a plaintext approval document, synchronizes the result to relevant business chains by means of a cross-chain protocol, and generates verifiable credentials.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a cross-departmental collaborative approval digital processing method based on blockchain and smart contracts. Background Technology

[0002] Currently, cross-departmental collaborative approval processes between government departments and enterprises generally adopt a combination of centralized databases and manual review. By establishing a unified approval data platform, the approval rules and data of various departments are centrally managed. After application materials are recognized by OCR, they are stored in a relational database and routed to the corresponding department for manual review according to a preset process. Role-based access control mechanisms are usually adopted to achieve data isolation between departments by assigning different permission levels. In terms of data security, existing technologies mostly adopt a combination of transport layer encryption and database field-level encryption to ensure the confidentiality of approval information during transmission and storage. The hash value of the approval result is stored on the blockchain to enhance the traceability of the process.

[0003] However, existing technological systems still have room for improvement in achieving a balance between cross-departmental data collaboration and secure computing. When multiple departments are involved in parallel approvals, traditional solutions require copying and distributing the original application materials to each participating department. Even with field-level encryption, there is still a risk of excessive data exposure. In the scenario of joint approval for construction projects, the environmental protection department needs to verify pollution indicators, and the fire department needs to assess the design of evacuation routes. Although the encrypted data obtained by the two departments is isolated by permissions, the data preprocessing and key management before encryption still rely on a centralized institution, making it difficult to completely eliminate the possibility of unauthorized access by internal personnel. Summary of the Invention

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a cross-departmental collaborative approval digital processing method based on blockchain and smart contracts, which solves the privacy leakage risk problem caused by data replication and distribution and centralized key management in traditional solutions.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0007] In a first aspect, the present invention provides a cross-departmental collaborative approval digital processing method based on blockchain and smart contracts, which includes submitting approval materials through a front-end application, converting the approval materials into standardized JSON format data and generating data fingerprints, writing the data fingerprints into the blockchain and generating an NFT with a status of pending pre-approval;

[0008] The smart contract retrieves the list of departments involved in the approval process based on the approval type field in the standardized JSON format data, verifies the validity of the approval authority NFT of each department, and generates an encrypted pre-approval task package.

[0009] The encrypted pre-approval task package is encrypted using a fully homomorphic encryption algorithm, encrypted compliance calculation is performed, and joint approval middleware is generated.

[0010] The smart contract uses the private key bound to the approval authority NFT of each approval department to sign the joint approval middleware, collects signatures that meet the threshold conditions, and generates a risk analysis request package.

[0011] The risk analysis request package is input into a neural network model deployed in a smart contract for real-time risk analysis, generating a risk disposal report and a plaintext approval document. The smart contract synchronizes the plaintext approval document and the risk disposal report to the relevant business chain through a cross-chain protocol to generate verifiable credentials.

[0012] As a preferred embodiment of the cross-departmental collaborative approval digital processing method based on blockchain and smart contracts described in this invention, the method includes the following steps: submitting approval materials through a front-end application, converting the approval materials into standardized JSON format data and generating a data fingerprint, writing the data fingerprint into the blockchain and generating an NFT with a status of pending pre-approval.

[0013] Upload the approval documents through the front-end interface, temporarily store the approval documents in the distributed storage node, use the document parsing tool to process the temporary files, convert image materials into readable text, and obtain standardized JSON format data;

[0014] Standardized JSON format data is input into the classification model to generate structured data;

[0015] A hash tree is constructed from the structured data, and the hash value of the leaf nodes is calculated using the SHA3-256 algorithm to generate data fingerprints;

[0016] Based on the uploaded approval documents, user identity is obtained through digital wallet authorization;

[0017] The front end uses smart contracts to write data fingerprints and user identity identifiers into the blockchain and trigger contract events;

[0018] NFTs conforming to the ERC-721S standard are minted through smart contracts, with metadata links pointing to stored approval information and marked as pending pre-approval.

[0019] As a preferred embodiment of the cross-departmental collaborative approval digital processing method based on blockchain and smart contracts described in this invention, the smart contract retrieves the list of departments participating in the approval based on the approval type field in standardized JSON format data, verifies the validity of the approval right NFT of each department, and generates an encrypted pre-approval task package, including the following steps.

[0020] The smart contract parses the approvalType field in the standardized JSON data to obtain the current business category for approval, outputs the approval type string, queries the on-chain department registry contract based on the approval type string, obtains the list of participating approval department addresses, and outputs an array of department addresses.

[0021] Based on the department address array, examine the approval authority NFT held by each address to obtain a valid subset of department addresses that have passed verification;

[0022] Based on the permission bitmap of the valid department address subset, filter the fields that the valid departments can access from the JSON data to obtain the data subset after field filtering;

[0023] Obtain the public key from the NFT metadata, encrypt the data subsets after field filtering, and use the BFV homomorphic encryption method of the SEAL library to obtain the encrypted data packet;

[0024] Zero-knowledge proofs in Groth16 format are generated based on encrypted data packets. The encrypted data packets are verified to conform to the value range of the original JSON data, and proof documents and data integrity commitments are obtained.

[0025] The encrypted data packet, zero-knowledge proof, approval type string, and Merkle root hash are combined into a structured task package, and the task ID is calculated using a hash algorithm to generate an encrypted pre-approval task package.

[0026] As a preferred embodiment of the cross-departmental collaborative approval digital processing method based on blockchain and smart contracts described in this invention, the method includes the following steps: encrypting the encrypted pre-approval task package using a fully homomorphic encryption algorithm, performing encrypted compliance processing, and generating a joint approval middleware.

[0027] The smart contract parses the encrypted pre-approval task package, extracts the exclusive encrypted data blocks and corresponding zero-knowledge proof files of each department, obtains structured encrypted data, calls zk-SNARK to verify the encrypted data of each approval department, forms a valid zero-knowledge proof and associated Merkle root hash, and obtains a set of encrypted data that has passed verification.

[0028] Based on the encrypted data packet, an executable encrypted runtime environment is generated, and the homomorphism is initialized. The encrypted data packet is processed in the homomorphism calculator to obtain a Boolean result. The encrypted result is decrypted by each department using private key fragmentation to generate decryption parameters. The decryption parameters are aggregated by the Lagrange interpolation algorithm to obtain a readable compliance verification result.

[0029] The initialized homomorphic parameters, partially decrypted parameters, and readable compliance verification results are used to generate a joint approval middleware.

[0030] As a preferred embodiment of the cross-departmental collaborative approval digital processing method based on blockchain and smart contracts described in this invention, the smart contract allows the approval department to sign the joint approval middleware using the private key bound to the approval right NFT, including the following steps.

[0031] By parsing the joint approval middleware through smart contract, the validity of the aggregation result and zero-knowledge decryption proof is checked to obtain the verified middleware data. Random numbers are generated using the private key bound to the approval right NFT to form elliptic curve commitment points and temporary identifiers, and signature initialization parameters are obtained.

[0032] By broadcasting commitment points and temporary identifiers through the P2P network, the smart contract records valid commitments to on-chain storage, obtains a set of registered commitments, uses private key shards to sign the middleware hash, generates signature shares, and obtains cryptographic signature shards.

[0033] The smart contract calculates dynamic weights based on the signature response time of each department to obtain a weighted list of signature validity.

[0034] As a preferred embodiment of the cross-departmental collaborative approval digital processing method based on blockchain and smart contracts described in this invention, the following steps are included: collecting signatures that meet threshold conditions and generating a risk analysis request package.

[0035] The smart contract collects valid signature fragments that satisfy the t-of-n threshold, calculates the aggregate signature using Lagrange interpolation, and obtains the final aggregate signature.

[0036] The middleware data, departmental signature fragments, aggregated signatures, and timestamps are packaged to generate a standardized risk analysis request package.

[0037] As a preferred embodiment of the cross-departmental collaborative approval digital processing method based on blockchain and smart contracts described in this invention, the method includes the following steps: A risk analysis request package is input into a neural network model deployed in a smart contract for real-time risk analysis, generating a risk handling report and a plaintext approval document, respectively.

[0038] Structured analysis data is obtained by extracting the signature data, middleware content, and timestamp from the risk analysis request packet using smart contracts.

[0039] Based on structured analysis data, signature time dispersion, approval conflict index, and historical risk records are extracted, and feature standardization vectors are generated through Min-Max normalization.

[0040] The standardized feature vector is input into the lightweight ONNX model deployed by the compilation contract, and the forward computation is performed through the Sigmoid approximation function to obtain the risk probability value.

[0041] The risk threshold is dynamically calculated based on the urgency of the approval process to obtain the current decision threshold;

[0042] By comparing risk probability values ​​with dynamic thresholds, low, medium, and high risk levels are classified to obtain level labels;

[0043] Based on the rating labels, generate risk management reports using generateReport, issueApproval to issue digital approval documents conforming to W3C VC standards, and generate plaintext approval documents.

[0044] As a preferred embodiment of the cross-departmental collaborative approval digital processing method based on blockchain and smart contracts described in this invention, the smart contract synchronizes the plaintext approval document and risk disposal report to the relevant business chain through a cross-chain protocol to generate verifiable credentials, including the following steps.

[0045] The smart contract extracts the plaintext approval document, compresses and encrypts it using the Zstandard algorithm, and obtains a standardized cross-chain data packet.

[0046] Based on the globally unique registration identifier of the blockchain network, the source chain ID and target chain ID are obtained, and a serial number is generated based on the auto-incrementing counter maintained by the smart contract;

[0047] Encapsulate the encrypted data packet with the source chain ID, target chain ID, and sequence number into an IBC data structure to obtain the cross-chain packet to be transmitted;

[0048] Based on the relay node listening to source chain events, IBC packets and Merkle proofs are submitted to the target chain to obtain the data packet to be verified on the target chain;

[0049] Based on the data packet to be verified on the target chain, after determining its validity, it is stored in the on-chain receiving queue, and a verification success event is obtained.

[0050] By parsing and verifying the successful event on the target chain, a structured certificate ontology is generated according to the W3C VC standard, resulting in an unsigned certificate draft. The target chain smart contract then signs the certificate draft to generate a verifiable certificate.

[0051] In a second aspect, the present invention provides a computer device, including a memory and a processor, wherein the memory stores a computer program, wherein when the computer program is executed by the processor, it implements any step of the cross-departmental collaborative approval digital processing method based on blockchain and smart contracts as described in the first aspect of the present invention.

[0052] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program is executed by a processor, it implements any step of the cross-departmental collaborative approval digital processing method based on blockchain and smart contracts as described in the first aspect of the present invention.

[0053] The beneficial effects of this invention are as follows: Approval materials are submitted through a front-end application and converted into standardized JSON format data. After generating a data fingerprint, it is written to the blockchain and a pre-approval NFT is created. The smart contract retrieves a list of relevant departments based on the approval type and verifies the validity of their approval authority NFTs, generating an encrypted pre-approval task package. A fully homomorphic encryption algorithm is used to perform encrypted compliance calculations on the task package, generating a joint approval middleware. Each approval department uses its NFT-bound private key to sign the middleware. The smart contract collects threshold signatures and generates a risk analysis request package. Real-time risk analysis is performed using a neural network model deployed in the smart contract, outputting a risk disposal report or plaintext approval document. The results are synchronized to the relevant business chain via a cross-chain protocol, generating verifiable credentials. Attached Figure Description

[0054] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0055] Figure 1 This is a flowchart of a cross-departmental collaborative approval digital processing method based on blockchain and smart contracts.

[0056] Figure 2 This is a diagram illustrating a verifiable credential.

[0057] Figure 3 This is a diagram showing a status marked as pending pre-review.

[0058] Figure 4 A diagram illustrating the generation of a W3C VC standard verifiable credential. Detailed Implementation

[0059] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0060] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0061] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0062] Reference Figures 1-4 This is one embodiment of the present invention, which provides a cross-departmental collaborative approval digital processing method based on blockchain and smart contracts, including the following steps:

[0063] S1. Submit approval materials through the front-end application, convert the approval materials into standardized JSON format data and generate data fingerprints, write the data fingerprints into the blockchain and generate NFTs with a status of pending pre-approval.

[0064] S1.1 Upload the approval documents through the front-end interface, temporarily store the approval documents in the distributed storage node, use the document parsing tool to process the temporary files, convert image materials into readable text, and obtain standardized JSON format data.

[0065] Furthermore, after the approval document is uploaded to the front-end interface, it is temporarily stored on a distributed storage node, which returns a unique content identifier for the stored file. A document parsing tool reads the approval document from the distributed storage node. For image-based materials, an optical character recognition engine is used to convert the text content in the image into UTF-8 encoded plain text. For PDF and document-based files, the original text content is extracted. The extracted text content is then structured according to a predefined JSON Schema specification, including field name standardization, value type conversion, and null value handling, generating standardized JSON format data.

[0066] S1.2 Input standardized JSON format data into the classification model to generate structured data.

[0067] Furthermore, standardized JSON format data is input into a classification model. The model performs feature extraction and classification on the text fields within the JSON data. Feature extraction includes term frequency-inverse document frequency vectorization of the text content, named entity recognition (NAME) algorithms to extract key entity information, and the classification model performs multi-class predictions based on a predefined set of approval type labels, outputting an approval type string. The structured data is composed of the original standardized JSON format data and the approval type string output by the classification model, forming an enhanced JSON structure containing the original fields and classification results.

[0068] It should be noted that the classification model is fine-tuned using a pre-trained language model based on the Transformer architecture, and the training data includes manually annotated approval type labels from historical approval documents.

[0069] S1.3 Construct a hash tree for the structured data, use the SHA3-256 algorithm to calculate the hash value of the leaf nodes, and generate data fingerprints.

[0070] Specifically, the hash expression for the leaf node is:

[0071] H l eaf=SHA3-256(fieldName+fieldValue);

[0072] Among them, H l eaf is the leaf node hash, fieldValue is the standardized JSON format data, and fieldName is the name of the JSON field.

[0073] Specifically, the parent node hash expression is:

[0074] H p arent=SHA3-256(leftChildHash+||rightChildHash);

[0075] Among them, H p arent is the hash of the parent node, rightChildHash is the hash of the right child node of the current node, and leftChildHash is the hash of the left child node of the current node.

[0076] Specifically, the data fingerprint expression is as follows:

[0077] Hash t otal=SHA3-512(RootHash+MetadataHash);

[0078] Among them, Hash t otal is the data fingerprint, RootHash is the root hash value of the Merkle tree, and MetadataHash is the hash value of the metadata.

[0079] S1.4. Based on the uploaded approval documents, obtain the user's identity identifier through digital wallet authorization.

[0080] Furthermore, after uploading the approval documents and generating standardized JSON format data through the front-end interface, the system calls the Web3.js interface provided by the digital wallet to initiate an identity authentication request. The digital wallet pops up a signature dialog box, requiring the user to sign a specific message containing a hash value of standardized JSON format data. The user completes the ECDSA signature operation using the private key stored in the digital wallet, and the front-end recovers the user's identity identifier in the Ethereum address format by verifying the signature.

[0081] S1.5 The front end uses smart contracts to write data fingerprints and user identity identifiers into the blockchain and trigger contract events.

[0082] Furthermore, the front-end connects to the blockchain network through the Web3.js library, calls the write method defined in the pre-deployed smart contract, and passes the data fingerprint and user identity as parameters to the smart contract. When the smart contract is executed, it stores the data fingerprint in a bytes32 type state variable on the chain and the user identity in an address type state variable. After storage is completed, a contract event containing the data fingerprint, user identity, and current block timestamp is triggered.

[0083] S1.6. Cast ERC-721S standard NFTs through smart contracts, with metadata links pointing to stored approval information and the status marked as pending pre-approval.

[0084] Furthermore, the smart contract executes the ERC-721S standard minting function to generate new non-fungible tokens. The token metadata links to the approval document content and standardized JSON format data stored in the distributed storage nodes. The token's status field is set to pending pre-approval. During the minting process, a Transfer event conforming to the ERC-721S standard specification is triggered.

[0085] S2. The smart contract retrieves the list of departments involved in the approval process based on the approval type field in the standardized JSON format data, verifies the validity of the approval authority NFT of each department, and generates an encrypted pre-approval task package.

[0086] S2.1 The smart contract parses the approvalType field in the standardized JSON data to obtain the current business category for approval, outputs the approval type string, queries the on-chain department registry contract based on the approval type string, obtains the list of participating approval department addresses, and outputs the department address array.

[0087] Furthermore, during smart contract execution, the `approvalType` field in the standardized JSON data is first parsed. A string matching algorithm compares the field value with a predefined list of approval business categories to determine the current approval's category and outputs the corresponding approval type string. The smart contract then calls the department registry contract deployed on the blockchain, querying the `mapping` type data structure maintained in the department registry contract with the approval type string as a parameter. This retrieves all approval department addresses associated with that approval type, returning an array of department addresses in the format `address[]`. The address mapping relationships in the department registry contract are pre-set through on-chain governance mechanisms, with each approval type string corresponding to a verified list of department addresses. During the query process, the smart contract verifies that the address array returned by the department registry contract is not empty and that each address conforms to the Ethereum address format specification, ensuring that subsequent processing can obtain a valid set of approval departments.

[0088] S2.2 Based on the department address array, check the approval right NFT held by each address to obtain a valid subset of department addresses that have passed the verification.

[0089] Furthermore, the smart contract iterates through each Ethereum address in the department address array, calling the ERC-721S standard `balanceOf` function to query the number of approval-right NFTs held by each address. For addresses with a greater than zero number of NFTs held, it further calls the `ownerOf` function of the approval-right NFT contract to verify NFT ownership. The smart contract checks the expiration field in the approval-right NFT metadata to ensure it has not expired, and verifies that the permission bitmap contains the operation permissions required for the current approval type. Department addresses that pass all verifications are added to the valid department address subset. The following addresses are excluded during the generation of the valid department address subset: addresses that do not hold approval-right NFTs, addresses that hold expired approval-right NFTs, and addresses whose permission bitmaps do not contain the permissions required for the current approval type. The metadata stored in the approval-right NFT contract includes verification elements such as the permission bitmap, expiration timestamp, and issuing authority signature.

[0090] S2.3. Based on the permission bitmap of the valid department address subset, filter the fields that the valid departments can access from the JSON data to obtain the data subset after field filtering.

[0091] Furthermore, the smart contract reads the permission bitmap stored in the NFT metadata corresponding to each address in the subset of valid department addresses. It performs a bitwise AND operation between the permission bitmap and the standardized JSON data field access control list to determine the specific set of fields accessible to each valid department address. The smart contract iterates through all fields of the standardized JSON data, checking for the corresponding access permission bit in the permission bitmap for each field. Only the field content corresponding to the set permission bit is retained, generating a field-filtered data subset for each valid department address. During field filtering, the hierarchical structure and field types of the original standardized JSON data are preserved to ensure that the data subset remains in valid JSON format. Each bit in the permission bitmap corresponds to the access permission of a predefined field in the standardized JSON data; for example, bit 0 corresponds to the applicantName field, and bit 1 corresponds to the approvalType field. The smart contract maintains a complete audit log of field access during field filtering, recording the specific list of fields accessed by each valid department address.

[0092] S2.4 Obtain the public key from the NFT metadata, encrypt the data subsets after field filtering, and use the BFV homomorphic encryption method of the SEAL library to obtain the encrypted data packet.

[0093] Furthermore, the smart contract extracts the RSA public key corresponding to each valid department address from the approval authority NFT metadata, and converts each field value in the filtered data subset into BigInteger format. A BFV homomorphic encryption scheme implemented using the SEAL library is employed, setting the polynomial modulus to 4096 and the plaintext modulus to a 1024-bit prime number, performing independent encryption on each field value. The encryption process first generates a random polynomial and calculates its ciphertext component. The plaintext polynomial is then encrypted using the public key from the approval authority NFT, outputting BFV ciphertext containing two polynomial components. After performing the same encryption operation on all fields in the filtered data subset, the ciphertext of each field is combined with the field name to generate an encrypted data packet conforming to JSON format.

[0094] S2.5. Generate a zero-knowledge proof in Groth16 format based on the encrypted data packet, verify that the encrypted data packet conforms to the value range of the original JSON data, and obtain the proof document and data integrity commitment.

[0095] Furthermore, the smart contract uses the Merkle root hash of the encrypted data packet and the original standardized JSON data as public input to construct a Groth16 zero-knowledge proof circuit. The circuit internally verifies that the ciphertext of each field in the encrypted data packet corresponds to the plaintext value of the corresponding field in the original JSON data, and that the plaintext value is within a predefined range (e.g., numeric fields are in the range [0, 100]). The proof generation process is implemented using the libsnark library, expressing the field value range verification logic through R1 CS constraints, and generating a proof file containing three elliptic curve points π_A, π_B, and π_C. The data integrity commitment is generated by the logical AND operation of the Merkle tree path verification result and the field range verification result output by the circuit, in the form of a SHA256 hash of the boolean value true. The verification key for the Groth16 proof is pre-deployed on the chain. When the smart contract calls the verification function, it passes in the proof file and the public input. After successful verification, it returns the data integrity commitment. The circuit design includes verification of the BFV encryption parameters of the SEAL library to ensure that the ciphertext is generated using the correct public key and parameters.

[0096] S2.6 Combine the encrypted data packet, zero-knowledge proof, approval type string, and Merkle root hash into a structured task package, and generate an encrypted pre-approval task package by calculating the task ID using a hash algorithm.

[0097] Specifically, the expression is,

[0098] taskId = SHA3(A+T);

[0099] Where taskId is the task ID, A is the approval type, and T is the timestamp;

[0100] S3. Use a fully homomorphic encryption algorithm to encrypt the encrypted pre-approval task package, perform encrypted compliance processing, and generate joint approval middleware.

[0101] S3.1 The smart contract parses the encrypted pre-approval task package, extracts the exclusive encrypted data blocks and corresponding zero-knowledge proof files of each department, obtains structured encrypted data, calls the zk-SNARK verification contract for the encrypted data of each approval department, forms a valid zero-knowledge proof and associated Merkle root hash, and obtains a set of encrypted data that has passed verification.

[0102] Furthermore, the smart contract parses the JSON structure in the cryptographic pre-audit task package, separating the unique cryptographic data block corresponding to each department address and the associated Groth16 format zero-knowledge proof file. The smart contract traverses the list of department addresses, extracts the corresponding zero-knowledge proof file for each department's cryptographic data block, and calls the zk-SNARK verification contract pre-deployed on the blockchain. The verification contract receives the Merkle root hash of the cryptographic data block as public input, verifies whether the three elliptic curve points π_A, π_B, and π_C in the Groth16 proof file satisfy the pairing equation, and verifies that the Merkle root hash associated with the proof is consistent with the root hash recorded in the cryptographic pre-audit task package. Cryptographic data blocks that pass verification are marked as valid and added to the cryptographic data set, while data blocks that fail verification are discarded. During the verification process, the zk-SNARK verification contract uses a pre-compiled verification key to perform elliptic curve pairing operations to check the validity of the proof. The verification result of each cryptographic data block is recorded on the chain, forming a complete audit trail. The cryptographic data set that passes verification maintains the original JSON structure and only contains the cryptographic data blocks that have been successfully verified from all departments.

[0103] S3.2. Based on the encrypted data packet, generate an executable encrypted runtime environment, obtain the initialized homomorphic state, process the encrypted data packet in the homomorphic calculator, obtain the Boolean result, decrypt the encrypted state result using private key fragmentation for each department, generate decryption parameters, aggregate the decryption parameters through the Lagrange interpolation algorithm, and obtain a readable compliance verification result.

[0104] Furthermore, the smart contract initializes the homomorphic encryption runtime environment based on the SEAL library, configures BFV parameters consistent with the encrypted data packets, loads the encrypted data packets of each department into the homomorphic calculator, executes predefined compliance calculation logic, and generates a boolean result in the encrypted state. Each department holding the NFT with approval authority uses its bound private key fragment to perform partial decryption operations on the encrypted result. Each department generates a decryption response containing partial decryption parameters and zero-knowledge proofs. After collecting the decryption responses from all departments, the smart contract verifies the zero-knowledge proofs to ensure the correctness of the decryption parameters and uses the Lagrange interpolation algorithm to calculate the aggregation result over a finite field. For the t-of-n threshold scheme, when more than the threshold t of valid decryption parameters are collected, the smart contract recovers the compliance verification result in plaintext form. During the decryption process, the private key fragments of each department are always kept in the hardware security module, and only the partial decryption parameters of the encrypted signature are output. The compliance verification result, along with the list of addresses of the departments participating in the decryption, is recorded on the blockchain, forming an immutable audit record.

[0105] S3.3. Generate a joint approval middleware from the initialized homomorphic parameters, partially decrypted parameters, and readable compliance verification results.

[0106] Furthermore, the smart contract combines the initialized SEAL library homomorphic encryption runtime environment parameters, partial decryption parameters provided by each department (including department addresses, partial decryption values, and associated zero-knowledge proofs), and the plaintext compliance verification results recovered through the Lagrange interpolation algorithm to generate a joint approval middleware. The joint approval middleware is stored in a JSON-LD format structure and contains three main parts: a homomorphic environment configuration section that records BFV scheme parameters and computation metadata; a decryption parameter section that stores all valid partial decryption parameters and verification proofs indexed by department address; and a result section that stores the final compliance verification result, a list of participating departments, and a timestamp. The smart contract calculates a SHA3-256 hash value for the joint approval middleware as an integrity check code to ensure that the middleware is not tampered with in subsequent processes. The partial decryption parameters of each department in the joint approval middleware remain in an encrypted signature state. The signature is generated using the private key bound to the approval right NFT of each department, and its authenticity can be verified through the corresponding public key.

[0107] S4. The smart contract uses the private key bound to the approval authority NFT to sign the joint approval middleware.

[0108] S4.1. By parsing the joint approval middleware through smart contracts, check the validity of the aggregation results and zero-knowledge decryption proof, obtain the verified middleware data, use the private key bound to the approval right NFT to generate random numbers, form elliptic curve commitment points and temporary identifiers, and obtain signature initialization parameters.

[0109] Furthermore, the smart contract parses the aggregation result field and zero-knowledge decryption proof file in the joint approval middleware, calls the on-chain verification function to check whether the elliptic curve pairing equation of the zero-knowledge proof holds, and confirms that the aggregation result is consistent with the commitment in the decryption proof. The middleware data that passes the verification is marked as valid. The smart contract reads the secp256k1 curve private key bound in the approval right NFT metadata, generates a cryptographically secure random number as a temporary private key, and calculates the corresponding elliptic curve public key as the commitment point.

[0110] Specifically, the expression is,

[0111] K = k * G;

[0112] Where K is the commitment point, k is a random number, and G is the curve base point.

[0113] It should be noted that the commitment point is combined with the hash value of the token_id of the approval right NFT to generate a temporary identifier. The final output contains the commitment point, the temporary identifier and a random number. The random number in the signature initialization parameters is encrypted and temporarily stored in memory and is only used for the current signature session. The commitment point is recorded on the blockchain through the event log for subsequent verification.

[0114] S4.2. The smart contract records the valid commitments to the on-chain storage by broadcasting commitment points and temporary identifiers through the P2P network, obtains the set of registered commitments, signs the middleware hash using private key shards, generates signature shares, and obtains the cryptographic signature shards.

[0115] Furthermore, the elliptic curve commitment point and temporary identifier are broadcast to all participating department nodes via a P2P network. After the department nodes verify the validity of the commitment point, the smart contract associates the verified commitment point K with the token_id of the corresponding approval right NFT and stores it in the on-chain mapping table, forming a set of registered commitments. Each department uses the private key fragment bound to the approval right NFT to perform threshold signature on the SHA3-256 hash value of the joint approval middleware. The Shamir secret sharing scheme is used to generate a (t,n) threshold signature share. Each signature share, together with the corresponding commitment point and department address, constitutes an encrypted signature fragment. The encrypted signature fragment is transmitted after being encrypted with RSA-OAEP using the recipient's public key.

[0116] S4.3 The smart contract calculates dynamic weights based on the signature response time of each department to obtain a weighted signature validity list.

[0117] Specifically, the expression is,

[0118]

[0119] Where weight is the dynamically adjusted effective weight, baseWeight is the base weight value, delay is the actual time elapsed from the approval request to the completion of the signature, and τ is the base weight. max This is the maximum response latency threshold.

[0120] S5. Collect signatures that meet the threshold conditions and generate a risk analysis request packet.

[0121] S5.1 The smart contract collects valid signature fragments that satisfy the t-of-n threshold, calculates the aggregate signature through Lagrange interpolation, and obtains the final aggregate signature.

[0122] Specifically, the expression is,

[0123] S=∑(s i weight i );

[0124] Where S is the final aggregate signature, and weight i Let s be the dynamic weight of the i-th approval department. i This is a partial signature generated for the i-th approval department, where i is the index of the approval department.

[0125] S5.2 Package the middleware data, departmental signature fragments, aggregated signatures, and timestamps to generate a standardized risk analysis request package.

[0126] Furthermore, the smart contract will collect all departmental cryptographic signature shards and the final aggregated signature from the complete middleware data collection in the joint approval middleware, as well as the timestamp of the current block, and structure them according to the predefined JSON Schema specification. The risk analysis request package organizes data in the JSON format standardized by RFC 8259, containing four top-level fields: the middleware_data field stores the Base64 encoding of the original middleware data; the signature_shards field stores the array of cryptographic signature shards indexed by department address; the aggregated_signature field stores the aggregated signature in elliptic curve point format; and the timestamp field records the UTC timestamp in ISO 8601 format. The smart contract uses the SHA3-256 hash value of the risk analysis request package as an integrity check code, and the check code is submitted to on-chain storage along with the request package. The cryptographic signature shards in the risk analysis request package are kept in RSA-OAEP encrypted state, and only the target analysis node holding the corresponding private key can decrypt them.

[0127] S6. The risk analysis request package is input into the neural network model deployed in the smart contract for real-time risk analysis, generating a risk disposal report and a plaintext approval letter respectively.

[0128] S6.1 Extract the signature data, middleware content, and timestamp from the risk analysis request packet through the smart contract to obtain structured analysis data.

[0129] Furthermore, the smart contract parses the JSON structure in the risk analysis request packet, extracting the encrypted signature shard array stored in the `signature_shards` field, the Base64-encoded middleware content stored in the `middleware_data` field, and the ISO 8601 format timestamp recorded in the `timestamp` field. The encrypted signature shard array is restored to its original data structure by department address index, with each element containing the department address, RSA-OAEP encrypted signature share, and associated commitment point. The Base64-encoded middleware content is decoded to restore the original joint approval middleware data, including the homomorphic environment configuration segment, decryption parameter segment, and result segment. The extracted signature data, middleware content, and timestamp are reorganized according to a predefined analysis data schema to generate structured analysis data with three levels: the first level is signature metadata (aggregated signature, list of signature shards for each department), the second level is middleware parsing data (compliance verification results, list of participating departments), and the third level is time characteristics (block timestamp, signature time dispersion).

[0130] S6.2. Based on structured analysis data, extract signature time dispersion, approval conflict index, and historical risk records, and generate a feature standardization vector through Min-Max normalization.

[0131] Furthermore, the signature time dispersion is derived from the standard deviation of the signature shard timestamps of each department, and the approval conflict index is calculated based on the number of disagreements in the past 10 joint approvals by the current approval department combination according to historical on-chain data. The historical risk record query shows the proportion of high-risk approvals by the initiator address in the past 30 days. Each feature value is normalized by Min-Max. The signature time dispersion is normalized to the range of [0,1] with a maximum allowable delay of 300 seconds. The approval conflict index is normalized with a maximum of 5 historical conflicts as the upper limit, and the historical risk record is normalized with a maximum of 100%. The three normalized feature values ​​are combined in a fixed order to form a three-dimensional feature normalized vector [dispersion, conflict index, risk record].

[0132] The standardized feature vector is input into the lightweight ONNX model deployed by the compilation contract, and forward computation is performed through the Sigmoid approximation function to obtain the risk probability value.

[0133] Specifically, the expression is,

[0134]

[0135] Where p is the risk probability value, b is the bias term, n is the total dimension of the feature vector, j is the feature dimension index, and w j Let x' be the weight parameter for the j-th feature dimension. j is the original feature value of the j-th feature dimension;

[0136] S6.3 Calculate the risk threshold dynamically based on the urgency of the approval to obtain the current decision threshold.

[0137] Specifically, the expression is,

[0138] threshold=baseThrehsold+trustScore*0.1-urgency*0.05;

[0139] Where threshold is the risk threshold, baseThreshold is the basic risk threshold, trustScore is the credit score, and urgency is the urgency of the approval process.

[0140] S6.4. Compare the risk probability value with the dynamic threshold to classify low, medium and high risk levels and obtain level labels.

[0141] Furthermore, the smart contract compares the risk probability value with the dynamic decision threshold and generates a risk level label according to the predefined interval division rules. When the risk probability value is less than 0.3 times the dynamic decision threshold, it is marked as low risk; when the risk probability value is between 0.3 and 0.7 times the dynamic decision threshold, it is marked as medium risk; and when the risk probability value is greater than 0.7 times the dynamic decision threshold, it is marked as high risk. The risk level label is stored in string format.

[0142] S6.5. Based on the grade label, use generateReport to generate a risk management report, use issueApproval to issue a digital approval document that conforms to the W3C VC standard, and generate a plain text approval document.

[0143] Furthermore, the smart contract calls the generateReport function based on the risk level label, reads the list of approval departments, compliance verification results, and risk characteristic values ​​from the structured analysis data, and generates a risk disposal report containing three chapters: risk level description, disposal suggestions, and approval basis, according to a predefined report template. The report is stored in Markdown format. At the same time, the smart contract executes the issueApproval function, which constructs a data structure that conforms to the W3C verifiable credential standard, including fields such as credential identifier, issuer, holder, risk level label, validity date, and cryptographic signature. The smart contract's private key is used to perform ECDSA-SHA256 signature on the credential to generate a digital approval certificate.

[0144] The plaintext approval document consists of a risk management report and a digital approval document, encapsulated in JSON-LD format. It includes an @context field pointing to the W3C VC and the ontology definition of risk management. The digital signature in the plaintext approval document is generated using the secp256k1 curve, and the signature value is contained in the proof field. The verification method points to the on-chain smart contract address. The management recommendations in the risk management report are dynamically generated based on the risk level label. For example, recommendations triggered by high risk levels require manual review, while recommendations generated by low risk levels are automatically approved. The plaintext approval document and the risk analysis request package are associated through a Merkle root hash to ensure the verifiability of the approval process.

[0145] S7. Smart contracts synchronize plaintext approval documents and risk disposal reports to relevant business chains through cross-chain protocols to generate verifiable credentials.

[0146] S7.1 The plaintext approval document extracted by the smart contract is compressed and encrypted using the Zstandard algorithm to obtain a standardized cross-chain data packet.

[0147] Furthermore, the smart contract reads the plaintext approval document JSON-LD data, calls the Zstandard compression algorithm (compression level set to 3) to perform binary compression on the text content, and encrypts the compressed data using the AES-256-GCM algorithm. The encryption key is dynamically generated by the smart contract and encapsulated into the data packet. The standardized cross-chain data packet is organized in TLV (Type-Length-Value) format, containing four fields: the type field identifies the data packet version (e.g., 0x01 indicates the approval result type), the length field records the number of bytes of compressed data, the value field stores the encrypted Zstandard compressed data, and the checksum field is the CRC32 checksum value of the entire data packet. The AES-256-GCM algorithm used for encryption is accompanied by a 12-byte randomly generated initialization vector and a 16-byte authentication tag to ensure data confidentiality and integrity.

[0148] S7.2. Based on the globally unique registration identifier of the blockchain network, obtain the source chain ID and the target chain ID, and generate a serial number based on the auto-incrementing counter maintained by the smart contract.

[0149] Furthermore, the smart contract queries the blockchain network registry for the globally unique identifier of the current chain, which serves as the source chain ID. Based on the target business chain name specified in the plaintext approval document, it queries the corresponding target chain ID from the cross-chain routing contract. The smart contract accesses an internally maintained uint256 type auto-incrementing counter (initial value 1, incrementing by 1 with each call), combines the current counter value with the block height to generate a sequence number. The sequence number format is block height - counter value. The source chain ID and target chain ID are stored using a standardized format defined by the network registry; for example, the Ethereum mainnet ID is 1, and the Polygon chain ID is 137. The incrementing operation of the auto-incrementing counter is completed in the same atomic transaction as the cross-chain data packet generation, ensuring that the sequence number is globally unique and continuous. The sequence number, source chain ID, and target chain ID combine to form a unique tracking identifier for cross-chain transactions, establishing a bidirectional index relationship with the standardized cross-chain data packet. The chain ID mapping table maintained in the cross-chain routing contract is updated through on-chain governance mechanisms, containing metadata such as identifiers of participating chains, a list of validator nodes, and communication protocols.

[0150] S7.3. Encapsulate the encrypted data packet with the source chain ID, target chain ID, and sequence number into an IBC data structure to obtain the cross-chain packet to be transmitted.

[0151] Furthermore, the smart contract encapsulates the standardized cross-chain data packet, source chain ID, target chain ID, and generated sequence number into a cross-chain packet to be transmitted, according to the core specifications of the IBC protocol. The cross-chain packet is organized using the Protocol Buffers serialization format and contains five fields: the header field stores byte arrays of the source chain ID and target chain ID; the sequence field records the BigEndian encoding of the sequence number; the data field stores the raw bytes of the standardized cross-chain data packet in TLV format; the timestamp field writes the Unix nanosecond format of the current block timestamp; and the proof field reserves 32 bytes for subsequent filling of Merkle proofs.

[0152] During the encapsulation process, the smart contract derives the SHA-256 hash value of the data field as a content integrity checksum. This checksum is combined with the sequence number to generate a unique identifier for the cross-chain packet. The byte layout of the cross-chain packet strictly follows the message structure specified by the IBC ICS-20 standard. The header field adopts the chain ID encoding rules of the ICS-23 standard to ensure interoperability between different chains. The cross-chain packet to be transmitted and the plaintext approval document on the source chain establish a bidirectional index through the sequence number. The index relationship is recorded in the type state variable of the smart contract. After the cross-chain packet is encapsulated, the IBC standard SendPacket event is triggered. The event log contains the cross-chain packet identifier, source chain ID, and target chain ID.

[0153] S7.4 Based on the relay node, listen to the source chain events, submit the IBC packet and Merkle proof to the target chain, and obtain the data packet to be verified by the target chain.

[0154] Furthermore, the relay node continuously listens for the IBC standard SendPacket event triggered by the source chain smart contract. After capturing the cross-chain packet identifier contained in the event log, it requests the complete IBC cross-chain packet data from the source chain full node. It then calls the getProof method of the source chain light client, using the block height and storage path of the cross-chain packet as parameters, to generate a Merkle proof containing the cross-chain packet data. The proof format follows the standard Merkle proof structure specified in ICS-23. The relay node constructs a transaction message compatible with the target chain, combining the original IBC cross-chain packet data, the Merkle proof, and the latest block header of the source chain into a verification data packet.

[0155] The data packet is submitted to the `recvPacket` function of the target chain's smart contract via the target chain's RPC interface. Upon receiving the verification data packet, the target chain's smart contract temporarily stores it in the `pending_packages` mapping table, generating a record of the target chain's pending verification data packet containing the cross-chain packet identifier, source chain ID, and arrival timestamp. The pending verification data packet is marked as unverified, awaiting cross-chain validity verification by the target chain's validator. During the submission process, the relay node verifies the initial consistency between the Merkle proof and the source chain block header, ensuring that invalid proofs are not forwarded to the target chain. The target chain's pending verification data packet retains the complete original IBC cross-chain packet byte data for subsequent verification stages.

[0156] S7.5. Based on the data packet to be verified on the target chain, after determining its validity, store it in the on-chain receiving queue and obtain a verification success event.

[0157] Furthermore, to verify the validity of the Merkle proof and the source chain block header, the `verifyMembership` method of the light client contract is called to check whether the cross-chain packet data actually exists in the state tree of the specified block on the source chain. After successful verification, the smart contract parses the header field of the IBC cross-chain packet, confirms that the source chain ID and the target chain ID match the current chain configuration, and checks whether the sequence number in the `sequence` field meets the expected value (i.e., it is 1 greater than the previously successfully received sequence number). After all validity verifications pass, the smart contract writes the decompressed standardized cross-chain data packet into the on-chain receiving queue. The queue is stored in the contract storage using a FIFO structure. Each data packet entry contains the source chain ID, sequence number, Zstandard compressed data, and arrival timestamp. The smart contract triggers the `PacketReceived` event as a successful verification event. The event parameters include the cross-chain packet identifier, the source chain ID, and the timestamp of the verified block. The successful verification event is written to the blockchain log, and the latest verified sequence number state variable of the source chain stored on the target chain is updated. Standardized cross-chain data packets in the receive queue remain encrypted, awaiting decryption and use in subsequent processing. Failure at any step during the verification process will trigger a verification failure event and discard the data packets to be verified.

[0158] S7.6. After successfully verifying the event through the target chain parsing, a structured certificate ontology is generated according to the W3C VC standard, resulting in an unsigned certificate draft. The target chain smart contract signs the certificate draft to generate a verifiable certificate.

[0159] Furthermore, the target chain smart contract listens for the PacketReceived event, extracts the successfully verified standardized cross-chain data packets from the receiving queue, decrypts and decompresses the Zstandard compressed data using the AES-256-GCM algorithm, and recovers the original JSON-LD data of the plaintext approval document. The smart contract constructs a structured certificate ontology according to the W3C verifiable certificate standard. The issuer field records the DID identifier of the target chain smart contract, the issuanceDate field records the certificate generation time in ISO 8601 format, and the credentialSubject field embeds the approval result and risk level label from the plaintext approval document, forming an unsigned certificate draft. The smart contract uses a secp256k1 elliptic curve private key to perform ECDSA signing on the normalized JSON string of the certificate draft, writes the signature value to the proof field, and records the signing time in the created field, generating a complete verifiable certificate.

[0160] This embodiment also provides a computer device applicable to the cross-departmental collaborative approval digital processing method based on blockchain and smart contracts, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to realize the cross-departmental collaborative approval digital processing method based on blockchain and smart contracts as proposed in the above embodiment.

[0161] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0162] This embodiment also provides a storage medium storing a computer program. When executed by a processor, the program implements the cross-departmental collaborative approval digital processing method based on blockchain and smart contracts as proposed in the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0163] In summary, this invention involves submitting approval materials through a front-end application and converting them into standardized JSON format data. After generating a data fingerprint, the data is written to the blockchain and a pre-approval NFT is created. The smart contract retrieves a list of relevant departments based on the approval type and verifies the validity of the approval authority NFT. An encrypted pre-approval task package is generated, and a fully homomorphic encryption algorithm is used to perform encrypted compliance calculations on the task package. A joint approval middleware is generated, and each approval department uses its NFT-bound private key to sign the middleware. After collecting threshold signatures, the smart contract generates a risk analysis request package. Real-time risk analysis is performed using a neural network model deployed in the smart contract, and a risk disposal report or plaintext approval document is output. The results are synchronized to the relevant business chain through a cross-chain protocol, and verifiable credentials are generated.

[0164] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A cross-departmental collaborative approval digital processing method based on blockchain and smart contracts, characterized by: include, The application submits approval materials through a front-end application, converts the materials into standardized JSON format data and generates a data fingerprint, writes the data fingerprint into the blockchain and generates an NFT with a status of pending pre-approval. The smart contract retrieves the list of departments involved in the approval process based on the approval type field in the standardized JSON format data, verifies the validity of the approval authority NFT of each department, and generates an encrypted pre-approval task package. The encrypted pre-approval task package is encrypted using a fully homomorphic encryption algorithm, encrypted compliance calculation is performed, and joint approval middleware is generated. The smart contract uses the private key bound to the approval authority NFT to sign the joint approval middleware for each approval department, collects signatures that meet the threshold conditions, and generates a risk analysis request package. The risk analysis request package is input into the neural network model deployed in the smart contract for real-time risk analysis, generating a risk disposal report and a plaintext approval letter respectively; Smart contracts synchronize plaintext approval documents and risk disposal reports to relevant business chains via cross-chain protocols, generating verifiable credentials. The front end uses smart contracts to write data fingerprints and user identity identifiers into the blockchain and trigger contract events; The front-end connects to the blockchain network through the Web3.js library, calls the write method defined in the pre-deployed smart contract, and passes the data fingerprint and user identity as parameters to the smart contract. When the smart contract is executed, it stores the data fingerprint in a bytes32 type state variable on the chain and the user identity in an address type state variable. After storage is completed, a contract event containing the data fingerprint, user identity, and current block timestamp is triggered.

2. The cross-departmental collaborative approval digital processing method based on blockchain and smart contracts as described in claim 1, characterized in that: The process involves submitting approval materials through a front-end application, converting these materials into standardized JSON format data and generating a data fingerprint. This data fingerprint is then written to the blockchain, creating an NFT with a pending pre-approval status. The steps include: Upload the approval documents through the front-end interface, temporarily store the approval documents in the distributed storage node, use the document parsing tool to process the temporary files, convert image materials into readable text, and obtain standardized JSON format data; Standardized JSON format data is input into the classification model to generate structured data; A hash tree is constructed from the structured data, and the hash value of the leaf nodes is calculated using the SHA3-256 algorithm to generate data fingerprints; Based on the uploaded approval documents, user identity is obtained through digital wallet authorization; The front end uses smart contracts to write data fingerprints and user identity identifiers into the blockchain and trigger contract events; NFTs conforming to the ERC-721S standard are minted through smart contracts, with metadata links pointing to stored approval information and marked as pending pre-approval.

3. The cross-departmental collaborative approval digital processing method based on blockchain and smart contracts as described in claim 2, characterized in that: The smart contract retrieves the list of departments involved in the approval process based on the approval type field in the standardized JSON format data, verifies the validity of the approval authority NFTs for each department, and generates an encrypted pre-approval task package, including the following steps: The smart contract parses the approvalType field in the standardized JSON data to obtain the current business category for approval, outputs the approval type string, queries the on-chain department registry contract based on the approval type string, obtains the list of participating approval department addresses, and outputs an array of department addresses. Based on the department address array, examine the approval authority NFT held by each address to obtain a valid subset of department addresses that have passed verification; Based on the permission bitmap of the valid department address subset, filter the fields that the valid departments can access from the JSON data to obtain the data subset after field filtering; Obtain the public key from the NFT metadata, encrypt the data subsets after field filtering, and use the BFV homomorphic encryption method of the SEAL library to obtain the encrypted data packet; Zero-knowledge proofs in Groth16 format are generated based on encrypted data packets. The encrypted data packets are verified to conform to the value range of the original JSON data, and proof documents and data integrity commitments are obtained. The encrypted data packet, zero-knowledge proof, approval type string, and Merkle root hash are combined into a structured task package, and the task ID is calculated using a hash algorithm to generate an encrypted pre-approval task package.

4. The cross-departmental collaborative approval digital processing method based on blockchain and smart contracts as described in claim 3, characterized in that: The encrypted pre-approval task package is encrypted using a fully homomorphic encryption algorithm, and encrypted compliance processing is performed to generate joint approval middleware. This includes the following steps: The smart contract parses the encrypted pre-approval task package, extracts the exclusive encrypted data blocks and corresponding zero-knowledge proof files of each department, obtains structured encrypted data, calls zk-SNARK to verify the encrypted data of each approval department, forms a valid zero-knowledge proof and associated Merkle root hash, and obtains a set of encrypted data that has passed verification. Based on the encrypted data packet, an executable encrypted runtime environment is generated, and the homomorphism is initialized. The encrypted data packet is processed in the homomorphism calculator to obtain a Boolean result. The encrypted result is decrypted by each department using private key fragmentation to generate decryption parameters. The decryption parameters are aggregated by the Lagrange interpolation algorithm to obtain a readable compliance verification result. The initialized homomorphic parameters, partially decrypted parameters, and readable compliance verification results are used to generate a joint approval middleware.

5. The cross-departmental collaborative approval digital processing method based on blockchain and smart contracts as described in claim 4, characterized in that: The smart contract allows the approval department to sign the joint approval middleware using the private key bound to the approval authority NFT, including the following steps. By parsing the joint approval middleware through smart contract, the validity of the aggregation result and zero-knowledge decryption proof is checked to obtain the verified middleware data. Random numbers are generated using the private key bound to the approval right NFT to form elliptic curve commitment points and temporary identifiers, and signature initialization parameters are obtained. By broadcasting commitment points and temporary identifiers through the P2P network, the smart contract records valid commitments to on-chain storage, obtains a set of registered commitments, uses private key shards to sign the middleware hash, generates signature shares, and obtains cryptographic signature shards. The smart contract calculates dynamic weights based on the signature response time of each department to obtain a weighted list of signature validity.

6. The cross-departmental collaborative approval digital processing method based on blockchain and smart contracts as described in claim 5, characterized in that: Collect signatures that meet the threshold conditions and generate a risk analysis request packet. Includes the following steps, The smart contract collects valid signature fragments that satisfy the t-of-n threshold, calculates the aggregate signature using Lagrange interpolation, and obtains the final aggregate signature. The middleware data, departmental signature fragments, aggregated signatures, and timestamps are packaged to generate a standardized risk analysis request package.

7. The cross-departmental collaborative approval digital processing method based on blockchain and smart contracts as described in claim 6, characterized in that: The risk analysis request package is input into a neural network model deployed in a smart contract for real-time risk analysis, generating a risk mitigation report and a plaintext approval document, including the following steps. Structured analysis data is obtained by extracting the signature data, middleware content, and timestamp from the risk analysis request packet using smart contracts. Based on structured analysis data, signature time dispersion, approval conflict index, and historical risk records are extracted, and feature standardization vectors are generated through Min-Max normalization. The standardized feature vector is input into the lightweight ONNX model deployed by the compilation contract, and the forward computation is performed through the Sigmoid approximation function to obtain the risk probability value. The risk threshold is dynamically calculated based on the urgency of the approval process to obtain the current decision threshold; By comparing risk probability values ​​with dynamic thresholds, low, medium, and high risk levels are classified to obtain level labels; Based on the rating labels, generate risk management reports using generateReport, issueApproval to issue digital approval documents conforming to W3C VC standards, and generate plaintext approval documents.

8. The cross-departmental collaborative approval digital processing method based on blockchain and smart contracts as described in claim 7, characterized in that: Smart contracts synchronize plaintext approval documents and risk management reports to relevant business chains via cross-chain protocols, generating verifiable credentials, including the following steps: The smart contract extracts the plaintext approval document, compresses and encrypts it using the Zstandard algorithm, and obtains a standardized cross-chain data packet. Based on the globally unique registration identifier of the blockchain network, the source chain ID and target chain ID are obtained, and a serial number is generated based on the auto-incrementing counter maintained by the smart contract; Encapsulate the encrypted data packet with the source chain ID, target chain ID, and sequence number into an IBC data structure to obtain the cross-chain packet to be transmitted; Based on the relay node listening to source chain events, IBC packets and Merkle proofs are submitted to the target chain to obtain the data packet to be verified on the target chain; Based on the data packet to be verified on the target chain, after determining its validity, it is stored in the on-chain receiving queue, and a verification success event is obtained. By parsing and verifying the successful event on the target chain, a structured certificate ontology is generated according to the W3C VC standard, resulting in an unsigned certificate draft. The target chain smart contract then signs the certificate draft to generate a verifiable certificate.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the steps of the cross-departmental collaborative approval digital processing method based on blockchain and smart contracts as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the steps of the cross-departmental collaborative approval digital processing method based on blockchain and smart contracts as described in any one of claims 1 to 8.

Images