---
title: "BLS 簽章"
description: "以驗證為核心，理解 Boneh-Lynn-Shacham 簽章、聚合模式、密碼套件、惡意金鑰防禦、以太坊共識用途與實作風險。"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# BLS 簽章
> 僅供教育參考，不構成投資或密碼學實作建議。簽章有效本身無法證明協定安全、授權、可用性或最終性。
## 直接答案
Boneh-Lynn-Shacham 簽章是一種以配對為基礎的數位簽章。在一種常見方向中，私密金鑰 `sk` 產生公開金鑰 `PK = sk * G1`；訊息 `m` 被映射為 `H(m)`，該點位於 `G2`；簽章 `sig = sk * H(m)` 透過 `e(PK, H(m)) = e(G1, sig)` 驗證。確切群、編碼、雜湊至曲線套件與網域分離均由密碼套件決定，不能將不同選擇視為可互換記法。
BLS 有一項特殊的操作優勢：有效簽章可以相加成一個固定大小的群元素。這會壓縮簽章，但不會壓縮簽章者清單，也不能證明法定人數、識別獲授權驗證者、防止雙簽或使共識最終確定。這些屬性來自周邊協定。
## 運作方式
1. 固定協定、密碼套件與版本：曲線、公開金鑰群與簽章群、序列化、雜湊至曲線函式、網域分離標籤與訊息根建構。絕不能只憑 BLS 名稱推斷相容性。
2. 依規定的金鑰產生程序建立 `sk` 並推導 `PK`。根據確切的 `KeyValidate` 與反序列化規則，拒絕零值、無窮點、格式錯誤、非規範及錯誤子群編碼。
3. 建構確切的訊息位元組與簽章網域。在以太坊共識中，簽章根將 SSZ 物件根與由操作類型和分叉資料推導的網域繫結；畫面顯示文字不是被簽署物件。
4. 使用選定方案簽署並逐一驗證。Basic、訊息擴充與持有證明三種變體採用不同的惡意金鑰防禦，不能任意混用。
5. 依訊息模式選擇聚合驗證器。只有在多個已驗證公開金鑰依所需持有證明假設簽署同一訊息時，才使用 `FastAggregateVerify`；對於方案允許的公開金鑰與訊息清單，使用 `AggregateVerify`。
6. 根據委員會資料或參與者位元清單獨立重建簽章者集合，拒絕重複或未授權索引，套用質押權重或門檻權重，然後驗證聚合簽章。有效聚合只認證所提供集合，並不決定該集合是否符合政策。
7. 將結果與分叉選擇、罰沒條件、法定人數、可用性、時限和最終性進行核對。保存輸入位元組、網域、簽章者索引、實作版本與測試向量，並在部署前比較獨立函式庫。
## 算例
- **壓縮不會消除成員資料。** 以太坊共識將每個 BLS 公開金鑰編碼為 `48 bytes`，每個簽章編碼為 `96 bytes`。`512` 個同訊息簽章個別占用 `512 * 96 = 49,152 bytes`。一個聚合簽章加上 `512-bit = 64-byte` 參與者位元清單共占 `96 + 64 = 160 bytes`，減少 `49,152 - 160 = 48,992 bytes`，即 `99.6744791667%`。驗證者公開金鑰與委員會映射仍須在其他位置提供。
- **同訊息聚合。** 假設已註冊驗證者 `17`、`24` 和 `91` 都簽署相同簽章根 `R`，簽章聚合為 `sigAgg = sig17 + sig24 + sig91`。驗證使用有序且已驗證的公開金鑰集合 `[PK17, PK24, PK91]`、同一個 `R` 與 `FastAggregateVerify`。有效結果證明這些金鑰依該方案簽署了 `R`；另一項規則決定其權重，以及三位簽章者是否構成法定人數。
- **不同訊息需要正確 API。** 公開金鑰 `PK1`、`PK2` 和 `PK3` 分別簽署訊息 `m1`、`m2` 和 `m3`。驗證器必須保留配對 `[PK1, m1]`、`[PK2, m2]`、`[PK3, m3]`，並呼叫適用的 `AggregateVerify`；將這些輸入替換為單一訊息並呼叫 `FastAggregateVerify`，驗證的是另一項主張。在 Basic 方案下，訊息還必須互不相同。
- **聚合不等於門檻簽章。** 在一個 `8` 人群組中，成員 `[1, 2, 4, 6, 8]` 的一般簽章聚合會產生一個簽章與五人簽章者清單，不會變成由單一群組公開金鑰驗證的 `5-of-8` 門檻簽章。真正的門檻 BLS 需要分散式金鑰產生或可信任經銷商模型、份額索引與插值規則；其信任與失敗假設必須另行查核。
## 風險
- 使用與協定不同的曲線、群方向或密碼套件。
- 顯示相同可讀訊息，卻簽署不同序列化位元組。
- 遺漏分叉、操作或應用程式網域，導致跨情境重播。
- 將已過期 Internet-Draft 當成不可變的最終標準。
- 接受格式錯誤、非規範或無窮點編碼。
- 跳過子群檢查，接納無效曲線或小子群輸入。
- 不依規定套件與測試向量，而自行撰寫雜湊至曲線程式碼。
- 產生有偏、為零、重複、洩漏或可預測推導的私密金鑰。
- 在持有證明與網域假設不同的協定之間重複使用同一金鑰。
- 未採用方案要求的惡意金鑰防禦，就聚合未註冊公開金鑰。
- 對不同訊息或不一致訊息根呼叫同訊息快速驗證。
- 置換、重複或遺漏公開金鑰與訊息的對應關係。
- 未核實委員會成員資格與索引唯一性就信任參與者位元清單。
- 統計簽章數量，而不是協定定義的質押、權重或門檻。
- 假設單一聚合能指出哪一份個別簽章無效。
- 混淆一般聚合、多重簽章與門檻簽章。
- 將簽章有效視為資料可用、執行正確或最終確定的證明。
- 忽略雙簽、可罰沒訊息、時間窗口或分叉選擇情境。
- 依賴單一函式庫、CPU 功能或未經檢查的批次驗證最佳化。
- 低估配對成本、阻斷服務輸入、旁通道、金鑰保管、升級與不具抗量子安全性的風險。
## 常見迷思
- 聚合簽章證明所有驗證者都參與了。
- 無須持有證明規則，任何 BLS 公開金鑰與簽章都能安全組合。
- 固定大小聚合消除了傳送或重建簽章者成員資訊的需要。
- BLS 聚合與門檻 BLS 是同一種建構。
- 有效 BLS 簽章使所簽區塊、跨鏈橋訊息或協定在經濟上安全且最終確定。
## 相關主題
- [密碼學雜湊](/zh-tw/crypto/cryptographic-hash/)
- [權益證明](/zh-tw/crypto/proof-of-stake/)
- [門檻簽章](/zh-tw/crypto/threshold-signature/)
## 資料來源
- [BLS 簽章](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-06) - Internet Research Task Force（查閱日期：2026-08-12）
- [RFC 9380：雜湊至橢圓曲線](https://www.rfc-editor.org/rfc/rfc9380.html) - RFC Editor（查閱日期：2026-08-12）
- [來自 Weil 配對的短簽章](https://doi.org/10.1007/3-540-45682-1_30) - Springer（查閱日期：2026-08-12）
- [以太坊權益證明共識規範](https://github.com/ethereum/consensus-specs) - Ethereum Foundation（查閱日期：2026-08-12）
- [Phase 0 信標鏈規範](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation（查閱日期：2026-08-12）
- [以太坊註解規範：BLS 簽章](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#bls-signatures) - Ethereum Foundation（查閱日期：2026-08-12）
- [EIP-2537：BLS12-381 曲線運算預編譯](https://eips.ethereum.org/EIPS/eip-2537) - Ethereum Improvement Proposals（查閱日期：2026-08-12）
- [共識機制](https://ethereum.org/developers/docs/consensus-mechanisms/) - Ethereum.org（查閱日期：2026-08-12）
Source: https://wiki.fcontext.com/zh-tw/crypto/bls-signature/index.mdx