An ultrasonic data verification method and system based on federated learning and blockchain

Abstract

The application provides an ultrasonic data verification method and system based on federated learning and a blockchain. The method comprises: each participant locally maintaining a blockchain based on a directed acyclic graph structure to record model transactions generated in the training process; each participant uses local private ultrasonic data to perform local training to obtain an updated local model based on at least one existing model obtained from the locally maintained blockchain; every preset training period, all participants pause local training and enter a consensus phase; in the consensus phase, each participant verifies and evaluates the performance of all models published to the blockchain in the current period based on private verification data, and generates a model ranking; the highest ranked model is selected as the reference model for the next training period, and each participant continues the next round of asynchronous local training based on the reference model; iteration is performed until a preset training termination condition is met, and finally a global model is output as the collaborative training result.

Description

Technical Field

[0001] This application relates to the field of medical data training technology, and in particular to an ultrasound data verification method and system based on federated learning and blockchain. Background Technology

[0002] With the rapid development of ultrasound imaging technology and artificial intelligence algorithms in the field of medical diagnosis, intelligent analysis and assisted diagnosis based on ultrasound data have become important technical means to improve the efficiency and accuracy of clinical diagnosis and treatment. Ultrasound data has the characteristics of low acquisition cost, wide application scenarios, and multimodal collaboration, but its diagnostic performance is highly dependent on large-scale and diverse data support. Due to medical data privacy protection regulations and data barriers between institutions, ultrasound data has long been stored in different medical institutions in a scattered manner, making it difficult to achieve centralized sharing and unified modeling, forming a typical data silo problem.

[0003] Federated learning, as a distributed learning paradigm that enables multi-party collaborative modeling without sharing raw data, provides a new technical approach for collaborative training of ultrasound data across institutions. However, in practical applications, ultrasound data sources are complex and vary significantly in quality, and the model training and update process involves multiple stakeholders. How to effectively verify, trace, and reliably manage the models uploaded or generated by participating parties while ensuring data privacy has become a key issue restricting the practical application of federated learning in ultrasound medical scenarios. Summary of the Invention

[0004] In view of this, it is necessary to provide an ultrasonic data verification method and system based on federated learning and blockchain, which can at least overcome one of the above-mentioned defects.

[0005] In a first aspect, embodiments of this application provide an ultrasound data verification method based on federated learning and blockchain, applied to collaborative model training and verification among multiple participants. The method includes:

[0006] Each participating party maintains a blockchain based on a directed acyclic graph structure locally to record model transactions generated during the training process; wherein each model transaction includes at least model parameters, publisher identifier, timestamp, and reference information pointing to previous transactions;

[0007] Each of the aforementioned participants obtains at least one existing model from the locally maintained blockchain, performs local training using local private ultrasound data to obtain an updated local model, and constructs the updated local model as a new model transaction to publish to the blockchain.

[0008] Every preset training cycle, all participating parties pause their local training and enter the consensus phase;

[0009] During the consensus phase, each participating party verifies and evaluates the performance of all models published to the blockchain within the current period based on its own private verification data, and generates a model ranking.

[0010] Based on the model ranking generated in the consensus phase, the model with the highest ranking is selected as the benchmark model for the next training cycle, and each participant continues to conduct the next round of asynchronous local training based on the benchmark model.

[0011] The process iterates until the preset training termination condition is met, and finally outputs the global model confirmed by the consensus of all participating parties as the collaborative training result.

[0012] In one embodiment, each of the model transactions further includes: at least one parent transaction hash, round identifier, model number, available modal metadata of the publisher, model verification digest, and digital signature;

[0013] The blockchain uses the initial model transaction as the root node, and each newly published model transaction after the initial model references at least one previous model transaction as the parent node, thus forming a model evolution graph.

[0014] In one embodiment, each of the participating parties obtains at least one existing model from the locally maintained blockchain and performs local training using local private ultrasound data, including:

[0015] From the local blockchain, unverified or recent transactions that meet the preset freshness constraints are selected first. At the same time, a roulette-style random sampling strategy based on score metric is adopted to construct a candidate model set that combines timeliness and diversity.

[0016] Local validation screening: Using local private validation data, the models in the candidate model set are evaluated for performance, and models whose evaluation results are lower than a preset accuracy threshold or are judged to be abnormal are removed to obtain the validation model set.

[0017] Starting model generation: Based on the set of validation models and the available data modalities, one or more of the following methods are used to generate the starting model for this round of asynchronous training: model integration, parameter fusion, or knowledge distillation.

[0018] In one embodiment, the consensus phase includes a periodic consensus message phase, a preparation phase, and a voting phase:

[0019] During the periodic consensus message phase, the leader of the current round initiates a consensus request and broadcasts a periodic consensus message that includes the ranking information of the candidate models in this round calculated by the leader.

[0020] During the preparation phase, each participating party verifies the validity of the periodic consensus message. After successful verification, asynchronous training is paused and a preparation message is broadcast to other participating parties.

[0021] During the voting phase, each participating party generates and broadcasts an in-modal ranking for all candidate models published within the current period based on its available data modalities, using its local private verification data.

[0022] After the leader collects the intramodal rankings of all participants, it performs weighted fusion based on the pre-announced proportion of data volume to generate a global model ranking and writes it into the phase consensus result.

[0023] If the global model ranking is not accepted by the majority of participants, a leader replacement mechanism is triggered.

[0024] In one embodiment, after the iteration continues until a preset training termination condition is met, the process further includes:

[0025] In the final round, the leader calculates the contribution and reward distribution of each participant based on the consensus results of each round, and constructs a final transaction including a final model summary, reward distribution details, and consensus round records.

[0026] Each of the aforementioned parties verifies the correctness of the final transaction and attaches a digital signature to the final transaction;

[0027] After receiving a preset number of digital signatures, the leader combines the digital signatures with the final transaction to construct a completed transaction and publishes it to the blockchain.

[0028] In one embodiment, the leader replacement mechanism includes:

[0029] When more than a preset proportion of the participants raise objections to the global model ranking, the current leader is marked as invalid.

[0030] Candidate participants will be selected as new leaders in descending order of their ranking from the previous consensus.

[0031] If the previous consensus ranking does not exist, the new leader will be determined through a proof-of-stake mechanism.

[0032] The newly appointed leader restarts the consensus process until a ranking result is generated that is accepted by the majority of participants.

[0033] In one embodiment, when the private ultrasound data of the participating party contains multiple imaging modalities, the step of generating the model ranking further includes:

[0034] Each participant first calculates the performance metrics for different candidate models on each available data modality based on their local private validation data;

[0035] Each participating party will submit the calculated modal performance indicators during the consensus phase;

[0036] By using preset fusion rules, the performance evaluation results from different participants targeting different modalities are integrated to form a unified global model ranking.

[0037] In one embodiment, the preset fusion rule includes:

[0038] The data modalities are weighted and merged based on their proportion of the total publicly declared data among all participating parties.

[0039] In one embodiment, the method further includes:

[0040] The triggering conditions for the consensus phase are adjusted based on at least one of the following: model performance convergence, differences in training progress among participants, or network load.

[0041] Secondly, embodiments of this application provide an ultrasound data verification system based on federated learning and blockchain, applied to implement the ultrasound data verification method based on federated learning and blockchain as described in the first aspect, the system comprising:

[0042] The local training module includes multiple participants, each of whom maintains a blockchain based on a directed acyclic graph structure locally to record model transactions generated during training. Each model transaction includes at least model parameters, a publisher identifier, a timestamp, and reference information pointing to previous transactions. Each participant obtains at least one existing model from the locally maintained blockchain, performs local training using local private ultrasound data to obtain an updated local model, and publishes the updated local model as a new model transaction to the blockchain.

[0043] A consensus generation module is used to pause local training and enter the consensus phase at each preset training cycle. In the consensus phase, each participant verifies and evaluates the performance of all models published to the blockchain in the current cycle based on their own private verification data, and generates a model ranking. Based on the model ranking generated in the consensus phase, the model with the highest ranking is selected as the benchmark model for the next training cycle, and each participant continues to conduct the next round of asynchronous local training based on the benchmark model.

[0044] The result output module is used to output the global model, which has been confirmed by the consensus of all the participating parties, as the collaborative training result when the preset training termination condition is met during iteration.

[0045] This application provides a method and system for ultrasound data verification based on federated learning and blockchain. By combining a federated learning framework with a DAG blockchain, multiple medical institutions can securely and reliably conduct collaborative model training without sharing original sensitive data, fundamentally protecting patient privacy and data security. Secondly, a hybrid mechanism combining asynchronous local training and periodic synchronous consensus is employed. This avoids equipment waiting and resource waste in fully synchronous solutions, improving training efficiency, and effectively ensures the convergence speed and final performance of the global model through phased model selection and consensus calibration. Furthermore, addressing the common problem of heterogeneous multimodal ultrasound data in medical scenarios, this method designs a multimodal ranking fusion mechanism based on data volume weighting, ensuring fair representation of the contributions of different data modalities and improving the model's generalization ability and diagnostic robustness. Finally, relying on the immutable and traceable characteristics of blockchain, all training processes, model versions, and consensus results are fully recorded, enhancing the system's transparency and credibility, and providing a reliable technical foundation for subsequent model auditing, accountability, and compliance verification. Attached Figure Description

[0046] Figure 1 This is a schematic diagram of an ultrasonic data verification method based on federated learning and blockchain, provided in one embodiment of this application.

[0047] Figure 2 This is a diagram of the algorithm training architecture provided in one embodiment of this application.

[0048] Figure 3 This is a verification schematic diagram provided in one embodiment of this application.

[0049] Figure 4 This is a schematic diagram of model accuracy voting provided in one embodiment of this application.

[0050] Figure 5 This is a schematic diagram of an ultrasonic data verification system module based on federated learning and blockchain provided in one embodiment of this application.

[0051] Figure 6 A schematic diagram of an electronic device provided in one embodiment of this application.

[0052] Explanation of main component symbols

[0053] An Ultrasonic Data Validation System Based on Federated Learning and Blockchain 10 Local training module 11 Consensus generation module 12 Result Output Module 13 electronic devices 20 processor 21 memory 22 Methods and Steps S100-S600 Detailed Implementation

[0054] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them.

[0055] It should be noted that, in the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in the specification of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application.

[0056] It should be noted that in the embodiments of this application, the terms "first," "second," etc., are used only for descriptive purposes and should not be construed as indicating or implying relative importance, nor as indicating or implying order. Features specified as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0057] Based on the embodiments described in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0058] With the rapid development of ultrasound imaging technology and artificial intelligence algorithms in the field of medical diagnosis, intelligent analysis and assisted diagnosis based on ultrasound data have become important technical means to improve the efficiency and accuracy of clinical diagnosis and treatment. Ultrasound data has the characteristics of low acquisition cost, wide application scenarios, and multimodal collaboration, but its diagnostic performance is highly dependent on large-scale and diverse data support. Due to medical data privacy protection regulations and data barriers between institutions, ultrasound data has long been stored in different medical institutions in a scattered manner, making it difficult to achieve centralized sharing and unified modeling, forming a typical data silo problem.

[0059] Federated learning, as a distributed learning paradigm that enables multi-party collaborative modeling without sharing raw data, provides a new technical approach for collaborative training of ultrasound data across institutions. However, in practical applications, ultrasound data sources are complex and vary significantly in quality, and the model training and update process involves multiple stakeholders. How to effectively verify, trace, and reliably manage the models uploaded or generated by participating parties while ensuring data privacy has become a key issue restricting the practical application of federated learning in ultrasound medical scenarios.

[0060] Therefore, this application provides a method and system for ultrasound data verification based on federated learning and blockchain. By combining the federated learning framework with DAG blockchain, multiple medical institutions can safely and reliably conduct collaborative model training without sharing original sensitive data, fundamentally protecting patient privacy and data security. Secondly, a hybrid mechanism combining asynchronous local training and periodic synchronous consensus is adopted. This avoids equipment waiting and resource waste in fully synchronous schemes, improving training efficiency, and effectively ensures the convergence speed and final performance of the global model through phased model selection and consensus calibration. Furthermore, addressing the common problem of heterogeneous multimodal ultrasound data in medical scenarios, this method designs a multimodal ranking fusion mechanism based on data volume weighting, ensuring fair representation of the contributions of different data modalities and improving the model's generalization ability and diagnostic robustness. Finally, relying on the immutable and traceable characteristics of blockchain, all training processes, model versions, and consensus results are fully recorded, enhancing the system's transparency and credibility, and providing a reliable technical foundation for subsequent model auditing, accountability, and compliance verification.

[0061] The following detailed description of some embodiments of the application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0062] Figure 1 This is a schematic diagram of an ultrasound data verification method based on federated learning and blockchain, provided in one embodiment of this application. Figure 1 The ultrasonic data verification method based on federated learning and blockchain, as shown, includes at least the following steps: S100: Each participant maintains a blockchain based on a directed acyclic graph structure locally to record model transactions generated during training; S200: Each participant obtains at least one existing model from the locally maintained blockchain, performs local training using local private ultrasonic data, obtains an updated local model, and publishes the updated local model as a new model transaction to the blockchain; S300: Every preset training cycle, all participants pause local training and enter the consensus phase; S400: In the consensus phase, each participant verifies and evaluates the performance of all models published to the blockchain in the current cycle based on their own private verification data, and generates a model ranking; S500: Based on the model ranking generated in the consensus phase, the model with the highest ranking is selected as the benchmark model for the next training cycle, and each participant continues to perform the next round of asynchronous local training based on the benchmark model; S600: Iterate until the preset training termination condition is met, and finally output the global model confirmed by the consensus of all participants as the collaborative training result.

[0063] S100: Each participant maintains a blockchain based on a directed acyclic graph structure locally to record model transactions generated during the training process.

[0064] In this embodiment of the application, the ultrasonic data verification method based on federated learning and blockchain includes step S100, in which each participant maintains a blockchain based on a directed acyclic graph structure locally to record model transactions generated during training. Each model transaction includes at least model parameters, a publisher identifier, a timestamp, and reference information pointing to previous transactions.

[0065] Specifically, participants deploy and maintain a lightweight blockchain ledger based on a Directed Acyclic Graph (DAG) structure locally. This ledger uses the initial model transaction as its root node, and each subsequent locally trained model is published as a transaction, containing at least: model parameters or a model summary, a publisher identifier (participant ID), a timestamp, a round identifier, a model number, a set of parent hashes pointing to one or more parent transactions, available modal metadata of the publisher (e.g., modal types and sample sizes such as ultrasound, color Doppler, and contrast imaging), a local verification summary or performance metric summary, and a digital signature field to ensure transaction integrity and authenticity. Participants exchange transaction metadata and synchronize tips information (i.e., transactions that have not been fully verified or referenced) through a P2P network to support subsequent model selection and traceability auditing. The blockchain layer can also configure transaction format constraints, signature verification rules, and digest algorithms (e.g., SHA256 + asymmetric signature) to ensure the immutability and traceability of on-chain records.

[0066] Understandably, adopting a DAG design instead of a traditional linear chain is beneficial for supporting the parallel release of model transactions by multiple participants, reducing on-chain confirmation latency, and improving throughput. At the same time, recording modal metadata and verification summaries in transactions can provide necessary metadata support for subsequent modal self-adaptation, ranking aggregation, and auditing, thus balancing efficiency and auditability.

[0067] S200: Each participant obtains at least one existing model from the locally maintained blockchain, performs local training using local private ultrasound data, obtains an updated local model, and constructs the updated local model into a new model transaction and publishes it to the blockchain.

[0068] In this embodiment of the application, the ultrasound data verification method based on federated learning and blockchain includes step S200, in which each participant obtains at least one existing model from the locally maintained blockchain, performs local training using local private ultrasound data, obtains an updated local model, and constructs the updated local model as a new model transaction and publishes it to the blockchain.

[0069] Specifically, at the start of each training round, participants read several candidate model transactions from their local DAG that meet preset screening criteria (e.g., freshness, model source credibility, initial validation scores, etc.). These transactions are selected primarily from tips or recent transactions, and diversity can be introduced through score metrics and roulette wheel betting. The candidate models are quickly evaluated on a local private validation set, and obviously low-quality or anomalous models are eliminated. Subsequently, based on the selected set of validated models, one or more methods are used to generate the starting model for this round—including but not limited to model ensemble (weighted averaging), parameter fusion (hierarchical parameter merging), knowledge distillation (teacher → student), or transfer learning (freezing the underlying representation and fine-tuning the higher layers). After generating the starting model, participants perform asynchronous local training using their private training data (hyperparameters such as the number of local iterations, learning rate scheduling, and early stopping strategies can be set). After training, a model transaction containing the aforementioned transaction fields is constructed, and after signing the key fields, it is published to the local DAG. The transaction summary or tip notification is then broadcast to other nodes via P2P communication to achieve on-chain propagation.

[0070] Understandably, performing rapid local validation of candidate models and generating a starting model through fusion / distillation can improve the quality and convergence speed of the local training starting point. At the same time, recording validation summaries and source information in transactions helps to audit the traceability of model sources and evolution paths in the future, and provides a chain of evidence for model evaluation in the consensus phase.

[0071] S300: Every preset training cycle, all participants pause local training and enter the consensus phase.

[0072] In this embodiment of the application, the ultrasonic data verification method based on federated learning and blockchain includes step S300, in which all participants pause local training and enter the consensus phase every preset training cycle.

[0073] Specifically, a periodic consensus process is triggered every pre-defined time window or upon reaching a certain iteration threshold (e.g., every N local updates or every T minutes / hour). Upon triggering, the current round's leader (selected based on the previous round's consensus ranking, random election, or predefined rules) broadcasts a periodic consensus message (PCM), containing the current round's view number, a summary of the candidate model list, and its own calculated candidate ranking information. Participants receiving the PCM, after verifying its validity, pause their local training and enter a preparation phase, completing a local state snapshot and necessary local cache write-back to ensure no critical model updates are lost during the pause. Participants who have completed preparation and passed verification return a preparation message to the network, awaiting entry into the voting phase. The consensus phase has explicit timeout and exception handling mechanisms to prevent a few node failures from blocking global progress.

[0074] Understandably, periodically pausing and entering the consensus phase does not involve global synchronous training every time. Instead, it compromises the efficiency of asynchronous training with the requirement for global consistency in a phased and periodic manner. This reduces the waste of computing power caused by waiting and corrects the drift and inconsistency problems that may be caused by asynchronous training through phased synchronization.

[0075] S400: During the consensus phase, each participant verifies and evaluates the performance of all models published to the blockchain within the current period based on their own private verification data, and generates a model ranking.

[0076] In this embodiment of the application, the ultrasonic data verification method based on federated learning and blockchain includes the following steps in step S400: During the consensus phase, each participant verifies and evaluates the performance of all models published to the blockchain in the current period based on their own private verification data, and generates a model ranking.

[0077] Specifically, during the voting (verification) phase, each participant will calculate performance metrics (e.g., AUC, precision, recall, F1 score, confidence distribution, etc.) for each modality of the models published and included in the candidate set within the current cycle, based on their local private validation set. This generates an in-modality ranking for each candidate model within that modality. When a participant lacks a particular modality, they only validate their available modalities and generate a ranking for that modality. Participants broadcast their in-modality rankings to the network using signatures. The leader aggregates all in-modality rankings submitted by participants, employing a pre-published modality weighting strategy (e.g., weighting based on the proportion of data disclosed in S100 for each modality, or reweighting based on data quality metrics), and may combine robust aggregation algorithms (e.g., Trimmed Mean, Krum, or median-based aggregation) to resist anomalous or malicious rankings, ultimately calculating a global model ranking. This global ranking is written into the phase consensus result and uploaded to the blockchain as the decision-making basis for this phase. If a majority of participants disagree with the aggregation result submitted by the leader, the leader is replaced and the ranking aggregation is re-executed.

[0078] Understandably, by first sorting within a modality and then merging it into a global ranking based on modality weights, the system takes into account the differences in the impact of multimodal heterogeneous data on model performance; at the same time, the use of robust aggregation and signature verification can improve the fault tolerance and credibility against malicious updates or abnormal evaluations.

[0079] S500: Based on the model ranking generated in the consensus phase, the model with the highest ranking is selected as the benchmark model for the next training cycle, and each participant continues to conduct the next round of asynchronous local training based on the benchmark model.

[0080] In this embodiment of the application, the ultrasonic data verification method based on federated learning and blockchain includes step S500, which involves selecting the model with the highest ranking as the benchmark model for the next training cycle based on the model ranking generated in the consensus phase, and each participant continuing to conduct the next round of asynchronous local training based on the benchmark model.

[0081] Specifically, in the global model ranking determined by the consensus phase, the complete transaction of the top-ranked model (or its summary plus the authorized path to obtain model parameters) is identified as the baseline model for this round. After receiving and verifying the consensus result, each participant uses this baseline model as the starting point for the next round of asynchronous training. Participants can directly continue local fine-tuning on this model, perform local training based on shared representations, or fuse / distill it with the local best model to generate a training starting point more suitable for their local modality. Simultaneously, the publisher of the highest-ranked model can be designated as the leader for the next round to initiate the next round of PCM. The selection and replacement of the leader role follows preset rules (e.g., based on ranking, historical contribution, or staking mechanisms) and is accompanied by incentive / penalty constraints to prevent malicious behavior. The next round of training begins asynchronously immediately after resolving any anomalies recorded during the consensus phase (e.g., removing models deemed anomalous).

[0082] Understandably, using the optimal model selected by consensus as the starting point for the next round can accelerate global convergence and improve model quality; directly binding leaders to contributions and combining it with reward / penalty mechanisms helps incentivize participants to provide high-quality models and maintain system integrity.

[0083] S600: Iterate until the preset training termination condition is met, and finally output the global model confirmed by the consensus of all participants as the collaborative training result.

[0084] In this embodiment of the application, the ultrasonic data verification method based on federated learning and blockchain includes step S600, which iterates until a preset training termination condition is met, and finally outputs a global model confirmed by consensus among all participants as a collaborative training result.

[0085] Specifically, the system can stop iteration and enter the final confirmation stage based on one or more preset termination conditions. These conditions include, but are not limited to: reaching the preset maximum number of training rounds, the global model's performance gain falling below a threshold during phase verification (e.g., gain < ϵ for k consecutive phases), training resources or time reaching their limits, or participants reaching a consensus on the final model. Upon termination, the final leader calculates and generates a final transaction based on the overall phase consensus results, including a final model summary (or model retrieval / download authorization information), proof of contribution and reward distribution details for each participant, and a complete set of phase consensus records and signatures. All participants verify and sign the final transaction. After meeting the predetermined signature threshold, the leader uploads the completed transaction to the blockchain as proof of the end of this federated learning process; simultaneously, it can trigger on-chain or off-chain reward distribution, audit export, and model deployment processes. This final on-chain transaction provides an immutable chain of evidence for subsequent audits, compliance checks, and result traceability.

[0086] Understandably, clear termination conditions and final transaction completion mechanisms not only ensure the controllability and auditability of the training process, but also provide on-chain evidence for reward distribution and accountability, thereby improving the acceptability and compliance of multi-institutional collaborative training in real-world medical scenarios.

[0087] In this embodiment, each model transaction further includes: at least one parent transaction hash, round identifier, model number, available modal metadata of the publisher, model verification digest, and digital signature. The blockchain uses the initial model transaction as the root node, and each newly published model transaction after the initial model references at least one previous model transaction as its parent node, thus forming a model evolution graph.

[0088] Specifically, model transactions are represented using a structured field serialization format (e.g., JSON / Protobuf). The parent transaction hash field stores the hash values ​​of one or more parent transactions to establish a reference relationship. The round identifier indicates the asynchronous training phase or view number to which the model belongs. The model number distinguishes multiple updates from the same participant within the same round. Available modal metadata includes a modality type identifier, the number of samples on that modality, and data quality estimates. The model validation summary is a summary of several performance metrics calculated on the local validation set (e.g., summary statistics of accuracy, AUC, or F1) or a model fingerprint. Digital signatures use a public-private key signing mechanism to sign key fields to ensure the transaction's origin is unforgeable and non-repudiable. In the local chain, the initial model transaction is the root node, and subsequent newly published transactions reference at least one parent transaction, thus forming a model evolution graph. Simultaneously, indexes and retrieval fields are maintained on-chain to support retrieving historical models by modality, publisher, or time window.

[0089] Understandably, by recording the parent hash, modal meta information, and verification digest in each transaction, the evolution path and source evidence of the model can be fully displayed, which facilitates subsequent model selection, source tracing audit, and accountability. The signature and digest mechanism can prevent transaction forgery and improve the credibility of on-chain records. The DAG structure can support parallel updates by multiple participants, improving on-chain throughput and availability.

[0090] In this embodiment, each participant obtains at least one existing model from its locally maintained blockchain and performs local training using local private ultrasound data. This includes: prioritizing the selection of unverified or recent transactions that meet a preset freshness constraint from the local blockchain, while employing a roulette-style random sampling strategy based on a score metric to construct a candidate model set that combines timeliness and diversity. Local validation screening: using local private validation data, the models in the candidate model set are evaluated for performance, and models with evaluation results below a preset accuracy threshold or deemed abnormal are eliminated to obtain a validation model set. Starting model generation: based on the validation model set and its own available data modalities, one or more methods, such as model ensemble, parameter fusion, or knowledge distillation, are used to generate a starting model for the current round of asynchronous training.

[0091] Specifically, participants construct a candidate model set from their local DAG according to a preset strategy: first, they filter out recently generated tips or transactions that meet the time window based on a freshness strategy; second, they calculate a score for each transaction in the candidate set. The process involves introducing diversity through roulette-style random sampling based on scores. For the sampled candidate models, participants calculate performance metrics for each modality on their local private validation set and perform anomaly detection (e.g., anomaly determination based on confidence intervals or isolated forests), eliminating models below a preset accuracy threshold or those deemed anomalous. For the remaining validation model set, participants choose an appropriate starting point generation method based on available local modalities and resource constraints: weighted ensemble (assigning weights based on validation scores / data volume), hierarchical parameter fusion (merging general and task layers separately), or knowledge distillation to distill a lightweight student model from multiple high-quality models. The generated starting point model simultaneously records its source transaction set and fusion strategy summary, which serves as the initial weight for this round of local training.

[0092] Understandably, the above screening and generation process takes into account both the freshness and diversity of models, which helps to prevent outdated or single-source models from dominating training. At the same time, it improves the system's robustness to low-quality or malicious updates through local validation and anomaly detection. The use of multiple starting point generation techniques can adapt to the heterogeneity of participants in terms of modality and computing power, thereby improving local convergence speed and global performance.

[0093] In this embodiment, the consensus phase includes a periodic consensus message phase, a preparation phase, and a voting phase. In the periodic consensus message phase, the leader of the current round initiates a consensus request and broadcasts a periodic consensus message containing the ranking information of candidate models for this round, calculated by the leader. In the preparation phase, each participant verifies the validity of the periodic consensus message; upon successful verification, asynchronous training is paused, and a preparation message is broadcast to other participants. In the voting phase, each participant, based on its local private verification data, generates and broadcasts an in-modal ranking for all candidate models published within the current period, according to their available data modalities. After collecting the in-modal rankings from all participants, the leader performs a weighted fusion based on a pre-announced data volume ratio to generate a global model ranking and writes it into the phase consensus result. If the global model ranking is not accepted by a majority of participants, a leader replacement mechanism is triggered.

[0094] Specifically, the Periodic Consensus Message (PCM) includes a leader view ID, a summary of the candidate model set (a list of transaction hashes), a preliminary leader candidate ranking, a timestamp, and a signature. During the preparation phase, participants first verify the signature and the legitimacy of the candidate list in the PCM. If the verification passes, they take a training snapshot locally and broadcast a preparation message (and sign it). The preparation message includes the participant's available modal declarations and metadata about the local verification summary for subsequent verification. During the voting phase, each participant calculates performance metrics for each candidate model modally based on its private verification set and generates an intra-modal ranking. The intra-modal ranking and corresponding metrics are broadcast via signed messages to ensure non-repudiation. After collecting a sufficient number of intra-modal rankings, the leader weights and fuses the results of each modality according to pre-published weighting rules (e.g., weights normalized by modal sample size or data quality score). If necessary, robust aggregation methods (such as Trimmed Mean, Krum, or median-based strategies) are used to suppress aberrant submissions. Finally, a global model ranking is generated, and the ranking and aggregation evidence are written into the phase consensus result and signed onto the blockchain. The consensus process sets timeout and minimum admission vote (quorum) thresholds to ensure progress even when there is network jitter or a few nodes are unreachable; if a majority of participants object to the leader's aggregation result, a recalculation is triggered according to the leader replacement mechanism.

[0095] Understandably, clarifying the three phases of PCM / preparation / voting and standardizing message signing, timeout, and quorum not only ensures the legitimacy and verifiability of the consensus result, but also provides a clear path for error correction and replacement in case of disputes, thereby achieving a balance between efficiency and security.

[0096] In this embodiment, after iterating until a preset training termination condition is met, the process further includes: the leader of the final round calculates the contribution and reward distribution of each participant based on the consensus results of each round, and constructs a final transaction including a final model summary, reward distribution details, and consensus round records. Each participant verifies the correctness of the final transaction and attaches a digital signature to it. After receiving a preset number of digital signatures, the leader combines the digital signatures with the final transaction to construct a completed transaction and publishes it to the blockchain.

[0097] Specifically, the global model ranking written in the phase consensus is identified by transaction hashes, with the top-ranked model transaction designated as the benchmark model for this round. After verifying the signature and aggregation evidence of the consensus record, participants can obtain the complete parameters of the benchmark model or download authorization through on-chain indexing or peer-to-peer retrieval (if the model parameters are stored off-chain, a trusted retrieval certificate is attached). Participants can choose to fine-tune the benchmark model directly or merge the benchmark model with their local best model according to a preset fusion strategy to create a more suitable starting point for their local modality before continuing asynchronous training. The top-ranked model publisher can be designated as the leader for the next round, or the leader can be replaced according to predetermined rotation / staking rules to reduce the risk of single-point power. If the leader role is linked to rewards, the incentive parameters will be adjusted based on the contribution of the previous round before the start of the next round.

[0098] Understandably, using the model ranked first in consensus as the starting point for the next round helps to promote the solution deemed optimal by the collective evaluation to all participants, thereby improving the overall convergence rate; dynamic management and incentive design for the role of leaders can effectively suppress fraud and encourage positive contributions.

[0099] After the termination conditions are met, the final round leader calculates the participants' contributions based on the consensus results of each stage. Contributions are calculated using a weighted formula, taking into account factors such as the number of times the model was selected as the benchmark in each round, its positive contribution to the global ranking (e.g., increased validation scores), and the amount of data reported by the participants. Rewards are allocated from a pre-set reward pool based on contribution percentages, while also considering a penalty factor (deducting a corresponding share from participants deemed malicious or abnormal). The final transaction includes: a final model summary (hash / version number), details of contribution and reward allocation, consensus records from all stages, and a set of signatures from each participant for the final transaction. Participants verify and sign the final transaction (using threshold signatures or m-of-n signature schemes). Once the leader collects a predetermined threshold number of signatures, the transaction is uploaded to the blockchain, triggering the reward distribution mechanism (on-chain or off-chain). The completed transaction serves as an immutable record of the federated learning process and can be used for subsequent auditing and compliance checks.

[0100] Understandably, linking contribution and reward distribution to the final on-chain transaction creates a transparent and traceable incentive loop to promote honest participation, while reducing the incentive to act maliciously and enhancing system credibility through signature thresholds and penalty mechanisms.

[0101] In this embodiment, the leader replacement mechanism includes: when more than a preset proportion of participants object to the global model ranking, the current leader is marked as invalid. Candidate participants are selected as new leaders in descending order of the previous consensus ranking. If no previous consensus ranking exists, a new leader is determined through a proof-of-stake mechanism. The new leader re-initiates the consensus process until a ranking result accepted by a majority of participants is generated.

[0102] Specifically, when more than a preset proportion of participants (e.g., more than half or a pre-agreed objection threshold) raise objections to the global ranking generated by the leader through signatures or votes, the system will mark the current leader as invalid and freeze its subsequent PCM initiation privileges. Subsequently, it will attempt to nominate the next highest-ranked participant as a candidate leader and have them initiate a new consensus process, following the previous round's consensus ranking from highest to lowest. If the previous ranking is unavailable or challenged, it will switch to a Stake-based or random lottery mechanism to select a new leader. The replaced leader may be subject to penalties such as temporary bans, staking penalties, or trust score downgrades to deter malicious behavior. The new leader must complete the re-initiated PCM within the specified timeout period; otherwise, the next candidate will be selected sequentially.

[0103] In this embodiment, a proof-of-stake mechanism is used to determine a leader when there is a lack of effective model ranking or when consensus rollback occurs. The proof-of-stake mechanism uses the stake value held by each participant in the system as a weight, and this stake value is related to at least one of the following: the participant's historical model contribution, data sample size, number of available data modalities, or credibility of historical consensus behavior. The system selects a new leader proportionally or through a weighted random method based on the stake values ​​of each participant to ensure a fair and stable consensus process even without explicit performance priorities.

[0104] Understandably, this replacement mechanism, by using historical rankings as a priority list and supplementing it with a stake / random rollback strategy, enables rapid, explainable, and binding leadership replacement when challenges arise, ensuring both the continuity of consensus and constraining the behavior of leaders.

[0105] In this embodiment, when a participant's private ultrasound data contains multiple imaging modalities, and a model ranking is generated, the process further includes: each participant first calculating performance metrics for different candidate models on each available data modality based on their local private validation data. Each participant then submits the calculated performance metrics for each modality during the consensus phase. Through preset fusion rules, the performance evaluation results from different participants for different modalities are integrated to form a unified global model ranking.

[0106] Specifically, during the voting phase, participants with multimodal capabilities calculate and submit performance metrics (e.g., AUC, sensitivity, specificity, etc. for each modality) for each candidate model across all available modalities. They also normalize the results within each modality for cross-participant comparisons (e.g., mapping scores to [0,1] or normalizing them to a participant's local baseline). If a participant lacks a modality, they do not submit a ranking or submit a null value for that modality; during aggregation, the weight of that modality is determined solely by the contributions of participants possessing that modality. All modal performance and ranking are submitted in the form of signatures and stored on-chain or used as evidence of phase consensus. Finally, the global ranking is formed by merging the modality-level rankings of each modality according to their weights (see fusion rules below).

[0107] Understandably, evaluating different modalities separately and preserving the differences between modalities during fusion can avoid the influence of bias from a single modality or a single participant on the overall judgment, and ensure the comprehensiveness and fairness of the evaluation in a multimodal environment.

[0108] In this embodiment of the application, the preset fusion rules include: weighted fusion based on the proportion of the total amount of data publicly declared by each data modality among all participants.

[0109] Specifically, the default fusion rule calculates modality weights based on the publicly declared percentage of each data modality's total sample size across all participants: Weight = (Total number of samples for this modality / Total number of samples for all modalities) normalized value. To ensure data quality, a quality factor can be introduced into the weight calculation (e.g., adjusting weights based on the average performance or noise metrics of each modality on the validation set) to obtain the final fusion weights, which are then used for modality-level ranking weighted averaging. The fusion rule supports both static (fixed) and dynamic (real-time adjustment based on stage evaluation) modes, and allows configuring thresholds and smoothing factors in the system parameters to prevent drastic weight fluctuations caused by single-round anomalies.

[0110] Understandably, using the publicly declared data volume percentage as the basis for weights can reflect the representativeness of each modality in the overall training samples, and combining it with data quality correction can further improve the reliability of the fusion results; supporting dynamic adjustment enables the system to adapt the weight allocation as data distribution and model performance change.

[0111] In this embodiment of the application, the method further includes: adjusting the triggering conditions of the consensus phase based on at least one of the following: model performance convergence, differences in training progress among participants, or network load.

[0112] Specifically, the system dynamically adjusts the consensus phase triggering conditions by monitoring several operational metrics (such as the global model performance gain curve, the difference in local training progress among participants, network bandwidth / latency, and on-chain transaction congestion). When global performance converges rapidly and the training progress among participants tends to be consistent, the consensus triggering interval can be appropriately extended to reduce synchronization overhead. When the heterogeneity or performance fluctuations among participants are large, or the network load is low and the stability benefits brought by consensus are high, the triggering interval can be shortened to improve global consistency. The adjustment range is constrained by preset upper and lower limits to ensure system stability (e.g., the triggering interval must not be lower than a certain threshold). or higher Furthermore, the system supports immediate triggering based on anomaly detection: if any participant submits an abnormal score or significant concept drift is detected, a compensatory consensus can be immediately triggered to correct the direction. All adjustments and their rationale will be written to the on-chain log for auditing.

[0113] Understandably, by adaptively adjusting the consensus triggering conditions, the system can dynamically trade off between resource overhead and model consistency, thereby maintaining better training efficiency and security under different operating environments; recording the adjustments on the blockchain can enhance the transparency of the adjustments and facilitate post-event traceability.

[0114] Please refer to the following: Figures 2 to 4 . Figure 2 This is a diagram of the algorithm training architecture provided in one embodiment of this application. Figure 3 This is a verification schematic diagram provided in one embodiment of this application. Figure 4 This is a schematic diagram of model accuracy voting provided in one embodiment of this application.

[0115] Specifically, the model selection and starting point generation stage (see...) Figure 3During the verification phase, the system first calculates a score for each candidate transaction on the chain. This score is obtained by adding the transaction's own weight to the weights of the transactions it directly or indirectly verifies. Then, based on this score set, a roulette wheel sampling strategy is used to select several transactions as a candidate set to balance freshness and diversity. The selected candidate models are quickly evaluated on the local private verification set according to their available modalities. If a model performs below a preset accuracy threshold on any available modal or is identified as an anomaly by an anomaly detector (e.g., confidence interval anomaly or an anomaly detected by isolated forest), it is removed from the set. For the set of verified models that pass the screening, the participants choose the starting point generation method based on their available modalities and computing resources. This method can be one or a combination of the following: model integration weighted by verification score, parameter fusion separated by hierarchy (e.g., freezing the first few layers and fusing task layer parameters), or knowledge distillation (distilling a lightweight student model from multiple teacher models). After generation, the starting point model, its source transaction set, fusion strategy, and local verification summary are recorded together as the starting point metadata for this round of training and uploaded / written to the local DAG (for traceability and auditing).

[0116] Specifically, the phased consensus voting process (see...) Figure 4 and Figure 2Training Architecture: When a consensus condition is triggered, the current leader stops local training and initiates a periodic consensus message (PCM). The PCM includes the view number, a list of candidate model transaction hashes, the leader's preliminary candidate ranking, and a signature. Each participant verifies the validity of the PCM and takes a snapshot of the training state locally. If the verification passes, a signature preparation message is returned (preparation phase). When a sufficient number of preparation messages are collected (reaching the preset quorum), the voting phase begins. Each participant calculates performance metrics for each available modality of the candidate model based on its private validation set and generates a ranking within that modality (the ranking within the modality and the corresponding metrics are broadcast via a signature message). After collecting the rankings submitted by all participants, the leader uses a robust aggregation strategy (e.g., TrimmedMean or median aggregation / or Krum) to weight and fuse the rankings of each modality according to the pre-announced modality weights (which can be based on the proportion of the total number of modality samples publicly declared by all participants by default and can be adjusted in conjunction with data quality) to generate a global model ranking. This global ranking and aggregation evidence will be written into the phase consensus result and signed and uploaded to the blockchain. If the global ranking is not approved by a majority of participants (e.g., dissenting signatures or the dissenting percentage exceeds a threshold), a leader replacement mechanism is triggered: the system selects a new leader based on the previous round's consensus ranking priority or according to the Proof-of-Stake / Random Rollback rules, and re-initiates PCM until a ranking approved by a majority of participants is generated. After voting concludes and consensus is reached, the model ranked first is adopted by all parties as the benchmark model for the next training cycle, and the model's publisher or a participant elected according to the rules can serve as the leader for the next round of PCM (see [link to relevant documentation]). Figure 4 (Model accuracy voting illustration). Figure 2 The training architecture shown demonstrates the overall timing and data flow of asynchronous local training alternating with phased synchronous consensus.

[0117] Understandably, by introducing score-based roulette wheel sampling and local precision screening during the verification phase, the system can ensure that the selected candidate models are time-sensitive and diverse, while filtering out low-quality or malicious models at the local level, thereby improving the quality of the training starting point and convergence efficiency. By adopting intra-modal ranking + robust aggregation based on modal weights and supplemented by signature and timeout / quorum constraints during the consensus phase, the system can improve robustness to abnormal or malicious behavior while ensuring the fairness of multimodal heterogeneity evaluation. By using DAG to record model evolution and writing consensus evidence on the chain, an immutable chain of evidence is provided for model source tracing, contribution calculation, and subsequent auditing, achieving a controllable trade-off between efficiency, accuracy, and credibility.

[0118] The ultrasonic data verification method based on federated learning and blockchain proposed in this application is described below with an exemplary embodiment.

[0119] In this embodiment of the application, the structure of the model transaction in S100 (on-chain model transaction structure and notarization) is a structured record, and the example field set is as follows: Transaction = {TXID, ParentHashes, RoundID, ModelID, PublisherID, ModalitiesMeta, VerifySummary, Timestamp, Signature}.

[0120] Where Parent Hashes represents one or more parent transaction hashes to construct the DAG topology; ModalitiesMeta contains the type identifier for each modality, the sample size N_m for that modality, and its quality score. Verify Summary is the digest performance obtained through local verification (e.g., AUC, F1 digest); Signature is the publisher's digital signature of key fields (ensuring the source cannot be forged).

[0121] Understandably, the transaction structure not only supports model tracing and evolutionary map reconstruction, but also provides necessary metadata and evidence chains for subsequent modality-based weighted aggregation and auditing.

[0122] In this embodiment, S200 (model candidate selection, local validation screening, and starting model generation), candidate model scoring, and roulette wheel sampling: calculate the score for each candidate transaction i on the chain. An example formula is as follows:

[0123]

[0124] in, Freshness metrics (e.g., exponential decay value over publication time) ); : Performance score declared or verified in the transaction (normalized to [0,1]); Indirect verification weight represents the cumulative weight of other transactions cited / endorsed by the exchange (reflecting the degree to which they are cited multiple times or verified by high-reputation nodes). Non-negative weights and .

[0125] After calculating the scores of all candidate transactions based on the above formula, K candidate transactions are selected by roulette wheel probability sampling, with the sampling probability being:

[0126]

[0127] Local validation screening: For each candidate model obtained from the sampling, the performance index is calculated on the local private validation set for each available mode m. (e.g., AUC, F1, etc.), and perform anomaly detection on the model (e.g., if for any mode) (Or, if an anomaly is detected by the anomaly detector, it is removed). The retained set is denoted as... .in The accuracy threshold for this mode can be set according to medical needs (e.g., (This represents the minimum AUC threshold).

[0128] Starting point model generation: for the validation set The model in the model selects a generation strategy based on the available modalities and computing power of the participants:

[0129] (a) Weighted fusion: If parameters are directly fused, a weighted parameter average is used:

[0130]

[0131] in For the parameters of model i, (Using the verification score as the weight);

[0132] (b) Knowledge distillation: The lightweight student model is trained using several excellent teacher models from the validation set. Example of loss function:

[0133]

[0134] Parameter description: For cross-entropy loss, For Kullback–Leibler divergence, The distillation temperature. For distillation weight.

[0135] Understandably, by first scoring, then sampling, then local screening, and finally generating the starting point, low-quality or abnormal models can be eliminated while preserving freshness and diversity, thereby improving the quality of local training starting points and enhancing convergence and robustness.

[0136] In this embodiment, S300–S400 (periodic consensus and modal voting) is a periodic consensus process divided into three stages: PCM (periodic consensus message) → preparation → voting. The key logic and formulas are as follows:

[0137] PCM Phase: The current leader issues a PCM, which includes a list of candidate models. View ID, leader's signature, etc.

[0138] Preparation Phase: Participants verify the integrity and signature of the PCM. If successful, a preparation message is returned. The preparation message carries locally available modal declarations and locally cached verification digest metadata for this round (for subsequent verification).

[0139] Voting Phase (Intramodal Ranking and Weighted Fusion): Each participant uses its private validation set to pair with the set. The performance of each model is calculated based on modal m. (Participant p's score for model j on mode m), and generate intra-modal ranking. To obtain the global score for model j, first normalize and robustly aggregate the scores of the same mode submitted by participants (e.g., take the mean after removing the highest k1 and lowest k2 from the scores submitted by participants for that mode, or directly take the median), and denote the aggregated mode score as... Based on modal weights (Preset or dynamically adjusted, see below) Calculate the model's global score:

[0140]

[0141] modal weights A default calculation method is based on the total number of modal samples publicly declared by all participants. :

[0142]

[0143] To ensure data quality, it can be further revised as follows: ,in This is the modal quality factor (e.g., the reciprocal of the average validation score or noise level). Finally, all models are calculated according to... Sort and generate a global ranking. If a majority of participants (e.g., more than 50%) have no objection to the ranking, the ranking is written into the phase consensus result and uploaded to the blockchain; otherwise, a leader replacement is triggered.

[0144] Understandably, the process of first aggregating within a modality and then merging by modality weights not only preserves the professionalism of each modality in local evaluation, but also reflects the representativeness and quality of the modality in the entire system through weighted fusion, thereby achieving fair and robust model ranking in a multimodal heterogeneous environment.

[0145] In this embodiment of the application, S500 (baseline model distribution and next round of asynchronous training) if the model The highest score among the above (i.e. If a transaction is deemed valid, the resulting model transaction is designated as the benchmark model for this round. The benchmark model parameters or its authorized retrieval information will be delivered to each participant via on-chain records or P2P. Each participant can then directly use this benchmark model locally. Continue fine-tuning using these as initial weights:

[0146]

[0147] in It may include a regularized supervision loss, a regularization term, and an optional migration loss (to maintain consistency with the baseline model). The next leader may be appointed by the publisher of the baseline model or determined according to rules (e.g., rotation / staking).

[0148] It is understandable that by periodically distributing the "most widely accepted optimal model" as the starting point for the next round, it is possible to periodically correct deviations during asynchronous training, improve the overall convergence speed, and take into account local adaptability.

[0149] In this embodiment of the application, S600 (termination condition, contribution and reward distribution, transaction completion), the termination condition may be one of the following or a combination thereof: reaching the maximum round. ,continuous Global performance gains at each stage Or resources / time reach their limits. Global performance gain is defined as the difference between a certain stage and the baseline model of the previous stage on a unified validation metric.

[0150] Contribution Measurement and Reward Distribution: Contribution to Participant p An exemplary linear combination measurement can be used:

[0151]

[0152] in This represents the marginal contribution of the model submitted by participant p to the global performance in stage t (which can be approximated by ablation or by the difference before and after consensus ranking). The weighting is based on time sequence (e.g., higher weight for recent periods). The total reward pool is R, and the total reward is distributed according to the contribution percentage.

[0153]

[0154] Complete the transaction and sign-off thresholds: The final round of leaders constructs the final transaction, including the final model summary and each party's signature. This includes reward details, consensus records, etc.; participating parties verify the final transaction and attach their signatures. If the total number of participating parties is N, let the signature threshold be... Then at least A transaction can only be completed and recorded on the blockchain after a valid signature is obtained (e.g.) (This indicates that at least two-thirds of the signatures are required). Upon completion of the transaction and its recording on the blockchain, an on-chain / off-chain reward distribution mechanism is triggered simultaneously.

[0155] Understandably, linking contribution measurement, reward allocation, and transaction completion on the blockchain not only creates an incentive loop but also provides on-chain traceable evidence of contributions and rewards throughout the training process, which helps to curb malicious behavior and increase the enthusiasm of participants.

[0156] In this application embodiment, regarding robustness, anomaly handling, and adaptive consensus triggering, to prevent individual malicious participants from affecting the aggregation results, the system can perform anomaly detection (such as z-score, isolated forest, or bias detection based on historical consistency) on the scores reported by participants before modal score aggregation, and remove or reduce their weights if necessary; consensus triggering interval. Adaptive adjustment: based on the monitored global performance slope Differences in progress among participants Given network load L as input, formulate a strategy:

[0157]

[0158] Where clip indicates truncation to the interval. , For the normalization function (example: when Smaller and Larger time reduction (To achieve more frequent consensus), the specific form can be designed according to engineering requirements and written into the implementation.

[0159] Understandably, the robust aggregation, anomaly detection, and adaptive triggering mechanisms described above enable the system to remain stable and improve training efficiency and security when faced with heterogeneity of participants, network fluctuations, or concept drift.

[0160] In summary, this exemplary embodiment achieves trusted collaborative training and auditable verification of multi-participant, multi-modal ultrasound data under privacy protection by recording model evolution and verification summaries on-chain, selecting candidate models locally using a score-plus-roulette wheel approach, generating a global ranking during the voting phase through intra-modal sorting and weighted robust aggregation, and driving reward allocation and transaction signing on-chain based on contribution. It is understood that the formulas, parameters, and thresholds given above are exemplary settings, and actual engineering implementations can be optimized based on specific scenarios (number of participants, modal types, compliance requirements, and computing power conditions). Several value examples are provided in the dependent claims or embodiments of the specification to support the full implementation of patent protection.

[0161] Figure 5 This is a schematic diagram of a module of an ultrasound data verification system based on federated learning and blockchain, provided in an embodiment of this application. Figure 5 The ultrasonic data verification system 10 based on federated learning and blockchain shown includes at least the following parts: local training module 11, consensus generation module 12, and result output module 13.

[0162] In this embodiment, the local training module 11 includes multiple participants. Each participant maintains a blockchain based on a directed acyclic graph structure locally to record model transactions generated during training. Each model transaction includes at least model parameters, a publisher identifier, a timestamp, and reference information pointing to previous transactions. Each participant obtains at least one existing model from its locally maintained blockchain, performs local training using local private ultrasound data, obtains an updated local model, and publishes the updated local model as a new model transaction to the blockchain. Please refer to the following for details. Figures 1 to 4 The details and their corresponding descriptions are not repeated here.

[0163] In this embodiment, the consensus generation module 12 is used to pause local training and enter the consensus phase at preset training cycles. During the consensus phase, each participant verifies and evaluates the performance of all models published to the blockchain within the current cycle based on their own private verification data, and generates a model ranking. Based on the model ranking generated in the consensus phase, the model with the highest ranking is selected as the benchmark model for the next training cycle, and each participant continues asynchronous local training based on the benchmark model. Please refer to the following for details. Figures 1 to 4 The details and their corresponding descriptions are not repeated here.

[0164] In this embodiment, the result output module 13 is used to output the global model, which has been agreed upon by all participants, as the collaborative training result when the preset training termination condition is met during iteration. Please refer to the following for details. Figures 1 to 4 The details and their corresponding descriptions are not repeated here.

[0165] Figure 6 This is an electronic device 2O provided in one embodiment of this application. For example... Figure 6 As shown, the electronic device 2O includes at least the following components: processor 21 and memory 22.

[0166] In this embodiment, the memory 22 is used to store executable instructions of the processor 21, which, when configured to execute instructions, implement... Figure 1 This paper presents an ultrasonic data verification method based on federated learning and blockchain.

[0167] In embodiments of this application, a computer-readable storage medium includes instructions that instruct a device to perform the method as described in the first aspect. For example, the instructions instruct the device to perform... Figure 1 The steps S100 to S600 illustrate an ultrasonic data verification method and system based on federated learning and blockchain.

[0168] In one embodiment of this application, the program operating in the electronic device 2O may be a program that controls a central processing unit (CPU) or similar device to achieve the functions of the above-described embodiments of the present invention (a program that enables the computer to function). The information processed by these devices is then temporarily stored in random access memory (RAM) during processing, and subsequently stored in various ROMs such as read-only memory (Flash ROM) and hard disk drives (HDDs), and read, corrected, and written by the CPU as needed.

[0169] It should be noted that a portion of the electronic device 20 described above can also be implemented using a computer. In this case, the program for implementing the control function can be recorded on a computer-readable recording medium, and the program recorded on the recording medium can be read into the computer system and executed.

[0170] It should be noted that the "computer system" mentioned here refers to a computer system built into an electronic device 2O, employing hardware including an operating system and peripheral devices. Furthermore, "computer-readable recording media" refers to removable media such as floppy disks, magneto-optical disks, ROMs, and CD-ROMs, as well as storage devices such as hard drives built into computer systems.

[0171] Furthermore, a "computer-readable recording medium" can include: a medium that dynamically stores a program for a short period of time, such as a communication line used when transmitting a program via a network such as the Internet or a communication line such as a telephone line; or a medium that stores a program for a fixed period of time, such as volatile memory within a computer system that serves as a server or client in this case. In addition, the aforementioned program can be a program used to implement the above-mentioned functions, or it can be a program that can implement the above-mentioned functions by combining with programs already recorded in the computer system.

[0172] It is understood that the ultrasound data verification method and system based on federated learning and blockchain provided in this application, through the combination of a federated learning framework and DAG blockchain, enables multiple medical institutions to conduct collaborative model training securely and reliably without sharing original sensitive data, fundamentally protecting patient privacy and data security. Secondly, the hybrid mechanism combining asynchronous local training and periodic synchronous consensus avoids equipment waiting and resource waste in fully synchronous schemes, improving training efficiency, and effectively ensures the convergence speed and final performance of the global model through phased model selection and consensus calibration. Furthermore, addressing the common problem of heterogeneous multimodal ultrasound data in medical scenarios, this method designs a multimodal ranking fusion mechanism based on data volume weighting, ensuring fair representation of the contributions of different data modalities and improving the model's generalization ability and diagnostic robustness. Finally, relying on the immutable and traceable characteristics of blockchain, all training processes, model versions, and consensus results are fully recorded, enhancing the system's transparency and credibility, and providing a reliable technical foundation for subsequent model auditing, accountability, and compliance verification.

[0173] Those skilled in the art should recognize that the above embodiments are only used to illustrate this application and are not intended to limit this application. Any appropriate changes and variations made to the above embodiments within the essential spirit and scope of this application fall within the scope of protection claimed in this application.

Claims

1. A method for verifying ultrasonic data based on federated learning and blockchain, applied to collaborative model training and verification among multiple participants, characterized in that... The method includes: Each participating party maintains a blockchain based on a directed acyclic graph structure locally to record model transactions generated during the training process; wherein each model transaction includes at least model parameters, publisher identifier, timestamp, and reference information pointing to previous transactions; Each of the aforementioned participants obtains at least one existing model from the locally maintained blockchain, performs local training using local private ultrasound data to obtain an updated local model, and constructs the updated local model as a new model transaction to publish to the blockchain. Every preset training cycle, all participating parties pause their local training and enter the consensus phase; During the consensus phase, each participating party verifies and evaluates the performance of all models published to the blockchain within the current period based on its own private verification data, and generates a model ranking. Based on the model ranking generated in the consensus phase, the model with the highest ranking is selected as the benchmark model for the next training cycle, and each participant continues to conduct the next round of asynchronous local training based on the benchmark model. The process iterates until the preset training termination condition is met, and finally outputs the global model confirmed by the consensus of all participating parties as the collaborative training result.

2. The ultrasonic data verification method based on federated learning and blockchain according to claim 1, characterized in that, Each of the model transactions further includes: at least one parent transaction hash, round identifier, model number, available modal metadata of the publisher, model verification digest, and digital signature; The blockchain uses the initial model transaction as the root node, and each newly published model transaction after the initial model references at least one previous model transaction as the parent node, thus forming a model evolution graph.

3. The ultrasonic data verification method based on federated learning and blockchain according to claim 2, characterized in that, Each of the aforementioned participants obtains at least one existing model from the locally maintained blockchain and performs local training using local private ultrasound data, including: From the local blockchain, unverified or recent transactions that meet the preset freshness constraints are selected first. At the same time, a roulette-style random sampling strategy based on score metric is adopted to construct a candidate model set that combines timeliness and diversity. Local validation screening: Using local private validation data, the models in the candidate model set are evaluated for performance, and models whose evaluation results are lower than a preset accuracy threshold or are judged to be abnormal are removed to obtain the validation model set. Starting model generation: Based on the set of validation models and the available data modalities, one or more of the following methods are used to generate the starting model for this round of asynchronous training: model integration, parameter fusion, or knowledge distillation.

4. The ultrasonic data verification method based on federated learning and blockchain according to claim 3, characterized in that, The consensus phase includes a periodic consensus message phase, a preparation phase, and a voting phase: During the periodic consensus message phase, the leader of the current round initiates a consensus request and broadcasts a periodic consensus message that includes the ranking information of the candidate models in this round calculated by the leader. During the preparation phase, each participating party verifies the validity of the periodic consensus message. After successful verification, asynchronous training is paused and a preparation message is broadcast to other participating parties. During the voting phase, each participating party generates and broadcasts an in-modal ranking for all candidate models published within the current period based on its available data modalities, using its local private verification data. After the leader collects the intramodal rankings of all participants, it performs weighted fusion based on the pre-announced proportion of data volume to generate a global model ranking and writes it into the phase consensus result. If the global model ranking is not accepted by the majority of participants, a leader replacement mechanism is triggered.

5. The ultrasonic data verification method based on federated learning and blockchain according to claim 4, characterized in that, The iteration continues until a preset training termination condition is met, and then includes: In the final round, the leader calculates the contribution and reward distribution of each participant based on the consensus results of each round, and constructs a final transaction including a final model summary, reward distribution details, and consensus round records. Each of the aforementioned parties verifies the correctness of the final transaction and attaches a digital signature to the final transaction; After receiving a preset number of digital signatures, the leader combines the digital signatures with the final transaction to construct a completed transaction and publishes it to the blockchain.

6. The ultrasonic data verification method based on federated learning and blockchain according to claim 4, characterized in that, The leader replacement mechanism includes: When more than a preset proportion of the participants raise objections to the global model ranking, the current leader is marked as invalid. Candidate participants will be selected as new leaders in descending order of their ranking from the previous consensus. If the previous consensus ranking does not exist, the new leader will be determined through a proof-of-stake mechanism. The newly appointed leader restarts the consensus process until a ranking result is generated that is accepted by the majority of participants.

7. The ultrasonic data verification method based on federated learning and blockchain according to claim 1, characterized in that, When the private ultrasound data of the participating parties contains multiple imaging modalities, the process of generating model rankings also includes: Each participant first calculates the performance metrics for different candidate models on each available data modality based on their local private validation data; Each participating party will submit the calculated modal performance indicators during the consensus phase; By using preset fusion rules, the performance evaluation results from different participants targeting different modalities are integrated to form a unified global model ranking.

8. The ultrasonic data verification method based on federated learning and blockchain according to claim 7, characterized in that, The preset fusion rules include: The data modalities are weighted and merged based on their proportion of the total publicly declared data among all participating parties.

9. The ultrasonic data verification method based on federated learning and blockchain according to claim 1, characterized in that, The method further includes: The triggering conditions for the consensus phase are adjusted based on at least one of the following: model performance convergence, differences in training progress among participants, or network load.

10. An ultrasound data verification system based on federated learning and blockchain, applied to implement the ultrasound data verification method based on federated learning and blockchain as described in any one of claims 1 to 9, characterized in that, The system includes: The local training module includes multiple participants, each of whom maintains a blockchain based on a directed acyclic graph structure locally to record model transactions generated during training. Each model transaction includes at least model parameters, a publisher identifier, a timestamp, and reference information pointing to previous transactions. Each participant obtains at least one existing model from the locally maintained blockchain, performs local training using local private ultrasound data, obtains an updated local model, and publishes the updated local model as a new model transaction to the blockchain. A consensus generation module is used to pause local training and enter the consensus phase at each preset training cycle. In the consensus phase, each participant verifies and evaluates the performance of all models published to the blockchain in the current cycle based on their own private verification data, and generates a model ranking. Based on the model ranking generated in the consensus phase, the model with the highest ranking is selected as the benchmark model for the next training cycle, and each participant continues to conduct the next round of asynchronous local training based on the benchmark model. The result output module is used to output the global model, which has been confirmed by the consensus of all the participating parties, as the collaborative training result when the preset training termination condition is met during iteration.

Images