Don’t Trust. Verify: 驗證錢包助記詞為例

“Don’t Trust. Verify.” 起源與意義

有句俄國的順口溜「доверяй, но проверяй（Trust, but verify）」，有其歷史場景；後來演變為「Don’t Trust. Verify.」成為比特幣或區塊鏈社群的金科玉律。

中本聰（Satoshi Nakamoto）在 2009 年 2 月 11 日發表「Bitcoin open source implementation of P2P currency」時，討論的是傳統貨幣金融仰賴對銀行的「Trust（信任）」，而比特幣則是建立在密碼學基礎上，任何人都能「Verify（驗證）」區塊鏈帳本。

然而，即便是軟體工程師，都很可能不會自己去驗證區塊鏈上的每筆交易。我們傾向信任那些分散於世界上的區塊鏈驗證人。

為何要驗證錢包助記詞？

接著談到密碼學錢包。這裏我們主要是針對以太坊 EOA (Externally Owned Account) 錢包，譬如 MetaMask 小狐狸錢包，而非代管或智慧合約錢包。

使用密碼學錢包的你，應該已經知道助記詞是一切的根源，必須安全地儲存、切勿洩漏。

只要匯入原先的助記詞，就應能推導出相同的錢包私鑰與錢包地址，即可回復錢包。（P.S. 實際情況可能依各錢包的自訂機制而異。）

但你怎麼知道當初生成的助記詞，確實能用來存取該錢包資產？畢竟我們自己儲存的只有助記詞，而非錢包私鑰本身！

因此，在使用任一款新錢包之前（無論是軟體或硬體錢包），何不先驗證一下？譬如同樣的助記詞，是否真能推導出相同的錢包地址？若通過驗證，可以重設錢包換個助記詞來用。

錢包驗證篇：初探「助記詞」

任何有經驗的軟體工程師，應該都能運用自己熟悉的密碼學套件來驗證，但通常得操作文字命令列介面（終端機），這對一般人來說可能太複雜。

更簡單的作法是，拿不同廠牌的錢包來交叉驗證。不過這可能還是有點麻煩，而且仍需要信任其他錢包品牌。

因此這個專案的目標，就是開發一個夠安全且可驗證的「助記詞驗證器」。

首先，你需要一台 iPad（抱歉了，因為我們需要蘋果的 Swift Playgrounds）。

點擊這個專案連結、「在 Playgrounds 中打開」。任何人都可以驗證專案裡的全部程式碼：就只是一個簡單的使用介面，以及運用 ether.js 的幾行 JavaScript 程式碼。

就是這麼單純。執行這個專案，就能在 app 裡驗證助記詞！

App 內建的預設助記詞，是摘自 Ethereum.org 上的範例錢包，因為已經公開了，任何人都可以存取該錢包裡的資產，所以當然不要再使用這個錢包了。

為何選擇這樣的運作環境呢？首先，一般人的資安意識可能不夠敏感，相較於較具風險的傳統電腦（包含 Windows 和 Mac），在 iOS/iPadOS 執行程式是最簡單又安全的方式，惡意軟體很難侵入或在背景作怪，也有系統級警示來避免其他軟體竊取剪貼簿內容。

App Store 上也有其他開發環境，譬如：JSBox、Pythonista 等。我只是為了盡可能減少依賴第三方，而選用了蘋果官方的 Swift Playgrounds。

為何要自己從原始碼開始來執行程式呢？「開發原始碼」是區塊鏈技術得以發展的重要基石，有些嚴謹的軟體工程師，會親自從原始碼編譯所使用的程式，而不會直接下載其他人產出的執行檔來用。畢竟驗證執行檔是否確實編譯自該開源專案並不容易，對 iOS app 來說就更麻煩了。

為何不做成 Web App 呢？理論上是可以的，不過管理瀏覽器裡的儲存空間，可能會很麻煩。況且我希望盡可能確保此驗證器只在離線時使用，但人們通常會用 Web 瀏覽器來連線上網，因此增加了風險。

你也可以在 Mac 上用 Xcode 執行此專案或編譯給 iPhone 使用，請自行注意資安狀況。此專案為 MIT 授權，意即歡迎隨意使用，但我們不承擔任何責任哦。

P.S. 此專案亦以英文公開發表於 Mirror.xyz 上（連結）。

重新思考信任（Trust）

由於我們不可能親自驗證所有程式碼，因此建立「信任鏈」才是最重要的；即使是 Linux 專案發起人 Linus Torvalds 也是這樣工作的！這對應了現實世界的人際關係，使得分散式信任得以建立起眾多軟體王國。

因此，執行這個專案，等同於信任了以下成員或組織：

• code (@denkeni)
• ethers.js (@ricmoo)
• Swift Playgrounds (Apple)
• iPadOS (Apple)

誠如 Ken Thompson 圖靈獎的授獎演講「Reflections on trusting trust」所述：

To what extent should one trust a statement that a program is free of Trojan horses? Perhaps it is more important to trust the people who wrote the software.

當然，這並不表示前述成員或組織就不會出錯。2015年，蘋果的 Xcode 就曾遭發現被注入惡意程式碼的嚴重事件「XcodeGhost」。

驗證，則是為了挑戰與重新建立信任。

P.S. 本文為「作者保留所有權利」，無視 Matters 版權聲明版型。