摘要：在以太坊未來的 Casper 實現中，有非常多的驗證者都要對區塊簽名，加密貨幣簽名算法BLS以其聚合免信任等多種特性脫穎而出。
上篇，我們對加密貨幣簽名算法BLS的特性及其優勢做了著重的闡述。本文，我們將對BLS如何應用於加密貨幣以及其工作原理做簡要分析。
將BLS應用於加密貨幣
BLS最明顯的用途是加密貨幣中m-n的多重交易，比如比特幣。用戶可以向他的錢包詢問m-of-n地址，然後獲得單個地址和密鑰共享列表。之後，它會把“密鑰分享”分配到不同的地方(電腦或硬件錢包)。錢包不會存儲這些“密鑰共享”，否則所有這些都將毫無意義。
生成的地址在內部只是原始密鑰的公鑰（並不再為人所知）。此外，該地址與普通的1-1BLS地址沒有任何區別，這意味著任何人都不可能知道這實際上是一個m-n多重簽名，也不知道涉及多少密鑰或需要多少共享才能恢復密鑰。
如此一來，對於m-n多重交易就不需要特殊的處理，因為在內部，驗證一個簡單的簽名交易需要完全相同的驗證（例如CHECKBLSSIG）。
目前，基於ECDSA的m-n預算需要有m個公鑰和m個簽名作為交易的一部分，這很容易導致在鏈上產生幾個kB，從進而損壞其延展性。
此外，ECDSA還洩露了用於簽署交易的密鑰的相關信息。但如果使用基於BLS的閾值簽名，預算的大小是固定的(例如32字節)，其獨立於值m和n，也沒有任何隱私洩漏。
使其分佈式且去信任化（免信任）
上述方案本身已經很好了，但它有一個缺點，只有當創造者（交易商）是祕密共享的接收者的時候，它才會生效。因此，只有當你想要分發自己的密鑰以避免安全問題時，它才會很好地工作。
如果涉及多方當事人需要簽署交易的時候，則該方案存在問題。這需要對單一交易商的絕對信任。如果交易商不值得信任或妥協，原始密鑰則可能被濫用或洩露。
幸運的是，由於BLS的特性，這個問題會很容易被修復。
我們可以讓每個參與者都成為一個交易商，然後把多方的結果彙總起來，這樣密鑰就可以在沒有任何人知道的情況下達成一致。
當然，它需要每方參與者進行一次驗證，以確保其他各方都是誠實的。如果遇到不誠實的一方，整個過程必須中止。
這個過程需要對Shamir的祕密共享進行補充，所以我們首先要更詳細地解釋Shamir的祕密共享，然後討論我們需要執行的添加選項。這些添加需要交換一些加密數據，因此每一方必須做的第一件事就是聲明一個BLS公鑰。
在Shamir的祕密共享中，創建了一個度數為n-1次的多項式S(x)。該多項式的第一個值(自由係數)是原始密鑰，其餘的n-1個係數是隨機生成的密鑰。多項式內部可以表示為一個簡單的密鑰向量。多項式中的參數“x”是一個唯一編號，用來標識參與的各方。
例如，它可以是每個參與方基於1的索引，但也可以是任何其他的公知值（例如公鑰或哈希值）。為每一方計算這個多項式給出了每一方的密鑰共享。
如果任何人知道這些祕密共享的“m”，則可以使用多項式插值來恢復原始密鑰，這就是Shamir祕密分享的基礎。
如果我們創建一個相同度數的新多項式P(x)，並將所有係數設置為第一個多項式中使用密鑰的公鑰，我們就可以使用這個新多項式生成與密鑰共享對應的公鑰共享。
這是由於BLS原語的屬性，其中對兩個對應的BLS原語（例如祕密和公鑰）執行相同的操作將生成一個相應BLS原語的新元組。
這個多項式可以公開共享，並且不會洩露任何關於密鑰的信息。它可以用來驗證接收到的密鑰共享實際上是在不知道多項式的情況下對多項式S(x)求值的結果。這隻需要用P(x)計算公鑰共享，並將結果與從接收的密鑰共享所計算的公鑰進行比較即可。
現在，為了使其分佈式且去信任化，我們讓每一方都創建自己的多項式S(x)和P(x)。然後每一方都公佈P(x)以便讓所有方都清楚存在的P(x)。
然後，每一方都將為另一方計算S(x)，並使用之前公佈的公鑰加密結果(密鑰共享)。隨後，每一方將加密的祕密共享發送給相應的其他方。在進行所有這些操作時，每一方還必須為自己執行的S(x)進行評估。
在此之後，每一方都應該接收到精確的“n”加密密鑰共享，這意味著每一方都應該從另一方接收到一個密鑰共享。如果缺少任何密鑰共享或多項式P(x)，則整個過程中止。
當各方收到加密的祕密共享時，他們將首先解密並驗證這些共享。驗證是通過計算P(x)來執行的，其中x是自己的標識符（參與方列表中的索引）。如果計算的結果(公鑰共享)與所接收密鑰共享的計算公鑰不匹配，則整個過程中止。
在這個階段，每一方都應該有“n”個多項式P(x)和“n”個經過驗證的祕密共享。記住，祕密共享使用的多項式S(x)的自由係數（第一個值）與原始密鑰相同。這又意味著P(x)的自由係數是原密鑰的對應公鑰。
現在我們將所有多項式P(x)聚合成一個最終多項式FP(x)。由於BLS原語的屬性，FP(x)的自由係數與最終密鑰的公鑰匹配。
然而，最終密鑰是未知的，因為所有各方只知道各自的多項式S(x)，因此沒有人能夠聚合係數。FP(x)的自由係數（第一個值）是最後一個m-n公鑰，並在隨後用作支付地址。
我們還將所有接收到的密鑰共享聚合為最終密鑰共享。同樣，由於BLS原語屬性，最終得到的密鑰共享與FS(x)的多項式求值結果相匹配。然而，FS(x)也是未知的，因為它還需要聚合所有單方多項式S(x)。
由於各個參與方可能已經決定在此階段中止進程，所以在考慮使用m-n公鑰進行任何支付之前，所有參與方必須首先宣佈進程成功，這一點很重要。否則，即使某些其他方稍後無法提供簽名共享，也可能會欺騙單方使用公鑰。
因此，為了表示成功（協議），各方必須發佈某種協議消息，並使用之前公佈的公鑰的密鑰（不是密鑰共享，而是最開始的那個）進行簽署。
此外，協議消息必須包含本地聚合的m-n公鑰，以便其他各方可以驗證其與聚合的公鑰相同。只有當一方遵守所有“n”所期望的協議時，它才會被認為m-n公鑰是一個好的公鑰。
從現在開始，我們將回到簡單的Shamir祕密共享計劃。每一方都有自己的密鑰共享，並且能夠創建簽名共享。如果收集m-n簽名共享，則可以使用多項式插值來恢復最終的簽名。
這個簽名還是普通的BLS簽名，它針對m-n公鑰進行驗證，m-n公鑰是FP(x)的自由係數。正如你可能猜到的那也，不需要對這些m-n地址和簽名進行特殊處理，一個通用的CHECKBLSSIG就足夠了。
整個過程聽起來可能涉及很多交互性和溝通。然而，這可以簡化為需要交換的幾個消息。
每一方都可以將P(x)和所有單獨加密的密鑰共享打包成一條消息，從而將所需的通信減少到每一方3條消息，即公鑰公告、共享分配和協議。
然而，這將允許觀察者查看哪一個公鑰已經達成一致（密鑰仍然不為任何人所知）。
如果需要更多隱私，則每一方都應將每個P(x)和祕密共享單獨加密發送給所有其他成員。
為了使其更加可用，可以使用中央服務（其中存在多個服務，可以選擇一個）作為代理/調度程序，同時仍然保留單獨的加密。
不管解決方案是什麼，它都可以集成到錢包中，這樣就可以隱藏所有的內部結構。最後，每一方只需選擇其他方，並點擊“生成m-n地址”即可。
更加去中心化和自動化
前面描述的過程可以完全去中心化和自動化。這涉及到一個多階段的網絡協議，該協議能夠處理和容忍進程中的故障。容忍失敗（故障）意味著協議能夠從分佈式密鑰生成中踢出各個參與方，而不是中止整個過程。
BLS的表現
此前Stepan在其文中提到過，BLS 簽名驗證的複雜度要比 ECDSA 高上一個數量級。 在驗證區塊中 1000 筆交易的聚合簽名時，仍需要進行 1000 次配對計算，這可能比使用 ECDSA 時（對 1000 個單獨簽名進行驗證）還要慢。唯一的好處在於，可以在區塊中放更多筆的交易，畢竟聚合簽名只佔 32 字節。
與 BLS 不同，Schnorr 驗證算法的效率很高，它可以把簽名放一起驗證，效率是 ECDSA 算法的三倍。這樣，問題來了，效率和安全哪個對我們更重要？
實際上，BLS 簽名算法已經足夠出色。它能將區塊中的簽名聚合成單一簽名；能進行密鑰聚合和 m-n多重簽名（無需額外通信）；能避免使用隨機數生成器。
這些優點使BLS顯得如此簡單優雅。當然，它仍有改進空間，標準化和優化也尚需時日。但我希望有朝一日，它能變得足夠好，可以被納入比特幣協議中。這樣的話，我們不但能獲得它出色的功能，還可享受體積更小、聚合度更強的簽名算法帶來的好處。
翻譯：共享財經Lam 責任編輯：Alian
（本文系共享財經原創翻譯，轉載請註明出處及作者）
相關推薦
