作者：Optech

來源： https://bitcoinops.org/zh/newsletters/2022/12/21/

本譯本由“原語裡弄（ Primitives Lane ）” 提供。

這份特別版的Optech Newsletter 總結了2022 年全年比特幣值得注意的發展。這是我們的年終總結系列（ 2018 、 2019 、 2020以及2021 ）的延續。

一月

一月份，LDK 合併了一個“無狀態發票” 的實現，這種技術允許生成無限數量的發票而不必存儲任何相關數據，除非這樣的發票得到支付。無狀態發票的提議是在2021 年9 月提出的，LDK 的實現不同於建議手段，雖然它實現了相同的目標，而且不需要閃電網絡協議作出任何變更。稍後，閃電網絡規範合併了一項更新，允許其它類型的無狀態發票可以—— 至少是部分地—— 添加到Eclair 、 Core Lightning和LND諸客戶端中。

同樣在一月份，Jack Dorsey、Alex Morcos 和Martin White 設立了一個比特幣法律辯護基金（Bitcoin Legal Defense Fund），這是“一個非營利的實體，致力於盡可能減少阻遏開發者主動開發比特幣和相關項目的法律問題。”

二月

在一月份發生的，關於簡化為預簽名的交易增加手續費的討論，在二月份引發了關於Jeremy Rubin 在2020 年提出的“交易手續費贊助” 想法的新一輪討論。人們提出了對這種實現的多項挑戰。儘管當時的討論沒有取得太大的精湛，但一種實現了類似目標—— 而且不像手續費贊助那樣需要軟分叉—— 的技術在十月份出現了。

LKD 對無狀態發票的初步支持，使它可以加入一種新的、用於閃電網絡節點負載均衡的簡單方法，稱作“幻影節點支付”。

比特幣2022全年回顧：盤點那些值得關注的發展動向

三月

由René Pickhardt 和Stefan Richter 在2021 年首次推出的閃電網絡尋路算法在三月得到了一次更新，Pickhardt 指出一項優化使其計算效率提高很多。

一項與之匹配、允許開設“零確認通道” 的方法也形成了規範，並開始產生實現；LDK 在三月添加對相關的“通道短標識符（SCID）”暱稱字段時率先起步， Eclair 、 Core Lightning和LND相繼跟上。

比特幣2022全年回顧：盤點那些值得關注的發展動向

2022 總結：Replace-By-Fee

今年，我們看到了許多關於“手續費替換（RBF）” 的討論，以及一些重要的行動。我們一月份的周報總結了一項來自Jeremy Rubin 的提議：任意交易都可以在原版交易到達節點後的一段時間內被更高手續費的替代版本替換；超時之後，再應用現有的規則——僅允許遵循BIP125的替代版本替換原版。這將允許商家在替換窗口關閉之後接受未確認的交易，就像現在這樣。更重要的是，它也許可以讓依賴於可替換性來實現安全性的協議不必擔心未攜帶BIP125 信號的交易，只要一個協議節點或者瞭望塔擁有合理的機會、在知曉一筆交易後即時響應即可。

在一月底， Gloria Zhao 開始了一場關於RBF 的新討論，她介紹了當前的RBF 策略的背景、過去幾年間發現的一些問題（例如“交易釘死攻擊”）、RBF 策略如何影響錢包軟件的用戶界面，以及幾種可能的優化措施。在三月上旬，Zhao 追加了兩場關於RBF 的開發者討論的總結，一場來自線上，一場來自線下。

同樣在三月，Larry Ruane 提出了跟RBF 相關的問題：替換交易的見證數據而不改變交易的其餘部分（決定txid 的部分）。

在七月，Antoine Riard 在Bitcoin Core 代碼庫開啟了一個PR，為Bitcoin Core 添加了一個mempoolfullrbf配置選項。這個選項默認保持Bitcoin Core 以前的行為：僅允許包含BIP125信號的未確認交易被替換。而額外配置了這個選項的節點則會接受任意替換交易並轉發和挖礦，即使原版交易並不包含BIP125 信號。 Riard 也在Bitcoin-Dev 郵件組中開啟了一個帖子以討論這一變更。幾乎所有的PR 評論都是正面的，而大部分郵件組討論都是不相關的話題，所以並不意外地，這個PR 在開啟的大約一個月後合併了。

在十月份，Bitcoin Core 項目開始分發24.0 版本的候選版本—— 24.0 將是第一個包含mempoolfullrbf配置選項的。 Dario Sneidermanis 看到了候選版本的更新聲明中關於這個選項的部分，於是在Bitcoin-Dev 郵件組中發帖指出，太多用戶和礦工啟用這個選項會讓不帶信號的替換交易變成可以依靠的。而更可靠的無信號替換交易也會讓接受未確認交易作為支付手段的服務商更容易遭受盜竊、迫使這些服務商改變自己的行為。討論在接下來的一周和又一周連綿不斷。一個月後，Sneidermanis 在郵件組中引起了擔憂的苗頭，Suhas Daftuar 總結了反對該選項的一些論證，並開啟了一個將它從Bitcoin Core 中移除的PR。類似的其它PR 在此前和此後都出現了，但Daftuar 的PR 變成了討論有無可能永久移除這個選項的焦點。

在Daftuar 的PR 中出現了許多指出保留mempoolfullrbf的反面意見。包括許多錢包開發者都提到，有時候他們會遇到希望發起替換、又沒有使用BIP125 信號的用戶。

在十一月末，Daftuar 關閉了這個PR，而且Bitcoin Core 項目也放出了帶有mempoolfullrbf的24.0。在十二月，開發者0xB10C推出了一個網站，用於監控並不包含BIP125 信號的替換交易；這樣的交易如果能得到確認，則表明它可能由一個使用mempoolfullrbf配置選項（或帶有類似特性的其它軟件）開啟全面RBF（full-RBF）的礦工經手。至今年年底，全面RBF 依然在其它的Bitcoin Core PR 和郵件組帖子中被討論。

四月

四月份，Ruben Somsen 提出了“靜默支付” 的想法，它將允許人們給一個公開的標識符（近似於“地址”）支付，但不必在鏈上顯示出這個標識符。這可以幫助防止地址復用。舉個例子，Alice 可以在自己的網頁中發布一個公開標識符，而Bob 可以將這個標識符轉化為一個獨一無二的、只有Alice 可以花費的比特幣地址。如果Carol 後來訪問Alice 的網站，並複用Alice 的標識符，她將推導出另一個地址；這個地址無論是Bob 還是其它第三方，都無法直接斷定是否屬於Alice。後來，開發者W0ltx 為Bitcoin Core 創建了靜默支付的一個提議實現，並在稍後取得了重大進展。

Lightning Labs 推出了Taro，這個協議（基於以前的提議）允許用戶將非比特幣的代幣的創建和轉移承諾到比特幣區塊鏈上。 Taro 旨在跟閃電網絡一起使用，實現可路由的鏈下轉賬。類似於以前的閃電網絡跨資產轉賬提議，僅僅轉發支付的中間節點不需要理解Taro 協議，也不需要知道被轉移的資產的細節—— 他們只需使用跟其它閃電支付同樣的協議，轉移比特幣即可。

四月份還出現了關於量子安全的密鑰交換的討論；未來可能出現快速的量子計算機，但量子安全的密鑰交換將允許用戶使用可以抵禦這樣的量子計算攻擊的密鑰來接收比特幣。這份特別版的Optech Newsletter 總結了2022 年全年比特幣值得注意的發展。這是我們的年終總結系列（ 2018 、 2019 、 2020以及2021 ）的延續。

五月

用於創建schnorr 多簽的MuSig2協議在2022 年取得了一些進展。 提議的一個BIP在5 月收到了重要的反饋。後來，在10 月，Yannick Seurin、Tim Ruffing、Elliott Jin 和Jonas Nick 發現了一個 漏洞：該協議在某些方式下可被利用。研究人員宣布他們計劃在更新版本中修復該漏洞。

包中繼的BIP 草案由Gloria Zhao 在5 月發布。包中繼修復了Bitcoin Core CPFP 手續費追加這一重大問題。這個問題是如果其父交易支付的費率高於節點的動態最低交易池手續費，則各個節點只會接受手續費追加的子交易。這使得CPFP 對依賴於預簽名交易的協議來說不夠可靠，例如許多合約協議（包括當前的閃電網絡協議）。包中繼允許將父交易和子交易看作是一個單位進行評估，從而消除了上述問題——儘管沒有消除其他相關問題，例如交易釘死。在6 月份， 有更多關於包中繼的討論。

在5 月份，我們還見證了比特幣內核庫項目（libbitcoinkernel）的第一次合併，試圖將盡可能多的Bitcoin Core 共識代碼分離到一個單獨的庫中，即使該代碼仍附帶有一些非共識代碼。從長遠來看，這一目標是精簡libbitcoinkernel 到只包含共識代碼，讓其他項目可以輕鬆使用該代碼或讓審計人員分析對Bitcoin Core 的共識邏輯的變更。幾個額外的libbitcoinkernel PR 也在今年合併。

2022 總結：流行基礎設施項目的主要發布

六月

6 月，閃電網絡開發人員開會討論協議開發的未來。討論的主題包括基於taproot的閃電網絡通道、 tapscript和MuSig2 （包括遞歸MuSig2）、更新gossip 協議以公告新通道及已變更通道、洋蔥消息，盲化路徑、探測（probing）及餘額共享、蹦床（trampoline ）路由、要約（offers）和LNURL 協議。

七月

7 月，Bastien Teinturier 發布了一篇關於限制洋蔥消息以防止拒絕服務攻擊想法的摘要。他將該想法歸功於Rusty Russell。但是，Olaoluwa Osuntokun 建議可以重新考慮他在3 月份的提案。該提案通過對數據中繼收費來防止濫用洋蔥消息。參與討論的大多數開發人員似乎更願意在向協議添加額外費用之前先嘗試限制速率。

本月Bitcoin Core 還合併了一個pull request ，添加了對用miniscript編寫的輸出腳本描述符僅觀察模式的支持。我們預計未來的PR 將允許錢包為基於miniscript 的描述符創建簽名。隨著其他錢包和簽名設備實現miniscript 支持，在錢包之間轉移策略、多個錢包合作花費比特幣應該變得更容易，例如多重簽名策略或者那些涉及到不同簽名者在不同場合下的策略（例如後備簽名者）。

八月

8 月，Eclair 合併了一項對交互式充值協議的支持。雙重充值協議依賴於該支持。雙重充值協議允許兩個節點中的任何一個（或共同）為新的閃電網絡通道充值。當月晚些時候，另一項合併使Eclair 開始對雙重充值進行實驗性支持。雙重充值的開放協議有助於確保商家能夠訪問那些能立即收到客戶付款的通道。

Antoine Riard 和Gleb Naumenko 發布了一份關於 通道阻塞攻擊及其若干建議解決方案的指南。對於攻擊者控制的每個通道，他們可以通過發送永遠不會完成的付款使十多個其他通道無法使用——這意味著攻擊者不需要支付任何直接成本。該問題自2015 年以來就已為人所知，但之前提出的解決方案均未獲得廣泛接受。在之後的11 月，Clara Shikhelman 和Sergei Tikhomirov 將發表他們自己的論文。論文中有對此的分析和建議的解決方案，包括基於小額預付費用和基於信譽自動推薦。隨後，Riard 發表了一個使用特定於節點、不可交易令牌的替代解決方案。在之後的12 月，Joost Jager 將宣布一個“簡單但不完美”的實用程序，可以幫助節點減輕一些阻塞問題，而無需對閃電網絡協議進行任何更改。

比特幣2022全年回顧：盤點那些值得關注的發展動向

Lloyd Fournier 寫了一篇關於DLC預言機使用Boneh-Lynn-Shacham（ BLS ）簽名進行證明的好處。比特幣不支持BLS 簽名，需要軟分叉才能添加它們，但Fournier 給出了他合著的一篇論文鏈接。該論文描述瞭如何從BLS 簽名中安全地提取信息，將該信息用在與比特幣兼容的簽名適配器中而不對比特幣進行任何變更。這將允許“無狀態”預言機，其中合約各方（但不是預言機）可以私下同意他們希望預言機證明哪些信息，例如，通過指定一個程序。而該程序可用他們所知預言機可以運行的任何編程語言來編寫。

然後他們可以根據合約分配他們的存款資金，甚至不需要告知預言機他們計劃使用它。到了結算合約的時候，每一方都可以自己運行程序。如果他們都同意運行結果，就可以合作結算合約，根本不需要預言機的參與；如果他們不同意，他們中的任何一方都可以將程序發送到預言機（可能需要為其服務支付少量費用）並收到BLS 對程序源代碼的證明以及運行程序的返回值。證明可以轉換為允許在鏈上結算DLC 的簽名。與當前的DLC 合約一樣，預言機無法根據其BLS 簽名知道是哪些鏈上交易。

2022 總結：Bitcoin Optech

在Optech 的第五年，我們發布了51 份週報，並在我們的主題索引中新增了11 個頁面。 Optech 今年總共發表了超過70,000 字的有關比特幣軟件研發的文章，大致相當於一本200 頁的書。

九月

Lisa Neigut 在Lightning-Dev 郵件列表中發表了一個費率卡的提案。該提案允許節點宣傳其轉發費用的四級費率。更好地宣傳轉發費用，包括在某些情況下設置負費用的能力，可以幫助確保轉發節點有足夠的容量將付款中繼到最終目的地。開發人員ZmnSCPxj 在今年早些時候曾發布了他自己基於費用來改進路由的解決方案。這是一種使用費率卡的簡單方法，“你可以將價目表建模為相同兩個節點間的四個獨立通道，每個都有不同的成本。如果成本最低的路徑失敗了，你只需嘗試另一條可能有更多跳數但有效成本較低的路由，或者以更高的成本嘗試相同的通道。” René Pickhardt 建議了一個支付流量控制的替代方法。

十月

在十月，Gloria Zhao 提出允許使用版本號3 的交易運用修改後的交易中繼策略組。這些策略基於使用CPFP和RBF的經驗，並增添了打包中繼的思想。設計這些策略是為了幫助防止LN 等兩方合約協議中的釘死攻擊—— 確保用戶能夠及時得到交易確認，以關閉通道，結算付款( HTLCs ) ，並對不當行為進行強制懲罰。 Greg Sanders 在本月晚些時候跟進，提出一個關於臨時錨點的額外提議，一種已經在大多數LN 實現中應用的錨點輸出的簡單形式。

Eclair 增加了在使用蹦床中繼時對基礎形式的異步付款的支持。異步付款允許在無需信任有資產的第三方的情況下向離線節點（例如手機錢包）支付。異步支付的理想機制依賴PTLCs ，但為其部分實現，僅需要第三方延遲轉發資金，直到離線節點恢復上線。蹦床節點可以提供這種延遲，因此這個PR 利用它們來進行異步支付的實驗。

十月同樣出現了兩個影響多個應用程序的區塊解析錯誤。 BTCD 的一個意外觸發的錯誤使它和下游程序LND 無法處理最新的區塊。這會讓用戶丟失資產，儘管尚未報告此類問題。 第二個相關錯誤此次被故意觸發，再次影響了BTCD 和LND 以及某些版本的Rust-Bitcoin 的用戶。同樣，可能有用戶失去資金，儘管我們尚未得到此類事件報告。

John Light 發布了一篇關於validity rollups 的研究報告—— 一種側鏈，其當前狀態被緊湊地存儲在主鏈上。側鏈比特幣的所有者可以使用存儲在主鏈上的狀態來證明他們控制了多少個側鏈比特幣。通過提交帶有有效性證明的主鏈交易，他們可以從側鏈上提取其擁有的比特幣，即使側鏈的運營商或礦工試圖阻止。 Light 的研究深入描述了validity rollups，研究瞭如何在比特幣中支持它及實施中的各種擔憂。

BIP324提案更新了，並得到了三年內的首次郵件列表討論。 BIP324 是關於 加密的v2 P2P 傳輸協議。對未經確認的交易進行加密傳輸，有助於隱藏其來源，不被控制許多互聯網中繼的竊聽者（如大型ISP 和政府）發現。它還可以幫助檢測篡改，並可能使日蝕攻擊更加困難。

一次比特幣協議開發者會議中，Bryan Bishop 主持了幾項議題討論，包括傳輸加密、交易費和經濟安全性、 FROST門限簽名方案、使用GitHub進行源代碼託管和開發討論的可持續性、BIP 中的可證明規範、包中繼和v3 交易中繼、Stratum 第二版採礦協議、以及讓代碼合併到比特幣核心和其他自由軟件項目。

2022 年軟分叉提議總結

一月伴隨著Jeremy Rubin 舉行第一次IRC 會議，審核和討論OP_CHECKTEMPLATEVERIFY (CTV) 軟分叉提案。同時，Peter Todd 在Bitcoin-Dev 郵件列表中發布了對該提案的一些擔憂，最值得注意的是，他認為此前的軟分叉已經使幾乎所有比特幣用戶受益。

Lloyd Fournier 在DLC-Dev 和Bitcoin-Dev 郵件列表中發布了CTV操作碼如何從根本上減少創建某些 謹慎日誌合約（DLC）所需的簽名數量，以及減少一些其他操作的數量。 Jonas Nick 指出，使用提議的SIGHASH_ANYPREVOUT (APO)簽名哈希模式也可以進行類似的優化。

Russell O'Connor 提議了CTV 和APO 的替代方案——一個軟分叉，增加了一個“OP_TXHASH” 操作碼和一個OP_CHECKSIGFROMSTACK （CSFS）操作碼。 TXHASH 操作碼將指定一個花費交易的哪些部分應該被序列化和散列化，其散列摘要將被放在評估堆棧中供以後的操作碼使用。 CSFS 操作碼將指定一個公鑰，並要求對堆棧上的特定數據進行相應的簽名，例如由TXHASH 創建的交易摘要。這將允許以一種可能更簡單、更靈活、更容易通過其他後續軟分叉擴展的方式來模擬CTV 和APO。

二月，Rusty Russell 提出OP_TX ，這是OP_TXHASH的一個更簡單的版本。同時，Jeremy Rubin 發表了激活CTV 的Signet的參數和代碼。這簡化了提議的操作碼的公開實驗，並使使用該代碼的不同軟件之間的兼容性測試變得更加容易。同樣在2 月，開發者ZmnSCPxj 提出了一個新的操作碼OP_EVICT ，作為2021 年提出的操作碼OP_TAPLEAF_UPDATE_VERIFY （TLUV）的替代。與TLUV 一樣，EVICT 專注於兩個以上用戶共享單個UTXO 所有權的用例，如joinpools 、 channel factories和某些covenants 。 ZmnSCPxj 後來提出一個不同的新操作碼， OP_FOLD ，作為一個可以建立類似EVICT的行為的更通用的構造（儘管這需要一些其他腳本語言的改變）。

到了三月，關於CTV 和較新的操作碼提案的討論導致了關於限制比特幣腳本語言的表現力的討論，主要是為了防止遞歸契約——在重新花費這些比特幣及與其合併的比特幣的每筆交易中都需要永遠滿足這些條件。擔心的問題包括失去抗審查能力，啟用驅動鏈，鼓勵不必要的計算，並使用戶有可能因遞歸契約而意外地丟幣。

三月還見證了另一個對比特幣的腳本語言進行軟分叉的想法，這次是允許未來的交易選擇使用一種完全不同的基於Lisp 的語言。 Anthony Towns 提議了這個想法，並描述了它如何比Script 以及之前提議的替代品Simplicity更好。

四月，Jeremy Rubin 在Bitcoin-Dev 郵件列表發布了發佈軟件的計劃，該軟件允許礦工開始示意他們是否打算強制執行針對擬議的CTV 操作碼的BIP119規則。這引發了關於CTV 和類似建議的討論，如APO。 Rubin 後來宣布，由於他和其他CTV 支持者評估了他們收到的反饋，他目前不會發布激活CTV 的編譯軟件。

五月，Rusty Russell 更新了他的OP_TX提案。最初的提議將允許遞歸契約，這引起了本節前面提到的擔憂。取而代之的是，Russell 提出了一個TX 的初始版本，僅限於允許CTV 的行為，CTV 是專門為防止遞歸契約而設計的。這個新版本的TX 可以在未來逐步更新，以提供更多的功能，使其更加強大，但也允許對這些新功能進行獨立分析。五月的附加討論考察了OP_CAT操作碼（2010年從比特幣中刪除），一些開發者偶發建議將來可將其作為添加的候選操作碼。

九月，Jeremy Rubin 描述了如何將可信設置程序與提議的APO 特性相結合，實現類似於驅動鏈所提議的行為。防止驅動鏈在比特幣上的實施是開發者ZmnSCPxj 在今年早些時候建議全節點運營商反對實現了遞歸契約的軟分叉的原因之一。

同樣在九月，Anthony Towns 宣布一個專門為測試軟分叉而設計的比特幣實現signet 。基於比特幣核心，Towns 的代碼將以高質量的規範和實現來執行軟分叉提案的規則，使用戶更簡單地嘗試擬議的更改——包括相互比較更改或看到它們的互動方式。 Towns 還計劃加入對交易中繼政策（如包中繼）提議的重大改變。

十一月，Salvatore Ingala 在Bitcoin-Dev 郵件列表中發布了一個提議，提出了一個新的契約類型（需要一個軟分叉），允許使用默克爾樹來創建智能合約，此合約可以在一筆鏈上交易到另一筆鏈上交易中攜帶狀態。這將與其他一些密碼貨幣系統智能合約的應用類似，但與比特幣現有的基於UTXO 的系統兼容。

十一月

十一月見證了Joost Jager 更新了2019 年的一份提案，該提案用於改善LN 中失敗支付的錯誤報告。該錯誤將指明未能由節點轉發付款的通道的身份，這樣花費者可以在有限時間內避免使用包含該節點的通道。一些LN 的實現將更新代碼支持此提案，即使他們不會立即開始使用。這些實現包括Eclair和Core Lightning 。

十二月

在十二月，協議開發者John Law 在Lightning-Dev 郵件列表中發表了他今年的第三份主要提案。如前兩份提案，他提出了LN 的鏈外交易的新設計方式，以在不對比特幣的共識代碼進行任何修改的情況下實現新的功能。總的來說，Law 提出了LN 臨時用戶可以一次保持離線狀態數月的方式，將特定付款的執行與已結算資產的管理分離，以提高與瞭望塔的兼容性，並優化通道工廠中LN 通道的使用，這可以大規模降低使用LN 的鏈上開銷。

我們感謝所有前文中列出姓名的比特幣的貢獻者，並感謝做出同樣重要工作的其他人，他們為比特幣的發展創造了難以置信的另一年。 Optech 週報將於1 月4 日恢復常規週三出版計劃。