一文讀懂Schnorr籤名如何提升比特幣
原文標題:《幹貨 | Schnorr 籤名如何提升比特幣》,作者Stepan
在閱讀 Blockstream 撰寫的 MuSig 論文時,我一直在想象,這對於我一個比特幣用戶來說,到底意味着什么。我發現 Schnorr 籤名的一些特性實在是非常棒而且便利,但某一些特性則非常煩人。在這篇文章裏,我希望能跟各位分享我的想法。不過,我們先快速回顧一下。
橢圓曲线籤名算法
當前比特幣的所有權體系用的是 ECDSA(橢圓曲线籤名算法)。在籤名一條消息 m 時,我們先哈希這條消息,得出一個哈希值,即 z = hash(m) 。我們也需要一個隨機數(或者至少看似隨機的數)k 。在這裏,我們不希望信任隨機數生成器(有太多的錯誤和漏洞都與不合格的隨機數生成器有關),所以我們通常使用 RFC6979,基於我們所知的一個祕密值和我們要籤名的消息,計算出一個確定性的 k。
使用私鑰 pk ,我們可以為消息 m 生成一個籤名,籤名由兩個數組成:r(隨機點 R = k * G 的 x 坐標)和 s = (z + r*pk)/k。
然後,使用我們的公鑰 P = pk * G ,任何人都可以驗證我們的籤名,也就是檢查 (z/s)×G+(r/s)×P 的 x 坐標確為 r。
ECDSA 算法圖解。為便於說明,橢圓曲线作在實數域上
這種算法是很常見的,也非常好用。但還有提升空間。首先,籤名的驗證包含除法(1/s)和兩次點乘法,而這些操作的計算量都非常大。在比特幣網絡中,每個節點都要驗證每一筆交易,所以當你在網絡中發出一筆交易時,全網幾千個節點都要驗證你的籤名。因此,即使籤名的過程开銷變得更大,讓驗證籤名變得更簡單也還是非常有好處的。
其次,節點在驗證籤名時,每個籤名都要單獨驗證。在一個 m-n 的多籤交易中,節點必須多次驗證同一個籤名。比如一筆 7-11 的多籤名交易,裏面包含了 7 個籤名,網絡中的每個節點都要分別驗證 7 個籤名。另外,這種交易的體積也非常大,用戶必須為此付出多得多的手續費。
Schnorr 籤名
Schnorr 籤名的生成方式有些許不同。它不是兩個標量 (r, s),而是一個點 R 和一個標量 s 。類似於 ECDSA 籤名,R 是一個橢圓曲线上的隨機點 R = k * G。而籤名的第二部分 s 的計算過程也有一些不同: s = k + hash(P,R,m) ⋅ pk 。這裏 pk 就是你的私鑰,而 P = pk * G 是你的公鑰,m 就是那條消息。驗證過程是檢查 s * G = R + hash(P,R,m) * P。
圖解 Schnorr 籤名和驗證
這個等式是线性的,所以多個等式可以相加相減而等號仍然成立。這給我們帶來了 Schnorr 籤名的多種良好特性。
1. 批量驗證
在驗證區塊鏈上的一個區塊時,我們需要驗證區塊中所有交易的籤名都是有效的。如果其中一個是無效的,無論是哪一個 —— 我們都必須拒絕掉整個區塊。
ECDSA 的每一個籤名都必須專門驗證,意味着如果一個區塊中包含 1000 條籤名,那我們就需要計算 1000 次除法和 2000 次點乘法,總計約 3000 次繁重的運算。
但有了 Schnorr 籤名,我們可以把所有的籤名驗證等式加起來並節省一些計算量。在一個包含 1000 筆交易的區塊中,我們可以驗證:
(s1+s2+…+s1000) × G=(R1+…+R1000)+(hash(P1,R1,m1)×P1+ hash(P2,R2,m2)×P2+…+hash(P1000,R1000,m1000)×P1000)
這裏就是一連串的點加法(從計算機運算的角度看,簡直是免費的)和 1001 次點乘法。已經是幾乎 3 倍的性能提升了 —— 驗證時只需為每個籤名付出一次重運算。
兩個籤名的批量驗證。因為驗證等式是线性可加的,所以只要所有的籤名都是有效的,這幾個等式的和等式也必成立。我們節約了一些運算量,因為標量和點加法比點乘法容易計算得多。
2. 密鑰生成
我們想要安全地保管自己的比特幣,所以我們可能會希望使用至少兩把不同的私鑰來控制比特幣。一個在筆記本電腦或者手機(在线錢包,熱錢包)上使用,而另一個放在 硬件錢包/冷錢包 裏面。即使其中一個泄露了,我們還是掌控着自己的比特幣。
當前,實現這種錢包的做法是通過 2-2 的多籤名腳本。也就是一筆交易需要包含兩個獨立的籤名。
有了 Schnorr 籤名,我們可以使用一對密鑰 (pk1,pk2),並使用一個共享公鑰 P = P1 + P2 = pk1 * G + pk2 * G 生成一個共同籤名。在生成籤名時,我們需要在兩個設備上分別生成一個隨機數 (k1, k2),並以此生成兩個隨機點 Ri = ki * G,再分別加上 hash(P, R1 + R2, m),就可以獲得 s1 和 s2 了(因為 si = ki + hash(P, R, m)* pki )。最後,把它們都加起來即可獲得籤名 (R, s) = (R1+R2, s1+s2),這就是我們的共享籤名,可用共享公鑰來驗證。其他人根本無法看出這是不是一個聚合籤名,它跟一個普通的 Schnorr 籤名看起來沒有兩樣。
不過,這種做法有三個問題。
第一個問題是 UI 上的。要發起一筆交易,我們需要在兩個設備上發起多輪交互 —— 為了計算共同的 R,為了籤名。在兩把私鑰的情況下,只需訪問一次冷錢包:我們可以在熱錢包裏准備好待籤名的交易,選好 k1 並生成 R1 = k1 * G,然後把待籤名的交易和這些數據一同傳入冷錢包並籤名。因為已經有了 R1,籤名交易在冷錢包中只需一輪就可以完成。從冷錢包中我們得到 R2 和 s2,傳回給熱錢包。熱錢包使用前述的 (k1,R1) 籤名交易,把兩個籤名加總起來即可向外廣播交易了。
這在體驗上跟我們現在能做到的沒有什么區別,而且每當你加多一把私鑰,問題就會變得更加復雜。假設你有一筆財富是用 10 把私鑰共同控制的,而 10 把私鑰分別存放在世界各地,這時候你要發送交易,該有多麻煩!在當前的 ECDSA 算法中,每個設備你都只需要訪問一次,但如果你用上 Schnorr 的密鑰聚合,則需要兩次,以獲得所有的 Ri 並籤名。在這種情況下,可能不使用聚合,而使用各私鑰單獨籤名的方式會好一些 —— 這樣就只需要一輪交互。
文章完成後,我得到了 Manu Drijvers 的反饋:在一個可證明安全性的多籤名方案中,你需要 3 輪交互:
選擇一個隨機數 ki 以及相應的隨機點 Ri = ki \ G,然後告訴每一個設備 Ri 的哈希值 ti=hash(Ri),然後每個設備都能確保你沒有在知道其他人的隨機數之後改變主意*
收集所有的數字 Ri 並計算公共的 R
籤名
第二個問題是已知的 Rogue 密鑰攻擊。這篇論文講解得非常好,所以我就不贅述了。大概意思是如果你的其中一個設備被黑(比如你的熱錢包被劫持),並假裝自己的公鑰是 (P1 - P2),那就可以僅憑私鑰 pk1 便控制兩個私鑰共享的資金。一個簡單的解決方案是,在設置設備時,要求使用私鑰對相應的公鑰籤名。
還有第三個重大問題。你沒法使用確定性的 k 來籤名。如果你使用了確定性的 k,則只需一種簡單的攻擊,黑客即可獲得你的私鑰。攻擊如下:某個黑客黑入你的筆記本電腦,完全控制了其中一把私鑰(比如 pk1)。我們感覺資金仍是安全的,因為使用我們的比特幣需要 pk1 和 pk2 的聚合籤名。所以我們像往常一樣發起交易,准備好一筆待籤名的交易和 R1,發送給我們的硬件錢包,硬件錢包籤名後將 (R2, s2)發回給熱錢包 …… 然後,熱錢包出錯了,沒法完成籤名和廣播。於是我們再試一次,但這一次被黑的電腦用了另一個隨機數 —— R1' 。我們在硬件錢包裏籤名了同一筆交易,又將 (R2, s2')發回給了被黑的電腦。這一次,沒有下文了 —— 我們所有的比特幣都不翼而飛了。
在這次攻擊中,黑客獲得了同一筆交易的兩個有效的籤名:(R1, s1, R2, s2) 和 (R1', s1',R2,s2')。這個 R2 是一樣的,但是 R = R1 + R2 和 R' = R1' + R2 是不同的。這就意味着黑客可以計算出我們的第二個私鑰:s2-s2'=(hash(P,R1+R2,m)-hash(P,R1'+R2,m))⋅pk2 或者說 pk2=(s2-s2')/(hash(P,R1+R2,m)-hash(P,R1'+R2,m))。我發現這就是密鑰聚合最不方便的地方 —— 我們每次都要使用一個好的隨機數生成器,這樣才能安全地聚合。
3. Musig
MuSig 解決了其中一個問題 —— rogue key 攻擊將不能再奏效。這裏的目標是把 多方/多個設置的籤名和公鑰聚合在一起,但又無需你證明自己具有與這些公鑰相對應的私鑰。
聚合籤名對應着聚合公鑰。但在 MuSig 中,我們不是把所有聯合籤名者的公鑰直接相加,而是都乘以一些參數,使得聚合公鑰 P = hash(L,P1)×P1 + … + hash(L,Pn)×Pn 。在這裏,L = hash(P1,…,Pn) —— 這個公共數基於所有的公鑰。L 的非线性特性阻止了攻擊者構造特殊的公鑰來發動攻擊。即使攻擊者知道他的 hash(L,Patk)×Patk 應該是什么,他也無法從中推導出 Patk 來 —— 這就跟你想從公鑰中推導出私鑰是一樣的。
籤名構造的其它過程跟上面介紹的很像。在生成籤名時,每個聯合籤名者都選擇一個隨機數 ki 並與他人分享 Ri = ki * G。然後他們把所有的隨機點加起來獲得 R=R1+…+Rn ,然後生成籤名 si = ki + hash(P,R,m) ⋅ hash(L,Pi) ⋅ pki 。因此,聚合籤名是 (R, s)=(R1+…+Rn, s1+…+sn) ,而驗證籤名的方法與以前一樣:s×G = R + hash(P,R,m)×P 。
4. 默克爾樹多籤名
你可能也注意到了,MuSig 和密鑰聚合需要 *所有籤名者籤名一個交易*。但如果你想做的是 2-3 的多籤名腳本呢?這時候我們能夠使用籤名聚合嗎,還是不得不使用通常的 OP_CHECKMULTISIG 和分別籤名?(譯者注:OP_CHECKMULTISIG 是比特幣驗證橢圓曲线多籤名腳本的操作碼)
先說答案,是可以的,但是協議上將有些許的不同。我們可以开發一個類似於 OP_CHECKMULTISIG 的操作碼,只不過是檢查聚合籤名是否對應於公鑰默克爾樹上的一個元素。
舉個例子,如果我們想用公鑰 P1、P2 和 P3 組成一個 2-3 的多籤名腳本,我們需要用這幾把公鑰的所有兩兩組合 (P1, P2)、(P2, P3)、(P1, P3) 來構建一棵默克爾樹,並把默克爾樹根公布在鎖定腳本中。
在花費比特幣時,我們需要提交一個籤名和一個證據,證明這個籤名所對應的公鑰位於由這個樹根標記的默克爾樹上。對於 2-3 多籤名合約來說,樹上只有 3 個元素,證據只需 2 條哈希值 —— 那個我們想用的公鑰組合的哈希值,還有一個鄰居的。對於 7-11 多籤名腳本來說,公鑰組合有 11!/7!/4!=330 種,證據需要 8 條哈希值。通常來說,證據所包含的元素數量與多籤名的密鑰數量大體成正比 ,為 log2(n!/m!/(n-m)) 。
但有了默克爾公鑰樹,我們就不必局限於 m-n 多籤名腳本了。我們可以做一棵使用任意公鑰組合的樹。舉個例子,如果我們有一個筆記本電腦,一個手機,一個硬件錢包和一個助記詞,我們可以構建一棵默克爾樹,允許我們使用 筆記本電腦 + 硬件錢包、手機 + 硬件錢包 或者單獨的助記詞來使用比特幣。這是當前的 OP_CHECKMULTISIG 做不到的 —— 除非你使用 “IF - Else” 式的流程控制來構造更復雜的腳本。
聚合公鑰的默克爾樹。不僅僅是多籤名
結論
Schnorr 籤名很棒,它解決了區塊驗證中的一些計算开銷問題,也給了我們密鑰聚合的能力。後者在使用時有些不便利,但我們不是在強迫大家使用它 —— 無論如何,我們都可以仍舊使用普通的多籤名方案,使用單獨的、不聚合的籤名。
我迫不及待想使用 Schnorr 籤名,希望比特幣協議能盡快納入這種籤名方案。
另外,我也真心喜歡 MuSig,它是個優雅的方案,論文也淺顯易懂。我強烈建議各位有闲之時通讀全文。
鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播信息之目的,不構成任何投資建議,如有侵權行為,請第一時間聯絡我們修改或刪除,多謝。
Uniswap公告Unichain主網明年初上線!首測路線圖兩功能,UNI強彈17%
去 中心化交易所(DEX)龍頭 Uniswap 於 10 月宣佈推出專為 DeFi 設計的 Lay...
下周必關注|LayerZero決定是否开啓“費用开關”;Aligned空投注冊結束(12.23-12.29)
下周重點預告 12 月 23 日 Aligned 將向 891322 個地址空投 26% 的 AL...
空投周報 | OpenSea基金會官推上线;Azuki、Doodles疑似即將發幣(12.16-12.22)
@OdailyChina @web3_golem Odaily星球日報盤點了 12 月 16 日至...
資金費率的演變:從2021年黃金時代,到2024-2025年套利復興
資金費率起源 資金費率起源於加密貨幣衍生品市場,特別是從永續期貨合約中發展而來。它作為一種機制,用...