Google 將於 2027 年推出機構級加密貨幣託管平台：其 MPC 技術如何運作
Google Cloud 已推出 Google 多方計算（MPC），這是一種專為全球銀行、資產管理公司和受監管金融機構設計的數位資產密鑰管理與託管基礎設施解決方案。目前該服務處於僅限受邀用戶的私人預覽階段，雲端供應商目標於 2027 年初實現商業通用版本（GA）。在大規模商業推廣之前，Google 已在支援主要區塊鏈生態系統（包括以太坊和 Solana）的內部生產環境中驗證了該架構。
此舉代表機構級 Web3 雲端基礎設施的顯著擴展。多年來，主要雲端供應商將其數位資產服務主要集中在託管遠端程序呼叫（RPC）節點、在 BigQuery 中索引公共區塊鏈數據集，以及探索企業結算網絡。
透過引入原生 MPC 基礎設施，Google Cloud 正深入機構數位金融的安全堆疊：加密密鑰的分散生成、策略驗證與門檻簽名。隨著受監管的金融機構擴大參與代幣化存款、現貨交易所交易產品（ETPs）和現實世界資產（RWA）結算，雲端整合的 MPC 提供了一個模組化的技術基礎，與傳統託管服務提供商和舊式硬體金庫並行。
密鑰洩露與機構託管的權衡
機構參與數碼資產的增長，突顯了堅固的密鑰管理系統的重要性。來自 DeFiLlama 等平台的行業安全追蹤數據持續顯示，憑證遭盜用和私鑰被利用是加密貨幣領域中資本損失最大的途徑之一，在近期的市場週期中已造成數十億美元的累計行業損失。
歷史上，機構數位資產存儲主要依賴兩種架構模型，每種模型對商業金融機構都帶來不同的運營取捨。
-
傳統硬體安全模組與單點風險
傳統金融的密鑰管理嚴重依賴實體硬體安全模組（HSM）和空氣隔離的冷儲存環境。雖然 HSM 能將加密密鑰隔離在防篡改硬體內，但標準的單一密鑰配置仍可能引入結構性單點故障（SPOF）。
要授權傳統的單簽名區塊鏈交易，在簽名生成過程中，完整的私鑰必須存在於單一模組的記憶體邊界內。如果攻擊者入侵主機管理層、利用固件漏洞或繞過管理存取控制，該單一密鑰所控制的資產將立即面臨暴露風險。
-
鏈上多重簽名限制
為避免單一密鑰依賴，許多 Web3 協議採用鏈上多重簽名（Multi-Sig）智能合約，例如 Safe。在標準的 M 出 N 多重簽名結構中，多個獨立的私鑰必須提交獨立的批准，以滿足智能合約的執行規則。
雖然對去中心化國庫而言極為有效，但鏈上多重簽名對傳統銀行工作流程提出了三個實際挑戰：
跨鏈不相容：智能合約多重簽署邏輯在異構的第1層區塊鏈上並非統一。雖然在以太坊虛擬機（EVM）網絡上已廣泛標準化，但在非EVM鏈（如比特幣或Solana）上實現相同的智能合約治理，需要不同的原生腳本和獨立的操作流程。
較高的網絡交易成本：由於多重簽名交易需要在鏈上直接驗證多個加密簽名或合約調用，因此相比標準的單簽名轉帳，會消耗更多的區塊空間和網絡費用。
治理規則的公開可見性：由於多重簽名規則透過公開的智能合約執行，機構的法定人數門檻、簽署者地址和組織批准模式都會在公開帳本上顯示。
這些限制推動了機構對鏈下門檻密碼學的需求，以統一多條區塊鏈的安全政策。
Google 多方計算如何運作
Google Cloud 多方計算透過基於多方計算（MPC）的門檻簽名方案（TSS）來解決單點密鑰風險。在這種加密模型下，完整的私鑰在密鑰生成、存儲或交易簽署的任何階段都不會在任何單一設備、伺服器記憶體匯流排或資料中心中組裝。
硬化版 DKLs23 門檻簽名協議
根據平台的技術規格，Google 的 ECDSA 簽名引擎採用了經過強化的 DKLs23 協議實現。DKLs23 以密碼學家 Döttling、Komargodski、Lai 和 Shen 命名，是一種現代的門檻簽名協議，旨在在分散式參與方之間以最低的通信開銷安全地計算橢圓曲線簽名。
Google 的實施重點放在三個運營優先事項上：
-
惡意對手韌性：該協議設計為即使攻擊者入侵了低於簽名門檻的參與節點，仍能維持不可偽造性。內建的一致性檢查會在簽名儀式期間檢測到格式錯誤的加密分片，並在產生無效簽名前自動中止會話。
-
低延遲回合優化：早期的 MPC 實現由於多次往返網路通信，通常面臨簽名時間緩慢的問題。通過採用 DKLs23 的簡化回合結構，本地密碼學運算可在毫秒內完成，一旦機構政策檢查通過，即可實現亞秒級端到端簽名工作流程。
異構密鑰分割：2-of-3 共識模型
平台採用分散式密鑰生成（DKG），而非在單一地點生成私鑰後再進行分割，各獨立節點透過數學運算計算各自的密鑰分片，且任何單一節點都從未見過完整密鑰。
為避免風險過度集中於單一雲端供應商，機構部署通常採用異質性的 2-of-3 多數決結構：
-
分享 1（客戶控制環境）：直接託管於金融機構的內部資料中心或專用 HSM 環境中。
-
分享 2（Google Cloud 恩克拉夫）：託管於 Google Cloud 硬體隔離的保密空間環境中。
-
分享 3（獨立恢復或第三方雲端）：託管於外部雲端環境（例如 AWS 或 Azure）或由獨立恢復受託人離線保管。
在這種 2-of-3 閾值結構下，任何兩份授權份額均可在鏈下協作生成標準的加密簽名。對於底層的區塊鏈而言，所產生的交易與正常的單密鑰轉帳完全相同。
如果攻擊者入侵單一環境，他們僅能取得一個孤立的密鑰分片——該分片在數學上無法揭示完整私鑰的任何資訊，且無法單獨授權交易。相反地，若機構的本地工作站遭到入侵，攻擊者仍無法單方面轉移資金，除非 Google Cloud 的隔離區獨立驗證該交易符合預設的安全策略。
硬體層級隔離：Google Cloud 機密空間（TEE）
雲端主機金鑰管理的一個歷史性擔憂是主機層級的權限提升：如果雲端伺服器的操作系統或虛擬化管理程式遭到入侵，高權限管理員可能會嘗試檢視儲存在系統記憶體（RAM）中的加密資料。
Google 透過在 Google Cloud Confidential Space 中運行其 MPC 簽名節點來降低此風險，該空間是由保密計算硬體支援的可信執行環境（TEE）：
硬體記憶體加密：保密空間利用處理器層級的記憶體加密（如 AMD SEV-SNP），確保密鑰分片和中間簽名運算在 RAM 中使用主機作業系統無法存取的硬體金鑰保持加密狀態。
加密證明：在存取金鑰分片或開始簽名週期前，安全區會產生一個以硬體為基礎的證明令牌，用以驗證容器映像和固件基線的精確加密雜湊值。若軟體映像有任何更改，證明檢查將失敗，並阻止簽名流程。
受限的管理員存取：保密空間強制執行嚴格的工作負載隔離，移除標準的 root 存取權或互動式除錯功能，即使雲端基礎架構管理員也無法查看活動圍區內的資料。
交易政策執行情形與密鑰分享更新機制
保護密鑰分片免於提取，僅解決了託管挑戰的一部分。實際上，許多機構安全事件源於被入侵的 API 憑證、釣魚攻擊，或未經授權的內部批准，這些都會欺騙合法系統簽署惡意交易。
預簽署政策驗證引擎
為防止應用層的未授權轉帳，Google Cloud 將一個確定性政策驗證引擎直接嵌入 Confidential Space 沙箱中。在 Google 的 MPC 節點參與門檻簽名週期之前，所提議的交易載荷會根據機構定義的治理規則進行檢查——例如白名單目的地址、最大交易價值限制、速度上限、一天中的時間窗口以及多重批准者多數簽名。
如果受損的端點終端機嘗試請求轉帳至未經批准的地址或超過允許的閾值，圍籬會在任何密碼學分片計算之前拒絕簽署請求。
主動式秘密共享（金鑰分片更新）
為降低複雜攻擊者在長時間內逐步入侵多個節點的風險，此架構支援主動式秘密共享（PSS），通常稱為密鑰分片輪換或更新。
根據預定時間表或人員變動後，參與的節點會執行數學刷新協議：
-
節點共同計算一組全新的加密分片。
-
先前的密鑰分片已永久失效並被覆寫。
-
底層的主公鑰和鏈上錢包地址完全保持不變。
這意味著，即使攻擊者在一個月內成功竊取了單一密鑰分片，該分片在下一次計劃的分片刷新後也會失效——從而讓機構能夠定期輪換其底層安全材料，而無需將資金轉移到新的區塊鏈地址或支付鏈上網絡費用。
後量子靈活性與 2027 年商業適用性
隨著金融機構以多年期的視角評估託管基礎設施，長期的密碼學敏捷性，包括為量子計算做準備，已成為重要的架構考量。標準橢圓曲線方案（secp256k1 和 Ed25519）依賴的數學問題，最終可能對足夠強大且容錯的量子電腦產生漏洞。
雖然 Google Cloud 的初始 MPC 部署專注於解決即時的操作威脅，例如憑證竊取、單一故障點和內部串通，但該平台在設計時考慮了密碼學的模組化。透過將政策協調和 API 層與底層簽名原語分離，該架構已結構化，以便在區塊鏈網路和國際標準機構（如 NIST）確定後量子簽名規範後，支援未來的後量子密碼學（PQC）和量子安全傳輸標準。
結論
Google Cloud 推出機構級多方計算基礎設施，凸顯企業數位資產安全的持續成熟。透過結合 DKLs23 閾值簽名協議、硬體認證的 Confidential Space 沙箱以及異質性的 2-of-3 金鑰分發，該平台協助金融機構在不犧牲簽名速度或多鏈彈性的前提下，降低單點金鑰漏洞風險。隨著該服務於 2027 年邁向商業化，雲端整合的 MPC 將在銀行與資產管理公司大規模保障 代幣化資產 的方式中發揮日益重要的作用。
常見問題
什麼是 Google Cloud 多方計算？
Google Cloud 多方計算（MPC）是一個機構級數位資產密鑰管理與簽署基礎設施平台，目前處於私人預覽階段，預計於 2027 年初正式商業推出。它採用門檻密碼學，將私鑰控制分散至不同環境中，從而消除區塊鏈交易簽署時的單一故障點。
為什麼 Google 將商業可用性目標設定在 2027 年？
於 2026 年底運行限時邀請制私人預覽，讓合作銀行與機構資產管理人進行安全審計、政策整合與合規測試。2027 年初的全面上線目標，與在成熟監管框架下（如歐盟的 MiCA 機制及日漸發展的巴塞爾委員會對銀行加密資產風險敞口的標準）機構採用率的提升相一致。
Google 的 MPC 與鏈上多重簽名有何不同？
鏈上多重簽名智能合約直接在區塊鏈上驗證多個獨立簽名，這會增加氣體費用、公開批准結構，並需要特定鏈的智能合約支援。Google 的 MPC 使用強化的 DKLs23 協議在鏈下進行多方批准與閾值運算，輸出單一標準簽名，可在不同區塊鏈上使用，費用更低且治理規則更私密。
MPC 技術能消除所有加密貨幣託管風險嗎？
沒有任何安全架構能消除所有風險。雖然 MPC 移除了將完整私鑰存放在單一位置所帶來的單點故障問題，但機構仍需防範釣魚攻擊、端點被入侵以及內部治理缺陷。Google 的設計透過將異質分割的密鑰分片與硬體隔離的 Confidential Space 異構區結合，並配合預簽名政策檢查，有助於降低這些運營風險。
免責聲明
免責聲明: 本頁面經由 AI 技術翻譯，旨在方便您的閱讀。欲獲取最準確資訊，請以原始英文版本為準。