苑陳娟，孫國梓，李華康，王紀濤

南京郵電大學(xué)計算機學(xué)院，南京210023

牌類游戲因其量級輕、配置友好、游戲內(nèi)容豐富同時又具有一定的可挖掘性而在游戲市場中占據(jù)一席之地[1].然而，用戶之間的信任問題一直得不到妥善解決，外掛等作弊手段層出不窮.

目前，游戲平臺防止玩家篡改花色的方法是基于中心化節(jié)點的，即通過租賃第3 方網(wǎng)絡(luò)服務(wù)器來備份存儲玩家的數(shù)據(jù)，從而保證游戲的公平性，但該方法主要存在著以下幾個問題：

1）數(shù)據(jù)在傳輸過程中遭到破壞的風(fēng)險較大，容易出現(xiàn)瑕疵、斷點、不完整等問題，且需要多方人員共同處理數(shù)據(jù)，以致增加了數(shù)據(jù)中轉(zhuǎn)的次數(shù)，加大了數(shù)據(jù)被篡改的風(fēng)險.

2）這種方法對第3 方網(wǎng)絡(luò)服務(wù)器的依賴較大，一旦服務(wù)器遭受惡意入侵或者無法運轉(zhuǎn)，則連同其所控制的若干服務(wù)器上的電子數(shù)據(jù)都將面臨完整性、隱私性和可修復(fù)性等巨大安全隱患.

3）這種中心化的方法無法保證第3 方網(wǎng)絡(luò)服務(wù)器是完全安全又絕對公平的，用戶往往會對第3 方網(wǎng)絡(luò)服務(wù)器的誠實程度產(chǎn)生質(zhì)疑，擔心自己所上傳的數(shù)據(jù)泄露或者遭到惡意破壞，不利于系統(tǒng)與用戶建立長期的信任關(guān)系，且可能導(dǎo)致用戶與平臺之間的信任危機，增加了雙方建立可靠的信任機制所需要的時間.

4）這種方法需要租賃第3 方網(wǎng)絡(luò)服務(wù)器，成本較高，經(jīng)濟負擔較重.

區(qū)塊鏈運用了分布式存儲、共識機制、P2P 網(wǎng)絡(luò)、加密算法等技術(shù)，與傳統(tǒng)數(shù)據(jù)庫將讀寫數(shù)據(jù)庫權(quán)限完全交付給某公司或管理員的中心化方式不同，它以去中心化和去信任的方式允許所有節(jié)點享有同等的讀寫操作權(quán)利以保證區(qū)塊鏈網(wǎng)絡(luò)中所有數(shù)據(jù)的一致性和可靠性，使得參與者在無需任何外部強制約束的情況下即可自行形成相互牽制的可信環(huán)境.這種可信的環(huán)境建立在互不信任的基礎(chǔ)之上，解決了信用與治安問題.

智能合約[2]是Nick Szabo 在90年代提出的概念，由主流的區(qū)塊鏈系統(tǒng)Ethereum 率先進行開發(fā).這種合約是圖靈完備的編程語言，通過建立抽象的基礎(chǔ)層能使任何人都能創(chuàng)建合約并實現(xiàn)去中心化應(yīng)用的目的.它是一種可以部署在區(qū)塊鏈上的交易協(xié)議，其觸發(fā)條件、規(guī)則和事件信息可以預(yù)先設(shè)置.一旦部署在區(qū)塊鏈中就會自動執(zhí)行并根據(jù)觸發(fā)條件提供相應(yīng)的反饋信息，具有實時更新、準確執(zhí)行、低人為干預(yù)和低運營成本的特點.從本質(zhì)上來說，智能合約是傳統(tǒng)合約的數(shù)字化版本，以計算機程序的方式運行在區(qū)塊鏈系統(tǒng)上.當系統(tǒng)的狀態(tài)滿足源碼中預(yù)先設(shè)定的條件時，自動觸發(fā)預(yù)設(shè)的行為.智能合約一旦參與，達成協(xié)議寫入?yún)^(qū)塊鏈后就不可更改，這一點可以讓用戶對智能合約產(chǎn)生信任.

區(qū)塊鏈系統(tǒng)具有公開透明、無法篡改、便于追溯的特點，規(guī)避了數(shù)據(jù)被篡改的風(fēng)險，而可編程易操作的智能合約能使用戶更方便直接地查看并驗證電子數(shù)據(jù).因此，本文在區(qū)塊鏈基礎(chǔ)之上提出了一種牌類游戲可信存證鏈系統(tǒng)，妥善解決了用戶之間的信任問題.

傳統(tǒng)的存證模式存在電子化程度較低、數(shù)據(jù)易丟失易篡改、法律服務(wù)過程低效的問題，而區(qū)塊鏈特有的確保數(shù)據(jù)真實、不可篡改等特點就能有效解決上述問題.文獻[3]用一個存證鏈框架來管理收集到的車輛數(shù)據(jù)，將車輛公鑰管理整合到存證鏈中為會員們提供隱私保護，并設(shè)計分類帳存儲車輛數(shù)據(jù).該框架實現(xiàn)了無信任、可追蹤和隱私感知事故后分析的目的，并將存儲和處理開銷降到最低.文獻[4]提出了以區(qū)塊鏈替代第3 方服務(wù)器，在固定地理區(qū)域內(nèi)實現(xiàn)動態(tài)導(dǎo)航的同時確保用戶匿名，只允許法律授權(quán)機構(gòu)對分類帳進行取證分析，因此該方法能夠保護用戶的隱私.文獻[5]將區(qū)塊鏈與取證中的監(jiān)管鏈相結(jié)合，保證了所收集證據(jù)的可審計完整性和所有者的可追溯性.文獻[1]中將數(shù)據(jù)存證相關(guān)技術(shù)與區(qū)塊鏈技術(shù)相結(jié)合，為用戶提供更高效的數(shù)據(jù)存證服務(wù).文獻[2]提出一個基于智能合約的以太坊可信存證框架，與區(qū)塊鏈存證相比，其數(shù)據(jù)管理功能更多樣，區(qū)塊存儲成本更低，存證效率更高.

目前，將區(qū)塊鏈存證應(yīng)用在牌類游戲的可信存證方面的文獻尚未查到.市場上仍然使用第3 方服務(wù)器備份玩家數(shù)據(jù)，這種中心化的模式具有極大的安全隱患，因此本文提出了一種牌類游戲可信存證鏈系統(tǒng).采用區(qū)塊鏈存證技術(shù)來保存牌類游戲中每個玩家在整個游戲流程中的牌面信息，這樣牌面信息一旦上鏈就不可篡改.如果在游戲過程中有玩家換牌的事件發(fā)生，那么存證鏈上的玩家初始牌面信息將不同于游戲結(jié)束后玩家的出牌信息，此時系統(tǒng)就能及時發(fā)現(xiàn)玩家的作弊行為，大大提高了牌類游戲的可信任性.

1 基本原理

1.1 系統(tǒng)整體運行流程

牌類游戲可信鏈系統(tǒng)的詳細流程圖如圖1所示.

圖1 系統(tǒng)詳細流程圖Figure 1 System detailed flow chart

本系統(tǒng)首先通過API 接收玩家初始抽到的牌面信息即發(fā)牌信息，根據(jù)一定的隨機算法選定一套數(shù)據(jù)庫里的編碼對牌類信息進行數(shù)據(jù)壓縮；接著通過智能合約將數(shù)據(jù)上傳并錨定至區(qū)塊鏈側(cè)鏈；然后從側(cè)鏈上將可信數(shù)據(jù)拉取下來并用HuffMHT 算法對牌面信息進行處理壓縮后生成摘要，再通過智能合約將其錨定在區(qū)塊鏈主鏈上形成最終存證，同時智能合約也會反饋對局作弊情況至本地.另外，當游戲系統(tǒng)、玩家或是第3 方仲裁機構(gòu)需要查詢過往對局信息時，也只要提供牌局ID 與玩家ID 即可獲取過往對局最終信息，或進一步從側(cè)鏈上獲取具體的牌局對戰(zhàn)信息，以判定作弊情況.

1.2 系統(tǒng)整體框架

本框架設(shè)計將整個系統(tǒng)劃分成3 層，從上至下依次是邏輯實現(xiàn)層、智能合約層、區(qū)塊鏈層，如圖2所示.

1.2.1 邏輯實現(xiàn)層

邏輯實現(xiàn)層是系統(tǒng)核心功能的實現(xiàn)層.首先，系統(tǒng)通過API 接入玩家初始抽到的牌面信息對牌面數(shù)據(jù)進行編碼、壓縮、編碼排序、數(shù)據(jù)加密等一系列數(shù)據(jù)預(yù)處理；其次，當一局游戲結(jié)束以及當平臺或用戶對游戲?qū)执嬖诋愖h時，需要證明對局數(shù)據(jù)信息是否可信，本系統(tǒng)將會收集平臺或用戶的異議信息，自動從區(qū)塊鏈上取證驗證信息比對Hash.

1.2.2 智能合約層

在智能合約層里有部署在以太坊平臺的智能合約.智能合約層作為邏輯實現(xiàn)層和區(qū)塊鏈層之間的橋梁，將邏輯實現(xiàn)層的處理數(shù)據(jù)，如牌局的ID、游戲平臺發(fā)牌過程中的編碼信息等錨定到區(qū)塊鏈上，或從區(qū)塊鏈上獲取數(shù)據(jù)至邏輯實現(xiàn)層；同時智能合約也實現(xiàn)了一部分的邏輯函數(shù)，如CmprStr，這樣可以方便地實現(xiàn)系統(tǒng)功能并統(tǒng)一系統(tǒng)輸出API.

圖2 系統(tǒng)架構(gòu)圖Figure 2 System architecture diagram

1.2.3 區(qū)塊鏈層

區(qū)塊鏈層作為系統(tǒng)去中心化的數(shù)據(jù)庫，存儲邏輯實現(xiàn)層產(chǎn)生的數(shù)據(jù)信息.其中，網(wǎng)絡(luò)層承擔驗證交易信息、產(chǎn)生新區(qū)塊、維護區(qū)塊鏈網(wǎng)絡(luò)穩(wěn)定運行的工作；數(shù)據(jù)層保存著整個系統(tǒng)所有上傳的關(guān)鍵信息.

2 系統(tǒng)實現(xiàn)方法

2.1 玩家信息接入

將游戲開始時各位玩家及其抽取牌的信息通過API 接入本插件.考慮到牌的花色信息需要在客戶端以及后端系統(tǒng)之間進行傳輸，故借助Socket[6-7]實現(xiàn)兩者之間數(shù)據(jù)的傳輸與控制.目前，可以使用的Socket 有兩種方式：流式和數(shù)據(jù)報式.其中，前者基于TCP 傳輸，后者基于UDP 傳輸.經(jīng)比較發(fā)現(xiàn)：流式Socket 能按序提供穩(wěn)定的雙向數(shù)據(jù)流通信服務(wù)，適合本系統(tǒng)需要傳輸牌面信息和網(wǎng)絡(luò)之間數(shù)據(jù)的傳輸情況，故選擇基于TCP 的Socket 來實現(xiàn)通信.

基于TCP 的Socket 通信主要分為下述4 個基本步驟：

步驟1在服務(wù)器端定義ServerSocket 對象實例，監(jiān)聽來自客戶端的連接請求；

步驟2在客戶端定義Socket 對象實例，向指定的服務(wù)器發(fā)起連接請求；

步驟3按照一定協(xié)議對Socket 進行讀/寫操作，完成數(shù)據(jù)的計算和交互；

步驟4關(guān)閉輸入流、輸出流、雙方的Socket.

本文為每局游戲單獨啟動一個線程進行通信，所傳輸?shù)臄?shù)據(jù)有用戶信息和牌類花色信息.

2.2 數(shù)據(jù)預(yù)處理

牌面信息數(shù)據(jù)量較大，為了減少系統(tǒng)處理時間和存儲空間，需要對數(shù)據(jù)進行壓縮.這里運用了Huffman 編碼[8]和Merkle-tree[9]相結(jié)合的編碼方法對HuffMHT 編碼進行移位壓縮，最終達到數(shù)據(jù)壓縮的目的.本文將此方法稱為Huffman Merkle Hash tree，簡稱HuffMHT.

2.2.1 HuffMHT 編碼

HuffMHT 以牌面信息（牌的花色數(shù)字）的哈希值構(gòu)建一個不平衡的哈希樹.一個樣例HuffMHT 如圖3所示.

圖3 HuffMHTFigure 3 HuffMHT

下面概述構(gòu)建HuffMHT 的算法步驟.

步驟1本文將每張牌的花色數(shù)字轉(zhuǎn)換成對應(yīng)的哈希值并存放在一個數(shù)組中，這個數(shù)組就是哈希序列.

步驟2將哈希值序列以字典順序進行排序.

步驟3選取排序后哈希序列中最末的兩個哈希值作為孩子節(jié)點，將這兩個節(jié)點的值進行雙哈希運算Hash（左孩子哈希值，右孩子哈希值），從而生成了一個父節(jié)點.此時，在哈希序列中去掉剛剛相互組合的兩個孩子節(jié)點，加入生成的父節(jié)點的值.

步驟4重復(fù)步驟2 和3，當哈希序列中的元素為0 時，HuffMHT構(gòu)建完成.

2.2.2 移位壓縮

2.2.1 節(jié)采用HuffMHT 編碼方式將字符轉(zhuǎn)變?yōu)榫幋a，若用char 數(shù)組存儲編碼，則size并沒有減少，因此本文考慮用移位壓縮.編碼完成后，碼的形式是0 和1 組成的二進制編碼串，因此按位存儲更節(jié)省空間.由Huffman 編碼性質(zhì)可知：編碼長的出現(xiàn)頻率低，編碼短的出現(xiàn)頻率高.假設(shè)平均編碼長度為5 位，則32 位4 個字節(jié)可以存儲6.4 個字符，而char 只能存儲4 個字符，顯然數(shù)據(jù)得到了壓縮.整個壓縮執(zhí)行過程圖4所示.

2.2.3 編碼排序

接入的游戲牌面信息（牌的花色數(shù)字）都是亂序狀態(tài)，可見其對應(yīng)的壓縮編碼串也是一個亂序的狀態(tài)，于是本文按照牌面花色數(shù)字的大小規(guī)則將該編碼串排序，以便后續(xù)的作弊判定.排序流程如圖5所示：

圖4 移位壓縮Figure 4 Shift compression

圖5 排序圖示Figure 5 Sorting icon

對于圖5中有著4 個鍵值對的映射，以花色數(shù)字作為鍵，以花色數(shù)字對應(yīng)的壓縮編碼作為值，將花色數(shù)字由大到小排序后輸出其對應(yīng)的壓縮編碼值，這樣就完成了壓縮編碼的排序.

2.3 數(shù)據(jù)加密

因為SHA1 算法的安全性較高，且加密運行時間較少[10]，所以本文選擇SHA1 算法進行加密.

2.4 數(shù)據(jù)上鏈

2.4.1 以太坊環(huán)境的搭建

以太坊環(huán)境的搭建步驟如下：

步驟1從官網(wǎng)上下載Windows 版本的Geth 安裝包，完成安裝后將軟件目錄添加到Windows 系統(tǒng)環(huán)境變量PATH 列表中.

步驟2右鍵點擊任務(wù)欄上Windows 徽標，打開powershell，進入項目目錄，如D:Ether,其命令為cd D:Ether

步驟3以開發(fā)人員模式新建Etherum 私有鏈，并開啟rpc 模式，其命令為

geth-datadir data-dev-networkid 233-rpc

-datadir 參數(shù)為系統(tǒng)擬建立的私鏈數(shù)據(jù)目錄，如data，此處路徑表示為相對路徑，其對應(yīng)的絕對路徑應(yīng)為D:Gethdata.

-dev 參數(shù)為開啟開發(fā)者模式.在開發(fā)者模式下，會自動生成一個創(chuàng)世區(qū)塊，使用POA 共識網(wǎng)絡(luò)并隨之生成一個初始賬戶，其初始密碼為空；在開發(fā)者模式下，一旦交易被提交至私鏈上時，初始賬戶便自動開始挖礦，將交易自動寫入?yún)^(qū)塊鏈.測試開發(fā)時使用開發(fā)者模式來模擬一條保持運行的成熟私鏈.

-networkid 參數(shù)表示選擇的區(qū)塊網(wǎng)絡(luò).若要搭建私鏈網(wǎng)絡(luò)，則輸入任意非一般常見網(wǎng)絡(luò)ID 即可.

-rpc 參數(shù)為啟用http 的rpc（遠程過程調(diào)用）服務(wù)，系統(tǒng)采用了所有的默認參數(shù).

-rpcaddr value HTTP-RPC 服務(wù)器監(jiān)聽地址(default: “l(fā)ocalhost”)

-rpcport value HTTP-RPC 服務(wù)器監(jiān)聽端口(default: 8545)

-rpcapi value 指定需要調(diào)用的HTTP-RPC API 接口，默認只有eth，net，web3

步驟4保持步驟3 中powershell 運行，新建powershell，輸入如下命令連接至運行的區(qū)塊鏈節(jié)點：

geth attach ipc:\.pipegeth.ipc

其中attach 參數(shù)是通過rpc 或者ipc 與節(jié)點進行交互的.

步驟5新建測試用戶

personal.newAccount(“test”)

這里新建了一個密碼為test 的賬戶.

步驟6為了便于后續(xù)開發(fā)，將兩個賬戶定義為變量m與n：

m=eth.accounts[1]

n=eth.accounts[0]

2.4.2 編寫智能合約

將開始時的牌面Hash 和整局游戲結(jié)束時贏家的Hash 稱為數(shù)據(jù)Hash，為了將這個數(shù)據(jù)Hash 值存入以太坊區(qū)塊鏈，本文采用編寫智能合約的方法將該值錨定在區(qū)塊鏈上.

智能合約[11-13]最早是由Nick Szabo 于20世紀90年代提出的，但當時缺少可信的執(zhí)行環(huán)境，因此并未應(yīng)用于實際產(chǎn)業(yè).Ethereum 作為主流的區(qū)塊鏈系統(tǒng)，率先進行智能合約的開發(fā).

智能合約本質(zhì)上是傳統(tǒng)合約的數(shù)字化版本，以計算機程序的方式運行于區(qū)塊鏈系統(tǒng).當系統(tǒng)的狀態(tài)滿足源碼中預(yù)先設(shè)定的條件時，自動觸發(fā)預(yù)設(shè)的行為.智能合約被寫入Ethereum 區(qū)塊鏈后便不可更改，這一點可以讓用戶對智能合約產(chǎn)生信任.

本文定義的智能合約包含4 個集合，分別為發(fā)牌集合cardsL、出牌集合cardsP、出牌結(jié)果集合resultL、發(fā)牌結(jié)果集合resultP，用以存儲各個階段的牌類信息.其中cardsL、cardsP 存放的是發(fā)牌、出牌階段的詳細牌類信息的編碼，resultL、resultP 存放的是本系統(tǒng)對詳細牌類信息處理后得到的HuffMHT 摘要的值.基于上述4 個變量，編寫了上傳數(shù)據(jù)模塊函數(shù)、查詢下載數(shù)據(jù)模塊函數(shù)以及游戲?qū)纸Y(jié)果查詢函數(shù).

智能合約簡要算法流程圖如圖6與7 所示.

編寫完智能合約后需要完成智能合約的部署，其大致步驟如下.

步驟1編譯與調(diào)試

本文使用Remix 對智能合約進行編譯與調(diào)試.首先選擇與智能合約solidity 語言版本相符的編譯器版本，如本系統(tǒng)的智能合約solidity 語言版本如下：

pragma solidity ^0.5.2;

意味著編譯器需要采用兼容0.5.2 的編譯器，如

version: 0.5.9+commit.e560f70d.Emscripten.clang

圖6 對局信息編碼交互流程圖Figure 6 Flow chart for game information coding interaction

之后選擇remix 自帶的JavaScript VM 環(huán)境中進行調(diào)試.

步驟2獲取智能合約的abi 與bytecode

編譯與調(diào)試無誤后，需要從remix 中獲取智能合約的abi（應(yīng)用程序二進制接口）與bytecode，當然也需要對這兩個數(shù)據(jù)進行格式化處理.abi 需要用在線json 格式化工具去除空格，使其成為一行字符串；bytecode 中需要留下object 部分，并在其前加上“0x”十六進制標識符.

步驟3創(chuàng)建合約

進入已連接上節(jié)點的Geth 環(huán)境，將步驟2 中的abi 與bytecode 數(shù)據(jù)賦值給abi 與byte變量.

通過abi 變量在Geth 環(huán)境中重現(xiàn)智能合約，命令為

Contract =eth.contract(abi)

之后預(yù)估合約所需的gas，為部署智能合約預(yù)設(shè)的gas 上限需要大于預(yù)估值，其命令為

eth.estimateGas({data: byte})

命令行返回的結(jié)果即為智能合約部署所需要的gas，同時在部署之前需要解鎖賬戶，以支付智能合約部署所需的gas，命令為

personal.unlockAccount(my)

此時需要輸入m賬戶的密碼test，注意此時輸入沒有回顯.

之后部署智能合約，生成智能合約對象，并將其用變量fff 表示，命令為

fff=Contract.new({data:byte,gas:3000000,from:my})

圖7 對局結(jié)果交互流程圖Figure 7 Game result interaction flow chart

因為后面涉及到后端與區(qū)塊鏈的交互，所以要保留智能合約對象的地址，其命令為

fff.address

步驟4Geth 中智能合約對象的方法調(diào)用

Solidity 的方法調(diào)用一般分為交易方法的調(diào)用與常量方法的調(diào)用.

常量方法的調(diào)用只需直接以類方法的格式調(diào)用.假設(shè)需要獲取已上傳至區(qū)塊鏈的牌類信息，則調(diào)用getCardInfo.命令為

fff.getCardInfo(<參數(shù)>)

而交易方法的調(diào)用還需要額外進行sendTransaction 操作，即需要加入交易的發(fā)起者.假設(shè)需要調(diào)用uploadCardL方法，其命令為

demo.uploadCardL.sendTransaction(<參數(shù)>,<參數(shù)>, {from: my})

2.5 作弊判定

當平臺或用戶對游戲?qū)执嬖诋愖h時，需要證明對局數(shù)據(jù)信息是否可信，本系統(tǒng)將收集平臺或用戶的異議信息，自動從區(qū)塊鏈上驗證信息的有效性.流程圖如圖8所示.

3 實 驗

3.1 HuffMHT 編碼測試與結(jié)果分析

本文提出了一種有效的編碼實現(xiàn)方案HuffMHT，允許以一種最小化平均響應(yīng)長度的方式分發(fā)包含牌面信息的葉節(jié)點HuffMHT，為狀態(tài)檢查中可以找到的所有類型的統(tǒng)計數(shù)據(jù)節(jié)省了較大的帶寬[14-15].該編碼方案能夠保持良好的性能，比Huffman 樹表現(xiàn)得更好.

當牌的數(shù)量不同時，比較HuffMHT 編碼和Huffman 編碼的編碼耗時情況，如圖9所示.

圖8 數(shù)據(jù)仲裁流程圖Figure 8 Data arbitration flow chart

從圖9中可以看出，隨著牌的數(shù)據(jù)規(guī)模的增大，HuffMHT 編碼的性能越來越好.此外，HuffMHT 編碼結(jié)合了加密算法，可防御Sybul 攻擊，剝奪“睡眠”攻擊等，與Huffman 編碼相比安全性得到了大幅度的提高.從以上分析可以看出，HuffMHT 編碼比Huffman 編碼表現(xiàn)得更好.

圖9 HuffMHT 編碼速度Figure 9 HuffMHT encoding speed

3.2 編碼壓縮測試與結(jié)果分析

根據(jù)HuffMHT 編碼原理可以知道，牌的花色數(shù)字采用的是定長編碼（每種都是用一個字節(jié)表示），而HuffMHT 編碼是緊致碼[16].因此，牌的花色數(shù)字的編碼串是具有壓縮空間的，表1給出了壓縮測試的結(jié)果.

表1 移位壓縮測試結(jié)果Table 1 Shift compression test result

從測試結(jié)果來看，壓縮后的文件小于源文件所占的空間，因此采取移位壓縮的方法的確可以達到數(shù)據(jù)壓縮的目的.從表1中可以看出：隨著牌的數(shù)據(jù)量的上升，壓縮率是不斷下降的.這一點根據(jù)移位壓縮的原理不難理解，一個字符占8 位，如果編碼長度不超過8 位，就有壓縮的空間；如果編碼長度等于或超過8 位，移位壓縮就不起作用了.本文只需要壓縮54 張牌，顯然移位壓縮能夠滿足本系統(tǒng)的需求.

3.3 加密算法測試與結(jié)果分析

以一個108.0 字節(jié)的牌面花色數(shù)字信息為測試樣本，測試1 000 次的平均值，3 種算法的運行時間見表2.

表2 3 種常見加密算法的運行時間Table 2 Time of three common encryption algorithms

由表2中信息可知：MD5[17]的加密運行時間最短，但比其他兩種加密算法更容易碰撞，安全性較低；SHA256[18]的安全性最高，但其加密運行時間比MD5 和SHA1 大得多，因此SHA1 是這3 種加密算法中性能最好的一款加密算法，故本文采用了SHA1 算法生成Hash.

4 結(jié) 語

考慮到了區(qū)塊鏈與游戲的結(jié)合點太少，本文改變應(yīng)用場景，利用區(qū)塊鏈去信任、去中心化的獨特機制有效驗證作弊行為.同時棋牌類小游戲數(shù)據(jù)并不復(fù)雜，運算時不會造成太大負擔而產(chǎn)生擁堵現(xiàn)象.因此本文基于區(qū)塊鏈的獨特性質(zhì)來設(shè)計防作弊系統(tǒng)，將牌類游戲中牌的花色作為電子數(shù)據(jù)存于區(qū)塊鏈中，以保證數(shù)據(jù)的可驗證性、不可篡改性和不可偽造性.花色等電子數(shù)據(jù)一旦存儲在系統(tǒng)中，就可以供驗證者調(diào)用并與待查證信息進行比對，以證明此待查證數(shù)據(jù)的真實性，防止玩家中途換牌等作弊行為.借助以太坊平臺，通過API 接口接入游戲，從而防止用戶更改花色、私自換牌等篡改、偽造游戲數(shù)據(jù)的作弊行為.