BSC GameFi Bot 專案封面

專案聲明：本專案為個人學習 Web3 與 DApp 的練習專案，大部分程式碼是由 AI 程式助手（如 Codex）協作產生，非生產級別的專業代碼，如有疏漏或錯誤請多包涵，非常歡迎交流指教！

最近我利用閒暇時間開發了一個 DApp 練習專案 bsc-gamefi-bot。這個專案的遊戲規格，主要是參考了 Telegram 上常見的熱門小遊戲。為打造一個完整的微型經濟體，核心玩法不僅包含三款滿足不同風險偏好的遊戲，更加入了吸引玩家留存的鎖倉理財機制：

  1. 硬幣比大小（Coin Flip）：低波動、高頻次。平台設定了 3% 的莊家優勢（House Edge），這意味著長期下來，玩家每下注 100 元，平台就能穩定賺取 3 元，作為基礎利潤。
  2. 骰子比大（Dice）：中波動，滿足喜歡調整勝率與賠率的策略型玩家。
  3. 幸運轉盤（Lucky Spin）：高波動，包含大獎（Jackpot）機制。為了避免玩家連中大獎瞬間掏空平台的「遊戲金庫 (Game Vault)」，平台實作了動態單注上限（Risk Control Max Bet），單注最高上限被限制為當前金庫餘額的一小部分，以保護平台不破產。
  4. 7 天收益寶（Earn Vault）：這是一個鎖倉玩法。為了讓玩家願意將贏來的資金留在平台，玩家可以將資金鎖定 7 天來賺取高額年化利息（APY）。這部分結合了後面會提到的平台經濟模型，形成了一套完整的生態循環。

有了上述這些玩法機制後，接下來要面對的問題就是：該如何把它們放到區塊鏈上順暢運行？

在這之前，我其實沒寫過什麼智能合約，對區塊鏈開發的了解也不深。這是初次嘗試實作包含錢包簽名登入、合約存提款等功能的小專案，希望能藉此初步了解「前後端架構搭配合約」的開發方式。這篇文章就來分享這次的架構設計、經濟模型與風控取捨。寫法會延續我之前整理 匯率展示系統 MVP 架構規劃 時的思路：先把問題拆清楚，再說明為什麼採用這套架構，以及哪些地方仍然保留成練習專案的模擬範圍。

1. 核心痛點：高頻遊戲與昂貴 Gas Fee 的衝突

在設計這個參考 TG 遊戲的 GameFi 專案時，最直覺的作法可能是「每一次下注都發起一次 Web3 交易，由智能合約直接計算輸贏並派彩」。然而，在真實世界中，這樣做有幾個致命的問題：

  • Gas Fee 成本過高：即便是在費率較低的 BSC (BNB Chain) 上，每一筆交易仍要花費數美分。如果玩家玩一局硬幣或骰子只要 0.1 USDT，手續費可能就佔了交易金額的一大半。
  • 玩家體驗極差：區塊鏈打包需要時間（BSC 也要約 3 秒）。每次按一下按鈕就要彈出 MetaMask 簽章、等 3 秒確認，根本談不上遊戲體驗。

因此，我決定採用 「混合式雙帳本架構」（Hybrid Ledger Architecture）來解決這個衝突：

  • 鏈上（On-chain）：由 Solidity 寫的 VaultManager.sol 智能合約負責玩家的充值（Deposit）與提現（Withdrawal）安全。它就像銀行的「金庫」，只管錢的進出。
  • 鏈下（Off-chain）：玩家使用 MetaMask 簽章登入系統後，所有的下注、結算與返獎，通通在 Next.js 後端與 PostgreSQL 資料庫中「以內部籌碼積分」的形式在毫秒間完成，完全免除鏈上交易等待。

2. 系統架構與資料同步流程

為了實現這套架構，我設計了三個核心元件：Next.js 前端 Dashboard、Node.js 事件監聽器 (Listener)、以及 VaultManager 智能合約。

整個系統的前後端、合約與資料庫架構關係如下圖所示：

當玩家在前端呼叫合約將 MockUSDT 充值存入金庫時，鏈上會觸發一個 Deposit 事件。我們的 Node.js 監聽器會透過 Web3 RPC 節點捕捉到這個事件，驗證交易無誤後，使用 Prisma ORM 更新 PostgreSQL 資料庫中玩家的帳戶餘額。

3. 平台經濟模型：遊戲金庫與收益寶的微型生態系

在進行面試或向資方展示專案時，比起單純的程式碼實作，資方通常更想看到**「營運邏輯與代幣經濟」**（Tokenomics）。前述的三款小遊戲為平台帶來了源源不絕的「遊戲金庫收入」，但除此之外，我還加入了更進階的經濟模型設計：

A. 7 天收益寶 (Earn Vault)：平台的利息支出與外部模擬

為了讓玩家願意將贏來的資金存放在平台，而不是立刻出金提現，我設計了 7 天鎖定期的「收益寶」理財產品。

  • 鎖倉與利息：玩家將 MockUSDT 鎖定在收益寶 7 天，平台承諾給予年化收益（APY）。對平台而言，發放這些利息就是一種支出。
  • 利息來源的兩條路徑：
    1. 外部 DeFi 收益：在真實世界的產品中，玩家鎖倉的資金，平台可以自動透過智能合約轉存到外部的 DeFi 協議（如 Aave 或 Compound）去賺取利息。不過因為這是個 MVP 練習專案，這次並沒有真正去串接外部 DeFi 合約，而是用模擬的方式來計算外部 APY。
    2. 遊戲利潤補貼：如果外部利息不夠付，平台就要拿出前面「三款小遊戲賺來的利潤」來補貼給收益寶的玩家。
  • 風控機制：如果遊戲利潤不足以補貼玩家的 APY，系統會發出警告，並觸發 APY Cap（動態收益天花板），自動調降收益寶的利率，防止利息支出拖垮平台。

B. 純前端試算頁（/simulator）：沙盤推演的利器

在實際開發一個區塊鏈專案前，營運方最怕的是「數值沒調好，上線 3 天被玩家贏光金庫或利息發不出」。為此，我特別在專案中開發了 純前端試算頁（/simulator）。
這是一個在不依賴任何智能合約與資料庫的狀況下，純靠前端運算模擬平台運作的工具。你可以手動微調「三款遊戲的比例」、「收益寶資金佔比」、「莊家優勢 %」、「外部 APY 報酬率」。系統會模擬運行多個週期，並輸出「金庫餘額變化曲線」以及「收益寶池健康度」。這不僅能用來測試經濟模型的長期穩定性，在面試展示時，也能展現開發者具備「產品經營大局觀與風控意識」的亮點。

4. 可驗證公平性設計 (Provably Fair)

既然遊戲的結算是在我們自己的伺服器（鏈下）進行，要怎麼向玩家證明我們「沒有作弊」？如果玩家連輸 10 把骰子，他一定會懷疑是後端擅自修改了隨機數。

在沒有使用昂貴的 Chainlink VRF（合約隨機數）的情況下，我採用了目前主流 Web3 遊戲（如 Stake.com）普遍使用的**「可驗證公平隨機數機制」**（Provably Fair Algorithm）：

  1. Server Seed（伺服器種子）：由伺服器隨機生成一個加密安全隨機數，並在玩家下注前，將其 Hash 值（如 SHA256）展示在網頁上。這等於是伺服器做出了「簽章承諾」，一旦確定就無法事後修改。
  2. Client Seed（玩家種子）：由玩家瀏覽器隨機生成，或由玩家手動輸入一串自訂字串。這保證了伺服器無法預知玩家的輸入，進而無法刻意操控結果。
  3. Nonce（下注次數）：每次下注自動遞增的計數器。
  4. 計算公式：
    我們將三個參數串聯在一起，計算 HMAC-SHA512 的 Hash 值：
    Hash = HMAC-SHA512(ServerSeed, ClientSeed + Nonce)
    再取 Hash 的前幾個位元轉換成我們需要的隨機數範圍（例如 0-99 的骰子點數）。

當局結束後，系統會公開該局的 Server Seed 明文。玩家可以直接將明文與之前看到的 Hash 對照，並自行用公式計算，驗證伺服器是否真的使用了該種子，且沒有在開獎時動手腳。這套邏輯我全部用 TypeScript 封裝並寫了對應的單元測試，確保公平性禁得起科學檢驗。

5. 寫在最後：區塊鏈新手的心得

雖然這也許只是一個程式碼不夠專業、寫法有些粗淺的練習專案，但它對我個人意義重大。

以前我沒寫過什麼智能合約，對區塊鏈底層運作的了解也不多。透過這次初次實作，我親手完成了從 MetaMask 簽名登入、Solidity 合約開發、到 Node.js 事件監聽與 PostgreSQL 資料庫同步的完整流程。這不僅讓我初步了解了「前後端架構搭配智能合約」的開發方式，更讓我對 Web3 的混合帳本架構、防重寫機制以及可驗證公平性（Provably Fair）有了全新的認識。

這段踩坑與摸索的過程，讓我對區塊鏈技術又多了幾分敬畏與熱情。如果你對這個小專案有興趣，歡迎到我的 GitHub 交流與提 PR！大家在開發 DApp 時，又是如何平衡 Gas Fee 與使用者體驗的呢？歡迎在下方留言一起討論！