ETH Taipei 2026｜密碼學專案的反直覺本質
開發者 C.C. Liang，在 ETHTaipei 以「The Weird Nature of Crypto Projects」為題，探討密碼學產品為何與一般消費型軟體截然不同，以及開發者應如何重新思考安全、使用體驗與產品設計。
C.C. 首先分享一項透過 AI 開發數位憑證皮夾的實驗。其友人 Mashbean 曾參與台灣數位憑證皮夾開發，希望加入零知識證明與「選擇性揭露」功能；由於原型只有 iOS 版本，C.C. 便要求 AI Agent 製作 Android 版，並實際帶到 7-Eleven 測試。
傳統超商取貨時，消費者可能需要向店員出示包含姓名、身分證字號與其他個人資料的證件；數位皮夾則可由電信業者證明使用者的姓名與手機末幾碼，再透過 QR Code 只揭露領取包裹所需資訊。儘管測試介面仍充滿除錯訊息，超商店員最終仍成功掃描 QR Code，系統也確實找到他的包裹。
廣告 - 內文未完請往下捲動
然而，這項結合數位憑證與隱私技術的實驗，在一般人眼中看起來只是「掃了一個 QR Code」。
最好的密碼學，可能讓人毫無感覺
C.C. 認為，這正是密碼學產品最特殊的地方。生成式 AI 能寫出近似人類的文字、生成精美圖片，使用者第一次體驗時便能直接感受到技術突破；密碼學帶來的進步卻經常隱藏在背景之中。
當區塊鏈交易移除切換網路、準備 Gas 代幣與簽署交易等摩擦後，使用體驗可能只會像一般銀行 App。HTTPS 保護網路連線時，瀏覽器也只是顯示一個鎖頭；Signal 採用端對端加密等隱私技術，但多數人使用它，可能只是因為身邊的朋友也在使用。
他也提出一種「替代觀點」：密碼學就像以技術模擬可信任的第三方。許多由密碼學完成的功能，理論上也能透過銀行、交易所或其他中心化機構提供，因此未必會替使用者創造全新的表面體驗。
密碼學確實能從底層限制資料可以或不可以被如何使用，但如果使用者缺乏專業知識，便很難直接感受到這些保護究竟是否存在。
密碼學軟體不能沿用一般產品的開發邏輯
C.C. 引用 1999 年經典論文《Why Johnny Can’t Encrypt》指出，要實現真正「可用的安全」，產品所需的設計優先順序，以及各種安全特性帶來的挑戰，都與一般消費型軟體顯著不同。
論文歸納出五項安全軟體的特殊性。首先，使用者通常缺乏主動理解安全技術的動機。安全就像保險，只有當風險足夠高、採用成本足夠低時，人們才願意認真處理。Signal 在俄烏戰爭爆發後於烏克蘭的下載排名快速上升，便顯示現實威脅如何改變使用者行為。正如 Mashbean 所形容：「沒有人會穿著盔甲去買早餐。」
其次，密碼學高度抽象。加密、私鑰與數位簽章都是作用於資料之上的陌生規則，產品只能借用「鎖、鑰匙與簽名」等現實隱喻，協助使用者建立不完全精確的理解。
第三，安全操作缺乏即時回饋。當使用者洩漏密碼、連接惡意網站或錯誤簽署交易時，系統往往無法立即指出問題，直到資產遭竊才看見後果。硬體錢包的「盲簽」便是典型案例：使用者原本只是想將 ETH 換成 USDC，裝置畫面卻可能只顯示一串合約與函式資訊，難以判斷交易是否符合真正意圖。
第四是「穀倉門效應」：等到私鑰遭竊或手機遺失後才加強安全，就像馬已逃走才關上穀倉門，往往已經無法補救。
最後，整體安全取決於最弱環節。即使電腦採用極強的加密技術，攻擊者仍可能透過釣魚、社交工程，甚至直接威脅使用者取得密碼。若一項技術進步並未改善真正的最弱環節，使用者也很難感受到整體安全性有所提升。
密碼學是一種「用了也不知道好不好」的商品
C.C. 進一步借用經濟學框架解釋密碼學產品。蘋果屬於購買前就能觀察品質的「搜尋品」；餐廳料理是使用後可以判斷好壞的「經驗品」；醫療與汽車維修則屬於「信用品」（credence goods），即使服務完成，消費者仍缺乏專業能力判斷它是否必要或有效。
密碼學同樣接近信用品。使用者將資產存入隱私池、支付手續費後，未必理解自己獲得了多少「不可連結性」，也很難自行驗證隱私是否真的受到保護。
因此，開發者可以將密碼學產品拆成兩個部分：一部分是使用者能直接確認的經驗，例如訊息成功傳送、資產完成轉帳；另一部分則是難以親自驗證的安全、隱私與加密保證。
從要求使用者注意安全，走向讓安全機制隱形
C.C. 將安全技術的發展分成四個階段：首先是使用者處於容易遭受攻擊的狀態；接著，密碼學家提出解法並建立小眾基礎設施；當重大威脅出現後，大眾開始採用相關工具，但仍需學習密碼管理、雙重驗證及安全操作；最終階段，則是由電腦在背景完成安全流程，讓人類退出決策迴圈。
HTTPS 的普及便是一個案例。早期只有處理信用卡資料的頁面使用加密連線，史諾登事件提高大眾對網路監控的警覺後，Let’s Encrypt、瀏覽器警告與網站業者才共同推進 HTTPS。真正的障礙並非加密技術本身，而是如何協調所有人共同採用。
問題因此轉化為：每一項安全判斷應該由誰承擔？如果機器能準確掌握使用者意圖，部分流程便能自動化；如果開發者、政府或標準制定機構與使用者利益一致，也可以替使用者吸收判斷成本。
反之，若服務提供者同時也是被驗證對象，使用者就不能只相信一個綠色勾號。C.C. 以幣安儲備證明為例，由於交易所正在證明自身的償付能力，便必須解釋 Merkle Tree 與驗證方法，讓使用者理解自己究竟在驗證什麼。
開發者不應把密碼學術語直接當成賣點
C.C. 最後建議，開發者應先區分哪些功能是使用者能感受到的「經驗品」，哪些屬於難以自行判斷的「信用品」，再決定哪些資訊應呈現在產品介面，哪些安全機制應在背景自動完成。
他認為，產品若只是強調使用零知識證明或後量子簽章，實際上等於要求缺乏專業知識的使用者替開發團隊進行安全審計。開發者真正需要思考的，是能否將複雜判斷交由機器、產業標準、政府或其他利益一致的角色處理。
風險提示
加密貨幣投資具有高度風險，其價格可能波動劇烈，您可能損失全部本金。請謹慎評估風險。
