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