BLS 簽名無處不在，從乙太坊的共識到 EigenLayer。但是很容易錯誤地使用它們。 什麼是BLS簽名？讓我們談談使用它們的正確方法和錯誤方法：

但首先，什麼是BLS簽名？ BLS 簽名是一種用於對消息（如 ECDSA）進行簽名的加密原語。 以下是數學的工作原理。它建立在橢圓曲線配對之上。 但是什麼讓他們如此特別呢？為什麼要使用這些花哨的搭配？

BLS 的殺手鐧功能：簽名聚合。 您可以將多個 BLS 簽名合併為一個簽名。這使您可以一次傳輸和檢查 N 個簽名，從而更節省空間和時間！在鏈上，優化對於節省 gas 非常重要。

要深入瞭解BLS簽名的工作原理，以及構建聚合和多重簽名的過程，請查看本帖子末尾連結的完整博客文章！ 現在，讓我們看看BLS簽名是如何出錯的，以及EigenLayer如何使用它們（正確地避免了這些陷阱）！

EigenLayer 是以太坊的 retaking 層。在 EigenLayer AVS 中，驗證者對其驗證計算的結果進行簽名。 聚合器收集所有這些簽名並將它們推送到鏈上。聚合的簽名在鏈上進行驗證。

該任務包含創建任務時的數據塊編號和一個閾值，該閾值指示驗證作員驗證的百分比，這是驗證任務所必需的。 選擇加入 AVS 的作員可以獲取這些任務來計算任務答案，然後作員可以將答案及其任務的 BLS 簽名發送給聚合商。 一旦達到相同答案的閾值，聚合器就會將所有BLS簽名合併為一個唯一的聚合簽名，並將其發送回 AVS 合同。 合約驗證簽名是否正確，並開啟一個具有挑戰性的時期，挑戰者可以證明驗證不正確，如果是這樣，行為不端的作員將被罰沒。

在合約中，驗證發生在 'trySignatureAndApkVerification' 函數中：

但是，如果使用不當，多重簽名會帶來一個稱為 rogue-key 攻擊的嚴重問題。 假設一個誠實的使用者有一個公鑰 'pk_0'。以前見過“pk_0”的攻擊者可以選擇他們的公鑰 pk_1 = sk_1⋅G_1—pk_0。 攻擊者不會知道與公鑰關聯的私鑰。但是，多重簽名驗證將提供以下內容：

只需“sk_1”即可對消息進行簽名，從而產生有效的多重簽名，即使第一個使用者可能尚未對其進行簽名。 通過選擇流氓鍵，這很容易推廣到任意數量的誠實使用者 『r』 ，即：

這是一個危險的威脅，因為在我們之前的 AVS 示例中，之前註冊了流氓密鑰的惡意聚合器可能會發送未由驗證者簽名但仍被合同接受的聚合簽名。 這將導致驗證者被罰沒，即使他們沒有行為不端。

因此，為了防止 Rogue 金鑰攻擊，常見的方法是要求使用者證明他們知道私鑰與其公鑰匹配，這稱為擁有權證明。 因此，在第一個註冊步驟中，要求用戶註冊他們的公鑰以及擁有權證明π以便：

基本上，要求使用者簽署他們的公鑰或任何其他識別消息。在 AVS 中，消息是作員位址。 在 EigenLayer 合約中，擁有權證明由 'registerBLSPublicKey' 函數驗證：

函數 'pubkeyRegistrationMessageHash' 用於對自定義域分隔符 'PUBKEY_REGISTRATION_TYPEHASH' 和作員地址進行哈希處理。

註冊后，公鑰將添加到合約中。我們可以通過調用 『getRegisteredPubkey』 函數來驗證它的值。 以下是為 EigenDA AVS 註冊的 BLS 公鑰的範例：

持有證明基本上是BLS簽名。但是，在擁有權證明步驟中使用多重簽名也是不可取的，例如，為單個參與者註冊多個公鑰。 如果是這樣，參與者將實現splitting-zero攻擊。在這種情況下，參與者可以註冊密鑰，這些金鑰在匯總時會被取消，並且可以繞過所有權證明。

我們已經看到BLS多重簽名提供了一個重要的優化機會。 EigenLayer 的實現展示了BLS簽名的強大功能，也突出了其實際部署中涉及的複雜性。但是，多重簽名會帶來安全風險，例如 Rogue-Key 攻擊，這需要保護措施，例如擁有權證明。 但是隨著 Pectra 升級支援 BLS12-381，我們可能會看到 Solidity 的進一步實現和改進，因此我們希望這篇文章有助於避免已知的實現錯誤和漏洞。

要更深入地瞭解BLS簽名、構建聚合和多重簽名，請查看我們最近發佈的以下博客文章：