Method and system for automatic settlement of funds for transaction of scientific and technological achievements based on smart contract

Abstract

The present application relates to payment settlement technical field, disclose a kind of based on smart contract's scientific and technological achievement transaction fund automatic settlement method and system, the method includes: based on transaction intention to compile transaction parameter, obtain contract bytecode and deploy to block chain, obtain unique contract address.Buyer locks transaction fund to the contract account, while the achievement delivery file uploaded by seller is encrypted fragment, generates derivative data section.Derivative data section is distributed to distributed storage node, and the storage address returned by node and content hash value are combined into fragment index list according to agreed format.Extract the digital voucher information of delivery file from the list, carry out byte check with the seller digital voucher sample in transaction parameter, obtain content acceptance result.Finally, according to the settlement mark in acceptance result, the direction of the transfer of transaction funds of both parties is automatically determined;The present application can improve the efficiency of scientific and technological achievement transaction fund automatic settlement based on smart contract.

Description

Technical Field

[0001] This invention relates to the field of payment and settlement technology, and in particular to a method and system for automatic settlement of funds for technology transaction based on smart contracts. Background Technology

[0002] In the current field of technology transfer, the commonly used fund settlement methods mainly rely on traditional third-party escrow or offline agreement payments. After both parties reach an agreement, the buyer pays funds to an escrow account provided by a bank or third-party payment platform. After the seller completes the delivery of the technology, they need to wait for the buyer to manually confirm receipt or complete an offline acceptance process before the escrow provider processes the fund transfer based on the buyer's instructions or offline documents. This model heavily relies on manual intervention and the credit endorsement of centralized institutions. The settlement process is lengthy and inefficient, with funds often remaining in the escrow account for days or even weeks, increasing the time cost of the transaction. At the same time, the centralized escrow model has the risk of fund misappropriation and single point of failure. Once the escrow provider's system fails or a credit crisis occurs, the fund security of both parties will be directly threatened.

[0003] Furthermore, existing technologies lack transparent and automated verification mechanisms in the delivery and acceptance stages. Delivery documents uploaded by the seller are typically stored in plaintext on a centralized server, requiring the buyer to manually verify them after downloading. This process cannot guarantee the authenticity and integrity of the documents, making them susceptible to tampering or malicious delays in acceptance by the buyer. Due to the lack of cryptographic evidence storage and automated comparison mechanisms for the delivered content, disputes often require significant effort from both parties in evidence gathering and coordination, sometimes even resorting to legal action. This vague, manual acceptance model not only fails to guarantee the seller's timely payment rights but also makes it difficult for the buyer to objectively and reliably verify the deliverables before payment, severely hindering the efficiency of technology transfer and the healthy development of the trading market. Summary of the Invention

[0004] This invention provides a method and system for automatic settlement of funds in technology transaction based on smart contracts, the main purpose of which is to solve the problem of low efficiency in automatic settlement of funds in technology transaction based on smart contracts.

[0005] To achieve the above objectives, this invention provides a method for automatic settlement of funds in technology transfer transactions based on smart contracts, comprising:

[0006] The transaction parameters of the target process are compiled based on the transaction intention of the target process to obtain the contract bytecode of the target process;

[0007] The contract bytecode is deployed to the blockchain network of the target process to obtain the contract address of the target process;

[0008] The transaction funds paid by the buyer during the target process are locked into the contract account corresponding to the contract address, and the deliverable files uploaded by the seller during the target process are encrypted and fragmented to obtain the derived data segment of the target process.

[0009] The derived data segments are distributed to the distributed storage nodes of the target process, and the storage addresses and content hash values ​​returned by the distributed storage nodes are combined into a shard index list of the target process according to the format agreed in the transaction parameters.

[0010] The digital certificate information of the delivered files in the fragmented index list is compared with the seller's digital certificate sample in the transaction parameters by byte verification to obtain the content acceptance result of the target process.

[0011] The direction of fund transfer between the two parties in the target process is determined based on the settlement identifier of the acceptance result of the content.

[0012] In a preferred embodiment, compiling the transaction parameters of the target process based on the transaction intention of the target process to obtain the contract bytecode of the target process includes:

[0013] The transaction parameters of both parties in the target transaction process are obtained. The transaction parameters include the hash value of the transaction target, the transaction amount, the delivery deadline, the acceptance deadline, and the blockchain identity identifiers of both parties.

[0014] The transaction parameters are converted into the initial parameter byte stream of the target process according to the calibrated bytecode format of the target process;

[0015] The initial parameter byte stream is encapsulated to obtain the contract bytecode of the target process.

[0016] In a preferred embodiment, deploying the contract bytecode to the blockchain network of the target process to obtain the contract address of the target process includes:

[0017] The deployment transaction format of the blockchain network is determined, and the deployment transaction format includes a transaction initiator identifier, a transaction recipient identifier, and a transaction data field;

[0018] The transaction initiator identifier is set as the contract deployment identifier, the transaction receiver identifier is set as the contract creation identifier, and the contract bytecode is filled into the transaction data field to obtain the transaction payload body of the blockchain network;

[0019] The hash value of the transaction payload is digitally signed based on the private key corresponding to the contract deployment identifier to obtain the signature data of the blockchain network.

[0020] The transaction payload body is assembled with the signature data to obtain the transaction payload of the blockchain network;

[0021] Based on the valid bytecode of the transaction payload, a contract instance corresponding to the target process is generated in the ledger of the blockchain network, and the storage location of the contract instance is used as the contract address of the target process.

[0022] In a preferred embodiment, the step of locking the transaction funds paid by the buyer in the target process to the contract account corresponding to the contract address, and encrypting and fragmenting the deliverable files uploaded by the seller in the target process to obtain the derived data segment of the target process, includes:

[0023] The transfer amount of the fund transfer transaction initiated by the buyer to the contract address during the target process is compared with the transaction amount value in the transaction parameters;

[0024] If the transferred amount is consistent with the transaction amount, the fund lock operation of the contract account is triggered, and the funds corresponding to the transferred amount are marked as locked.

[0025] If the transferred amount is inconsistent with the transaction amount, the fund rejection operation of the contract account is triggered, the funds corresponding to the transferred amount are returned to the account corresponding to the blockchain identity of the buyer in the target process, and an abnormal record of the amount discrepancy is generated.

[0026] The lock timestamp, lock amount, and blockchain identity identifiers of both parties generated based on the lock status are written into the ledger of the blockchain network;

[0027] The deliverables are segmented and encrypted based on the time factor and identity factor of the target process to obtain the derived data segment of the target process.

[0028] In a preferred embodiment, the step of segmenting and encrypting the deliverable file based on the time factor and identity factor of the target process to obtain the derived data segment of the target process includes:

[0029] The deliverables are divided according to the data block boundaries of the transaction parameters to obtain the original data fragments of the target process;

[0030] The current timestamp of the target process, the blockchain identity identifier of the seller in the target process, and the fragment sequence number of the original data fragment are concatenated to obtain the key seed corresponding to the original data fragment.

[0031] Perform a hash operation on the key seed to obtain the encryption key for the original data fragment;

[0032] Perform a bitwise XOR operation between the original data fragment and the encryption key to obtain the encrypted data fragment of the original data fragment;

[0033] The fragment number, the encrypted data fragment, and the encryption key are associated and stored to obtain the derived data segment of the target process.

[0034] In a preferred embodiment, the step of distributing the derived data segment to the distributed storage node of the target process, and combining the storage address and content hash value returned by the distributed storage node into a fragment index list of the target process according to the format agreed in the transaction parameters, includes:

[0035] Calculate the node adaptability of the derived data segment based on the current load value and historical response time of the distributed storage node;

[0036] Based on the node adaptability, the optimal storage node is selected for the derived data segment to obtain the target storage node for the derived data segment;

[0037] The derived data segment is sent to the corresponding target storage node, and the storage location identifier and data content hash value returned by the target storage node are received to obtain the index entry of the derived data segment;

[0038] The index entries are arranged in order of the fragment number of the derived data segment to obtain the fragment index list of the target process.

[0039] In a preferred embodiment, the formula for calculating the node adaptability includes:

[0040]

[0041] in, For the first The derived data segment and the first The adaptability of each storage node For the index of derived data segments, For the index of the storage node, For the first Network bandwidth value of each storage node This represents the maximum network bandwidth value in the storage node. To indicate the first Historical availability of each storage node This represents the maximum historical availability among the storage nodes. For the first The current load value of each storage node. It is a very small constant. This is the load weighting index. For the first Historical response time of each storage node In response to the duration-weighted index, It is a natural constant. For the first Storage cost coefficient for each storage node This is the cost attenuation coefficient.

[0042] In a preferred embodiment, the step of performing byte verification between the digital certificate information of the delivered files in the fragmented index list and the seller's digital certificate sample in the transaction parameters to obtain the content acceptance result of the target process includes:

[0043] Based on the byte position and byte length marked in the transaction parameters, the byte sequence at the corresponding position will be extracted from the delivery file of the shard index list as the digital certificate information of the target process;

[0044] The digital voucher information is compared byte by byte with the seller's digital voucher sample to obtain the byte record sequence of the target process;

[0045] If all byte values ​​in the byte record sequence are the same, a positive acceptance result for the target process is generated.

[0046] If there are differing bytes in the byte record sequence, then a reverse acceptance result of the target process is generated.

[0047] In a preferred embodiment, determining the direction of fund transfer between the transacting parties in the target process based on the settlement identifier of the content acceptance result includes:

[0048] If the value of the settlement identifier field in the content acceptance result is a positive transfer code, the contract account in the target process executes a fund transfer instruction, and the transaction funds deducted from the balance of the contract account are added to the account balance corresponding to the blockchain identity identifier of the seller in the target process. At the same time, a positive transfer record containing the transaction hash value, the transferor address, the receiver address, the transfer amount, and the transfer timestamp is generated.

[0049] If the value of the settlement identifier field is a reverse return code, the contract account executes a fund return instruction, which adds the transaction funds deducted from the balance of the contract account to the account balance corresponding to the blockchain identity identifier of the buyer in the target process, and generates a reverse return record containing the transaction hash value, the sender address, the receiver address, the return amount, and the return timestamp.

[0050] To address the aforementioned problems, this invention also provides an automatic settlement system for technology transfer transactions based on smart contracts, the system comprising:

[0051] The contract bytecode module compiles the transaction parameters of the target process based on the transaction intention of the target process to obtain the contract bytecode of the target process;

[0052] The contract address module deploys the contract bytecode to the blockchain network of the target process to obtain the contract address of the target process;

[0053] The derived data segment module locks the transaction funds paid by the buyer in the target process into the contract account corresponding to the contract address, and encrypts and fragments the deliverable files uploaded by the seller in the target process to obtain the derived data segment of the target process.

[0054] The sharding index list module distributes the derived data segments to the distributed storage nodes of the target process, and combines the storage addresses and content hash values ​​returned by the distributed storage nodes into a sharding index list of the target process according to the format agreed in the transaction parameters.

[0055] The content acceptance module performs byte verification between the digital certificate information of the delivered files in the fragment index list and the seller's digital certificate sample in the transaction parameters to obtain the content acceptance result of the target process.

[0056] The fund allocation direction module determines the fund allocation direction between the two parties in the target process based on the settlement identifier of the content acceptance result.

[0057] Compared with the prior art, the present invention has the following beneficial effects:

[0058] 1. This smart contract-based automatic settlement method for technology transaction funds achieves the codification and decentralized execution of transaction rules by compiling transaction parameters into contract bytecode and deploying it to the blockchain. The transaction funds paid by the buyer are locked in an account uniquely identified by the contract address, with complete control over the funds entrusted to a transparent and tamper-proof smart contract. This mechanism ensures the security of funds throughout the entire transaction cycle. Only when the agreed acceptance conditions are met will the automatic transfer operation be triggered based on the settlement identifier, accurately and promptly transferring the funds to the seller's account. The entire process eliminates human intervention and the credit endorsement of intermediaries, fundamentally improving settlement efficiency. Every change in the state of the fund flow generates an irrefutable record on the blockchain ledger, providing both parties with extremely high fund security and process transparency.

[0059] 2. In processing the delivery content of scientific and technological achievements, this method introduces encrypted fragmentation and distributed storage technologies. The delivery files uploaded by the seller are segmented and encrypted based on time and identity factors to generate derived data segments uniquely bound to the transaction. These segments are then distributed to distributed storage nodes, and an ordered fragmentation index list is constructed. This processing method not only ensures the confidentiality and integrity of the delivery data during transmission and storage, but also generates objective and accurate content acceptance results by automatically comparing the digital voucher information in the fragmentation index list with the seller's preset digital voucher samples at the byte level. The acceptance process is entirely based on preset byte positions and lengths for automatic verification, eliminating subjective judgment and human delays, ensuring the uniformity of acceptance standards and the fairness of execution results, and providing a reliable and irrefutable basis for the subsequent automatic transfer of funds. Attached Figure Description

[0060] Figure 1 This is a flowchart illustrating an embodiment of the automatic settlement method for technology transaction funds based on smart contracts provided by the present invention.

[0061] Figure 2 A functional block diagram of an automatic settlement system for technology transaction funds based on smart contracts, provided in an embodiment of the present invention;

[0062] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0063] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0064] This application provides a method for automatic settlement of funds in technology transaction based on smart contracts. The executing entity of this method includes, but is not limited to, at least one of the following electronic devices that can be configured to execute the method provided in this application: a server, a terminal, etc. In other words, the method for automatic settlement of funds in technology transaction based on smart contracts can be executed by software or hardware installed on a terminal device or a server device. The server includes, but is not limited to, a single server, a server cluster, a cloud server, or a cloud server cluster. The server can be an independent server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0065] Reference Figure 1The diagram shown is a flowchart illustrating an automatic settlement method for technology transfer transactions based on smart contracts, according to an embodiment of the present invention. In this embodiment, the automatic settlement method for technology transfer transactions based on smart contracts includes:

[0066] In this embodiment of the invention, when compiling the transaction parameters of the target process based on the transaction intention of the target process to obtain the contract bytecode of the target process, it is specifically used for:

[0067] The transaction parameters of both parties in the target transaction process are obtained. The transaction parameters include the hash value of the transaction target, the transaction amount, the delivery deadline, the acceptance deadline, and the blockchain identity identifiers of both parties.

[0068] The transaction parameters are converted into the initial parameter byte stream of the target process according to the calibrated bytecode format of the target process;

[0069] The initial parameter byte stream is encapsulated to obtain the contract bytecode of the target process.

[0070] Specifically, the system first receives transaction information jointly confirmed by both the buyer and seller from the client nodes associated with their digital identities on the blockchain network. This transaction information is encapsulated into a structured digital offer document. The system then parses this document and extracts the hash value of the transaction target contained therein. This hash value is calculated from the original data of the delivery document provided by the seller using a hash algorithm and serves as the unique digital fingerprint of the target.

[0071] Specifically, the underlying bytecode conversion engine is invoked. This engine reads each data element in the transaction parameters, first processes the hash value of the transaction target, converting it from a hexadecimal string into a fixed-length raw byte sequence, and then processes the transaction amount value, converting it from a decimal integer into a big-endian integer byte sequence.

[0072] Specifically, the system obtains a smart contract template pre-stored in the code repository. This template contains the contract's logical code framework and variable placeholders for filling external data. The system passes the initial parameter byte stream as input data to the constructor of the contract template. The constructor copies the initial parameter byte stream as a whole and fills it into the data segment position specified in the template, overwriting the original placeholders, thus completing the static fusion of data and code.

[0073] Furthermore, the system simultaneously extracts the transaction amount promised by the buyer, as well as the agreed delivery and acceptance deadlines. Finally, it extracts the blockchain identity identifiers of the buyer and the seller. The system then arranges and combines the five extracted data elements according to a preset field order to form a complete data set, which is the transaction parameters of both parties in the target process.

[0074] Next, the delivery deadline and acceptance deadline are processed, converting these two time points from standard timestamp format into unsigned long integer byte sequences. Finally, the blockchain identity identifiers of both parties are processed, decoding these two address strings into original 20-byte public key hash byte sequences. The system concatenates all the byte sequences obtained above according to the order of data elements in the transaction parameters, forming a continuous byte stream, which is the initial parameter byte stream of the target process.

[0075] Furthermore, the system calls the compiler backend to perform a complete compilation operation on the contract template code that incorporates specific transaction parameters. The compiler first performs lexical analysis and syntax analysis to convert the code text into an abstract syntax tree, then performs semantic analysis and code optimization, and finally generates a bytecode instruction sequence that can be executed on the blockchain virtual machine. The compiler outputs this sequence and appends a piece of initialization parameter data to the end of it. The final generated complete binary data packet is the contract bytecode of the target process.

[0076] In summary, by explicitly extracting the hash value of the transaction target, the transaction amount, the delivery deadline, the acceptance deadline, and the blockchain identity identifiers of both parties, a unique and tamper-proof digital agreement is established for the entire transaction process. The hash value of the transaction target serves as a unique digital fingerprint for the final document, ensuring the uniqueness and non-repudiation of the transaction object and preventing subsequent alteration of delivery documents. The extraction of the transaction amount and deadline provides precise triggering conditions for the subsequent automatic execution of fund locking and acceptance upon maturity by the smart contract. The acquisition of the blockchain identity identifiers of both parties ensures the authenticity of the transaction entities and the accuracy of the fund transfer recipients, preventing transaction disputes caused by identity ambiguity from the outset.

[0077] In summary, this step unifies transaction parameters from various data formats into a machine-readable initial parameter byte stream, eliminating data heterogeneity and creating conditions for standardized processing of smart contracts. This transformation converts abstract transaction intentions into concrete, fixed-order byte sequences, enabling subsequent contract templates to accurately read and use these parameters through preset byte positions. This standardized encapsulation greatly improves the efficiency and accuracy of data processing, providing clean and unambiguous input data for contract bytecode generation, and serves as a crucial bridge connecting real-world transaction parameters with on-chain code execution.

[0078] In summary, this step merges and compiles the initial parameter byte stream containing specific transaction parameters with a pre-built contract logic code template, generating the final deployable contract bytecode. This encapsulation process integrates the transaction's business logic and technical implementation, forming an automated legal and technical contract. Once the generated contract bytecode is deployed on the blockchain, its execution logic will be free from any human intervention, ensuring the fairness and transparency of the transaction. This step transforms static transaction parameters into dynamic executable code, giving life to all subsequent automated operations and serving as the core technological guarantee for the entire method to achieve "automatic settlement."

[0079] In this embodiment of the invention, the step of deploying the contract bytecode to the blockchain network of the target process to obtain the contract address of the target process is specifically used for:

[0080] The deployment transaction format of the blockchain network is determined, and the deployment transaction format includes a transaction initiator identifier, a transaction recipient identifier, and a transaction data field;

[0081] The transaction initiator identifier is set as the contract deployment identifier, the transaction receiver identifier is set as the contract creation identifier, and the contract bytecode is filled into the transaction data field to obtain the transaction payload body of the blockchain network;

[0082] The hash value of the transaction payload is digitally signed based on the private key corresponding to the contract deployment identifier to obtain the signature data of the blockchain network.

[0083] The transaction payload body is assembled with the signature data to obtain the transaction payload of the blockchain network;

[0084] Based on the valid bytecode of the transaction payload, a contract instance corresponding to the target process is generated in the ledger of the blockchain network, and the storage location of the contract instance is used as the contract address of the target process.

[0085] Specifically, the first step is to read the specification document on transaction construction in the underlying protocol of the blockchain network, and then parse out the deployment transaction format that must be followed when deploying smart contracts from the document. This format clearly stipulates that a legitimate deployment transaction must contain three core data segments.

[0086] Specifically, the system writes the previously determined contract deployment identifier into the transaction initiator identifier position in the deployment transaction format. This contract deployment identifier is the blockchain address of the account responsible for publishing this contract. At the same time, the system writes the contract creation identifier into the transaction recipient identifier position. This contract creation identifier is a special predefined address used to indicate to the blockchain network that the purpose of this transaction is not to transfer funds to a regular account, but to create a new smart contract.

[0087] Specifically, the system reads the private key corresponding to the contract deployment identifier from the local secure key storage area. This private key is a strictly confidential, very large integer. The system uses this private key to perform a hash operation on the transaction payload body and then digitally signs the digest value obtained.

[0088] Specifically, the system concatenates the already constructed transaction payload with the newly generated signature data, following the packaging format specified by the blockchain network, and appends the signature data to the end of the transaction payload.

[0089] Specifically, the system broadcasts the transaction payload to all nodes in the blockchain network through the underlying network interface. After receiving the transaction payload, each node first uses the contract deployment identifier contained in the transaction payload to query the corresponding public key from the blockchain ledger, and uses the public key to verify the signature data. After successful verification, the node extracts the valid bytecode from the transaction payload. Here, the valid bytecode refers to the contract bytecode part carried in the transaction data field.

[0090] Furthermore, the first data segment is the transaction initiator identifier, which records the account address that sends the transaction; the second data segment is the transaction recipient identifier, which records the target account address to which the transaction is to be sent; and the third data segment is the transaction data field, which carries the additional data that needs to be sent to the blockchain network along with the transaction. The system stores the specific structure of this format in memory.

[0091] Furthermore, the previously compiled contract bytecode is completely copied into the transaction data field. At this point, the transaction initiator identifier, transaction receiver identifier, and transaction data field are all filled in. The data entity formed by the combination of these three parts is the main body of the transaction load of the blockchain network.

[0092] Furthermore, the specific process of hash operation is that the system takes the transaction payload as input data, converts it into a fixed-length byte sequence through a hash function, and then the signature algorithm uses the private key to encrypt and transform the byte sequence to generate a signature data that cannot be reversed from the private key. This signature data can prove that the transaction payload was indeed authorized and issued by the account holding the private key, and that the transaction payload has not been tampered with after signing.

[0093] Furthermore, by adding header information required for network transmission to the outermost layer, a complete data packet that can be broadcast to the blockchain peer-to-peer network is finally formed, which is the transaction payload of the blockchain network.

[0094] Furthermore, the virtual machine on the node begins to execute the constructor instruction in the valid bytecode, allocates new storage space in the virtual machine's runtime environment, and writes the initial state data of the contract into this space. The contract code itself is also persistently stored in this newly allocated space, and the unique index position of this storage space in the entire blockchain ledger is the contract address of the target process.

[0095] In summary, by strictly adhering to the transaction construction specifications in the underlying blockchain protocol, and by pre-determining that transactions must include the transaction initiator identifier, the transaction recipient identifier, and transaction data fields, this step provides a standardized data container framework for all subsequent operations. This ensures that the entire contract deployment process fully complies with the blockchain network's acceptance and verification rules from the very beginning, avoiding transaction rejection due to format errors, and laying an unshakable format foundation for the successful on-chain uploading of contract bytecode.

[0096] In summary, by filling the blockchain address of the contract deployer into the initiator identifier, filling the network-predefined contract creation address into the receiver identifier, and completely filling the previously compiled contract bytecode into the transaction data field, these three actions together construct a semantically clear and network-recognizable core part of the transaction. This transaction payload accurately conveys all the information about the initiator, the operation to be performed, and the contract creation to the blockchain network, achieving a precise conversion from contract code to on-chain broadcastable data.

[0097] In summary, using a private key uniquely corresponding to the contract deployment identifier to cryptographically transform the hash value of the transaction payload to generate signature data provides dual cryptographic protection. First, the private key signature proves that the transaction payload was indeed authorized by the legitimate contract deployer. Second, the hash value locking ensures that any byte modification to the transaction payload after signing can be detected by the verification node, thereby eliminating the possibility of malicious tampering of the transaction content during broadcast.

[0098] In summary, the transaction payload, which carries all the transaction content, and the signature data that provides proof of authenticity are assembled according to the network's prescribed format to form the final broadcastable data packet. This complete transaction payload contains all the business data required for blockchain nodes to execute contract creation, as well as cryptographic evidence to verify the source and integrity of these data. This allows the transaction payload to be received, verified, and executed by all nodes in the network without any obstacles once it is sent, completing the final assembly from local data to a network-propagable entity.

[0099] In summary, relying on the consensus mechanism and virtual machine environment of the blockchain network, valid bytecode is extracted from the transaction payload and its constructor is executed, creating a brand-new, independently running contract instance in the distributed ledger. At the same time, the unique storage location of this instance in the ledger is returned as the contract address. The creation of this contract address marks the official establishment of a legally valid automated transaction program on the chain. All subsequent fund locking, document notarization, and automatic acceptance will be triggered by calling this address, providing a permanent and non-migratable execution center for the entire technology achievement transaction settlement process.

[0100] In this embodiment of the invention, the step of locking the transaction funds paid by the buyer in the target process to the contract account corresponding to the contract address, and encrypting and fragmenting the deliverable files uploaded by the seller in the target process to obtain the derived data segment of the target process, is specifically used for:

[0101] The transfer amount of the fund transfer transaction initiated by the buyer to the contract address during the target process is compared with the transaction amount value in the transaction parameters;

[0102] If the transferred amount is consistent with the transaction amount, the fund lock operation of the contract account is triggered, and the funds corresponding to the transferred amount are marked as locked.

[0103] If the transferred amount is inconsistent with the transaction amount, the fund rejection operation of the contract account is triggered, the funds corresponding to the transferred amount are returned to the account corresponding to the blockchain identity of the buyer in the target process, and an abnormal record of the amount discrepancy is generated.

[0104] The lock timestamp, lock amount, and blockchain identity identifiers of both parties generated based on the lock status are written into the ledger of the blockchain network;

[0105] The deliverables are segmented and encrypted based on the time factor and identity factor of the target process to obtain the derived data segment of the target process.

[0106] Specifically, the system continuously monitors all transactions in the blockchain network. When it detects a transaction initiated by the buyer's blockchain identity address and the recipient's address is the contract address, it immediately suspends the current process and enters the verification phase. The system extracts the value of the transfer amount field from the original data structure of the transaction.

[0107] Specifically, if the comparison result determines that the transferred amount is completely consistent with the transaction amount, the contract code immediately jumps to the fund locking branch. The contract calls the balance management interface provided by the underlying blockchain to transfer the funds transferred by the buyer from the temporary balance of their account to a specially established locked balance sub-account within the contract.

[0108] Specifically, if the comparison result determines that the transfer amount is inconsistent with the transaction amount, the contract code jumps to the fund rejection branch. The contract immediately constructs a new transfer transaction, with the transaction recipient set to the buyer's blockchain identity address and the transfer amount set to the initial transfer amount transferred by the buyer. This transaction is initiated by the contract account and signed using the contract's own permissions, thereby returning the funds to their original source.

[0109] Specifically, the contract executes a ledger write operation immediately after the funds are successfully locked. The system first obtains the lock timestamp from the current block header, extracts the locked amount from the lock record, and extracts the buyer's blockchain identity and the seller's blockchain identity from the transaction parameters.

[0110] Specifically, the system obtains the precise system clock time when the seller uploads the deliverable file as a time factor, and at the same time obtains the seller's blockchain identity identifier address as an identity factor. These two factors are concatenated with the file's fragment number. The system then cuts the deliverable file according to fixed-length data block boundaries to obtain multiple raw data fragments. For each raw data fragment, the system inputs the byte sequence of its corresponding time factor, identity factor, and fragment number into a hash function.

[0111] Furthermore, the pre-written transaction parameters are read from the persistent storage area of ​​the contract, the transaction amount is extracted, and then the two values ​​are compared bit by bit to confirm whether they are completely equal. This comparison operation is directly executed by the verification function inside the contract. After the comparison is completed, a boolean result value is generated for subsequent branch judgment.

[0112] Furthermore, a new lock record is created in the contract's state database, clearly marking that the funds are currently locked. No subsequent operation can access these funds before they are unlocked. At the same time, the contract updates its internal counter, reducing the available balance and increasing the locked balance to ensure account balance.

[0113] Furthermore, the contract calls the event log interface to generate an exception record. The exception record details the exception type as a discrepancy in amount, the buyer's address, the actual amount transferred, the expected transaction amount, and the current block timestamp. This record is permanently stored as part of the blockchain transaction receipt.

[0114] Furthermore, these three data items are then assembled into a structured data packet according to the predefined field order. Finally, the entire data packet is saved to the exclusive storage area allocated by the contract itself in the blockchain ledger through the contract's storage write interface. Once written, this data cannot be tampered with and becomes the legal basis for subsequent acceptance and settlement.

[0115] Furthermore, after performing multiple iterative operations on the sequence, the hash function outputs a fixed-length hash value as the encryption key for the segment. Finally, the system performs a bitwise XOR operation on each byte in the original data segment and the corresponding byte in the encryption key. The result of the XOR operation is the encrypted data segment. The system stores all encrypted data segments together with their respective segment numbers and encryption keys, ultimately obtaining the derived data segment of the target process.

[0116] In summary, by automatically capturing fund transfer transactions initiated by the buyer through smart contracts and immediately comparing the transferred amount with the transaction amount pre-written into the contract, this step directly links the payment behavior to the contractually agreed amount standard, eliminating subsequent disputes caused by insufficient or excessive payment amounts from the source. This establishes a clear and explicit payment verification checkpoint for the entire transaction process, ensuring that only funds that meet the agreement can enter the subsequent locking process.

[0117] In summary, once the payment amount is confirmed to be accurate, the funds lock-up mechanism is activated immediately, marking the funds transferred by the buyer as locked in the contract account and preventing them from being used at will. This operation transforms the buyer's payment funds into a performance bond strictly regulated by the contract rules, preventing the buyer from withdrawing funds before the transaction is completed and ensuring that the seller can receive payment after delivery. This provides equal fund security for both parties and builds a foundation of mutual trust.

[0118] In summary, when a discrepancy is detected between the payment amount and the agreed amount, the funds are immediately and automatically returned to the original payment method. At the same time, an immutable record of the anomaly is generated and stored on the blockchain. This mechanism protects the buyer's funds while fully recording abnormal events during the transaction process, preventing funds from being locked up for a long time or causing disputes due to incorrect amounts. The existence of the anomaly record also provides a reliable basis for both parties to the transaction or for regulators to trace and audit the transaction afterward.

[0119] In summary, by writing the key evidence of fund locking, including the precise locking time, the specific amount locked, and the blockchain identities of both parties to the transaction, into an immutable distributed ledger, the entire process of fund locking is permanently solidified on the blockchain, forming a legally valid digital notarization. This provides irrefutable factual evidence for subsequent delivery, acceptance, and fund transfer, and neither party can deny or tamper with the fact that the funds have been successfully locked.

[0120] In summary, by using the time factor representing the current moment and the identity factor representing the seller's identity as the basic materials for key generation, the delivered documents are segmented and encrypted. This mechanism ensures that the encryption key for each derived data segment is uniquely bound to a specific transaction process and the seller. Even if the same file is uploaded in different transactions, it will produce completely different encryption results due to different time factors, which greatly enhances the confidentiality and anti-attack capabilities of file storage. The segmentation operation also lays the data structure foundation for subsequent distributed storage and efficient verification.

[0121] In this embodiment of the invention, when the result delivery file is segmented and encrypted based on the time factor and identity factor of the target process to obtain the derived data segment of the target process, it is specifically used for:

[0122] The deliverables are divided according to the data block boundaries of the transaction parameters to obtain the original data fragments of the target process;

[0123] The current timestamp of the target process, the blockchain identity identifier of the seller in the target process, and the fragment sequence number of the original data fragment are concatenated to obtain the key seed corresponding to the original data fragment.

[0124] Perform a hash operation on the key seed to obtain the encryption key for the original data fragment;

[0125] Perform a bitwise XOR operation between the original data fragment and the encryption key to obtain the encrypted data fragment of the original data fragment;

[0126] The fragment number, the encrypted data fragment, and the encryption key are associated and stored to obtain the derived data segment of the target process.

[0127] Specifically, the system parses out the definition of the data block boundary, which specifies the byte length standard used when splitting the file. The system then locates the complete path of the deliverable file uploaded by the seller in the temporary storage area and opens the file in binary read-only mode.

[0128] Specifically, the system obtains the timestamp of the latest block in the current blockchain network as the current timestamp, and extracts the seller's blockchain identity identifier from the transaction parameters. The system traverses each raw data shard, reads the shard number corresponding to the shard, and then concatenates the current timestamp, the seller's blockchain identity identifier, and the shard number in chronological order.

[0129] Specifically, the system calls the underlying hash function library, passing the key seed corresponding to each original data fragment as input data to the hash function. The hash function performs a series of complex permutations and compression operations on the input key seed byte sequence.

[0130] Specifically, the system loads the original data fragments and corresponding encryption keys into memory simultaneously, and processes them byte by byte, starting from the first byte of the two data sequences, comparing the binary representations of the two bytes during processing.

[0131] Specifically, the system creates a new data record table in the persistent storage area. This table contains three fields. The system writes the fragment number corresponding to the original data fragment being processed to the first field, writes the encrypted data fragment obtained after encrypting the fragment to the second field, and writes the encryption key used to generate the encrypted data fragment to the third field.

[0132] Furthermore, starting from the beginning byte of the file, each consecutive data byte is read sequentially according to the number of bytes specified in the data block boundary definition as the cutting unit until the end of the file is reached. The system treats the byte sequence obtained from each cutting as an independent storage unit and assigns a fragment number starting from zero to each unit according to the cutting order. The set of fragment numbers and byte sequences obtained after all cuttings are completed is the original data fragment of the target process.

[0133] Furthermore, during the splicing process, the original byte forms of these data are directly concatenated sequentially to form a continuous byte sequence. This byte sequence uniquely corresponds to the original data fragment currently being processed, and this newly generated byte sequence is the key seed corresponding to the original data fragment.

[0134] Furthermore, the operation process first fills the input data to a fixed length, then divides it into multiple data blocks. Each data block undergoes multiple rounds of iterative calculation with intermediate variables, and finally outputs a hash value of a fixed length. The length of this output hash value is consistent with the length of the original data fragment. The system uses this output hash value as the key for subsequent encryption operations. This hash value is the encryption key of the original data fragment.

[0135] Furthermore, for each bit, if the bit value of the current byte of the original data fragment is the same as the corresponding bit value of the current byte of the encryption key, then the bit of the result byte is set to zero; otherwise, the bit of the result byte is set to one. After the system has traversed all bytes, it obtains a new byte sequence. This new sequence has the same length as the original data fragment, but its content has been completely obfuscated and cannot be read directly. This newly generated byte sequence is the encrypted data fragment of the original data fragment.

[0136] Furthermore, after the system has processed all the original data fragments in this way, the data record table contains information about all the fragments, and the complete data set formed by the entire record table is the derived data segment of the target process.

[0137] In summary, by strictly adhering to the pre-agreed data block boundary definitions in the transaction parameters and standardizing the cutting of the complete deliverable file, this operation splits a large overall file into multiple raw data fragments of uniform size and clear boundaries. This creates structured data units for subsequent encryption processing and distributed storage, allowing each fragment to be processed and transmitted independently, significantly improving data processing efficiency. At the same time, the standardized fragment size also provides a unified metrological basis for subsequent key generation and index construction.

[0138] In summary, by sequentially concatenating the current timestamp representing the moment the transaction occurred, the unique identifier representing the seller's identity, and the fragment sequence number identifying the fragment order, a unique key seed is generated for each original data fragment. This concatenation method ensures that the key seeds of different fragments in the same transaction are different from each other. Even if the same seller uploads the same file in different transactions, completely different key seeds will be generated due to different timestamps, fundamentally eliminating the security risk of key reuse.

[0139] In summary, using a hash function to process the key seed ensures that small changes in the input will lead to huge differences in the output. At the same time, the original key seed cannot be derived from the output encryption key. This mechanism transforms a readable information seed with a certain pattern into a completely randomized and fixed-length encryption key, giving the encryption key extremely high resistance to cracking and providing cryptographically strong security for subsequent data encryption.

[0140] In summary, by employing the reversible encryption operation of bitwise XOR, each byte in the original data fragment is compared and transformed bit by bit with the corresponding byte in the encryption key. The characteristics of XOR operation allow the same key to be used for both encryption and decryption simultaneously, and the operation process is simple and efficient. This operation completely obfuscates the original readable data content, generating encrypted data fragments that cannot be directly identified, ensuring that even if the delivered file is illegally obtained in the distributed storage network, its true content cannot be deciphered.

[0141] In summary, by storing the fragment number corresponding to each original data fragment, the encrypted data fragment, and the encryption key used for decryption as a whole unit, a self-contained data storage structure is formed. This associated storage method ensures that the fragment number can be accurately located during subsequent file reconstruction, and the corresponding encryption key can be obtained immediately for decryption without the need to maintain a complex key management table. This greatly simplifies the data recovery process and reduces the risk of key loss.

[0142] In this embodiment of the invention, the step of distributing the derived data segment to the distributed storage node of the target process, and combining the storage address and content hash value returned by the distributed storage node into a shard index list of the target process according to the agreed format in the transaction parameters, is specifically used for:

[0143] Calculate the node adaptability of the derived data segment based on the current load value and historical response time of the distributed storage node;

[0144] Based on the node adaptability, the optimal storage node is selected for the derived data segment to obtain the target storage node for the derived data segment;

[0145] The derived data segment is sent to the corresponding target storage node, and the storage location identifier and data content hash value returned by the target storage node are received to obtain the index entry of the derived data segment;

[0146] The index entries are arranged in order of the fragment number of the derived data segment to obtain the fragment index list of the target process.

[0147] Specifically, for each storage node, the system extracts its current load value, which reflects the number of tasks the node is currently processing or the percentage of resources it is using. It also extracts its historical response time, which is the average time the node takes to respond to storage requests over a period of time. In addition, the system also obtains the network bandwidth value, historical availability rate, and storage cost coefficient for each node. These data together form the basis for calculating the node adaptability.

[0148] Specifically, after the system completes the fitness calculation for all available storage nodes, it obtains a set of fitness values ​​corresponding to the derived data segment. Each value precisely identifies the overall suitability of the corresponding node for storing that data segment. The system then initiates a node selection process, traversing the entire fitness value set and comparing the size of each value one by one. During the comparison process, the system continuously records the maximum fitness value encountered and the identifier of the storage node that generated that value.

[0149] Specifically, the system establishes a network connection with the target storage node, encapsulates the derived data segment into a data packet according to the data transmission format specified by the distributed storage protocol, and sends it. During the transmission process, the system adopts a breakpoint resume mechanism to ensure that the data arrives completely. After the target storage node receives the derived data segment completely, it writes it into its own local storage system and assigns it a globally unique storage location identifier. This identifier is usually a string composed of the node's internal path and file name, which can accurately locate the storage location of the data in the node.

[0150] Specifically, the system reads the fragment number field from all index entries. This field is an integer that increments from zero, reflecting the order in which the original deliverable file was segmented. The system uses the fragment number as the sorting key to perform an ascending sort operation on all index entries. During the sorting process, the system compares the fragment numbers of every two entries, placing the entry with the smaller fragment number first and the entry with the larger fragment number second, ensuring that the sorted order is completely consistent with the data block order of the original file.

[0151] Furthermore, the system compares the network bandwidth value of each node with the maximum network bandwidth value of all nodes in the entire network, and obtains a bandwidth factor by calculating the ratio of the bandwidth value to the maximum value. Similarly, it compares the historical availability rate of each node with the maximum historical availability rate of all nodes to obtain an availability factor. For the current load value, the system uses it as a base value and performs a calculation based on a load weight index to reflect the inverse impact of load on adaptability. Specifically, the load value is transformed and combined with the bandwidth factor and availability factor. For historical response time, the system processes it using a response time weight index to generate a response time impact factor. The larger the factor value, the slower the response and the lower the contribution to adaptability. For the storage cost coefficient, the system processes it using a cost attenuation coefficient to obtain a cost factor. The smaller the factor value, the lower the cost and the higher the contribution to adaptability. Finally, the system multiplies the bandwidth factor, availability factor, load impact factor, response time impact factor, and cost factor, and introduces a natural constant for adjustment to ultimately calculate the adaptability value of each storage node for the current derived data segment.

[0152] Furthermore, after traversing all nodes, the system determines that the storage node with the highest fitness value is the optimal choice. The system extracts the network address and identity of this node from the candidate list and designates it as the designated node for storing the current derived data segment. The system writes the information of this node into a temporary storage area and marks it as the target storage node. All subsequent transmission operations related to this derived data segment will be performed only on this selected target storage node. This selection process ensures that the derived data segment is always assigned to the node that is most suitable for storing it under the current network conditions.

[0153] Furthermore, the target storage node simultaneously performs a hash operation on the received derived data segment to generate a fixed-length data content hash value. This hash value serves as the digital fingerprint of the derived data segment for subsequent data integrity verification. The target storage node packages the storage location identifier and the data content hash value into a response message and returns it to the system. After receiving the response, the system associates these two returned data with the fragment sequence number of the current derived data segment, combining them into a triplet data record containing the fragment sequence number, storage location identifier, and data content hash value. This record is the index entry for the derived data segment.

[0154] Furthermore, all sorted index entries are sequentially written into a continuous data structure to form an ordered list. The first item in the list corresponds to the first data fragment of the file, and the last item corresponds to the last data fragment of the file. The entire list completely records the storage location and content fingerprint of all derived data segments in the distributed storage network. This finally generated ordered list is the fragment index list of the target process.

[0155] In summary, by comprehensively considering the real-time operating status of each storage node, including the current load value reflecting the node's current busyness and the historical response time reflecting the node's past performance, and by fusing and calculating these raw monitoring data, multi-dimensional performance indicators that are difficult to compare directly are transformed into unified and quantifiable fit values. This transformation provides an objective basis for the scientific evaluation of candidate storage nodes for each derived data segment, so that subsequent node selection no longer relies on random allocation or simple round-robin, but is based on comprehensive performance data.

[0156] In summary, after calculating the fitness scores of all candidate nodes, the node with the highest fitness score is determined as the target storage node by comparing them one by one. This selection mechanism ensures that each derived data segment can be allocated to the storage node with the best overall performance in the current network environment, thereby obtaining the best storage service in terms of bandwidth resources, processing power, response speed, and other aspects, maximizing the efficiency and reliability of data storage, while avoiding storage bottlenecks or access delays caused by improper node selection.

[0157] In summary, by accurately sending the derived data segment to the previously selected optimal node and receiving the storage location identifier and data content hash value returned by the node after successful storage, these two returned data solve the core problems of how to find the data and how to verify its integrity. The storage location identifier provides precise data location information, while the data content hash value serves as the unique digital fingerprint of the data for integrity verification. The combination of the two constitutes a complete index entry, laying a solid foundation for subsequent data retrieval and verification.

[0158] In summary, by arranging all derived data segment index entries in ascending order of fragment number, the originally scattered and independent index information is integrated into a structured and complete list. This ordered fragment index list fully records the precise location of all fragments of the original deliverable file in the distributed storage network and their corresponding content fingerprints, providing a clear roadmap for subsequent file reconstruction. When acceptance or verification is required, the system only needs to traverse this ordered list to locate and retrieve all data fragments in the correct order, ensuring the accuracy and integrity of file restoration.

[0159] In this embodiment of the invention, the formula for calculating the node adaptability is specifically used for:

[0160]

[0161] in, For the first The derived data segment and the first The adaptability of each storage node For the index of derived data segments, For the index of the storage node, For the first Network bandwidth value of each storage node This represents the maximum network bandwidth value in the storage node. To indicate the first Historical availability of each storage node This represents the maximum historical availability among the storage nodes. For the first The current load value of each storage node. It is a very small constant. This is the load weighting index. For the first Historical response time of each storage node In response to the duration-weighted index, It is a natural constant. For the first Storage cost coefficient for each storage node This is the cost attenuation coefficient.

[0162] Specifically, the system obtains real-time monitoring data of all storage nodes from the node status database of the distributed storage network. The network bandwidth value comes from the network interface rate measurement results reported by the nodes periodically. The historical availability rate comes from the ratio of the node's online time to the total time over a period of time. The current load value comes from the comprehensive calculation of the real-time utilization rate of the node's central processing unit and memory. The historical response time comes from the average value of the node's response time to previous storage requests. The storage cost coefficient comes from the unit storage cost set by the service provider to which the node belongs. The maximum network bandwidth value and the maximum historical availability rate are obtained by comparing the corresponding data of all nodes and taking the maximum value. The minimum constant is a pre-set very small positive number to avoid the case where the denominator is zero. The load weight index, response time weight index, and cost attenuation coefficient are fixed values ​​pre-configured by the system according to the network environment and service policies. The natural constant is a fixed constant in mathematics.

[0163] Furthermore, the fit calculation comprehensively measures the performance of storage nodes across multiple dimensions. The first ratio factor reflects the relative level of the node's network bandwidth; the higher the bandwidth, the larger this factor. The second ratio factor reflects the relative level of the node's historical availability; the higher the availability, the larger this factor. The third factor reflects the reverse impact of the node's current load; the higher the load, the smaller this factor, and the sensitivity of the load impact is adjusted by a load weight index. The fourth factor reflects the reverse impact of the node's historical response time; the longer the response, the smaller this factor, and the sensitivity of the response time impact is adjusted by a response time weight index. The fifth factor reflects the reverse impact of storage costs; the higher the cost, the smaller this factor, and the decay rate of the cost impact is adjusted by a cost decay coefficient. The result of multiplying all factors is the fit, and the larger the value, the more suitable the node is for storing the current derived data segment.

[0164] In summary, as the network bandwidth of a storage node increases, the first ratio factor increases, and the fit also improves. As the historical availability of a storage node increases, the second ratio factor increases, and the fit also improves. As the current load of a storage node increases, the third factor decreases, and the fit decreases. Moreover, the larger the load weight index, the stronger the attenuation effect of increased load on fit. As the historical response time of a storage node increases, the fourth factor decreases, and the fit decreases. Moreover, the larger the response time weight index, the stronger the attenuation effect of increased response time on fit. As the storage cost coefficient of a storage node increases, the fifth factor decreases, and the fit decreases. Moreover, the larger the cost attenuation coefficient, the stronger the attenuation effect of increased cost on fit. The overall trend of fit is to favor storage nodes with high bandwidth, high availability, low load, fast response, and low cost.

[0165] In this embodiment of the invention, when performing byte verification between the digital certificate information of the delivered file in the shard index list and the seller's digital certificate sample in the transaction parameters to obtain the content acceptance result of the target process, it is specifically used for:

[0166] Based on the byte position and byte length marked in the transaction parameters, the byte sequence at the corresponding position will be extracted from the delivery file of the shard index list as the digital certificate information of the target process;

[0167] The digital voucher information is compared byte by byte with the seller's digital voucher sample to obtain the byte record sequence of the target process;

[0168] If all byte values ​​in the byte record sequence are the same, a positive acceptance result for the target process is generated.

[0169] If there are differing bytes in the byte record sequence, then a reverse acceptance result of the target process is generated.

[0170] Specifically, the system first parses two key fields from the transaction parameter structure stored in the blockchain ledger: byte position and byte length. These two fields are agreed upon by both parties before the transaction is completed and written into the transaction parameters. The byte position indicates the starting offset of the digital certificate information in the delivery file, and the byte length indicates the total amount of data to be extracted.

[0171] Specifically, the system reads the digital certificate sample submitted by the seller in advance when the transaction is created from the persistent storage area of ​​the contract. This sample is a standard byte sequence provided by the seller and is used as a standard reference for subsequent comparison. The system loads the digital certificate information just captured and the digital certificate sample into two independent comparison buffers at the same time, and compares them byte by byte starting from the first byte of the two buffers.

[0172] Specifically, the system iterates through the generated byte record sequence and checks each element in the sequence to determine if it is a difference identifier. If, after the traversal is completed, it is found that there are no difference identifiers in the entire byte record sequence, that is, all elements are the original identical byte values, the system immediately executes the acceptance result generation function inside the contract.

[0173] Specifically, during the traversal and inspection of the byte record sequence, if any element is found to be a difference identifier, the subsequent inspection process is immediately terminated. The system confirms that there is at least one case where the byte values ​​are different in the current byte record sequence, and then the system executes the acceptance result generation function inside the contract.

[0174] Furthermore, based on the storage location identifier and data content hash value recorded in the shard index list, the delivery file is completely obtained from the distributed storage node. After the delivery file is loaded into memory, the system takes the byte position as the starting point and continuously reads the number of bytes of data specified by the byte length from that starting point. The final continuous byte sequence read is the digital credential information of the target process.

[0175] Furthermore, during the comparison, the system checks whether the binary values ​​of the two bytes are exactly the same and records the result of each comparison as a byte value. If they are the same, the original byte value is recorded; if they are different, a difference identifier is recorded. The system continues this process until all bytes have been compared. The final sequence of all comparison results is the byte record sequence of the target process.

[0176] Furthermore, the function creates a new result data structure, writes a positive identifier code representing successful acceptance into the result type field of the data structure, and outputs the entire data structure as the return value of the function. The system persistently stores this output value in the contract state. This final generated result data is the positive acceptance result of the target process.

[0177] Furthermore, the function creates a new result data structure, writes a reverse identifier code representing the failure of acceptance into the result type field of the data structure, and outputs the entire data structure as the return value of the function. The system persists the output value to the contract state. This final generated result data is the reverse acceptance result of the target process.

[0178] In summary, by strictly adhering to the byte positions and lengths agreed upon by both parties in the transaction parameters, a byte sequence is precisely extracted from the delivery file restored through the fragmented index list as digital credential information. This operation transforms abstract file content verification into precise extraction of specific data fragments, avoiding the enormous computational overhead and network transmission burden caused by verifying the entire massive file. Furthermore, since the extraction position and length are agreed upon before the transaction, it ensures that the seller cannot guarantee the quality of only partial data while ignoring the integrity of the overall file by knowing the verification scope in advance. This provides a focused and efficient verification object for the acceptance phase.

[0179] In summary, the extracted digital certificate information is rigorously compared byte by byte with the digital certificate sample submitted by the seller and fixed on the blockchain before the transaction. This process verifies the authenticity of the document content at the granular level of each byte. Any tiny differences will be accurately captured. The byte record sequence completely records the specific situation of each byte position during the comparison process, providing an irrefutable original chain of evidence for the subsequent acceptance conclusion, and ensuring the transparency and traceability of the acceptance process.

[0180] In summary, after confirming that the byte values ​​at all positions in the byte record sequence are completely consistent with the sample, an acceptance result carrying a positive identification code is automatically generated. This positive acceptance result serves as the authoritative trigger signal for the smart contract to automatically execute subsequent fund transfers, meaning that the documents delivered by the seller have passed the verification standards agreed upon by both parties. The payment process can be initiated without any manual intervention, greatly shortening the settlement cycle of technology transaction and eliminating the possibility of the buyer maliciously delaying or unreasonably refusing to pay.

[0181] In summary, once a byte value at any position in the byte record sequence is found to be inconsistent with the sample, the comparison is immediately stopped and an acceptance result carrying a reverse identifier is generated. This reverse acceptance result serves as the authoritative instruction to initiate the fund return mechanism, clearly indicating to the smart contract that the delivered document has failed acceptance. The contract will automatically execute the fund return operation based on this result. The entire process eliminates the subjective factors of human judgment, protecting the buyer's funds in the event of seller default, and providing the seller with clear feedback on delivery failure, thus avoiding long-term disputes caused by ambiguous acceptance standards.

[0182] In this embodiment of the invention, when determining the direction of fund transfer between the two parties in the target process based on the settlement identifier of the content acceptance result, it is specifically used for:

[0183] If the value of the settlement identifier field in the content acceptance result is a positive transfer code, the contract account in the target process executes a fund transfer instruction, and the transaction funds deducted from the balance of the contract account are added to the account balance corresponding to the blockchain identity identifier of the seller in the target process. At the same time, a positive transfer record containing the transaction hash value, the transferor address, the receiver address, the transfer amount, and the transfer timestamp is generated.

[0184] If the value of the settlement identifier field is a reverse return code, the contract account executes a fund return instruction, which adds the transaction funds deducted from the balance of the contract account to the account balance corresponding to the blockchain identity identifier of the buyer in the target process, and generates a reverse return record containing the transaction hash value, the sender address, the receiver address, the return amount, and the return timestamp.

[0185] Specifically, the system reads the specific value of the settlement identifier field from the data structure of the content acceptance result, compares the value with the predefined positive transfer code constant in the contract code, and when the two are determined to be completely equal, the system immediately triggers the fund transfer instruction of the contract account. This instruction first calls the balance management interface provided by the underlying blockchain to deduct the amount of funds equal to the transaction amount in the transaction parameters from the locked balance sub-account of the contract account.

[0186] Specifically, the system reads the specific value of the settlement identifier field from the data structure of the content acceptance result, compares the value with the predefined reverse return code constant in the contract code, and when it is determined that the two are completely equal, the system immediately triggers the fund return instruction of the contract account. This instruction first calls the balance management interface provided by the underlying blockchain to deduct the amount of funds equal to the transaction amount in the transaction parameters from the locked balance sub-account of the contract account.

[0187] Furthermore, by calling the same interface to add the same amount of funds to the account balance corresponding to the seller's blockchain identity, this deduction and addition operation forms an atomic asset transfer record in the ledger through the consensus mechanism of the blockchain network, ensuring that the transfer of funds from the contract account to the seller's account is complete and irreversible. After the fund transfer is completed, the system obtains the globally unique hash value of the current transaction as the transaction hash value, uses the contract account address as the sender address, the seller's blockchain identity address as the receiver address, the actual transaction amount transferred as the transfer amount, and extracts the timestamp from the current block header as the transfer timestamp. The system assembles these five data elements into a structured data record according to the predefined field order and permanently writes this record to the event log area of ​​the blockchain. This finally generated data record is the aforementioned forward transfer record.

[0188] Furthermore, simultaneously calling the same interface to add the same amount of funds to the account balance corresponding to the buyer's blockchain identity identifier, this deduction and addition operation forms an atomic asset transfer record in the ledger through the consensus mechanism of the blockchain network, ensuring that the return process of funds from the contract account to the buyer's account is complete and irreversible. After the funds are returned, the system obtains the globally unique hash value of the current transaction as the transaction hash value, uses the address of the contract account as the sender address, the address of the buyer's blockchain identity identifier as the receiver address, the actual returned transaction amount as the return amount, and extracts the timestamp from the current block header as the return timestamp. The system assembles these five data elements into a structured data record according to the predefined field order and permanently writes this record into the event log area of ​​the blockchain. This finally generated data record is the reverse return record.

[0189] In summary, upon confirming the settlement identifier as a positive transfer code, the contract account is immediately triggered to execute a fund transfer instruction. The locked transaction funds are deducted from the contract account balance and fully added to the seller's account. This operation transforms the previously locked performance bond into the seller's actual income, achieving second-level automatic settlement of payments for technology transactions. This completely eliminates the time lag and credit risk associated with the seller waiting for payment after the buyer's payment in traditional transactions. Simultaneously, the generated positive transfer record completely writes the transaction hash value, sender's address, receiver's address, transfer amount, and transfer timestamp onto the blockchain. This immutable payment certificate provides the seller with legally valid proof of receipt, offering irrefutable on-chain evidence for subsequent tax declarations, financial audits, or potential dispute resolution.

[0190] In summary, upon confirming the settlement identifier as a reverse return code, the contract account is immediately triggered to execute a fund return instruction. The locked transaction funds are deducted from the contract account balance and fully returned to the buyer's account. This operation automatically returns funds to the buyer if the seller's delivered documents fail acceptance, eliminating the need for the buyer to initiate a refund request or pursue legal action, thus maximizing the buyer's fund security. Simultaneously, the generated reverse return record completely writes the transaction hash value, sender's address, receiver's address, return amount, and return timestamp onto the blockchain. This transparent return certificate clearly demonstrates the complete trajectory of the fund return to both parties, proving that the contract has been fairly executed according to the acceptance results and providing solid on-chain evidence for the buyer to subsequently re-trade or pursue the seller's liability for breach of contract.

[0191] Compared with the prior art, the present invention has the following beneficial effects:

[0192] 1. This smart contract-based automatic settlement method for technology transaction funds achieves the codification and decentralized execution of transaction rules by compiling transaction parameters into contract bytecode and deploying it to the blockchain. The transaction funds paid by the buyer are locked in an account uniquely identified by the contract address, with complete control over the funds entrusted to a transparent and tamper-proof smart contract. This mechanism ensures the security of funds throughout the entire transaction cycle. Only when the agreed acceptance conditions are met will the automatic transfer operation be triggered based on the settlement identifier, accurately and promptly transferring the funds to the seller's account. The entire process eliminates human intervention and the credit endorsement of intermediaries, fundamentally improving settlement efficiency. Every change in the state of the fund flow generates an irrefutable record on the blockchain ledger, providing both parties with extremely high fund security and process transparency.

[0193] 2. In processing the delivery content of scientific and technological achievements, this method introduces encrypted fragmentation and distributed storage technologies. The delivery files uploaded by the seller are segmented and encrypted based on time and identity factors to generate derived data segments uniquely bound to the transaction. These segments are then distributed to distributed storage nodes, and an ordered fragmentation index list is constructed. This processing method not only ensures the confidentiality and integrity of the delivery data during transmission and storage, but also generates objective and accurate content acceptance results by automatically comparing the digital voucher information in the fragmentation index list with the seller's preset digital voucher samples at the byte level. The acceptance process is entirely based on preset byte positions and lengths for automatic verification, eliminating subjective judgment and human delays, ensuring the uniformity of acceptance standards and the fairness of execution results, and providing a reliable and irrefutable basis for the subsequent automatic transfer of funds.

[0194] like Figure 2 The diagram shown is a functional block diagram of an automatic settlement system for technology transaction funds based on smart contracts, provided in an embodiment of the present invention.

[0195] The smart contract-based automatic settlement system 100 for technology transaction funds described in this invention can be installed in an electronic device. Depending on the functions implemented, the smart contract-based automatic settlement system 100 may include a contract bytecode module 101, a contract address module 102, a derived data segment module 103, a fragment index list module 104, a content acceptance module 105, and a transfer direction module 106. The module described in this invention can also be called a unit, which refers to a series of computer program segments that can be executed by the processor of an electronic device and can perform a fixed function, and are stored in the memory of the electronic device.

[0196] In this embodiment, the functions of each module / unit are as follows:

[0197] The contract bytecode module compiles the transaction parameters of the target process based on the transaction intention of the target process to obtain the contract bytecode of the target process;

[0198] The contract address module deploys the contract bytecode to the blockchain network of the target process to obtain the contract address of the target process;

[0199] The derived data segment module locks the transaction funds paid by the buyer in the target process into the contract account corresponding to the contract address, and encrypts and fragments the deliverable files uploaded by the seller in the target process to obtain the derived data segment of the target process.

[0200] The sharding index list module distributes the derived data segments to the distributed storage nodes of the target process, and combines the storage addresses and content hash values ​​returned by the distributed storage nodes into a sharding index list of the target process according to the format agreed in the transaction parameters.

[0201] The content acceptance module performs byte verification between the digital certificate information of the delivered files in the fragment index list and the seller's digital certificate sample in the transaction parameters to obtain the content acceptance result of the target process.

[0202] The fund allocation direction module determines the fund allocation direction between the two parties in the target process based on the settlement identifier of the content acceptance result.

[0203] In the several embodiments provided by this invention, it should be understood that the disclosed methods and systems can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and other division methods may be used in actual implementation.

[0204] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0205] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules.

[0206] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0207] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence is the theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

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

Claims

1. A method for automatic settlement of funds in technology transfer transactions based on smart contracts, characterized in that, The method includes: The transaction parameters of the target process are compiled based on the transaction intention of the target process to obtain the contract bytecode of the target process; The contract bytecode is deployed to the blockchain network of the target process to obtain the contract address of the target process; The transaction funds paid by the buyer during the target process are locked into the contract account corresponding to the contract address, and the deliverable files uploaded by the seller during the target process are encrypted and fragmented to obtain the derived data segment of the target process, including: The deliverables are divided according to the data block boundaries of the transaction parameters to obtain the original data fragments of the target process; The current timestamp of the target process, the blockchain identity identifier of the seller in the target process, and the fragment sequence number of the original data fragment are concatenated to obtain the key seed corresponding to the original data fragment. Perform a hash operation on the key seed to obtain the encryption key for the original data fragment; Perform a bitwise XOR operation between the original data fragment and the encryption key to obtain the encrypted data fragment of the original data fragment; The fragment sequence number, the encrypted data fragment, and the encryption key are associated and stored to obtain the derived data segment of the target process; The derived data segments are distributed to the distributed storage nodes of the target process, and the storage addresses and content hash values ​​returned by the distributed storage nodes are combined according to the format agreed upon in the transaction parameters to form a shard index list for the target process, including: Calculate the node adaptability of the derived data segment based on the current load value and historical response time of the distributed storage node; Based on the node adaptability, the optimal storage node is selected for the derived data segment to obtain the target storage node for the derived data segment; The derived data segment is sent to the corresponding target storage node, and the storage location identifier and data content hash value returned by the target storage node are received to obtain the index entry of the derived data segment; The index entries are arranged in order of the fragment number of the derived data segment to obtain the fragment index list of the target process; The digital certificate information of the delivered files in the fragmented index list is compared with the seller's digital certificate sample in the transaction parameters by byte verification to obtain the content acceptance result of the target process. The direction of fund transfer between the two parties in the target process is determined based on the settlement identifier of the acceptance result of the content.

2. The method for automatic settlement of funds in technology transfer transactions based on smart contracts as described in claim 1, characterized in that, The transaction parameters of the target process are compiled based on the transaction intention of the target process to obtain the contract bytecode of the target process, including: The transaction parameters of both parties in the target transaction process are obtained. The transaction parameters include the hash value of the transaction target, the transaction amount, the delivery deadline, the acceptance deadline, and the blockchain identity identifiers of both parties. The transaction parameters are converted into the initial parameter byte stream of the target process according to the calibrated bytecode format of the target process; The initial parameter byte stream is encapsulated to obtain the contract bytecode of the target process.

3. The method for automatic settlement of funds in technology transfer transactions based on smart contracts as described in claim 1, characterized in that, The step of deploying the contract bytecode to the blockchain network of the target process to obtain the contract address of the target process includes: The deployment transaction format of the blockchain network is determined, and the deployment transaction format includes a transaction initiator identifier, a transaction recipient identifier, and a transaction data field; The transaction initiator identifier is set as the contract deployment identifier, the transaction receiver identifier is set as the contract creation identifier, and the contract bytecode is filled into the transaction data field to obtain the transaction payload body of the blockchain network; The hash value of the transaction payload is digitally signed based on the private key corresponding to the contract deployment identifier to obtain the signature data of the blockchain network. The transaction payload body is assembled with the signature data to obtain the transaction payload of the blockchain network; Based on the valid bytecode of the transaction payload, a contract instance corresponding to the target process is generated in the ledger of the blockchain network, and the storage location of the contract instance is used as the contract address of the target process.

4. The method for automatic settlement of funds in technology transfer transactions based on smart contracts as described in claim 1, characterized in that, The step of locking the transaction funds paid by the buyer during the target process into the contract account corresponding to the contract address includes: The transfer amount of the fund transfer transaction initiated by the buyer to the contract address during the target process is compared with the transaction amount value in the transaction parameters; If the transferred amount is consistent with the transaction amount, the fund lock operation of the contract account is triggered, and the funds corresponding to the transferred amount are marked as locked. If the transferred amount is inconsistent with the transaction amount, the fund rejection operation of the contract account is triggered, the funds corresponding to the transferred amount are returned to the account corresponding to the blockchain identity of the buyer in the target process, and an abnormal record of the amount discrepancy is generated. The lock timestamp, lock amount, and blockchain identity identifiers of both parties generated based on the lock status are written into the ledger of the blockchain network.

5. The method for automatic settlement of funds in technology transfer transactions based on smart contracts as described in claim 1, characterized in that, The formula for calculating the node adaptability includes: in, For the first The derived data segment and the first The adaptability of each storage node For the index of derived data segments, For the index of the storage node, For the first Network bandwidth value of each storage node This represents the maximum network bandwidth value in the storage node. For the first Historical availability of each storage node This represents the maximum historical availability among the storage nodes. For the first The current load value of each storage node. It is a very small constant. This is the load weighting index. For the first Historical response time of each storage node In response to the duration-weighted index, It is a natural constant. For the first Storage cost coefficient for each storage node This is the cost attenuation coefficient.

6. The method for automatic settlement of funds in technology transfer transactions based on smart contracts as described in claim 1, characterized in that, The step of performing byte verification between the digital certificate information of the delivered files in the fragmented index list and the seller's digital certificate sample in the transaction parameters to obtain the content acceptance result of the target process includes: Based on the byte position and byte length marked in the transaction parameters, the byte sequence at the corresponding position will be extracted from the delivery file of the shard index list as the digital certificate information of the target process; The digital voucher information is compared byte by byte with the seller's digital voucher sample to obtain the byte record sequence of the target process; If all byte values ​​in the byte record sequence are the same, a positive acceptance result for the target process is generated. If there are differing bytes in the byte record sequence, then a reverse acceptance result of the target process is generated.

7. The method for automatic settlement of funds in technology transfer transactions based on smart contracts as described in claim 1, characterized in that, The process of determining the direction of fund transfer between the two parties in the target transaction based on the settlement identifier of the content acceptance result includes: If the value of the settlement identifier field in the content acceptance result is a positive transfer code, the contract account in the target process executes a fund transfer instruction, and the transaction funds deducted from the balance of the contract account are added to the account balance corresponding to the blockchain identity identifier of the seller in the target process. At the same time, a positive transfer record containing the transaction hash value, the transferor address, the receiver address, the transfer amount, and the transfer timestamp is generated. If the value of the settlement identifier field is a reverse return code, the contract account executes a fund return instruction, which adds the transaction funds deducted from the balance of the contract account to the account balance corresponding to the blockchain identity identifier of the buyer in the target process, and generates a reverse return record containing the transaction hash value, the sender address, the receiver address, the return amount, and the return timestamp.

8. A smart contract-based automatic settlement system for technology transfer transactions, used to implement the smart contract-based automatic settlement method for technology transfer transactions as described in any one of claims 1-7, characterized in that, The system includes: The contract bytecode module compiles the transaction parameters of the target process based on the transaction intention of the target process to obtain the contract bytecode of the target process; The contract address module deploys the contract bytecode to the blockchain network of the target process to obtain the contract address of the target process; The derived data segment module locks the transaction funds paid by the buyer in the target process into the contract account corresponding to the contract address, and encrypts and fragments the deliverable files uploaded by the seller in the target process to obtain the derived data segment of the target process, including: The deliverables are divided according to the data block boundaries of the transaction parameters to obtain the original data fragments of the target process; The current timestamp of the target process, the blockchain identity identifier of the seller in the target process, and the fragment sequence number of the original data fragment are concatenated to obtain the key seed corresponding to the original data fragment. Perform a hash operation on the key seed to obtain the encryption key for the original data fragment; Perform a bitwise XOR operation between the original data fragment and the encryption key to obtain the encrypted data fragment of the original data fragment; The fragment sequence number, the encrypted data fragment, and the encryption key are associated and stored to obtain the derived data segment of the target process; The sharding index list module distributes the derived data segments to the distributed storage nodes of the target process, and combines the storage addresses and content hash values ​​returned by the distributed storage nodes into a sharding index list of the target process according to the format agreed in the transaction parameters, including: Calculate the node adaptability of the derived data segment based on the current load value and historical response time of the distributed storage node; Based on the node adaptability, the optimal storage node is selected for the derived data segment to obtain the target storage node for the derived data segment; The derived data segment is sent to the corresponding target storage node, and the storage location identifier and data content hash value returned by the target storage node are received to obtain the index entry of the derived data segment; The index entries are arranged in order of the fragment number of the derived data segment to obtain the fragment index list of the target process; The content acceptance module performs byte verification between the digital certificate information of the delivered files in the fragment index list and the seller's digital certificate sample in the transaction parameters to obtain the content acceptance result of the target process. The fund allocation direction module determines the fund allocation direction between the two parties in the target process based on the settlement identifier of the content acceptance result.

Images