MPC Threshold Signature

MPC 門檻簽章是什麼，跟傳統私鑰保管有什麼不同？

傳統的私鑰保管方式，不管是寫在紙上、存在硬體錢包，還是放在雲端服務裡，本質上都是「單一完整金鑰存放在單一地方」——任何一方只要拿到這把完整的鑰匙，就能單獨簽署交易、動用資金，這代表整個系統只有一個需要被攻破的點（single point of failure）。MPC 門檻簽章的做法完全不同：透過多方運算（Multi-Party Computation）技術，把私鑰在產生的那一刻就拆成多份「份額」（share），分別交給不同的裝置、系統或參與方保管，而且不是像傳統密碼學那樣先產生完整金鑰再切開，是從一開始就用分散式金鑰生成（Distributed Key Generation）讓完整金鑰從未真正存在過。

簽署交易時，需要達到一個預先設定的「門檻」（例如三份中的兩份、五份中的三份）份額共同參與運算，才能生成一個有效簽章，而且整個運算過程中，完整私鑰依然不會在任何一個裝置上被重組出來——這跟傳統多重簽名（MultiSig）「每個人各自用完整私鑰簽一次、鏈上看得到多筆簽名」的做法也不一樣，MPC 門檻簽章對外呈現的是單一標準簽章，鏈上看不出這是多方協作產生的。

MPC 門檻簽章為什麼會出現，是什麼原因造成的？

核心驅動力是傳統單一私鑰模式在企業級與 Agent 場景下的風險太集中：私鑰遺失，資產永久鎖死；私鑰外洩或裝置遭入侵，資產可能瞬間被盜走且無法追回，區塊鏈交易一旦簽署完成就不可逆轉。當資產規模擴大到機構等級，或是需要讓程式化系統（例如 AI 代理）具備簽署交易的能力時，「把完整私鑰交給某一方保管」這件事本身的風險就變得難以接受——不管交給的是內部員工、外部托管平台，還是一段程式碼，只要那一方被攻破，資產就直接暴露。

另一個推力來自 AI 代理興起後的新需求：如果要讓 AI 代理有能力執行支付，同時又不希望代理本身握有能單獨動用資金的完整權限，MPC 門檻簽章提供了一個具體的技術解法——讓代理成為簽署運算裡的其中一份參與方，而不是唯一的掌控者，即使代理的判斷被劫持，攻擊者拿到的也只是不完整的份額，無法單獨完成簽署。

MPC 門檻簽章具體怎麼運作，簽署一筆交易的完整流程是什麼？

整個生命週期分成兩個核心階段。第一階段是分散式金鑰生成：在創建錢包時，多個參與方（可能是使用者的裝置、服務供應商的伺服器、以及其他授權方）各自在本地獨立產生一份隨機的密碼學份額，這些份額之間透過協定互相驗證，但沒有任何一方，也沒有任何一個中央角色，曾經看過或組裝過完整的私鑰——這跟「先有一把完整鑰匙再切成幾份」的直覺想像不同，完整金鑰在這個架構裡從一開始就不存在。第二階段是門檻簽章：當需要簽署一筆交易時，達到門檻數量的參與方各自用手上的份額進行本地運算，透過多輪協定交換運算結果（而不是交換份額本身），最終共同生成一個標準格式的有效簽章，供應鏈上驗證。整個過程中，任何一方能看到的都只有自己那一份的運算結果，無法從中推導出其他人的份額或完整私鑰。

門檻的設定方式很彈性，常見的是 t-of-n（n 份份額中集滿 t 份即可簽署），企業場景常會搭配額外的治理規則，例如小額交易自動核准、大額交易需要更高層級參與、特定時段或特定目的地地址需要額外審核，這些規則是疊加在門檻簽章之上的政策層，不是密碼學機制本身的一部分。

MPC 門檻簽章對我有什麼影響，該怎麼判斷一個產品是不是真的用了這套機制？

如果你正在評估任何涉及資金管理的產品——不管是機構託管服務、還是近期出現的 AI 代理支付工具，MPC 門檻簽章提供了一個具體的檢驗問題：完整私鑰在這個系統的哪個環節、哪個時間點，會被重組出來？如果答案是「完整私鑰確實會在某個伺服器或裝置上短暫重組」，這就不是真正的 MPC 門檻簽章，風險評估要回到傳統單點失效的邏輯；如果答案是「私鑰從產生到簽署全程都不曾被重組」，才符合這個技術真正的安全承諾。

另一個值得注意的判斷點是門檻設定本身的合理性——t-of-n 的 t 值設得太低（例如 5 份份額中只需要 1 份），等於變相退化成單點失效；設得太高，又可能在部分參與方離線時完全無法簽署任何交易，實務上需要在安全性跟可用性之間找平衡，這個平衡點怎麼設，比「有沒有用 MPC」這個標籤本身更能反映一個系統的實際安全水準。