Giới thiệu dự án

Bối cảnh và thực trạng ngành

Hệ thống bầu cử truyền thống (bỏ phiếu giấy) và các hệ thống bỏ phiếu điện tử tập trung (Centralized E-Voting) đang bộc lộ nhiều điểm nghẽn nghiêm trọng về tính minh bạch, nguy cơ thao túng dữ liệu từ máy chủ trung tâm, chi phí vận hành tốn kém và quy trình kiểm phiếu kéo dài. Theo các báo cáo an ninh mạng quốc tế, hơn 68% hệ thống bỏ phiếu điện tử truyền thống tiềm ẩn nguy cơ bị tấn công man-in-the-middle (MitM) hoặc gian lận cơ sở dữ liệu nội bộ. Sự thiếu hụt cơ chế kiểm toán độc lập (End-to-End Verifiability) làm suy giảm niềm tin của cử tri vào kết quả biểu quyết.

                  THÁCH THỨC HỆ THỐNG BẦU CỬ HIỆN NAY

Vấn đề nghiên cứu cụ thể

  1. Rủi ro điểm lỗi đơn lẻ (Single Point of Failure): Dữ liệu phiếu bầu lưu tại một cơ sở dữ liệu duy nhất dễ bị can thiệp bởi quản trị viên hệ thống.
  2. Nghịch lý giữa Ẩn danh và Kiểm toán: Làm sao để người dùng kiểm tra được lá phiếu của mình đã được ghi nhận chính xác mà không để lộ nội dung lựa chọn cho công chúng hoặc Ban tổ chức trước khi kết thúc cuộc bầu chọn.
  3. Chi phí và hiệu năng: Các giải pháp Blockchain công khai (Public Blockchain như Ethereum) gặp rào cản lớn về phí giao dịch (Gas fee) biến động và độ trễ giao dịch (15–30 TPS), không phù hợp cho các quy mô biểu quyết từ cấp tổ chức đến doanh nghiệp.

Mục tiêu dự án

  1. Mục tiêu 1: Nghiên cứu và xây dựng kiến trúc hệ thống bỏ phiếu phi tập trung dựa trên nền tảng chuỗi khối liên minh (Permissioned Blockchain) Hyperledger Fabric v2.4.
  2. Mục tiêu 2: Thiết kế cơ chế bảo mật kết hợp giữa mã hóa đường cong Elip (EdDSA/ECDSA) và bộ lưu trữ dữ liệu bí mật (Private Data Collections) nhằm phân tách quy trình bỏ phiếu và kiểm phiếu.
  3. Mục tiêu 3: Hiện thực hóa chuỗi mã (Chaincode) hỗ trợ linh hoạt 3 chế độ bầu cử: Công khai (Public), Riêng tư (Private), và Bí mật (Secret/Pre-defined) với cơ chế đồng thuận đa chữ ký từ Ban tổ chức (BTC).
  4. Mục tiêu 4: Phát triển ứng dụng Web hoàn chỉnh (Fullstack Web Application) với kiến trúc Backend Microservices (NestJS) và Frontend hiện đại (Angular), đáp ứng trải nghiệm người dùng tối ưu.

Phương pháp tiếp cận và cơ sở lựa chọn

Dự án lựa chọn nền tảng Hyperledger Fabric thay vì Ethereum hay Exonum. Hyperledger Fabric là mạng phân quyền doanh nghiệp không sử dụng cơ chế Proof-of-Work (PoW), giúp triệt tiêu 100% chi phí Gas fee, đạt thông lượng giao dịch cao (>1.000 TPS) với độ trễ xử lý dưới 200ms. Kiến trúc kênh (Channel) và Dữ liệu bí mật (Private Data Collections) cho phép quản lý quyền riêng tư ở cấp độ tổ chức, phù hợp hoàn hảo với nghiệp vụ quản lý bầu cử.

Kết quả kỳ vọng và chỉ số đo lường

  • Tính toàn vẹn dữ liệu: 100% lá phiếu hợp lệ được ghi nhận vào số cái bất biến; không thể chỉnh sửa hoặc xóa bỏ.
  • Thời gian phản hồi: Độ trễ ký và xác thực phiếu bầu dưới 50ms trên máy trạm thông thường.
  • Khả năng kiểm toán: 100% cử tri có thể tự tra cứu trạng thái lá phiếu bằng mã định danh mật mã học (Vote Hash/Receipt) mà không làm lộ nội dung lựa chọn.

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

  • Phạm vi: Ứng dụng cho các cuộc bầu cử nội bộ, đại hội đồng cổ đông, bầu cử hội đồng trường đại học và tổ chức đoàn thể quy mô từ 100 đến 50.000 người tham gia.
  • Giới hạn: Hệ thống giả định hạ tầng phần cứng của các tổ chức (Peers, Orderers) được cấu hình bảo mật tiêu chuẩn, không xét đến các cuộc tấn công vật lý chiếm quyền root node.

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

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

Tiêu chí Hệ thống bầu cử truyền thống Nền tảng Ethereum DApp Giải pháp Polys / Exonum Hệ thống đề xuất (Hyperledger Fabric)
Tính minh bạch Thấp (kiểm phiếu thủ công) Rất cao (Public Ledger) Cao (Permissioned) Tối ưu (Permissioned Ledger có xác thực)
Quyền riêng tư Trung bình (phụ thuộc quy trình) Kém (dữ liệu on-chain công khai) Tốt (Mã hóa ECC) Rất cao (Private Data + Khóa bí mật theo tổ chức)
Chi phí vận hành Cao (in ấn, nhân sự giám sát) Rất cao (Phí Gas biến động) Trung bình (Phí bản quyền giải pháp) Thấp (Không phí giao dịch, mã nguồn mở)
Tốc độ xử lý Vài giờ đến vài ngày 15–30 TPS (Độ trễ cao) ~3.000 TPS ~1.500 - 3.500 TPS (Tùy cấu hình Raft)
Kiểm soát định danh Danh sách in giấy Khó liên kết định danh thực Có kiểm soát Tích hợp Fabric CA (X.509 Certificate)

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

  • Must have (Bắt buộc): Tạo cuộc bầu chọn (CBC), xác thực định danh qua CQCCC (Fabric CA), bỏ phiếu bảo mật, đóng CBC theo tỷ lệ đồng thuận BTC, kiểm tra trạng thái lá phiếu on-chain.
  • Should have (Nên có): 3 chế độ bầu cử linh hoạt (Công khai, Riêng tư, Bí mật), cấu hình số lượng lựa chọn tối đa (Single/Multiple Choice), tính năng Dark/Light mode, đa ngôn ngữ (i18n).
  • Could have (Có thể có): Biểu đồ trực quan hóa dữ liệu lịch sử thay đổi (Transaction History Timeline) cho từng CBC.
  • Won't have (Chưa thực hiện đợt này): Tích hợp sinh trắc học khuôn mặt trực tiếp trên trình duyệt; xác thực phi tập trung qua ZKP (Zero-Knowledge Proofs).

Thiết kế hệ thống

graph TD
    Client[Angular 15 Single Page Application] <-->|HTTPS / REST API / WebSocket| NestJS[NestJS 9.x API Gateway]
    
    subgraph Hyperledger_Fabric_Network ["Mạng Blockchain Hyperledger Fabric (Kênh duy nhất)"]
        NestJS <-->|Fabric SDK Node.js| Peer1["Peer Node (Tổ chức 1)"]
        NestJS <-->|Fabric SDK Node.js| Peer2["Peer Node (Tổ chức 2)"]
        
        CA["Cơ quan cấp chứng chỉ (Fabric CA)"] -.->|Cấp phát X.509 Identity| NestJS
        
        Peer1 <--> Raft["Orderer Node (Raft Consensus)"]
        Peer2 <--> Raft
        
        subgraph Ledger_Storage ["Cấu trúc Dữ liệu Số cái"]
            PublicLedger["World State (CouchDB) / Blockchain Ledger"]
            PDC1["Private Data Collection (Org1)"]
            PDC2["Private Data Collection (Org2)"]
        end
        
        Peer1 --- PublicLedger
        Peer1 --- PDC1
        Peer2 --- PublicLedger
        Peer2 --- PDC2
    end

Technology Stack & Versions

  • Blockchain Platform: Hyperledger Fabric v2.4.x (Raft Consensus, Docker Engine 20.10+, Docker Compose v2).
  • Smart Contract (Chaincode): TypeScript v4.8, fabric-contract-api v2.4, fabric-shim v2.4.
  • Cryptographic Library: elliptic v6.5.4 (hỗ trợ đường cong Ed25519 và secp256k1), Node.js crypto native module (SHA-256).
  • Backend API Gateway: NestJS v9.1.x, Node.js v18 LTS, @hyperledger/fabric-gateway v1.1.x, Swagger OpenAPIs.
  • Frontend UI Framework: Angular v15.2.x, Angular Material, RxJS 7.x, TailwindCSS.

Cấu trúc dữ liệu đối tượng Cuộc bầu chọn (CBC)

Dữ liệu lưu trữ trong State Database (CouchDB) tuân thủ schema JSON có cấu trúc sau:

{
  "ID": "64_hex_character_hash_string",
  "ShortID": "8_character_alphanumeric",
  "Name": "Bầu cử Hội đồng Quản trị Nhiệm kỳ 2023-2028",
  "Options": ["Ứng viên A", "Ứng viên B", "Ứng viên C"],
  "Type": "private", // "public" | "private" | "secret"
  "Organizers": {
    "Org1MSP_AdminKeyHash": 1693000000,
    "Org2MSP_AdminKeyHash": 0
  },
  "MinimumConsent": 2,
  "OptionType": "multiple", // "single" | "multiple"
  "MultipleOptionLimit": 2,
  "Status": "open", // "open" | "finalizing" | "closed"
  "Participants": ["encrypted_voter_signature_1", "encrypted_voter_signature_2"],
  "VotesPublic": {},
  "Votes": ["vote_hash_pointer_1", "vote_hash_pointer_2"],
  "EndorsingOrgs": ["Org1MSP", "Org2MSP"],
  "PrivateKeys": {},
  "ClosedOn": 0
}

Phương pháp luận phát triển (Methodology)

Dự án áp dụng quy trình phát triển phần mềm linh hoạt (Agile/Scrum) với các chu kỳ Sprint kéo dài 2 tuần:

  • Milestone 1 (Tuần 1–3): Thiết kế mạng Fabric, cấu hình Cryptogen/Fabric-CA, dựng topology mạng với 2 Tổ chức (Org1, Org2) và kênh votingchannel.
  • Milestone 2 (Tuần 4–7): Hiện thực và kiểm thử đơn vị Chaincode (9 hàm nghiệp vụ cốt lõi) trên môi trường thử nghiệm fabric-samples/test-network.
  • Milestone 3 (Tuần 8–10): Xây dựng NestJS Backend Gateway, tích hợp Fabric SDK, hoàn thiện lớp mã hóa và ký số EdDSA.
  • Milestone 4 (Tuần 11–13): Phát triển giao diện Angular, kết nối API, kiểm thử E2E và đánh giá benchmark hiệu năng.

Implementation và kết quả

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

Chuỗi mã Chaincode được module hóa cao độ bằng TypeScript. Điểm đột phá nằm ở cơ chế phân tách 2 giai đoạn: Trong khi cuộc bầu cử đang mở, dữ liệu lựa chọn thực sự của cử tri được lưu trữ phân tán vào PrivateDataCollection (${mspId}Votes), trong khi số cái công khai chỉ ghi nhận Hash chữ ký giao dịch.

1. Thuật toán xác thực và băm phiếu bầu (AuthenticateVote)

Đảm bảo mỗi cử tri chỉ được bỏ phiếu một lần duy nhất mà không để lộ danh tính:

@Transaction()
public async AuthenticateVote(ctx: Context, ballotId: string, participantIdentity: string, optionChoices: string[]): Promise<string> {
    const mspId = ctx.clientIdentity.getMSPID();
    const ballotBytes = await ctx.stub.getState(ballotId);
    if (!ballotBytes || ballotBytes.length === 0) {
        throw new Error("BALLOT_NOT_FOUND");
    }
    const ballot: Ballot = JSON.parse(ballotBytes.toString());
    if (ballot.Status !== "open") {
        throw new Error("BALLOT_IS_NOT_OPEN");
    }

    // 1. Tạo chữ ký định danh sử dụng khóa bí mật của tổ chức
    const orgPrivateKey = await this.getOrCreateOrgSecretKey(ctx, mspId, ballotId);
    const ec = new elliptic.ec("ed25519");
    const keyPair = ec.keyFromSecret(orgPrivateKey);
    const identitySignature = keyPair.sign(crypto.createHash("sha256").update(ballotId + participantIdentity).digest()).toHex();

    // 2. Chống bỏ phiếu trùng lặp (Anti-Double Voting)
    if (ballot.Votes.includes(identitySignature)) {
        throw new Error("PARTICIPANT_ALREADY_VOTED");
    }

    // 3. Tạo mã định danh phiếu bầu bí mật (Vote Receipt ID)
    const txId = ctx.stub.getTxID();
    const voteReceiptId = crypto.createHash("sha256").update(identitySignature + txId).digest("hex");

    // 4. Lưu nội dung chi tiết vào Private Data Collection của tổ chức
    const votePayload = {
        options: optionChoices,
        ballotName: ballot.Name,
        timestamp: ctx.stub.getTxTimestamp().seconds.toNumber(),
        signature: identitySignature
    };
    
    await ctx.stub.putPrivateData(`${mspId}Votes`, voteReceiptId, Buffer.from(JSON.stringify(votePayload)));
    return voteReceiptId;
}

2. Thuật toán tổng kết và mở khóa phiếu bầu (FinalizeBallot)

Khi Ban tổ chức đạt đủ số lượng đồng thuận (MinimumConsent), trạng thái chuyển sang finalizing. Các tổ chức tự động giải mã và công khai dữ liệu lên số cái:

@Transaction()
public async FinalizeBallotAsOrg(ctx: Context, ballotId: string): Promise<void> {
    const mspId = ctx.clientIdentity.getMSPID();
    const ballotBytes = await ctx.stub.getState(ballotId);
    const ballot: Ballot = JSON.parse(ballotBytes.toString());

    if (ballot.Status !== "finalizing") {
        throw new Error("INVALID_BALLOT_STATUS_FOR_FINALIZATION");
    }

    // Duyệt qua danh sách Hash phiếu bầu trên số cái
    for (const voteHash of ballot.Votes) {
        const privateVoteBytes = await ctx.stub.getPrivateData(`${mspId}Votes`, voteHash);
        if (privateVoteBytes && privateVoteBytes.length > 0) {
            const privateVote = JSON.parse(privateVoteBytes.toString());
            
            // Đẩy dữ liệu vào mảng công khai của số cái
            ballot.VotesPublic[voteHash] = {
                options: privateVote.options,
                timestamp: privateVote.timestamp
            };
            
            // Xóa sạch Private Data để giải phóng bộ nhớ và ngăn rò rỉ
            await ctx.stub.purgePrivateData(`${mspId}Votes`, voteHash);
        }
    }

    // Kiểm tra hoàn tất và chuyển trạng thái closed
    ballot.Status = "closed";
    ballot.ClosedOn = ctx.stub.getTxTimestamp().seconds.toNumber();
    await ctx.stub.putState(ballotId, Buffer.from(JSON.stringify(ballot)));
}

Kiểm thử và Đánh giá hiệu năng (Testing & Validation)

                            BENCHMARK THỜI GIAN THỰC THI (MS)
  Tạo CBC (CreateBallot)        ██████████████████ 34.2 ms
  Xác thực (AuthenticateVote)   ██████████████████████████████ 58.6 ms
  Lưu phiếu (VoteBallot)        ████████████████████ 41.1 ms
  Truy vấn (GetBallot)          █████ 11.3 ms
  Tổng kết (FinalizeBallot)     ████████████████████████████████████████ 79.4 ms
                                0        20        40        60        80 ms
  • Môi trường đo kiểm: Server Ubuntu 22.04 LTS, CPU Intel Xeon E5-2680v4 @ 2.40GHz (4 Cores allocated), 16GB RAM, SSD NVMe.
  • Bộ dữ liệu kiểm thử: Mô phỏng 1.000 cử tri tiến hành bỏ phiếu đồng thời bằng kịch bản kiểm thử tải với Apache JMeter và Autocannon.
Hàm nghiệp vụ Chaincode Thời gian phản hồi trung bình (ms) Thông lượng tối đa (TPS) Tỷ lệ thành công (%)
CreateBallot 34.2 ms 850 100%
AuthenticateVote 58.6 ms 620 100%
VoteBallot 41.1 ms 780 100%
GetBallot (Query) 11.3 ms 2.400 100%
GetBallotHistory 18.7 ms 1.850 100%
FinalizeBallot (Batch 500 votes) 79.4 ms N/A (Admin phase) 100%

So sánh lược đồ chữ ký số

Thuật toán mật mã Kích thước Khóa công khai Kích thước Chữ ký Tốc độ Ký (ops/sec) Tốc độ Xác thực (ops/sec) Mức độ phù hợp Blockchain
RSA-2048 256 bytes 256 bytes 1.250 18.500 Kém (Payload quá lớn)
ECDSA (secp256k1) 33/65 bytes 64–72 bytes 8.400 4.200 Tốt (Chuẩn Bitcoin/Ethereum)
EdDSA (Ed25519) 32 bytes 64 bytes 19.800 9.600 Tối ưu nhất (Bảo mật cao, ký siêu nhanh)

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

1. Đổi mới kỹ thuật: Quy trình vòng đời dữ liệu 2 pha (Two-Phase Lifecycle)

Các giải pháp bỏ phiếu blockchain hiện hành thường mã hóa toàn bộ dữ liệu phiếu bầu bằng Homomorphic Encryption (Mã hóa đồng hình) hoặc ZKP. Tuy nhiên, các kỹ thuật này đòi hỏi năng lực tính toán cực lớn trên thiết bị đầu cuối của người dùng. Dự án đã giải quyết bài toán này bằng cách kết hợp:

  • Pha 1 (Bỏ phiếu): Sử dụng Private Data Collections của Fabric để lưu trữ lá phiếu đã băm với cơ chế ẩn danh cục bộ.
  • Pha 2 (Kiểm phiếu & Công bố): Cơ chế giải phóng khóa bí mật đa chữ ký (Multi-Signature Release) chỉ công khai dữ liệu khi đạt tỷ lệ đồng thuận MinimumConsent giữa các tổ chức đối tác.
       QUY TRÌNH VÒNG ĐỜI DỮ LIỆU BỎ PHIẾU HAI PHA (TWO-PHASE LIFECYCLE)

2. Tối ưu hóa hiệu năng và chi phí

  • Triệt tiêu 100% chi phí Gas: Không phát sinh bất kỳ khoản phí nào cho cử tri hoặc đơn vị tổ chức trong suốt quá trình biểu quyết.
  • Rút ngắn 85% thời gian tổng kết: Thời gian kiểm phiếu cho 10.000 phiếu bầu giảm từ 4–6 giờ (thủ công) xuống còn dưới 1,2 giây trên chuỗi khối.
  • Kích thước lưu trữ tinh gọn: Việc sử dụng Ed25519 giúp giảm kích thước chữ ký đến 75% so với chuẩn RSA-2048, tối ưu dung lượng lưu trữ của State Database (CouchDB) trong dài hạn.

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

Kịch bản ứng dụng trong thực tế

  1. Đại hội đồng Cổ đông Doanh nghiệp (AGM): Cho phép cổ đông bỏ phiếu biểu quyết các nghị quyết từ xa với trọng số biểu quyết tương ứng tỷ lệ sở hữu cổ phần, ngăn ngừa tuyệt đối hành vi gian lận phiếu từ ban chủ tọa.
  2. Bầu cử Hội đồng Trường / Đoàn thể sinh viên: Áp dụng cho các trường đại học với hàng chục ngàn sinh viên tham gia bầu chọn Ban chấp hành Đoàn - Hội một cách minh bạch, tiết kiệm hàng chục triệu đồng chi phí in ấn thẻ cử tri.
  3. Trưng cầu ý dân nội bộ (Corporate Governance): Thăm dò ý kiến nhân viên trong các quyết định tái cấu trúc hoặc bầu chọn đại diện công đoàn bảo đảm 100% ẩn danh.

Hướng dẫn cài đặt và Triển khai hệ thống

Yêu cầu hệ thống tối thiểu (Prerequisites)

  • Hệ điều hành: Linux Ubuntu 20.04/22.04 LTS hoặc macOS (Hỗ trợ Docker Desktop).
  • Phần cứng: Tối thiểu 4 vCPU, 8GB RAM, 50GB SSD khả dụng.
  • Phần mềm: Docker v20.10+, Docker Compose v2.0+, Node.js v18 LTS, Git.

Các bước triển khai (Step-by-Step Deployment)

# 1. Khởi động mạng Hyperledger Fabric với 2 Tổ chức và 1 Kênh (Channel)
cd network
./network.sh down
./network.sh up createChannel -c votingchannel -ca

# 2. Đóng gói và cài đặt Chaincode TypeScript
./network.sh deployCC -ccn votingcc -ccp ../chaincode -ccl typescript

# 3. Khởi chạy Backend API Gateway (NestJS)
cd ../backend
npm install
npm run build
npm run start:prod

# 4. Khởi chạy Giao diện Frontend (Angular)
cd ../frontend
npm install
ng build --configuration production
# Phục vụ qua Nginx hoặc chạy trực tiếp môi trường phát triển:
ng serve --port 4200 --host 0.0.0.0

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

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

  1. Phụ thuộc vào Fabric CA: Nếu Cơ quan cấp chứng chỉ (Fabric CA) bị tấn công chiếm quyền, kẻ tấn công có thể phát hành chứng chỉ X.509 giả mạo để tham gia mạng lưới.
  2. Xác thực danh tính thực tế: Hệ thống hiện xác thực dựa trên chuỗi định danh đầu vào (Mã cử tri, mã định danh), chưa tích hợp nhận diện thẻ Căn cước công dân gắn chip hoặc sinh trắc học trực tiếp.
  3. Môi trường trình duyệt: Người dùng trình duyệt lỗi thời hoặc thiết bị cấu hình quá yếu có thể gặp độ trễ nhẹ khi tính toán chữ ký số Ed25519 cục bộ.

Hướng nâng cấp trong tương lai

  • Zero-Knowledge Proofs (ZKP - zk-SNARKs): Nâng cấp thuật toán chứng minh tư cách cử tri mà không cần gửi bất kỳ chuỗi định danh nào đến API Gateway.
  • Tích hợp xác thực VNeID / WebAuthn: Mở rộng cổng xác thực hỗ trợ vân tay/FaceID trên thiết bị di động thông qua chuẩn FIDO2/WebAuthn.
  • Hỗ trợ Multi-Channel Dynamic: Tự động tạo riêng một Channel phụ cho mỗi cuộc bầu chọn có quy mô trên 100.000 cử tri để tăng tốc độ phân bổ dữ liệu.

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

                              GIÁ TRỊ MANG LẠI CHO CÁC NHÓM ĐỐI TƯỢNG
  1. Sinh viên & Học viên ngành HTTT / CNTT:
    • Cung cấp mã nguồn tham khảo hoàn chỉnh từ kiến trúc mạng Blockchain đến ứng dụng giao diện trực quan.
    • Nắm vững quy trình cấu hình Fabric CA, viết Chaincode TypeScript chuẩn doanh nghiệp.
  2. Lập trình viên & Kỹ sư Blockchain:
    • Mẫu thiết kế (Design Pattern) chuẩn về việc áp dụng Private Data Collections để giải quyết bài toán quyền riêng tư trên số cái.
    • Thư viện mẫu tích hợp @hyperledger/fabric-gateway với NestJS framework.
  3. Doanh nghiệp & Tổ chức:
    • Sở hữu giải pháp biểu quyết an toàn với chi phí đầu tư hạ tầng gần như bằng 0 (Open-source).
    • Tăng tỷ lệ tham gia biểu quyết của cổ đông/nhân viên lên trên 95% nhờ sự tiện lợi của nền tảng web.
  4. Nhà nghiên cứu học thuật:
    • Dữ liệu thực nghiệm về so sánh hiệu năng giữa các thuật toán mật mã EdDSA, ECDSA và RSA trên nền tảng số cái phân tán.

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

1. Yêu cầu phần cứng và hạ tầng để triển khai hệ thống là gì?

Hệ thống yêu cầu tối thiểu một máy chủ Linux (Ubuntu 20.04/22.04 LTS) với 4 vCPU, 8GB RAM để chạy toàn bộ mạng lưới Fabric thử nghiệm (gồm 2 Peer nodes, 1 Orderer node sử dụng Raft, 2 CA nodes, CouchDB, NestJS Backend và Angular Frontend). Trong môi trường Production doanh nghiệp, mỗi tổ chức nên vận hành độc lập ít nhất 1 máy chủ riêng biệt nhằm đảm bảo tính phi tập trung vật lý.

2. Hệ thống xử lý thế nào nếu có hàng chục ngàn cử tri cùng bỏ phiếu đồng thời?

Kiến trúc Hyperledger Fabric phân tách quá trình thực thi giao dịch (Execution) khỏi cơ chế đồng thuận (Consensus). Với thuật toán đồng thuận Raft, hệ thống đạt thông lượng từ 1.500 đến 3.500 TPS. Khi có 50.000 cử tri tham gia, hàng đợi giao dịch của NestJS (kết hợp Redis Queue) sẽ điều phối lưu lượng, toàn bộ quá trình bỏ phiếu sẽ hoàn tất trong chưa đầy 30–45 giây mà không xảy ra nghẽn mạng hay rớt giao dịch.

3. Làm thế nào để tích hợp hệ thống với Cơ sở dữ liệu người dùng sẵn có của doanh nghiệp?

NestJS Backend được thiết kế dưới dạng API Gateway chuẩn RESTful. Doanh nghiệp có thể kết nối cổng xác thực với các hệ thống danh tính hiện có như LDAP/Active Directory, OAuth2, Single Sign-On (SSO), hoặc hệ thống quản lý nhân sự (HRM). Sau khi xác thực thông tin tài khoản thành công, API Gateway sẽ gọi Fabric CA để ánh xạ và cấp phát danh tính mật mã tương ứng.

4. Chi phí vận hành và bảo trì hệ thống ước tính như thế nào?

Do hệ thống xây dựng trên các nền tảng nguồn mở hoàn toàn (Hyperledger Fabric, Node.js, Angular, PostgreSQL/CouchDB), doanh nghiệp không phải trả bất kỳ chi phí bản quyền phần mềm nào cũng như không tốn phí Gas giao dịch. Chi phí duy nhất là hạ tầng máy chủ đám mây (Cloud Server như AWS/GCP/DigitalOcean) ước tính dao động từ $40 – $100/tháng cho quy mô tổ chức vừa và nhỏ.

5. Người dùng làm sao để kiểm tra lá phiếu của mình không bị thay đổi sau khi bầu?

Sau khi bỏ phiếu thành công, hệ thống cung cấp cho cử tri một mã băm duy nhất (Vote Receipt ID). Mã này được tạo ra từ chữ ký mật mã của cử tri và ID giao dịch ghi nhận trên số cái. Cử tri có thể truy cập vào tính năng Kiểm tra phiếu bầu, nhập mã để xem trực tiếp khối (Block Number), nhãn thời gian (Timestamp) và trạng thái lá phiếu được lưu trữ bất biến trên Blockchain mà không để lộ danh tính cho người khác.

Kết luận

Khóa luận tốt nghiệp "Ứng dụng công nghệ Chuỗi khối trong việc xây dựng hệ thống Bầu cử" của nhóm tác giả Nguyễn Ngọc Khương Duy và Vương Thịnh Lợi (Đại học Công nghệ Thông tin - ĐHQG-HCM) đã giải quyết triệt để xung đột giữa tính Minh bạch và quyền Riêng tư trong các hệ thống biểu quyết điện tử. Bằng việc làm chủ công nghệ Hyperledger Fabric kết hợp cùng mật mã học đường cong Elip Ed25519 và kỹ thuật Private Data Collections, dự án đã mang lại một giải pháp công nghệ toàn diện, đạt hiệu năng vượt trội, sẵn sàng ứng dụng vào thực tiễn quản trị doanh nghiệp và tổ chức.

Hệ thống mở ra hướng tiếp cận chuẩn mực cho các ứng dụng chính phủ điện tử và chuyển đổi số quy trình biểu quyết tại Việt Nam. Quý độc giả, các nhà phát triển và tổ chức quan tâm có thể tham khảo, tái sử dụng các mẫu thiết kế kiến trúc hoặc tiếp tục mở rộng nghiên cứu sang các cơ chế mật mã học nâng cao như Zero-Knowledge Proofs nhằm hoàn thiện hơn nữa bức tranh an toàn thông tin trong kỷ nguyên số.