Giao thức Mật mã

Commit / Reveal

Trong Round (vòng) t, người dùng i với bí mật riêng tư s_i ∈ {0,1}^128 chọn câu trả lời b_i ∈ {0,1} và công bố:

$$c_i=\text{HMAC-SHA256}(s_i\parallel {\text{round}}_t,b_i)$$

Trong đó ‖ biểu thị phép nối chuỗi và round_t là một định danh Round (vòng) duy nhất công khai.

Trong giai đoạn Reveal, người dùng i phát sóng (s_i, b_i). Round Engine (Công cụ Round) và bất kỳ người xác minh bên thứ ba nào tính toán HMAC-SHA256(s_i ‖ round_t, b_i) và kiểm tra xem nó có khớp với c_i đã công bố trước đó hay không. Các Reveal không khớp sẽ bị từ chối; những người không Reveal sẽ bị loại khỏi Round (vòng) nhưng Commit của họ vẫn nằm trong Merkle Root (Gốc Merkle) để kiểm toán.

Tại sao lại dùng HMAC mà không phải hash thuần

Một Commit thuần H(s_i ‖ b_i) dễ bị tổn thương trước hai cuộc tấn công:

1. Tính toán trước Rainbow. Nếu s_i ngắn (UX trên di động buộc chúng ta phải dùng độ ngẫu nhiên gắn với thiết bị ≤16 byte), một bảng tính toán trước của H(s ‖ 0) và H(s ‖ 1) trên toàn bộ không gian bí mật có thể phá vỡ Commit trước khi Reveal.
2. Phát lại qua các Round. Nếu không có ràng buộc Round, một Commit hợp lệ trong Round t có thể được phát lại làm bằng chứng trong Round t' ≠ t.

HMAC với khóa có kích thước phù hợp (ở đây là 128 bit) và ràng buộc Round (nối round_t vào thông điệp có khóa) loại bỏ cả hai vấn đề. Tính giả ngẫu nhiên của cấu trúc HMAC theo các giả định tiêu chuẩn đảm bảo rằng nếu không có s_i, lợi thế của kẻ tấn công trong việc phân biệt b_i = 0 với b_i = 1 là không đáng kể.

s_i đến từ đâu

Mỗi thiết bị người dùng tạo s_i khi tham gia Round (vòng) thông qua crypto.getRandomValues(new Uint8Array(16)) của trình duyệt. Nó được lưu trữ trong bộ nhớ phiên của WebApp chỉ trong suốt thời gian Round (vòng). Sau Reveal, nó bị loại bỏ. Không có bí mật nào do người dùng nhập vào.

Đối với người dùng xóa phiên giữa Round (vòng), Round (vòng) sẽ bị mất (họ không thể Reveal một Commit mà họ không còn giữ khóa). Reputation Score (Điểm uy tín) sẽ bị giảm nhẹ.

Round Merkle Root (Gốc Merkle của Round)

Tại giai đoạn Settle, Engine tính toán:

$${\text{root}}_t=\text{Merkle}(\{(i,c_i,b_i,{\text{outcome}}_i):i\in {\text{Participants}}_t\})$$

Root (gốc) được xếp hàng để thanh toán hàng loạt lên TON mỗi 24 giờ. Một giao dịch duy nhất trên TON có thể cam kết ~5,760 Round roots (gốc Round) (một root mỗi 60 giây × 86,400 / 60 / 15 khấu hao).

Bất kỳ người tham gia nào cũng có thể lấy một Merkle proof (bằng chứng Merkle) từ Engine và xác minh sự có mặt của họ so với root (gốc) trên chuỗi, mà không cần tin tưởng Engine.

Cửa sổ tranh chấp

Một cửa sổ tranh chấp 24 giờ cho phép thách thức trên chuỗi: người dùng gửi một Merkle proof (bằng chứng Merkle) cho thấy root (gốc) trên chuỗi không khớp với tuyên bố của Engine ngoài chuỗi. Nếu thách thức thành công, round (vòng) sẽ bị vô hiệu và được thanh toán lại; người vận hành phải trả 1,000 $POP (token $POP) tiền phạt vào Treasury (Kho bạc). Các root (gốc) không bị thách thức sẽ trở thành chính thức.

Reputation Score (Điểm uy tín)

r_i ∈ [0, 1] là ước tính Bayes về độ trung thực của người dùng, được cập nhật mỗi Round (vòng):

$$r_i^{(t+1)}=\frac{r_i^{(t)}\cdot \lambda (o_i^{(t)})}{r_i^{(t)}\cdot \lambda (o_i^{(t)})+(1-r_i^{(t)})\cdot (1-\lambda (o_i^{(t)}))}$$

Trong đó λ(o_i^{(t)}) là hàm khả năng dựa trên các quan sát (tham gia, Reveal đúng giờ, độ lệch so với xác suất thiểu số, các dấu hiệu bất thường). Giá trị ban đầu r_i = 0.5 (tiên nghiệm không có thông tin).

Reputation (Uy tín) giảm dần khi không hoạt động với tốc độ δ = 0.01 / ngày. Reputation (Uy tín) không thể vượt quá 0.99 (khiêm tốn nhận thức) hoặc giảm xuống dưới 0.01 (cho phép phục hồi).

Reputation Score (Điểm uy tín) nhân với hệ số nhân của Trust Ladder (Bậc thang tin cậy) trong quá trình thanh toán:

$${\text{trọng số hiệu quả}}_i=r_i\times {\alpha }_{T(i)}$$

Lập luận bảo mật chính thức

Với giả định rằng HMAC-SHA256 là một hàm giả ngẫu nhiên (PRF) và s_i là ngẫu nhiên đồng nhất và không được biết đến bởi kẻ tấn công, không có kẻ tấn công hiệu quả nào có thể:

1. Phân biệt commit c_i = HMAC(s_i ‖ round_t, b_i) cho b_i = 0 so với b_i = 1 với lợi thế không đáng kể. (Tính ẩn danh.)
2. Tìm (s'_i, b'_i) ≠ (s_i, b_i) sao cho HMAC(s'_i ‖ round_t, b'_i) = c_i. (Tính ràng buộc, dưới khả năng chống va chạm của HMAC.)
3. Dự đoán seed (hạt giống) của round (vòng) tiếp theo mà không thông đồng với cả bộ xác thực DRAND và TON-VRF. (Xem Oracle & Randomness.)

Đây là ba thuộc tính cần thiết cho một trò chơi phối hợp Commit / Reveal công bằng. Giao thức không yêu cầu bất kỳ giả định mật mã bổ sung nào.

Kiểm toán & Mã nguồn mở

Round Engine (Công cụ Round) và logic xác minh được phát hành dưới dạng mã nguồn mở theo giấy phép MIT. Kho lưu trữ tại github.com/cashpop-protocol/round-engine. Một cuộc kiểm toán đầy đủ bởi Trail of Bits được lên kế hoạch cho Giai đoạn 2 (Quý 4 năm 2026).