Cross-department collaborative approval digital processing method based on block chain and smart contract

Abstract

The invention discloses a cross-department collaborative approval digital processing method based on a block chain and a smart contract, and relates to the technical field of block chains, and the method comprises the steps: submitting an approval material through a front-end application, converting the approval material into standardized JSON format data, generating a data fingerprint, writing the data fingerprint into a block chain, and generating an NFT in a to-be-pre-audited state; the intelligent contract retrieves a list of departments participating in examination and approval according to examination and approval type fields in the standardized JSON format data, verifies the validity of the examination and approval right NFT of each department, and generates an encrypted pre-examination task package; and encrypting the encrypted pre-auditing task package by using a fully homomorphic encryption algorithm. The risk analysis request packet is generated after the threshold signature is collected through the smart contract, real-time risk analysis is performed through the neural network model deployed in the smart contract, the risk disposal report or the plaintext approval document is output, the result is synchronized to the related service chain through the cross-chain protocol, and the verifiable certificate is generated.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchains, and in particular to a cross-department collaborative approval digital processing method based on blockchains and smart contracts. BACKGROUND

[0002] Currently, the cross-department collaborative approval process between government departments and enterprises generally adopts a combination of centralized databases and manual audits. A unified approval data platform is established to centrally manage the approval rules and data of each department. After the application materials are identified by OCR, they are stored in a relational database and routed to the corresponding department for manual review according to the preset process. A role-based access control mechanism is usually used to achieve data isolation between departments by assigning different permission levels. In terms of data security, the existing technology combines transport layer encryption and database field-level encryption to ensure the confidentiality of the approval information during transmission and storage. The hash value of the approval result is stored on the chain to enhance the traceability of the process.

[0003] However, the existing technical system still has room for improvement in balancing cross-department data collaboration and secure computing. When multiple departments are involved in parallel approval, the traditional solution requires 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 context of joint construction project approval, the environmental protection department needs to check pollution indicators, and the fire department needs to evaluate evacuation passage design. Although the encrypted data obtained by the two departments is isolated by permission, the data preprocessing before encryption and key management still rely on centralized institutions, making it difficult to completely eliminate the possibility of internal personnel exceeding their authority. SUMMARY

[0004] In view of the above existing problems, the present application is proposed.

[0005] Therefore, the present application provides a cross-department collaborative approval digital processing method based on blockchains and smart contracts, which solves the privacy leakage risk problem caused by data duplication and distribution and centralized key management in traditional solutions.

[0006] To solve the above technical problems, the present application provides the following technical solutions:

[0007] In a first aspect, the present application provides a cross-department collaborative approval digital processing method based on blockchains and smart contracts, which includes 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 a blockchain and generating an NFT with a status of pending pre-approval;

[0008] The smart contract retrieves the department list involved in the approval according to the approval type field in the standardized JSON format data, and verifies the validity of the department approval right NFT, and generates an encrypted pre-approval task package.

[0009] The encrypted pre-audit task package is encrypted using a homomorphic encryption algorithm, a compliance calculation in an encrypted state is performed, and a joint approval middleware is generated;

[0010] The smart contract signs the joint approval middleware using the private key bound to the approval right NFT of each approval department, collects signatures that meet the threshold condition, and generates a risk analysis request package;

[0011] The risk analysis request package is input into a neural network model deployed in the smart contract for real-time risk analysis, and a risk disposal report and a plaintext approval letter are generated respectively; the smart contract synchronizes the plaintext approval letter and the risk disposal report to the related business chain through a cross-chain protocol to generate a verifiable credential.

[0012] As a preferred scheme of the cross-department collaborative approval digital processing method based on blockchain and smart contract, the application comprises the following steps of:

[0013] The approval file is uploaded through the front-end interface, the approval file is temporarily stored in the distributed storage node, the document parsing tool is used to process the temporary storage file, the image type material is converted into readable text, and the standardized JSON format data is obtained;

[0014] The standardized JSON format data is input into a classification model to generate structured data;

[0015] A hash tree is constructed for the structured data, and a leaf node hash value is calculated using a SHA3-256 algorithm to generate a data fingerprint;

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

[0017] The front-end uses the smart contract to write the data fingerprint and the user identity into the blockchain, and triggers the contract event;

[0018] An NFT of the ERC-721S standard is minted through the smart contract, the metadata link points to the stored approval information, and the state is marked as pending pre-audit.

[0019] As a preferred scheme of the cross-department collaborative approval digital processing method based on blockchain and smart contract, the application comprises the following steps of:

[0020] The smart contract parses an approvalType field in the standardized JSON data, obtains a current business classification of approval, outputs an approval type string, queries a department registration table contract on a chain according to the approval type string, obtains an address list of participating approval departments, and outputs a department address array;

[0021] Based on the department address array, the holding approval right NFT of each address is checked to obtain a valid department address subset that passes the verification;

[0022] According to the permission bitmap of the valid department address subset, the fields accessible by the valid departments are filtered from the JSON data to obtain a data subset after field filtering;

[0023] The public key is obtained from the NFT metadata, and the data subset after field filtering is encrypted respectively, and the BFV homomorphic encryption method of the SEAL library is used to obtain an encrypted data packet;

[0024] Based on the encrypted data packet, a Groth16 format zero-knowledge proof is generated to verify that the encrypted data packet meets the value range of the original JSON data, and a proof file and a data integrity commitment are obtained;

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

[0026] As a preferred scheme of the cross-department collaborative approval digital processing method based on a blockchain and a smart contract, wherein: a full homomorphic encryption algorithm is used to encrypt the encrypted pre-examination task package, and an encrypted compliance processing is performed to generate a joint approval middleware, including the following steps,

[0027] The smart contract parses the encrypted pre-examination task package, extracts the exclusive encrypted data block of each department and the corresponding zero-knowledge proof file, obtains structured encrypted data, calls a zk-SNARK verification contract for the encrypted data of each approval department, forms a zero-knowledge proof that is valid and associated with a Merkle root hash, and obtains a set of encrypted data that passes the verification;

[0028] Based on the encrypted data packet, an executable encrypted runtime environment is generated, a homomorphism is obtained after initialization, the encrypted data packet is processed in a homomorphism calculator, a Boolean result is obtained, the encrypted state result is decrypted using a private key fragment for each department, decryption parameters are generated, the decryption parameters are aggregated through a Lagrange interpolation algorithm, and a readable compliance verification result is obtained;

[0029] The initialized homomorphism, the partial decryption parameters and the readable compliance verification result are used to generate the joint approval middleware.

[0030] As a preferred scheme of the cross-department collaborative approval digital processing method based on blockchain and smart contract, wherein the smart contract uses the private key bound with the approval right NFT to sign the joint approval middleware, including the following steps,

[0031] The joint approval middleware is parsed by the smart contract, the validity of the aggregation result and the zero-knowledge decryption proof is checked, the middleware data that passes the verification is obtained, a random number is generated using the private key bound with the approval right NFT, an elliptic curve commitment point and a temporary identifier are formed, and signature initialization parameters are obtained;

[0032] The commitment point and the temporary identifier are broadcasted through the P2P network, the smart contract records the valid commitment on the chain for storage, obtains a registered commitment set, signs the middleware hash using the private key slice, generates a signature share, and obtains an encrypted signature slice;

[0033] The smart contract calculates the dynamic weight according to the response time of the signature of each department, and obtains a weighted signature validity list.

[0034] As a preferred scheme of the cross-department collaborative approval digital processing method based on blockchain and smart contract, wherein the signature satisfying the threshold condition is collected to generate a risk analysis request package, including the following steps,

[0035] The smart contract collects the valid signature slices satisfying the t-of-n threshold, calculates the aggregated signature through Lagrange interpolation, and obtains the final aggregated signature;

[0036] The middleware data, the signature slices of each department, the aggregated signature, and the timestamp are packaged to generate a standardized risk analysis request package.

[0037] As a preferred scheme of the cross-department collaborative approval digital processing method based on blockchain and smart contract, wherein the risk analysis request package is input into a neural network model deployed in the smart contract for real-time risk analysis, and a risk disposal report and a plaintext approval letter are generated, including the following steps,

[0038] The signature data, the middleware content, and the timestamp in the risk analysis request package are extracted by the smart contract to obtain structured analysis data;

[0039] The signature time dispersion, the approval conflict index, and the historical risk record are extracted based on the structured analysis data, and the feature standardization vector is generated through Min-Max normalization;

[0040] The feature standardization vector is input into a lightweight ONNX model deployed by the compiled contract, and forward calculation is performed through a Sigmoid approximation function to obtain a risk probability value;

[0041] According to the dynamic calculation of the risk threshold according to the approval urgency, the current decision threshold is obtained;

[0042] The risk probability value is compared with the dynamic threshold, and the low, medium and high risk levels are divided to obtain the level label;

[0043] Based on the level label, the risk disposal report is generated using generateReport, and the digital approval in accordance with the W3C VC standard is issued using issueApproval, and the plaintext approval is generated.

[0044] As a preferred scheme of the cross-department collaborative approval digital processing method based on blockchain and smart contract, wherein: the smart contract synchronizes the plaintext approval and the risk disposal report to the related business chain through the cross-chain protocol, and generates a verifiable credential, including the following steps,

[0045] The smart contract extracts the plaintext approval, compresses and encrypts it through 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 the target chain ID are obtained, and based on the self-incrementing counter maintained by the smart contract, a serial number is generated;

[0047] The encrypted data packet, the source chain ID, the target chain ID and the serial number are encapsulated into an IBC data structure to obtain a cross-chain packet to be transmitted;

[0048] Based on the relay node listening to the source chain event, the IBC packet and the Merkle proof are submitted to the target chain to obtain a data packet to be verified by the target chain;

[0049] Based on the data packet to be verified by the target chain, the validity is obtained, and the data packet is stored on the chain receiving queue, and a verification success event is obtained;

[0050] The target chain analyzes the verification success event, generates a structured credential ontology according to the W3C VC standard, obtains an unsigned credential draft, and the target chain smart contract signs the credential draft to generate a verifiable credential,

[0051] In a second aspect, the present application provides a computer device comprising a memory and a processor, the memory storing a computer program, wherein: the computer program is executed by the processor to implement any step of the cross-department collaborative approval digital processing method based on blockchain and smart contract according to the first aspect of the present application.

[0052] In a third aspect, the present application provides a computer readable storage medium having a computer program stored thereon, wherein: the computer program is executed by the processor to implement any step of the cross-department collaborative approval digital processing method based on blockchain and smart contract according to the first aspect of the present application.

[0053] The application has the beneficial effects that: by submitting the approval materials through the front-end application and converting them into standardized JSON format data, writing the data fingerprints into the blockchain and creating the NFT to be pre-approved, the smart contract searches the relevant department list according to the approval type and verifies the validity of the approval right NFT, generates an encrypted pre-approval task package, uses the fully homomorphic encryption algorithm to perform compliance calculation on the task package, generates a joint approval middleware, each approval department uses the NFT binding private key to sign the middleware, the smart contract collects the threshold signature to generate a risk analysis request package, performs real-time risk analysis through the neural network model deployed in the smart contract, outputs the risk disposal report or the plaintext approval, and synchronizes the result to the relevant business chain through the cross-chain protocol and generates the verifiable credential. BRIEF DESCRIPTION OF DRAWINGS

[0054] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0055] Fig. 1 The flowchart of the cross-department collaborative approval digital processing method based on blockchain and smart contract.

[0056] Fig. 2 The schematic diagram of the verifiable credential.

[0057] Fig. 3 The schematic diagram of the state marked as to be pre-approved.

[0058] Fig. 4 The schematic diagram of generating the W3C VC standard verifiable credential. DETAILED DESCRIPTION

[0059] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the specific embodiments of the present application will be described in detail below with reference to the drawings of the specification.

[0060] In the following description, many specific details are set forth in order to provide a thorough understanding of the present application, but the present application can also be implemented in other ways different from those described herein, and those skilled in the art can make similar generalizations without departing from the connotation of the present application, therefore the present application is not limited to the specific embodiments disclosed below.

[0061] Second, the "one embodiment" or "an embodiment" referred to herein can include a particular feature, structure, or characteristic. The various embodiments appearing at different places in this specification can not all refer to the same embodiment or to the same implementations or alternatives of the same implementation.

[0062] Referring to Figs. 1-4 For one embodiment of the present application, the embodiment provides a cross-department collaborative approval digital processing method based on blockchain and smart contract, including the following steps:

[0063] S1, submit the 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 NFT with a state of pending pre-examination.

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

[0065] Further, after uploading the approval file through the front-end interface, the approval file is transmitted to the distributed storage node for temporary storage, and the distributed storage node returns a unique content identifier for file storage. The document parsing tool reads the approval file in the distributed storage node, calls an optical character recognition engine to convert the text content in the picture into pure text in UTF-8 encoding for image materials, extracts the original text content for PDF and document files, and structures the extracted text content according to the predefined JSON Schema specification, including field name standardization, value type conversion and null value processing, to generate standardized JSON format data.

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

[0067] Further, the standardized JSON format data is input into the classification model, the classification model performs feature extraction and classification processing on the text fields in the JSON format data, the feature extraction process includes term frequency-inverse document frequency vectorization processing of text content, named entity recognition algorithm to extract key entity information, the classification model according to the pre-defined approval type label set, multi-classification prediction is carried out on the extracted features, and the approval type string is output. 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 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 a Transformer architecture, and the training data contains manually labeled approval type labels in historical approval files.

[0069] S1.3, construct a hash tree for structured data, calculate the leaf node hash value using SHA3-256 algorithm, and generate a data fingerprint.

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

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

[0072] Where 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] Where H p arent is the parent node hash, rightChildHash is the hash value of the right child node of the current node, and leftCHildHash is the hash value of the left child node of the current node.

[0076] Specifically, the data fingerprint expression is,

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

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

[0079] S1.4, based on the uploaded approval file, obtain the user identity through digital wallet authorization.

[0080] Further, after completing the upload of the approved file and generating standardized JSON format data through the front-end interface, the Web3.js interface provided by the digital wallet is called to initiate an identity authentication request. The digital wallet pops up a signature dialog box to require the user to sign a specific message containing the hash value of the standardized JSON format data. The user completes the ECDSA signature operation using the private key stored in the digital wallet. The front-end verifies the signature to recover the user identity identifier in the format of an Ethereum address.

[0081] S1.5, the front-end uses the smart contract to write the data fingerprint and user identity identifier into the blockchain, triggering the contract event.

[0082] Further, the front-end connects to the blockchain network through the Web3.js library and calls the write method defined in the pre-deployed smart contract, passing the data fingerprint and user identity identifier as parameters into the smart contract. The smart contract stores the data fingerprint in the bytes32 type state variable on the chain and the user identity identifier in the address type state variable. After completing the storage, it triggers a contract event containing the data fingerprint, user identity identifier, and current block timestamp.

[0083] S1.6, cast NFT of ERC-721S standard through smart contract, metadata link points to stored approval information, and marks the state as pending pre-examination.

[0084] Further, the smart contract executes the casting function of the ERC-721S standard to generate a new non-fungible token. The token metadata links to the approval file content and standardized JSON format data stored in the distributed storage node. The state field in the token attribute is set to pending pre-examination. The casting process triggers the Transfer event conforming to the ERC-721S standard specification.

[0085] S2, the smart contract retrieves the department list participating in the approval according to the approval type field in the standardized JSON format data, and verifies the validity of each department's approval right NFT, and generates an encrypted pre-examination task package.

[0086] S2.1, the smart contract parses the approvalType field in the standardized JSON data to obtain the current business classification of the approval, outputs the approval type string, queries the department registration contract on the chain according to the approval type string, obtains the address list of the participating approval departments, and outputs the department address array.

[0087] Further, the smart contract first parses the approvalType field content in the standardized JSON data when executing, and compares the field value with the pre-defined approval business classification list through a string matching algorithm to determine the business classification of the current approval and output the corresponding approval type string. The smart contract then calls the department registry contract deployed on the blockchain to query the mapping type data structure maintained in the department registry contract with the approval type string as a parameter, obtain all approval department addresses associated with the approval type, and return a department address array in the format of address[]. The address mapping relationship in the department registry contract is pre-set through on-chain governance mechanism, and each approval type string corresponds to a verified department address list. During the query process, the smart contract verifies that the address array returned by the department registry contract is non-empty and each address conforms to the Ethereum address format specification, ensuring that the 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 subset of valid department addresses that pass the verification.

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

[0090] S2.3, according to the permission bitmap of the subset of valid department addresses, filter the fields accessible by the valid departments from the JSON data to obtain a subset of data after field filtering.

[0091] Further, the smart contract reads the permission bitmap stored in the approval right NFT metadata corresponding to each address in the effective department address subset, performs a bitwise AND operation between the permission bitmap and the standardized JSON data field access control list, determines the specific field set accessible by each effective department address, and traverses all fields of the standardized JSON data. For each field, check if the corresponding access permission bit in the permission bitmap is set. Only the field content corresponding to the set permission bit is retained to generate a field-filtered data subset for each effective department address. The hierarchical structure and field type of the original standardized JSON data are preserved during field filtering to ensure that the data subset is still a 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, the 0th bit corresponds to the applicantName field and the 1st bit corresponds to the approvalType field. The smart contract maintains a complete audit record of field access when performing field filtering, recording the specific field list accessed by each effective department address.

[0092] S2.4, obtain the public key from the NFT metadata, respectively encrypt the field-filtered data subset, use the BFV homomorphic encryption method of the SEAL library to obtain the encrypted data packet.

[0093] Further, the smart contract extracts the RSA public key corresponding to each effective department address from the approval right NFT metadata and converts each field value in the field-filtered data subset to BigInteger format. The BFV homomorphic encryption scheme implemented by the SEAL library is used to set the polynomial modulus number to 4096 and the plaintext modulus to a 1024-bit prime number. Each field value is independently encrypted. The encryption process first generates a random polynomial and calculates the ciphertext component, encrypts the plaintext polynomial using the public key in the approval right NFT, and outputs a BFV ciphertext containing two polynomial components. After performing the same encryption operation on all fields in the field-filtered data subset, combine the field ciphertext with the field name to generate an encrypted data packet in JSON format.

[0094] S2.5, generate a Groth16 format zero-knowledge proof based on the encrypted data packet, verify that the encrypted data packet meets the value range of the original JSON data, and obtain a proof file and a data integrity commitment.

[0095] Further, the smart contract takes the encrypted data packet and the Merkle root hash of the original standardized JSON data as public input, constructs a Groth16 zero-knowledge proof circuit, verifies the ciphertext of each field in the encrypted data packet corresponding to the plaintext value of the corresponding field in the original JSON data inside the circuit, and the plaintext value is within the predefined value range (for example, the numerical field is within the interval [0, 100]), the proof generation process is implemented using the libsnark library, the field value range verification logic is expressed by R1CS constraints, a proof file containing three elliptic curve points π_A, π_B, and π_C is generated, 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, and the form is a SHA256 hash of the Boolean value true, the verification key of the Groth16 proof is pre-deployed on the chain, the smart contract calls the verification function by inputting the proof file and the public input, and returns the data integrity commitment after verification. The circuit design includes verification of the SEAL library BFV encryption parameters 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-audit task package by calculating the task ID through a hash algorithm.

[0097] Specifically, the expression is,

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

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

[0100] S3, encrypt the encrypted pre-audit task package using a fully homomorphic encryption algorithm, perform compliance processing in an encrypted state, and generate a joint approval middleware.

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

[0102] Further, the smart contract parses the JSON structure in the encrypted pre-audit task package, separates the exclusive encrypted data block corresponding to each department address and the associated Groth16 format zero-knowledge proof file, and traverses the department address list. The smart contract extracts the corresponding zero-knowledge proof file for each department's encrypted data block and calls the zk-SNARK verification contract pre-deployed on the blockchain. The verification contract receives the Merkle root hash of the encrypted data block as the 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 associated Merkle root hash is consistent with the root hash recorded in the encrypted pre-audit task package. The encrypted data block that passes the verification is marked as valid and added to the encrypted data set, and the data block that fails the verification is discarded. During the verification process, the zk-SNARK verification contract uses pre-compiled verification keys to perform elliptic curve pairing operations to check the validity of the proof. The verification result of each encrypted data block is recorded on the chain to form a complete audit trail. The encrypted data set that passes the verification maintains the original JSON structure and only contains the encrypted data blocks that pass the verification in all departments.

[0103] S3.2, based on the encrypted data package, an executable encrypted runtime environment is generated, and a homomorphic initialization is completed. The encrypted data package is processed in the homomorphic calculator to obtain a Boolean result. The private key fragments of each department are used to decrypt the encrypted state result to generate decryption parameters. The decryption parameters are aggregated by the Lagrange interpolation algorithm to obtain a readable compliance verification result.

[0104] Further, the smart contract initializes the homomorphic encryption runtime environment based on the SEAL library, configures the BFV parameters consistent with the encrypted data package, loads the encrypted data package of each department in the homomorphic calculator, executes the predefined compliance calculation logic, generates the encrypted state Boolean result, and uses the bound private key fragments of each department holding the approval right NFT to perform partial decryption operations on the encrypted state result. Each department generates a decryption response containing partial decryption parameters and zero-knowledge proof. After the smart contract collects all department decryption responses, it verifies the zero-knowledge proof to ensure the correctness of the decryption parameters, and uses the Lagrange interpolation algorithm to calculate the aggregation result on the finite field. For the t-of-n threshold scheme, when more than threshold t valid decryption parameters are collected, the smart contract restores the compliance verification result in plaintext form. During the decryption process, the private key fragments of each department remain in the hardware security module, and only the partially decrypted parameters with encrypted signatures are output. The compliance verification result and the department address list participating in the decryption are recorded on the blockchain to form an unalterable audit record.

[0105] S3.3, the initialized homomorphism, partial decryption parameters, and readable compliance verification result are used to generate a joint approval middleware.

[0106] Further, the smart contract combines the initialized SEAL library homomorphic encryption runtime environment parameters, the partial decryption parameters provided by each department (including department address, partial decryption value and associated zero-knowledge proof), and the plaintext compliance verification results recovered through the Lagrange interpolation algorithm to generate a joint approval middleware. The joint approval middleware is structured and stored in JSON-LD format, including three main parts: the homomorphic environment configuration section records the BFV scheme parameters and calculation metadata; the decryption parameter section stores all valid partial decryption parameters and verification proofs according to department address; and the result section stores the final compliance verification results, participating department list and timestamp. The smart contract calculates the SHA3-256 hash value of 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, and the signature is generated using the private key bound to the approval right NFT of each department, which can be verified for authenticity through the corresponding public key.

[0107] S4, the smart contract signs the joint approval middleware using the private key bound to the approval right NFT of the approval department.

[0108] S4.1, parse the joint approval middleware through the smart contract, check the validity of the aggregation result and zero-knowledge decryption proof, get the verified middleware data, generate a random number using the private key bound to the approval right NFT, form an elliptic curve commitment point and a temporary identifier, get the signature initialization parameters.

[0109] Further, 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 is established, 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 a commitment point,

[0110] Specifically, the expression is,

[0111] K = k * G;

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

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

[0114] S4.2, broadcast the commitment point and the temporary identifier through the P2P network, record the valid commitment to the on-chain storage by the smart contract, get the registered commitment set, sign the middleware hash using the private key shard to generate the signed share, and get the encrypted signature shard.

[0115] Further, the elliptic curve commitment point and the temporary identifier are broadcast to all participating department nodes through the P2P network, the department nodes verify the validity of the commitment point, the smart contract stores the verified commitment point K and the corresponding approval right NFT token_id in the on-chain mapping table, forms the registered commitment set, and each department uses the private key shard bound to the approval right NFT to threshold sign the SHA3-256 hash value of the joint approval middleware, uses the Shamir secret sharing scheme to generate (t, n) threshold signature shares, each signature share and the corresponding commitment point, department address constitute an encrypted signature shard, and the encrypted signature shard is transmitted after being encrypted using the receiver's public key.

[0116] S4.3, the smart contract calculates the dynamic weight according to the response time of each department signature, and gets the weighted signature validity list.

[0117] Specifically, the expression is,

[0118]

[0119] Wherein, weight is the dynamically adjusted effective weight, baseWeight is the basic weight value, delay is the actual time consumption from the approval request to the completion of the signature, τ max is the maximum response delay threshold.

[0120] S5, collect the signatures that meet the threshold condition to generate a risk analysis request package.

[0121] S5.1, the smart contract collects the valid signature shards that meet the t-of-n threshold, calculates the aggregated signature by Lagrange interpolation, and gets the final aggregated signature.

[0122] Specifically, the expression is,

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

[0124] Wherein, S is the final aggregated signature, weight i is the dynamic weight of the i-th approval department, s i is the partial signature generated by the i-th approval department, and i is the approval department index.

[0125] S5.2, Pack the middleware data, department signature shards, aggregated signature and timestamp to generate a standardized risk analysis request package.

[0126] Further, the smart contract will encrypt and sign all department shards of the complete middleware data collected in the joint approval middleware and the final aggregated signature, as well as the timestamp of the current block, and pack them according to the predefined JSON Schema specification. The risk analysis request package uses the RFC 8259 standardized JSON format to organize data, containing four top-level fields: the middleware_data field stores the Base64 encoded original middleware data; the signature_shards field stores the encrypted signature shard array 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, which is submitted to the chain together with the request package. The encrypted signature shards in the risk analysis request package remain in RSA-OAEP encrypted state and can only be decrypted by the target analysis node holding the corresponding private key.

[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.

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

[0129] Further, the smart contract parses the JSON structure in the risk analysis request package, extracts 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 indexed by department address and restored to the original data structure, each element containing a department address, a RSA-OAEP encrypted signature share and an associated commitment point. The Base64 encoded middleware content is restored to the original joint approval middleware data by decoding, containing the homomorphic environment configuration segment, the decryption parameter segment and the result segment. The extracted signature data, middleware content and timestamp are reorganized according to the predefined analysis data Schema to generate structured analysis data containing three levels: the first level is the signature metadata (aggregated signature, list of department signature shards), the second level is the middleware analysis data (compliance verification result, list of participating departments), and the third level is the time feature (block timestamp, signature time dispersion).

[0130] S6.2, based on structured analysis data, signature time dispersion, approval conflict index, historical risk record are extracted, and feature standardization vector is generated through Min-Max normalization.

[0131] Further, the signature time dispersion is obtained by the standard deviation of the signature timestamp of each department, the approval conflict index is obtained according to the historical on-chain data, and the number of times of disagreement in the past 10 times of joint approval of the current approval department combination is obtained; the historical risk record queries the high-risk approval proportion of the initiator address in the past 30 days, and each feature value is processed by Min-Max normalization. The signature time dispersion is normalized to the interval [0, 1] according to the maximum allowed delay of 300 seconds, the approval conflict index is normalized with the maximum conflict number of 5 times as the upper limit, the historical risk record is normalized with 100% as the upper limit, and the three normalized feature values are combined into a three-dimensional feature standardization vector [dispersion, conflict index, risk record] in a fixed order.

[0132] The feature standardization vector is input into the lightweight ONNX model deployed by the compiled contract, and the forward calculation 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 number of the feature vector, j is the feature dimension index, w j is the weight parameter of the jth feature dimension, and x' j is the original feature value of the jth feature dimension.

[0136] S6.3, according to the approval urgency, the risk threshold is dynamically calculated, and the current decision threshold is obtained.

[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 approval urgency,

[0140] S6.4, compare the risk probability value with the dynamic threshold, and divide the low, medium and high risk levels to obtain the grade label.

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

[0142] S6.5, based on the level label, using generateReport to generate a risk disposal report, using issueApproval to issue a digital approval in accordance with the W3C VC standard, and generating a plaintext approval.

[0143] Further, the smart contract calls the generateReport function according to the risk level label, reads the approval department list, compliance verification result and risk characteristic value in the structured analysis data, generates a risk disposal report containing three chapters of risk level description, disposal suggestion and approval basis according to the predefined report template, and the report is stored in Markdown format. At the same time, the smart contract executes the issueApproval function, which constructs a data structure conforming to the W3C verifiable credential standard, including fields such as credential identifier, issuer, holder, risk level label, validity date and encrypted signature, and uses the private key of the smart contract to perform ECDSA-SHA256 signature on the credential to generate a digital approval;

[0144] The plaintext approval is composed of the risk disposal report and the digital approval, packaged in JSON-LD format, containing the @context field pointing to the ontology definition of W3C VC and risk management, the digital signature in the plaintext approval is generated through 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 disposal suggestion in the risk disposal report is dynamically generated according to the risk level label, for example, the high risk level triggers the manual review suggestion, and the low risk level generates the automatic pass suggestion, and the plaintext approval and the risk analysis request package are associated through the Merkle root hash to ensure the verifiability of the approval process.

[0145] S7, the smart contract synchronizes the plaintext approval and the risk disposal report to the related business chain through the cross-chain protocol to generate a verifiable credential.

[0146] S7.1, the smart contract extracts the plaintext approval, compresses and encrypts it through the Zstandard algorithm, and obtains a standardized cross-chain data package.

[0147] Further, the smart contract reads the plaintext approval note JSON-LD data, calls the Zstandard compression algorithm (compression level set to 3) to perform binary compression on the text content, and the compressed data is encrypted by the AES-256-GCM algorithm. The encryption key is dynamically generated by the smart contract and packaged into the data packet. The standardized cross-chain data packet adopts the TLV (Type-Length-Value) format organization, which includes four fields: the type field identifies the data packet version (for example, 0x01 represents the approval result type), the length field records the number of compressed data bytes, 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, ensuring data confidentiality and integrity.

[0148] S7.2, based on the globally unique registration identifier of the blockchain network, the source chain ID and the target chain ID are obtained, and the sequence number is generated based on the self-incrementing counter maintained by the smart contract.

[0149] Further, the smart contract queries the globally unique identifier of the current chain in the blockchain network registry as the source chain ID; according to the target business chain name specified in the plaintext approval note, the corresponding target chain ID is queried from the cross-chain routing contract, the smart contract accesses the internally maintained uint256 type self-incrementing counter (the initial value of the counter is 1, and it is incremented by 1 each time it is called), and the current counter value and the block height are combined to generate a sequence number. The sequence number format is block height-counter value, the source chain ID and the target chain ID are stored in the standardized format defined by the network registry, for example, the Ethereum mainnet ID is 1 and the Polygon chain ID is 137. The increment operation of the self-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 form a unique tracking identifier for cross-chain transactions, and a bidirectional index relationship is established 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, including the identifiers of each participating chain, the list of validation nodes and communication protocols, and other metadata.

[0150] S7.3, the encrypted data packet is packaged 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] Further, the smart contract encapsulates the standardized cross-chain data packet, source chain ID and target chain ID, and the generated sequence number into a cross-chain packet to be transmitted according to the core specification of the IBC protocol. The cross-chain packet is organized in the Protocol Buffers serialization format and includes five fields: the header field stores the byte array of the source chain ID and the target chain ID; the sequence field records the BigEndian encoding of the sequence number; the data field stores the original bytes of the standardized cross-chain data packet in the 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 the Merkle proof.

[0152] In the encapsulation process, the smart contract derives the SHA-256 hash value of the data field as the content integrity check code, and the check code and the sequence number are combined to generate a unique identifier for the cross-chain packet. The byte layout of the cross-chain packet strictly follows the message structure specified in the IBC ICS-20 standard, and the header field uses the chain ID encoding rule specified in ICS-23 to ensure interoperability between different chains. The cross-chain packet to be transmitted and the plaintext approval on the source chain are indexed bidirectionally by the sequence number, and the index relationship is recorded in the type state variable of the smart contract. After the cross-chain packet is encapsulated, the SendPacket event of the IBC standard is triggered, and the event log includes the cross-chain packet identifier, the source chain ID and the target chain ID.

[0153] S7.4, based on the relay node listening to the source chain event, submitting the IBC packet and the Merkle proof to the target chain to obtain the data packet to be verified by the target chain.

[0154] Further, the relay node continuously listens to the IBC standard SendPacket event triggered by the source chain smart contract, and after capturing the cross-chain packet identifier contained in the event log, requests the full node of the source chain to obtain the complete IBC cross-chain packet data, calls the getProof method of the source chain light client with the block height and storage path of the cross-chain packet as parameters to generate a Merkle proof containing the cross-chain packet data, and 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, and combines the IBC cross-chain packet original data, the Merkle proof, and the latest block header of the source chain into a verification data packet;

[0155] The target chain smart contract receives the verification data packet and temporarily stores it in the pending_packages mapping table after receiving the recvPacket function submitted through the RPC interface of the target chain. The target chain generates a data packet record for verification containing the cross-chain packet identifier, source chain ID, and arrival timestamp. The status of the data packet for verification is marked as unverified, waiting for the target chain validator to perform cross-chain validity verification. The relay node verifies the Merkle proof and the preliminary consistency of the source chain block header during submission to ensure that invalid proofs are not forwarded to the target chain. The target chain data packet for verification retains the complete original IBC cross-chain packet byte data for subsequent verification steps.

[0156] S7.5, based on the target chain data packet for verification, the validity is obtained and stored in the on-chain receiving queue, and the verification success event is obtained.

[0157] Further, the validity of the Merkle proof and the source chain block header is verified, and 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 of the source chain. After verification, the smart contract parses the header field of the IBC cross-chain packet to confirm that the source chain ID and the target chain ID match the current chain configuration, and checks whether the sequence number of the sequence field meets the expected value (i.e., greater than the last successfully received sequence number by 1). After all validity verification steps are passed, the smart contract writes the decompressed and standardized cross-chain data packet into the on-chain receiving queue, which is stored in the contract storage in 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 the verification success event, and the event parameters include the cross-chain packet identifier, source chain ID, and verified block timestamp. The verification success event is written into the blockchain log, and the latest verified sequence number state variable of the source chain stored on the target chain is updated. The standardized cross-chain data packet in the receiving queue remains encrypted and waits for subsequent processing to decrypt and use. Any step failure in the verification process will trigger a verification failure event and discard the data packet for verification.

[0158] S7.6, the target chain parses the verification success event and generates a structured credential ontology according to the W3C VC standard to obtain an unsigned credential draft. The target chain smart contract signs the credential draft to generate a verifiable credential.

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

[0160] The embodiment also provides a computer device suitable for the cross-department collaborative approval digital processing method based on a blockchain and a smart contract, 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-department collaborative approval digital processing method based on a blockchain and a smart contract proposed in the above embodiment.

[0161] The computer device can be a terminal, and the computer device includes a processor, a memory, a communication interface, a display screen and an input device connected through a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operating system and the computer program in the non-volatile storage medium to run. The communication interface of the computer device is used to communicate with external terminals in a wired or wireless manner. The wireless manner can be achieved through WIFI, an operator network, NFC (near field communication) or other technologies. The display screen of the computer device can be a liquid crystal display screen or an electronic ink display screen. The input device of the computer device can be a touch layer overlaid on the display screen, or a key, trackball or touchpad arranged on the shell of the computer device. In addition, the input device can also be an external keyboard, touchpad or mouse, etc.

[0162] The embodiment also provides a storage medium on which a computer program is stored, the program being executed by a processor to implement the method for realizing cross-department collaborative approval digital processing based on a blockchain and a smart contract as proposed in the above embodiment; the storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as a static random access memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic memory, a flash memory, a magnetic disk, or an optical disk.

[0163] To sum up, the application submits the approval materials through the front-end application and converts them into standardized JSON format data, generates a data fingerprint, writes the data fingerprint into a blockchain, and creates an NFT to be pre-approved, the smart contract retrieves a list of relevant departments according to the approval type and verifies the validity of the approval right NFT, generates an encrypted pre-approval task package, performs compliance calculation on the task package in an encrypted state by using a full-homomorphic encryption algorithm, generates a joint approval middleware, each approval department signs the middleware by using an NFT-bound private key, the smart contract generates a risk analysis request package after collecting threshold signatures, performs real-time risk analysis by using a neural network model deployed in the smart contract, outputs a risk disposal report or a plaintext approval letter, and synchronizes the result to a relevant business chain through a cross-chain protocol and generates a verifiable credential.

[0164] It should be noted that the above embodiments are only used to illustrate the technical solutions of the application but not limit the application, although the application has been described in detail with reference to the preferred embodiments, it should be understood by those skilled in the art that the technical solutions of the application can be modified or replaced equivalently without departing from the spirit and scope of the technical solutions of the application, and all of them should be covered in the scope of the claims of the application.

Claims

1. A cross-departmental collaborative approval digital processing method based on blockchain and smart contracts, characterized by: comprising, The approval materials are submitted through the front-end application, the approval materials are converted into standardized JSON format data and a data fingerprint is generated, the data fingerprint is written into the blockchain and an NFT with a state of to-be-pre-audited is generated; The smart contract retrieves the department list participating in the approval according to the approval type field in the standardized JSON format data, and verifies the validity of the approval right NFT of each department, and generates an encrypted pre-audit task package; The encrypted pre-audit task package is encrypted using a fully homomorphic encryption algorithm, and an encrypted compliance calculation is performed to generate a joint approval middleware; The smart contract signs the joint approval middleware using the private key bound to the approval right NFT of each approval department, collects the signatures that meet the threshold condition, 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, and a risk disposal report and a plaintext approval letter are generated respectively; The smart contract synchronizes the plaintext approval letter and the risk disposal report to the related business chain through a cross-chain protocol to generate a verifiable credential.

2. The blockchain and smart contract-based cross-department collaborative examination and approval digital processing method according to claim 1, characterized in that: The approval materials are submitted through the front-end application, the approval materials are converted into standardized JSON format data and a data fingerprint is generated, the data fingerprint is written into the blockchain and an NFT with a state of to-be-pre-audited is generated, including the following steps, Upload the approval file through the front-end interface, temporarily store the approval file in the distributed storage node, process the temporarily stored file using a document parsing tool, convert the image type material into readable text, and obtain the standardized JSON format data; Input the standardized JSON format data into a classification model to generate structured data; Build a hash tree for the structured data, calculate the leaf node hash value using the SHA3-256 algorithm, and generate a data fingerprint; Based on the uploaded approval file, obtain the user identity through digital wallet authorization; The front-end uses the smart contract to write the data fingerprint and user identity into the blockchain, and triggers the contract event; Cast an NFT of ERC-721S standard through the smart contract, the metadata link points to the stored approval information, and marks the state as to-be-pre-audited. 3.The method of claim 2, wherein the method further comprises: The smart contract retrieves the department list participating in the approval according to the approval type field in the standardized JSON format data, and verifies the validity of the approval right NFT of each department, and generates an encrypted pre-audit task package, including the following steps, The smart contract parses the approvalType field in the standardized JSON data to obtain the current business classification, outputs an approval type string, queries the department registration contract on the chain according to the approval type string, obtains the address list of the participating approval departments, and outputs the department address array; Based on the department address array, check the approval right NFT held by each address to obtain a subset of valid department addresses that pass the verification; According to the permission bitmap of the valid department address subset, filter the fields accessible to the valid departments from the JSON data to obtain a subset of data filtered by fields; Get the public key from the NFT metadata, respectively encrypt the data subset filtered by fields, and use the BFV homomorphic encryption method of the SEAL library to obtain an encrypted data package; Generate a zero-knowledge proof in Groth16 format based on the encrypted data packet, verify that the encrypted data packet meets the value range of the original JSON data, and obtain a proof file and a data integrity commitment; 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-audit task package by calculating the task ID using a hash algorithm.

4. The blockchain and smart contract-based cross-department collaborative examination and approval digital processing method of claim 3, characterized in that: Encrypt the encrypted pre-audit task package using a fully homomorphic encryption algorithm for encrypted compliance processing, and generate a joint approval middleware, including the following steps, The smart contract parses the encrypted pre-audit task package, extracts the department's exclusive encrypted data block and corresponding zero-knowledge proof file, obtains structured encrypted data, calls the zk-SNARK verification contract for each department's encrypted data, forms a zero-knowledge proof that is valid and associated with the Merkle root hash, and obtains a set of encrypted data that passes the verification; Based on the encrypted data packet, generate an executable encrypted runtime environment, obtain an initialized homomorphism, process the encrypted data packet in the homomorphic calculator, and obtain a Boolean result. Decrypt the encrypted result using private key fragments for each department to generate decryption parameters, aggregate the decryption parameters using the Lagrange interpolation algorithm, and obtain a readable compliance verification result; Generate a joint approval middleware with the initialized homomorphism, partial decryption parameters, and readable compliance verification results. 5.The blockchain and smart contract based cross-department collaborative examination and approval digital processing method according to claim 4, characterized in that: The smart contract signs the joint approval middleware using the private key bound to the approval right NFT, including the following steps, Parse the joint approval middleware through the smart contract, check the validity of the aggregated result and zero-knowledge decryption proof, obtain the middleware data that passes the verification, generate a random number using the private key bound to the approval right NFT, form an elliptic curve commitment point and a temporary identifier, and obtain signature initialization parameters; Broadcast the commitment point and temporary identifier through the P2P network, and record the valid commitment on the chain through the smart contract to obtain a registered commitment set. Sign the middleware hash using private key fragments to generate signature shares and obtain encrypted signature fragments; The smart contract calculates dynamic weights based on the response time of each department's signature to obtain a weighted signature validity list.

6. The blockchain and smart contract-based cross-department collaborative examination and approval digital processing method of claim 5, characterized in that: Collect signatures that meet the threshold conditions to generate a risk analysis request package, Including the following steps, The smart contract collects valid signature fragments that meet the t-of-n threshold and calculates the aggregated signature through Lagrange interpolation to obtain the final aggregated signature; Pack the middleware data, department signature fragments, aggregated signature, and timestamp to generate a standardized risk analysis request package.

7. The blockchain and smart contract-based cross-department collaborative examination and approval digital processing method of claim 6, characterized in that: Input the risk analysis request package into the neural network model deployed in the smart contract for real-time risk analysis, and generate a risk disposal report and a clear approval letter, including the following steps, Extract the signature data, middleware content, and timestamp from the risk analysis request package through the smart contract to obtain structured analysis data; Extract the signature time dispersion, approval conflict index, and historical risk records from the structured analysis data, and generate a feature standardization vector through Min-Max normalization; The feature standardization vector is input into the lightweight ONNX model deployed by the compiled contract, and the forward calculation is performed through the Sigmoid approximation function to obtain a risk probability value; According to the dynamic calculation of the risk threshold according to the approval urgency, the current decision threshold is obtained; The risk probability value is compared with the dynamic threshold to divide the low, medium and high risk levels, and the grade label is obtained; Based on the grade label, the risk disposal report is generated using generateReport, and the digital approval in line with the W3C VC standard is issued using issueApproval, and the plaintext approval is generated.

8. The blockchain and smart contract-based cross-department collaborative examination and approval digital processing method of claim 7, characterized in that: The smart contract synchronizes the plaintext approval and the risk disposal report to the related business chain through the cross-chain protocol, generates a verifiable credential, including the following steps, The smart contract extracts the plaintext approval, compresses and encrypts it through 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 the target chain ID are obtained, and based on the self-incrementing counter maintained by the smart contract, a serial number is generated; The encrypted data packet, the source chain ID, the target chain ID and the serial number are encapsulated into an IBC data structure to obtain a cross-chain packet to be transmitted; Based on the relay node listening to the source chain event, the IBC packet and the Merkle proof are submitted to the target chain to obtain the data packet to be verified by the target chain; Based on the data packet to be verified by the target chain, the validity is obtained, and the data packet is stored in the on-chain receiving queue, and the verification success event is obtained; The target chain analyzes the verification success event, generates a structured credential ontology according to the W3C VC standard, obtains an unsigned credential draft, and the target chain smart contract signs the credential draft to generate a verifiable credential. 9.A computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the computer device is characterized in that: The processor executes the computer program to realize the steps of the cross-departmental collaborative approval digital processing method based on the blockchain and the smart contract of any one of claims 1-8.

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

Images