Giới thiệu dự án

Tình trạng cuộc gọi rác, cuộc gọi làm phiền và đặc biệt là cuộc gọi lừa đảo công nghệ cao đang trở thành một vấn nạn nhức nhối mang tính toàn cầu trong kỷ nguyên viễn thông số. Theo các báo cáo thống kê an ninh mạng năm 2023, hoạt động lừa đảo qua điện thoại tại Việt Nam đã gây thiệt hại ước tính lên đến 16 tỷ USD. Trên phạm vi toàn cầu, tổng số tiền thất thoát do các hình thức lừa đảo qua viễn thông và mạng Internet trong cùng năm đạt con số kỷ lục 1.026 nghìn tỷ USD, tương đương khoảng 1,05% GDP toàn cầu. Người dùng dịch vụ viễn thông không chỉ chịu tổn thất nặng nề về tài chính, lãng phí thời gian mà còn phải đối mặt với các hệ lụy tâm lý kéo dài do bị quấy rối liên tục.

Vấn đề cốt lõi (Problem Statement) nằm ở sự bất cập của các giải pháp phòng chống hiện hành:

  • Nguy cơ rò rỉ quyền riêng tư và điểm lỗi đơn lẻ (Single Point of Failure): Các ứng dụng định danh và lọc cuộc gọi phổ biến hiện nay (như Truecaller) vận hành dựa trên kiến trúc cơ sở dữ liệu tập trung. Mô hình này buộc hàng trăm triệu người dùng phải tải toàn bộ danh bạ cá nhân lên máy chủ trung tâm, dẫn đến nguy cơ bị tấn công xâm nhập dữ liệu nhạy cảm (như các sự cố lộ dữ liệu của Truecaller năm 2013 và lỗ hổng bảo mật năm 2019).
  • Thiếu tính minh bạch và bất biến: Cơ sở dữ liệu tập trung có thể bị chỉnh sửa, thao túng danh sách đen/danh sách trắng một cách đơn phương mà không có cơ chế giám sát độc lập từ cộng đồng.
  • Nút thắt cổ chai về hiệu năng của Smart Contract truyền thống: Các nghiên cứu ứng dụng blockchain trước đây (như đề xuất của Muttavarapu et al. năm 2019) triển khai trên mạng Ethereum công khai gặp phải rào cản nghiêm trọng về phí giao dịch (Gas fee) đắt đỏ và thông lượng thấp (chỉ 15–30 TPS), hoàn toàn không đáp ứng được tần suất báo cáo cuộc gọi viễn thông thực tế (đòi hỏi trên 1.000 TPS).

Mục tiêu cụ thể của đề tài:

  1. Nghiên cứu toàn diện cơ sở lý thuyết về kiến trúc mạng ngang hàng (P2P), cây Merkle, thuật toán chữ ký số ECDSA, mô hình chuỗi chéo (Cross-Chain/Polkadot) và giải bài toán Bộ ba bất khả thi (Blockchain Trilemma: Security - Decentralization - Scalability).
  2. Thiết kế và hiện thực hóa nền tảng Sentinel Platform – một hệ sinh thái phi tập trung cho phép thu thập, xác thực và truy vấn danh tính số điện thoại theo thời gian thực trên nền tảng Substrate Framework.
  3. Đề xuất và tích hợp cơ chế đồng thuận phân tán Proof-of-Spam (PoS) kết hợp hệ thống bỏ phiếu dân chủ và điểm danh tiếng (Reputation Score), trao quyền cho cộng đồng cùng xác minh dữ liệu số điện thoại lừa đảo một cách minh bạch, an toàn và chống thao túng.

Giải pháp mang lại kết quả đầu ra đo lường được: hệ thống blockchain chuyên dụng có khả năng xử lý giao dịch với độ trễ thấp (Block time ~6 giây), thông lượng giao dịch cao, bảo toàn 100% tính toàn vẹn dữ liệu cuộc gọi và đảm bảo quyền riêng tư của người dùng thông qua cơ chế mã hóa định danh phi tập trung. Phạm vi nghiên cứu tập trung vào việc thiết kế cấu trúc Runtime Blockchain (Substrate Pallets), xây dựng ứng dụng di động Sentinel DApp kết nối qua Substrate RPC Node và kiểm thử hiệu năng chịu tải trên mạng thử nghiệm.

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

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

Nghiên cứu tiến hành đánh giá so sánh các mô hình và giải pháp phòng chống cuộc gọi lừa đảo hiện có trên thị trường và trong giới học thuật:

Giải pháp Kiến trúc nền tảng Cơ chế phân loại Ưu điểm Nhược điểm & Rủi ro
Truecaller Tập trung (Centralized Server & DB) Đám đông báo cáo + Máy chủ phân tích Triển khai nhanh, UX tốt, độ trễ truy vấn thấp (<100ms). Điểm lỗi đơn lẻ; rò rỉ dữ liệu cá nhân (vụ hack 2013, lỗ hổng 2019); thiếu minh bạch trong thuật toán whitelist.
Muttavarapu et al. (2019) Blockchain công khai (Ethereum DApp) Smart Contract logic Minh bạch, dữ liệu bất biến, chống giả mạo tốt. Giới hạn thông lượng (PoW ~15 TPS), chi phí Gas fee quá cao, không mở rộng được cho tải viễn thông (cần >1.000 TPS).
Proof-of-AntiScam (Thế Duy et al., 2023) Blockchain chuyên dụng + Machine Learning PoAS Consensus (Proof of Anti-Scam) Khuyến khích cộng đồng đóng góp dữ liệu huấn luyện phát hiện website lừa đảo. Chỉ tập trung vào dữ liệu URL/IP và chụp ảnh màn hình web lừa đảo, chưa tối ưu cho dữ liệu cuộc gọi viễn thông.
Sentinel Platform (Đề tài đề xuất) Phân tán (Substrate Custom Blockchain Runtime) Proof-of-Spam Consensus + Reputation Voting Xử lý giao dịch miễn phí gas cho người dùng cuối; tùy biến Pallet logic; mở rộng chuỗi chéo qua XCM/Relay Chain. Đòi hỏi thiết lập hạ tầng node validator ban đầu; cần thời gian tích lũy dữ liệu cộng đồng ban đầu (Cold-start).

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

  • Must have (Bắt buộc): Chức năng báo cáo số điện thoại nghi vấn kèm nhãn phân loại; cơ chế bỏ phiếu cộng đồng dựa trên điểm danh tiếng; lưu trữ thông tin trạng thái số điện thoại bất biến trên chuỗi; API truy vấn nhanh danh tính số gọi đến cho ứng dụng di động.
  • Should have (Nên có): Bảng điều khiển Grafana giám sát hiệu năng node theo thời gian thực; cơ chế thưởng/phạt điểm uy tín tự động cho người tham gia biểu quyết; tích hợp chữ ký số cục bộ trên thiết bị di động.
  • Could have (Có thể có): Mở rộng tương tác chuỗi chéo qua giao thức Cross-Consensus Messaging (XCM) của Polkadot để liên kết với các Parachain khác; tích hợp AI Off-chain Worker để tiền phân tích giọng nói.
  • Won't have (Chưa hỗ trợ trong giai đoạn này): Can thiệp chặn trực tiếp cuộc gọi từ tầng phần cứng của nhà mạng viễn thông (GSM Switch Layer).

Thiết kế hệ thống

Kiến trúc tổng thể của Sentinel Platform bao gồm 3 lớp chính: Lớp giao diện người dùng (Sentinel Mobile DApp), Lớp trung gian giao tiếp (RPC Gateway) và Lớp lõi chuỗi khối (Substrate Blockchain Node Core).

+-------------------------------------------------------------------------+
|                       SENTINEL MOBILE APPLICATION                       |
|   +-----------------------+ +---------------------+ +-----------------+ |
|   | Incoming Call Tracker | | Spam Reporting UI   | | Proposal Voting | |
|   +-----------------------+ +---------------------+ +-----------------+ |
|               |                         |                    |          |
|               +------------+------------+--------------------+          |
|                            | (Local Keypair ECDSA Sign)                 |
|                            v                                            |
|                   [ Polkadot-JS / RPC Client ]                          |
+----------------------------+--------------------------------------------+
                             | JSON-RPC over WebSocket (Port 9944)
                             v
+-------------------------------------------------------------------------+
|                  SUBSTRATE CORE NODE (SENTINEL NODE)                    |
|   +-----------------------------------------------------------------+   |
|   |                       RPC & Network Layer                       |   |
|   |   - P2P Libp2p Network Engine     - Transaction Pool (Mempool)  |   |
|   +-----------------------------------------------------------------+   |
|   |                   RUNTIME (WebAssembly - WASM)                  |   |
|   |  +-------------------+  +--------------------+  +------------+  |   |
|   |  |   Pallet SCBC     |  | Pallet Validator   |  | Pallet     |  |   |
|   |  | (Spam Call Control|  |        Set         |  |Collectives |  |   |
|   |  +-------------------+  +--------------------+  +------------+  |   |
|   +-----------------------------------------------------------------+   |
|   |                      STATE STORAGE (RocksDB)                    |   |
|   |   - Merkle Patricia Trie State    - Blockchain Block Ledger     |   |
|   +-----------------------------------------------------------------+   |
|   |                   CONSENSUS ENGINE (AURA / GRANDPA)             |   |
+---+-----------------------------------------------------------------+---+

Danh mục công nghệ sử dụng (Technology Stack):

  • Ngôn ngữ lõi Runtime: Rust (v1.75-nightly), biên dịch sang WebAssembly (WASM) nhằm đảm bảo tính độc lập môi trường thực thi và khả năng nâng cấp chuỗi không cần fork (Forkless runtime upgrade).
  • Khung kiến trúc Blockchain: Substrate Framework (Polkadot SDK v0.9.43).
  • Mã hóa & Chữ ký số: ECDSA (secp256k1) và sr25519 cho định danh người dùng và xác thực khối.
  • Cơ sở dữ liệu nút mạng: RocksDB lưu trữ cấu trúc Merkle Patricia Trie.
  • Giao diện & Ứng dụng: Flutter/Dart (Mobile DApp) kết hợp thư viện Polkadot-JS API kết nối qua giao thức WebSocket JSON-RPC.
  • Giám sát hạ tầng: Prometheus & Grafana Dashboard.

Thiết kế lưu trữ trạng thái (State Storage Schema) trong Pallet SCBC:

// Cấu trúc dữ liệu số điện thoại trên chuỗi
#[derive(Clone, Encode, Decode, Eq, PartialEq, RuntimeDebug, TypeInfo, MaxEncodedLen)]
pub struct PhoneNumberRecord<AccountId, BlockNumber> {
    pub reporter: AccountId,
    pub phone_hash: [u8; 32],       // Băm số điện thoại đảm bảo quyền riêng tư
    pub report_count: u32,
    pub status: PhoneStatus,         // Pending, SpamVerified, NormalVerified
    pub reputation_score: i32,
    pub created_at: BlockNumber,
}

#[derive(Clone, Encode, Decode, Eq, PartialEq, RuntimeDebug, TypeInfo, MaxEncodedLen)]
pub enum PhoneStatus {
    Unverified,
    PendingProposal,
    SpamVerified,
    NormalVerified,
}

Các API giao dịch chính (Extrinsics & RPC Endpoints):

  • scbc.reportSpam(phone_number_hash, call_category, metadata): Gửi báo cáo số điện thoại rác/lừa đảo lên mạng P2P.
  • scbc.proposeStatusChange(phone_number_hash, target_status): Tạo đề xuất chuyển trạng thái số điện thoại sang danh sách đen.
  • scbc.voteProposal(proposal_id, approve_boolean): Thực hiện bỏ phiếu cho đề xuất dựa trên trọng số uy tín của tài khoản.
  • scbc.queryPhoneNumber(phone_number_hash): RPC endpoint đọc dữ liệu trạng thái và điểm tin cậy của số gọi đến với độ trễ thấp.

Methodology

Quy trình phát triển dự án tuân theo mô hình Agile/Scrum với 4 giai đoạn chính kéo dài 16 tuần:

  1. Sprint 1–3 (Tuần 1–6): Nghiên cứu lý thuyết Blockchain Trilemma, khảo sát Relay Chain/Parachain Polkadot, thiết kế mô hình toán học cho Proof-of-Spam.
  2. Sprint 4–6 (Tuần 7–11): Lập trình các Pallet tùy biến trên Substrate (pallet_scbc, pallet_validator_set, pallet_collectives), cấu hình cơ chế đồng thuận PoA/Aura ban đầu và logic biểu quyết.
  3. Sprint 7–8 (Tuần 12–14): Phát triển ứng dụng client (Mobile DApp), tích hợp Polkadot-JS API, xử lý ký số giao dịch ngoại tuyến (offline signing).
  4. Sprint 9 (Tuần 15–16): Triển khai mạng thử nghiệm nội bộ đa nút (Multi-node Testnet), thực hiện các kịch bản kiểm thử chịu tải (Stress test), đo lường chỉ số qua Grafana và đánh giá an toàn hệ thống.

Implementation và kết quả

Development process

Trọng tâm triển khai của đề tài là xây dựng Pallet SCBC (Spam Call Blockchain Control) và cơ chế đồng thuận Proof-of-Spam (PoS). Thuật toán xác minh dữ liệu số điện thoại lừa đảo vận hành dựa trên sự kết hợp giữa ngưỡng tối thiểu số lượng báo cáo và tỷ lệ trọng số biểu quyết danh tiếng của cộng đồng:

$$S(N) = \frac{\sum_{i=1}^{k} \left( R(u_i) \cdot V_i \right)}{\sum_{i=1}^{k} R(u_i)}$$

Trong đó:

  • $S(N)$ là điểm số đồng thuận tổng hợp cho số điện thoại $N$.
  • $R(u_i)$ là điểm uy tín (Reputation Score) của người dùng thứ $i$ tham gia bỏ phiếu.
  • $V_i \in {+1, -1}$ đại diện cho lá phiếu chấp thuận (Spam) hoặc bác bỏ (Không phải spam).
  • Nếu $S(N) \ge \theta_{threshold}$ (ngưỡng xác định, ví dụ 0.65) và số lượng phiếu $k \ge Q_{min}$ (tổng số lượng tối thiểu), trạng thái số điện thoại sẽ tự động chuyển thành SpamVerified.

Đoạn mã nguồn hiện thực logic xử lý biểu quyết trong Substrate Runtime (pallet-scbc/src/lib.rs):

#[pallet::call]
impl<T: Config> Pallet<T> {
    #[pallet::weight(10_000 + T::DbWeight::get().writes(1))]
    pub fn vote_spam_proposal(
        origin: OriginFor<T>,
        proposal_id: T::Hash,
        vote_for_spam: bool,
    ) -> DispatchResult {
        let voter = ensure_signed(origin)?;
        let mut proposal = Proposals::<T>::get(&proposal_id)
            .ok_or(Error::<T>::ProposalNotFound)?;
        
        ensure!(!VotesHistory::<T>::contains_key((&proposal_id, &voter)), Error::<T>::AlreadyVoted);
        
        let voter_reputation = UserReputations::<T>::get(&voter).unwrap_or(1);
        
        if vote_for_spam {
            proposal.yes_weight = proposal.yes_weight.saturating_add(voter_reputation);
        } else {
            proposal.no_weight = proposal.no_weight.saturating_add(voter_reputation);
        }
        
        proposal.total_votes = proposal.total_votes.saturating_add(1);
        
        // Kiểm tra điều kiện đồng thuận Proof-of-Spam
        let total_weight = proposal.yes_weight.saturating_add(proposal.no_weight);
        if total_weight >= T::MinQuorum::get() {
            let consensus_ratio = (proposal.yes_weight as f64) / (total_weight as f64);
            if consensus_ratio >= T::SpamThreshold::get() {
                PhoneRecords::<T>::mutate(&proposal.phone_hash, |record| {
                    if let Some(ref mut r) = record {
                        r.status = PhoneStatus::SpamVerified;
                    }
                });
                Self::deposit_event(Event::PhoneMarkedAsSpam(proposal.phone_hash));
            }
        }
        
        Proposals::<T>::insert(&proposal_id, proposal);
        VotesHistory::<T>::insert((&proposal_id, &voter), true);
        
        Ok(())
    }
}

Testing và validation

Hệ thống được thiết lập trên môi trường thử nghiệm bao gồm cụm 4 Node Validator Substrate và 2 RPC Node Gateway. Việc giám sát và thu thập dữ liệu được tự động hóa qua Prometheus và biểu đồ hóa bằng Grafana.

                    Hiệu năng thực thi giao dịch và độ trễ
  Request Rate (req/s) | Block Execution Time (ms) | Finalization Latency (s)
-------------------------------------------------------------------------------
         100           |          12.4 ms          |          6.0 s
         500           |          48.7 ms          |          6.1 s
        1000           |         112.5 ms          |          6.2 s
        1500           |         230.1 ms          |          6.4 s

Kết quả đo đạc từ Grafana Dashboard:

  • Thời gian tạo khối (Block Generation Time): Dao động ổn định ở mức $6.0 \pm 0.2$ giây theo cấu hình của Aura Consensus.
  • Thời gian hoàn tất giao dịch (Finalization Time): Cơ chế GRANDPA đảm bảo tính hữu hạn (Deterministic finality) chỉ sau 1 đến 2 chu kỳ khối.
  • Khả năng chịu tải (Throughput): Hệ thống duy trì sự ổn định tuyệt đối khi tải giao dịch tăng từ 100 req/s lên 1.500 req/s mà không xảy ra tình trạng rớt giao dịch trong Mempool.
  • Độ trễ truy vấn RPC: Thời gian phản hồi cho tác vụ tra cứu danh tính số điện thoại từ ứng dụng di động đạt trung bình 35ms qua mạng LAN và 85ms qua kết nối Internet di động 4G/5G, đáp ứng hoàn hảo yêu cầu hiển thị thông tin người gọi theo thời gian thực (Real-time Caller ID) trước khi người dùng nhấc máy.

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

  1. Khắc phục triệt để điểm lỗi đơn lẻ của kiến trúc tập trung: Bằng cách chuyển dịch toàn bộ cơ sở dữ liệu báo cáo sang sổ cái phân tán Substrate, Sentinel loại bỏ hoàn toàn nguy cơ máy chủ trung tâm bị tấn công chiếm quyền điều khiển hoặc làm rò rỉ dữ liệu cá nhân của người dùng viễn thông.
  2. Cơ chế đồng thuận Proof-of-Spam (PoS) độc đáo: Khác với PoW gây lãng phí năng lượng hoặc PoS tài chính thuần túy dễ bị chi phối bởi giới tài phiệt (Whales), Proof-of-Spam sử dụng chỉ số danh tiếng được tích lũy từ đóng góp chính xác trong quá khứ làm trọng số biểu quyết, ngăn chặn hiệu quả các cuộc tấn công giả mạo số lượng lớn (Sybil Attack).
  3. Loại bỏ rào cản chi phí giao dịch (Fee-less User Experience): Nhờ kiến trúc tùy biến sâu của Substrate Framework, hệ thống thiết lập mô hình miễn phí giao dịch cho người dùng phổ thông khi báo cáo số rác, đồng thời áp dụng thuật toán Rate-limiting và Staking nhẹ từ các nhà mạng/tổ chức để duy trì an ninh mạng, giải quyết triệt để bài toán kinh tế mà các giải pháp trên Ethereum không thể thực hiện.
  4. Khả năng liên kết chuỗi chéo (Cross-chain Interoperability): Thiết kế tương thích hoàn toàn với chuẩn XCM (Cross-Consensus Messaging) của Polkadot, sẵn sàng kết nối dưới dạng Parachain để chia sẻ dữ liệu danh sách đen viễn thông cho nhiều mạng blockchain khác trong tương lai.

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

Kịch bản sử dụng thực tế (Real-world Use Cases)

  • Cảnh báo cuộc gọi lừa đảo theo thời gian thực cho cá nhân: Khi có cuộc gọi đến từ số lạ, ứng dụng Sentinel tự động tính mã băm SHA-256 của số điện thoại và gửi yêu cầu truy vấn đến mạng Blockchain RPC. Nếu trạng thái trả về là SpamVerified với điểm tín nhiệm cao, màn hình cuộc gọi sẽ lập tức hiển thị cảnh báo đỏ "Nghi vấn lừa đảo tài chính/Mạo danh cơ quan chức năng".
  • Liên minh phòng chống gian lận giữa các nhà mạng viễn thông (Telecom Consortium): Các nhà mạng (Viettel, VNPT, MobiFone) có thể cùng vận hành các Validator Node độc lập. Dữ liệu số rác được chia sẻ đồng bộ liên mạng mà không bên nào có quyền đơn phương thao túng hay can thiệp vào cơ sở dữ liệu của đối thủ.
+--------------------------------------------------------------------------+
|                  YÊU CẦU PHẦN CỨNG TRIỂN KHAI HẠ TẦNG                    |
+------------------------------------+-------------------------------------+
|         VALIDATOR NODE             |            RPC GATEWAY NODE         |
+------------------------------------+-------------------------------------+
| CPU: 4 Cores (x86_64, 3.2+ GHz)    | CPU: 8 Cores (x86_64, 3.4+ GHz)     |
| RAM: 16 GB DDR4/ECC                | RAM: 32 GB DDR4                     |
| Storage: 500 GB NVMe SSD PCIe 4.0  | Storage: 1 TB NVMe SSD              |
| Network: 1 Gbps Full-duplex        | Network: 1 Gbps, CDN / Load Balancer|
| OS: Ubuntu Server 22.04 LTS        | OS: Ubuntu Server 22.04 LTS         |
+------------------------------------+-------------------------------------+

Lộ trình triển khai hệ thống (Implementation Roadmap)

  • Giai đoạn 1 (Quý 1 - 2): Khởi chạy Private Testnet giữa các đơn vị nghiên cứu; tối ưu hóa kích thước khối và thời gian sinh khối.
  • Giai đoạn 2 (Quý 3): Ra mắt phiên bản Sentinel DApp Open Beta trên Android/iOS; thử nghiệm cộng đồng với 10.000 người dùng đầu tiên.
  • Giai đoạn 3 (Quý 4): Đấu thầu slot Parachain hoặc tích hợp cầu nối Relay Chain; thiết lập liên minh dữ liệu với các tổ chức tài chính và nhà mạng viễn thông.

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

Hạn chế kỹ thuật hiện tại

  • Bài toán khởi đầu nguội (Cold-start Problem): Đối với các số điện thoại lừa đảo mới kích hoạt (SIM rác dùng một lần), hệ thống cần một khoảng thời gian trễ nhất định để thu thập đủ số lượng báo cáo và hoàn tất chu kỳ bỏ phiếu đồng thuận.
  • Rào cản về hệ điều hành di động: Trên hệ điều hành iOS, quyền can thiệp và đọc thông tin số điện thoại của cuộc gọi đến bị hạn chế nghiêm ngặt bởi chính sách quyền riêng tư của Apple so với Android.

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

  • Tích hợp học máy qua Substrate Off-chain Workers: Ứng dụng các mô hình Machine Learning phân tích mẫu số điện thoại, tần suất gọi và ngữ điệu cuộc gọi trực tiếp ngoài chuỗi (Off-chain) rồi đẩy kết quả xác thực vào chuỗi thông qua mật mã Zero-Knowledge Proofs (ZKP).
  • Mã hóa bảo vệ quyền riêng tư nâng cao: Triển khai cơ chế băm kết hợp Salt bảo mật và mã hóa đồng hình (Homomorphic Encryption) để người dùng có thể đối chiếu danh bạ mà hoàn toàn không để lộ bất kỳ thông tin số điện thoại cá nhân nào lên mạng P2P.

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

  • Người dùng dịch vụ viễn thông: Được bảo vệ an toàn trước các cuộc gọi quấy rối và bẫy lừa đảo tài chính tinh vi; toàn quyền kiểm soát thông tin cá nhân mà không lo ngại rò rỉ danh bạ.
  • Kỹ sư và nhà phát triển phần mềm: Tiếp cận mã nguồn mở mẫu về cách xây dựng Custom Substrate Pallet, tích hợp Polkadot-JS API với ứng dụng Flutter di động và kỹ thuật quản lý trạng thái phi tập trung.
  • Doanh nghiệp & Nhà mạng viễn thông: Cắt giảm chi phí vận hành các trung tâm dữ liệu lọc spam cồng kềnh; thiết lập nền tảng liên minh dữ liệu đáng tin cậy giữa các doanh nghiệp viễn thông đối thủ.
  • Cộng đồng nghiên cứu học thuật: Cung cấp mô hình thực nghiệm hoàn chỉnh giải quyết bài toán Blockchain Trilemma trong lĩnh vực an ninh mạng và viễn thông ứng dụng.

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

1. Yêu cầu kỹ thuật tối thiểu để thiết lập một Node xác thực (Validator Node) trong mạng Sentinel là gì?

Hệ thống yêu cầu máy chủ chạy hệ điều hành Ubuntu Server 22.04 LTS (hoặc các bản phân phối Linux tương đương), trang bị vi xử lý tối thiểu 4 nhân (x86_64, xung nhịp từ 3.2 GHz trở lên), 16 GB RAM DDR4 và ổ cứng thể rắn 500 GB NVMe SSD. Cổng mạng cần mở kết nối P2P (Port 30333) và RPC WebSocket (Port 9944) với băng thông đối xứng tối thiểu 100 Mbps.

2. Hệ thống xử lý thế nào trước nguy cơ tấn công Sybil (tạo hàng loạt tài khoản ảo để thao túng kết quả bỏ phiếu số rác)?

Sentinel ngăn chặn tấn công Sybil thông qua cơ chế trọng số danh tiếng (Reputation-based Weighting) của Proof-of-Spam. Tài khoản mới tạo có điểm uy tín mặc định ở mức sàn ($R=1$) và bị giới hạn số lần biểu quyết trong một chu kỳ khối. Điểm uy tín chỉ gia tăng khi các báo cáo trước đó được mạng lưới đồng thuận xác thực là chính xác. Nếu phát hiện hành vi bỏ phiếu sai lệch có chủ đích, điểm uy tín sẽ bị trừ nặng hoặc khóa quyền biểu quyết.

3. Tốc độ tra cứu thông tin số điện thoại có đủ nhanh khi có cuộc gọi đến hay không?

Có. Nhờ thiết kế tách biệt giữa lớp đồng thuận ghi khối (Write-path) và lớp truy vấn bộ nhớ RocksDB đã lập chỉ mục (Read-path qua RPC), thời gian phản hồi tra cứu của Sentinel chỉ mất từ 30ms đến 80ms, đảm bảo thông tin cảnh báo xuất hiện ngay tức thì khi chuông điện thoại vừa reo.

4. Chi phí vận hành và bảo trì mạng lưới Blockchain Sentinel được duy trì như thế nào?

Mạng lưới áp dụng mô hình phân bổ phí duy trì từ quỹ ngân sách cộng đồng (Treasury) được tài trợ bởi các tổ chức tham gia liên minh viễn thông/ngân hàng (những đơn vị hưởng lợi trực tiếp từ việc giảm thiểu gian lận mạo danh). Ngoài ra, các Validator Node duy trì khối sẽ nhận được phần thưởng khối (Block Rewards) theo tỷ lệ đóng góp năng lực tính toán.

5. Dữ liệu số điện thoại lưu trên Blockchain có vi phạm quy định bảo vệ dữ liệu cá nhân (như GDPR hay Nghị định 13/2023/NĐ-CP) không?

Không. Hệ thống hoàn toàn không lưu trữ số điện thoại dưới dạng chuỗi văn bản thuần (Plaintext). Mọi số điện thoại trước khi đưa lên mạng lưới đều được băm bằng thuật toán SHA-256 một chiều kết hợp khóa bảo mật cục bộ, do đó không thể giải mã ngược lại để tìm ra số điện thoại gốc nếu không sở hữu thông tin đầu vào.

Kết luận

Đồ án tốt nghiệp "Phát triển giải pháp chống cuộc gọi lừa đảo trên nền tảng Blockchain với cơ chế đồng thuận Proof-of-Spam" của nhóm tác giả Nguyễn Anh Tài và Trần Thế Anh (Trường Đại học Công nghệ Thông tin – ĐHQG-HCM) đã giải quyết thành công bài toán bảo mật và minh bạch trong phòng chống gian lận viễn thông. Bằng việc làm chủ công nghệ Substrate Framework và sáng tạo cơ chế Proof-of-Spam, nghiên cứu không chỉ đưa ra giải pháp kỹ thuật có tính thực tiễn cao mà còn mở ra hướng đi mới trong việc ứng dụng công nghệ chuỗi khối phi tài chính nhằm bảo vệ an toàn thông tin cho hàng triệu người dùng trong thời đại số.