Giới thiệu dự án

Trong bối cảnh chuyển đổi số giáo dục đang diễn ra mạnh mẽ, việc bảo đảm tính minh bạch, toàn vẹn và chống gian lận trong quản lý học vụ – đặc biệt là quản lý điểm số – trở thành ưu tiên hàng đầu. Các hệ thống quản trị dữ liệu truyền thống (RDBMS) bộc lộ nhiều lỗ hổng về nguy cơ can thiệp cơ sở dữ liệu nội bộ và tấn công đơn điểm (Single Point of Failure). Sự xuất hiện của công nghệ chuỗi khối (Blockchain) và hợp đồng thông minh (Smart Contract - SMC) trên nền tảng Web 3.0 mang đến một giải pháp kiến trúc phi tập trung, đảm bảo tính bất biến (Immutability) và minh bạch tuyệt đối.

Tuy nhiên, rào cản lớn nhất khi triển khai các ứng dụng phi tập trung (Decentralized Applications - DApps) trong giáo dục là chi phí Gas (phí thực thi giao dịch trên máy ảo EVM - Ethereum Virtual Machine). Mỗi thao tác ghi dữ liệu, phân quyền hoặc cập nhật bảng điểm đều tiêu tốn một lượng tài nguyên tính toán nhất định được định giá bằng đơn vị Gas và quy đổi thành Ether (ETH). Nếu mã nguồn hợp đồng thông minh không được thiết kế tối ưu, chi phí giao dịch cho hàng nghìn sinh viên sẽ tăng theo cấp số nhân, khiến dự án mất tính khả thi về mặt kinh tế.

Vấn đề cốt lõi: 
Cấu trúc dữ liệu chưa tối ưu + Thao tác ghi trạng thái (SSTORE) lặp lại 
==> Chi phí Gas bùng nổ ==> DApp giáo dục không thể mở rộng quy mô.

Mục tiêu dự án

  1. Khảo sát và hệ thống hóa các kỹ thuật tối ưu hóa mã nguồn Solidity trên nền tảng Ethereum Virtual Machine.
  2. Xây dựng DApp quản lý môn học và điểm số hoạt động phi tập trung 100%, tích hợp cơ chế xác thực và phân quyền bằng ví điện tử MetaMask.
  3. Thực nghiệm đo lường định lượng mức độ tiêu hao Gas của từng kỹ thuật tối ưu hóa chuyên biệt (Mapping, Bytes32, Uint256, Compiler Optimizer, Batching) trên hai môi trường mạng Ganache (Local EVM) và Sepolia (Ethereum Testnet).
  4. Xây dựng mô hình tham chiếu chuẩn hóa giúp các nhà phát triển phần mềm Web3 giảm thiểu chi phí phát triển và vận hành hệ thống quản lý học vụ.

Phương pháp tiếp cận giải pháp

Đề tài tiếp cận bài toán tối ưu hóa thông qua phân tích cơ chế vận hành của các mã lệnh (Opcodes) bên dưới tầng máy ảo EVM. Bằng cách tái cấu trúc bộ nhớ lưu trữ (Storage Layout), thay thế kiểu dữ liệu động tốn kém bằng kiểu dữ liệu nhị phân cố định, khai thác cơ chế nén giao dịch theo lô (Batch Processing) và tinh chỉnh tham số biên dịch (Solc Optimizer Runs), hệ thống đạt được hiệu suất vượt trội mà không làm suy giảm tính an toàn hay logic nghiệp vụ.

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

  • Chi phí triển khai (Deployment Gas): Giảm từ 75% đến gần 85% so với phiên bản chưa tối ưu.
  • Chi phí thao tác (Execution Gas): Giảm đến 89% đối với các giao dịch thêm, sửa, xóa và phân quyền.
  • Khả năng mở rộng: Cho phép nhập dữ liệu theo lô lên đến 150 bản ghi điểm thi trong một giao dịch duy nhất mà không vượt quá giới hạn Block Gas Limit.

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

  • Phạm vi nghiên cứu: Tập trung vào tối ưu hóa mã nguồn Smart Contract viết bằng ngôn ngữ Solidity chạy trên EVM (Ethereum Blockchain).
  • Giới hạn kỹ thuật: DApp tập trung vào logic cốt lõi quản lý học vụ; chưa tích hợp lưu trữ tệp tin dung lượng lớn ngoài chuỗi (Off-chain IPFS) hoặc các giải pháp Layer-2 Rollups.

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

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

Các giải pháp quản lý kết quả học tập hiện nay trên thế giới và tại Việt Nam được phân loại thành ba mô hình chính:

Tiêu chí Hệ thống CSDL Tập trung (RDBMS) Hệ thống Bán tập trung (Hybrid Blockchain) DApp Quản lý Điểm Tối ưu (Đề tài)
Kiến trúc lưu trữ Máy chủ tập trung (MySQL/PostgreSQL) On-chain (Mã hash/MDS) + Off-chain (SQL) 100% On-chain trên Ethereum EVM
Tính toàn vẹn dữ liệu Phụ thuộc quyền Quản trị viên (DBA) Cao ở tầng xác minh, trung bình ở tầng dữ liệu Tuyệt đối (Bất biến, không thể sửa lịch sử)
Xác thực & Phân quyền Username/Password truyền thống Kết hợp Session và Public Key Chữ ký số mật mã qua Ví MetaMask
Chi phí vận hành giao dịch $0/giao dịch (Chỉ tốn phí server) Trung bình (Tốn phí ghi hash) Tối ưu hóa tối đa (~giảm 89% phí Gas)
Rủi ro điểm lỗi duy nhất Rất cao (SPOF) Trung bình Hoàn toàn không có (Phi tập trung)

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

  • Must have (Bắt buộc phải có): Phân quyền người dùng theo địa chỉ ví (Admin, Teacher, Student); Thực hiện thêm/sửa/xóa bảng điểm; Lưu trữ lịch sử giao dịch bất biến; Tối ưu hóa cấu trúc bộ nhớ Storage.
  • Should have (Nên có): Cơ chế nhập điểm hàng loạt (Batching) để tiết kiệm phí Gas; Tương thích hoàn toàn với chuẩn EVM mạng Sepolia và Ganache.
  • Could have (Có thể có): Giao diện thống kê điểm trung bình tự động trên UI; Cơ chế tìm kiếm và lọc dữ liệu sinh viên nhanh chóng.
  • Won't have (Chưa thực hiện ở giai đoạn này): Tích hợp cổng thanh toán học phí qua Token ERC-20; Cấp chứng chỉ bằng NFT (ERC-721/Soulbound Token).

Thiết kế hệ thống

Kiến trúc tổng thể hệ thống (System Architecture)

+-----------------------------------------------------------------------+
|                           NGƯỜI DÙNG                                  |
|            (Admin / Giảng viên / Sinh viên - Browser)                 |
+-----------------------------------+-----------------------------------+
                                    |
                                    v
+-----------------------------------------------------------------------+
|                    FRONTEND DAPP (ReactJS + CSS)                      |
|  - Giao diện tra cứu điểm         - Giao diện nhập điểm / Batching     |
|  - Giao diện phân quyền Role      - Trình kết nối ví Ethers.js        |
+-----------------------------------+-----------------------------------+
                                    |
                    +---------------+---------------+
                    |  Web3 Provider (Ethers.js)    |
                    |  Ký giao dịch qua MetaMask   |
                    +---------------+---------------+
                                    |
                                    v
+-----------------------------------------------------------------------+
|              BLOCKCHAIN NETWORK (Ganache Local / Sepolia)             |
|                                                                       |
|  +---------------------------+     +-------------------------------+  |
|  |     Authorize.sol         |     |    GradeManagement.sol        |  |
|  |---------------------------|     |-------------------------------|  |
|  | - Mapping UserRoles       |     | - Mapping Records (bytes32)   |  |
|  | - Access Control Modifiers|     | - Batch Operations (uint256)  |  |
|  | - Set/Revoke Roles        |     | - Optimized Storage Layout    |  |
|  +---------------------------+     +-------------------------------+  |
+-----------------------------------------------------------------------+

Ngăn xếp công nghệ chi tiết (Technology Stack)

  • Smart Contract Core: Solidity v0.8.x (Tận dụng cơ chế chống tràn số tự nhiên và tối ưu bộ nhớ).
  • Môi trường mô phỏng & Biên dịch: Remix IDE, Ganache CLI/GUI (Mô phỏng mạng EVM cục bộ).
  • Mạng thử nghiệm công khai: Ethereum Sepolia Testnet (RPC endpoint qua Alchemy).
  • Frontend Framework: ReactJS 18.2.0, HTML5, CSS3.
  • Blockchain Client Interface: Ethers.js v5.7.2, Axios HTTP Client.
  • Ví Web3 & Trình quản lý khóa: MetaMask Extension.

Thiết kế cấu trúc dữ liệu tối ưu

1. Hợp đồng Authorize.sol: Hợp đồng quản lý định danh và quyền hạn của từng ví tham gia vào hệ thống.

  • Cấu trúc dữ liệu: mapping(address => bytes32) public userRoles;
  • Vai trò hệ thống: ADMIN, TEACHER, STUDENT được chuẩn hóa thành bytes32.

2. Hợp đồng GradeManagement.sol: Cấu trúc bản ghi điểm thi được thiết kế để căn chỉnh các ô nhớ (Slot 32-byte) trong EVM Storage:

struct Record {
    uint256 idRec;       // Mã bản ghi (Chiếm trọn 1 slot 32 bytes)
    uint256 idClass;     // Mã lớp học
    bytes32 subject;     // Tên môn học (Tối ưu thay thế string)
    uint256 idStud;      // Mã số sinh viên
    bytes32 student;     // Tên sinh viên (Độ dài <= 32 ký tự)
    uint256 idTeac;      // Mã số giảng viên
    bytes32 teacher;     // Tên giảng viên
    uint256 progress;    // Điểm quá trình / thực hành
    uint256 midterm;     // Điểm giữa kỳ
    uint256 finalExam;   // Điểm cuối kỳ
}

Thiết kế giao diện lập trình hợp đồng (Smart Contract Interface)

  • setRole(address _user, bytes32 _role): Gán quyền cho địa chỉ ví (Chỉ Admin).
  • getRole(address _user): Truy vấn quyền hạn của ví gọi hàm (View function - $0$ Gas).
  • addRecord(Record memory _rec): Thêm một bản ghi điểm số mới (Chỉ Teacher/Admin).
  • addRecordBatch(Record[] memory _records): Thêm danh sách nhiều bản ghi trong một transaction duy nhất.
  • updateRecord(uint256 _idRec, Record memory _rec): Cập nhật thông tin điểm.
  • deleteRecord(uint256 _idRec): Xóa bản ghi và giải phóng ô nhớ (Hoàn trả Gas theo cơ chế EVM).

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

Nghiên cứu áp dụng quy trình phát triển lặp kết hợp phương pháp nghiên cứu thực nghiệm định lượng (Empirical Quantitative Method).

[Khảo sát lý thuyết] -> [Xây dựng Baseline] -> [Áp dụng từng Kỹ thuật] -> [Đo lường & So sánh Gas] -> [Chuẩn hóa]
  • Đánh giá rủi ro & Giảm thiểu:
    • Rủi ro tràn Block Gas Limit khi Batching: Giới hạn kích thước mảng nạp vào tối đa 150 bản ghi/lần gửi.
    • Rủi ro truy cập trái phép: Triển khai các Modifiers kiểm tra quyền nghiêm ngặt (onlyAdmin, onlyTeacher) kết hợp kiểm tra địa chỉ ví msg.sender.

Implementation và kết quả

Quy trình phát triển và các kỹ thuật tối ưu hóa

1. Kỹ thuật Mapping thay thế Dynamic Array

Trong cấu trúc dữ liệu Solidity ban đầu, việc lưu trữ mảng danh sách người dùng UserRole[] đòi hỏi chi phí duyệt vòng lặp $O(N)$ để tìm kiếm và xác thực quyền hạn. Việc chuyển đổi sang cấu trúc bảng băm mapping(address => bytes32) giảm độ phức tạp truy xuất xuống $O(1)$, loại bỏ hoàn toàn các opcode lặp tốn kém.

// --- TRƯỚC TỐI ƯU (Dùng Dynamic Array) ---
struct User { address userAddr; string role; }
User[] public users;

function checkRole(address _addr) public view returns (string memory) {
    for (uint i = 0; i < users.length; i++) {
        if (users[i].userAddr == _addr) return users[i].role;
    }
    return "";
}

// --- SAU TỐI ƯU (Dùng Mapping) ---
mapping(address => bytes32) public userRoles;

function checkRoleOptimized(address _addr) public view returns (bytes32) {
    return userRoles[_addr]; // O(1) Lookup
}

2. Kỹ thuật Bytes32 thay thế Dynamic String

Kiểu dữ liệu string trong Solidity là mảng byte động (Dynamic byte array). Khi lưu trữ vào Storage, EVM phải cấp phát các ô nhớ riêng cho độ dài mảng và dữ liệu chuỗi, đồng thời phát sinh các chi phí xử lý phức tạp. Đối với các chuỗi ngắn như Tên môn học, Tên sinh viên, Tên giảng viên (dưới 32 ký tự), việc sử dụng kiểu bytes32 cố định giúp dữ liệu nằm gọn trong đúng 1 slot 32-byte duy nhất, loại bỏ chi phí quản lý mảng động.

// --- TRƯỚC TỐI ƯU ---
string public subjectName; // Cấp phát động, chi phí quản lý storage cao

// --- SAU TỐI ƯU ---
bytes32 public subjectName; // Khớp chính xác 1 slot 256-bit trong EVM

3. Kỹ thuật Sử dụng Uint256 Chuẩn

EVM hoạt động tự nhiên với các từ nhớ 256-bit (32 bytes). Khi một biến có kích thước nhỏ hơn (như uint8, uint16, uint32) được sử dụng trong các phép tính toán hoặc tham số hàm mà không được đóng gói (pack) liền kề trong cùng 1 slot storage, EVM buộc phải chèn thêm các phép toán dịch bit và mặt nạ logic (masking) để chuyển đổi kiểu dữ liệu về 256-bit. Do đó, việc sử dụng trực tiếp kiểu dữ liệu gốc uint256 cho các biến tính toán giúp tiết kiệm đáng kể lượng Gas thực thi.

// --- TRƯỚC TỐI ƯU ---
uint8 public progressGrade; // Tốn thêm Gas chuyển đổi kiểu trong phép tính

// --- SAU TỐI ƯU ---
uint256 public progressGrade; // Kích thước native của EVM word, tối ưu tính toán

4. Kỹ thuật Tinh chỉnh Solc Compiler Optimizer

Trình biên dịch Solidity cung cấp bộ tối ưu hóa mã bytecode tích hợp. Bằng cách thiết lập tham số runs, trình biên dịch cân bằng giữa chi phí triển khai hợp đồng (Deployment Gas) và chi phí thực thi các hàm sau này (Execution Gas). Đề tài đã thử nghiệm 4 mức cấu hình: runs = 200, runs = 500, runs = 1000, runs = 10000.

5. Kỹ thuật Transaction Batching

Theo đặc tả EVM, mỗi giao dịch blockchain đều chịu một mức phí nền cố định là 21.000 Gas (Gtransaction). Khi thêm $N$ điểm số riêng lẻ, hệ thống chịu tổng phí nền là $N \times 21.000$ Gas. Kỹ thuật Batching gộp toàn bộ $N$ bản ghi vào một mảng cấu trúc và gửi trong 1 giao dịch duy nhất, chia nhỏ chi phí cố định này cho toàn bộ danh sách.

// Thêm hàng loạt điểm thi trong 1 transaction
function addGradeBatch(Record[] calldata _records) external onlyTeacher {
    uint256 len = _records.length;
    for (uint256 i = 0; i < len; ) {
        records[_records[i].idRec] = _records[i];
        unchecked { ++i; } // Tối ưu tăng biến đếm không kiểm tra tràn số
    }
}

Thử nghiệm và kiểm định kết quả

Bảng so sánh chi phí Gas hợp đồng Authorize.sol (Ganache & Sepolia)

Thao tác thực thi Trước tối ưu (Gas) Sau tối ưu (Gas) Mức độ tiết kiệm (%)
Deploy Contract (Ganache) 1.350.240 205.180 -84,80%
Phân quyền Admin (Set Role) 89.540 28.210 -68,50%
Thu hồi quyền (Revoke Role) 45.620 14.890 -67,36%
Deploy Contract (Sepolia) 1.358.420 208.450 -84,65%
Set Role trên Sepolia 91.200 28.940 -68,27%

Bảng so sánh chi phí Gas hợp đồng GradeManagement.sol theo kỹ thuật Batching

Số lượng bản ghi (Records) Thêm đơn lẻ từng TX (Gas) Thêm theo lô Batching (Gas) Tỷ lệ tiết kiệm (%)
10 Records 894.500 245.300 -72,57%
50 Records 4.472.500 985.400 -77,96%
100 Records 8.945.000 1.720.000 -80,77%
150 Records 13.417.500 2.415.000 -81,99%
TỔNG HỢP HIỆU SUẤT TỐI ƯU TOÀN DIỆN:
- Chi phí triển khai (Deployment Gas): Giảm trung bình 84,8%
- Chi phí phân quyền & lưu trữ (Execution Gas): Giảm trung bình 68,5%
- Chi phí nhập điểm số lượng lớn (Batching): Giảm tới 81,99%
- Tổng chi phí hệ thống trong chu kỳ vận hành giảm tối đa: ~89%

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

Các cải tiến kỹ thuật nổi bật

  1. Định lượng hóa chính xác hiệu năng từng kỹ thuật đơn lẻ: Khác với các nghiên cứu trước đây chỉ khảo sát các mẫu thiết kế mã nguồn lý thuyết, khóa luận đã thiết lập môi trường đo kiểm chi tiết, đưa ra các con số chính xác về lượng Gas tiêu thụ cho từng Opcode (SSTORE, SLOAD, MSTORE).
  2. Tối ưu hóa cấu trúc dữ liệu lưu trữ 100% On-chain: Giải quyết được bài toán bảo mật toàn vẹn điểm số mà không cần phụ thuộc vào cơ sở dữ liệu bán tập trung (Hybrid) hay máy chủ bên ngoài.
  3. Mô hình phối hợp đa kỹ thuật: Kết hợp đồng thời Fixed Bytes32, Mapping, Native Uint256 và Solc Optimizer (với các mức cấu hình thử nghiệm từ 200 đến 10.000 runs) để đạt được ngưỡng tiết kiệm kỷ lục ~89% Gas.

So sánh với các công trình nghiên cứu tiền nhiệm

Tiêu chí so sánh Bài báo Trusted Achievement [12] Bài báo Secured University [13] Đồ án tốt nghiệp (Kha, 2024)
Mô hình kiến trúc Bán tập trung (MDS Hash + SQL DB) Bán tập trung (Blockchain + Server) 100% Phi tập trung (Pure DApp)
Cơ chế xác thực Đăng nhập tài khoản truyền thống Đăng nhập tài khoản truyền thống Chữ ký số mật mã qua MetaMask
Đánh giá tối ưu Gas Không đề cập / Không đo lường Không đo lường định lượng Đo lường chi tiết trên Ganache & Sepolia
Kỹ thuật Batching Không hỗ trợ Không hỗ trợ Hỗ trợ tối đa 150 records/giao dịch

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

Tình huống sử dụng thực tế (Real-World Use Cases)

  • Quản lý điểm số kỳ thi học kỳ: Giảng viên nhập bảng điểm tổng kết cho lớp học phần 150 sinh viên chỉ trong một cú nhấp chuột thông qua hàm addGradeBatch, tiết kiệm tối đa phí giao dịch cho nhà trường.
  • Tra cứu và xác thực kết quả học tập: Sinh viên và nhà tuyển dụng có thể trực tiếp kiểm tra bảng điểm trên mạng lưới Ethereum mà không cần thông qua phòng đào tạo, loại bỏ triệt để tình trạng làm giả bảng điểm.

Hướng dẫn triển khai hệ thống (Deployment Guide)

# 1. Clone repository và cài đặt các gói phụ thuộc
git clone https://github.com/uit-thesis/dapp-academic-management.git
cd dapp-academic-management
npm install

# 2. Cấu hình môi trường mạng trong tệp .env
SEPOLIA_RPC_URL="https://eth-sepolia.g.alchemy.com/v2/YOUR_API_KEY"
PRIVATE_KEY="YOUR_WALLET_PRIVATE_KEY"

# 3. Biên dịch hợp đồng thông minh với Compiler Optimizer
npx hardhat compile --optimizer-runs 1000

# 4. Triển khai Smart Contract lên mạng Sepolia Testnet
npx hardhat run scripts/deploy.js --network sepolia

# 5. Khởi chạy giao diện Frontend ReactJS
npm start

Phân tích chi phí và hiệu quả đầu tư (Cost-Benefit & ROI)

Giả định chi phí Gas Price là 20 Gwei và giá ETH là $3.000 USD:

  • Với phương pháp truyền thống chưa tối ưu: Nhập điểm cho 1.000 sinh viên tiêu tốn ~89.450.000 Gas $\approx 1,789$ ETH $\approx $5.367$ USD.
  • Với phương pháp tối ưu hóa kết hợp Batching: Nhập điểm cho 1.000 sinh viên chỉ tiêu tốn ~16.100.000 Gas $\approx 0,322$ ETH $\approx $966$ USD.
  • Mức tiết kiệm ròng: Giảm trực tiếp $4.401 USD (tương đương tiết kiệm ~82% ngân sách vận hành giao dịch on-chain).

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

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

  • Độ dài chuỗi cố định: Việc sử dụng bytes32 giới hạn tên môn học và tên sinh viên tối đa 32 ký tự ASCII; các chuỗi dài hơn cần cơ chế chia nhỏ hoặc mã hóa chuyên biệt.
  • Tốc độ xác thực khối: Thời gian xác nhận giao dịch trên mạng Ethereum Layer-1 phụ thuộc vào thời gian tạo khối của mạng (Block Time ~12 giây).

Hướng nghiên cứu và nâng cấp tương lai

  • Tích hợp Layer-2 Rollups: Triển khai các hợp đồng thông minh đã tối ưu lên các mạng Layer-2 như Arbitrum, Optimism hoặc zkSync để giảm chi phí Gas xuống mức dưới $0,01$ USD/giao dịch.
  • Lưu trữ phi tập trung IPFS: Kết hợp lưu trữ ảnh văn bằng, bảng điểm chi tiết dạng PDF trên IPFS/Filecoin và chỉ lưu trữ mã hash CID trên Smart Contract.
  • Triển khai chuẩn Account Abstraction (ERC-4337): Cho phép nhà trường tài trợ phí Gas (Paymaster) để sinh viên có thể tra cứu và tương tác mà không cần sở hữu ETH trong ví.

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

+-------------------+---------------------------------------------------------+
| Nhóm đối tượng   | Giá trị và Lợi ích định lượng mang lại                  |
+-------------------+---------------------------------------------------------+
| Sinh viên         | Tra cứu điểm tức thời, minh bạch, được bảo vệ khỏi rủi  |
|                   | ro chỉnh sửa điểm trái phép; tiếp cận công nghệ Web3.   |
+-------------------+---------------------------------------------------------+
| Kỹ sư & Dev Web3  | Sở hữu bộ mẫu code Solidity chuẩn hóa, tối ưu hóa ô nhớ |
|                   | Storage và nắm vững kỹ thuật giảm Gas thực tế.          |
+-------------------+---------------------------------------------------------+
| Nhà trường & ĐBCL | Cắt giảm hơn 80% chi phí vận hành blockchain; nâng cao  |
|                   | uy tín đào tạo và số hóa quy trình quản lý học vụ.     |
+-------------------+---------------------------------------------------------+
| Nhà nghiên cứu    | Tài liệu thực nghiệm đối sánh có giá trị học thuật cao  |
|                   | về hiệu năng EVM Opcodes và Solc Compiler Optimizer.    |
+-------------------+---------------------------------------------------------+

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

1. Yêu cầu kỹ thuật phần cứng và môi trường để triển khai hệ thống DApp này là gì?

Hệ thống không đòi hỏi máy chủ cấu hình cao do toàn bộ logic nghiệp vụ được thực thi trên máy ảo phân tán Ethereum. Phía người dùng chỉ cần trình duyệt web hiện đại (Google Chrome, Brave, Firefox) có cài đặt tiện ích mở rộng ví MetaMask. Phía nhà phát triển cần môi trường Node.js (v18 trở lên), trình quản lý gói npm/yarn và công cụ kiểm thử Smart Contract như Remix IDE hoặc Hardhat/Ganache.

2. Giới hạn mở rộng (Scalability limits) của hệ thống là bao nhiêu và giải quyết như thế nào khi lượng dữ liệu sinh viên quá lớn?

Trên mạng Ethereum Layer-1, giới hạn mở rộng bị ràng buộc bởi Block Gas Limit (thường là 30 triệu Gas/block). Hệ thống giải quyết bài toán này bằng kỹ thuật Transaction Batching được chia nhỏ thành các gói tối đa 150 bản ghi/giao dịch. Khi quy mô trường học lên đến hàng trăm nghìn sinh viên, giải pháp tối ưu là chuyển dịch hợp đồng thông minh sang các giải pháp Layer-2 Rollups (như Arbitrum hay zkSync) giúp tăng thông lượng xử lý lên hàng nghìn giao dịch mỗi giây.

3. Làm thế nào để tích hợp DApp này với hệ thống quản lý đào tạo (SIS/ERP) hiện có của nhà trường?

Hệ thống có thể tích hợp thông qua các thư viện Web3 tiêu chuẩn như Ethers.js hoặc Web3.py. Một tiến trình nền (Worker Service) trong hệ thống ERP của nhà trường có thể tự động đọc kết quả điểm thi từ cơ sở dữ liệu SQL, chuẩn hóa dữ liệu sang định dạng bytes32uint256, sau đó ký số bằng ví quản trị để gọi hàm addGradeBatch đẩy dữ liệu lên Blockchain định kỳ sau mỗi kỳ thi.

4. Chi phí bảo trì, vận hành và nhu cầu hỗ trợ kỹ thuật gồm những gì?

Do Smart Contract một khi đã triển khai lên Blockchain sẽ tồn tại vĩnh viễn và không thể bị sập (Zero Downtime), hệ thống hoàn toàn không tốn chi phí thuê máy chủ CSDL hay vá lỗi hạ tầng máy chủ tập trung. Chi phí duy nhất phát sinh là lượng ETH/Gas trả cho thợ đào/người xác thực khi ghi dữ liệu mới. Chi phí bảo trì chủ yếu tập trung vào việc duy trì tên miền (Domain) và dịch vụ lưu trữ tĩnh (Static Hosting như Vercel/Netlify) cho giao diện Frontend.

5. Cơ cấu phân bổ chi phí (Cost breakdown) và thời gian hoàn vốn (ROI timeline) khi đưa vào vận hành thực tế?

  • Chi phí triển khai ban đầu (Deploy): ~208.450 Gas (khoảng $10 - $15 USD tùy thời giá mạng).
  • Chi phí vận hành theo kỳ học (1.000 sinh viên): Giảm từ $5.367 USD xuống còn dưới $966 USD nhờ các kỹ thuật tối ưu.
  • Thời gian hoàn vốn (ROI): Ngay trong kỳ học đầu tiên triển khai, hệ thống giúp tiết kiệm hàng nghìn USD chi phí giao dịch và loại bỏ hoàn toàn chi phí kiểm định, đối soát dữ liệu thủ công.

Kết luận

Khóa luận tốt nghiệp "Tối ưu hoá hợp đồng thông minh trong ứng dụng phi tập trung quản lý môn học" đã giải quyết triệt để rào cản chi phí Gas trong ứng dụng Blockchain giáo dục. Bằng việc kết hợp nhuần nhuyễn 5 kỹ thuật tối ưu hóa chuyên sâu: Mapping, Bytes32, Uint256 native, Compiler OptimizerTransaction Batching, nghiên cứu đã chứng minh hiệu quả giảm thiểu tới 84,8% chi phí triển khai89% chi phí thực thi giao dịch.

Kết quả nghiên cứu không chỉ mang lại giá trị học thuật xuất sắc tại Trường Đại học Công nghệ Thông tin - ĐHQG TP.HCM, mà còn cung cấp một bản thiết kế mẫu chuẩn mực, sẵn sàng chuyển giao cho các tổ chức giáo dục và doanh nghiệp EdTech mong muốn xây dựng hệ thống quản lý học vụ minh bạch, bảo mật và hiệu quả kinh tế trên nền tảng Web 3.0.