系統流程

可稽核的彩票系統在每一次進行遊戲時將會經過以下步驟1 至步驟 10，分 別為：1.系統初始化、2.投注、3.回傳收據、4.紀錄投注資訊 5.上傳獎金與中獎 號碼、6.傳送 TP Merkle Tree 至 IPFS、7.玩家索取密碼學證據、8.稽核遊戲正確 性、9.提起申訴、10.領獎，整體的遊戲規範並沒有強制要求，即符合彩票彩券

的形式皆可以運用此系統進行開發，由於投注時是向遊戲供應商進行投注，故 並不限定使用區塊鏈的加密貨幣，此舉可以大幅度增加與現實彩票系統的銜接 性，以及增進投注效率。

圖 4-4 系統流程圖

在本篇論文中將會提及幾個系統運作時所運用的名詞，這些名詞在往後的 章節中將會頻繁出現，為避免繁複多重的解釋故在此對這些使用的名詞做初步 定義。

1. 保證金：保證金為確保遊戲正確進行，遊戲供應商將會上傳一筆巨額的加密

貨幣至智能合約Smart Contract 中做擔保，若往後系統的流程中有出現錯誤，投

20

注資訊有出現紕漏，玩家皆可將自己的密碼學證據上傳至智能合約，取走保證 金。

2. 賠償金：賠償金為玩家經由向智能合約提出申訴後，智能合約會依據上傳的

投注資訊、密碼學證據進行判讀，確認錯誤是遊戲供應商所產生後，轉帳一筆 加密貨幣給提出申訴的玩家，此一加密貨幣就是賠償金。賠償金的金額主要來 源為上一項目所提及的保證金。

3.投注金：投注金為玩家在投注階段向遊戲供應商投注所支付的貨幣，此一貨幣

不限定為加密貨幣，為增進與實際上的彩票系統做連結，投注的方法可以運用 現金、線上支付、ATM 轉帳、信用卡支付等等普通的支付系統。

4.彩金：彩金為遊戲供應商在清算 TP-Merkle Tree 完成後，會將與投注金總額等

值的加密貨幣上傳至智能合約中，此加密貨幣將會在往後開獎中被當作彩金轉 帳給得獎者。

第一段 步驟 1 系統初始化

在進入系統初始化之前，遊戲供應商會先將彩票系統所使用的智能合約部 屬上區塊鏈，並且開始與智能合約互動。在系統初始化時，遊戲供應商將會公

告本次遊戲所使用的開獎號碼取用來源，以供所有玩家進行審閱，玩家可以依 照遊戲供應商所提供的資訊進行審查，再決定是否與遊戲供應商進行遊戲。關 於開獎號碼取用來源，在本節之第五段領獎階段將會有詳細的說明以及建議。

再來遊戲供應商將會到智能合約中檢查保證金是否充足，此一保證金的價值必

21

須遠高於單一彩票的價值，用以對遊戲的保證。若在智能合約上的保證金不 足，遊戲供應商必須補充。

第二段 步驟 2、3、4 投注、回傳收據與紀錄資訊

在投注階段，玩家開始可以與遊戲供應商進行投注，投注並沒有特殊的規 定，以不遠離樂透彩票的模式為主，若以台灣彩券為例，將由玩家選號6 組數 字進行投注。在本系統，詳細流程可以參考以下圖4-4。

圖 4-5 投注階段流程圖

首先玩家將與遊戲供應商進行投注動作，在此稱投注資訊為M Request，並且在投 注內容應包含以下列舉資訊

( PK Player | Clearance Order | PK_Index Player| Choose Number | TimeStamp Player | Signature Player)

在投注資訊中 PK Player 將表示玩家所使用的公開金鑰，在此採用RSA 非對稱式 金鑰加密系統 [15]。Clearance Order 說明了本次投注的遊戲期數。PK_Index

Player 代表使用在 TP Merkle Tree 的定位資訊，由本章第二節可知，將一筆資料

放入TP Merkle Tree 時，需要使用到一個 Key 來進行定位，才能計算出本資料 須放入哪個葉子節點底下，故在此的PK_Index Player 就是使用在此處。Choose

22

Number 如同上面所述，是由玩家選擇的號碼。TimeStamp Player 代表玩家產出此 一投注資訊時的時間戳計。Signature Player 代表玩家的電子簽章，本系統所使用 的電子簽章以橢圓曲線數字簽名算法(ECDSA)為主 [16]。

再來第二步，遊戲供應商收到玩家所傳送的投注資訊後，必須產生相對應

之收據M Reply，此一收據必須包含以下列舉資訊

( M Request | Result | SN | Accumulate Bet | TimeStamp SPO | Signature SPO)

在收據資訊中，將包含整個玩家的投注資訊M Request 用以在稽核階段可以對內 容進行稽核。Result 表示此次投注成功與否，投注成功條件將由遊戲供應商進

行列舉，在此舉例像是不能讓PK_Index Player 重複、Clearance Order 必須符合當 前遊戲期數、Choose Number 不能超出規定範圍等等。SN 將表示本期遊戲到此

一玩家投注為止，被列為第幾個投注，也就是每一期投注的流水編碼。

Accumulate Bet 表示到此一玩家投注為止，總共累積多少投注金，此累積投注金

將在下一階段上傳獎金時，扣除遊戲供應商抽成後依照一定比例轉換為加密貨 幣，並上傳至智能合約當作彩金使用。TimeStamp SPO 代表此次收據產出時的時 間戳記。Signature SPO 代表遊戲供應商的電子簽章。

再產出收據之後，遊戲供應商必須將此收據放入TP Merkle Tree 中，並使 用玩家提供的PK_Index Player 進行定位，把一整張收據放入其中。最後再將本次 產出的即時回傳給投注的玩家。在本篇論文中，將玩家的投注資訊M Request 與

遊戲收據M Reply 進行簡單計算，M Request大小約在104 bytes 上下，依照玩家的

23

選號長度、大小將會有些微的差距。M Reply的大小將會在180 bytes 上下。

第三段 步驟 5、6、7 上傳獎金與 TP-Merkle 至 IPFS、索取密碼學證 據

在投注階段經過一段時間之後，遊戲供應商將會停止接受投注，並開始對 TP Merkle Tree 進行清算，在此清算的意思代表著將 TP Merkle Tree 從葉子節點

開始，將其底下的Key-Value Pairs 進行合併與取雜湊的動作，以計算出葉子節 點所要包含的雜湊值，接下來將一步一步計算所有內部節點一直推算至根節點 的雜湊值RootHash。

再來遊戲供應商必須將此一清算後的 RootHash 上傳至智能合約當中，除此 之外將附帶累積投注金扣除抽成後轉換過的彩金，以及本期遊戲的最後一張收據 也都必須一同上傳至智能合約。在上傳完成後，遊戲供應商將要把整個TP Merkle Tree 進行打包，並且附上電子簽章之後上傳至 IPFS [17]，IPFS 為一個分散式的雲

端儲存服務系統廠商，當然不一定要使用IPFS 此廠商作為儲存手段，也可以選擇 其他的服務廠商，只要能夠確保資料安全性、公開性、存在性即可。在本論文中 往後的章節將會多次提及IPFS，皆為上述所示。再將 TP Merkle Tree 上傳之後，

遊戲供應商必須將此連結公開給所有人知道，並且所有人皆可以提取這個 TP Merkle Tree。

在階段的最後，遊戲供應商將要開放所有參與遊戲的玩家索取密碼學證據，

以利於往後的中獎登記、稽核與申訴。在此所提及的密碼學證據與本章第二節所

24

提到的密碼學證據相同，但有加入其他必要資訊，而整體的密碼學證據架構如下 ( Slice | List of Key-Value Pair | Clearance Order | Signature SPO)

除了推算至根結點所需的Slice 與 List of Key-Value Pair 之外，必須附上 Clearance Order 以確定是哪一期的投注收據，最後附上遊戲供應商的電子簽章。

第四段 步驟 8、9 稽核遊戲正確性與提起申訴

在稽核與提起申訴階段，將會分成稽核部分與申訴部分，在稽核部分中，

投注玩家在遊戲流程中若有受到遊戲資訊錯誤，遊戲供應商流程有誤，將可以 在智能合約上提起申訴，並將在投注階段取得的收據、索取的密碼學證據上 傳，智能合約將可以依照上傳的資料來進行公平的裁決。而非玩家的其他人一 樣皆可以取得在IPFS 上的 TP Merkle Tree 並取得內部的所有收據來進行稽核，

若有發現遊戲資訊有誤，便可以將有問題的收據上傳至智能合約提起申訴，智 能合約一樣會依照上傳的資訊進行公平的裁決。在向智能合約提起申訴時，皆 須附上一筆押金以示負責，避免大量的申訴佔據區塊鏈的頻寬，若在往後申訴 成功時，將會退回此筆押金，並且將遊戲供應商提供的保證金一同領回。若申 訴失敗，將會沒收申訴所上傳的押金以示懲罰。

再進行申訴之前，在智能合約中會有一個公開稽核獎勵機制，也就是任何 一個人在取得IPFS 上的 TP Merkle Tree 並取得內部的所有收據來進行稽核後，

如果沒有發現任何問題，便可以至智能合約中宣告此次的遊戲是正常無誤的，

當然此一動作也必須附上押金，智能合約會在時限之內開放稽核正確登記，最

25

後若沒有其他玩家、其他稽核員提起任何一個因遊戲資訊錯誤而發起的申訴的 話，前三名至智能合約登記的稽核員將可以在智能合約中提領到一筆稽核獎 金。相反的若是有人提起申訴成功的話，及證明此次稽核是有問題的，會沒收 掉當初公開稽核時進行登記所需要的押金，此筆押金將會一同與保證金轉帳給 發現錯誤的人。

在申訴部分詳細說明之前，必須先提出三個情境假設如下：

1. 遊戲供應商一定會將 TP Merkle Tree 上傳至 IPFS，且 IPFS 將會完整保存此筆

檔案，不會遺失。

2. 遊戲供應商將與智能合約持續互動，推動整個遊戲流程，亦即上傳中獎 號碼、獎金等等必要行動

3. 玩家在步驟 7 時會與遊戲供應商索取密碼學證據，此一密碼學證據一定 可以取得。

若以上三點未達成的話，將可以視為遊戲供應商捲款潛逃，玩家可以透過法律 途徑提出抗告。申訴部分將會細分成兩大類的申訴與五項的申訴情境與申訴辦 法，第一大類為”玩家權益受到損害而發起的申訴”，在此類別之中包含以下情

形：

1. 收據M Reply 未被記錄在 TP Merkle tree 上

第二大類為”公開稽核遊戲資訊，發現錯誤而發起的申訴”， 在此類別之中包含

第二大類為”公開稽核遊戲資訊，發現錯誤而發起的申訴”， 在此類別之中包含