• 沒有找到結果。

實現在每秒交易數量有限之公有區塊鏈下可稽核的彩票系統

N/A
N/A
Protected

Academic year: 2021

Share "實現在每秒交易數量有限之公有區塊鏈下可稽核的彩票系統"

Copied!
58
0
0

加載中.... (立即查看全文)

全文

(1)國立臺灣師範大學理學院 資訊工程學系 碩士論文. Department of Science and Information Engineering College of Science. National Taiwan Normal University Master’s Thesis. 實現在每秒交易數量有限之公有區塊鏈下 可稽核的彩票系統 Implement an Auditable Lottery System On Blockchain with Limited Number of Transactions Per Second. 陸毅軒 Lu, Yi-Syuan. 指導教授:黃冠寰 博士 中華民國. 109. 年. July 2020. 7. 月.

(2) 致謝 就讀碩士班的二年就要即將邁入最後一幕,在這些日子裡學習到的處世態 度、報告呈現、實驗技術等等都由衷感謝黃冠寰老師的指導,感謝老師每一次 不厭其煩的教導做研究應有的態度、報告上的點評等等的概念傳授。 黃老師說「如果你懂一件事,你可以用很簡單的方式告訴別人」,當一個產 品、實驗數據經過繁複的研究、修正、結論等等的步驟,最重要的不只侷限於 自行研究的技術而已,該如何表達給大眾、給不知道的人,讓他能夠清楚的了 解,也能簡單的呈現出該技術的重要性,這也是整個研究很重要的部分。 除了老師的指導幫忙外,也感謝培均學長在我碩一時的課業幫助,並且讓 我對於區塊鏈、智能合約等等地研究技術有大幅度的進步,平時的論文報告也 能夠給我中心的建議以及提點不足、邏輯矛盾之處。同樣感謝在同一間實驗室 的同學們,麒翔、仲嘉、宏文、東霖、政佑、亦祥的大力幫助。 最後再次感謝黃冠寰教授,能夠在短短兩年時間內教導我如何從事”研究”所 需要的研究態度,我定會不負教授的指導,並保持在這兩年間的認真態度,在 未來的路上努力向前。 陸毅軒. 誌於. 國立臺灣師範大學資訊工程所 民國. i. 109 年 7 月.

(3) 摘要 在每秒交易數量有限之公有區塊鏈下可稽核的彩票系統 陸毅軒 彩票系統在全世界各個國家皆有運行,其中又以樂透彩券最為大家所熟知,藉 由玩家選號並基於一定規則進行抽獎的遊戲方式,最早能夠溯源到西元 13 世 紀,直至今日依舊盛行於世界各地。彩票系統的運作需要一筆龐大的資金做為 信用保障以及獎金使用,使得彩票系統大多都由龐大的企業、金融業、政府所 舉辦。這種系統被單一組織機構所掌控稱為中心式架構系統,在彩票系統這種 需要公開規則、公開詳細資訊並講求公平性的博弈產業來說,中心式架構具有 一定的風險存在;民眾無法對政府、龐大企業要求有效的稽核方法,確定遊戲 過程沒有作弊行為。因此彩票系統憑藉著區塊鏈技術興起,在區塊鏈平台上建 立了去中心化的彩票系統,其中又以公有區塊鏈「比特幣」 [1]、「以太坊」 [2] 為主要開發平台。但是在公有區塊鏈上,每秒交易數量(TPS)因為共識決議程 序,而被限定在一定數值之內,以「以太坊」為例,每秒交易數量約為每秒 10 筆交易,如此的限制將會影響彩票系統的使用人數,以台灣彩券 [3]每期、每三 日約有 200 萬比投注來計算,將會佔據 70% 以太坊區塊鏈頻寬,更不用說美國 MegaMillions Lottery [4]每期、每三日約 1000 萬筆投注,將會使區塊鏈造成嚴重 壅塞。. ii.

(4) 因此我們提出了基於以太坊區塊鏈智能合約,並搭配鏈下遊戲供應商的遊戲方 式,能夠負荷超過千萬筆投注,且能進行遊戲資訊稽核、自動賠償機制卻只會 占據約十萬分之一區塊鏈頻寬的彩票系統,達成更有效且可實踐的區塊鏈彩票 系統。. 關鍵字:樂透、區塊鏈、智能合約、自動賠償. iii.

(5) Abstract Implement an Auditable Lottery System On Blockchain with Limited Number of Transactions Per Second Lu, Yi-Syuan The gambling system operates in various countries around the world, among which lottery tickets are the most well-known. The game method of lottery which is select numbers by player and following some special rules, it can be traced back to the 13th century AD as early as today and is still popular in the world now. The operation of the lottery system requires a large amount of funds for credit protection and bonus use, making the lottery system mostly organized by huge enterprises, financial industries, and governments. Such a system is called a centralized architecture system controlled by a single organization. In the lottery system, a game industry that requires open rules, detailed information, and fairness, the centralized architecture has certain risks; the public cannot require government or huge enterprises to provide an effective auditing methods to ensure that there is no cheating in the game. Therefore, with the rise of blockchain technology, the lottery system has established a decentralized lottery system on the blockchain platform. Among them, the public blockchains "Bitcoin" [1] and "Ethereum" [2] are the main ones. However, on the public blockchain, the number of transactions per second (TPS) is limited to a value due to the consensus resolution iv.

(6) process. Taking Ethereum as an example, the number of transactions per second is about 10 transactions per second. The limit will affect the number of users of the lottery system. Based on the Taiwan lottery [3], there are about 2 million bets per period in three days, which will occupy 70% of the Ethereum blockchain bandwidth, not to mention the US MegaMillions. Lottery [4] about 10 million bets per period in three days, that will cause serious congestion on the blockchain. Therefore, we propose a smart contract based on the Ethereum blockchain and a game method with an off-chain game provider, which can load more than 10 million bets, and can perform game information audit and automatic compensation mechanism, but only occupy about 1 in 100,000 blockchain bandwidth, that achieve a more effective and practical blockchain lottery system.. Keywords: Lottery, Blockchain, Smart Contract, Automatic Compensation. v.

(7) 目錄 致謝.................................................................................................................................. i 摘要................................................................................................................................. ii 目錄................................................................................................................................ vi 附表目錄........................................................................................................................ ix 附圖目錄......................................................................................................................... x 第一章 緒論................................................................................................................... 1 第一節 Lottery 彩票系統 ...................................................................................... 1 第二節 樂透彩票的問題....................................................................................... 1 第三節 台灣彩券與美國彩券的爭議................................................................... 2 第四節 解決方法................................................................................................... 3 第二章 去中心化系統................................................................................................... 3 第一節 中心式架構............................................................................................... 3 第二節 去中心式架構........................................................................................... 3 第三節 Blockchain 介紹 ....................................................................................... 4 第四節 以太坊....................................................................................................... 5 第五節 智能合約................................................................................................... 6 第三章 基於乙太坊智能合約的彩票系統................................................................... 7 第一節 在乙太坊上的彩票系統........................................................................... 7 第一段 BanFEL: A Blockchain Based Smart Contract for Fair and Efficient Lottery Scheme ............................................................................................... 7 第二段 Quanta Lottery .................................................................................. 9 第二節 區塊鏈彩票系統面臨的問題................................................................. 10 第一段 實驗數據遠低於實際投注總數..................................................... 11 vi.

(8) 第二段 無法提出有效的稽核與申訴......................................................... 11 第四章 可稽核的彩票系統......................................................................................... 12 第一節 系統架構................................................................................................. 12 第二節 Transaction Positioned Merkle Tree ....................................................... 13 第一段 Slice................................................................................................. 16 第二段 密碼學證據..................................................................................... 17 第三節 系統流程................................................................................................. 19 第一段 步驟 1 系統初始化........................................................................ 20 第二段 步驟 2、3、4 投注、回傳收據與紀錄資訊................................ 21 第三段 步驟 5、6、7 上傳獎金與 TP-Merkle 至 IPFS、索取密碼學證據 ....................................................................................................................... 23 第四段 步驟 8、9 稽核遊戲正確性與提起申訴...................................... 24 第一項 收據 M Reply 未被記錄在 TP Merkle tree 上 .......................... 26 第二項 序列號 SN 錯誤 ..................................................................... 27 第三項 定位使用的 PK_Index Player 錯誤 ........................................... 28 第四項 遊戲供應商上傳彩金不足..................................................... 29 第五項 累積投注金記錄錯誤............................................................. 30 第五段 步驟 10、11 上傳中獎號碼、領獎 .............................................. 31 第五章 實驗結果......................................................................................................... 33 第一節 環境說明................................................................................................. 33 第二節 TP Merkle Tree 前置說明 ...................................................................... 33 第三節 稽核所需時間......................................................................................... 36 第四節 消耗 Gas 的數量 .................................................................................... 37 第五節 與區塊鏈交互次數................................................................................. 43 第六章 結論與未來展望............................................................................................. 44 vii.

(9) 第一節 結論......................................................................................................... 44 第二節 未來展望................................................................................................. 44. viii.

(10) 附表目錄 表 5-1 TP Merkle Tree 碰撞測試 ................................................................ 33 表 5-2 TP Merkle Tree 對於玩家與遊戲供應商的硬碟儲存空間需求 .... 34 表 5-3 各項目稽核時間 ............................................................................. 36 表 5-4 樹高與驗證所需時間關係圖 ......................................................... 36 表 5-5 智能合約所需成本與 Gas 消耗表 .................................................. 37 表 5-6 樹高與所需成本和 Gas 消耗表 ..................................................... 40 表 5-7 與區塊鏈交互次數表 ..................................................................... 43. ix.

(11) 附圖目錄 圖 4-1 可稽核的彩票系統架構圖 .............................................................. 13 圖 4-2 TP Merkle Tree 結構 ........................................................................ 14 圖 4-3 Slice .................................................................................................. 16 圖 4-4 系統流程圖 ..................................................................................... 19 圖 4-5 投注階段流程圖 .............................................................................. 21 圖 6-1 樹高與需求空間分析圖 .................................................................. 36. x.

(12) 第一章 緒論 第一節 Lottery 彩票系統 彩票又稱為彩券,是一種賭博的形式,將印有號碼或圖形或文字供人們填寫、 選擇、購買並按特定規則取得中獎權利的憑證。在英國《不列顛百科全書》 [5]解 釋為「通過抽籤搖彩,憑機會在一定範圍的人們中分配獎品或獎金」 。當今世界上 共有 110 多個國家在發行彩票,按特徵分類主要有傳統型彩票(例:統一發票兌 獎) 、即開型彩票(例:刮刮樂) 、樂透型彩票(例:大樂透) 、數字型彩票(例: 三星彩) 。現行世界上彩票主要由政府當局或機構組織兩種形式。本文僅探討樂透 型彩券,並將其系統經過修改後使用於機構或組織且與公有區塊鏈進行互動。. 第二節 樂透彩票的問題 樂透彩在全球多個國家中運行,大多數由特定機構或是政府組織所掌控, 並為政府帶來額外的稅收,雖然每個國家運行的模式各不相同,但仍環繞於 「購買」、「開獎」、「領獎」等等程序。在「開獎」程序,中獎資訊由特定機構 或是政府組織所決定,此兩單位聲稱依循特定規範、法律公開必要的資訊,但 其開獎系統背後仍以中心式架構運行,使開獎行為必要的「隨機性」仍以單一 方面進行決定,無法對其「隨機性」進行檢驗。在「領獎」程序上,依照各個 政府法規,有保護中獎人資訊而隱藏相關資訊,也有必須公開身分資訊才能領 獎的規定。此兩種模式皆有運行在不同的地區,下一節會以兩個例子來做此問. 1.

(13) 題的說明。. 第三節 台灣彩券與美國彩券的爭議 以美國為例,美國雖有不同州政府且運行不同種類的彩票系統,但皆運行 必須公開身分才得以領獎的模式,衍伸出中獎者個人資料外洩,進而造成人身 安全問題,甚至需要委外第三方信託機構才能夠安心領獎,且有美國公民控告 政府機關以保護個人資料的案例。 以台灣為例,台灣彩券運行保護中獎人資訊並隱藏的行為下,進而衍伸出 「中獎人是否為實際玩家」的問題,也就是當彩票系統開獎累積金額達到一定 數量時,必會出現一名中獎者的疑慮,基於政府以及其所制定的法規之下,這 個疑慮便無從得以驗證,甚至進而懷疑是否有特定人士中獎、是否有其得獎人 等等具有爭議的說法。 目前在台灣所運行的彩票系統,主要是由「台灣彩券」所營運,並且為台 灣銀行「中國信託金融控股公司」的子公司,自 2007 年開始至今受到政府委託 負責辦理公益彩券業務。在 2016 年 5 月,當時的台灣彩券總經理黃志宜表示自 己親眼會面過超過 100 位頭獎得獎者,還表示財政部與台灣彩券都有公益彩券 高額中獎人的個人資料,承辦人員皆有簽屬保密協議,只有高階主管、中信商 銀理財規劃師和現場兌獎承辦人員,不會超過 5 人。2017 年 4 月,台灣彩券在 媒體上推出標題為「頭獎故事」新聞專題報導 [6],並揭露一部分中獎者的職業 背景,令民眾起疑是不是真有其得獎者,職業背景是否正確等等疑慮。 2.

(14) 第四節 解決方法 我們需要解決公平的第三方進行判斷與驗證隨機數的問題,還需要解決系統 導致區塊鏈壅塞、遊戲的公開性與公平性問題。所以我們研究了去中心化的區塊 鏈系統 [7],我們會在下一章說明去中心化系統,有了去中心化系統,我們可以透 過此系統來達到彩票系統地的投注、領獎等等程序,並利用區塊鏈的特殊協議來 達成快速理賠機制,一但問題發生,可以靠去中心化系統去判斷對錯,接著在運 用數位貨幣的交易來完成申訴賠償,這樣便可以達成可稽核、可申訴、低使用頻 寬、負荷大量玩家的線上彩票系統。. 第二章 去中心化系統 第一節 中心式架構 中心式架構,顧名思義由一單方機構、組織、機器、人員掌控某一系統的 所有運作,包含前端服務、資料傳遞、後端處理、資料儲存等等行為,此一種 系統運行方式即稱為”中心式架構”。在”去中心化”此專有名詞尚未被使用之前, 中心式架構已經普遍存在於世界各國,最具代表性的實際案例即為政府營運的 服務系統。當然,任何一個企業開發的服務,也普遍性為中心式架構,都是由 政府或是單一企業組織管理整個系統流程。. 第二節 去中心式架構 相較於前一節所提及的中心式架構,”去中心式”只能出現在擁有眾多用戶系. 3.

(15) 統中,每個用戶都可以互相連接並影響其他用戶,這種扁平化結構,稱之為“去 中心化”。在去中心化的架構中,不再有某一單位、政府、組織擁有資料、行為 控制的權力,而是讓每一位用戶都能夠執行資料傳遞、服務行為等等。去中心 式架構最具代表性的實際應用像是 Peer-to-Peer 網路。. 第三節 Blockchain 介紹 區塊鏈(blockchain),是一個創新時代的記帳技術,它讓每一筆交易都存在每 個節點中,資料公開透明又很安全,又稱為分散式帳本技術,區塊鏈就是去中心 式架構最好的範例。區塊鏈靠著強大的密碼學技術來完成,像是雜湊、加密、工 作量證明(Proof of work)、數位簽章…等,讓他人難以有造假的可能,使得區塊鏈 有強大的安全性。又因為它是去中心式架構,任何一個人若要更動、新增資料至 區塊鏈,必須同步發送給在區塊鏈上的其他所有用戶,並且得到驗證、確認核可 後才能進行操作,此一舉動讓所有在區塊鏈的資料皆為公開透明的。 區塊鏈的起源來自 2008 年由中本聰(Satoshi Nakamoto)的人提出,透過 Peerto-Peer 的網路技術,加密演算法、時間戳、電子簽章、共識決等等一連串的資料 加密、互相確保資料一致性方法,當這些結合在一起後,而產生比特幣區塊鏈。 區塊鏈是一個去中心式架構的資料庫,並且不限定任何用戶,每個用戶都可 以參與這個系統中,並且透過共識機制、競爭計算來共同維護整個區塊,達成資 料一致性。即使有些節點失去了功能,也不影響這個區塊的安全性,因為資料將 儲存於每一位用戶節點當中。每個用戶節點之間透過數位簽章技術進行稽核,所 4.

(16) 以無須彼此信任,用戶節點之間也無法做到欺騙的手段。區塊鏈上的任何資料都 是公開的,但用戶節點之間無須公開身分,如果遇到有惡意的攻擊者想要攻擊這 個區塊鏈,是難以實行的,必須掌握掌握 51%的節點數量同時發動攻擊,在共識 決時將錯誤有害的資料變為正確的資料才能夠攻擊成功,因此這些交易是極難以 被篡改的。當交易被記錄到區塊鏈是就會永遠的保存下來。. 第四節 以太坊 以太坊(Ethereum) 是一個公共區塊鏈平台,運行的加密貨幣為以太幣,使用 者可以在上面進行交易、撰寫與發佈程式(智能合約)來發展多元化的應用,國外 已經有非常多團隊利用智能合約來打造服務(如 Quanta 等等),在 Ethereum 裡面 智能合約通過去中心化的虛擬機器稱為「以太虛擬機」Ethereum Virtual Machine 來處理合約,Ethereum 的概念首次在 2013~2014 年間,被程式設計師 Vitalik Buterin 提出,並在 2015 年啟動 Ethereum Public Chain。 目前以太坊的交易速度,平均每秒 10 筆交易,以信用卡公司 Visa 作比較, Visa 的交易速度是每秒 1,667 筆,相差 160 倍的數據,由於區塊鏈使用共識機制 在保護資料一致性,每一次的交易都會經過此共識機制做確認以及稽核,故拖慢 整體交易速度。 以太坊目前採用的工作量證明(Proof-of-Work),工作量證明共識機制,共識機 制皆有一個特點就是運算困難,驗證容易;乙太坊區塊鏈採用了 SHA-256 去運 算 Hash 值,在 PoW 中,每個用戶節點節點比拼運算能力,看哪一個用戶節點 5.

(17) 節點優先計算出本次區塊的難題,就能將自己所驗證的交易打包成區塊放置區塊 鏈上,此一行為被稱之為”挖礦”,最先算出難題而得到放置區塊權力的用戶節點 節點將會取得交易所需要付的部分手續費,也因此在共識機制上會有競爭產生。 目前區塊鏈技術不斷在改革,要解決交易速度過慢,還有儲存空間不斷膨脹 的問題,還有許多匿名跟法律的問題,即使至今仍有大量的科學家、研究者都在 試圖解決區塊鏈的問題,希望在區塊鏈上能夠有更好的應用、更快的速度以及更 低的成本營運。. 第五節 智能合約 一個建立在以太坊之上的特殊協議被稱為智能合約 [8],智能合約是基於現 實數據自動執行的數位協議,用戶節點可以在其撰寫程式語法,來寫一個程式結 構,來達到各種應用,由於乙太坊區塊鏈為去中心式架構,故此智能合約並非所 謂的中心式機器。每一次智能合約的動作,皆是自動執行,其執行結果亦為一個 交易,也必須經由礦工進行共識決來將其結果放上區塊鏈。 分散式應用程式(DApp),是依賴以太坊區塊鏈上智能合約的應用程式,開發 人員可以在以太坊的區塊鏈基礎架構之上建立 DApp,來達成各種與普通使用者 的任何互動,而不必親自使用區塊鏈的帳戶、轉帳等等功能。直至今日智能合約 的應用在現實世界中已經非常多種,本篇論文將使用智能合約進行開發彩票系統, 達成可稽核、可申訴之目的,此一稽核申訴的作法參照 Blockchain-based Automatic Indemnification Mechanism [9]的概念,並對其中的 Protocol 進行必要的修改以符 6.

(18) 合本系統的需求,詳細的傳輸內容以及申訴方式會在本文第四章進行詳細說明。. 第三章 基於乙太坊智能合約的彩票系統 第一節 在乙太坊上的彩票系統 區塊鏈平台擁有資料不可竄改、資料公開透明、不易被攻擊等等特性,對 於博弈產業的產業特性,有高度的需求重疊,也就是說博弈產業相對於其他產 業來說,在區塊鏈上發展的機會是高於其他產業的。我們能夠利用區塊鏈不可 竄改的特性來保證不會有惡意賭博、竄改賭注等等的事件發生;資料透明公開 性亦可保證在博弈的過程中沒有任意一方舞弊,因此對於企業方或是玩家方都 能夠做到完整的保護。接下來本論文將介紹兩種使用乙太坊區塊鏈作為平台的 樂透遊戲,並且對其進行分析與評估,在下一節將會提出我們對於區塊鏈樂透 遊戲的幾個問題。. 第一段 BanFEL: A Blockchain Based Smart Contract for Fair and Efficient Lottery Scheme BanFEL [10]在 2019 年由 Hangzhou 所提出,文中提出的二種貢獻包括創造 公平的隨機數與向智能合約提出投注請求,針對此二點我們將進行分析並評估 其可行性。 BanFEL 系統以智能合約作為投注平台並以 1000 名玩家作為限制,玩家將平面 座標一點(X,Y)進行雜湊計算繳交至智能合約上記錄,當購買時間結束,再由玩. 7.

(19) 家將當初選定的(X,Y)揭示至智能合約以確保沒有玩家作弊,在此智能合約將會 派發一序列號 SN 作為標記中獎之用。在開獎部份,BanFEL 提出一種隨機數產 生方式,使用各個玩家的(Xi,Yi)進行計算,利用 Euler-Lagrange equation [11]對其 進行運算,可以找到一個方程式 F(x) = a0 + a1 * x + a2 * x^2 + a3 * x^3 + …. + an * x^n 符合所有玩家提出的(X,Y),得到所有在 F(x)內的係數,並以此係數作為 隨機數使用,當玩家所得的序列號 SN = F(a0 | a1… | an) mod 1000 即為中獎。每 一位玩家皆可以用 F(xi) = yi 的方式對每一個隨機數進行驗證。 對於 BanFEL 系統,有兩大問題必須解決,首先是計算隨機數的成本過高, 在文中提出計算隨機數必須要 O(n^3+n)的時間複雜度,對於大量玩家的彩票系 統來說,此時間複雜度是非常龐大的,若以 BanFEL 提出的實驗數據 10000 人, 產生隨機數所需時間雖然沒有在論文中所提到,在此若以 10000 名玩家資料進 行 Euler-Lagrange equation 計算,假設一名玩家固定需要 1us 帶入方程,則隨機 數產生就要約 1000000 秒共 11 天來計算隨機數,但這充其量是在 10000 名玩家 底下的狀況,與台灣運行的彩券每期平均 200 萬位玩家來看,根本是無法實現 的。 再來是玩家向智能合約投注的系統流程,對於乙太坊區塊鏈平台來說是非 常大的負荷,以目前以太坊 TPS 10 的狀態來說,一日最多交易量大約為 90 萬 筆,以台灣彩券 3 日一期為例,一次遊戲將佔據 74%區塊鏈頻寬,導致其他區 塊鏈應用出現壅塞的情況,此種現象對於區塊鏈平台將會造成非常嚴重的影 8.

(20) 響。. 第二段 Quanta Lottery Quanta [12]是目前在生活中有實踐的區塊鏈彩票系統,Quanta 在 2015 年開 始投入博弈產業並在區塊鏈上進行研究,Quanta Lottery 在 2018 年被發表出來, 它也是全球第一家獲得牌照的區塊鏈彩票公司,是由曼島賭博業監管委員會頒 發博彩牌照。它的系統主要分成投注與隨機數產生兩個部份,並在乙太坊區塊 鏈上運行,它也有運行 ERC20 的標準發行 Token,這個 Token 是用來參與隨機 數產生的。Quanta 的隨機數生成技術是讓每個使用 Token 的玩家選擇一個號 碼,並將這些號碼進行雜湊運算,與 BanFEL 一樣,玩家必須在一定時間內揭示 它所選擇的號碼讓其他玩家進行驗證,最後 Quanta 在將這些數字進行簡單運算 成為中獎號碼。 對於 Quanta 所實施的系統,他並沒有像 BanFEL 隨機數產生有嚴重的時間 複雜度問題,但是在開獎號碼計算上仍有一些疑慮,根據 Quanta White Paper 的 論述,持有 Token 並且聲明參與隨機數產生的人才能進行開獎號碼的產生,又 由於 Quanta 發行的 Token 並非向所有玩家販售,而是向一些 Quanta 會員與公司 贊助者進行販售,在此可能就會有彼此勾串之疑慮。再來是 Quanta 每一期的遊 戲約 5000 至 50000 人進行參與,離實際生活上的玩家總數有巨大的差距,雖然 Quanta 並沒有清楚表示如何與智能合約進行投注,但在與智能合約的互動,就 會有與 BanFEL 一樣的問題產生。Quanta 並沒有發表每一次遊玩所需的時間成 9.

(21) 本,但相較於 BanFEL 來說應是極小的。. 第二節 區塊鏈彩票系統面臨的問題 從以上兩個區塊鏈彩票、樂透系統可以得知,雖然實際上是可以運行的, 但是就生活層面上無法完全取代以往的中心式彩票系統,主要原因在於玩家的 數量無法跟上現有中心式彩票系統的人數,距離完美運行區塊鏈彩票系統仍有 一段距離需要克服,在此我們提出三點區塊鏈彩票系統會遇到的問題以及其帶 來的影響,並且在下一章提出解決方法。. 第一段 大量玩家投注導致區塊鏈頻寬壅塞 由上一節所提 BanFEL 與 Quanta 可以得知,當任何系統會有大量人數湧入 區塊鏈進行交易動作的時候,有極大可能會造成區塊鏈的壅塞甚至崩壞。以乙 太坊區塊鏈 TPS 只有 10 的狀況之下,一周內最多只能容納約 600 萬的交易數 量,因為此有限的每秒交易數量,導致像是此種樂透博奕遊戲無法發展得更加 茁壯,亦不能廣泛使用在各個國家。 我們兩個彩票系統為例,第一個是台灣彩券,台灣人口約 2300 萬人,每一 期台灣彩券有 3 日時間進行投注,每一期投注總數大約為 200 萬注,若要將台 灣彩券使用在乙太坊區塊鏈上,以精確數字來算,3 日的交易數量總額大約為 270 萬筆,光是台灣彩券就必須使用超過 74%的乙太坊區塊鏈頻寬,在現今區塊 鏈產業在多方面皆有應用的局勢下,佔據如此大的區塊鏈頻寬將會導致整個區 塊鏈產業停擺,全世界的乙太坊區塊鏈節點花費大量運算力在處理彩票系統 10.

(22) 上,故此種樂透博弈遊戲並不適合與乙太坊區塊鏈智能合約做直接的互動。 第二個是美國彩券 MegaMillion,美國總共約 3.2 億人,MegaMillion 每一期 的投注時間也是 3 日,每一期的總注數超過 1000 萬以上,基於前面的敘述, 1000 萬筆投注資訊是絕對不可能被乙太坊區塊鏈平台給消化完畢,因此區塊鏈 彩票系統需要更完善的優化,大幅降低實際所使用的區塊鏈頻寬,才能在此種 博弈產業上有更好的發展。. 第一段 實驗數據遠低於實際投注總數 BanFEL 以及 Quanta 彩票系統,每一期遊玩人數大約為 1000 至 50000 人, 這是在文內皆有詳細規定的,此舉對於”樂透”博奕遊戲的宗旨相繼違背,"樂透” 的最主要遊玩方式極為大量的玩家進行投注,用抽獎的方式去決定誰是中獎玩 家,獎金最終由極少數人取得。若在此去限制遊玩人數,不只無法將區塊鏈公 開透明、不可竄改的優勢帶到實際生活層面,更有可能淪為直銷、傳銷、非法 投資、非法吸金的商品。故區塊鏈彩票系統應該要能夠容納大量玩家,將以往 中心式架構彩票系統的問題解決,而非在小眾區域內發展。. 第二段 無法提出有效的稽核與申訴 即便在區塊鏈資料公開透明、具有高度不可竄改的特性,仍有其相對應的 缺點存在,就因為區塊鏈是分散式的儲存系統,導致在區塊鏈上執行的結果不 正常時,如果礦工並沒有及時發現,就會導致不可逆的危機。此種情況在乙太 坊區塊鏈智能合約中又顯得更加重要,因為智能合約的執行與使用者的互動距 11.

(23) 離相對於普通發送交易來說相對的更加接近,以致受到惡意攻擊的機會也大幅 度增加本篇論文探討的區塊鏈彩票系統是以龐大的資金作為基礎架構,在惡意 攻擊的防範上便顯得更為重要。 在上一節所提及的區塊鏈彩票系統 BanFEL 與 Quanta 並沒有實質的對於稽 核或申訴整體遊戲做出明確的規範以及方法,此舉使得區塊鏈彩票系統依然有 中心式彩票的單一方控制整體遊戲的缺點。為有效提升彩票系統的安全性以及 公平性,稽核整體遊戲將會是其必要手段,公開所有投注資料供遊玩者進行稽 查,並能隨時提出遊戲錯誤的申訴,在遊戲發生錯誤的第一時間便能告知所有 玩家以及遊戲服務商做進一步的處理,以避免遊戲流程結束後造成的不可逆結 果致使整體系統崩潰。. 第四章 可稽核的彩票系統 第一節 系統架構 在本章節會說明可稽核的彩票系統的每一個運作階段、資料流以及對彩票系 統的稽核流程,並詳細說明相關技術與申訴情境、申訴方法。並會在下一章節提 出依據本系統所做的實驗環境與實驗結果。 首先我們要先說明系統架構如下圖 4-1,這個系統主要分為三大重要腳色進 行互動,分別為 1. 玩家(Player) 2. 遊戲供應商(Service Provide Organization) 3. 智 能合約(Smart Contract),我們能夠看到遊戲的基礎設將是以玩家向遊戲供應商進. 12.

(24) 行 投注的動作,遊戲供應商將會在投注結束後,把此次投注的累積的總獎金換算為 等值的加密貨幣轉帳至智能合約中,並會上傳一組中獎號碼至智能合約,接下來 玩家將可以在智能合約上進行兌獎的動作。圖 4-1 為本系統最基礎的建構設施說 明,在下一節中將會詳細介紹每一個腳色之間資料交流的詳細項目,以及所需應 用到的相關技術。. 圖 4-1 可稽核的彩票系統架構圖. 第二節 Transaction Positioned Merkle Tree 由於彩票系統的遊玩人數將會非常龐大,我們需要一個技術將玩家們的投 注資訊進行整理儲存,並且可以透過有效的方式對投注資訊進行稽核,在申訴 時也能取出證據使智能合約能夠做出正確的判斷,在這邊我們採用 TP Merkle Tree (Transaction Positioned Merkle Tree) [13],它是由 ITM 國際信任機器在 2019 13.

(25) 年所提出的樹狀結構,他是一個 FBHTree (Full Binary Hash Tree) ,FBHTree 是 一個二元樹的資料結構,樹的結構可以分成三個部分:葉節點、內部節點、根部 節點,這個樹狀結構最早是由 Proof Of Violation [14]所使用,其憑藉著 Hash Function 搭配上完滿二元樹,可以用一筆 32Bytes 的 Hash 值來驗證樹底下的 100 萬筆資料是否有被竄改,TP Merkle Tree 基於此種技術做了傳輸 Protocol 修正與 應用。如下面圖(2)是一個 4 層的 TP Merkle Tree 資料結構。. 圖 4-2 TP Merkle Tree. 結構. Key-Value = Hash(Index) | Receipt Key-Value Pair List = Key-Value 1st -> Key-Value 2nd-> …-> Key-Value Nth Leaf node = Hash(Key-Value Pair List) Internal node, Root node = Hash(Left child node | Right child node) 接著開始說明 TP Merkle Tree 的運作原理,TP Merkle Tree 在建立之前,會先 依照需要放置資料的數量來決定樹的高度,如果資料總量為 N,如果樹的高度 H 是則是H = 𝐿𝑜𝑔2 𝑁,總共會有 2H-1 個節點與 2H-1 的葉子節點。 14.

(26) 葉子節點(Leaf node)是由 Key-Value 的集合產生的 Key-Value Pair List 並進行 Hash 運算所得出來的結果,Key-Value 將是把某一個玩家的個人身分的公開金鑰 資訊 PK(Public Key)當作 Key 值,並將其與某一個序列化的 Index 數字進行合併, 合併完再對其進行 Hash 的動作,Value 值則是將此玩家投注所產生的 Receipt,即 每個 Key-Value Pair 的形式如下(𝑷𝑲_𝑰𝒏𝒅𝒆𝒙 , 𝑹𝒆𝒄𝒆𝒊𝒑𝒕)。每當要存入一筆投注資 訊的時後,會用一個 Index function Γ 函式來計算對應的 Leaf node 位置,Index function Γ 的函式如下。 𝜞(𝑷𝑲_𝑰𝒏𝒅𝒆𝒙) = 𝑺𝑯𝑨𝟐𝟓𝟔(𝑷𝑲_𝑰𝒏𝒅𝒆𝒙) 𝒎𝒐𝒅 𝟐𝑵−𝟏 如果樹高是 H 的話,用Γ算出來的數值會介於 2H-1 至 1 之間,例如 Public Key 0xabcdef 與 Index 123 進行合併為 0xabcdef123,並透過Γ函式的計算後,得出來的 數值為 7 這筆投注資訊就會儲存在 Index = 7 的 Leaf node 中。 內節點(internal node)是由左子樹節點的 hash 值和右子樹節點的 hash 值,兩 數值合併並做一次 hash 的計算得出來的 hash 值,重複以上的動作,從葉子節點 開始往上做兩兩運算,最後會得到根節點的 hash 值,這個根節點的 hash 值,我 們稱此數值為這棵 TP Merkle Tree 的 Root hash,Root hash 將會使用在稽核以及申 訴部分 ,在下一段中將會說明如何使用 TP Merkle Tree 的節點組合 Slice 並將其運算至根 節點取得 Root Hash。. 15.

(27) 第一段 Slice Slice 在是 TP Merkle Tree 內的葉子節點、內部節點與根節點所組成的一個集 合,如下圖 4-3 所示,假設新的一筆投注資訊被放在 Index = 3 的葉子節點內,則 圖內所有實心點的集合便被稱作為 Slice。. 圖 4-3 Slice. Slice 的主要功能一共有兩項,第一項是當一筆新的投注資訊被插入至 TP Merkle Tree 中時,由於葉子節點的更動,使得 Slice 將會隨之更動,此舉的優點 在於當一筆新的資訊插入時,我們不用更動除了 Slice 以外的其他節點,便能達到 更新根節點值,降低更新 TP Merkle Tree 的運算量。第二項是玩家在投注階段結 束後,將可以從遊戲供應商端取得 Slice,以此去計算根節點值是否與遊戲供應商 所公告的根節點值相同,甚至到提起申訴階段,玩家依然可以使用 Slice 來向智能 合約進行申訴,便能達到稽核整體遊戲的效果。 Slice of TP Merkle Tree = Root node | Left Internal node | Right internal node |…| 16.

(28) Left Leaf node | Right Leaf node 每一個葉子節點的 Index = I 可以找出對應的 Slice(I),我們可以從樹底的葉 子節點向上追蹤到根節點,在這之中的父節點和兄弟節點都包含重要的 Hash 值, 這些全部 Hash 值我們將它們按順序儲存在一維陣列中,再透過兩兩合併與 Hash 計算,我們可以導出 Root hash。 因此,如果我們有一個 Slice(I),我們可以計算出一個 Root Hash 值,玩家將 可以用此 Slice 的計算結果,與遊戲供應商提供的 Root Hash 值進行比對,就能知 道說遊戲供應商提供的 Root Hash 值是否有出現錯誤的現象,或是延伸出其他遊 戲錯誤,玩家將能以 Slice 作為其中一個密碼學證據向智能合約提出申訴請求。. 第二段 密碼學證據 自前一段 Slice 進行了介紹,可以知道我們使用 Slice 可以從 TP Merkle Tree 的葉子節點開始計算,直至根節點的 Hash 值,我們便可利用這個 Root Hash 值 來確定在 TP Merkle Tree 內的資料是否有更動過,又或者是確定資料有被放入 TP Merkle Tree 之中。 除了透過 Slice 對 TP Merkle Tree 的 Root Hash 進行核對以外,存在於葉子 節點中的 Key-Value 依然是決定整個 TP Merkle Tree 正確與否的焦點,因此若要 詳細的比對資料的正確性,必須將葉子節點中的內容一同取出,將裡面的 KeyValue Pair List,同樣做 Hash 的運算過後再與 Slice、Root Hash 進行比對,可以 提升整體的正確性。否則可能將會出現資料在 Key-Value Pair List 中遺失的可能 17.

(29) 性。 在本篇論文中,可稽核的彩票系統在多個階段運用了密碼學證據來進行比 對,以確保遊戲供應商在遊戲過程中沒有出現缺失、惡意攻擊。在往後的章節 中所使用的密碼學證據將由以下幾個資料所組合而成: 1. Slice 2. Key-Value Pair List 3. Clearance Order 以及遊戲供應商對此資料組合所做的電子簽章。Slice 主 要能將玩家的投注資訊與本次遊戲使用 TP Merkle Tree 做連接,確保玩家索取到 的 Slice 與遊戲供應商儲存遊戲資訊的 TP Merkle Tree 是同一棵樹,如同上述我 們能將 Root Hash 進行比對便能確保此次的遊戲程序無誤。Key-Value Pair List 內 將存放除了自己以外的投注資訊,由於 Key-Value Pair List 是葉子節點的主要內 容,因此取得 Key-Value Pair List 後,再透過合併以及 Hash 計算過後,便能取 得葉子節點的 Hash 值,此值將會被放在 Slice 中,我們就能進一步比對 Slice 中 的值是否有包含此葉子節點的 Hash 值,玩家便能自行比對自己的投注資訊是否 有正確的被放在葉子節點、TP Merkle Tree 之中。Clearance Order 就是將以上的 Slice、Key-Value Pair 與某一個場次的遊戲做直接的關聯,以確保在日後申訴時 不會有惡意攻擊的出現。密碼學證據將會把此三種資訊做合併後,在附上遊戲 供應商的電子簽章,以確保密碼學證據是經由遊戲供應商正確提供,而非自行 竄改的結果。密碼學證據並不會在玩家投注時就取得,而是至遊戲清算 TPMerkle Tree 時才開放與遊戲供應商進行索取,詳細的流程將會在第三節進行說 明。 18.

(30) 第三節 系統流程 可稽核的彩票系統在每一次進行遊戲時將會經過以下步驟 1 至步驟 10,分 別為:1.系統初始化、2.投注、3.回傳收據、4.紀錄投注資訊 5.上傳獎金與中獎 號碼、6.傳送 TP Merkle Tree 至 IPFS、7.玩家索取密碼學證據、8.稽核遊戲正確 性、9.提起申訴、10.領獎,整體的遊戲規範並沒有強制要求,即符合彩票彩券 的形式皆可以運用此系統進行開發,由於投注時是向遊戲供應商進行投注,故 並不限定使用區塊鏈的加密貨幣,此舉可以大幅度增加與現實彩票系統的銜接 性,以及增進投注效率。. 圖 4-4 系統流程圖. 在本篇論文中將會提及幾個系統運作時所運用的名詞,這些名詞在往後的 章節中將會頻繁出現,為避免繁複多重的解釋故在此對這些使用的名詞做初步 定義。 1. 保證金:保證金為確保遊戲正確進行,遊戲供應商將會上傳一筆巨額的加密 貨幣至智能合約 Smart Contract 中做擔保,若往後系統的流程中有出現錯誤,投 19.

(31) 注資訊有出現紕漏,玩家皆可將自己的密碼學證據上傳至智能合約,取走保證 金。 2. 賠償金:賠償金為玩家經由向智能合約提出申訴後,智能合約會依據上傳的 投注資訊、密碼學證據進行判讀,確認錯誤是遊戲供應商所產生後,轉帳一筆 加密貨幣給提出申訴的玩家,此一加密貨幣就是賠償金。賠償金的金額主要來 源為上一項目所提及的保證金。 3.投注金:投注金為玩家在投注階段向遊戲供應商投注所支付的貨幣,此一貨幣 不限定為加密貨幣,為增進與實際上的彩票系統做連結,投注的方法可以運用 現金、線上支付、ATM 轉帳、信用卡支付等等普通的支付系統。 4.彩金:彩金為遊戲供應商在清算 TP-Merkle Tree 完成後,會將與投注金總額等 值的加密貨幣上傳至智能合約中,此加密貨幣將會在往後開獎中被當作彩金轉 帳給得獎者。. 第一段 步驟 1 系統初始化 在進入系統初始化之前,遊戲供應商會先將彩票系統所使用的智能合約部 屬上區塊鏈,並且開始與智能合約互動。在系統初始化時,遊戲供應商將會公 告本次遊戲所使用的開獎號碼取用來源,以供所有玩家進行審閱,玩家可以依 照遊戲供應商所提供的資訊進行審查,再決定是否與遊戲供應商進行遊戲。關 於開獎號碼取用來源,在本節之第五段領獎階段將會有詳細的說明以及建議。 再來遊戲供應商將會到智能合約中檢查保證金是否充足,此一保證金的價值必 20.

(32) 須遠高於單一彩票的價值,用以對遊戲的保證。若在智能合約上的保證金不 足,遊戲供應商必須補充。. 第二段 步驟 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. 21.

(33) 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 上下,依照玩家的 22.

(34) 選號長度、大小將會有些微的差距。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。 在階段的最後,遊戲供應商將要開放所有參與遊戲的玩家索取密碼學證據, 以利於往後的中獎登記、稽核與申訴。在此所提及的密碼學證據與本章第二節所 23.

(35) 提到的密碼學證據相同,但有加入其他必要資訊,而整體的密碼學證據架構如下 ( 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 並取得內部的所有收據來進行稽核後, 如果沒有發現任何問題,便可以至智能合約中宣告此次的遊戲是正常無誤的, 當然此一動作也必須附上押金,智能合約會在時限之內開放稽核正確登記,最 24.

(36) 後若沒有其他玩家、其他稽核員提起任何一個因遊戲資訊錯誤而發起的申訴的 話,前三名至智能合約登記的稽核員將可以在智能合約中提領到一筆稽核獎 金。相反的若是有人提起申訴成功的話,及證明此次稽核是有問題的,會沒收 掉當初公開稽核時進行登記所需要的押金,此筆押金將會一同與保證金轉帳給 發現錯誤的人。 在申訴部分詳細說明之前,必須先提出三個情境假設如下: 1. 遊戲供應商一定會將 TP Merkle Tree 上傳至 IPFS,且 IPFS 將會完整保存此筆 檔案,不會遺失。. 2. 遊戲供應商將與智能合約持續互動,推動整個遊戲流程,亦即上傳中獎 號碼、獎金等等必要行動 3. 玩家在步驟 7 時會與遊戲供應商索取密碼學證據,此一密碼學證據一定 可以取得。 若以上三點未達成的話,將可以視為遊戲供應商捲款潛逃,玩家可以透過法律 途徑提出抗告。申訴部分將會細分成兩大類的申訴與五項的申訴情境與申訴辦 法,第一大類為”玩家權益受到損害而發起的申訴”,在此類別之中包含以下情 形: 1.. 收據 M Reply 未被記錄在 TP Merkle tree 上. 第二大類為”公開稽核遊戲資訊,發現錯誤而發起的申訴”, 在此類別之中包含 以下情形: 25.

(37) 1.. 序列號 SN 錯誤. 2.. 定位使用的 PK Index 錯誤. 3.. 遊戲供應商上傳彩金不足. 4.. 累積投注金記錄錯誤. 以上四種申訴情境會在接下來的文章中進行詳細的說明,以及其申訴辦法,最 後在下一章便會呈現其實驗結果、所需要的 Gas 消耗量與時間等等。. 第一項 收據 M Reply 未被記錄在 TP Merkle tree 上 此一種錯誤情境會在投注階段發生,在清算 TP-Merkle Tree 時玩家向遊戲供 應商索取密碼學證據的時候就會發現這個錯誤。其定義為遊戲供應商在接受玩 家的投注資訊之後,必須產生一個遊戲收據並把它放入 TP Merkle Tree 做紀錄, 此種錯誤也許是因為不可抗力或是系統疏失而導致遊戲收據並未存在於 TP Merkle Tree 中。實際的申訴步驟如下: 1. 玩家自步驟 7 取得本次投注的密碼學證據。 2. 玩家自行比對密碼學證據中的 List of Key-Value Pair,並自行計算其 Hash 以比對 Slice 中是否存在此葉子節點。 3. 依照 TP Merkle Tree 計算規則,將 Slice 資訊計算出其根節點的 Hash 值。 4. 比對此 RootHash 值是否與智能合約上公布的 RootHash 值相同。 5. 若玩家在 List of Key-Value Pair 找不到自己的收據,而 Slice、Hash(List 26.

(38) of Key-Value Pair)、RootHash 皆與遊戲供應商公告的無誤的話,就能使 用遊戲收據、密碼學證據至智能合約提出申訴,並交付一定押金至智能 合約。 6. 智能合約將會計算密碼學證據的正確性,並比對玩家與遊戲供應商的電 子簽章。 7. 若申訴成功,則會轉帳一筆賠償金,並退還押金給該玩家,智能合約將 會記錄此次上傳的收據的 Hash 值,使它不能夠進行二次申訴。 8. 若申訴失敗,則會沒收其押金。. 第二項 序列號 SN 錯誤 此一種錯誤會在投注階段時發生,遊戲供應商將錯誤的序列號 SN 寫入某一 次玩家的投注收據中,隨後被放至 TP Merkle Tree,而此種錯誤會在稽核與申訴 階段被發現。任意一位使用者想要稽核本期遊戲的所有遊戲資訊,便可至 IPFS 取得遊戲供應商在步驟 6 上傳的 TP Merkle Tree,並提取內部的所有收據進行稽 核。如果有找到其中一張收據,其序列號有出現重複、跳號的狀況發生,便可 以將這張有問題的收據,以及其前一張收據上傳至智能合約進行申訴,實際的 申訴步驟如下: 1. 任意一位使用者至 IPFS 取得 TP Merkle Tree 2. 驗證其電子簽章是否無誤 3. 比對所有收據的序列號是否有誤 27.

(39) 4. 若找到錯誤,則上傳其收據以及前一張收據至智能合約進行申訴,並交 付一定押金。 5. 智能合約會進行比對收據使否有重複、跳號的狀況產生。 6. 若申訴成功,則會轉帳一筆賠償金,並退還押金給該玩家,智能合約將 會記錄此次上傳的收據的 Hash 值,使它不能夠進行二次申訴。 7. 若申訴失敗,則會沒收其押金。. 第三項 定位使用的 PK_Index Player 錯誤 此種錯誤將會在投注階段時發生,玩家在投注階段時即會表明自己的 PK Index,遊戲供應商應該要對此進行核對,才能接受此次投注。若遊戲供應商沒 有做到即時查核的動作便將此投注資訊接受之後,放至 TP Merkle Tree,則在稽 核與申訴階段就可以發現這個錯誤發生。若在 TP Merkle Tree 有找到其中一張收 據,其 PK Index 有出現重複、跳號的狀況發生,便可以將這張有問題的收據, 以及其前一張收據上傳至智能合約進行申訴,實際的申訴步驟如下: 1. 任意一位使用者至 IPFS 取得 TP Merkle Tree 2. 驗證其電子簽章是否無誤 3. 比對所有收據的 PK Index 是否有誤 4. 若找到錯誤,則上傳其收據以及前一張收據至智能合約進行申訴,並交 付一定押金。 5. 智能合約會進行比對收據是否有重複、跳號的狀況產生。 28.

(40) 6. 若申訴成功,則會轉帳一筆賠償金,並退還押金給該玩家,智能合約將 會記錄此次上傳的收據的 Hash 值,使它不能夠進行二次申訴。 7. 若申訴失敗,則會沒收其押金。. 第四項 遊戲供應商上傳彩金不足 此種申訴會在清算 TP-Merkle Tree 發生,遊戲供應商必須上傳 TP Merkle Tree 清算過後的 RootHash 以及彩金、本期最後一張彩票至智能合約中,其中, 在遊戲收據中將會記錄目前累積的投注金總額,在清算階段遊戲供應商必須將 這個累積投注金扣除抽成之後,依照一定比例轉換成加密貨幣上傳至智能合約 中,至此我們稱之為彩金。在稽核與提起申訴階段可以發現這個問題,任何想 稽核的人,可以在 TP Merkle Tree 有找到其中一張收據,其紀錄的累積投注金與 遊戲供應商上傳的彩金與出現差異時,便可以將這張有問題的收據上傳至智能 合約進行申訴,實際的申訴步驟如下: 1. 任意一位使用者至 IPFS 取得 TP Merkle Tree 2. 驗證其電子簽章是否無誤 3. 比對收據累積投注金與智能合約的彩金是否有誤 4. 若找到錯誤,則上傳其收據至智能合約進行申訴,並交付一定押金。 5. 智能合約會進行比對收據與智能合約裡的彩金是否出現差異。 6. 若申訴成功,則會轉帳一筆賠償金,並退還押金給該玩家,智能合約將 會記錄此次上傳的收據的 Hash 值,使它不能夠進行二次申訴。 29.

(41) 7. 若申訴失敗,則會沒收其押金。 必須注意的是,因加密貨幣與現實流通貨幣會有一定比值的差異,其差異是浮 動性的,在此遊戲供應商應自主規範,將投注金與彩金的轉換比例公開受所有 玩家、所有人進行稽核。. 第五項 累積投注金記錄錯誤 此一種錯誤會在投注階段時發生,遊戲供應商將錯誤的累積投注金紀錄寫 入某一次玩家的投注收據中,隨後被放至 TP Merkle Tree,而此種錯誤會在稽核 與申訴階段被發現。任意一位使用者想要稽核本期遊戲的所有遊戲資訊,便可 至 IPFS 取得遊戲供應商在步驟 6 上傳的 TP Merkle Tree,並提取內部的所有收 據進行稽核。如果有找到其中一張收據,其累積投注金有出現重複、跳號的狀 況發生,便可以將這張有問題的收據,以及其前一張收據上傳至智能合約進行 申訴,實際的申訴步驟如下: 1. 任意一位使用者至 IPFS 取得 TP Merkle Tree 2. 驗證其電子簽章是否無誤 3. 比對所有收據的累積投注金是否有誤 4. 若找到錯誤,則上傳其收據以及前一張收據至智能合約進行申訴,並交 付一定押金。 5. 智能合約會進行比對收據使否有重複、跳號的狀況產生。. 30.

(42) 6. 若申訴成功,則會轉帳一筆賠償金,並退還押金給該玩家,智能合約將 會記錄此次上傳的收據的 Hash 值,使它不能夠進行二次申訴。 7. 若申訴失敗,則會沒收其押金。. 第五段 步驟 10、11 上傳中獎號碼、領獎 此一階段可以與上一個稽核與提起申訴階段(步驟 6、7、8)同時進行。在領 獎階段時,遊戲供應商將在時間限制之內上傳一組中獎號碼至智能合約中開放 玩家進行比對,依照第一段所述,本文對於中獎號碼的選擇將提出幾種方案以 供參考,因為世上的隨機數有絕大部分都來自某一個偽隨機數的計算,也受隨 機的定義所局限,則在目前有效產生隨機數的方法之內,皆有可能被控制、被 破解的可能性存在,此一問題將會大幅威脅本系統的公正性,故遊戲供應商應 對本系統所使用的隨機數進行慎重的考量。在此本文提出三種隨機數選擇的方 案並且對他們的優缺點進行分析,其列舉如下: 1. 使用網路直播、電視轉播、現場錄影等等手段進行中獎號碼的選擇 2. 使用網路資訊、區塊鏈資訊等等公開資訊進行中獎號碼的選擇 3. 使用第三方不受少數人控制之資訊源進行中獎號碼的選擇 首先第一個方法採用實際的開獎方式,可以使用開獎機、號碼球、骰子等 等用具進行開獎,其優點就是過程簡單,公布影片等等的其他附加行動皆不會 帶來太多的額外成本。但仍然有著不可稽核的缺點,與本文第一章第二節所述 相同。 31.

(43) 再來第二種方法雖使用公開資訊可以達到稽核的特點,但網路資訊有其風 險,大多數網路服務都以某一個組織所維護、營運,若要取用其資訊當作中獎 號碼,就得承受被資訊服務來源控制的風險。若使用區塊鏈的資料,像是礦工 的公開金鑰、區塊的 Hash 值等等資訊,雖然達到分散式、可稽核兩個特點,但 是仍有被礦工勾串、強大算力攻擊的風險存在。 第三種是本文推薦的中獎號碼選擇方式,第三方的資訊源雖然可能被單一 組織控制,但仍有以多個資料組成且不受少數人控制的資訊存在,我們就以股 市資料為例,股市資料雖然是第三方資訊源,但其點數的產生依賴於每天的交 易數量、買與賣等等的交易行為,此交易行為是無法受少數人控制的,且在股 市的點數上若要做到控制的效果,必須付出一筆極其龐大的代價,因為其股市 股票皆為有價證券,此代價將會遠高於本系統的最大獲利。在此一特性上,本 文推薦使用股市資料做排列計算,計算出中獎號碼。 本系統的最後階段領獎階段,在上述的所有階段中若未出現巨大的問題, 都將在最後進入此階段中,此一階段將會開放一段時間讓玩家進行登記。玩家 可以藉由遊戲供應商在智能合約公開的中獎號碼來進行比對,看自己是不是中 獎人的其中之一。若玩家發現自己中獎了,則可以將投注收據與密碼學證據上 傳至智能合約進行中獎登記,智能合約會比對收據內的中獎號碼資訊以及密碼 學證據的有效性,若玩家為真正的中獎人,則在智能合約中會記錄此一玩家的 公開金鑰以及本次中獎收據的 Hash 值,使其不能夠進行二次領獎。在經過一定 32.

(44) 時間之後,將會停止中獎登記的功能,並且智能合約會開始計算所有中獎人的 人數,最後玩家將可以至智能合約中提取經過均分後的獎金,並在一定的時間 之內開啟下一次的遊戲。. 第五章 實驗結果 第一節 環境說明 實驗結果是在以太坊部署智能合約,我們使用了 Solidity 語言作為智能合約 的開發,部署到測試用區塊鏈 Ropsten Test Network 進行測試,並使用以太幣匯率 來分析金錢與 Gas 消耗量,整體系統以 Java 11 來實作,設備電腦作業系統為 Windows 10,處理器為 Intel(R) Core(TM) i5-7500CPU @3.40GHz,記憶體為 32GB。. 第二節 TP Merkle Tree 前置說明 TP Merkle Tree 資料結構使用 Index function Γ 來進行存放資料的定位,如果 同一個葉節點內的資料相當多的話,會影響到用戶稽核的時間與硬碟空間需求, 也進而影響到上傳密碼學證據至智能合約的 Gas 消耗量,因此,我們必須取用適 當的 TP Merkle Tree 樹高,觀察其放入資料後的碰撞結果,並在數據中取得最佳 使用方法。以下表 5-1 為實驗 Index function Γ,在一千萬筆資料下進行的碰撞測 試。 表 5-1 TP Merkle Tree. 樹高. 葉節點數. 碰撞測試 平均碰撞次數. 最小碰撞次數. 33. 最大碰撞次數.

(45) 17. 65,536. 152. 107. 209. 18. 131,072. 76. 44. 120. 19. 262,144. 38. 14. 72. 20. 524,288. 19. 3. 43. 21. 1,048,576. 10. 0. 30. 22. 2,097,152. 5. 0. 19. 23. 4,194,304. 3. 0. 13. 24. 8,388,608. 2. 0. 10. 25. 16,777,216. 1. 0. 8. 下表 5-2 的實驗數據在玩家所需要的硬碟儲存空間,是以本次投注總共一千 萬筆,其中一名玩家投注一次所需要的空間大小作計算,內容包含玩家本身的投 注資訊、遊戲供應商提供的遊戲收據以及玩家必須向遊戲供應商索取的密碼學證 據。故可以從數據內得知,當 TP Merkle Tree 樹高越高,玩家所需的空間會越小, 但相對遊戲供應商所需空間會變大。因本系統在稽核與申訴階段時,將會公開 TP Merkle Tree 已供稽核,故在 TP Merkle Tree 樹高的選擇,必須將網路傳輸時間考 慮進去 。在此實驗中,TP Merkle Tree 是透過 kryo 序列化 [18]技術將建構好的 TP Merkle Tree 輸出成一個檔案儲存在電腦當中。 表 5-2 TP Merkle Tree. 對於玩家與遊戲供應商的硬碟儲存空間需求 34.

(46) 樹高. 玩家. 遊戲供應商. 17. 24,199 Bytes. 1,519 MB. 18. 14,473 Bytes. 1,534 MB. 19. 9,257 Bytes. 1,564 MB. 20. 6,131 Bytes. 1,625 MB. 21. 4,765 Bytes. 1,747 MB. 22. 3,619 Bytes. 1,990 MB. 23. 3,023 Bytes. 2,476 MB. 24. 2,757 Bytes. 3,452 MB. 25. 2,601 Bytes. 5,372 MB. 如下圖 5-1 所示,可以發現在樹高 22 層時開始,玩家所需空間的下降曲線逐漸趨 緩,SPO 所需空間正準備進入指數上升階段。故可以判斷在樹高 22 層、23 層為 最佳取用樹高,玩家所需空間大約在 3 KB 上下,而稽核一整棵樹的所需空間落 在 2000 至 2500 MB。. 35.

(47) 硬碟儲存空間需求 (Bytes). (MB). 30000 25000. 5000. 24199. 20000. 4000. 3452 14473. 15000. 1519. 1534. 1564. 1625. 1747. 1990. 4765. 3619. 3023. 2757. 21. 22. 23. 24. 6131. 18. 19. 20. 2000. 1000. 0 17. 3000. 2476 9257. 10000. 5000. 6000. 5372. SPO所需空間…. 2601 25. 0. 樹高. 玩家所需空間…. 圖 6-1 樹高與需求空間分析圖. 第三節 稽核所需時間 在本系統的申訴與稽核階段,將會出現某一個稽核員想審查遊戲供應商公 開的遊戲資訊是否有錯,故如下表 5-3、5-4,稽核時間除了比對每一張遊戲收據 所需時間之外,還納入了將這些遊戲收據重新組成一棵樹的時間,進而比對遊 戲供應商所上傳的 RootHash 是否有所出入。 表 5-3 各項目稽核時間. 累積投注金. PK index 重複. PK index 跳號. SN 重複.跳號. 6,701 ms. 6,573 ms. 7,151 ms. 7,204 ms. 表 5-4 樹高與驗證所需時間關係圖. 樹高. 樹的空間. 驗證樹所需時間. 17. 1,519 MB. 270,224 ms. 36.

(48) 18. 1,534 MB. 281,299 ms. 19. 1,564 MB. 288,062 ms. 20. 1,625 MB. 298,347 ms. 21. 1,747 MB. 301,723 ms. 22. 1,990 MB. 326,931 ms. 23. 2,476 MB. 337,321 ms. 24. 3,452 MB. 396,338 ms. 25. 5,372 MB. 463,728 ms. 第四節 消耗 Gas 的數量 在本節中將會展現本系統智能合約的設計功能實際在區塊鏈上需要消耗多 少 Gas 以及設定為不同 Gas Price、換算為美金、台幣的實驗結果如下表 5-5。 Gas 即為在以太坊上所需要的計算量,Gas Price 是智能合約執行完畢後,請礦工 部屬上區塊鏈所需要的手續費。 表 5-5 智能合約所需成本與 Gas 消耗表. Function. 部屬合約. Gas 消耗. Gas Price. ETH. USD. TWD. MAX. 10. 0.04133255. 4.133255. 123.99765. AVG. 4. 0.01653302. 1.653302. 49.59906. 4,133,255. 37.

(49) MIN. 3. 0.012399765. 1.2399765. 37.199295. MAX. 10. 0.000259. 0.0259. 0.777. AVG. 4. 0.0001036. 0.01036. 0.3108. MIN. 3. 0.0000777. 0.00777. 0.2331. MAX. 10. 0.00047467. 0.047467. 1.42401. AVG. 4. 0.000189868. 0.0189868. 0.569604. MIN. 3. 0.000142401. 0.0142401. 0.427203. MAX. 10. 0.00129535. 0.129535. 3.88605. AVG. 4. 0.00051814. 0.051814. 1.55442. MIN. 3. 0.000388605. 0.0388605. 1.165815. MAX. 10. 0.00068844. 0.068844. 2.06532. AVG. 4. 0.000275376. 0.0275376. 0.826128. MIN. 3. 0.000206532. 0.0206532. 0.619596. MAX. 10. 0.00333992. 0.333992. 10.01976. AVG. 4. 0.001335968. 0.1335968. 4.007904. MIN. 3. 0.001001976. 0.1001976. 3.005928. MAX. 10. 0.0007048. 0.07048. 2.1144. AVG. 4. 0.00028192. 0.028192. 0.84576. 上傳保證 25,900. 金. 上傳 47,467 RootHash. 上傳中獎 129,535. 號碼. 公開稽核 68,844 聲明. 不在樹上 333,992 申訴. 上傳彩金 70,480 不足申訴. 38.

(50) MIN. 3. 0.00021144. 0.021144. 0.63432. MAX. 10. 0.00137734. 0.137734. 4.13202. AVG. 4. 0.000550936. 0.0550936. 1.652808. 重複申訴. MIN. 3. 0.000413202. 0.0413202. 1.239606. PK. MAX. 10. 0.00306408. 0.306408. 9.19224. AVG. 4. 0.001225632. 0.1225632. 3.676896. MIN. 3. 0.000919224. 0.0919224. 2.757672. MAX. 10. 0.00109826. 0.109826. 3.29478. AVG. 4. 0.000439304. 0.0439304. 1.317912. MIN. 3. 0.000329478. 0.0329478. 0.988434. MAX. 10. 0.00114967. 0.114967. 3.44901. AVG. 4. 0.000459868. 0.0459868. 1.379604. MIN. 3. 0.000344901. 0.0344901. 1.034703. MAX. 10. 0.00144399. 0.144399. 4.33197. AVG. 4. 0.000577596. 0.0577596. 1.732788. MIN. 3. 0.000433197. 0.0433197. 1.299591. PK INDEX. INDEX. 137,734. 306,408. 跳號申訴. SN 重複 109,826 申訴. SN 跳號 114,967 申訴. 累積投注 金錯誤申. 144,399. 訴. *ETH= Gas Used* Gas Price. *Gwei=10^-9ETH. *1 ETH=100USD. *1 USD=30TWD. *Gas Price 單位為 Gwei 39.

(51) 下表 5-6 為當玩家中獎時,需要至智能合約進行”中獎登記”,依據不同樹高所上 傳的密碼學證據大小亦不相同,主要被 TP Merkle Tree 碰撞次數所影響。 表 5-6 樹高與所需成本和 Gas 消耗表. 樹 碰撞次數. Gas. Gas Price. ETH. USD. TWD. 高. MAX. 209. 6,348,643. MAX. 10. 0.06348643. 6.348643. 190.45929. AVG. 4. 0.025394572. 2.5394572. 76.183716. MIN. 3. 0.019045929. 1.9045929. 57.137787. MAX. 10. 0.01671392. 1.671392. 50.14176. AVG. 4. 0.006685568. 0.6685568. 20.056704. MIN. 3. 0.005014176. 0.5014176. 15.042528. MAX. 10. 0.01961467. 1.961467. 58.84401. AVG. 4. 0.007845868. 0.7845868. 23.537604. MIN. 3. 0.005884401. 0.5884401. 17.653203. MAX. 10. 0.00736402. 0.736402. 22.09206. AVG. 4. 0.002945608. 0.2945608. 8.836824. MIN. 3. 0.002209206. 0.2209206. 6.627618. MAX. 10. 0.01037126. 1.037126. 31.11378. 17. MIN. MAX. 1. 120. 1,671,392. 1,961,467. 18. MIN. 19. MAX. 1. 72. 736,402. 1,037,126. 40.

(52) MIN. MAX. 1. 43. 544,371. 760,819. AVG. 4. 0.004148504. 0.4148504. 12.445512. MIN. 3. 0.003111378. 0.3111378. 9.334134. MAX. 10. 0.00544371. 0.544371. 16.33113. AVG. 4. 0.002177484. 0.2177484. 6.532452. MIN. 3. 0.001633113. 0.1633113. 4.899339. MAX. 10. 0.00760819. 0.760819. 22.82457. AVG. 4. 0.003043276. 0.3043276. 9.129828. MIN. 3. 0.002282457. 0.2282457. 6.847371. MAX. 10. 0.00450992. 0.450992. 13.52976. AVG. 4. 0.001803968. 0.1803968. 5.411904. MIN. 3. 0.001352976. 0.1352976. 4.058928. MAX. 10. 0.00647874. 0.647874. 19.43622. AVG. 4. 0.002591496. 0.2591496. 7.774488. MIN. 3. 0.001943622. 0.1943622. 5.830866. MAX. 10. 0.00536245. 0.536245. 16.08735. AVG. 4. 0.00214498. 0.214498. 6.43494. MIN. 3. 0.001608735. 0.1608735. 4.826205. MAX. 10. 0.00613149. 0.613149. 18.39447. 20. MIN. MAX. 1. 30. 450,992. 647,874. 21. MIN. 22. MAX. 1. 19. 536,245. 613,149. 41.

(53) MIN. MAX. 1. 13. 553,356. 615,537. AVG. 4. 0.002452596. 0.2452596. 7.357788. MIN. 3. 0.001839447. 0.1839447. 5.518341. MAX. 10. 0.00553356. 0.553356. 16.60068. AVG. 4. 0.002213424. 0.2213424. 6.640272. MIN. 3. 0.001660068. 0.1660068. 4.980204. MAX. 10. 0.00615537. 0.615537. 18.46611. AVG. 4. 0.002462148. 0.2462148. 7.386444. MIN. 3. 0.001846611. 0.1846611. 5.539833. MAX. 10. 0.00599745. 0.599745. 17.99235. AVG. 4. 0.00239898. 0.239898. 7.19694. MIN. 3. 0.001799235. 0.1799235. 5.397705. MAX. 10. 0.00619307. 0.619307. 18.57921. AVG. 4. 0.002477228. 0.2477228. 7.431684. MIN. 3. 0.001857921. 0.1857921. 5.573763. MAX. 10. 0.00578621. 0.578621. 17.35863. AVG. 4. 0.002314484. 0.2314484. 6.943452. MIN. 3. 0.001735863. 0.1735863. 5.207589. MAX. 10. 0.00629664. 0.629664. 18.88992. 23. MIN. MAX. 1. 10. 599,745. 619,307. 24. MIN. 25. MAX. 1. 8. 578,621. 629,664. 42.

(54) MIN. 1. AVG. 4. 0.002518656. 0.2518656. 7.555968. MIN. 3. 0.001888992. 0.1888992. 5.666976. MAX. 10. 0.00596309. 0.596309. 17.88927. AVG. 4. 0.002385236. 0.2385236. 7.155708. 596,309. 第五節 與區塊鏈交互次數 依照下表 5-7 可以知道,本文所開發的彩票系統相比於 BanFEL 所需要的區 塊鏈交互次數是極低的,我們以單次遊戲有一千萬名玩家,並假設有 K 人中 獎,遊戲流程皆沒有出現錯誤的情況進行計算,最多交互次數在 K+8 次。 表 5-7 與區塊鏈交互次數表. Function. 本篇論文. BanFEL. 投注. x. 1000 萬. 上傳保證金. 1. x. 上傳彩金. 1. x. 上傳 RootHash. 1. x. 上傳最後一張彩票. 1. x. 公開稽核正確宣告. 3. x. 申訴. 0. x. 43.

(55) 上傳中獎號碼. 1. x. 領獎. K. K. 總和. K+8. K+1000 萬. 第六章 結論與未來展望 第一節 結論 博弈產業在現今社會中不管是傳統的樂透彩券或者是許許多多的線上投注 網站,都有被單一組織控制的中心式架構問題。本文利用了以太坊區塊鏈以及智 能合約創造了一個可以容納大量投注、可受稽核、公開公正的中獎號碼選擇、自 動賠償機制、使用極低區塊鏈頻寬的彩票系統,相比於其他區塊鏈博彩遊戲,雖 然使用區塊鏈,雖然使用區塊鏈有一定的公開透明、不可竄改的特性,但內部所 有運行方式卻不一定能夠公開,本文的彩票系統可受稽核搭配上自動賠償的機制 就能夠把公開透明的問題完整的解決。對於區塊鏈的使用頻寬也相比於其他彩票 系統都來的低上許多,我們還能夠容納超過千萬級距的玩家同時遊玩,足以支撐 現今各國運行的博弈產業。除了彩票系統之外,只要依此系統架構進行開發,其 他博奕遊戲亦可達到相同的成效,不只讓整體博弈遊戲的公平性更加進步,亦能 夠使整個博弈產業向前邁進。. 第二節 未來展望 本文所建置之可稽核的彩票系統,在中心式架構風險上有大量的改進,利用. 44.

(56) 區塊鏈智能合約來對遊戲供應商提起到監督的效用。但由於遊戲供應商亦能算是 中心式架構的一部分,在本文之投注階段下,仍有可能將玩家所選號碼進行頻率 分析、篩選而做出舞弊行為,雖本文使用的中獎號碼由非少數人控制之資訊做為 建議選擇,但仍需防範所有可能舞弊之事項。 因此若在本文的系統上加入零知識證明(Zero-Knowledge) [19]的應用,推測能 夠將本系統的安全性向上提升。由於零知識證明能夠在雙方之間進行安全的資訊 轉換,意旨假設今有 A、B 雙方並且 A 掌握秘密資訊 S ,A 可生成一組證明,給 B 做驗證,使得 B 可以在不知道 S 的情況下,能夠利用 A 所產生的證據,讓 B 相 信 A 持有秘密資訊 S。以上為零知識證明之簡短應用,詳細行為與本論文設計之 系統能夠在投注方面做整合應用,使遊戲供應商不能得知玩家、中獎者所投注的 號碼,亦能在智能合約上驗證玩家、中獎者的投注資訊,使本論文設計之系統更 為公平且安全。. 45.

(57) 參考著作 [1] S. Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. [2] D. G. WOOD, ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER, 2014. [3] “台灣彩券,” [線上]. Available: https://www.taiwanlottery.com.tw/. [4] “Mega Millions,” [線上]. Available: https://www.megamillions.com/. [5] Encyclopædia Britannica. [6] ETtoday 新聞雲, “樂透「億元頭獎」真有人中?. 台彩主管爆:職業背景. 都假的!,” 2017. [線上]. Available: https://www.ettoday.net/news/20170424/910546.htm. [7] “Blockchain,” [線上]. Available: https://en.wikipedia.org/wiki/Blockchain. [8] V. Buterin, A Next-Generation Smart Contract and Decentralized Application Platform, 2017. [9] Gwan-Hwan Hwang, Pei-Chun Tien, Yi-Hsiang Tang , Blockchain-based Automatic Indemnification Mechanism Based on Proof of Violation for Cloud Storage Services, ICBCT'20, 2020. [10] Jiasheng Li ; Zijian Zhang ; Meng Li, BanFEL: A Blockchain Based Smart Contract for Fair and Efficient Lottery Scheme. [11] “Euler–Lagrange equation,” [線上]. Available: https://en.wikipedia.org/wiki/Euler%E2%80%93Lagrange_equation. [12] “Quanta White Paper,” [線上]. Available: https://www.quantaplc.im/. [13] “Transaction Positioned Merkle Tree,” [線上]. Available: https://itrustmachines.com/. 46.

參考文獻

相關文件

另有很多學者,並不使⽤Axiology這個字,⽽以Philosophy of Value ,Theory of

同一個常數 C ,只適用在 ( 0) 或者 (0, ) 上。.

但是 T, A, O, I 出現的次數幾乎不相上下。 要是把每一種組合都試一遍, 直到得出一個 意思 來, 那會是一項沒完沒了的工作。 所以, 只好等新材料來了再說。

Caption 出現的文字 Enabled 是否有致能 Value

一、下表為一年三班票選衛生股長 的得票結果,得票數最多的為 衛生股長,請完成表格並回答 問題(○代表票數). (

有一長條型鏈子,其外型由邊長為 1 公分的正六邊形排列而成。如下 圖表示此鏈之任一段花紋,其中每個黑色六邊形與 6 個白色六邊形相

有一長條型鏈子,其外型由邊長為 1 公分的正六邊形排列而成。如下 圖表示此鏈之任一段花紋,其中每個黑色六邊形與 6 個白色六邊形相

求出 Select Case 運算式之值,並逐一與 Case 運算式值串列比對,若符合則執行該 Case 之後的敘述區段。1. 如果所有的