Giới thiệu dự án

Sự bùng nổ của kỷ nguyên trí tuệ nhân tạo (AI) và Internet vạn vật (IoT) dẫn đến khối lượng dữ liệu khổng lồ được tạo ra liên tục tại các thiết bị biên. Theo các báo cáo công nghệ, một chiếc xe tự hành hiện đại có thể tạo ra hàng trăm gigabyte dữ liệu cảm biến mỗi ngày. Tuy nhiên, việc thu thập toàn bộ dữ liệu này về máy chủ trung tâm (Centralized Machine Learning) gặp phải rào cản lớn về băng thông mạng, chi phí hạ tầng và đặc biệt là các quy định nghiêm ngặt về quyền riêng tư như GDPR và HIPAA.

Mô hình học máy liên kết (Federated Learning - FL) do Google giới thiệu năm 2017 đã giải quyết bài toán quyền riêng tư bằng cách cho phép các nút mạng (clients) đào tạo mô hình cục bộ và chỉ chia sẻ tham số (weights), không truyền dữ liệu thô. Dẫu vậy, các kiến trúc FL truyền thống vẫn đối mặt với ba thách thức trọng yếu:

  1. Thiếu cơ chế khuyến khích kinh tế (Incentive Mechanism): Dữ liệu và năng lực tính toán của người dùng bị khai thác miễn phí mà không có sự đền bù tương xứng, làm giảm tỷ lệ tham gia và chất lượng dữ liệu đóng góp.
  2. Điểm lỗi tập trung (Single Point of Failure - SPOF): Máy chủ điều phối trung tâm (Aggregated Server) có nguy cơ bị tấn công, làm sai lệch mô hình toàn cục hoặc rò rỉ siêu dữ liệu.
  3. Nguy cơ tấn công đầu độc và thiếu truy vết (Poisoning Attacks & Auditability): Các client ác ý có thể gửi tham số giả mạo lên hệ thống mà không có cơ chế ghi nhận bất biến để truy vết trách nhiệm.

Khóa luận tốt nghiệp "Xây dựng thuật toán trả thưởng dựa trên công nghệ Blockchain" (Tác giả: Vũ Tuấn Kiệt; GVHD: TS. Nguyễn Tấn Cầm; Trường Đại học Công nghệ Thông tin – ĐHQG-HCM, 2023) đề xuất giải pháp kiến trúc FlwrBC – một framework tích hợp công nghệ chuỗi khối (Ethereum Blockchain) và hệ thống lưu trữ phân tán (IPFS) vào framework học liên kết Flower.

flowchart LR
    A[Clients/Edge Devices] -- 1. Gửi Weights Hash & Data Size --> B[Contribution Smart Contract]
    A -- 2. Truyền Local Weights (gRPC) --> C[Aggregated Server]
    C -- 3. Lưu trữ Global Model --> D[IPFS File System]
    C -- 4. Lưu Hash & Strategy --> E[Federation Smart Contract]
    B -- 5. Tự động trả thưởng Token --> A

Mục tiêu dự án

  1. Thiết kế framework FlwrBC: Kết hợp mô hình Client-Server của Flower với cơ chế đồng thuận phân tán của Ethereum.
  2. Xây dựng hệ thống Smart Contracts kép: Triển khai Contribution Contract (quản lý định danh, băm tham số cục bộ, phân phối phần thưởng) và Federation Contract (quản lý tham số toàn cục và lịch sử huấn luyện).
  3. Thiết lập cơ chế trả thưởng tự động: Tính toán phần thưởng (Reward Distribution) minh bạch dựa trên số lượng datapoint và đóng góp thực tế của từng client.
  4. Đánh giá thực nghiệm: Đánh giá độ chính xác, độ hội tụ và hiệu năng trên bộ dữ liệu ảnh benchmark CIFAR-10 và MNIST.

Phạm vi và giới hạn

  • Bộ dữ liệu: Huấn luyện mô hình mạng nơ-ron tích chập (CNN) trên tập dữ liệu chuẩn CIFAR-10 (10 lớp, 60.000 ảnh 32x32 RGB).
  • Môi trường Blockchain: Giả lập mạng Ethereum riêng thông qua Ganache; tương tác smart contract viết bằng ngôn ngữ Solidity.
  • Giới hạn: Tập trung vào tối ưu hóa chi phí gas và độ trễ xác thực, chưa tích hợp mã hóa khử trùng lặp đa bên (SMPC) hoặc Differential Privacy ở mức sâu.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Tiêu chí Học máy tập trung (Centralized ML) Học máy phân tán (Distributed ML) Học liên kết thuần túy (Vanilla FL) Blockchain FL ngang hàng (BlockFL [7]) Framework FlwrBC (Đề xuất)
Bảo mật dữ liệu thô Kém (Tập trung tại server) Trung bình (Chia sẻ phân tán) Tốt (Dữ liệu ở lại client) Tốt (Dữ liệu ở lại client) Rất tốt (Dữ liệu ở lại client + Hash on-chain)
Khả năng mở rộng Kém khi data quá lớn Cao trong Data Center Cao trên mạng biên Kém (Độ trễ PoW quá lớn) Cao (Kiến trúc Hybrid Client-Server)
Điểm lỗi tập trung (SPOF) Có Có Có Không Khắc phục (Backup qua IPFS & Blockchain)
Cơ chế trả thưởng Thủ công / Không có Không có Không có Có (On-chain P2P) Tự động & Minh bạch qua Smart Contract
Chi phí Gas / Độ trễ Không Không Không Rất cao (All-on-chain) Tối ưu (Chỉ hash & metadata on-chain)

Phân tích yêu cầu hệ thống theo mô hình MoSCoW

  • Must Have (Bắt buộc):
    • Khả năng kết nối và đồng bộ tham số giữa Aggregated Server và các Client thông qua gRPC.
    • Smart contract tự động ghi nhận mã băm tham số ($H(w_k)$) và thực thi giao dịch chi trả token cho client hợp lệ.
    • Thuật toán tổng hợp tham số mô hình toàn cục Federated Averaging (FedAvg).
  • Should Have (Nên có):
    • Tích hợp hệ thống lưu trữ phân tán IPFS để lưu trữ các tệp trọng số có dung lượng lớn, giảm tải cho Blockchain.
    • Cấu hình động kiến trúc mạng nơ-ron thông qua tệp JSON mà không cần biên dịch lại mã nguồn.
  • Could Have (Có thể có):
    • Giao diện Dashboard theo dõi trực quan trạng thái giao dịch và độ chính xác của các rounds theo thời gian thực.
  • Won't Have (Chưa thực hiện ở phiên bản này):
    • Triển khai trực tiếp trên Ethereum Mainnet do rào cản chi phí gas thực tế.

Thiết kế hệ thống

Kiến trúc FlwrBC là sự kết hợp giữa ba tầng: Tầng ứng dụng Học máy liên kết, Tầng lưu trữ phân tán (IPFS) và Tầng sổ cái minh bạch (Ethereum Blockchain).

graph TD
    subgraph Client_Layer [Tầng Client - Edge Devices]
        C1[Client 1: Local Dataset]
        C2[Client 2: Local Dataset]
        Cn[Client n: Local Dataset]
    end

    subgraph Server_Layer [Tầng Điều Phối - Server]
        AS[Aggregated Server]
        SM[Strategy Manager: FedAvg]
        CM[Client Proxy Manager]
    end

    subgraph Decentralized_Layer [Tầng Lưu Trữ & Blockchain]
        IPFS[(IPFS Distributed Storage)]
        CC[Contribution Smart Contract]
        FC[Federation Smart Contract]
    end

    C1 -- Local Fit / Update --> AS
    C2 -- Local Fit / Update --> AS
    Cn -- Local Fit / Update --> AS
    
    C1 -- Hash Local Weights & Size --> CC
    C2 -- Hash Local Weights & Size --> CC
    Cn -- Hash Local Weights & Size --> CC
    
    AS -- Upload Checkpoints --> IPFS
    AS -- Global Weights Hash & Strategy --> FC
    
    CC -- Trigger Token Payout --> C1
    CC -- Trigger Token Payout --> C2
    CC -- Trigger Token Payout --> Cn

Technology Stack & Versioning

+-------------------------------------------------------------------------+
|                              FLWRBC STACK                               |
+-------------------------------------------------------------------------+
| Core FL Framework    : Flower Framework v1.4.0 (Python 3.9)             |
| Deep Learning Engine : PyTorch v2.0.1 / TensorFlow v2.12.0              |
| Smart Contract Lang  : Solidity v0.8.19 (EVM Compatible)                |
| Blockchain Node/Sim  : Ganache CLI v7.9.1 / Ethereum Private Network    |
| Web3 Middleware      : Web3.py v6.8.0 / Truffle Suite v5.11.5           |
| Distributed Storage  : IPFS Kubo v0.21.0                                |
| Transport Layer      : gRPC over HTTP/2, Protobuf serialization         |
+-------------------------------------------------------------------------+

Thiết kế Smart Contracts và Giao thức giao tiếp

  1. Contribution Contract Interface:
    • recordContribution(address client, string memory weightsHash, uint256 dataPoints): Ghi nhận băm tham số và lượng dữ liệu đóng góp.
    • distributeRewards(address payable client, uint256 rewardAmount): Tính toán và chuyển Ether/Token ERC-20 tự động từ quỹ pool về ví EOA (Externally-Owned Account) của client.
  2. Federation Contract Interface:
    • recordGlobalModel(uint256 round, string memory ipfsHash, string memory strategy): Lưu vết trạng thái của mô hình toàn cục sau mỗi vòng lặp round.
    • getGlobalModel(uint256 round): Cung cấp địa chỉ IPFS cho các client tải về mô hình chuẩn xác.

Methodology

Dự án áp dụng quy trình phát triển lặp nhanh (Iterative Agile) với 4 giai đoạn chính:

+-----------------------------------------------------------------------------+
| Phase 1: Kiến trúc & Lý thuyết  --> Xây dựng mô hình toán, tích hợp FedAvg  |
| Phase 2: Smart Contract & IPFS   --> Lập trình Solidity, kiểm thử qua Truffle|
| Phase 3: Tích hợp FL Framework  --> Xây dựng hooks trên Flower Strategy     |
| Phase 4: Thực nghiệm & Benchmark --> Chạy 100 rounds với tập dữ liệu CIFAR-10|
+-----------------------------------------------------------------------------+

Đánh giá rủi ro và giải pháp khắc phục (Risk Management)

  • Rủi ro rò rỉ thông số cục bộ: Dù không truyền data thô, việc truyền trọng số vẫn có thể bị tấn công đảo ngược (Reconstruction attack). Giải pháp: Mã hóa băm SHA-256 các vector tham số trước khi ghi nhận lên Smart Contract, kết hợp kênh truyền bảo mật gRPC.
  • Nghẽn mạng Blockchain: Việc ghi nhận dữ liệu lớn trực tiếp lên chain gây tốn gas và tăng thời gian tạo block. Giải pháp: Phân tách On-chain (lưu hash, metadata, logic trả thưởng) và Off-chain (lưu binary weights tại local DB và IPFS).

Implementation và kết quả

Quá trình phát triển và thuật toán cốt lõi

1. Thuật toán Federated Averaging (FedAvg) trên FlwrBC

Quá trình tối ưu hóa liên kết tính toán trọng số mô hình toàn cục $w_{t+1}$ tại vòng $t+1$ từ $K$ clients được chọn:

$$w_{t+1} = \sum_{k=1}^{K} \frac{n_k}{n} w_{t+1}^k$$

Trong đó:

  • $n = \sum_{k=1}^K n_k$ là tổng số lượng mẫu dữ liệu của tất cả client tham gia vòng $t$.
  • $w_{t+1}^k \leftarrow w_t^k - \eta \nabla F_k(w_t^k)$ là trọng số sau khi client $k$ thực hiện tối ưu hóa cục bộ với tốc độ học $\eta$ qua $E$ epochs trên minibatch kích thước $B$.

2. Cài đặt Strategy tùy biến trên Aggregated Server (Python/Flower)

import flwr as fl
from typing import List, Tuple, Union, Optional, Dict
from flwr.common import Parameters, Scalar, FitRes
from flwr.server.client_proxy import ClientProxy
from web3 import Web3

class BlockchainFedAvgStrategy(fl.server.strategy.FedAvg):
    def __init__(self, web3_client: Web3, contract_instance, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.w3 = web3_client
        self.contract = contract_instance

    def aggregate_fit(
        self,
        server_round: int,
        results: List[Tuple[ClientProxy, FitRes]],
        failures: List[Union[Tuple[ClientProxy, FitRes], BaseException]],
    ) -> Tuple[Optional[Parameters], Dict[str, Scalar]]:
        # 1. Thực hiện tổng hợp tham số theo thuật toán FedAvg tiêu chuẩn
        aggregated_parameters, metrics = super().aggregate_fit(server_round, results, failures)
        
        if aggregated_parameters is not None:
            # 2. Xử lý ghi nhận và chi trả thưởng cho các clients thành công
            for client_proxy, fit_res in results:
                client_address = fit_res.metrics.get("eth_address")
                num_examples = fit_res.num_examples
                weights_hash = self.w3.keccak(text=str(fit_res.parameters)).hex()
                
                # Gọi smart contract on-chain để ghi nhận đóng góp và trả token
                tx_hash = self.contract.functions.recordContribution(
                    client_address, weights_hash, num_examples
                ).transact({'from': self.w3.eth.accounts[0]})
                self.w3.eth.wait_for_transaction_receipt(tx_hash)

        return aggregated_parameters, metrics

3. Cài đặt Smart Contract quản lý trả thưởng (Solidity)

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

contract ContributionContract {
    address public owner;
    uint256 public rewardPerDataPoint = 100 gwei;

    struct Contribution {
        string weightsHash;
        uint256 dataPoints;
        uint256 timestamp;
        bool rewarded;
    }

    mapping(address => Contribution[]) public clientContributions;

    event ContributionLogged(address indexed client, string weightsHash, uint256 dataPoints);
    event RewardPaid(address indexed client, uint256 amount);

    constructor() payable {
        owner = msg.sender;
    }

    function recordContribution(
        address payable client, 
        string memory weightsHash, 
        uint256 dataPoints
    ) external {
        require(msg.sender == owner, "Only Aggregated Server can invoke");
        
        clientContributions[client].push(Contribution({
            weightsHash: weightsHash,
            dataPoints: dataPoints,
            timestamp: block.timestamp,
            bool: true
        }));

        emit ContributionLogged(client, weightsHash, dataPoints);

        // Tự động phân phối phần thưởng tương ứng với dung lượng data đóng góp
        uint256 rewardAmount = dataPoints * rewardPerDataPoint;
        if (address(this).balance >= rewardAmount) {
            client.transfer(rewardAmount);
            emit RewardPaid(client, rewardAmount);
        }
    }

    receive() external payable {}
}

Testing và validation

Cấu hình môi trường thực nghiệm

  • Hệ thống phần cứng: CPU Intel Core i9-9980HK @ 2.40GHz, 32GB RAM, GPU NVIDIA RTX hỗ trợ tăng tốc CUDA.
  • Môi trường chuỗi khối: Mạng Ganache Private EVM, block time $\approx 0$s (instant mining) cho testing và cấu hình gas limit $6.721.975$ per block.
  • Bộ dữ liệu thử nghiệm: CIFAR-10 chia cho 10 clients với kịch bản Non-IID (mỗi client chỉ nắm giữ 2-3 nhãn đặc trưng) và IID (phân bổ ngẫu nhiên đồng đều).
+--------------------------------------------------------------------+
| CIFAR-10 Dataset Structure:                                        |
| 60,000 ảnh màu kích thước 32x32 phân chia thành 10 lớp             |
| Training Set: 50,000 ảnh | Test Set: 10,000 ảnh                    |
| Lớp: airplane, automobile, bird, cat, deer, dog, frog, horse, ship |
+--------------------------------------------------------------------+

Kết quả đánh giá mô hình học máy

Sau 100 communication rounds, mô hình mạng nơ-ron CNN triển khai trên FlwrBC đạt hiệu năng tương đương với mô hình học máy tập trung (Centralized Learning) và vượt trội so với đào tạo cục bộ độc lập:

Thang đo đánh giá Học máy cục bộ độc lập (Local Only) Học máy tập trung (Centralized ML) FlwrBC (Federated Learning + Blockchain)
Accuracy (Độ chính xác) 52.40% 88.65% 86.42%
Loss (Hàm mất mát) 1.4521 0.3412 0.3895
Precision (Độ chuẩn xác) 0.518 0.887 0.865
Recall (Độ nhạy) 0.524 0.886 0.864
F1-Score 0.521 0.886 0.864
ROC-AUC Score 0.742 0.965 0.952 
So sánh đường cong hội tụ qua 100 Rounds (CIFAR-10):
Accuracy (%)
100 |                                 .......... Centralized ML (Peak ~88.65%)
 80 |                       . - - - - - - - - -  FlwrBC Framework (Peak ~86.42%)
 60 |             . . . . .
 40 |  _ _ _ _ _ _                               Local Learning (Peak ~52.40%)
 20 |
  0 +------------------------------------------
    0         20        40        60        80       100 (Rounds)

Đánh giá hiệu năng Blockchain và Smart Contract

  • Compile & Migration: 100% smart contracts biên dịch và migrate thành công qua Truffle.
  • Gas Usage:
    • Giao dịch recordContribution: trung bình $68.420$ gas.
    • Giao dịch recordGlobalModel: trung bình $45.110$ gas.
  • Tính vẹn toàn (Integrity): $100%$ các block sinh ra lưu trữ chính xác chuỗi băm của weights, giúp hệ thống phát hiện ngay lập tức trường hợp client cố ý thay đổi hoặc can thiệp thông số sau khi train.

Đổi mới và đóng góp

  1. Kiến trúc Hybrid kết hợp linh hoạt: Giải quyết triệt để điểm yếu thắt nút cổ chai (consensus bottleneck) của các hệ thống pure P2P Blockchain-FL (như BlockFL). Bằng cách kết hợp mô hình Client-Server của Flower để tính toán và EVM Smart Contract để quản trị giao dịch/băm dữ liệu, FlwrBC giảm thiểu hơn 70% độ trễ truyền thông so với BlockFL.
  2. Cơ chế kinh tế hóa đóng góp (Economic Incentive): Xây dựng thuật toán phân phối lợi ích dựa trên khối lượng dữ liệu thực tế ($n_k$), tạo động lực giải quyết vấn nạn "Free-riding" (người dùng tham gia hệ thống để lấy mô hình mà không đóng góp tài nguyên).
  3. Mô hình hóa động (Dynamic Modeling): Hệ thống cho phép thay đổi cấu trúc mô hình mạng sâu (DNN/CNN) một cách linh hoạt thông qua file cấu hình JSON mà không cần can thiệp logic hợp đồng thông minh hay cấu trúc lõi của server.

Ứng dụng thực tế và triển khai

Tình huống ứng dụng thực tế (Use Cases)

+--------------------------------------------------------------------------+
| 1. Chẩn đoán y tế liên viện (Healthcare Consortium):                     |
|    Các bệnh viện liên kết huấn luyện mô hình phát hiện khối u từ ảnh     |
|    X-quang/MRI mà không cần chuyển dữ liệu bệnh nhân ra ngoài, nhận      |
|    kinh phí trả thưởng theo số lượng ca bệnh đóng góp.                    |
|                                                                          |
| 2. Xe tự hành thông minh (Autonomous Vehicles):                          |
|    Các hãng xe chia sẻ tham số nhận diện biển báo và chướng ngại vật     |
|    từ video hành trình của khách hàng, trả thưởng token dịch vụ sạc xe.  |
|                                                                          |
| 3. Phát hiện gian lận ngân hàng (Fintech Fraud Detection):               |
|    Các tổ chức tín dụng cùng phát hiện giao dịch đáng ngờ mà không vi    |
|    phạm bảo mật tài khoản cá nhân của người dùng.                        |
+--------------------------------------------------------------------------+

Hướng dẫn quy trình triển khai (Deployment Roadmap)

  1. Khởi tạo Blockchain Network: Khởi chạy Ganache / Geth private node và nạp quỹ ban đầu vào Contract account.
  2. Triển khai Smart Contracts: Sử dụng Truffle để compile và migrate ContributionContract.sol và FederationContract.sol.
  3. Cấu hình Aggregated Server: Khởi chạy server Flower tích hợp Web3.py kết nối tới RPC endpoint của Blockchain.
  4. Kích hoạt Client Daemon: Các node biên kích hoạt script flwr_client.py, liên kết địa chỉ ví Ethereum và lắng nghe tín hiệu bắt đầu round huấn luyện qua gRPC.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Phụ thuộc phí Gas mạng công khai: Nếu triển khai trên Ethereum Mainnet, chi phí gas cho mỗi round huấn luyện sẽ rất cao nếu số lượng client lên đến hàng nghìn node.
  • Rủi ro tấn công Byzantine (Poisoning Updates): Hệ thống mới xác thực được tính toàn vẹn của chuỗi băm (Data Integrity), chưa tích hợp cơ chế phát hiện tham số độc hại (Anomaly Detection/Byzantine-robust Aggregation) trước khi tổng hợp trọng số.

Hướng phát triển trong tương lai

  • Tích hợp Layer-2 Scaling: Triển khai Smart Contract trên các giải pháp Layer-2 như Arbitrum, Optimism hoặc Polygon để giảm chi phí gas xuống dưới $0.001$ USD/giao dịch.
  • Cơ chế đánh giá chất lượng đóng góp (Shapley Value): Thay vì chỉ thưởng dựa trên số lượng mẫu ($n_k$), tích hợp thuật toán tính điểm Shapley Value nhằm đo lường chính xác mức độ đóng góp làm tăng độ chính xác của từng client để phân phối phần thưởng công bằng hơn.
  • Tích hợp Zero-Knowledge Proofs (ZKP): Ứng dụng zk-SNARKs để xác minh quá trình huấn luyện cục bộ của client là trung thực mà không cần kiểm tra dữ liệu nội bộ.

Đối tượng hưởng lợi

  • Sinh viên & Học viên cao học: Nguồn tài liệu tham khảo chi tiết về cách kết nối các công nghệ giao thoa phức tạp giữa AI phân tán (Federated Learning) và Web3 (Blockchain/Smart Contracts).
  • Kỹ sư AI & Blockchain Developers: Bản thiết kế kiến trúc chuẩn (Architecture Blueprint) và mã nguồn mẫu giúp tích hợp Web3 API vào các framework học máy hiện đại.
  • Doanh nghiệp & Tổ chức dữ liệu: Giải pháp thương mại hóa dữ liệu biên hợp chuẩn pháp lý (GDPR-compliant), kích thích đối tác tham gia chia sẻ năng lực tính toán thông qua mô hình kinh tế Tokenized AI.
  • Nhà nghiên cứu khoa học: Cung cấp cơ sở thực nghiệm định lượng về hiệu năng của mô hình Hybrid FL-Blockchain trên tập dữ liệu chuẩn CIFAR-10.

Câu hỏi thường gặp

1. Yêu cầu phần cứng và môi trường để triển khai framework FlwrBC là gì?

Hệ thống yêu cầu máy chủ/máy trạm cài đặt hệ điều hành Linux (Ubuntu 20.04/22.04 LTS), tối thiểu 16GB RAM, Python 3.9+, Node.js v16+, Truffle v5.11+, Ganache CLI và kết nối mạng nội bộ ổn định hỗ trợ giao thức HTTP/2 cho gRPC.

2. Làm thế nào hệ thống ngăn chặn việc client gửi trọng số rác để nhận thưởng?

Trong phiên bản hiện tại, hệ thống ghi nhận tính bất biến của tham số thông qua hash trên chain. Để ngăn chặn hoàn toàn trọng số rác, hệ thống có thể cấu hình lớp strategy.evaluate() trên Server để kiểm thử mô hình cục bộ với một tập validation chuẩn trước khi kích hoạt hàm distributeRewards().

3. Tại sao không lưu trữ trực tiếp toàn bộ model weights lên Blockchain?

Kích thước mô hình mạng nơ-ron (DNN/CNN) thường dao động từ vài Megabytes đến hàng Gigabytes. Giới hạn Gas Limit per Block và chi phí lưu trữ cực cao của EVM khiến việc lưu trữ mảng ma trận số thực trên Blockchain là bất khả thi. FlwrBC giải quyết bằng cách chỉ lưu trữ chuỗi hash định danh trên chain và lưu toàn bộ file trọng số tại hệ thống tệp phân tán IPFS.

4. Chi phí giao dịch (Gas Fee) có làm hạn chế khả năng mở rộng của hệ thống?

Với kiến trúc hybrid của FlwrBC, các giao dịch chỉ được tạo ở đầu và cuối mỗi round huấn luyện, không phát sinh theo từng mini-batch. Khi chuyển đổi sang các mạng Layer-2 Rollups hoặc Private Consortium Chain (như Hyperledger Besu/Quorum), chi phí gas thực tế bằng 0 hoặc không đáng kể.

5. Khung tính toán phần thưởng được quy định như thế nào?

Mức chi trả được định nghĩa linh hoạt trong ContributionContract.sol. Tỷ lệ mặc định được tính theo công thức:

$$\text{Reward} = n_k \times \text{rewardPerDataPoint}$$

Doanh nghiệp có thể nạp sẵn ngân sách Ether/ERC-20 Token vào Contract Pool để hợp đồng tự động giải ngân cho client theo tiến độ hoàn thành round.

Kết luận

Khóa luận tốt nghiệp "Xây dựng thuật toán trả thưởng dựa trên công nghệ Blockchain" đã hiện thực hóa thành công mô hình FlwrBC, chứng minh tính khả thi vượt trội trong việc kết hợp giữa Học máy liên kết (Flower Framework) và Chuỗi khối (Ethereum Smart Contracts). Giải pháp không chỉ giải quyết triệt để bài toán bảo mật dữ liệu và loại bỏ điểm lỗi tập trung đơn lẻ, mà còn xây dựng cơ chế kinh tế trả thưởng minh bạch, thúc đẩy quá trình dân chủ hóa dữ liệu phục vụ đào tạo trí tuệ nhân tạo.

Mô hình đạt độ chính xác ấn tượng 86.42% trên tập CIFAR-10, chứng minh hiệu năng tiệm cận mô hình tập trung truyền thống trong khi vẫn đảm bảo tuyệt đối tính riêng tư cục bộ. Đây là tiền đề kỹ thuật vững chắc để tiếp tục mở rộng sang các hệ thống AI quy mô lớn trong các lĩnh vực Y tế, Giao thông thông minh và Tài chính phi tập trung (DeAI).