A multi-scenario intelligent transaction and data linkage processing system driven by an urban transaction brain

Abstract

This invention relates to the field of data processing technology and discloses a multi-scenario intelligent transaction and data linkage processing system driven by a city transaction brain. The system includes: a privacy computing awareness layer that extracts local transaction event features using federated learning edge nodes deployed in independent transaction subsystems and outputs feature gradient sequences to protect the privacy of the original data; a city transaction brain central layer that maps the gradient sequences to a dynamic transaction knowledge graph, predicts the probability of the correlation impact of core transaction events on affected nodes across scenarios using a graph neural network model, calculates the incremental demand for concurrent computing resources, and generates cross-scenario linkage instructions when the dynamic adaptive threshold is exceeded; and a multi-scenario linkage execution layer that parses the linkage instructions to generate composite smart contracts and executes them in parallel using a two-stage cross-chain submission mechanism. This invention achieves data privacy mutual trust in cross-domain transactions, intelligent prediction and reservation of resource demands, and strong consistency linkage of underlying data states.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a multi-scenario intelligent transaction and data linkage processing system driven by an urban transaction brain. Background Technology

[0002] With the continuous development of smart cities, numerous independent trading subsystems have emerged, such as municipal public resource trading centers, provincial power trading centers, and national carbon emission trading platforms. However, existing city-level trading systems still face the following technical bottlenecks in cross-scenario business collaboration and underlying data linkage processing:

[0003] First, the various independent transaction subsystems typically belong to different administrative or commercial entities, resulting in significant data silos between them. Under compliance requirements such as the Data Security Law, direct interoperability and sharing of raw data are difficult, leading to a lack of trust in cross-domain collaboration.

[0004] Secondly, multi-scenario transactions in cities often have a ripple effect. For example, after a company successfully bids for industrial land in scenario A, it will typically apply for high-voltage power capacity expansion in scenario B and purchase carbon emission allowances in scenario C. Existing systems mostly adopt a serial mode of post-application and queuing, lacking the ability to predict the chain reaction of cross-domain transactions and failing to reserve and allocate underlying computing resources in advance for upcoming concurrent requests, which can easily lead to system resource shortages during the morning peak of transactions.

[0005] Finally, different scenarios often employ different heterogeneous blockchain networks or distributed databases at their underlying layers. When performing cross-scenario collaborative operations, the lack of strong global consistency control makes it easy to generate dirty write issues where some operations succeed while others fail, leading to serious business failures that severely disrupt the consistency of underlying data, such as a successful land auction but failure to reserve supporting power resources. Summary of the Invention

[0006] This invention provides a multi-scenario intelligent transaction and data linkage processing system driven by a city transaction brain. Under the premise of ensuring the privacy of multimodal transaction data and strong consistency of heterogeneous database states, it realizes accurate calculation and prediction of cross-domain transaction ripple effects and intelligent and automated linkage allocation of underlying system computing resources.

[0007] This invention provides a multi-scenario intelligent transaction and data linkage processing system driven by an urban transaction brain, comprising:

[0008] The privacy computing perception layer includes federated learning edge nodes deployed in multiple independent trading subsystems. The federated learning edge nodes are used to extract features from local trading events occurring within their respective independent trading subsystems without sharing the original multimodal trading data, and output a feature gradient sequence including the trading subject, trading object, and current trading status. Among them, the multiple independent trading subsystems respectively correspond to different urban trading scenarios;

[0009] The urban trading brain central layer is communicatively connected to the privacy computing perception layer and specifically includes:

[0010] The cross-scenario graph construction module is used to map the feature gradient sequence into a dynamic trading knowledge graph. Among them, the graph nodes represent the trading subject and trading object, and are updated in time series according to the current trading status. The graph edges represent the association and dependence relationships between different independent trading subsystems established based on historical cross-domain trading records;

[0011] The ripple effect prediction module is used to, when detecting a local trading event as a core trading event occurring in the first scenario, determine the graph node representing the core trading event as a trigger node in the dynamic trading knowledge graph, calculate the feature weights transmitted by the trigger node along the graph edges to at least one affected node corresponding to the second scenario, and map them into the probability of associated influence, so as to calculate the incremental concurrent computing resource requirements of the affected nodes in the second scenario. Among them, the first scenario and the second scenario are both urban trading scenarios;

[0012] The linkage adaptive trigger module is used to calculate the associated influence index of the affected nodes based on the probability and the incremental concurrent computing resource requirements, and generate a cross-scenario linkage instruction when the associated influence index exceeds the dynamic adaptive threshold;

[0013] The multi-scenario linkage execution layer is communicatively connected to the urban trading brain central layer and specifically includes:

[0014] The composite intelligent contract generation module is used to parse the cross-scenario linkage instruction, call the cross-domain contract templates matching the first scenario and the second scenario, embed the trading request corresponding to the core trading event and the resource allocation request corresponding to the incremental concurrent computing resource requirements into the cross-domain contract templates respectively, and generate a composite intelligent contract;

[0015] The distributed transaction coordination module is used to execute the composite intelligent contract in parallel by adopting a two-phase cross-chain submission mechanism to ensure the data consistency of the underlying data state updates between the first scenario and the second scenario, and complete the cross-scenario data linkage processing and intelligent trading.

[0016] Furthermore, in the privacy-aware computing layer, the federated learning edge nodes extract features from local transaction events occurring within their respective independent transaction subsystems and output a feature gradient sequence containing the transaction subject, transaction object, and current transaction state, specifically including:

[0017] Obtain the multimodal raw transaction data corresponding to the local transaction event, including structured data and unstructured data;

[0018] The multimodal raw transaction data is preprocessed by alignment and denoising to extract implicit feature vectors representing the transaction subject, the transaction object, and the current transaction state; wherein, the implicit feature vectors include transaction subject feature vectors representing the business attributes of the buyer and seller, transaction object feature vectors representing the resource attributes of the transaction target, and current transaction state feature vectors representing the transaction lifecycle;

[0019] Based on the implicit feature vector and the global basic model parameters issued by the central layer of the city transaction brain, the model forward propagation and backward propagation calculations are performed locally at the federated learning edge node to generate local feature gradients.

[0020] The local feature gradients within a continuous time window are combined, a preset encryption component is invoked, and a homomorphic encryption algorithm or a differential privacy algorithm is used to encrypt and encapsulate or add noise to the feature gradient sequence, thereby generating the feature gradient sequence and outputting it to the central layer of the city transaction brain.

[0021] Furthermore, the local feature gradient The calculation formula is:

[0022]

[0023] in, This represents the local feature gradient generated by the i-th federated learning edge node in the t-th communication iteration; This represents the global basic model parameters issued by the central layer of the city transaction brain for the t-th iteration; The data set representing the implicit feature vectors; This represents a data set based on the implicit feature vectors. and the global basic model parameters The calculated local loss function; This represents partial derivative operations.

[0024] Furthermore, in the central layer of the city transaction brain, the cross-scenario graph construction module maps the feature gradient sequence into a dynamic transaction knowledge graph, and updates it temporally based on the current transaction status, specifically including:

[0025] A directed attribute graph is constructed as the basic data structure of the dynamic transaction knowledge graph, wherein the graph nodes of the directed attribute graph are used to represent the transaction subjects and transaction objects participating in the transaction;

[0026] The received feature gradient sequences are aggregated using a federated learning aggregation algorithm to update the network weights of the global base model. The updated global base model outputs the implicit feature vectors of each trading entity and trading object, which are then mapped to the node attribute values ​​of the corresponding graph nodes.

[0027] When the feature gradient sequence contains information about changes in the current transaction state, the gated loop unit is invoked to update the historical state of the corresponding graph node in a temporal sequence. The calculation formula for the temporal update of the node state is as follows:

[0028]

[0029] in, This represents the hidden state feature representation of node i at the current time step t; This represents the newly added transaction state feature input obtained by mapping the feature gradient sequence; This indicates the historical hidden state of node i in the previous time step; This represents the nonlinear activation and memory update operation of the gated loop unit.

[0030] Furthermore, in the central layer of the city transaction brain, the ripple effect prediction module calculates the feature weights transmitted by the triggering node along the graph edge to at least one affected node corresponding to the second scenario, specifically including:

[0031] The attention mechanism of a graph neural network model is adopted. Starting from the trigger node, features are passed along the cross-domain graph edge to the target affected node. The formula for calculating the feature passing weight during the passing process is as follows:

[0032]

[0033] in, This indicates that the triggering node i passes the weight of the feature to the affected node j; and These represent the current implicit feature vectors of the triggering node i and the affected node j, respectively. The shared linear transformation weight matrix is ​​learnable by the model; || represents the feature concatenation operation; This represents the weight vector of a single-layer feedforward neural network. The set of graph neighbor nodes of the trigger node i; It is a non-linear activation function.

[0034] Furthermore, in the central layer of the city transaction brain, the ripple effect prediction module calculates the incremental concurrent computing resource demand of the affected nodes in the second scenario, specifically including:

[0035] The newly generated feature vector, after aggregating the affected nodes, is input into the fully connected layer and the classifier to map the probability that the core transaction event will have a correlation effect on the affected nodes.

[0036] Based on the probability and the historical concurrency baseline of the second scenario, the incremental demand for concurrent computing resources is calculated using the following formula:

[0037]

[0038] in, This represents the incremental demand for concurrent computing resources; This represents the probability of the associated influence derived from the mapping; This indicates the baseline computing resources required to process a single standard transaction in the second scenario, including CPU computing power, memory allocation, and number of database connections; This represents the complexity coefficient that is adaptively adjusted based on the size of the transaction object.

[0039] Furthermore, the linkage adaptive triggering module in the central layer of the city transaction brain specifically includes:

[0040] The correlation impact index of the affected nodes is calculated based on the probability and the incremental demand for concurrent computing resources. The calculation formula is as follows:

[0041]

[0042] in, This represents the correlation impact index; This indicates the probability of the associated influence; This represents the incremental demand for concurrent computing resources; and These are preset probability weights and resource weights, respectively, and satisfy the following conditions: ; This is the resource normalization coefficient;

[0043] Obtain the real-time operating status data of the underlying distributed server cluster and calculate the dynamic adaptive threshold using the following formula:

[0044]

[0045] in, The dynamic adaptive threshold represents the current time step t; The baseline trigger threshold; As a penalty regulator; and These represent the real-time memory usage and the average CPU load rate at the current time step t, respectively. and These represent the total memory capacity and the total number of processor cores, respectively.

[0046] When the correlation impact index of the affected node is continuously greater than or equal to the dynamic adaptive threshold within a preset sliding time window, it is determined that the linkage triggering condition is met, and a data frame containing underlying call parameters is generated and sent to the message queue inside the system as the cross-scene linkage instruction.

[0047] Furthermore, in the multi-scenario linkage execution layer, the composite smart contract generation module specifically includes:

[0048] The data frames of the cross-scenario linkage instructions are deserialized and parsed to extract the source node identifier, affected node identifier, and concurrent computing resource demand increment of the core transaction event;

[0049] Based on the extracted source node identifier and affected node identifier, the matching cross-domain contract template containing the cross-chain call interface is invoked from the underlying contract repository;

[0050] The transaction request corresponding to the core transaction event is hardcoded into the main transaction execution function of the cross-domain contract template, and the resource allocation request corresponding to the concurrent computing resource demand increment is hardcoded into the resource reservation function of the cross-domain contract template to generate the composite smart contract.

[0051] Furthermore, in the multi-scenario linkage execution layer, the distributed transaction coordination module employs a two-phase cross-chain commit mechanism to execute the composite smart contract in parallel, including a preparation phase and an execution phase; the preparation phase specifically includes:

[0052] The distributed transaction coordination module, acting as a transaction coordinator, broadcasts a pre-commit instruction to the underlying subsystem nodes corresponding to the first and second scenarios participating in the composite smart contract.

[0053] Each of the underlying subsystem nodes pre-executes the logic of the composite smart contract locally, and determines the corresponding underlying data rows and computing resources based on the incremental concurrent computing resource requirements, while keeping the underlying final ledger state unchanged.

[0054] If the underlying subsystem node successfully performs local pre-execution and acquires the lock, it returns a ready response to the transaction coordinator; if pre-execution fails or resource locking fails, it returns an abort response.

[0055] Furthermore, the execution phase specifically includes:

[0056] If the transaction coordinator collects the ready responses from all the underlying subsystem nodes participating in the composite smart contract within the preset timeout period, it broadcasts a global commit instruction to the entire network to trigger each underlying subsystem node to persist the pre-committed data changes to the underlying ledger and release resource locks, thereby completing the underlying data state update.

[0057] If the transaction coordinator receives an abort response from any of the underlying subsystem nodes, or fails to collect all the ready responses within the preset timeout period, it broadcasts a global rollback instruction to the entire network to trigger each of the underlying subsystem nodes to revoke the resource locking and caching operations of the preparation phase, so that the underlying data state is rolled back to the initial state before the core transaction event occurred.

[0058] The beneficial effects of this invention are as follows:

[0059] This invention introduces federated learning edge nodes into the privacy computing awareness layer, outputting feature gradient sequences without requiring the original data to leave the domain. This fundamentally breaks down data silos between various transaction subsystems in the city and solves the privacy and trust bottleneck. At the central layer, it innovatively maps feature gradients to a dynamic transaction knowledge graph and combines this with a graph neural network model for ripple effect prediction. This accurately quantifies the probability of associated impacts caused by core transaction events across scenarios and pre-calculates the incremental demand for concurrent computing resources in the target scenario. Coupled with a dynamic adaptive threshold triggering mechanism based on the system's real-time operating load, it achieves intelligent pre-allocation and peak shaving of underlying computing resources. Finally, at the execution layer, through dynamic assembly of composite smart contracts and a two-stage cross-chain submission mechanism, it strictly guarantees the atomicity of main transactions and resource pre-allocation across heterogeneous systems and the strong consistency of underlying data states, effectively avoiding cross-scenario data breakage failures and significantly improving the processing efficiency and system concurrency stability of smart transactions across multiple city scenarios. Attached Figure Description

[0060] Figure 1 This is a schematic diagram of the structure of the multi-scenario intelligent transaction and data linkage processing system driven by the city transaction brain of the present invention.

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

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

[0063] like Figure 1 As shown, this invention provides a multi-scenario intelligent transaction and data linkage processing system driven by an urban transaction brain, comprising:

[0064] The privacy computing perception layer includes federated learning edge nodes deployed in multiple independent trading subsystems. The federated learning edge nodes are used to extract features from local trading events occurring within their respective independent trading subsystems without sharing the original multimodal trading data, and output a feature gradient sequence including the trading subject, trading object, and current trading status. Among them, the multiple independent trading subsystems respectively correspond to different urban trading scenarios;

[0065] The urban trading brain central layer is communicatively connected to the privacy computing perception layer and specifically includes:

[0066] The cross-scenario graph construction module is used to map the feature gradient sequence into a dynamic trading knowledge graph. Among them, the graph nodes represent the trading subject and trading object, and are updated in time series according to the current trading status. The graph edges represent the association and dependence relationships between different independent trading subsystems established based on historical cross-domain trading records;

[0067] The rippling effect prediction module is used to, when detecting a local trading event as a core trading event occurring in the first scenario, determine the graph node representing the core trading event as a trigger node in the dynamic trading knowledge graph, calculate the feature weights transmitted by the trigger node along the graph edges to at least one affected node corresponding to a second scenario, and map them into the probability of associated influence, so as to calculate the increment of the concurrent computing resource requirements of the affected node in the second scenario. Among them, the first scenario and the second scenario are both urban trading scenarios;

[0068] The linkage adaptive trigger module is used to calculate the associated influence index of the affected node based on the probability and the increment of the concurrent computing resource requirements, and generate a cross-scenario linkage instruction when the associated influence index exceeds the dynamic adaptive threshold;

[0069] The multi-scenario linkage execution layer is communicatively connected to the urban trading brain central layer and specifically includes:

[0070] The composite intelligent contract generation module is used to parse the cross-scenario linkage instruction, call the cross-domain contract template matching the first scenario and the second scenario, embed the trading request corresponding to the core trading event and the resource allocation request corresponding to the increment of the concurrent computing resource requirements into the cross-domain contract template respectively, and generate a composite intelligent contract;

[0071] The distributed transaction coordination module is used to execute the composite intelligent contract in parallel by adopting a two-phase cross-chain submission mechanism to ensure the data consistency of the underlying data state update between the first scenario and the second scenario, and complete the cross-scenario data linkage processing and intelligent trading.

[0072] (1) Privacy computing perception layer

[0073] In a preferred embodiment of the present invention, the privacy-aware computing layer directly addresses extremely complex heterogeneous data sources at the city level. Since multiple independent trading subsystems within a city typically belong to different administrative or commercial entities (e.g., municipal public resource trading centers, provincial power trading centers, national carbon emission trading platforms, etc.), data silos exist between them. To break down these data silos and meet compliance requirements such as the Data Security Law, federated learning edge nodes are deployed within each independent trading subsystem. These edge nodes act as lightweight algorithm containers, embedding local feature extraction models and homomorphic encryption components. Their core principle is that data is usable but not visible, and the original data does not leave the domain.

[0074] When a local transaction event occurs within the independent transaction subsystem, the federated learning edge node first acquires the multimodal raw data of that event. Specifically, the multimodal data includes, but is not limited to:

[0075] Structured data: Transaction details form (such as transaction amount, quantity, timestamp).

[0076] Unstructured data: transaction contract texts, electronic invoices (PDF / image format), and surveillance video frames from the transaction site.

[0077] The edge nodes are equipped with a multimodal data cleaning module to align, denoise, and standardize the heterogeneous data. The preprocessed data is then input into the local feature extraction model of the edge nodes (e.g., using pre-trained BERT for contract text, ResNet for image vouchers, and MLP for structured forms). The local model does not focus on specific privacy-related numerical values ​​of the transaction, but rather on abstracting implicit feature vectors for three core dimensions supporting subsequent graph construction: transaction subject features, transaction object features, and current transaction status features. Transaction subject features are vector representations of the industry attributes, credit ratings, and historical activity of both buyers and sellers. Transaction object features are the extracted resource attribute vectors of the transaction object (e.g., land area, electricity consumption in megawatt-hours, carbon quota in tons). The current transaction status features are the extracted time-series vectors of the transaction's lifecycle status (e.g., listed, bidding, completed).

[0078] Edge nodes receive global basic model parameters from the central layer of the city's transaction brain. Edge nodes utilize locally extracted subject, object, and state feature data. As input, the model's forward and backward propagation are calculated locally to derive the loss function for the current local transaction event. Local feature gradients of model parameters The calculation formula is as follows:

[0079]

[0080] Subsequently, the edge nodes combine multiple local feature gradients within a continuous time window to form the feature gradient sequence.

[0081] Before outputting to the central layer of the city's transaction brain, edge nodes call homomorphic encryption or differential privacy algorithms to add noise or encapsulate the feature gradient sequence. This ensures that the central layer only needs to aggregate and utilize the gradient update amount to build and update the global dynamic transaction knowledge graph, without having to grasp the specific transaction details of any independent subsystem. This solves the trust and privacy bottlenecks of cross-scenario linkage from the underlying computer architecture.

[0082] (2) The central layer of the urban transaction brain

[0083] ① Cross-scene graph construction module

[0084] In a preferred embodiment of the present invention, the cross-scene graph construction module constructs a directed attribute graph. This serves as the foundational data structure for the dynamic transaction knowledge graph. It represents the set of graph nodes at time step t, which includes two types of core nodes: the subject nodes representing the participants in the transaction (such as enterprises, natural persons, and government agencies) and the object nodes representing the transaction objects (such as land parcels, pollution discharge quotas, and electricity megawatt-hours). This represents the set of graph edges at time step t, used to characterize the association and dependency relationships between different nodes.

[0085] The cross-scenario graph construction module receives feature gradient sequences transmitted from the privacy-aware computing layer. To update the graph without parsing the original data, a global embedding matrix mechanism is used for node mapping. Specifically, a federated learning aggregation algorithm is used to aggregate the feature gradients of each federated learning edge node, updating the network weights of the global base model deployed in the central layer. The updated global base model outputs the latest implicit feature vectors corresponding to each transaction subject and transaction object, and these vectors are mapped to graph nodes. The node attribute values.

[0086] Since city transactions are a long-term dynamic process (e.g., from listing and bidding to fund settlement), a time-series-based node state update logic is introduced. When the feature gradient sequence contains information about changes in the current transaction state, a gated recurrent unit (GRU) is invoked to update the historical state of the corresponding node in time series, recording the evolution trajectory of the transaction on the timeline. The calculation formula for the node state time series update satisfies:

[0087]

[0088] in, This represents the hidden state feature representation of node i at the current time step t; This represents the input of new transaction state features obtained by mapping the current feature gradient sequence; This indicates the hidden historical state of the node at the previous time step; This indicates that the nonlinear activation and memory update operations of the gated cyclic unit enable the graph nodes to have memory capabilities, and they are no longer static and isolated data points.

[0089] Graph edges not only reflect buying and selling relationships within a single scenario, but more importantly, they establish the correlation and dependency relationships between different independent transaction subsystems. By reading pre-stored globally anonymized historical cross-domain transaction records (for example, historically, after a company successfully bids for industrial land in scenario A, it typically applies for high-voltage power capacity expansion in scenario B and purchases carbon emission allowances in scenario C), frequent co-occurrence patterns across scenarios are extracted using frequent itemset mining algorithms (such as FP-Growth) or causal inference models. Specifically, when a node in scenario one is found... With the nodes in Scenario 2 When there is high co-occurrence or causal dependence, create a cross-domain graph edge in the graph. And assign an initial dependency weight to the edge. The dependency weight is positively correlated with the frequency of historical cross-domain transactions.

[0090] After the node mapping, temporal updates, and edge construction described above, the cross-scenario graph construction module completes the construction of the dynamic transaction knowledge graph. The data is refreshed and stored in a graph database (such as Neo4j or a distributed in-memory graph cache) in a standard graph data format (such as adjacency matrix and feature matrix in matrix form).

[0091] ② Ripple Effect Prediction Module

[0092] In a preferred embodiment of the present invention, the ripple effect prediction module continuously monitors the transaction status information aggregated by the privacy computing awareness layer. When a core transaction event meeting preset conditions occurs within a first scenario (e.g., a large-scale industrial land transfer scenario on a municipal public resource trading platform) (such as a company successfully winning a bid for an industrial land plot), the dynamic transaction knowledge graph output by the cross-scenario graph construction module is first processed. In the process, the graph node representing the core transaction event is retrieved and identified through node identifiers, and then marked as the trigger node (source node). .

[0093] To quantify this cross-scenario ripple effect, a graph neural network model with an attention mechanism (such as Graph Attention Networks, GAT) is pre-defined. This model does not rely on pre-defined static rules but adaptively learns the influence of transaction behavior through a node aggregation mechanism. Specifically, the trigger node... Starting from the aforementioned graph edge, proceed to at least one affected node (target node) corresponding to a second scenario (e.g., the electricity capacity expansion scenario of the provincial power trading platform, or the carbon quota trading scenario of the carbon emission platform). Feature propagation is performed. During the propagation process, the node aggregation mechanism of the graph neural network model is invoked to calculate the feature propagation weights. This weight characterizes the degree of substantial impact of the transaction behavior of triggering node i on the affected node j, and its calculation formula satisfies:

[0094]

[0095] in, and These represent the current implicit feature vectors of node i (the triggering node) and node j (the affected node), respectively. The shared linear transformation weight matrix is ​​learnable by the model; || represents the feature concatenation operation; This represents the weight vector of a single-layer feedforward neural network. Let i be the set of its graph neighbor nodes; It is a non-linear activation function.

[0096] After calculating the feature propagation weights of each affected node, the ripple effect prediction module inputs the newly aggregated feature vector of the affected nodes into the fully connected layer and the Sigmoid classifier, mapping the high-dimensional feature space into a one-dimensional probability of association influence. The probability This is used to accurately quantify the likelihood that the core transaction event in the first scenario will trigger related transactions in the second scenario (for example, after a company acquires land, there is an 85% probability that it will initiate a 5,000 kVA power connection request within three months).

[0097] After obtaining the probability of the associated impact, unlike the traditional post-application and queuing mode, the incremental concurrent computing resource requirements of the affected nodes in the second scenario are calculated in advance. The calculation of this increment takes into account both the impact probability and the historical concurrency baseline of the target scenario. The calculation formula is as follows:

[0098]

[0099] in, This indicates the baseline computing resources (including CPU computing power, memory allocation, and number of database connections) required to process a single standard transaction in the second scenario. This is a complexity coefficient that adaptively adjusts based on the size of the transaction objects. It represents the calculated increment in concurrent computing resource requirements. As a key parameter, the output is linked to the adaptive triggering module.

[0100] ③ Linkage Adaptive Trigger Module

[0101] In a preferred embodiment of the present invention, the linkage adaptive triggering module receives the correlation influence probability output from the ripple effect prediction module. and the incremental demand for concurrent computing resources Then, the quantitative evaluation of the correlation impact index was initiated first. A nonlinear evaluation function that comprehensively considers the probability of occurrence and the system cost was constructed to calculate the affected nodes. The correlation impact index :

[0102]

[0103] in, and These are probability weights and resource weights, respectively (and satisfy...) (This can be preset and configured according to the fault tolerance rate of different city transaction scenarios); This is the resource normalization coefficient, used to map the incremental computational resources to a dimensionless interval with the same dimensions as the probability.

[0104] To prevent the underlying database from crashing due to excessive cross-scenario linkages during peak urban transaction periods (such as centralized bidding for public resources), a dynamic adaptive threshold is introduced. This threshold is related to the global resource overhead of the current system, and its update calculation formula is as follows:

[0105]

[0106] in, This serves as the baseline trigger threshold for system cold starts; As a penalty regulator; and These represent the real-time memory usage and average CPU load of the distributed server cluster at the bottom layer of the entire city transaction system at the current time step t. When the system's underlying computing power is sufficient, the threshold automatically decreases to encourage proactive data caching and resource reservation across scenarios; when the system load approaches the red line, the threshold automatically increases to suppress non-urgent ripple-effect linkage requests.

[0107] The linkage adaptive triggering module utilizes the calculated correlation influence index. Dynamic adaptive threshold at the current time step Real-time comparison is performed. To prevent frequent false triggers caused by minor oscillations in the features of the affected nodes, an embedded time window debouncing mechanism is used, allowing the system to only perform false triggers when the affected node's characteristics are stable. Within the preset sliding time window Internal duration greater than or equal to Only when the conditions for triggering the linkage are met will it be determined that the linkage triggering conditions are met.

[0108] Once the triggering conditions are met, a structured cross-scene linkage instruction is immediately generated. During data packet encapsulation, this instruction is a data frame containing underlying call parameters. The instruction payload forcibly hard-codes and encapsulates the following parameter sequence:

[0109] Core transaction event information includes the source node identifier (such as the transaction order number ID in the first scenario), transaction timestamp, and status hash value.

[0110] Incremental concurrent computing resource requirements: The above calculations are used to determine the incremental requirements. The specific resource allocation instructions required to transform into the second scenario server (such as requesting the allocation of a 2GB memory cache and 50 database connection pool threads).

[0111] Affected node identifier: Business node ID and routing address of the target scenario.

[0112] After encapsulation, the cross-scenario linkage instruction is asynchronously sent to the multi-scenario linkage execution layer through the system's internal high-speed message queue (such as Kafka or RocketMQ).

[0113] (3) Multi-scenario linkage execution layer

[0114] ① Composite Smart Contract Generation Module

[0115] In a preferred embodiment of the present invention, the composite smart contract generation module continuously monitors the message queue inside the system. When it receives a cross-scenario linkage instruction issued by the central layer, it first deserializes and parses the data frame of the instruction to extract the core load parameters, namely the source node identifier of the core transaction event (i.e., the business entity and operation of the first scenario), the target affected node identifier (i.e., the business entity of the second scenario), and the incremental demand for concurrent computing resources.

[0116] Subsequently, based on the extracted scenario identifier, a matching cross-domain contract template is called from the underlying contract repository. This template is a standardized code framework pre-written in a Turing-complete language (such as Solidity or Go), with reserved interface parameter bits for cross-chain calls.

[0117] After obtaining the template, the composite smart contract generation module performs parameter embedding and dynamic code assembly. Specifically, the transaction request corresponding to the core transaction event (e.g., the request to confirm the transfer of ownership of the target land plot by the winning bidder in the first scenario) is hard-coded into the Main_Transaction() function of the contract as the main transaction execution logic. The resource allocation request corresponding to the incremental concurrent computing resource demand (e.g., requesting the server in the second scenario to lock the corresponding megawatt-hour power index memory data block, or reserving the corresponding database concurrent connection pool) is hard-coded into the Resource_Reservation() function of the contract as a resource reservation operation.

[0118] Through the above assembly and compilation, operations that originally belonged to two different business domains are physically encapsulated into the same composite smart contract.

[0119] ② Distributed Transaction Coordination Module

[0120] In a preferred embodiment of the present invention, since the first scenario and the second scenario (such as the public resource trading chain and the carbon emission trading chain) often belong to different heterogeneous blockchain networks or distributed databases at their underlying levels, direct execution is highly likely to cause data inconsistency problems due to dirty writes or partial success. Therefore, the distributed transaction coordination module introduces a two-phase cross-chain commit mechanism. Specifically,

[0121] During the preparation phase (pre-commit phase), the transaction coordinator broadcasts the Prepare instruction to all subsystem nodes participating in the composite smart contract. The local execution engines of both the first and second scenarios execute the contract logic locally, but only determine the underlying data rows and computing resources (such as locking the incremental concurrent computing resource requirements involved in the transaction), without modifying the final state. If local pre-execution succeeds and locking is successful, a Ready response is returned to the coordinator; if pre-execution fails (e.g., the second scenario finds that underlying computing resources are exhausted or a network timeout occurs), an Abort response is returned.

[0122] During the execution phase, the distributed transaction coordination module enters the final decision-making and state update phase. Specifically, if the coordinator collects Ready responses from all participating nodes (including those in the first and second scenarios) within the preset timeout period, it broadcasts a Commit command to the entire network. Upon receiving the command, each subsystem node writes the pre-committed data changes to the underlying ledger (or persists them to the database), releases resource locks, and ensures strong consistency and atomicity between the main transaction and resource pre-allocation.

[0123] If the coordinator receives an Abort response from any node, or if a response times out, it triggers a fail-safe mechanism, broadcasting a Rollback command to the entire network. All subsystem nodes then cancel all resource locks and cache operations from the preparation phase, reverting the state to before the transaction occurred. This effectively avoids serious business failures such as "land auction successful, but power resource reservation failed" due to cross-scenario data breaks.

[0124] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0125] The above description is merely a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A multi-scenario intelligent transaction and data linkage processing system driven by an urban transaction brain, characterized in that, Comprising: A privacy computing perception layer, including federated learning edge nodes deployed in multiple independent trading subsystems, where the federated learning edge nodes are used to extract features from local trading events occurring within their respective independent trading subsystems without sharing the original multi-modal trading data, and output a feature gradient sequence containing the trading subject, trading object, and current trading status; wherein, the multiple independent trading subsystems respectively correspond to different urban trading scenarios; An urban trading brain central layer, communicatively connected to the privacy computing perception layer, specifically including: A cross-scenario graph construction module, used to map the feature gradient sequence into a dynamic trading knowledge graph; wherein, the graph nodes represent the trading subject and the trading object, and are updated in time series according to the current trading status, and the graph edges represent the associated dependency relationships between different independent trading subsystems established based on historical cross-domain trading records; A ripple effect prediction module, used to when detecting a local trading event as a core trading event occurring in a first scenario, determine the graph node representing the core trading event in the dynamic trading knowledge graph as a trigger node, calculate the feature weights transmitted by the trigger node along the graph edges to at least one affected node corresponding to a second scenario, and map them into the probability of associated influence, so as to calculate the increment of the concurrent computing resource requirements of the affected node in the second scenario; wherein, the first scenario and the second scenario are both urban trading scenarios; A linkage adaptive trigger module, used to calculate the associated influence index of the affected node based on the probability and the increment of the concurrent computing resource requirements, and generate a cross-scenario linkage instruction when the associated influence index exceeds the dynamic adaptive threshold; A multi-scenario linkage execution layer, communicatively connected to the urban trading brain central layer, specifically including: A composite intelligent contract generation module, used to parse the cross-scenario linkage instruction, call a cross-domain contract template matching the first scenario and the second scenario, and embed the trading request corresponding to the core trading event and the resource allocation request corresponding to the increment of the concurrent computing resource requirements into the cross-domain contract template respectively, to generate a composite intelligent contract; A distributed transaction coordination module, used to execute the composite intelligent contract in parallel by adopting a two-phase cross-chain submission mechanism, so as to ensure the data consistency of the underlying data state update between the first scenario and the second scenario, and complete the cross-scenario data linkage processing and intelligent trading.

2. The multi-scenario intelligent transaction and data linkage processing system driven by the city transaction brain according to claim 1, characterized in that, In the privacy computing perception layer, the federated learning edge nodes extract features from local trading events occurring within their respective independent trading subsystems, and output a feature gradient sequence containing the trading subject, trading object, and current trading status, specifically including: Obtaining the multi-modal original trading data corresponding to the local trading event, including structured data and unstructured data; The multimodal raw transaction data is preprocessed by alignment and denoising to extract implicit feature vectors representing the transaction subject, the transaction object, and the current transaction state; wherein, the implicit feature vectors include transaction subject feature vectors representing the business attributes of the buyer and seller, transaction object feature vectors representing the resource attributes of the transaction target, and current transaction state feature vectors representing the transaction lifecycle; Based on the implicit feature vector and the global basic model parameters issued by the central layer of the city transaction brain, the model forward propagation and backward propagation calculations are performed locally at the federated learning edge node to generate local feature gradients. The local feature gradients within a continuous time window are combined, a preset encryption component is invoked, and a homomorphic encryption algorithm or a differential privacy algorithm is used to encrypt and encapsulate or add noise to the feature gradient sequence, thereby generating the feature gradient sequence and outputting it to the central layer of the city transaction brain.

3. The multi-scenario intelligent transaction and data linkage processing system driven by the city transaction brain according to claim 2, characterized in that, The local feature gradient The calculation formula is: in, This represents the local feature gradient generated by the i-th federated learning edge node in the t-th communication iteration; This represents the global basic model parameters issued by the central layer of the city transaction brain for the t-th iteration; The data set representing the implicit feature vectors; This represents a data set based on the implicit feature vectors. and the global basic model parameters The calculated local loss function; This represents partial derivative operations.

4. The multi-scenario intelligent transaction and data linkage processing system driven by the city transaction brain according to claim 1, characterized in that, In the central layer of the city transaction brain, the cross-scenario graph construction module maps the feature gradient sequence into a dynamic transaction knowledge graph and updates it temporally based on the current transaction status, specifically including: A directed attribute graph is constructed as the basic data structure of the dynamic transaction knowledge graph, wherein the graph nodes of the directed attribute graph are used to represent the transaction subjects and transaction objects participating in the transaction; The received feature gradient sequences are aggregated using a federated learning aggregation algorithm to update the network weights of the global base model. The updated global base model outputs the implicit feature vectors of each trading entity and trading object, which are then mapped to the node attribute values ​​of the corresponding graph nodes. When the feature gradient sequence contains information about changes in the current transaction state, the gated loop unit is invoked to update the historical state of the corresponding graph node in a temporal sequence. The calculation formula for the temporal update of the node state is as follows: in, This represents the hidden state feature representation of node i at the current time step t; This represents the newly added transaction state feature input obtained by mapping the feature gradient sequence; This indicates the historical hidden state of node i in the previous time step; This represents the nonlinear activation and memory update operation of the gated loop unit.

5. The multi-scenario intelligent transaction and data linkage processing system driven by the city transaction brain according to claim 4, characterized in that, In the central layer of the city transaction brain, the ripple effect prediction module calculates the feature weights transmitted by the triggering node along the graph edge to at least one affected node corresponding to the second scenario, specifically including: The attention mechanism of a graph neural network model is adopted. Starting from the trigger node, features are passed along the cross-domain graph edge to the target affected node. The formula for calculating the feature passing weight during the passing process is as follows: in, This indicates that the triggering node i passes the weight of the feature to the affected node j; and These represent the current implicit feature vectors of the triggering node i and the affected node j, respectively. The shared linear transformation weight matrix is ​​learnable by the model; || represents the feature concatenation operation; This represents the weight vector of a single-layer feedforward neural network. The set of graph neighbor nodes of the trigger node i; It is a non-linear activation function.

6. The multi-scenario intelligent transaction and data linkage processing system driven by the city transaction brain according to claim 5, characterized in that, In the central layer of the city transaction brain, the ripple effect prediction module calculates the incremental concurrent computing resource demand of the affected nodes in the second scenario, specifically including: The newly generated feature vector, after aggregating the affected nodes, is input into the fully connected layer and the classifier to map the probability that the core transaction event will have a correlation effect on the affected nodes. Based on the probability and the historical concurrency baseline of the second scenario, the incremental demand for concurrent computing resources is calculated using the following formula: in, This represents the incremental demand for concurrent computing resources; This represents the probability of the associated influence derived from the mapping; This indicates the baseline computing resources required to process a single standard transaction in the second scenario, including CPU computing power, memory allocation, and number of database connections; This represents the complexity coefficient that is adaptively adjusted based on the size of the transaction object.

7. The multi-scenario intelligent transaction and data linkage processing system driven by the city transaction brain according to claim 1, characterized in that, The central layer of the city transaction brain specifically includes the following linkage and adaptive triggering module: The correlation impact index of the affected nodes is calculated based on the probability and the incremental demand for concurrent computing resources. The calculation formula is as follows: in, This represents the correlation impact index; This indicates the probability of the associated influence; This represents the incremental demand for concurrent computing resources; and These are preset probability weights and resource weights, respectively, and satisfy the following conditions: ; This is the resource normalization coefficient; Obtain the real-time operating status data of the underlying distributed server cluster and calculate the dynamic adaptive threshold using the following formula: in, The dynamic adaptive threshold represents the current time step t; The baseline trigger threshold; As a penalty regulator; and These represent the real-time memory usage and the average CPU load rate at the current time step t, respectively. and These represent the total memory capacity and the total number of processor cores, respectively. When the correlation impact index of the affected node is continuously greater than or equal to the dynamic adaptive threshold within a preset sliding time window, it is determined that the linkage triggering condition is met, and a data frame containing underlying call parameters is generated and sent to the message queue inside the system as the cross-scene linkage instruction.

8. The multi-scenario intelligent transaction and data linkage processing system driven by the city transaction brain according to claim 1, characterized in that, In the multi-scenario linkage execution layer, the composite smart contract generation module specifically includes: The data frames of the cross-scenario linkage instructions are deserialized and parsed to extract the source node identifier, affected node identifier, and concurrent computing resource demand increment of the core transaction event; Based on the extracted source node identifier and affected node identifier, the matching cross-domain contract template containing the cross-chain call interface is invoked from the underlying contract repository; The transaction request corresponding to the core transaction event is hardcoded into the main transaction execution function of the cross-domain contract template, and the resource allocation request corresponding to the concurrent computing resource demand increment is hardcoded into the resource reservation function of the cross-domain contract template to generate the composite smart contract.

9. The multi-scenario intelligent transaction and data linkage processing system driven by the city transaction brain according to claim 8, characterized in that, In the multi-scenario linkage execution layer, the distributed transaction coordination module employs a two-phase cross-chain commit mechanism to execute the composite smart contract in parallel, including a preparation phase and an execution phase; the preparation phase specifically includes: The distributed transaction coordination module, acting as a transaction coordinator, broadcasts a pre-commit instruction to the underlying subsystem nodes corresponding to the first and second scenarios participating in the composite smart contract. Each of the underlying subsystem nodes pre-executes the logic of the composite smart contract locally, and determines the corresponding underlying data rows and computing resources based on the incremental concurrent computing resource requirements, while keeping the underlying final ledger state unchanged. If the underlying subsystem node successfully performs local pre-execution and acquires the lock, it returns a ready response to the transaction coordinator; if pre-execution fails or resource locking fails, it returns an abort response.

10. The multi-scenario intelligent transaction and data linkage processing system driven by the city transaction brain according to claim 9, characterized in that, The execution phase specifically includes: If the transaction coordinator collects the ready responses from all the underlying subsystem nodes participating in the composite smart contract within the preset timeout period, it broadcasts a global commit instruction to the entire network to trigger each underlying subsystem node to persist the pre-committed data changes to the underlying ledger and release resource locks, thereby completing the underlying data state update. If the transaction coordinator receives an abort response from any of the underlying subsystem nodes, or fails to collect all the ready responses within the preset timeout period, it broadcasts a global rollback instruction to the entire network to trigger each of the underlying subsystem nodes to revoke the resource locking and caching operations of the preparation phase, so that the underlying data state is rolled back to the initial state before the core transaction event occurred.

Images