Sui Move technical documentation

Sui 大老二可驗證牌局文件

本文件說明 Sui Move 大老二的系統架構、鏈上狀態、可驗證流程、押注結算與信任邊界。 系統使用 Sui shared object 保存牌局狀態,並透過 Move events、commit-reveal 與 testnet SUI escrow 建立可檢查的牌局紀錄。

commit-revealGameRoom shared objectMove eventstestnet SUI escrow

deployed package

0x94b3f4d9451736b6af3679228852d1749dbb6949dded8da8dbb0cade7682f985

publish transaction

J6HWyu8trVtFcqE8biD5zCaW3PPYznaVc7gsrwdvm6fX

Network

sui:testnet

Stake

0.1 SUI

Overview

系統將牌局中的關鍵資料拆分為可檢查狀態:牌堆承諾雜湊、原始發牌紀錄、 Move 事件歷史、終局揭示資料與押注池狀態。使用者可透過驗證面板檢查牌堆揭示與發牌紀錄是否一致。

牌堆承諾

開局前把 sha3_256(deck || salt) 上鏈,先鎖住一副牌。

揭示驗證

終局公開 deck 與 salt,任何人都能重算雜湊。

發牌綁定

揭示出的 deck 必須切出與原始發牌紀錄相同的四手牌。

事件歷史

房間建立、加入、發牌、出牌、pass、結束、揭示都可作為 Move events 審計。

押注池

testnet SUI 可鎖在 GameRoom,勝者依 Move 狀態領取。

Architecture

系統分為三個主要部分:前端與 SDK 負責互動與本地驗證,Sui Move 合約負責共享狀態與規則約束, Verifier / Explorer 負責重算承諾、比對發牌資料並重放事件歷史。

Frontend / SDK

產生牌堆、洗牌、建立 commitment、渲染桌面、執行操作控制、重算 hash, 並將事件歷史整理為可閱讀流程。

Sui Move

GameRoom 是 shared object,保存玩家、手牌、回合、最後出牌、winner、 revealed deck、stake pot 與 pot claim 狀態。

Verifier / Explorer

重新計算 commitment、檢查 52 張牌唯一性、驗證 revealed deck 是否能切回原始發牌, 並用事件紀錄重放牌局。

WAITING

建立房間、等待玩家加入、保存 deck commitment。

PLAYING

莊家發牌後進入遊戲,合約驗證出牌與 turn state。

ENDED

某位玩家手牌歸零,winner 寫入 GameRoom。

REVEALED

公開 deck + salt,驗證 hash 與原始發牌是否匹配。

Verifiability

開局時的承諾是 sha3_256(deck || salt)。 終局時公開 deck 與 salt 後,系統要同時通過兩個檢查:第一,重算 hash 必須等於開局承諾; 第二,將 revealed deck 切成四份 13 張牌,必須等於當初紀錄的 original_hands。
1

Commit

先把 deck commitment 上鏈。

2

Deal

保存實際發出的 original_hands。

3

Reveal

公開 deck 與 salt。

4

Verify

hash match 且 deal match 才算通過。

竄改發牌檢查

竄改發牌不是更改揭示牌堆,而是把「實際發牌紀錄」替換成另一組合法但不同的手牌。 因此 revealed deck 仍然能算出相同 commitment,hash 會過;但 revealed deck 切出來的四手牌 對不上 original_hands,所以 deal match 會失敗。

Move Contract

合約模組為 big_two::big_two。 它不是只記錄結果,而是把回合狀態、牌型檢查、事件輸出、終局 winner 與 pot claim 都放在 Move 狀態機裡。
create_room

建立不押注房間,寫入 deck commitment。

create_room_with_stake

建立押注房間,將第一筆 testnet SUI 放入 pot。

join_room / join_room_with_stake

玩家加入房間;押注房需支付相同金額。

deal_cards

莊家送出四份 13 張手牌,合約檢查 52 張合法且不重複。

play_cards

驗證輪次、手牌所有權、牌型、大小與首出梅花 3。

pass_turn

允許玩家 pass,三家 pass 後清空 trick 並回到上一位出牌者。

reveal_deck

公開 deck 與 salt,驗證 commitment 以及 dealHands(deck) == original_hands。

claim_pot

遊戲結束後,只有 GameRoom 記錄的 winner 可以領取 pot。

Rule Model

牌用 0..51 編碼;rank = card / 4suit = card % 4。 花色大小為梅花、方塊、紅心、黑桃;第一手必須包含梅花 3。

牌型強度

單張、對子、三條、順子、同花、葫蘆、鐵支、同花順。五張牌比較時, 強度順序為順子小於同花,小於葫蘆,小於鐵支,小於同花順。

規則變體

本系統採固定規則:J Q K A 2 可視為順子;A 2 3 4 5 這類繞回順不支援。 同花比較使用該同花中的最大單張 power。

Operation Flow

操作流程由房間建立開始,依序完成鏈上房間建立、發牌、出牌、可驗證性檢查與勝利結算。 每個階段都會產生可供比對的狀態或事件資料。
1

建立房間

產生 deck commitment,顯示牌堆承諾雜湊。

2

鏈上建立

連接 Sui Wallet,在 testnet 建立 GameRoom 並押入 0.1 SUI。

3

發牌與出牌

執行梅花 3 首出、花色比較、鐵支與 pass 流程。

4

竄改發牌

替換原始發牌紀錄,使 hash 通過但 deal match 失敗。

5

揭示驗證

公開 deck + salt,並在驗證面板比對 commitment 與發牌紀錄。

6

勝利結算

說明 winner、GameRoom pot 與 claim_pot 的鏈上限制。

Trust Model

目前版本可驗證牌局歷史、原始發牌與終局揭示是否一致,並呈現 Move escrow 持有測試網資產的流程。 系統尚未提供隱藏手牌、公平隨機來源或完整爭議處理。

可以證明

revealed deck 是否符合開局 commitment、revealed deck 是否能切回 original_hands、 Move events 是否形成可重放歷史、winner 是否由 deterministic rules 得出。

尚未證明

莊家是否公平選牌、手牌是否保密、玩家斷線如何處理、多人真實同步如何爭議解決。

公開手牌

目前版本以公開手牌狀態呈現,以便完整檢查發牌、出牌與揭示流程。

隨機性邊界

commitment 可驗證牌局未被事後替換,但不能單獨證明初始牌堆由公平隨機來源產生。

測試網押注

testnet SUI escrow 用於驗證資產流程,不構成正式賭博或主網資金協議。

同步範圍

目前版本聚焦可驗證狀態與操作介面,不包含完整多人即時同步與爭議處理。

升級路線

多玩家 seed commit-reveal,降低單一莊家控制牌堆的能力。

接入 Sui Random object,讓 deck 來源更接近鏈上隨機。

使用 TEE、ZK 或 mental poker 協議處理隱藏手牌。

參考來源

以下為可驗證遊戲歷史、鏈上資產管理與可信執行環境相關的公開參考資料。