Tính công bằng của Dice

​

Vì sao Dice không có bước cam kết?

• slothash: mục mới nhất trong sysvar SlotHashes của Solana tại thời điểm giao dịch cược của bạn được thực thi. Đây là nguồn ngẫu nhiên do mạng tạo ra, chưa được biết khi giao dịch được tạo (người gửi không thể biết chính xác giao dịch sẽ rơi vào slot nào).
• user: địa chỉ 32 byte của tài khoản người dùng on-chain của bạn (tài khoản mà chương trình dẫn xuất từ ví của bạn). Điều này khiến kết quả tung giữa các người chơi độc lập với nhau: hai lượt cược rơi vào cùng một slot sẽ có kết quả khác nhau.
• nonce: bộ đếm lượt cược cá nhân của bạn, lưu on-chain và tăng lên sau mỗi lần chơi. Điều này khiến các lượt cược liên tiếp của chính bạn độc lập với nhau, kể cả trong cùng một slot, đồng thời chống gửi trùng.

​

Công thức chính xác của một lần tung Dice là gì?

đầu vào
  slothash   32 byte    slot hash Solana mới nhất khi giao dịch cược được thực thi
  user       32 byte    địa chỉ tài khoản người dùng on-chain của bạn
  nonce      8 byte     bộ đếm lượt cược của bạn, little-endian

dẫn xuất
  hash = sha256( "dice" ‖ slothash ‖ user ‖ nonce )   // "dice" = 4 byte ASCII 0x64 0x69 0x63 0x65
  roll = u128_be( hash[0..16] ) mod 10000              // 16 byte đầu, số nguyên không dấu 128-bit big-endian

kết quả
  roll là số nguyên trong khoảng 0..9999, tức 0.00–99.99 với hai chữ số thập phân

• Đầu vào của hàm hash là phép nối theo đúng thứ tự này: thẻ ASCII "dice", slot hash, địa chỉ tài khoản người dùng, rồi đến nonce được mã hóa thành 8 byte little-endian.
• Mẫu là 16 byte đầu của đầu ra SHA-256, đọc như một số nguyên không dấu 128-bit big-endian, rồi lấy modulo 10,000.
• Việc lấy modulo 10,000 một mẫu 128-bit có độ lệch lý thuyết dưới 2⁻¹¹⁴, nhỏ hơn lợi thế nhà cái hàng chục bậc độ lớn, nên nó được ghi rõ trong tài liệu thay vì được hiệu chỉnh.

​

Điều kiện thắng và tiền trả thưởng

Under target : thắng khi roll < target      tỷ lệ thắng = target kết quả trên 10000
Over  target : thắng khi roll > target      tỷ lệ thắng = 9999 − target kết quả trên 10000

multiplier_bps = floor( (10000 − edge_bps) × 10000 / win_chance_bps )

​

Điều gì được bảo đảm, điều gì không

• Kết quả tung được dẫn xuất và tất toán trong một lệnh on-chain duy nhất, từ các đầu vào mà chương trình tự đọc. Backend không cung cấp kết quả tung và không thể báo sai nó.
• Nhà vận hành không đóng góp đầu vào nào vào phép dẫn xuất: không có server seed nào để dò tìm kết quả có lợi.
• Nonce của bạn phải được gửi lại chính xác, nên cùng một lượt cược không thể vô tình (hay cố ý) bị chơi hai lần.
• Mỗi lần chơi đều công bố toàn bộ đầu vào dẫn xuất và kết quả, nên bất kỳ ai cũng có thể tính lại mọi lần tung trong lịch sử.

• Việc đưa vào khối không hoàn toàn kiểm soát được: chính mạng, không phải người gửi, quyết định chính xác slot mà giao dịch rơi vào.
• Mọi đầu vào đều được công bố, nên các mẫu trì hoãn gửi và mọi sai lệch của tỷ lệ thắng tổng thể so với tỷ lệ niêm yết đều có thể được bất kỳ ai đo lường từ dữ liệu công khai. Việc lạm dụng có hệ thống không thể bị che giấu.

​

Làm thế nào để xác minh một lần tung Dice?

1. Mở giao dịch của lượt cược trên một trình khám phá Solana và đọc các trường của sự kiện (màn hình Dice trong ứng dụng hiển thị các đầu vào công bằng trong phiên của bạn, và lịch sử cược của bạn có liên kết tới giao dịch).
2. Tính lại sha256("dice" ‖ slothash ‖ user ‖ nonce), lấy 16 byte đầu theo big-endian modulo 10,000, rồi so sánh với roll của sự kiện.
3. Kiểm tra kết luận thắng/thua (roll < target với Under, roll > target với Over) và hệ số nhân theo công thức ở trên.