Cloud computing operation settlement platform intelligent contract processing system based on government affair system

Abstract

The invention provides a cloud computing operation settlement platform intelligent contract processing system based on a government affair system, and relates to the technical field of financial science and technology, and the method comprises the steps: a user terminal submits a structured business data body containing a business type identifier, amount information and an electronic certificate to a cloud intelligent contract; executing standardized conversion based on the structured business data volume received by the cloud smart contract, and generating an XBRL language data packet; encrypting and storing the generated XBRL data packet to a distributed storage node, and generating a unique data index; based on the unique data index, the smart contract calls a rule engine to retrieve and analyze the corresponding XBRL data packet; and according to the business type identifier in the analysis result, automatically checking the amount compliance and the authenticity of the electronic certificate. Through safety technologies such as full-process automatic execution, standardized conversion, encryption and block chain, the service period is shortened, data safety is guaranteed, and settlement is accurate.

Description

Technical Field

[0001] This invention relates to the field of financial technology, and in particular to a smart contract processing system for a cloud computing operation and settlement platform based on the government system. Background Technology

[0002] With the rapid development of financial technology, cloud computing and blockchain technologies are increasingly being used in the settlement field. However, existing settlement processing methods suffer from the following pain points: Data formats across different business platforms may be highly heterogeneous, and core data such as electronic vouchers and monetary information may lack unified semantic standards. Cross-platform collaboration requires extensive manual adaptation, potentially leading to inefficient data flow. In traditional settlement processes, some steps, such as monetary compliance verification, electronic voucher authenticity review, and approval hierarchy transfer, rely on manual operation, which is not only time-consuming but also prone to risks due to subjective bias or operational errors. Business data storage may rely on centralized servers, which may pose single points of failure risks, and data transmission and storage may be tampered with, making it difficult to ensure the credibility of critical information such as electronic vouchers and payment instructions. Key nodes in the entire settlement process (such as data submission, approval, and fund transfer) may lack immutable records, making it difficult to quickly trace responsibility in case of disputes. The matching of payment rules and business types may rely on manual configuration, potentially leading to mismatches in settlement conditions, and the ledger status may not be updated in a timely manner after fund transfer, potentially resulting in inconsistencies between accounts and actual transactions. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide a smart contract processing system for a cloud computing operation and settlement platform based on the government system. Through fully automated execution, standardized conversion, encryption and blockchain and other security technologies, it can shorten business cycles, ensure data security and achieve accurate settlement.

[0004] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows: Firstly, a smart contract processing method for a cloud computing operation and settlement platform based on the government affairs system, the method comprising: Step 1: The user terminal submits a structured business data body containing business type identifier, amount information and electronic voucher to the cloud smart contract; Step 2: Perform standardized transformation on the structured business data received by the cloud smart contract to generate XBRL language data packets; encrypt and store the generated XBRL data packets to distributed storage nodes, and generate a unique data index; Step 3: Based on the unique data index, the smart contract calls the rules engine to retrieve and parse the corresponding XBRL data packet; according to the business type identifier in the parsing result, it automatically verifies the compliance of the amount and the authenticity of the electronic voucher; when the verification is successful, it generates an approval instruction containing the data index according to the preset approval level and pushes it to the approver's terminal. Step 4: In response to the approval instruction returned by the approving terminal, the smart contract retrieves the corresponding XBRL data packet through the data index; performs block processing on the retrieved XBRL data packet, and constructs a Merkle tree structure containing leaf nodes, intermediate nodes and root nodes based on the block data, where: the leaf node is the encrypted hash value of each data block, associated with the electronic voucher metadata; the root node is the Merkle root hash value, anchored to the blockchain; Step 5: Obtain the Merkle root hash value anchored to the blockchain and compare it with the locally calculated value submitted by the approving party's terminal; after the consistency verification is passed, generate an encrypted payment voucher by matching the settlement rules according to the business type identifier; send the encrypted payment voucher to the payment execution component to trigger the fund transfer and update the distributed ledger status.

[0005] Further, in step 1, the user terminal submits a structured business data body containing a business type identifier, amount information, and electronic voucher to the cloud smart contract, including: The user terminal extracts a set of voucher feature values ​​for electronic vouchers, including the encoded sequence value of the invoice code, the binary representation of the amount, and the grayscale feature value of the voucher image; the set of voucher feature values ​​is then bound to the business type identifier and amount information to form a structured business data body. Based on the structured business data body, coefficients are assigned according to the anti-counterfeiting weight level: the highest anti-counterfeiting level coefficient is assigned to the invoice code feature, the medium anti-counterfeiting level coefficient is assigned to the amount value feature, and the basic anti-counterfeiting level coefficient is assigned to the image grayscale feature; the corresponding level coefficients are applied to the invoice code feature, the amount value feature, and the image grayscale feature respectively to generate three types of weighted feature values; The three weighted feature values ​​are XORed in a fixed order. The invoice code feature value with the highest anti-counterfeiting level weight is XORed with the amount value feature value with the medium anti-counterfeiting level weight. The result is then XORed with the image grayscale feature value with the basic anti-counterfeiting level weight to generate a checksum. When the deviation rate between the checksum and the pre-stored registration value is within an acceptable risk range, a data validity flag is generated. The response data is valid, and the structured business data body is transmitted to the cloud smart contract through an encrypted channel; The cloud-based smart contract parses the metadata attributes of the received data, generates a submission credential hash containing a timestamp and data fingerprint, and writes it into the blockchain ledger.

[0006] Further, in step 2, the structured business data received from the cloud smart contract undergoes a standardized transformation to generate an XBRL language data packet; the generated XBRL data packet is then encrypted and stored in a distributed storage node, and a unique data index is generated, including: Based on the hash of the submitted voucher, the corresponding structured business data body is retrieved from the blockchain ledger; XBRL format conversion is performed on the structured business data body: the business type identifier is mapped to XBRL classification standard elements, the amount information is converted into XBRL numerical fact values, the electronic voucher feature value set is encoded into XBRL context entities, and a standardized data package conforming to the XBRL 2.1 specification is generated. Based on the standardized data packet, an encrypted data stream is generated using a block encryption algorithm; the encrypted data stream is segmented and stored in a distributed storage node cluster, and the storage location identifiers returned by each node are received; all storage location identifiers are merged to generate a global location hash value; Based on the global location hash value and the submission credential hash, an index source string is generated by sequentially concatenating the two strings and performing two consecutive hash operations on the string. The result of the operation is written as an index value into the smart contract state database, forming a unique data index for the XBRL data packet.

[0007] Further, in step 3, based on the unique data index, the smart contract calls the rules engine to retrieve and parse the corresponding XBRL data packet; according to the business type identifier in the parsing result, it automatically verifies the compliance of the amount and the authenticity of the electronic voucher; when the verification is successful, it generates an approval instruction containing the data index according to the preset approval level and pushes it to the approver's terminal, including: Based on the unique data index, the smart contract queries the state database to obtain the XBRL data packet storage location identifier; according to the location identifier, it downloads the encrypted data stream from the distributed storage node cluster, decrypts it using a symmetric key, and reconstructs the XBRL data packet. Based on the reconstructed XBRL data packets, the business type identifier is extracted and mapped to a preset rule base to match the classification standard; the compliance threshold of the corresponding business type is dynamically called according to the matching result. Based on compliance thresholds, boundary verification is performed on the amount information in the data packet; when the amount verification passes, the overall deviation rate of the feature value set of electronic vouchers and the feature values ​​of the pre-stored registration values ​​is calculated, and a verification result code is generated, including a verification pass code and a verification failure code. When the verification result code indicates that the verification is successful, the approval level configuration table is queried according to the business type identifier to determine the approval path and time constraints. The approval instruction containing the data index, approval path and time constraints is encapsulated. The approval instruction is pushed to the approver's terminal through the blockchain event log. When the verification result code indicates that the verification is unsuccessful, the process is terminated and the abnormal status code is persistently stored in the smart contract.

[0008] Furthermore, in step 4, in response to the approval instruction returned by the approving terminal, the smart contract retrieves the corresponding XBRL data packet through the data index, including: Based on the approval instruction returned by the approving terminal, the smart contract verifies the validity of the digital signature of the instruction; when the signature is valid, the data index is extracted from the instruction; the state database is queried through the data index to obtain the distributed storage location identifier and symmetric key of the XBRL data packet; Based on the storage location identifier, download a set of encrypted data blocks from the distributed storage node cluster; decrypt each block using a symmetric key to reconstruct the complete XBRL data packet.

[0009] Furthermore, the acquired XBRL data packets are processed into blocks, and a Merkle tree structure containing leaf nodes, intermediate nodes, and a root node is constructed based on the block data. The leaf nodes are the cryptographic hash values ​​of each data block, associated with electronic certificate metadata; the root node is the Merkle root hash value, anchored to the blockchain, including: For the reconstructed XBRL data packets, data segmentation is performed according to the predefined chunk size, generating an independent set of data blocks and assigning a unique location identifier to each data block; Based on the data block set, the initial hash value of the original content of each data block is calculated block by block; the initial hash value is concatenated with the associated electronic voucher metadata, and a second hash operation is performed to generate the leaf node value of the data block; when all data blocks have been processed, a set of leaf node values ​​is formed. Based on the set of leaf node values, recursively perform the concatenation hash operation of adjacent node pairs to generate intermediate nodes until they are aggregated into a single root node value. The root node value is bound to the block metadata to generate an anchor data packet; a blockchain transaction is initiated through a smart contract to write the anchor data packet into the distributed ledger.

[0010] Further, in step 5, the Merkle root hash value anchored to the blockchain is obtained and compared with the locally calculated value submitted by the approving terminal; after the consistency verification is passed, an encrypted payment voucher is generated according to the settlement rules matched with the business type identifier; the encrypted payment voucher is sent to the payment execution component to trigger the fund transfer and update the distributed ledger state, including: Based on the ledger records anchored to the blockchain, the on-chain Merkle root hash value is read from the smart contract state database; after successful acquisition, the local Merkle root hash value is requested and received from the approval terminal; the on-chain hash value and the local hash value are converted into equal-length binary bit strings; the binary bit strings are compared bit by bit, and the number of different bits is counted to generate a Hamming distance value; when the Hamming distance value is zero, a consensus pass signal is generated. The response consistency is achieved by extracting the business type identifier from the reconstructed XBRL data packet using signals; and querying the settlement rule base based on the business type identifier to match the payment condition parameters. Based on payment condition parameters, a structured payment instruction is generated; based on the structured payment instruction, asymmetric encryption is performed using the public key registered by the payee on the blockchain to generate an encrypted payment certificate; based on the encrypted payment certificate, the certificate is submitted to the clearing network through the standardized interface protocol of the payment execution component; the fund transfer status event returned by the clearing network is monitored, and a settlement confirmation signal is generated when the event type is success. In response to the settlement confirmation signal, the original transaction status is marked as completed in the smart contract, the settlement completion timestamp and clearing network transaction ID are written, and the balance status of the associated account is updated.

[0011] Secondly, the smart contract processing system of the cloud computing operation and settlement platform based on the government system includes: The submission module is used by user terminals to submit structured business data bodies containing business type identifiers, amount information, and electronic vouchers to cloud smart contracts. The preprocessing module is used to perform standardized transformation on the structured business data body received based on the cloud smart contract, generate XBRL language data packets; encrypt and store the generated XBRL data packets to distributed storage nodes, and generate a unique data index; The processing module is used to retrieve and parse the corresponding XBRL data packet by calling the rule engine based on the unique data index; automatically verify the compliance of the amount and the authenticity of the electronic voucher according to the business type identifier in the parsing result; when the verification is successful, generate an approval instruction containing the data index according to the preset approval level and push it to the approver's terminal. The anchoring module is used to respond to the approval instruction returned by the approval terminal. The smart contract obtains the corresponding XBRL data packet through the data index; it performs block processing on the obtained XBRL data packet, and constructs a Merkle tree structure containing leaf nodes, intermediate nodes and root nodes based on the block data. Among them, the leaf node is the encrypted hash value of each data block, which is associated with the electronic voucher metadata; the root node is the Merkle root hash value, which is anchored to the blockchain. The settlement module is used to obtain the Merkle root hash value anchored to the blockchain and compare it with the locally calculated value submitted by the approval terminal. After the consistency verification is passed, it generates an encrypted payment voucher by matching the settlement rules according to the business type identifier. It then sends the encrypted payment voucher to the payment execution component to trigger the fund transfer and update the distributed ledger status.

[0012] Thirdly, a computing device includes: One or more processors; A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method.

[0013] Fourthly, a computer-readable storage medium storing a program that, when executed by a processor, implements the method.

[0014] The above-described solution of the present invention has at least the following beneficial effects: The entire process—from data submission and standardized conversion to verification and approval, and payment transfer—is automated, shortening business cycles and reducing manpower and time costs. XBRL format conversion unifies data semantics and format, breaking down cross-platform data barriers and improving collaboration efficiency across multiple platforms and institutions. Encrypted storage, distributed storage, Merkle tree verification, and blockchain anchoring technologies prevent data leakage and tampering, ensuring the integrity of core data such as electronic vouchers and payment information. The rule engine automatically verifies the compliance of amounts and the authenticity of vouchers; the approval process automatically flows based on preset levels, and key node records are written to the blockchain, achieving full traceability and transparency, and reducing operational risks. Settlement rules are dynamically matched based on business type identifiers to generate encrypted payment vouchers and automatically trigger fund transfers, ensuring accurate matching of payment conditions and business characteristics. Simultaneously, the distributed ledger updates its status in real time, ensuring consistency between accounts and actual transactions. Distributed storage and the decentralized blockchain architecture avoid single points of failure, enhancing the platform's fault tolerance. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating the smart contract processing method for a cloud computing operation and settlement platform based on the government system, provided by an embodiment of the present invention.

[0016] Figure 2 This is a schematic diagram of a smart contract processing system for a cloud computing operation and settlement platform based on the government affairs system, provided by an embodiment of the present invention. Detailed Implementation

[0017] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0018] like Figure 1 As shown, embodiments of the present invention propose a smart contract processing method for a cloud computing operation and settlement platform based on the government system. The method includes the following steps: Step 1: The user terminal submits a structured business data body containing business type identifier, amount information and electronic voucher to the cloud smart contract; Step 2: Perform standardized transformation on the structured business data received by the cloud smart contract to generate XBRL language data packets; encrypt and store the generated XBRL data packets to distributed storage nodes, and generate a unique data index; Step 3: Based on the unique data index, the smart contract calls the rules engine to retrieve and parse the corresponding XBRL data packet; according to the business type identifier in the parsing result, it automatically verifies the compliance of the amount and the authenticity of the electronic voucher; when the verification is successful, it generates an approval instruction containing the data index according to the preset approval level and pushes it to the approver's terminal. Step 4: In response to the approval instruction returned by the approving terminal, the smart contract retrieves the corresponding XBRL data packet through the data index; performs block processing on the retrieved XBRL data packet, and constructs a Merkle tree structure containing leaf nodes, intermediate nodes and root nodes based on the block data, where: the leaf node is the encrypted hash value of each data block, associated with the electronic voucher metadata; the root node is the Merkle root hash value, anchored to the blockchain; Step 5: Obtain the Merkle root hash value anchored to the blockchain and compare it with the locally calculated value submitted by the approving party's terminal; after the consistency verification is passed, generate an encrypted payment voucher by matching the settlement rules according to the business type identifier; send the encrypted payment voucher to the payment execution component to trigger the fund transfer and update the distributed ledger status.

[0019] In this embodiment of the invention, structured business data is used as input to ensure the integrity of core elements and avoid the loss of key information; XBRL standardization transformation breaks down semantic barriers between different carriers; encrypted distributed storage and generation of unique data indexes facilitate subsequent retrieval and traceability; corresponding data packets are quickly retrieved based on the unique data index, improving data retrieval efficiency; approval instructions with data indexes are generated according to preset approval levels to ensure a standardized and orderly approval process; XBRL data packets are processed in blocks and a Merkle tree is constructed, with leaf nodes enabling fine-grained data verification, ensuring that any tampering with a data block will result in a change in hash value, which can be accurately identified; the Merkle root hash is anchored to the blockchain, using the immutability of the blockchain to solidify the final state of the data, providing a reliable data benchmark for subsequent settlement; hash value comparison verifies that the root hash stored on the blockchain is consistent with the locally calculated value by the approver, ensuring that the data has not been tampered with from approval to settlement, guaranteeing the authenticity of the payment basis; encrypted payment vouchers are generated according to settlement rules matched according to business type to avoid payment rule mismatch; fund transfers are automatically triggered and the distributed ledger is updated, improving payment efficiency.

[0020] In a preferred embodiment of the present invention, step 1 above, in which the user terminal submits a structured business data body containing a business type identifier, amount information, and electronic voucher to the cloud smart contract, may include: Step 11: The user terminal extracts the set of voucher feature values ​​of the electronic voucher, including the encoded sequence value of the invoice code, the binary representation of the amount value, and the grayscale feature value of the voucher image; and binds the set of voucher feature values ​​with the business type identifier and amount information into a structured business data body. Step 12: Based on the structured business data body, assign coefficients according to the anti-counterfeiting weight level: assign the highest anti-counterfeiting level coefficient to the invoice code feature, assign the medium anti-counterfeiting level coefficient to the amount value feature, and assign the basic anti-counterfeiting level coefficient to the image grayscale feature; apply the corresponding level coefficient weighting processing to the invoice code feature, amount value feature, and image grayscale feature respectively to generate three types of weighted feature values; Step 13: Perform an XOR operation on the three weighted feature values ​​in a fixed order. XOR the invoice code feature value with the highest anti-counterfeiting level weight with the amount value feature value with the medium anti-counterfeiting level weight to obtain the result. XOR the result with the image grayscale feature value with the basic anti-counterfeiting level weight to generate a checksum. When the deviation rate between the checksum and the pre-stored registration value is within the acceptable risk range, a data validity flag is generated. Step 14: Response data validity flag, transmit the structured business data body to the cloud smart contract through an encrypted channel; Step 15: The cloud-based smart contract parses the metadata attributes of the received data, generates a submission credential hash containing a timestamp and data fingerprint, and writes it into the blockchain ledger.

[0021] In this embodiment of the invention, core features of electronic vouchers are extracted from multiple dimensions to provide a comprehensive basis for subsequent anti-counterfeiting verification, avoiding the omission of key information by a single feature; structured binding ensures a one-to-one correspondence between business data and voucher features, laying the foundation for full-process data traceability; the anti-counterfeiting priority of features is distinguished by weight levels, allowing key features such as invoice codes to play a leading role in subsequent verification; multi-dimensional features are integrated into a single checksum through XOR operation, simplifying the verification logic while leveraging the characteristics of XOR operation to quickly detect whether feature values ​​have been tampered with; the deviation rate judgment mechanism provides fault tolerance for minor errors, avoiding misjudgments and improving the reliability of verification; only verified and valid data is transmitted to avoid invalid data occupying network resources and improve transmission efficiency; encrypted channels ensure that data is not stolen or tampered with during transmission, guaranteeing the security of data from the user terminal to the cloud; timestamps record the precise time of data submission, data fingerprints ensure data uniqueness, and the submission voucher hash generated by the combination of the two can serve as digital evidence of data submission; after being written to the blockchain, the immutability of the blockchain is used to achieve permanent traceability of data submission behavior.

[0022] In this embodiment of the invention, when applied in a specific way, it can be implemented through the following technical solutions, for example: In step 11 above, the user terminal extracts three types of feature values ​​from the electronic voucher: by reading the text information of the electronic voucher, the character / numeric sequence of the invoice code is extracted in sequence (e.g., "a sequence of 10-digit codes in sequence"); the specific numerical value of the amount information (e.g., "1000 yuan") is converted into binary form (i.e., a string of numbers composed of 0 and 1); the voucher image is processed in grayscale, and the grayscale value of each pixel in the image is extracted (e.g., "values ​​from 0 to 255") and formed a continuous feature sequence; these three types of voucher feature value sets are associated and integrated with the business type identifier (e.g., "travel expense reimbursement" "equipment procurement") and the original amount information (e.g., "1000 yuan") in a fixed format to form a structured business data body (i.e., each information element is bound to a preset field to ensure mutual association).

[0023] In step 12 above, weighting coefficients are set according to the anti-counterfeiting importance of the features: the highest anti-counterfeiting level coefficient is assigned to the invoice code feature (e.g., the coefficient value is higher than the other two types, reflecting its core status as a unique identifier), the medium anti-counterfeiting level coefficient is assigned to the amount value feature (the coefficient value is between the highest and the basic), and the basic anti-counterfeiting level coefficient (the lowest coefficient value) is assigned to the image grayscale feature; the invoice code feature value is weighted by the highest level coefficient (e.g., by multiplying the values ​​to strengthen its weight in subsequent verification) to generate the invoice code weighted feature value; similarly, the amount value feature value is multiplied by the medium coefficient, and the image grayscale feature value is multiplied by the basic coefficient to generate the other two types of weighted feature values ​​respectively.

[0024] Step 13 above involves performing an XOR operation in a fixed order: the weighted feature value of the invoice code for the highest anti-counterfeiting level is XORed with the weighted feature value of the amount for the medium anti-counterfeiting level (e.g., comparing two feature values ​​bit by bit, with the same bit resulting in 0 and different bits resulting in 1, yielding an intermediate result); then the intermediate result is XORed with the image grayscale weighted feature value for the basic anti-counterfeiting level, ultimately obtaining a comprehensive checksum; the deviation ratio between this checksum and the pre-stored registration value on the platform (i.e., the standard feature verification benchmark value for this type of electronic voucher) is calculated; if the deviation rate is within the preset acceptable risk range (e.g., ≤1%), the data is deemed valid, and a data validity flag is generated.

[0025] In step 14 above, after receiving the data validity flag (i.e., confirming data compliance in step 13), the user terminal establishes a secure transmission channel through an encryption protocol (such as SSL / TLS) and transmits the structured business data body (including feature values, business identifiers, amounts, and other information) in encrypted form to the cloud smart contract through this channel (i.e., the data is encrypted during transmission and can only be decrypted and read by the cloud smart contract).

[0026] In step 15 above, after receiving the data, the cloud smart contract parses its metadata (such as the data generation time, source terminal identifier, data format, etc.); based on the parsing results, it generates a timestamp of the current time (such as a time record accurate to milliseconds) and a data fingerprint (i.e., a unique identifier obtained by hashing the structured business data body, used to distinguish different data); it integrates the timestamp and the data fingerprint to generate a submission credential hash containing both (i.e., a unique hash value obtained by hashing the timestamp and the data fingerprint); finally, it writes the submission credential hash into the blockchain ledger (i.e., it is stored on multiple nodes of the blockchain to form an immutable record).

[0027] In a preferred embodiment of the present invention, step 2 above, which involves performing a standardized transformation on the structured business data received by the cloud smart contract to generate an XBRL language data packet; encrypting and storing the generated XBRL data packet to a distributed storage node, and generating a unique data index, may include: Step 21: Based on the hash of the submitted voucher, retrieve the corresponding structured business data body from the blockchain ledger; perform XBRL format conversion on the structured business data body: map the business type identifier to XBRL classification standard elements, convert the amount information into XBRL numerical fact values, encode the electronic voucher feature value set into XBRL context entities, and generate a standardized data package that conforms to the XBRL 2.1 specification. Step 22: Based on the standardized data packet, generate an encrypted data stream using a block encryption algorithm; store the encrypted data stream in segments to a distributed storage node cluster, and receive the storage location identifiers returned by each node; merge all storage location identifiers to generate a global location hash value; Step 23: Based on the global location hash value and the submission credential hash, generate an index source string by sequentially concatenating the two strings and perform two consecutive hash operations on the string. Write the operation result as the index value into the smart contract state database to form a unique data index for the XBRL data packet.

[0028] In this embodiment of the invention, data in the blockchain is accurately retrieved by submitting credential hashes, ensuring consistency between the converted original data and the user-submitted data and preventing data tampering. XBRL standardization unifies data format and semantics, improving the efficiency of data recognition and processing across different platforms. Block encryption ensures that sensitive information in standardized data packets cannot be accessed without authorization during storage, protecting data privacy. Distributed storage node clusters disperse data blocks to avoid data loss due to single node failures. The global location hash integrates all storage location information, providing a unified identifier for quickly locating complete data and improving data retrieval efficiency. Two hash operations strengthen the uniqueness of the index value through multi-level processing. The index value is associated with the global location hash and the submission credential hash, enabling precise traceability from the index to the data packet. Writing to the smart contract state database ensures that the index value is reliably stored and can be efficiently called by smart contracts.

[0029] In this embodiment of the invention, when applied in a specific way, it can be implemented through the following technical solutions, for example: Step 21 above involves matching and retrieving the corresponding structured business data body in the blockchain ledger based on the submitted voucher hash (i.e., the "digital evidence" recorded in the blockchain). The extracted structured business data body undergoes XBRL format conversion: the business type identifier (e.g., "purchase reimbursement") is mapped to a predefined element in the XBRL classification standard (e.g., mapped to the "Purchase Reimbursement" element); monetary information (e.g., specific monetary values) is converted into numerical fact values ​​that meet the format requirements in XBRL (i.e., recorded according to the numerical format specified in XBRL, including information such as units and precision); the feature value set of the electronic voucher (e.g., invoice code sequence, binary value of amount, etc.) is encoded into an XBRL context entity (i.e., the descriptive information that associates feature values ​​with the business scenario, ensuring the context of the feature values ​​is traceable); finally, the above conversion results are integrated to generate a standardized data package conforming to the XBRL 2.1 specification (i.e., a data package whose format and semantics conform to industry-standard norms).

[0030] Step 22 above, based on standardized data packets, uses a block encryption algorithm (i.e., splitting the data packet into fixed block sizes and encrypting each block) to process the entire data packet, generating a continuous encrypted data stream (i.e., the data packet is converted into a ciphertext sequence that cannot be directly read after encryption); the encrypted data stream is segmented into segments of a preset size (e.g., divided into multiple data blocks), and stored in different nodes in the distributed storage node cluster (e.g., node 1 stores the first segment, node 2 stores the second segment, etc.); after each node completes storage, it returns its own storage location identifier (e.g., the node's unique ID, the storage path of the data block within the node, etc.); the storage location identifiers of all nodes are collected, and a global location hash value (i.e., a hash result that uniquely represents all storage locations) is generated through hash processing (e.g., performing a hash operation on the combination information of all identifiers).

[0031] In step 23 above, the global location hash value and the submission credential hash are concatenated in a fixed order (e.g., the global location hash value is concatenated first, and then the submission credential hash is concatenated) to form a continuous index source string; the first hash operation is performed on the index source string (i.e., the string is converted into a fixed-length hash value using a hash algorithm), and then the result of the first operation is performed on the second hash operation (i.e., the previous hash value is hashed again) to obtain the final operation result; the result is written as an index value into the state database of the smart contract (i.e., the database in the smart contract used to store key state information), forming a unique data index for the corresponding XBRL data packet (i.e., the data packet can be uniquely associated with the data packet through this index value).

[0032] In a preferred embodiment of the present invention, step 3 above, based on a unique data index, involves the smart contract calling a rules engine to retrieve and parse the corresponding XBRL data packet; automatically verifying the compliance of the amount and the authenticity of the electronic voucher according to the business type identifier in the parsing result; and when the verification is successful, generating an approval instruction containing a data index based on a preset approval level and pushing it to the approver's terminal, which may include: Step 31: Based on the unique data index, the smart contract queries the state database to obtain the XBRL data packet storage location identifier; downloads the encrypted data stream from the distributed storage node cluster according to the location identifier, and reconstructs the XBRL data packet after decryption using a symmetric key; Step 32: Based on the reconstructed XBRL data packet, extract the business type identifier and map it to the preset rule base to match the classification standard; dynamically call the compliance threshold of the corresponding business type according to the matching result; Step 33: Based on the compliance threshold, perform boundary verification on the amount information in the data packet; when the amount verification passes, calculate the overall deviation rate of the feature values ​​between the electronic voucher feature value set and the pre-stored registration value, and generate a verification result code, including a verification pass code and a verification failure code. Step 34: When the verification result code indicates that the verification is successful, query the approval level configuration table according to the business type identifier, determine the approval path and time constraints, and encapsulate the approval instruction containing the data index, approval path and time constraints; push the approval instruction to the approver's terminal through the blockchain event log; when the verification result code indicates that the verification is unsuccessful, terminate the process and persistently store the abnormal status code in the smart contract.

[0033] In this embodiment of the invention, a unique data index is used to accurately locate the storage location, ensuring that the data fragments downloaded from the distributed nodes accurately correspond to the target data packet; symmetric key decryption ensures the security of the data before parsing, preventing unauthorized access, and reconstructing the complete data packet provides a complete data foundation for subsequent verification and parsing; precise matching of business type and rule base ensures that the compliance threshold of the call conforms to the characteristics of the business, and the dynamic calling mechanism allows the platform to flexibly adapt to rule updates for different business types, improving the adaptability and scalability of verification; amount boundary verification ensures that the business amount conforms to the preset rules, preventing excessive violations; the calculation of the overall deviation rate of feature values ​​realizes multi-dimensional verification of the authenticity of electronic vouchers, and the result code clearly quantifies the verification results, providing a clear basis for subsequent processes; approval levels are matched according to business type to ensure that the approval process conforms to the business characteristics and avoids process redundancy or omissions; blockchain event log push ensures that approval instructions are traceable and tamper-proof; persistent abnormal status codes facilitate subsequent tracing of failure reasons, while terminating the process to avoid invalid operations.

[0034] In this embodiment of the invention, when applied in a specific way, it can be implemented through the following technical solutions, for example: In step 31 above, the smart contract uses a unique data index to query and obtain the XBRL data packet storage location identifier corresponding to the index in the state database (i.e., the storage location information of each node associated with the global location hash value); based on these location identifiers, it downloads the corresponding encrypted data stream segments (i.e., the ciphertext data segmented and stored in step 22) from the distributed storage node cluster, decrypts each segment using a preset symmetric key (i.e., the same key used during encryption), and then splices and integrates all the decrypted data segments in their original order to reconstruct the complete XBRL data packet (i.e., restores it to the standardized data packet generated in step 21).

[0035] In step 32 above, the business type identifier (such as "service settlement") is extracted from the reconstructed XBRL data packet, and the identifier is matched with the classification standards stored in the preset rule base (that is, the rule base pre-stores the classification standards corresponding to business types such as "service settlement" and "procurement reimbursement"); according to the matched classification standard (such as the industry standard corresponding to "service settlement"), the compliance threshold specific to the business type is dynamically called (such as the upper limit of amount, voucher format requirements, etc., the thresholds are different for different business types, such as service settlement may be set to "no more than 50,000 yuan per transaction").

[0036] Step 33 above, based on a compliance threshold (e.g., "a single transaction not exceeding 50,000 yuan"), performs boundary verification on the amount information in the XBRL data packet (i.e., determines whether the actual amount is within the threshold range; for example, an amount of 30,000 yuan is compliant, while 60,000 yuan is not). If the amount verification passes, it further calculates the overall deviation rate between the electronic voucher feature value set (e.g., invoice code sequence, image grayscale value, etc.) and the pre-stored registration value (i.e., the standard feature value for platform filing) (i.e., the overall difference ratio of all features; for example, a perfect match of the invoice code, a deviation of 0.1% in the amount value, and a deviation of 0.5% in the image grayscale value, resulting in an overall deviation rate of 0.3%). Based on whether the deviation rate is within an acceptable range (e.g., ≤1%), a verification result code is generated (e.g., "00" represents pass, "01" represents failure).

[0037] In step 34 above, if the verification result code is "pass" (e.g., "00"), the smart contract queries the approval level configuration table (i.e., pre-stores the approval nodes and order corresponding to each business type, such as "department manager → financial director" two-level approval for service settlement) based on the business type identifier (e.g., "service settlement"), determines the specific approval path (e.g., node order) and time constraints (e.g., each level of approval must be completed within 24 hours); integrates and encapsulates the data index, approval path, and time constraints into an approval instruction, and pushes it to the corresponding approval terminal (e.g., the terminal of the department manager or financial director) through the blockchain event log (i.e., log records in the blockchain that can be listened to by the approval terminal); if the verification result code is "fail" (e.g., "01"), the current process is immediately terminated, and the abnormal status code (e.g., "1001" represents the amount exceeding the limit, "1002" represents the voucher characteristics not matching) is stored in the smart contract and persisted (i.e., permanently recorded, cannot be deleted or modified).

[0038] In a preferred embodiment of the present invention, in step 4 above, in response to the approval instruction returned by the approving terminal, the smart contract obtains the corresponding XBRL data packet through the data index; performs block processing on the obtained XBRL data packet, and constructs a Merkle tree structure containing leaf nodes, intermediate nodes, and a root node based on the block data, wherein: the leaf node is the cryptographic hash value of each data block, associated with electronic certificate metadata; the root node is the Merkle root hash value, anchored to the blockchain, and may include: Step 41: Based on the approval instruction returned by the approving terminal, the smart contract verifies the validity of the digital signature of the instruction; when the signature is valid, the data index is extracted from the instruction; the state database is queried through the data index to obtain the distributed storage location identifier and symmetric key of the XBRL data packet; Step 42: Download the set of encrypted data blocks from the distributed storage node cluster according to the storage location identifier; decrypt block by block using the symmetric key to reconstruct the complete XBRL data packet.

[0039] Step 43: For the reconstructed XBRL data packet, perform data segmentation according to the predefined chunk size, generate an independent set of data blocks, and assign a unique location identifier to each data block; Step 44: Based on the data block set, calculate the first hash value of the original content of each data block; concatenate the first hash value with the associated electronic voucher metadata, and perform a second hash operation to generate the leaf node value of the data block; after all data blocks have been processed, a set of leaf node values ​​is formed. Step 45: Recursively perform adjacent node pair concatenation hash operation based on the leaf node value set to generate intermediate nodes until they are aggregated into a single root node value; Step 46: Bind the root node value to the block metadata to generate an anchor data packet; initiate a blockchain transaction through a smart contract to write the anchor data packet into the distributed ledger.

[0040] In this embodiment of the invention, digital signature verification ensures the authenticity and legality of instructions, and data indexing accurately obtains the storage location and key to support subsequent download and decryption; distributed download ensures the efficiency and fault tolerance of data block acquisition, and block-by-block decryption ensures data security and prevents unauthorized access; reconstructing the complete data packet provides complete and accurate original data for subsequent block segmentation and Merkle tree construction; fixed-size block segmentation is standardized, and unique identifiers ensure accurate data block positioning and avoid confusion; the first hash verifies the integrity of the data block, and the second hash, combined with electronic voucher metadata, allows leaf nodes to be associated with content and business background, enhancing anti-counterfeiting; double hashing strengthens the immutability of data and provides reliable underlying node data for subsequent verification; in the Merkle tree constructed by recursive hashing, intermediate nodes are associated with lower-level hashes, and the root node aggregates all data block information; with the help of hashing characteristics, any change in data block will affect the root node, which can quickly verify whether it has been tampered with, improving verification efficiency and accuracy; after the root node value is bound to the block metadata, an anchored data packet is formed, which contains both the verification benchmark and the block background, facilitating traceability.

[0041] In this embodiment of the invention, when applied in a specific way, it can be implemented through the following technical solutions, for example: In step 41 above, after the approving terminal returns the approval instruction, the smart contract first verifies the digital signature of the instruction (i.e., checks whether the signature matches the approving party's preset identity identifier, confirming that the instruction was indeed issued by a legitimate approving party and has not been tampered with); if the signature verification is valid, the data index (i.e., the unique data index) is extracted from the instruction; the smart contract queries the state database through the data index to obtain the distributed storage location identifier of the corresponding XBRL data packet (i.e., the storage path of each node associated with the global location hash) and the symmetric key used for decryption (consistent with the decryption key used in step 31).

[0042] In step 42 above, based on the distributed storage location identifier, the smart contract downloads the corresponding encrypted data blocks (i.e., segments of encrypted data streams) from the distributed storage node cluster. After downloading, the smart contract uses the obtained symmetric key to decrypt each encrypted data block one by one (i.e., restores the ciphertext to the original data block using the key). Then, all the decrypted original data blocks are spliced ​​together and integrated according to their original order in the data packet to reconstruct a complete XBRL data packet (consistent with the data packet reconstructed in step 31).

[0043] In step 43 above, for the reconstructed complete XBRL data packet, the data packet is segmented according to a predefined block size (such as a fixed number of bytes) (i.e., starting from the beginning of the data packet, independent data blocks are divided according to the size), generating multiple independent data block sets; at the same time, a unique location identifier is assigned to each data block (such as numbered according to the block order, or generated based on the starting offset of the block in the data packet) to distinguish the location information of different data blocks.

[0044] In step 44 above, each data block in the data block set is processed one by one: the initial hash value of the original content of the data block is calculated (that is, the original information of the data block is processed by a hash algorithm to obtain a hash result of fixed length); then, the initial hash value is concatenated with the electronic voucher metadata associated with the data block (such as the generation time, number, source and other descriptive information of the electronic voucher) (that is, the hash value and metadata are combined in a fixed order); a second hash operation is performed on the concatenated content, and the result is used as the leaf node value corresponding to the data block; after all data blocks have completed the above processing, all leaf node values ​​are summarized to form a leaf node value set.

[0045] Step 45 above, based on the set of leaf node values, recursively performs the concatenation hash operation of adjacent node pairs: First, the leaf node values ​​are grouped in pairs in order, and the two leaf node values ​​in each group are concatenated (i.e., the two values ​​are combined in a fixed order), and the concatenation result is hashed to generate an intermediate node value; if the number of leaf nodes is odd, the last leaf node value is concatenated with itself and then hashed to generate an intermediate node value; then, the above pairwise grouping and concatenation hash operation is performed again on the generated intermediate node value, recursively generating the upper-level intermediate nodes, until finally aggregated into a single root node value (i.e., the Merkle root hash value).

[0046] In step 46 above, the root node value (Merkle root hash value) is bound together with the block metadata (such as the total number of data blocks, block size, location identifier rules, and other information describing the block partitioning process) (i.e., the root node value and block metadata are combined in a fixed format) to generate an anchor data packet; the smart contract initiates a blockchain transaction and writes the anchor data packet into the distributed ledger of the blockchain (i.e., the data packet is recorded on multiple nodes of the blockchain to form an immutable record).

[0047] In a preferred embodiment of the present invention, step 5 above, which involves obtaining the Merkle root hash value anchored to the blockchain and comparing it with the locally calculated value submitted by the approving terminal; after the consistency verification is passed, generating an encrypted payment voucher based on the settlement rules matched according to the business type identifier; and sending the encrypted payment voucher to the payment execution component to trigger fund transfer and update the distributed ledger status, may include: Step 51: Based on the ledger records anchored to the blockchain, read the on-chain Merkle root hash value from the smart contract state database; after successful acquisition, request and receive the local Merkle root hash value from the approval terminal; convert the on-chain hash value and the local hash value into equal-length binary bit strings; compare the binary bit strings bit by bit, count the number of different bits to generate a Hamming distance value; when the Hamming distance value is zero, generate a consistency pass signal. Step 52: Response consistency signal, extract the business type identifier from the reconstructed XBRL data packet; query the settlement rule base based on the business type identifier, and match the payment condition parameters; Step 53: Generate a structured payment instruction based on payment condition parameters; based on the structured payment instruction, perform asymmetric encryption using the public key registered by the payee on the blockchain to generate an encrypted payment certificate; based on the encrypted payment certificate, submit the certificate to the clearing network through the standardized interface protocol of the payment execution component; listen for the fund transfer status event returned by the clearing network, and generate a settlement confirmation signal when the event type is success. Step 54: Respond to the settlement confirmation signal, mark the original transaction status as completed in the smart contract, write the settlement completion timestamp and clearing network transaction ID, and update the balance status of the associated account.

[0048] In this embodiment of the invention, Hamming distance is used to quantify and compare on-chain and local hash values ​​to ensure that the data has not been tampered with after approval, and the verification process is objective and accurate. Zero Hamming distance is used as a pass condition to ensure strict verification of data consistency, providing a reliable data foundation for subsequent payments. Settlement rules are dynamically matched based on business type to ensure that payment conditions meet business characteristics. The rule base is flexibly configurable and supports rapid adjustment of business rules. Asymmetric encryption ensures the security of payment instructions and prevents payment information leakage or tampering. Standardized interface protocols support integration with different clearing networks, improving platform compatibility. Real-time monitoring of payment status ensures timely acquisition of payment results and avoids risks caused by unclear fund transfer status. Explicit updates to transaction status make the business process traceable, and timestamps and transaction IDs provide a complete record of the payment chain. Real-time updates to account balances ensure that the asset status in the distributed ledger is consistent with the actual fund flow, improving the asset management capabilities of the architecture.

[0049] In this embodiment of the invention, when applied in a specific way, it can be implemented through the following technical solutions, for example: In step 51 above, the smart contract reads the written Merkle root hash value (i.e., on-chain hash value) from the blockchain ledger and requests the Merkle root hash value (i.e., local hash value) calculated locally from the approval terminal; converts the two hash values ​​into binary bit strings of the same length (e.g., both converted to 256-bit binary), compares the two binary bit strings bit by bit, and counts the number of different bits at corresponding positions (i.e., Hamming distance); if the Hamming distance is zero, it means that the two hash values ​​are completely consistent, and a consistency pass signal is generated; otherwise, a verification failure signal is generated.

[0050] In step 52 above, responding to the consistency pass signal, the business type identifier (such as "equipment procurement") is extracted from the reconstructed XBRL data packet; using this identifier, the settlement rule base (i.e., the database that stores settlement rules corresponding to different business types) is queried, and the corresponding payment condition parameters (such as "30% prepayment is required for procurement, and the remaining 70% will be paid after acceptance") are matched.

[0051] In step 53 above, based on the matched payment condition parameters (such as amount, payment time, payee information, etc.), a structured payment instruction (i.e., an instruction that encapsulates payment elements in a fixed format) is generated; the payment instruction is asymmetrically encrypted using the payee's public key registered on the blockchain to generate an encrypted payment certificate (i.e., a certificate that can only be decrypted by the payee's private key); the encrypted payment certificate is sent to the clearing network to execute the fund transfer through the standardized interface protocol of the payment execution component (such as a general payment API); the status event returned by the clearing network is monitored, and if the event type is "payment successful", a settlement confirmation signal is generated.

[0052] In step 54 above, after receiving the settlement confirmation signal, the smart contract updates the original transaction status from "processing" to "completed", records the current time as the settlement completion timestamp, and writes the transaction ID (i.e. the unique identifier of fund transfer) returned by the clearing network into the smart contract; at the same time, it updates the balance status of the transaction-related accounts (e.g., reducing the payer's account balance and increasing the payee's account balance).

[0053] like Figure 2 As shown, embodiments of the present invention also provide a smart contract processing system for a cloud computing operation and settlement platform based on the government system, including: The submission module is used by user terminals to submit structured business data bodies containing business type identifiers, amount information, and electronic vouchers to cloud smart contracts. The preprocessing module is used to perform standardized transformation on the structured business data body received based on the cloud smart contract, generate XBRL language data packets; encrypt and store the generated XBRL data packets to distributed storage nodes, and generate a unique data index; The processing module is used to retrieve and parse the corresponding XBRL data packet by calling the rule engine based on the unique data index; automatically verify the compliance of the amount and the authenticity of the electronic voucher according to the business type identifier in the parsing result; when the verification is successful, generate an approval instruction containing the data index according to the preset approval level and push it to the approver's terminal. The anchoring module is used to respond to the approval instruction returned by the approval terminal. The smart contract obtains the corresponding XBRL data packet through the data index; it performs block processing on the obtained XBRL data packet, and constructs a Merkle tree structure containing leaf nodes, intermediate nodes and root nodes based on the block data. Among them, the leaf node is the encrypted hash value of each data block, which is associated with the electronic voucher metadata; the root node is the Merkle root hash value, which is anchored to the blockchain. The settlement module is used to obtain the Merkle root hash value anchored to the blockchain and compare it with the locally calculated value submitted by the approval terminal. After the consistency verification is passed, it generates an encrypted payment voucher by matching the settlement rules according to the business type identifier. It then sends the encrypted payment voucher to the payment execution component to trigger the fund transfer and update the distributed ledger status.

[0054] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A smart contract processing method for a cloud computing operation and settlement platform based on the government affairs system, characterized in that, The method includes: Step 1: The user terminal submits a structured business data body containing business type identifier, amount information and electronic voucher to the cloud smart contract; Step 2: Perform standardized transformation on the structured business data received by the cloud smart contract to generate XBRL language data packets; encrypt and store the generated XBRL data packets to distributed storage nodes, and generate a unique data index; Step 3: Based on the unique data index, the smart contract calls the rules engine to retrieve and parse the corresponding XBRL data packet; according to the business type identifier in the parsing result, it automatically verifies the compliance of the amount and the authenticity of the electronic voucher; when the verification is successful, it generates an approval instruction containing the data index according to the preset approval level and pushes it to the approver's terminal. Step 4: In response to the approval instruction returned by the approving terminal, the smart contract retrieves the corresponding XBRL data packet through the data index; performs block processing on the retrieved XBRL data packet, and constructs a Merkle tree structure containing leaf nodes, intermediate nodes and root nodes based on the block data, where: the leaf node is the encrypted hash value of each data block, associated with the electronic voucher metadata; the root node is the Merkle root hash value, anchored to the blockchain; Step 5: Obtain the Merkle root hash value anchored to the blockchain and compare it with the locally calculated value submitted by the approving party's terminal; after the consistency verification is passed, generate an encrypted payment voucher by matching the settlement rules according to the business type identifier; send the encrypted payment voucher to the payment execution component to trigger the fund transfer and update the distributed ledger status.

2. The smart contract processing method for a cloud computing operation and settlement platform based on the government affairs system according to claim 1, characterized in that, Step 1: The user terminal submits a structured business data body containing a business type identifier, amount information, and electronic voucher to the cloud smart contract, including: The user terminal extracts a set of voucher feature values ​​for electronic vouchers, including the encoded sequence value of the invoice code, the binary representation of the amount, and the grayscale feature value of the voucher image; the set of voucher feature values ​​is then bound to the business type identifier and amount information to form a structured business data body. Based on the structured business data body, coefficients are assigned according to the anti-counterfeiting weight level: the highest anti-counterfeiting level coefficient is assigned to the invoice code feature, the medium anti-counterfeiting level coefficient is assigned to the amount value feature, and the basic anti-counterfeiting level coefficient is assigned to the image grayscale feature; the corresponding level coefficients are applied to the invoice code feature, the amount value feature, and the image grayscale feature respectively to generate three types of weighted feature values; The three weighted feature values ​​are XORed in a fixed order. The invoice code feature value with the highest anti-counterfeiting level weight is XORed with the amount value feature value with the medium anti-counterfeiting level weight. The result is then XORed with the image grayscale feature value with the basic anti-counterfeiting level weight to generate a checksum. When the deviation rate between the checksum and the pre-stored registration value is within an acceptable risk range, a data validity flag is generated. The response data is valid, and the structured business data body is transmitted to the cloud smart contract through an encrypted channel.

3. The smart contract processing method for a cloud computing operation and settlement platform based on the government affairs system according to claim 2, characterized in that, Step 1: The user terminal submits a structured business data body containing a business type identifier, amount information, and electronic voucher to the cloud smart contract, which also includes: The cloud-based smart contract parses the metadata attributes of the received data, generates a submission credential hash containing a timestamp and data fingerprint, and writes it into the blockchain ledger.

4. The smart contract processing method for a cloud computing operation and settlement platform based on the government affairs system according to claim 3, characterized in that, Step 2: Perform standardized transformation on the structured business data received from the cloud smart contract to generate XBRL language data packets; The generated XBRL data packets are encrypted and stored on distributed storage nodes, and a unique data index is generated, including: Based on the hash of the submitted voucher, the corresponding structured business data body is retrieved from the blockchain ledger; XBRL format conversion is performed on the structured business data body: the business type identifier is mapped to XBRL classification standard elements, the amount information is converted into XBRL numerical fact values, the electronic voucher feature value set is encoded into XBRL context entities, and a standardized data package conforming to the XBRL 2.1 specification is generated. Based on the standardized data packet, an encrypted data stream is generated using a block encryption algorithm; the encrypted data stream is segmented and stored in a distributed storage node cluster, and the storage location identifiers returned by each node are received; all storage location identifiers are merged to generate a global location hash value; Based on the global location hash value and the submission credential hash, an index source string is generated by sequentially concatenating the two strings and performing two consecutive hash operations on the string. The result of the operation is written as an index value into the smart contract state database, forming a unique data index for the XBRL data packet.

5. The smart contract processing method for a cloud computing operation and settlement platform based on the government affairs system according to claim 4, characterized in that, Step 3: Based on the unique data index, the smart contract calls the rules engine to retrieve and parse the corresponding XBRL data packet; according to the business type identifier in the parsing result, it automatically verifies the compliance of the amount and the authenticity of the electronic voucher; when the verification is successful, it generates an approval instruction containing the data index according to the preset approval level and pushes it to the approver's terminal, including: Based on the unique data index, the smart contract queries the state database to obtain the XBRL data packet storage location identifier; according to the location identifier, it downloads the encrypted data stream from the distributed storage node cluster, decrypts it using a symmetric key, and reconstructs the XBRL data packet. Based on the reconstructed XBRL data packets, the business type identifier is extracted and mapped to a preset rule base to match the classification standard; the compliance threshold of the corresponding business type is dynamically called according to the matching result. Based on compliance thresholds, boundary verification is performed on the amount information in the data packet; when the amount verification passes, the overall deviation rate of the feature value set of electronic vouchers and the feature values ​​of the pre-stored registration values ​​is calculated, and a verification result code is generated, including a verification pass code and a verification failure code. When the verification result code indicates that the verification is successful, the approval level configuration table is queried according to the business type identifier to determine the approval path and time constraints. The approval instruction containing the data index, approval path and time constraints is encapsulated. The approval instruction is pushed to the approver's terminal through the blockchain event log. When the verification result code indicates that the verification is unsuccessful, the process is terminated and the abnormal status code is persistently stored in the smart contract.

6. The smart contract processing method for a cloud computing operation and settlement platform based on the government affairs system according to claim 5, characterized in that, Step 4: In response to the approval command returned by the approving terminal, the smart contract retrieves the corresponding XBRL data packet through the data index, including: Based on the approval instruction returned by the approving terminal, the smart contract verifies the validity of the digital signature of the instruction; when the signature is valid, the data index is extracted from the instruction; the state database is queried through the data index to obtain the distributed storage location identifier and symmetric key of the XBRL data packet; Based on the storage location identifier, download a set of encrypted data blocks from the distributed storage node cluster; decrypt each block using a symmetric key to reconstruct the complete XBRL data packet.

7. The smart contract processing method for a cloud computing operation and settlement platform based on the government affairs system according to claim 6, characterized in that, The acquired XBRL data packets are processed by chunking. Based on the chunked data, a Merkle tree structure containing leaf nodes, intermediate nodes, and a root node is constructed. The leaf nodes are the cryptographic hash values ​​of each data block, associated with the electronic certificate metadata; the root node is the Merkle root hash value, anchored to the blockchain, including: For the reconstructed XBRL data packets, data segmentation is performed according to the predefined chunk size, generating an independent set of data blocks and assigning a unique location identifier to each data block; Based on the data block set, the initial hash value of the original content of each data block is calculated block by block; the initial hash value is concatenated with the associated electronic voucher metadata, and a second hash operation is performed to generate the leaf node value of the data block; when all data blocks have been processed, a set of leaf node values ​​is formed. Based on the set of leaf node values, recursively perform the concatenation hash operation of adjacent node pairs to generate intermediate nodes until they are aggregated into a single root node value. The root node value is bound to the block metadata to generate an anchor data packet; a blockchain transaction is initiated through a smart contract to write the anchor data packet into the distributed ledger.

8. The smart contract processing method for a cloud computing operation and settlement platform based on the government affairs system according to claim 7, characterized in that, Step 5: Obtain the Merkle root hash value anchored to the blockchain and compare it with the locally calculated value submitted by the approving party's terminal; once the consistency verification is passed, generate an encrypted payment voucher by matching the settlement rules according to the business type identifier. Sending encrypted payment credentials to the payment execution component triggers fund transfers and updates the distributed ledger state, including: Based on the ledger records anchored to the blockchain, the on-chain Merkle root hash value is read from the smart contract state database; Upon successful acquisition, request and receive the local Merkle root hash value from the approval terminal; convert the on-chain hash value and the local hash value into equal-length binary bit strings; compare the binary bit strings bit by bit, count the number of different bits to generate a Hamming distance value; when the Hamming distance value is zero, generate a consistency pass signal; The response consistency is achieved by extracting the business type identifier from the reconstructed XBRL data packet using signals; and querying the settlement rule base based on the business type identifier to match the payment condition parameters. Based on payment condition parameters, a structured payment instruction is generated; based on the structured payment instruction, asymmetric encryption is performed using the public key registered by the payee on the blockchain to generate an encrypted payment certificate; based on the encrypted payment certificate, the certificate is submitted to the clearing network through the standardized interface protocol of the payment execution component; the fund transfer status event returned by the clearing network is monitored, and a settlement confirmation signal is generated when the event type is success. In response to the settlement confirmation signal, the original transaction status is marked as completed in the smart contract, the settlement completion timestamp and clearing network transaction ID are written, and the balance status of the associated account is updated.

9. A smart contract processing system for a cloud computing operation and settlement platform based on the government system, wherein the system implements the method as described in any one of claims 1 to 8, characterized in that, include: The submission module is used by user terminals to submit structured business data bodies containing business type identifiers, amount information, and electronic vouchers to cloud smart contracts. The preprocessing module is used to perform standardized transformation on the structured business data body received based on the cloud smart contract, generate XBRL language data packets; encrypt and store the generated XBRL data packets to distributed storage nodes, and generate a unique data index; The processing module is used to retrieve and parse the corresponding XBRL data packet by calling the rule engine based on the unique data index; automatically verify the compliance of the amount and the authenticity of the electronic voucher according to the business type identifier in the parsing result; when the verification is successful, generate an approval instruction containing the data index according to the preset approval level and push it to the approver's terminal. The anchoring module is used to respond to the approval instruction returned by the approval terminal. The smart contract obtains the corresponding XBRL data packet through the data index; it performs block processing on the obtained XBRL data packet, and constructs a Merkle tree structure containing leaf nodes, intermediate nodes and root nodes based on the block data. Among them, the leaf node is the encrypted hash value of each data block, which is associated with the electronic voucher metadata; the root node is the Merkle root hash value, which is anchored to the blockchain. The settlement module is used to obtain the Merkle root hash value anchored to the blockchain and compare it with the locally calculated value submitted by the approval terminal. After the consistency verification is passed, it generates an encrypted payment voucher by matching the settlement rules according to the business type identifier. It then sends the encrypted payment voucher to the payment execution component to trigger the fund transfer and update the distributed ledger status.

10. A computing device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the method as described in any one of claims 1 to 8.

Images