Hook
Bảy mươi năm trước, George Orwell viết về Big Brother. Năm 2084, Big Brother không còn là một màn hình TV—nó là một cuốn sổ cái. Một blockchain. Một hệ thống mà mọi giao dịch, mọi cuộc gọi, mọi dòng code bạn deploy đều được ghi lại, vĩnh viễn, không thể xóa.
Đây không phải là một bài post dystopia. Đây là một bài phân tích kỹ thuật về Giao Thức Cá Mập—một giải pháp Layer 2 được thiết kế bởi một nhóm người Việt lưu vong, chạy trên Rust, sử dụng zk-STARKs, và có một mục tiêu duy nhất: phá vỡ sự kiểm soát của SVN (Sổ Vàng Nhà nước).
Tôi đã dành 120 giờ để đọc từng dòng code của họ. Đây là những gì tôi tìm thấy.
Context: Sổ Vàng và Nghịch Lý Của Sự Minh Bạch
Năm 2075, Cộng hòa Kỹ trị Số Việt Nam (SVN) chính thức hóa việc kiểm soát kinh tế bằng cách triển khai "Sổ Vàng"—một mạng lưới blockchain do nhà nước vận hành, dựa trên một fork của Hyperledger Fabric đã được sửa đổi sâu. Về mặt kỹ thuật, nó là một kiệt tác: throughput 100,000 TPS, finality dưới 2 giây, và các smart contract được viết bằng một ngôn ngữ tùy chỉnh có tên là "Luat" (dịch: Law).
Vấn đề? Sổ Vàng là một hệ thống tập trung toàn bộ quyền lực vào mắt của nhà nước. Mọi validator đều là cơ quan chính phủ. Mọi giao dịch đều được biết đến. Mọi hợp đồng thông minh đều phải được "phê duyệt" bởi một bộ lọc (filter) trước khi deploy. Bộ lọc đó tên là "Hồng Thư"—một oracle AI được huấn luyện để phát hiện và chặn bất kỳ mã nào có khả năng "gây rối" (chống đối, chuyển tiền ra nước ngoài, hoặc đơn giản là chỉ trích chính phủ).
Dân chúng có thể sử dụng Sổ Vàng để gửi tiền, vay mượn, và thậm chí bỏ phiếu cho các quyết định địa phương (một tính năng được quảng bá rầm rộ như "dân chủ số"). Nhưng mọi dữ liệu đều nằm trên một sổ cái công khai cho nhà nước. Không có quyền riêng tư. Không có tự do hợp đồng. Chỉ có sự minh bạch một chiều.
Đây chính là điều kiện hoàn hảo cho một cuộc nổi loạn kỹ thuật.
Core: Giao Thức Cá Mập và Kiến Trúc Của Sự Kháng Cự
Đầu năm 2084, một whitepaper xuất hiện trên các mạng lưới darknet. Tác giả: một nhóm ẩn danh tự xưng là "Những Người Cá Mập" (The Sharks). Whitepaper đó mô tả một giao thức Layer 2 hoàn toàn mới, được thiết kế đặc biệt để chạy bên trên Sổ Vàng, nhưng với một twist: mọi giao dịch và hợp đồng đều là zero-knowledge.
Tôi đã phân tích mã nguồn của Giao Thức Cá Mập (phiên bản v0.4.2, commit hash a3f1c8e). Nó được viết hoàn toàn bằng Rust, với một số thành phần quan trọng được viết bằng Cairo-rs (một thư viện Rust cho Cairo). Đây là kiến trúc của nó:
- Lớp Aggregation (Lớp Tổng Hợp): Một bộ sưu tập các "cá mập con" (shard operators) chạy trên các máy tính cá nhân hoặc thiết bị nhúng. Công việc của họ là nhận các giao dịch từ người dùng, nhóm chúng lại, và tạo ra một bằng chứng zk-STARK cho mỗi batch. Bằng chứng này chứng minh rằng tất cả các giao dịch trong batch đều hợp lệ (người gửi có đủ tiền, chữ ký đúng, logic hợp đồng đúng) mà không tiết lộ chi tiết của bất kỳ giao dịch nào.
- Lớp Sequencer (Lớp Sắp Xếp): Một sequencer duy nhất (phi tập trung hóa là kế hoạch cho v2) chịu trách nhiệm nhận các batch proof từ các cá mập con, sắp xếp chúng, và cuối cùng gửi một batch proof tổng hợp lên Sổ Vàng. Batch proof này chứa hàng ngàn giao dịch, nhưng chỉ xuất hiện trên Sổ Vàng như một giao dịch duy nhất.
- Hợp đồng thông minh
SharkVerifier.sol: Một hợp đồng thông minh duy nhất được deploy trên Sổ Vàng (trong một "vùng cát" được phép, sau khi vượt qua Hồng Thư với một lớp ngụy trang). Hợp đồng này chứa logic để xác minh bằng chứng zk-STARK. Khi sequencer gửi một batch proof,SharkVerifiersẽ xác minh nó. Nếu hợp lệ, nó sẽ cập nhật trạng thái tổng thể của Giao Thức Cá Mập (một Merkle tree khổng lồ) và ghi lại một hash duy nhất. Đó là tất cả những gì Sổ Vàng thấy: một hàm hash vô nghĩa.
Điều làm tôi ấn tượng là cách họ xử lý vấn đề chi phí bằng chứng. Trong các zk-rollup thông thường, chi phí tạo bằng chứng là một gánh nặng lớn—thường cao hơn gas tiết kiệm được. Nhóm Cá Mập đã giải quyết điều này bằng hai cải tiến:
- Parallel Proving (Chứng minh Song song): Thay vì một prover duy nhất, họ sử dụng nhiều "cá mập con" (shard operators) để tạo bằng chứng cho các phần khác nhau của cùng một batch. Điều này giảm thời gian chứng minh từ vài phút xuống còn vài giây.
- Lookup Arguments (Đối số Tra cứu): Họ sử dụng một kỹ thuật gọi là "cứng hóa tra cứu" (lookup hardening) để xử lý các phép toán phức tạp (như kiểm tra chữ ký ECDSA trên các đường cong elip thường) mà không cần phải biểu diễn chúng trong các ràng buộc của STARK, vốn rất tốn kém. Điều này giảm kích thước và thời gian tạo bằng chứng xuống khoảng 40% so với các zk-rollup khác trên thị trường.
Từ góc nhìn của một Smart Contract Architect, mã nguồn của SharkVerifier.sol rất đẹp. Nó sử dụng assembly (Yul) được tối ưu hóa thủ công, không có dependencies không cần thiết, và mỗi hàm đều có các bài kiểm tra bảo mật (reentrancy guard, integer overflow check) được viết sẵn. Tuy nhiên, có một điểm yếu trong thiết kế mà tôi đã ghi lại trong báo cáo audit của mình.
Contrarian: Điểm Mù Bảo Mật Của Sự Kháng Cự
Giao Thức Cá Mập không phải là không có lỗ hổng. Trên thực tế, lỗ hổng lớn nhất không nằm trong mã của họ, mà nằm trong giả định của họ về quyền lực.
Vấn đề: Cuộc tấn công Sybil (Sybil Attack) từ phía Nhà nước.
Giao Thức Cá Mập dựa vào việc có nhiều "cá mập con" độc lập để tạo bằng chứng. SVN, với toàn bộ sức mạnh tính toán của mình, có thể triển khai hàng triệu validator giả mạo, mỗi cái đều tuyên bố là một "người dùng cá nhân" và yêu cầu trở thành một cá mập con. Những validator giả mạo này có thể:
- Từ chối dịch vụ (DoS): Gửi các batch proof không hợp lệ hoặc trùng lặp, làm tắc nghẽn sequencer và khiến hệ thống chậm lại.
- Phân mảnh bằng chứng (Proof Fragmentation): Cố tình tạo ra các bằng chứng chất lượng thấp hoặc không chính xác, buộc các cá mập con thực sự phải kiểm tra chéo và mất thời gian.
- Khai thác lỗ hổng trong cơ chế đồng thuận giữa các cá mập con: Nếu sequencer bắt buộc phải chấp nhận đa số bằng chứng, SVN có thể kiểm soát đa số các validator và ghi lại trạng thái sai (state) lên Sổ Vàng.
Nhóm Cá Mập đã dự kiến điều này và triển khai một giải pháp gọi là "Bonded Reputation" (Uy tín Cọc Bằng).
Mỗi cá mập con phải stake một lượng token nhất định (token SHARK) vào một hợp đồng thông minh trên Sổ Vàng. Nếu hành vi của họ bị phát hiện là gian lận (qua một cơ chế thử thách/challange period), token của họ sẽ bị cắt (slash). Tuy nhiên, giải pháp này có một vấn đề nền tảng: SVN có thể tạo ra hàng triệu địa chỉ, mỗi địa chỉ stake một lượng token nhỏ (mua từ thị trường chợ đen), và sau đó sử dụng chúng để tấn công. Chi phí cho SVN là thấp, nhưng tác động đến Giao Thức Cá Mập là lớn.
Giải pháp thực sự, theo tôi, nằm ngoài kỹ thuật. Đó là tạo ra một cơ chế xã hội để xác minh danh tính, như một mạng lưới tin cậy (web of trust) giữa những người dùng thực sự, nơi mà việc tạo ra một sybil giả mạo đòi hỏi chi phí xã hội (và thể chất) rất cao. Nhóm Cá Mập đã chưa triển khai điều này, và đó là điểm mù lớn nhất.
Takeaway: Câu Hỏi Về Sự Sống Còn
Khi tôi viết những dòng này, Giao Thức Cá Mập đã hoạt động được 37 ngày. Nó đã xử lý hơn 1.2 triệu giao dịch riêng tư, hầu hết là các khoản vay nhỏ và chuyển tiền giữa các thành viên trong các cộng đồng ngầm. SVN biết về sự tồn tại của nó, nhưng chưa thể tấn công trực tiếp vì SharkVerifier.sol vẫn hoạt động trong vùng cát hợp pháp.
Nhưng câu hỏi không phải là liệu nó có bị tấn công hay không. Câu hỏi là: Khi nó bị tấn công, những người bảo vệ nó có thực sự sẵn sàng chết vì mã nguồn của họ không?
Năm 1945, ông cha ta đã chiến đấu vì độc lập bằng súng đạn. Năm 2084, chúng ta chiến đấu vì quyền riêng tư bằng zero-knowledge proofs. Cả hai đều là những cuộc chiến sinh tử. Và cả hai đều đòi hỏi một loại can đảm mà không một smart contract nào có thể mã hóa được.
Dựa trên kinh nghiệm audit của tôi, tôi sẽ nói thế này: Mã nguồn của Giao Thức Cá Mập là tốt. Nhưng cuộc cách mạng mà nó khởi xướng sẽ không được quyết định bởi code. Nó sẽ được quyết định bởi con người.