Block chain-based cross-border transaction method and device, computer equipment and storage medium

Abstract

The invention relates to the technical field of information processing, and discloses a cross-border transaction method and device based on a block chain, computer equipment and a storage medium, and the method comprises the steps: receiving a transaction request for goods; performing feature extraction and alignment processing on the image data and the attribute data to generate a joint semantic vector; inputting the joint semantic vector into a neural network model to output a transaction risk index; generating a contract calling instruction according to the risk index; sending an instruction to the block chain to execute a corresponding contract function; on-chain event data generated by execution of the function is obtained, and a transaction processing credential is generated based on the on-chain event data. According to the method, the recognition accuracy of the complex transaction risk is improved by fusing the multi-modal data, an automatic credible closed loop from risk judgment to disposal is realized by means of the block chain smart contract, and the problems of low efficiency and insufficient execution credibility caused by single data dimension and dependence on manual intervention in the prior art are effectively solved.

Description

Technical Field

[0001] This invention relates to the field of information processing technology, and in particular to a blockchain-based method, apparatus, computer equipment, and storage medium for cross-border transactions. Background Technology

[0002] In current cross-border logistics and fund settlement transactions, ensuring transaction security is a core requirement. Existing technological solutions typically employ isolated, segmented processing models, which have limitations in overall efficiency, accuracy of judgment, and reliability of execution. For example, a common practice is to set rules so that when the system scans and identifies that key electronic documents such as delivery orders are compliant in format and valid in signature, it automatically triggers the bank's payment interface to complete the payment. This risk control model heavily relies on the authenticity of a single dimension of data (i.e., the document itself), revealing significant shortcomings in complex cross-border scenarios: even if the documents are authentic and valid, goods may still be switched during transportation, or the warehousing environment may be out of control, resulting in damage to goods while the document process remains complete. Existing technologies struggle to effectively identify such compound risks of "difference between documents and goods" or "out-of-control processes." Furthermore, when the system analysis indicates a risk to a batch of goods, it typically only generates a report and forwards it to manual review, requiring manual intervention by the bank or logistics system to freeze the goods. This process is not only slow and inefficient but also prone to introducing operational and ethical risks through human intervention. Summary of the Invention

[0003] Based on this, it is necessary to address the technical problems in existing technologies that rely on single-dimensional data to make it difficult to identify complex transaction risks and that risk handling relies on manual responses, resulting in low efficiency and insufficient credibility. Therefore, a blockchain-based cross-border transaction method, device, computer equipment, and storage medium are proposed.

[0004] Firstly, a blockchain-based cross-border transaction method is provided, the method comprising: The system receives a transaction request for goods, which includes: goods image data and goods attribute data. The goods attribute data includes document data, storage environment data, and logistics trajectory data. The goods image data includes: goods sealed image data and goods unsealed image data. Feature extraction and alignment are performed on the cargo image data and the cargo attribute data to generate a joint semantic vector; The joint semantic vector is input into a pre-trained neural network model, which then outputs a transaction risk index. A contract invocation instruction is generated based on the transaction risk index. The contract invocation instruction includes: the address of the target smart contract and the name of the target contract function in the target smart contract. Send the contract invocation instruction to the blockchain so that the blockchain executes the target contract function in the target smart contract; Obtain on-chain event data generated after the target contract function is executed, and generate a processing certificate for the transaction request based on the association information between the on-chain event data and the transaction request.

[0005] Secondly, a blockchain-based cross-border transaction device is provided, the device comprising: The receiving module is used to receive transaction requests for goods. The transaction requests include: goods image data and goods attribute data. The goods attribute data includes document data, storage environment data, and logistics trajectory data. The goods image data includes: goods sealed image data and goods unsealed image data. The processing module is used to perform feature extraction and alignment processing on the cargo image data and the cargo attribute data to generate a joint semantic vector; The output module is used to input the joint semantic vector into a pre-trained neural network model and output a transaction risk index. The generation module is used to generate a contract invocation instruction based on the transaction risk index. The contract invocation instruction includes: the address of the target smart contract and the name of the target contract function in the target smart contract. The sending module is used to send the contract call instruction to the blockchain so that the blockchain executes the target contract function in the target smart contract. The acquisition module is used to acquire on-chain event data generated after the target contract function is executed, and to generate a processing certificate for the transaction request based on the association information between the on-chain event data and the transaction request.

[0006] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described blockchain-based cross-border transaction method.

[0007] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the aforementioned blockchain-based cross-border transaction method.

[0008] The beneficial effects of this application are: First, this application extracts multimodal features from cargo images and attribute data, and maps them to a unified semantic space using a pre-trained model. This allows subsequent models to make judgments based on a feature vector that fully represents the overall picture of the cargo, thereby enabling the discovery of cross-modal contradictions such as "abnormal sealing images but compliant documents" or "normal logistics trajectory but abnormal temperature and humidity records." This solves the defect of existing technologies that cannot identify complex risks due to isolated data.

[0009] Secondly, based on a quantified transaction risk index, this application automatically matches and calls specific functions in the target smart contract through a predefined strategy to trigger operations such as fund freezing and payment. This can directly convert risk decisions into immutable on-chain actions, reducing response time from hours to minutes or even seconds, thus solving the problem of low efficiency. All rules and executions are solidified on the blockchain through code, making the process open, transparent, and the results irrefutable. This avoids delays, errors, and moral hazards in manual operations, and improves the procedural fairness and high credibility of execution. Attached Figure Description

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

[0011] in: Figure 1 This is a diagram illustrating the application environment of a blockchain-based cross-border transaction method in one embodiment. Figure 2 This is a flowchart of a blockchain-based cross-border transaction method in one embodiment; Figure 3 This is a structural block diagram of a blockchain-based cross-border transaction device in one embodiment; Figure 4 This is a structural block diagram of a computer device in one embodiment. Detailed Implementation

[0012] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0013] The blockchain-based cross-border transaction method provided in this invention can be applied to, for example... Figure 1In this application environment, the client communicates with the server via a network. The client receives a transaction request for goods, which includes images of the sealed and unsealed goods, as well as attribute data including documents, storage environment, and logistics trajectory. Feature extraction and alignment are performed on the image and attribute data to generate a joint semantic vector. This joint semantic vector is input into a pre-trained neural network model, which outputs a transaction risk index. Based on the risk index, a contract call instruction containing the target smart contract address and the target function name is generated. The instruction is sent to the blockchain to execute the corresponding contract function. On-chain event data generated by the function execution is obtained, and a transaction processing certificate is generated based on this. This method improves the accuracy of identifying complex transaction risks by fusing multimodal data and achieves an automated and reliable closed loop from risk assessment to handling through blockchain smart contracts, effectively solving the problems of low efficiency and insufficient execution reliability caused by single data dimensions and reliance on manual intervention in existing technologies. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0014] Please see Figure 2 As shown, Figure 2 A flowchart illustrating a blockchain-based cross-border transaction method provided in an embodiment of the present invention includes the following steps: S1. Receive a transaction request for goods. The transaction request includes: goods image data and goods attribute data.

[0015] The computer equipment receives transaction requests for a batch of goods initiated by the shipper after confirming that the goods have arrived at the preset target cross-border region. The transaction request can be initiated manually by the shipper on their operating terminal after receiving a logistics arrival notification, or automatically by pre-configured automated rules linked to the logistics status system when certain conditions are met. The transaction request is transmitted to the computer equipment as an integrated data object, its core components including cargo image data and cargo attribute data. Cargo image data is mainly used for visual verification, with sealed packaging images being a key component, demonstrating the integrity of the packaging before and after cross-border transportation. Cargo attribute data provides multi-dimensional information such as the cargo's identity, history, and status, specifically covering document data proving the cargo's contents and ownership, storage environment data reflecting the warehousing environment before and after cross-border transportation, and logistics trajectory data detailing the entire path from the point of origin to the target cross-border region. After receiving the transaction request through a network service interface, the computer equipment executes the protocol to parse the data carried within. Subsequently, various data types undergo format and integrity verification to ensure their validity and compliance with predefined specifications. For example, this verifies that image clarity can be analyzed and that the logistics trajectory includes key nodes for destination customs clearance or receipt. Data that passes verification will be converted into a standardized representation format unified within the system for use in subsequent feature extraction processes.

[0016] For example, a batch of goods is shipped from location A in China to location C in the United States. The shipper sets up their logistics tracking system so that when the system detects that the status of the goods has been updated to "arrived at port B and cleared customs," it automatically sends a notification to the shipper's management system. Upon receiving the notification, the shipper initiates a transaction request for the goods on their supply chain management platform. The transaction request automatically associates and packages the following data, which is then sent to the processing server via the Internet: a photo of the sealed container taken when the goods left the warehouse in location A; electronic files of the commercial invoice and packing list for the goods; temperature and humidity sensor records of the container during transportation from the warehouse in location A to the port area in location B; and the complete logistics node trajectory of sea freight and port customs clearance. The application interface of the computer equipment receives the request data packet, parses it, and extracts image files, document text, environmental sensor data sequences, and trajectory information. The system verifies that all data is complete and that the logistics trajectory does indeed contain the "customs clearance completed at port B" status node. Subsequently, the image is converted into a standard pixel matrix, and the text and environmental data are converted into structured data tables, completing the receiving and preprocessing process.

[0017] S2. Perform feature extraction and alignment processing on cargo image data and cargo attribute data to generate a joint semantic vector.

[0018] The feature extraction process handles two types of data in parallel. For cargo image data, the computer uses a pre-trained deep convolutional neural network model. This model receives a standardized image of the sealed cargo as input and automatically extracts edges, textures, shapes, and high-level semantic features from the image through multiple convolutional and pooling layers, ultimately outputting a fixed-dimensional image feature vector. For cargo attribute data, different feature extraction methods are used depending on the sub-type of the data. Document data, being textual information, is converted into text feature vectors by a pre-trained natural language processing model, which identifies key entities, semantic relationships, and the overall document intent. Storage environment data and logistics trajectory data are mostly time-series or structured numerical data. The computer calculates their statistical characteristics, such as mean, variance, extreme values, and trends in specific patterns, to generate corresponding numerical feature vectors.

[0019] The alignment process is responsible for semantically associating and integrating feature vectors from different sources and dimensions. The computer first generates a unique identifier for each batch of goods, which is used across all data. Based on this identifier, image feature vectors, text feature vectors, and numerical feature vectors for the same batch of goods are aggregated. These vectors are then input into a specially designed feature fusion network, which learns the intrinsic correlations between different feature modalities and maps them to a shared semantic space. In this space, features representing different aspects of the same goods are adjusted to be comparable and complementary. Finally, through concatenation or weighted aggregation, a single, high-dimensional joint semantic vector is generated. This vector comprehensively encodes information about the goods' visual appearance, document content, environmental history, and logistical status.

[0020] For example, feature extraction is performed on a batch of goods that has arrived at its destination. The sealed images of the goods are input into a pre-trained ResNet network. The last layer of the network outputs a 2048-dimensional vector representing the condition of the packaging and specific markings. Simultaneously, the commercial invoice text for this batch of goods is input into a BERT model, resulting in a 768-dimensional vector encoding information such as the goods' name, specifications, and quantity. The time-series data of temperature and humidity during transportation are used to calculate statistics such as average temperature, maximum humidity, and fluctuation period, forming a 50-dimensional vector. The logistics trajectory is converted into a series of geographic locations and timestamps, forming a 100-dimensional vector. These four vectors are aligned and aggregated using the unique waybill number of this batch of goods, and then input into a fully connected network with an attention mechanism. This network strengthens the association weights between the seal features in the image and abnormal stop events in the logistics trajectory, ultimately outputting a 2966-dimensional joint semantic vector that integrates all the above information.

[0021] S3. Input the joint semantic vector into the pre-trained neural network model and output the transaction risk index.

[0022] In this process, the computer device inputs the joint semantic vector generated in step S2 into a pre-trained neural network model for analysis and calculation, and finally outputs a quantified trading risk index. This pre-trained neural network model has been trained offline using a large number of historical trading samples and their corresponding real risk labels, and its model parameters have been fixed and deployed in the computing module of the computer device.

[0023] The specific process is as follows: First, the computer loads the network structure and weight parameters of the pre-trained neural network model from the storage medium. Then, the joint semantic vector is fed into the input layer of the model as input data. This vector flows sequentially through one or more hidden layers within the model. Each hidden layer typically consists of fully connected operations and nonlinear activation functions, responsible for performing layer-by-layer abstraction and nonlinear transformation of the input features to uncover deep patterns and complex correlations related to risk judgment. Finally, the model produces a scalar value, the trading risk index, through its output layer. This index is usually designed as a value that varies within a continuous range, and its magnitude directly corresponds to the system's assessment of the risk level of the transaction; a higher value indicates a higher risk level. The entire calculation process is a forward propagation process, with the model parameters remaining unchanged. After calculation, the risk index is output to the downstream decision module. The pre-trained neural network model contains one input layer, two cascaded hidden layers, and one output layer, for a total of four computational layers.

[0024] For example, a pre-trained three-layer fully connected neural network model is loaded. The model's input layer has 2966 nodes, matching the dimension of the joint semantic vector. After input, the vector first undergoes weighted summation and transformation via the ReLU activation function through 1024 nodes in the first hidden layer, followed by similar processing through 512 nodes in the second hidden layer. Finally, the output layer, with a single node, processes the vector and uses the Sigmoid activation function to constrain the output value between 0 and 1. If the joint semantic vector of a batch of goods is input into this model, processed through the aforementioned layers, and outputs a value of 0.72, this value represents the risk assessment index for the transaction, indicating that the system determines the transaction carries a moderately high risk.

[0025] The training process of the pre-trained neural network model is completed offline on a computer device. For example: First, a dataset containing 100,000 historical transaction records is collected and constructed. Each sample contains a 1024-dimensional joint semantic vector generated in step S2 as input features, and a true risk value in the range of 0 to 1 determined by post-validation as the training target. The dataset is randomly divided into training, validation, and test sets at a ratio of 70%, 15%, and 15%. A network structure with an input layer, two hidden layers, and an output layer is initialized, and all weight parameters are randomly initialized using a He normal distribution. During training, the batch size is set to 128, the Adam optimizer is used, and its initial learning rate is set to 0.001. Iterative training is performed on the training set, and the mean squared error loss is calculated on the validation set after each round of training. When the validation loss does not decrease for 10 consecutive rounds, the learning rate is halved. The entire training process consisted of 100 rounds. The model parameters with the smallest loss on the validation set were selected and evaluated on an independent test set. The mean absolute error between the predicted values ​​and the true risk values ​​was 0.08. The model parameters were then fixed and deployed.

[0026] The model in this application is a sequentially connected feedforward neural network. Its hierarchical structure is as follows: Input layer: Consists of 1024 nodes, each node directly receives a numerical input from one dimension of the 1024-dimensional joint semantic vector.

[0027] The first hidden layer contains 512 neurons. Each node in this layer is fully connected to all 1024 nodes in the input layer, resulting in a total of 524,288 trainable connection weights. This layer uses the ReLU activation function.

[0028] The second hidden layer contains 256 neurons. Each node in this layer is fully connected to all 512 nodes in the first hidden layer, resulting in a total of 131,072 trainable connection weights. This layer also uses the ReLU activation function.

[0029] Output layer: Consists of a single neuron. This node is fully connected to all 256 nodes in the second hidden layer, providing a total of 257 trainable parameters. This layer uses the sigmoid activation function to constrain the final output value between 0 and 1, serving as a trading risk index.

[0030] Data flows unidirectionally and sequentially from the input layer through two hidden layers and finally reaches the output layer. There are no cross-layer or circular connections between layers.

[0031] The key parameters of the model in this application mainly include: Structural parameters: Input layer dimension 1024, first hidden layer node count 512, second hidden layer node count 256, output layer node count 1.

[0032] Connection parameters: Fully connected weight matrices and bias vectors between layers, specifically the weight matrix from the input layer to the first hidden layer with dimensions [1024, 512], the weight matrix from the first hidden layer to the second hidden layer with dimensions [512, 256], the weight matrix from the second hidden layer to the output layer with dimensions [256, 1], and the corresponding bias vectors for each layer.

[0033] Activation functions: The first and second hidden layers use the ReLU function, and the output layer uses the Sigmoid function.

[0034] Training hyperparameters: batch size 128, base learning rate 0.001, optimizer Adam, number of iterations 100, and a learning rate decay strategy based on validation set performance was adopted.

[0035] S4. Generate contract call instructions based on the transaction risk index. The contract call instructions include: the address of the target smart contract and the name of the target contract function in the target smart contract.

[0036] In this application, the target smart contract refers to a computer program protocol designed and deployed on a blockchain to execute specific risk control and transaction logic. Functionally, it is the final execution vehicle for risk disposal decisions in this system, encapsulating clear business rules, such as automatically executing operations like fund payment, freezing, or release based on different instruction conditions. Technically, it possesses the general attributes of blockchain smart contracts: transparent code logic, immutability once deployed, and joint verification and execution by blockchain network nodes, thus ensuring the credibility and non-repudiation of the execution results. In the context of this solution, the target smart contract is identified and located through its unique contract address and completes specific risk control actions by calling one or more specific contract functions within it. For medium and high-risk operations, the smart contract automatically generates a time-limited "dispute period" or "manual review request" while freezing funds and notifies the relevant parties. Only after no objection or review confirmation is raised within the dispute period does the freezing or payment operation finally take effect.

[0037] For example, a dedicated escrow smart contract was deployed for a certain type of cross-border trade contract. The contract's rules stipulate that the buyer's payment must first be locked within the contract. The contract may contain multiple functions such as "payment," "dispute freeze," and "release and refund." When the system assesses the risk as low, it will call the "payment" function, triggering the contract to automatically transfer funds to the seller's address. This program, specifically designed for this type of contract, deployed on-chain, and possessing the aforementioned functions, is the target smart contract referred to in this solution.

[0038] The generation of a target smart contract is a separate, offline development and deployment process that precedes the transaction request processing flow. The complete generation process can be summarized into four main stages: design, coding, deployment, and registration, all completed by developers using computer equipment.

[0039] The first stage involves business rule design and contract logic coding. Developers first define the business rules that the smart contract must follow based on the specific transaction type and risk control requirements. These rules include payment trigger conditions, fund custody rules, multi-party permission settings, and dispute resolution mechanisms. Then, using a dedicated smart contract programming language such as Solidity, these business rules are translated into strict, unambiguous computer code logic, forming the smart contract's source code.

[0040] The second phase is compilation and testing. The completed source code is compiled into bytecode that can be executed in the blockchain virtual machine using a specialized compiler. Simultaneously, this bytecode undergoes thorough functional verification and security auditing in a test network environment to ensure that its behavior meets design expectations and that no fatal vulnerabilities exist.

[0041] The third stage is the formal deployment on the blockchain. After testing and verification, the contract bytecode is sent to the target blockchain network via a special blockchain transaction by an administrator with deployment privileges. Miners or validator nodes in the network process the transaction, permanently recording the contract bytecode on the blockchain and assigning it a globally unique contract address. At this point, the smart contract is officially generated and ready for invocation.

[0042] The fourth stage is system registration and mapping. The successfully deployed smart contract address and its associated business identifier, such as the contract template number, are recorded in the system's configuration database or a registry contract. This step establishes a mapping relationship between the "business identifier" and the "on-chain contract address," enabling step S41 to query the corresponding target contract address based on the contract ID.

[0043] Furthermore, based on the transaction risk index output in step S3, the computer device generates a corresponding contract invocation instruction according to a preset risk decision logic. This instruction is a structured command data block, the core function of which is to specify the specific operation to be executed on the blockchain. It contains at least two necessary elements: the deployment address of the target smart contract in the blockchain network and the name of the specific function to be called within the contract.

[0044] The specific process is as follows: A risk strategy mapping table is pre-configured or stored within the computer device. This mapping table defines the correspondence between different transaction risk index ranges and specific smart contract operations. For example, a lower index range may be associated with an auto-release contract function, a medium range with a flagged review contract function, and a higher range with risk control contract functions such as suspending transactions. After obtaining the transaction risk index, the computer device compares and matches it with the threshold ranges in the mapping table to determine the risk control strategy to be executed. Based on the matched strategy, the system retrieves the address of the target smart contract and the name of the target contract function from the mapping table. Subsequently, the computer device encapsulates this information according to a call data format recognizable by blockchain nodes, assembling it into a complete contract call instruction. This instruction data explicitly contains the aforementioned address and function name, and may include necessary call parameters represented by the unique identifier of the transaction, ultimately forming an instruction that can be directly sent in subsequent steps.

[0045] For example, a pre-defined risk strategy mapping table stipulates that when the transaction risk index is below 0.3, the "releasePayment" function in the payment contract at address "0xA1b2" is called to release the payment; when the index is between 0.3 and 0.8, the "markForReview" function in the review contract at address "0xC3d4" is called to mark it as awaiting manual review; and when the index is greater than or equal to 0.8, the "freezeTransaction" function in the risk control contract at address "0xE5f6" is called to freeze the transaction. When the risk index of a transaction is calculated to be 0.85, the computer device matches it with the mapping table to determine that it falls into the highest risk range. Subsequently, the system retrieves and obtains the corresponding target contract address "0xE5f6" and the target function name "freezeTransaction". Finally, this information, along with the tracking number of this transaction, is packaged together to generate a contract call instruction data packet conforming to the JSON-RPC standard.

[0046] S5. Send a contract call instruction to the blockchain so that the blockchain executes the target contract function in the target smart contract.

[0047] The process begins with a computer device establishing a trusted connection with one or more blockchain network nodes via its integrated blockchain node client software or a remote blockchain application service interface. The computer device then assembles the encapsulated contract invocation instructions according to the standard remote procedure call (RPC) format supported by the blockchain network, forming a valid on-chain transaction request. This request includes not only the address of the target smart contract and the name of the target contract function, but also typically the necessary parameters for executing the function and settings for paying network processing fees. The computer device sends this transaction request to the blockchain node it is connected to. The receiving node performs a series of validity checks, including format checks, digital signature verification, and fee adequacy checks. Upon successful verification, the node broadcasts the transaction to its neighboring nodes, thus initiating its propagation throughout the network. Miners or consensus nodes in the blockchain network collect these broadcast transactions and package them into a new unconfirmed block. Once the network reaches an agreement on the block and confirms its validity through its consensus mechanism, such as Proof-of-Work or Proof-of-Stake, the block is added to the blockchain. At this point, the transaction included in the block is finally confirmed. Its content, namely, calling a specific function at a specific contract address, will be executed by the virtual machine that executes the smart contract. Function execution may cause changes to the internal state of the smart contract and generate corresponding on-chain events. The blockchain transaction hash value corresponding to the contract call instruction is recorded.

[0048] For example, a computer device runs a node client on an Ethereum test network. The device assembles a transaction with a sender's signature and an appropriate gas fee, containing a call instruction with the contract address "0xE5f6" and the function name "freezeTransaction," according to the JSON-RPC protocol. This transaction is sent to the locally running Ethereum node via the client's network module. After verifying the signature's validity and the gas fee setting, the node broadcasts the transaction to the entire Ethereum test network. Miner nodes in the network include this transaction when packaging new blocks. After mining competition, a miner successfully produces a block, and after other nodes in the network verify the block's validity, consensus is reached, and the block is linked to the main chain. After block confirmation, the smart contract deployed on the address "0xE5f6" is triggered, and its internally defined "freezeTransaction" function is automatically executed. This function may modify the state variables in the contract related to the specified transaction, marking it as frozen.

[0049] S6. Obtain on-chain event data generated after the target contract function is executed, and generate a transaction request processing certificate based on the association information between the on-chain event data and the transaction request.

[0050] The process involves the computer device actively listening for and acquiring on-chain event data generated after the execution of a target smart contract function. After executing specific logic, a smart contract function can proactively emit an event containing key information about the execution result; this event is recorded in the blockchain log. The computer device subscribes to the event log stream of a specific contract address through a long-lived connection established with the blockchain node. To ensure the accuracy of event capture, the device needs to set filters, typically including the target smart contract address and the signature of the specific event. Once the blockchain network confirms a transaction containing the function call, the corresponding event log is pushed to the listening device. Upon receiving the raw log data, the computer device parses it according to the application binary interface definition of the smart contract, decoding the encoded log data into readable structured data, such as key fields like operation status, amount, and timestamp. The parsed structured event data, along with the original transaction hash that triggered the event, is stored in a local database, forming a quickly searchable on-chain operation record.

[0051] For example, when the target contract function "freezeTransaction" used to freeze funds executes successfully, the contract throws an event called "TransactionFrozen," which encodes the frozen transaction number "TX1001" and the frozen amount "10000 USD." The computer device has previously subscribed to all events of this contract address. After the relevant block is confirmed, the device receives the raw event log, then calls the locally stored contract ABI definition file to decode the log, extracts the readable transaction number and amount information, and stores it along with the blockchain transaction hash "0xa1b2c3…" in the "on-chain event table" of the database.

[0052] The key to generating processing credentials lies in fusing on-chain event data with the association information of the original transaction request. The computer device retrieves the parsed on-chain event data from its local database. Simultaneously, based on the business identifier contained within, it queries and retrieves the corresponding association information of the original transaction request within the system context. This association information typically includes core content such as the unique request identifier, goods summary, and requester identity received in step S1. The system automatically populates the corresponding fields of the template with the on-chain event data and request association information according to a predefined credential template. The template defines a fixed structure for the credential, including a title, information about both parties, risk mitigation basis, on-chain evidence index, and trusted timestamp. After population, the computer device typically generates a hash value for this credential and attaches it along with the system's digital signature, ultimately outputting a complete and tamper-proof processing credential document.

[0053] For example, the objective function "freezeTransaction" triggers a contract event named "TransactionFrozen" at the end of its execution. This event records the transaction number "TX1001" and the freeze timestamp. After the transaction is sent, the computer device subscribes to the "TransactionFrozen" event from address "0xE5f6" via the Ethereum node's WebSocket interface. When the transaction is confirmed, the device receives block information containing the event log. The system parses the log to obtain structured data such as the transaction number "TX1001" and the freeze time "October 26, 2023, 14:30:00 UTC". Subsequently, the system, according to the "Transaction Freeze Certificate" template, fills in the aforementioned time, transaction number, and the corresponding blockchain transaction hash value "0x789abc" to generate a PDF processing certificate file with the system's electronic signature. This file fully records the fact that this risky transaction was frozen by the system according to the contract rules and provides on-chain evidence.

[0054] In one possible embodiment, S2, the feature extraction and alignment processing of the cargo image data and the cargo attribute data to generate a joint semantic vector, includes: S21. Convert the cargo attribute data into formatted text; S22. After inputting the formatted text into the text encoder of the pre-trained multilingual CLIP model, a text feature vector is generated. S23. Input the cargo image data into the image encoder of the multilingual CLIP (Contrastive Language-Image Pre-training) model to generate image feature vectors; S24. Using the joint semantic space defined by the multilingual CLIP model, perform semantic alignment between the image feature vector and the text feature vector; S25. The aligned image feature vector and the text feature vector are fused to generate the joint semantic vector.

[0055] In step S21, the computer device performs structured text conversion processing on the received cargo attribute data. This attribute data includes data from multiple heterogeneous sources, such as document data, storage environment data, and logistics trajectory data. First, according to predefined rule templates, this data is converted into a plain text string with a uniform format. For the text content in the document data, the system directly extracts key fields; for the numerical sequences in the storage environment data, the system converts them into descriptive statements or text that retains key statistical values; for the logistics trajectory data, its node information is organized into a coherent text description in chronological order. Finally, all this information is integrated into a coherent, formatted text paragraph that comprehensively and clearly describes the cargo attribute information.

[0056] For example, the attribute data for a shipment includes a Chinese invoice, a series of temperature records, and the shipping trajectory from location A to location B. The computer extracts the shipper, product name, and quantity information from the invoice; converts the temperature records into statements such as "The average temperature during transportation was 5 degrees Celsius, and the highest temperature was 8 degrees Celsius"; and organizes the logistics trajectory into a text stating "The goods departed from port A on October 1st and arrived at port B and completed customs clearance on October 15th." Finally, all this information is merged to generate a complete, formatted text segment.

[0057] In step S22, the computer device inputs the formatted text generated in step S21 into a pre-trained multilingual CLIP model text encoder for processing. This text encoder is a deep neural network specifically designed to understand the semantics of text in multiple languages. It segments and encodes the input text string, mapping the text into a high-dimensional semantic vector space through its internal attention mechanism and multi-layer transformations, outputting a fixed-dimensional text feature vector. This vector numerically represents the overall semantic information of the input formatted text.

[0058] For example, the formatted text paragraph containing both Chinese and English information is input into the text encoder of the multilingual CLIP model. The encoder first performs word segmentation on the text, and then understands the semantics of cross-linguistic concepts such as "electronic products," "Shanghai Port," and "temperature-controlled transportation" through its network layers. Finally, it outputs a 512-dimensional vector representing the comprehensive meaning of the text paragraph, namely the text feature vector.

[0059] In step S23, the computer device inputs the received cargo image data, mainly cargo sealing image data, into the image encoder of the same multilingual CLIP model. This image encoder is typically a deep convolutional neural network that receives image pixel data and extracts edges, contours, textures, and high-level semantic features from the image layer by layer through a series of convolution and pooling operations, ultimately encoding the entire image into a fixed-dimensional image feature vector. This vector numerically represents the visual content information of the input image.

[0060] Before deploying the actual multilingual CLIP model, a supervised fine-tuning of the pre-trained multilingual CLIP model can be performed using an image-text pair dataset containing typical goods, document styles, and languages ​​of the target cross-border region, in order to improve its semantic alignment accuracy in specific trade domains.

[0061] For example, a photograph of a sealed carton is input into the CLIP model's image encoder. The encoder automatically identifies visual elements in the image, such as the shape of the carton, the style of the sealing tape, printed labels, and logos, and encodes them into an image feature vector with the same dimensions as the text feature vector (e.g., 512 dimensions).

[0062] In step S24, the computer device uses the joint semantic space defined by the multilingual CLIP model to semantically align the text feature vectors generated in step S22 and the image feature vectors generated in step S23. The CLIP model is pre-trained with a massive number of image-text pairs. Its core principle is to ensure that the vectors of images and texts describing the same semantic content are located close to each other in the joint semantic space after being encoded by the model. The system evaluates and ensures the degree of alignment between two vectors in this space by calculating the similarity or distance between them. This process essentially projects the textual description features and visual appearance features of goods from different modalities into a unified, comparable semantic reference system.

[0063] For example, for the same batch of goods, its text feature vector describes "electronic products, original factory seal," while its image feature vector encodes visual information such as intact sealing tape and original factory markings. In the joint semantic space formed by the CLIP model pre-training, these two feature vectors from text and image, respectively, are used to calculate cosine similarity. Since they describe two aspects of the same object, the model ensures that their vector representations are highly consistent in orientation in space, thus achieving semantic alignment.

[0064] In step S25, the computer device fuses the aligned image feature vectors with the text feature vectors to generate a final joint semantic vector. The purpose of fusion is to create a single feature representation that simultaneously contains and integrates information from both the visual and textual modalities. Common fusion methods include vector concatenation, bitwise addition, or weighted averaging. The computer device uses one or more of these methods in combination to merge the two aligned feature vectors into a new vector of higher or same dimension. This new vector is the joint semantic vector, which carries the fused semantic information of the visual appearance and attribute text of the goods.

[0065] For example, after obtaining the aligned 512-dimensional image feature vector and 512-dimensional text feature vector, the computer device fuses them using vector concatenation. The system concatenates these two vectors end-to-end to generate a new 1024-dimensional vector, which is the joint semantic vector. This vector simultaneously contains the visual features of the sealed image and the semantic features of the cargo attribute text.

[0066] This technical solution achieves efficient feature extraction and cross-modal semantic alignment of cargo image data and multilingual, multi-structured cargo attribute data by introducing a pre-trained multilingual CLIP model. This method can uniformly map data from different sources and in different formats to a common semantic space, generating a joint semantic vector with more complete information fusion and more accurate semantic understanding. This significantly improves the ability and accuracy of subsequent risk identification models to understand complex transaction scenarios, especially those involving cross-border multilingual documents and variable visual evidence, providing a higher-quality data foundation for automated transaction risk decision-making.

[0067] It should be noted that the training process of the multilingual CLIP model is completed offline on computer devices or distributed computing clusters. The core objective of training is to construct a joint semantic space capable of understanding multilingual text and establishing universal associations with image content. The training data is a large-scale, cross-lingual collection of massive image-text pairs, where the text descriptions cover multiple languages. The training process first preprocesses the raw data, including image size normalization, enhancement, and text segmentation and encoding. The model adopts a dual-tower architecture, containing an image encoder and a multilingual text encoder. During training, within the same batch, the model simultaneously processes a batch of images and their corresponding multilingual text descriptions. The training objective is to maximize the similarity of correctly matched image-text pairs in the joint semantic space while minimizing the similarity of incorrectly matched pairs. This is typically achieved through a contrastive learning loss function, such as the InfoNCE loss. The model parameters are iteratively updated using the backpropagation algorithm and gradient descent optimizer, ultimately enabling the model to learn to map different language texts and corresponding images describing the same semantic concept to similar vector positions in the joint semantic space.

[0068] For example, training uses a dataset containing hundreds of millions of image-text pairs, with text descriptions in multiple languages ​​including Chinese, English, and Spanish. The image encoder uses a Vision Transformer architecture, and the text encoder uses a multilingual BERT architecture. In each training iteration, a batch of images and their corresponding descriptions in different languages ​​are input into the model. The computer calculates the cosine similarity between the feature vector of each image and the feature vector of each text. The loss function encourages the model to improve the similarity score between "a picture of a German warehouse" and its correct descriptions "Warehouse in Germany" and "German warehouse," and to reduce its score with irrelevant descriptions such as "a blue car" or "a blue car." After several rounds of iterative optimization, the model is finally trained into a multilingual CLIP model that can effectively align cross-modal and cross-linguistic information.

[0069] The update process of the multilingual CLIP model aims to adapt the deployed model to new data distributions, languages, or business scenarios, maintaining its advanced performance and adaptability. Updates are not real-time but are initiated periodically or under specific conditions. The update process primarily involves incremental training or fine-tuning. First, new image-text pair data relevant to the target application domain needs to be collected, especially for goods types that are insufficiently covered in existing training data, newly emerging document formats, or new business region languages. Then, based on the deployed pre-trained multilingual CLIP model, using its current parameters as the initial state, additional training is performed using the collected new data. During fine-tuning, some network layers can be frozen or all parameters updated as needed; the learning rate is typically set lower than during initial training. After the updated training is complete, a new version of the model parameter file is generated. After rigorous validation and performance evaluation, the new version of the model is deployed to the production environment, replacing the old version, thus completing one model update iteration.

[0070] For example, the initial model training did not adequately cover local language documents from a certain region in Africa. As business expanded to that region, the system collected a batch of images of sealed goods containing descriptions in the local language. To update the model, technicians used this new data, along with some of the original data to prevent omissions, as a baseline using an already deployed multilingual CLIP model. Supervised fine-tuning of the model's text encoder was performed. During the update training, only the parameters of the last few layers of the text encoder and the projection layer were updated; the image encoder parameters remained unchanged. After training, evaluations showed a significant improvement in the model's text-image alignment capabilities for the new regional languages. Ultimately, this updated model was safely deployed to the transaction risk assessment system, replacing the original model and enabling the system to better handle transaction requests from this new market.

[0071] In one possible embodiment, S4, generating the contract invocation instruction based on the transaction risk index, includes: S41. Query the address of the corresponding target smart contract based on the contract ID of the goods; the target smart contract includes multiple contract functions; S42. Determine the corresponding target contract function from multiple contract functions based on the transaction risk index; S43. After signing the address of the target smart contract and the name of the target contract function using a preset private key, a contract call instruction is generated; S44. Broadcast the contract call instruction to each node in the blockchain.

[0072] In step S41, the computer device queries a local or on-chain associated mapping data source based on the unique contract identifier corresponding to the goods in the current transaction to determine the address of the target smart contract bound to that contract. This contract identifier is typically included in the document data when the transaction request is received in step S1. The computer device internally maintains a mapping table between contracts and smart contracts, recording the association between contract identifiers and their corresponding smart contract addresses deployed on the blockchain. The system queries this mapping table, using the contract identifier as the search key, to obtain the address of the precisely associated target smart contract. This address is a string that uniquely identifies a specific smart contract within the blockchain network.

[0073] For example, a transaction involves an electronic sales contract with the contract identifier "CON-2023-10-001". The computer device queries its local associated database using this contract identifier. The database returns a record showing that the smart contract corresponding to this contract has been deployed on the blockchain at the address "0x89abcdef1234567890". The system then uses this address as the target smart contract address for this call.

[0074] In step S42, the computer device, based on the transaction risk index calculated in step S3, determines the specific target contract function to be executed from among the multiple contract functions provided by the target smart contract. The target smart contract is typically designed to include a series of functions for different risk control operations. The system internally pre-defines a function mapping strategy, which defines the specific contract function names to be triggered for different ranges of transaction risk indices. The computer device compares the calculated transaction risk index with this strategy, and logically determines the corresponding target contract function name by determining which pre-defined numerical range the index falls into.

[0075] For example, the target smart contract address "0x89abcdef1234567890" contains several pre-defined functions, including "Normal Payment," "Delayed Payment," and "Pause Transaction." The system's default strategy is as follows: when the risk index is below 0.2, the "Normal Payment" function is called; when the index is between 0.2 and 0.6, the "Delayed Payment" function is called; and when the index is above 0.6, the "Pause Transaction" function is called. If the current transaction risk index is 0.75, the system determines the target contract function's name to be "Pause Transaction" through comparison.

[0076] In step S43, the computer device uses a pre-set private key of an account with calling authority to digitally sign the original call request data assembled in step S43. The private key is securely stored in the computer device's encrypted storage module. The signing process employs a cryptographic algorithm compatible with the target blockchain network, such as the elliptic curve digital signature algorithm. A unique digital signature is generated by hashing the call data and signing the hash value. Subsequently, the system merges the original call request data, the generated digital signature, and the corresponding public key information to finally assemble a complete and authenticated contract call instruction. This instruction can be verified by the blockchain network to confirm its source legitimacy and data integrity.

[0077] For example, a computer device retrieves the private key of an authorized account from a secure hardware module, performs a hash calculation on structured data containing addresses, function names, and transaction numbers to obtain a digest, and then signs the digest using the private key. Subsequently, the original data, the obtained signature value, and the account's public key address are packaged together into a contract call instruction conforming to the Ethereum transaction format.

[0078] In step S44, the computer device broadcasts the signed, complete contract call instruction generated in step S43 to the entire blockchain network through its connected blockchain network nodes. The computer device sends this instruction data packet to one or more known, accessible blockchain peer nodes. The receiving node first verifies its basic format and signature validity. Upon successful verification, the node broadcasts this pending call transaction to other nodes it is connected to, according to the blockchain network's peer-to-peer propagation protocol. Through this hierarchical propagation, the contract call instruction is rapidly disseminated to most nodes in the network and enters the pending transaction pool, awaiting being packaged into a new block by miners or consensus nodes for execution.

[0079] For example, a computer device sends a signed contract call instruction to an Ethereum gateway node via a JSON-RPC interface. After verifying the signature, the node broadcasts the transaction to a dozen or so other connected nodes via Ethereum's P2P network protocol. These nodes then forward the message, and within seconds, the instruction to call the "pause transaction" function at the address "0x89abcdef1234567890" has spread to Ethereum network nodes worldwide, awaiting inclusion in a block.

[0080] This technical solution precisely locates smart contracts using contract identifiers and automates decision-making based on quantified risk indices, achieving accurate matching between risk management strategies and on-chain contract execution. Combined with digital signatures and network broadcasting mechanisms, this process not only ensures the authority, integrity, and non-repudiation of contract call instructions but also guarantees the reliability and transparency of instruction transmission through a decentralized network. The entire process achieves secure, automated, and auditable closed-loop execution from risk assessment conclusions to on-chain risk control actions, significantly improving the automation level and execution credibility of transaction risk management.

[0081] In one possible embodiment of this application, S42, determining the corresponding target contract function among multiple contract functions based on the transaction risk index, includes: S421. Compare the transaction risk index with preset low-risk threshold and high-risk threshold; S422. If the transaction risk index is lower than the low risk threshold, determine the target contract function to pay for the release of all funds. S423. If the transaction risk index is between the low risk threshold and the high risk threshold, determine the target contract function for freezing a preset proportion of funds. S424. If the transaction risk index is higher than the high risk threshold, determine the target contract function to freeze all funds.

[0082] In step S421, the computer device reads two preset constant values, a low-risk threshold and a high-risk threshold, from its internal configuration memory. The low-risk threshold represents the upper limit at which the system considers the risk negligible, and the high-risk threshold represents the lower limit at which the system considers the risk unacceptable. Subsequently, the computer device compares the transaction risk index calculated in step S3 with these two thresholds. This comparison process is a logical judgment operation designed to determine the position of the transaction risk index relative to these two thresholds within a certain range.

[0083] For example, the preset low-risk threshold is 0.3, and the high-risk threshold is 0.7. The computer compares the current transaction's risk index of 0.5 with 0.3 and 0.7 respectively, and determines through logical operations that 0.5 is greater than 0.3 and less than 0.7.

[0084] The determination of the low-risk and high-risk thresholds is an offline process based on historical data analysis and model performance optimization, executed by computer equipment or a connected data analysis system. Its core purpose is to find a scientific and objective numerical standard for online automated decision-making, thereby achieving optimal matching between risk grading and subsequent actions.

[0085] The specific determination process includes the following steps. First, a large amount of historical transaction sample data is collected, each sample containing its ultimately verified true risk label, such as "normal transaction" or "fraudulent transaction". Using the same process described in steps S1 to S3 of this solution, each historical sample is processed to generate its corresponding joint semantic vector, which is then input into a pre-trained risk assessment model to obtain the "predicted transaction risk index" for each historical sample. At this point, the computer device has a dataset consisting of the "predicted index" and the "true label".

[0086] Secondly, based on this dataset, model evaluation and threshold optimization algorithms are used to determine the thresholds. A common approach is to use receiver operating characteristic (ROC) curve analysis. The system treats the prediction index as the output of a classifier, and calculates the model's recognition rate and false positive rate for "high-risk transactions" at different thresholds by traversing all possible threshold cutoff points. The determination of the low-risk threshold often focuses on controlling the false positive rate, that is, minimizing the misclassification of normal transactions as those requiring intervention. Its value may be chosen near the inflection point that ensures extremely high specificity. The determination of the high-risk threshold focuses more on ensuring the capture rate of truly high-risk transactions. Its value may be chosen near the inflection point where sensitivity begins to plateau. Another approach is to directly set the allowable misclassification ratio based on the business risk tolerance, and then deduce the corresponding threshold through probability distribution. Finally, an optimization algorithm is used to achieve a balance between the two objectives, thereby determining a set of recommended low-risk and high-risk threshold values.

[0087] Finally, validation and calibration are performed. The initially determined thresholds are applied to an independent validation dataset to observe whether the risk grading results under these thresholds meet business expectations. For example, do transactions in the medium-risk range indeed include most cases requiring manual review? Based on the validation results, the thresholds may need to be fine-tuned, and the final determined thresholds are written as configuration parameters into the system's strategy configuration module.

[0088] For example, analyzing 100,000 historical transactions from the past year yields 100,000 predicted risk indices. It is known that 1,000 of these were confirmed fraudulent transactions. The system plots the ROC curves of these predicted indices and calculates the Youden index to find the optimal classification point. However, business requirements dictate that the false freeze rate for legitimate transactions must be below 2%. Therefore, based on the cumulative distribution, the maximum predicted index value of 0.25, corresponding to a false freeze rate below 2%, is set as the low-risk threshold. Subsequently, to capture at least 90% of genuine fraudulent transactions, the technical staff finds the minimum predicted index value of 0.65 corresponding to 90% of the cumulative fraudulent samples and sets it as the high-risk threshold. This set of thresholds is validated on data from another quarter. After confirming the stable classification effect, the low-risk threshold of 0.25 and the high-risk threshold of 0.65 are officially written into the system configuration file.

[0089] In step S422, if the comparison result of step S421 shows that the transaction risk index is lower than the low-risk threshold, the computer device determines that the current transaction is in a low-risk state. Based on this determination, the system identifies and selects a target contract function from the predefined strategy mapping relationship to execute for paying and releasing all funds. This function is typically designed to automatically execute a smart contract operation to make full payment or release funds when the risk is extremely low, and its function name is associated with the "low-risk release" strategy in the system configuration.

[0090] Following the previous example, if the transaction risk index is 0.2, which is lower than the low-risk threshold of 0.3, the computer equipment determines that a low-risk handling strategy is applicable and retrieves the target contract function name "releaseAllFunds" from the configuration. This function is designed to release all locked funds under the contract to the seller upon invocation.

[0091] In step S423, if the comparison result of step S421 indicates that the transaction risk index is between the low-risk threshold and the high-risk threshold, the computer device determines that the current transaction is in a medium-risk state. Based on this determination, the system identifies and selects a target contract function to freeze a preset proportion of funds. This function is designed as a compromise risk control measure when the risk is uncertain, freezing only a portion of the contract funds instead of all of them. Its function name and preset freezing proportion are associated with the "medium-risk partial freeze" strategy in the system configuration. The preset proportion can be pre-configured by the system administrator or set in the smart contract based on historical transaction risk analysis, contract terms, or the credit ratings of the transacting parties.

[0092] Continuing the previous example, if the transaction risk index is 0.5, falling between the thresholds of 0.3 and 0.7, the computer equipment determines that a medium-risk handling strategy is appropriate. The configuration shows that the target contract function name for this strategy is "freezePercentage," with a pre-defined freeze percentage of 50%. This function is designed to freeze only half of the total contract funds upon invocation.

[0093] In step S424, if the comparison result in step S421 shows that the transaction risk index is higher than the high-risk threshold, the computer device determines that the current transaction is in a high-risk state. Based on this determination, the system identifies and selects a target contract function to freeze all funds. This function is designed to take the strictest risk control measures when the risk is extremely high, completely freezing all funds under the contract to prevent payment. Its function name is associated with the "high-risk full freeze" strategy in the system configuration.

[0094] Continuing the previous example, if the transaction risk index is 0.8, which is higher than the high-risk threshold of 0.7, the computer equipment determines that a high-risk handling strategy is applicable and retrieves the target contract function name "freezeAllFunds" from the configuration. This function is designed to immediately freeze all locked funds related to the contract upon invocation.

[0095] This technical solution achieves tiered risk response by setting clearly defined risk threshold ranges and mapping continuous risk indices to discrete, differentiated fund disposal strategies. This method enables computer equipment to automatically select on-chain contract functions with varying degrees of stringency, ranging from full release and partial proportional freezing to full freezing, based on precise risk level assessment. This refined, tiered automated decision-making mechanism significantly improves the accuracy and rationality of risk response measures, ensuring the safety of transaction funds while minimizing the impact of excessive risk control on normal transaction processes, thus achieving a balance between security and efficiency.

[0096] In one possible embodiment of this application, before step S2, the following steps are further included: A1. Verify the identity of the requester of the transaction request; if the identity verification is successful, then... A2. The authenticity of the cargo attribute data and cargo image data is verified, and the result of the authenticity verification is passed.

[0097] In step A1, after receiving the target transaction request, the computer device first authenticates the requester. This authentication process aims to confirm whether the requester possesses legitimate operating permissions and identity. The computer device completes the authentication by invoking its integrated identity authentication service or querying a pre-set authorization list. Specifically, the computer device extracts the requester's identity credential information from the received request data packet. This credential can be a digital certificate, access token, or registered identity identifier. The system compares this credential with legitimate credentials pre-stored in a whitelist or with the results of real-time verification by an external certification authority. If the credential is valid, not expired, and matches the authorization list, the authentication status is marked as passed. Only in this state is the request allowed to proceed to the subsequent processing flow; otherwise, the request will be rejected and an error message will be returned. The cargo image data primarily originates from IoT cameras with tamper-proof functionality that are bound to system authentication; the storage environment data originates from sensors with unique device identifiers and encrypted signatures. This enhances the credibility of off-chain data before it is uploaded to the blockchain.

[0098] For example, a cross-border trading company, as the requester, signs its transaction request using its corporate digital certificate. Upon receiving the request, the computer device extracts the attached digital certificate and verifies its authenticity and validity through a connected certificate authority verification service. Simultaneously, it queries its internal enterprise customer whitelist to confirm that the company corresponding to the certificate has completed registration and filing within the list. The computer device determines that the identity verification for this request is successful only if the certificate verification is successful and the company identity is on the whitelist.

[0099] In step A2, after successful identity verification, the computer device further verifies the authenticity of the cargo attribute data and cargo image data included in the request. This step aims to ensure that the submitted data is from a trustworthy source, has not been tampered with, and conforms to basic factual logic. For cargo attribute data, especially document data, the computer device can verify the validity of the attached electronic seal or digital signature, or compare its key fields with information queried from a trusted third-party system. For storage environment data and logistics trajectory data, the computer device can verify the compliance of its data format, the rationality of its timing, and its consistency with relevant physical laws. For cargo image data, the computer device can perform technical analysis to detect whether the image shows signs of tampering such as duplication, smearing, or resampling, or verify whether the device information and timestamps in its metadata are reasonable. Each of the above verifications has clear passing rules; only when all verified data items meet their corresponding rules is the overall result of the authenticity verification deemed passed.

[0100] For example, the request includes an electronic certificate of origin with the issuing authority's digital signature as documentation data. The computer device verifies the signature using the corresponding authority's public key, confirming that the certificate content has not been altered since its issuance. Simultaneously, the system performs a logical correlation check between the port of origin information in the logistics tracking data and the origin information on the electronic certificate of origin, confirming their geographical consistency. For the cargo sealing image, the system analyzes its pixel-level statistical features and compression characteristics, finding no abnormal traces of artificial synthesis, and the creation time in the image file's metadata is earlier than the current logistics node time, which is reasonable. When all the above sub-checks are successful, the computer device determines that the data authenticity verification result of this request is passed.

[0101] This technical solution introduces two pre-emptive steps: identity verification and data authenticity verification. These steps establish a crucial security and trust barrier before the core risk assessment process begins. First, it ensures the legitimacy of the operating entity, preventing unauthorized access and malicious requests at the source. Second, it proactively verifies the authenticity and integrity of input data, effectively preventing fraudulent activities based on forged or tampered data from interfering with system judgment. These two pre-emptive verifications significantly improve the quality and credibility of the data sources relied upon for subsequent feature extraction, risk analysis, and blockchain contract execution. This enhances the reliability of the entire system's decision-making foundation, reduces business risks caused by identity theft or inaccurate data, and ensures the secure and robust operation of the automated transaction processing flow.

[0102] In one possible embodiment of this application, S6, obtaining the on-chain event data generated after the execution of the target contract function, includes: S61. Monitor the event log data related to the target smart contract in the blockchain; S62. Filter out the on-chain event data corresponding to the target contract function from the event log; S63. The on-chain event data is formatted and then stored in the local database.

[0103] In step S61, the computer device initiates a continuous monitoring process on the blockchain network to capture event log data related to the target smart contract. This monitoring process establishes a long connection with a blockchain node connected to the computer device and registers an event filter with that node. This filter is configured to subscribe to all event logs generated by the target smart contract address, or further limited to subscribing to events with a specific event signature. When a new block is confirmed and added to the blockchain network, the blockchain node checks the transactions within that block. If it contains a transaction that calls the target smart contract and that transaction triggers an event, the node pushes the corresponding event log data to the computer device via the long connection. The computer device's monitoring process receives these pushed raw log data streams in real time.

[0104] For example, the target smart contract address is "0x89abcdef1234567890". The computer device starts a background service that connects to an Ethereum node via the WebSocket protocol. This service sends a filtering request to the node, subscribing to all event logs emitted by the address "0x89abcdef1234567890". Subsequently, whenever a transaction invokes the contract at this address and triggers an event, the Ethereum node pushes logs containing information such as the event topic and data to the computer device in real time.

[0105] In step S62, the computer device performs real-time analysis and filtering of the continuously received event log stream from step S61 to accurately identify the on-chain event data corresponding to the target contract function executed this time. The core basis for filtering is the matching of event signature and transaction hash. First, the system pre-stores the specific event signature expected to be emitted by the target contract function locally. Second, the system records the blockchain transaction hash returned after the contract call instruction is initiated in step S5. When a new event log is detected, the computer device compares the event signature in the log with the pre-stored event signature, and compares the transaction hash to which the log belongs with the recorded transaction hash. Only when the event signature matches and the transaction hash is consistent is the event log determined to be on-chain event data generated by the execution of the target contract function this time, and it is extracted from the log stream. The filtering condition includes that the transaction hash to which the event log belongs matches the recorded blockchain transaction hash value.

[0106] For example, the target function in this call is "freezeAllFunds," which, upon successful execution, triggers an event named "FundsFrozen" with a hash value of "0x123…abc." The transaction hash recorded by the system during the call is "0xdef…456." During the monitoring process, the computer device receives an event log entry with the event signature "0x123…abc" and its associated transaction hash "0xdef…456." The system compares these entries, confirms a perfect match, determines that this log entry is the required data, and extracts it.

[0107] In step S63, the computer device formats the raw on-chain event data filtered in step S62 and persistently stores it in a local database. Formatting refers to parsing and decoding the raw, encoded event log data. Based on the application binary interface definition of the target smart contract, the system restores the encoded event parameters in the log data into readable values, addresses, or strings. Simultaneously, the system extracts and transforms key metadata, such as block height, timestamp, and transaction hash. After processing, the system writes this structured data, including event name, decoded parameters, associated transaction hash, block information, and capture time, as a complete record into a designated table in the local database. This creates an on-chain operation evidence library that can be efficiently queried and audited.

[0108] For example, the computer device filters out the raw log data of the "FundsFrozen" event. The system loads the ABI definition file of the contract, decodes the log data, and parses out the frozen amount parameter "10000" and the target account address "0x…" contained in it. At the same time, it extracts the block height of the log as "152300" and the timestamp as "1698301200" from the log. Subsequently, the system inserts this information along with the transaction hash "0xdef…456" as a record into the "on-chain event record table" of the local database.

[0109] In one possible embodiment of this application, it further includes: B1. The transaction request, the joint semantic vector, the function call instruction, and the processing certificate are associated and written into the blockchain.

[0110] After completing all the aforementioned steps, the computer device performs a data aggregation and on-chain notarization operation to solidify the key evidence across the entire transaction processing chain. The specific process is as follows: First, the computer device extracts four types of data associated with the unique identifier of this transaction from its internal cache or database: the original target transaction request data received in step S1, the joint semantic vector generated in step S2, the contract call instruction data generated in step S4 and executed in step S5, and the processing voucher data generated in step S6. Second, the system establishes a logical master-slave relationship for these four types of data. Typically, the system generates a globally unique notarization index number for this processing and binds this index number to the inherent identifier of each of the four types of data. Subsequently, the computer device assembles these data themselves or their characteristic hash values, along with the notarization index number, timestamp, and other information, into a structured notarization data package. Finally, the computer device submits this notarization data package as a transaction call parameter to the blockchain network by calling a specific function of a smart contract dedicated to notarization. After consensus confirmation through the blockchain network, the evidence-stored transaction and its structured data are permanently recorded on the blockchain, forming an immutable and publicly verifiable end-to-end evidence chain. The hash value of the transaction request, the joint semantic vector (or its feature representation), the on-chain transaction hash corresponding to the function call instruction, and the hash value of the processing credential are correlated, and the correlation information is written into the blockchain.

[0111] Please see Figure 3 As shown, in one embodiment, a blockchain-based cross-border transaction device is provided, the device comprising: The receiving module 301 is used to receive a transaction request for goods, the transaction request including: goods image data and goods attribute data, the goods attribute data including document data, storage environment data, and logistics trajectory data; the goods image data including: goods sealed image data and goods unsealed image data; Processing module 302 is used to perform feature extraction and alignment processing on the cargo image data and the cargo attribute data to generate a joint semantic vector; Output module 303 is used to input the joint semantic vector into a pre-trained neural network model and output a transaction risk index; The generation module 304 is used to generate a contract call instruction based on the transaction risk index. The contract call instruction includes: the address of the target smart contract and the name of the target contract function in the target smart contract. Sending module 305 is used to send the contract call instruction to the blockchain so that the blockchain executes the target contract function in the target smart contract; The acquisition module 306 is used to acquire on-chain event data generated after the target contract function is executed, and to generate a processing certificate for the transaction request based on the association information between the on-chain event data and the transaction request.

[0112] In one possible embodiment, the step of performing feature extraction and alignment processing on the cargo image data and the cargo attribute data to generate a joint semantic vector includes: Convert the cargo attribute data into formatted text; The formatted text is input into the text encoder of the pre-trained multilingual CLIP model to generate text feature vectors; The cargo image data is input into the image encoder of the multilingual CLIP model to generate image feature vectors; Using the joint semantic space defined by the multilingual CLIP model, the image feature vector and the text feature vector are semantically aligned; The aligned image feature vector is fused with the text feature vector to generate the joint semantic vector.

[0113] In one possible embodiment, generating the contract invocation instruction based on the transaction risk index includes: The address of the corresponding target smart contract is retrieved based on the contract ID of the goods; the target smart contract includes multiple contract functions. The target contract function is determined from multiple contract functions based on the aforementioned trading risk index; The address of the target smart contract and the name of the target contract function are signed using a preset private key to generate a contract call instruction; The contract call instruction is broadcast to each node in the blockchain.

[0114] In one possible embodiment, determining the corresponding target contract function among multiple contract functions based on the trading risk index includes: The transaction risk index is compared with preset low-risk and high-risk thresholds; If the transaction risk index is lower than the low-risk threshold, determine the target contract function for paying out all funds. If the transaction risk index is between the low-risk threshold and the high-risk threshold, a target contract function is determined to freeze a preset proportion of the funds. If the transaction risk index is higher than the high-risk threshold, a target contract function is determined to freeze all funds.

[0115] In one possible embodiment, it also includes: The verification module is used to authenticate the requester of the transaction request, and the authentication is successful. The authenticity of the cargo attribute data and cargo image data is verified, and the result of the authenticity verification is passed.

[0116] In one possible embodiment, obtaining the on-chain event data generated after the execution of the target contract function includes: Monitor the event log data related to the target smart contract in the blockchain; Filter out the on-chain event data corresponding to the target contract function from the event log; The on-chain event data is formatted and then stored in a local database.

[0117] In one possible embodiment, it also includes: The writing module is used to associate the transaction request, the joint semantic vector, the function call instruction, and the processing credential and then write them into the blockchain.

[0118] It should be noted that the device 3 provided in the above embodiments, when executing the blockchain-based cross-border transaction method, is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the above functions. In addition, the blockchain-based cross-border transaction device and the blockchain-based cross-border transaction method embodiments provided in the above embodiments belong to the same concept, and their implementation process is detailed in the method embodiments, which will not be repeated here.

[0119] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0120] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements client-side functions or steps of a blockchain-based cross-border transaction method.

[0121] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements... Figure 2 The method shown can be referred to for its specific implementation process. Figure 2 As shown, it will not be elaborated further here.

[0122] In one embodiment, a computer-readable storage medium is provided that stores a computer program, which, when executed by a processor, is implemented... Figure 2 The method shown can be referred to for its specific implementation process. Figure 2 As shown, it will not be elaborated further here.

[0123] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0124] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0125] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0126] The above-described 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 the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A blockchain-based cross-border transaction method, characterized in that, Includes the following steps: The system receives a transaction request for goods, which includes: goods image data and goods attribute data. The goods attribute data includes document data, storage environment data, and logistics trajectory data. The goods image data includes: goods sealed image data and goods unsealed image data. Feature extraction and alignment are performed on the cargo image data and the cargo attribute data to generate a joint semantic vector; The joint semantic vector is input into a pre-trained neural network model, which then outputs a transaction risk index. A contract invocation instruction is generated based on the transaction risk index. The contract invocation instruction includes: the address of the target smart contract and the name of the target contract function in the target smart contract. Send the contract invocation instruction to the blockchain so that the blockchain executes the target contract function in the target smart contract; Obtain on-chain event data generated after the target contract function is executed, and generate a processing certificate for the transaction request based on the association information between the on-chain event data and the transaction request.

2. The blockchain-based cross-border transaction method according to claim 1, characterized in that, The step of performing feature extraction and alignment processing on the cargo image data and the cargo attribute data to generate a joint semantic vector includes: Convert the cargo attribute data into formatted text; The formatted text is input into the text encoder of the pre-trained multilingual CLIP model to generate text feature vectors; The cargo image data is input into the image encoder of the multilingual CLIP model to generate image feature vectors; Using the joint semantic space defined by the multilingual CLIP model, the image feature vector and the text feature vector are semantically aligned; The aligned image feature vector is fused with the text feature vector to generate the joint semantic vector.

3. The blockchain-based cross-border transaction method according to claim 1, characterized in that, The step of generating contract invocation instructions based on the transaction risk index includes: The address of the corresponding target smart contract is retrieved based on the contract ID of the goods; the target smart contract includes multiple contract functions. The target contract function is determined from multiple contract functions based on the aforementioned trading risk index; The address of the target smart contract and the name of the target contract function are signed using a preset private key to generate a contract call instruction; The contract call instruction is broadcast to each node in the blockchain.

4. The blockchain-based cross-border transaction method according to claim 3, characterized in that, The step of determining the corresponding target contract function among multiple contract functions based on the trading risk index includes: The transaction risk index is compared with preset low-risk and high-risk thresholds; If the transaction risk index is lower than the low-risk threshold, determine the target contract function for paying out all funds. If the transaction risk index is between the low-risk threshold and the high-risk threshold, a target contract function is determined to freeze a preset proportion of the funds. If the transaction risk index is higher than the high-risk threshold, a target contract function is determined to freeze all funds.

5. The blockchain-based cross-border transaction method according to claim 1, characterized in that, Before performing feature extraction and alignment processing on the cargo image data and the cargo attribute data to generate a joint semantic vector, the method further includes: The requester of the transaction request is authenticated, and the authentication is successful. The authenticity of the cargo attribute data and cargo image data is verified, and the result of the authenticity verification is passed.

6. The blockchain-based cross-border transaction method according to claim 1, characterized in that, The acquisition of on-chain event data generated after the execution of the target contract function includes: Monitor the event log data related to the target smart contract in the blockchain; Filter out the on-chain event data corresponding to the target contract function from the event log; The on-chain event data is formatted and then stored in a local database.

7. The blockchain-based cross-border transaction method according to claim 1, characterized in that, The method further includes: The transaction request, the joint semantic vector, the function call instruction, and the processing credential are associated and written into the blockchain.

8. A blockchain-based cross-border transaction device, characterized in that, The device includes: The receiving module is used to receive transaction requests for goods. The transaction requests include: goods image data and goods attribute data. The goods attribute data includes document data, storage environment data, and logistics trajectory data. The goods image data includes: goods sealed image data and goods unsealed image data. The processing module is used to perform feature extraction and alignment processing on the cargo image data and the cargo attribute data to generate a joint semantic vector; The output module is used to input the joint semantic vector into a pre-trained neural network model and output a transaction risk index. The generation module is used to generate a contract invocation instruction based on the transaction risk index. The contract invocation instruction includes: the address of the target smart contract and the name of the target contract function in the target smart contract. The sending module is used to send the contract call instruction to the blockchain so that the blockchain executes the target contract function in the target smart contract. The acquisition module is used to acquire on-chain event data generated after the target contract function is executed, and to generate a processing certificate for the transaction request based on the association information between the on-chain event data and the transaction request.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the blockchain-based cross-border transaction method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the blockchain-based cross-border transaction method as described in any one of claims 1 to 7.

Images