作者:Jeffrey Hu
關於近期取消 OP_RETURN 輸出轉發限制的爭論,相關人員在各個渠道(郵件組、Github、論壇、社交媒體等等)有了非常多的激烈討論,也有不少機構、媒體、KOL 的總結和解讀,也不可避免地帶有一定的支持或反對的立場。儘管放寬限制的修改已敲定,但遺憾的是,其中的一些內容對於客觀情況的理解在筆者看來並不準確。
筆者希望本文能為讀者儘可能準確地介紹(科普) OP_RETURN 的原理及比特幣網絡的相關情況、總結此次爭論正反雙方的觀點,並提出一些重要但未解決的問題。
OP_RETURN 是什麼?
可能很多朋友,包括筆者在內,一開始知道 OP_RETURN,是因為它可以讓用戶任意記錄數據在比特幣鏈上。那麼,這個類似交易附言(memo)的功能和它名字是怎麼聯繫到一起的呢?
從“OP”這個前綴不難看出, OP_RETURN 是比特幣腳本中的一個操作碼。但它怎麼攜帶數據呢?這需要從比特幣腳本層面來看。
OP_RETURN <data> OP_RETURN 是一個控制流終止操作碼,正如其他編程語言中的 return 關鍵詞會從函數返回跳出一樣,比特幣腳本一旦執行到該操作就會立即停止執行,並將結果標記為 false,即失敗(而至於為什麼會設計成 false,筆者會在下文解釋)。
由於比特幣的共識規則規定:所有輸入引用的輸出腳本執行後必須返回 true,因此任何包含 OP_RETURN 的輸出在嘗試花費時都會失敗,進而成為“不可花費輸出”。
重要的是,這一驗證行為只在嘗試花費該輸出時才會觸發。而在創建交易時,創建帶有 OP_RETURN 腳本的輸出並不會影響交易的有效性。並且,只要符合節點的標準策略(如大小限制),這樣的交易就會被節點轉發。由於這些輸出永遠無法被花費,它們也就不需要存儲到 UTXO 集,因此不會增加全節點的熱存儲負擔。
這樣就相當於給比特幣提供了一個寫入數據(或塗鴉)的功能。
中本聰也資辭麼?
或許讀者會說,往比特幣鏈上寫內容是天經地義、“自古以來”就有的事情。中本聰的第一個區塊不就寫了那句著名的話嘛 “Chancellor on the brink of second bailout for banks.”。
不過很遺憾,中本聰當時還沒有用上這個 OP_RETURN 這麼高級的功能。前述 OP_RETURN 的完整功能是 Bitcoin Core v0.9.0 版本重新定義的。
儘管在中本聰時代的早期版本就有 OP_RETURN,但在 v0.3.5 版本以前,其動作是跳過尚未執行的腳本部分,並將棧頂元素返回。是不是更像通常意義上的 return 語句?但這會帶來極大的安全隱患。例如攻擊者可以在解鎖腳本里構造出來如下內容:
OP_TRUE OP_RETURN當執行到 OP_RETURN 時,腳本就會把棧頂的 OP_TRUE 返回,而忽略所有鎖定腳本里的檢查條件,從而可以盜竊任何人的比特幣!所以中本聰很快修復,將 OP_RETURN 結果改為總是失敗(false),也就是我們現在看到的“攜帶數據、不可花費”的基礎。
而進一步定義 OP_RETURN <data> 為標準化腳本,從而數據體積在限制內的 OP_RETURN 輸出得以在網絡中轉發,則是在中本聰隱退之後、2014 年的 Bitcoin Core v0.9.0 版本中。
這裡,筆者將這段 OP_RETURN 的修改歷史簡要總結如下:
| 時間 | 版本 / 場景 | OP_RETURN 行為與能力說明 |
|---|---|---|
| 2009–2010 前期 | 比特幣最初版本(v0.1) | 可跳出執行並返回棧頂值,但存在漏洞:攻擊者可構造繞過簽名驗證的腳本,花費任意 UTXO。 |
| 約 2010 年 | Satoshi 緊急修復後 | 改為:執行立即失敗(即返回 false),但仍可用於阻止腳本繼續執行 。 |
| 2014 年 3 月 | Bitcoin Core v0.9.0 | 被重新啟用為標準的 “nulldata 輸出”:可在 scriptPubKey 中使用,創建不可花費的輸出,支持最多 40 字節數據,意在防止 UTXO 集膨脹 。 |
| 2014 年 末 | Bitcoin Core 0.9.x | 社區增強 relay policy,將最大數據限制擴展至 80 字節,仍為 policy 層設置(非共識層)。 |
| 2016 年 | Bitcoin Knots v0.12 默認 | Knots 分支默認更為嚴格的限制,將 OP_RETURN 數據體積限制設為 42 字節,同時用戶可自定義 。 |
各種塗鴉方法
那麼中本聰是怎麼寫那句話的?還有哪些將數據上鍊的方法?
scriptSig
中本聰使用的是 scriptSig(腳本簽名)字段。儘管 scriptSig 需要和解鎖中的輸出腳本(公鑰)對應才能成功花費,但只要精心構造腳本(如在解鎖驗證前用 OP_DROP 丟棄掉塗鴉數據等),仍然可以實現在正常花費的同時攜帶任意數據的效果。
目前直接在 scriptSig 裡寫數據的方式已經不太流行,但仍然會有使用,主要是在 coinbase 交易中。原因可能在於 coinbase 交易不需要解鎖之前的輸出,可更自由地填充一些內容,用來記錄區塊高度、擴展 nonce、礦工標識、信號等。
那麼,scriptSig 有什麼問題導致後來不流行了呢?一部分原因可能是成本:因為 scriptSig 是在交易的輸入中,所以必須先創建一個輸出,然後在花費這個輸出時攜帶數據,因此除了數據本身的體積,還需要為額外的輸出和交易的體積支付手續費(比特幣交易的手續費與其體積正相關)。另一部分則在於編程上的複雜性,同樣來自於必須先創建帶有專門構造的輸出。
P2FK
所以後來人們就想出了一個辦法來簡化:既然創建輸出本身不是為了 保存資金/花費(只是作為揭曉數據的橋樑),那麼可以直接把要寫的內容當作接收公鑰,即 Pay-to-Fake-Key。不再需要發起新的花費交易,需要額外付費體積自然就更小了,手續費成本也就降低了。
OP_PUSHBYTES_65 <fake-pubkey-data> OP_CHECKSIG而因為這個地址是沒有有效的私鑰可以花費的,這個 UTXO 永遠無法花費,其中的比特幣也就相當於是燃燒掉了;但交易從外表來看一切正常,節點還需要存儲,畢竟萬一真有一個對應的私鑰呢?所以代價自然就是 UTXO 集的膨脹,和節點存儲的成本提升。
類似的,還有 P2FKH(類似 P2PKH,將希望寫入的數據作為腳本中的哈希值)、P2FMS(Pay-to-Fake-Multisig,偽裝成裸多簽名腳本中的公鑰)等。
實際上,重新定義 OP_RETURN 為標準化腳本的一大目的就是提供替代方案,希望人們不再使用這些會引發 UTXO 集膨脹的假輸出。
Ordinals/Inscriptions
近些年開始瞭解比特幣的朋友可能對 Ordinals 及其數據寫入方法(“inscriptions”)更為熟悉。Inscriptions 是將任意文件數據放到了 Taproot 輸入的見證數據中。
這種實現方式的最終效果與 OP_RETURN 差別較大:OP_RETURN 輸出中的數據,在創建它的交易中就已經揭曉;inscriptions 則需要另一筆額外交易來揭示 witness 數據(與 scriptSig 方法相似,但經濟性更好)。此外,inscriptions 所受到的全網絡通行的交易池轉發策略較少,而大多數節點都不轉發數據體積超過 80 字節的 OP_RETURN 輸出。
儘管還有其他的技巧來實現數據的寫入,筆者在此對上述幾種流行或曾經流行的方式進行小結。
| OP_RETURN | scriptSig | P2FK/P2FKH | Inscriptions | |
|---|---|---|---|---|
| 原理 | 在不可花費的輸出腳本中攜帶數據 | 在輸入腳本中插入數據 | 將數據偽裝成輸出腳本中的 公鑰/哈希值 | 在 P2TR 輸入的 witness 中插入數據 |
| 發生位置 | 輸出腳本(scriptPubkey) | 輸入腳本(scriptSig) | 輸出腳本 | witness(隔離見證區域) |
| 是否會導致 UTXO 集膨脹 | 否,此種輸出不進入 UTXO 集合 | 不必然,通常不會。中間輸出在花費後就消失 | 是,這些輸出實際上不可花費,但無法從表面上區分,會永久留在 UTXO 集合中 | 不必然,取決於定義 inscriptions 意義的協議。 |
| 數據展示即時性 | 立即展示 | 延後展示 | 立即展示 | 延後展示 |
| 成本(手續費) | 低 | 高,需要先創建中間輸出 | 較低,因為腳本操作碼通常更多、輸出需攜帶價值而高於 OP_RETURN | 較高,因為 witness 體積折扣而低於 scriptSig 方法 |
| 是否受通行交易轉發策略影響 | 是 | 否 | 否 | 否 |
轉發策略 vs 共識規則
在上文及之前的表格中,筆者都提到了一個關鍵詞 “交易轉發策略”。近期的 OP_RETURN 風波的很大一部分討論焦點就集中在交易池轉發策略上。
交易轉發策略是指一個比特幣節點(如 Bitcoin Core)在轉發和接受未確認交易時執行的一系列非共識規則。這些策略通常用於防範 DoS 攻擊、預留日後升級空間或引導鼓勵某種更優行為。如果一筆交易符合節點本地的轉發策略規定(包括輸入輸出類型、大小、費用、腳本行為等),節點就會默認接受並轉發。
此處還有一個概念是 “標準交易”,這本身是 Bitcoin Core 軟件中的一個定義:當一筆交易並非本版軟件定義的標準交易時,節點就不會保存和轉發。
與之相對,是共識規則。共識規則是指所有節點對區塊和交易有效性的硬性判定標準,只有違反共識的交易才會被全網拒絕。
轉發策略與共識規則的重要區別在於:一筆交易可以“不標準”但仍然“合法”。也就是說,若某交易不符合默認的標準政策,節點會選擇不轉發、不納入交易池甚至不打包,但一旦它出現在區塊內(由礦工打包),其它節點仍會根據共識規則認定區塊有效。
以 OP_RETURN 輸出舉例,該操作碼自始至終存在,不論其腳本中攜帶的數據體積有多大,都不違反共識規則。只是,在本次爭議發生之前,大部分比特幣節點都採用 80 字節的數據體積限制作為一種交易轉發策略:數據體積小於 80 字節的 OP_RETURN 輸出會被自由轉發,超出的則不轉發。
所以讀者看到這裡應該就可以知道,一些媒體將此次修改稱為“比特幣 OP_RETURN 升級”顯然是不合適的。而筆者也對於一些項目期待基於此次 OP_RETURN 的修改來開發新項目持懷疑態度,因為此前也可以通過各種方法去發送一個攜帶更大體積數據的 OP_RETURN 交易上鍊,並無本質不同。
但在修改生效前,目前 Bitcoin Core 對於標準交易大致有以下規定:
- 標準腳本類型:如 P2PKH / P2SH / P2WPKH / P2WSH / P2TR(Taproot)等等 1、不使用未定義的 opcode 等。
- 簽名腳本大小:每個輸入的 scriptSig 長度不得超過 1,650 byte。
- 交易總大小:不超過 100,000 vByte。
- 輸出金額:輸出的面額有下限,比如 P2PKH 輸出需至少大於 546 sat 2(粉塵限制)、OP_RETURN 的輸出為 0 sat。
- 簽名腳本約束
- 費用費率約束:符合節點設定的最低 fee
- 版本號及對應規則:如 v2、v3。另外,還有 RBF、包中繼等規則。
注 1:通過花費條件,用戶可以構造各種類型的交易形式,上文的 P2FK 就是一個很好的例子。因此標準化對於應用間相互理解其輸出的含義十分有用。
注 2:郎教授可以理直氣壯地說:你給我 (BIP-177 下的) 1 bitcoin,我是不要的,因為有 546 bitcoin 的粉塵限制。
為什麼這些限制很重要,甚至是這次爭論的焦點呢?標準交易的主要作用包括以下幾個方面:
- 防止濫用:限制無效數據、過大交易或垃圾輸出進一步傳播。這樣可以有助於控制 mempool 中的交易格式,降低驗證與存儲壓力,也便於節點有效地防範 DDoS 攻擊。
- 控制鏈上膨脹:主要是控制 UTXO 集大小。因為節點理論上需要一直保存所有的 UTXO,即未來任何時刻都有可能要花費的資金。濫用或無必要地擴大 UTXO 集(例如粉塵攻擊)會嚴重影響節點的性能,進而影響整個網絡的安全性和去中心化。
- 提升效率和預測性:轉發策略不僅限制不符合規則的交易,同時也會有利於符合規則的交易。礦工收到符合標準的交易(如符合費率、清晰的輸出結構、簽名合理)時,更傾向於將其打包進區塊中。這為錢包實現費用估算和 RBF 提供了穩定依據,也讓用戶對交易確認時間更有預期。
- 提升可交互性:通過比特幣的簽名、腳本形式,用戶可以構建出來各種各樣的交易,但如果規定好若干類標準的交易,可以更方便錢包等應用針對這些交易格式進行開發,提升用戶在使用不同應用時的可遷移和可交互性。
近期爭議的時間線
有了前文略顯冗長的介紹後,下面我們可以來梳理近期 OP_RETURN 的爭議了。
| 日期 | 事件 |
|---|---|
| 2025 年 4 月 17 日 | 開發者 Antoine Poinsot 在比特幣開發者郵件列表發帖,提議解除 Bitcoin Core 標準交易規則對交易中 OP_RETURN 輸出數量和大小的限制,並闡述了這樣做的動機。 |
| 2025 年 4 月 28 日 | Peter Todd 提交 PR #32359,實現:1)取消 OP_RETURN 限制;2)移除 -datacarrier 配置參數;等更改。Github 上對該提案展開了激烈討論,不少社區成員發表支持或反對意見。 |
| 2025 年 5 月 2 日 | Greg Sanders(instagibbs)提交 PR #32406,取消 OP_RETURN 輸出數量限制,允許多個 OP_RETURN 輸出共同分享 100,000 vbyte 上限;保留 -datacarrier 參數以允許配置這個數量限制,但將參數標記為棄用。 |
| 2025 年 6 月 6 日 | Bitcoin Core 官方網站刊登題為《Bitcoin Core 開發與交易轉發政策》的聯名信聲明,由 31 位貢獻者簽署。聲明重申了開發團隊對交易中繼政策的看法:默認策略可以出於安全和效率考慮加入 DoS 防護和手續費判斷,但“不應阻止那些有持續經濟需求、且最終會被礦工打包進區塊的交易的中繼”。這被視為開發者對解除 OP_RETURN 限制的原則性說明。 |
| 2025 年 6 月 9 日 | Bitcoin Core 維護者完成對 PR #32406 的合併。開發者 Gloria Zhao 當日在社交媒體上確認了這一變更已進入 Bitcoin Core 主分支代碼。預計相關功能將包含在 10 月份發佈的 Bitcoin Core v30 版本中。 |
正反觀點整理
儘管 PR 32406 已經合併,似乎一切已蓋棺定論,筆者仍希望再次整理正反雙方的觀點。一方面是希望讀者通過文章前半部分的科普介紹來重新審視這些討論及觀點,另一方面是通過這些觀點,我們可能引發更多的思考和洞見。筆者個人的意見則留待下一章。
支持放寬 OP_RETURN 限制的觀點
尊重用戶需求,承認既成現實:支持者指出,轉發策略中的 OP_RETURN 相關限制並不能阻止鏈上存儲行為,因為市場對此已有真實需求且用戶願意付費實現。以 Ordinals 熱潮為例,大量圖片等非金融數據通過見證字段寫入區塊,並未受到任何標準策略限制。據統計,Ordinals 自推出以來總計已產生超過 8800 萬次銘文,支付了逾 7000 BTC 的手續費,說明很多用戶樂意為鏈上存儲買單。與其繼續堅持一條形同虛設的限制,不如順應現實解除它——因為“馬已經跑出柵欄”,就算沒有 OP_RETURN,這些數據依然會以別的方式上鍊。
中立性與抗審查原則:Bitcoin Core 開發者強調,比特幣網絡的抗審查性是首要屬性,節點軟件應保持中立,不因交易內容或用途而區別對待。他們同樣不喜歡垃圾數據或亂用鏈空間的行為,但信奉交易手續費機制是過濾交易的最終手段:只要有人願意為某筆交易付出高於他人的手續費,礦工就有經濟動機打包它。正如早期比特幣開發者 Eric Voskuil 所言:“對抗審查的能力歸根結底來自交易費率”。因此,與其嘗試在轉發層面進行控制,不如讓費用市場發揮作用——只要垃圾交易無法持續補貼高額手續費,它們自會因為無利可圖而逐漸消失。這種觀點認為,節點人為過濾雖然在道德上與內容審查有所區別,但技術效果上相近,同時還很難在有經濟動力的情況與其對抗。
兩害相權取其輕:這類觀點認為,當前不允許攜帶大體積數據的 OP_RETURN 輸出得到自由轉發,導致開發者和用戶轉而使用更“損害”網絡的方式存儲數據,例如上文提到的 P2FK、scriptSig 等造成 UTXO 永久膨脹。既然數據無論如何都會上鍊,那麼讓它們以對節點危害更小的方式存在就是合理的。OP_RETURN 輸出不進入UTXO集合,驗證時也無需執行復雜腳本,比起假輸出佔用資源要友好得多。當區塊空間被填滿時,大量使用 OP_RETURN 反而可能降低節點負擔:由於見證折扣的存在,一個區塊若全是見證數據,實際體積接近 4MB;但如果全是 OP_RETURN 則因沒有折扣,區塊字節上限約 1MB。同時 OP_RETURN 數據可被修剪(pruned)(不進入 UTXO 集合),這對減少全節點運營成本有利。因此,解除 OP_RETURN 轉發限制反而能夠避免更壞的鏈上數據利用方式,優化全網資源佔用。
與礦工行為保持一致,提升網絡效率:BitMEX 的研究指出,如果節點默認不轉發這類實際會被礦工接受的交易,用戶就會被迫求助於礦池的私有通道提交交易。例如 MARA 等礦池提供的接受非標準交易的服務。這樣的後果是:區塊內容和公開交易池漸行漸遠,節點難以及時知道區塊包含的所有交易,進而破壞緻密區塊(Compact Blocks)等加速區塊傳播的機制,導致區塊傳播延遲增加。傳播變慢將提高小礦工出塊後被孤立的概率,從而進一步加劇礦業中心化。相反,如果節點政策與礦工實際行為一致,公開的 P2P 網絡就能容納所有類型的交易,礦工就不需要架設私有渠道,交易也能更高效地廣播和打包。同時,每個節點的交易池更準確地反映待確認交易,全網對下一塊的預期更一致,有助於改進手續費估計和用戶體驗。總而言之,取消 OP_RETURN 限制可以讓比特幣網絡在透明度和效率上更勝一籌,而不是把大筆交易擠到幕後進行。
用戶選擇權與開發過程透明:支持者也回應了“強制所有人接受”這一指責,強調用戶依然擁有充分的選擇權。Bitcoin Core 軟件本身是開源的,任何人都可以複製修改。“Bitcoin Core 只是眾多協議實現之一,它之所以特別,只因為其貢獻者的決策方式”。如果強烈反對,用戶也完全可以用腳投票,繼續運行舊版本,或切換到其他客戶端,比如維持更嚴格策略的 Bitcoin Knots 等。另一方面,Core 開發者認為在整個決策過程中公開透明地討論和溝通了此提案:從郵件列表到 GitHub,再到 6 月的聯合聲明,信息都是公開可審閱的。據此,支持者認為此次修改遵循了比特幣開發一貫的開源協作精神,並無“不經討論強推”之嫌。
反對放寬 OP_RETURN 限制的觀點
濫用鏈上空間,偏離比特幣本旨:許多反對者認為,比特幣區塊鏈寶貴的空間應主要服務於貨幣交易,過度允許非金融數據嵌入將把比特幣變成“數據存儲網絡”,模糊其作為點對點電子現金系統的定位。正如有用戶諷刺的那樣:“這叫比特幣 (Bit‘Coin’),不是比特存 (Bit‘Store’)”。大量圖片、音頻等數據佔據區塊,將擠壓正常金融交易的空間,損害比特幣作為貨幣網絡的價值支撐。而 OP_RETURN 在 v0.9.0 修改為可攜帶數據時也專門提到並不鼓勵在區塊鏈寫入非金融數據。
引發垃圾交易(Spam)和潛在 DoS 風險:解除限制後,攻擊者或投機者可能因為實際門檻降低而發送更多垃圾交易。這不僅會推高正常用戶的手續費(因為需與垃圾數據競爭空間),還可能拖慢節點處理速度,對網絡造成拒絕服務(DoS)攻擊隱患。持此觀點者將開發者認為“垃圾數據終究會被礦工打包”的態度視作一種妥協和失敗主義,認為不應向惡意行為“繳械投降”。在他們看來,更積極的做法是加強節點過濾和社區文化來阻止垃圾數據上鍊。
破壞交易池轉發策略的自治:反對者強調,比特幣的去中心化不僅體現在共識層,節點對自身交易池(mempool)和轉發策略的自主控制也很重要。而取消 OP_RETURN 限制將使用戶失去一項自主選擇:過去節點可以通過
-datacarrier等參數設置拒收超出特定大小的交易,但新版本中該選項將被移除或失效。這意味著所有運行新版 Core 的節點都被強制接受並轉發含有大數據負載的交易,不再允許個人依據偏好過濾。這一改變引發對“節點策略單一化”的擔憂和質疑:Core 開發團隊是否在以軟件更新之名行改變網絡用途之實?知名開發者 Luke Dashjr 等公開呼籲用戶拒絕升級或轉用能夠堅持原有過濾策略的節點實現(如他維護的 Bitcoin Knots 軟件)。決策過程與價值觀爭議:除了技術顧慮,許多反對者對這一更改的決策流程表達了異議。在 GitHub 相應 PR 下,有大量用戶給出了大量的 👎 emoji。儘管 Core 團隊聲明流程是公開透明的,但很多人仍然認為開發者是在共識尚未充分達成、社區存在明顯分歧的情況下貿然合併代碼,有違“慎重避免爭議”的原則。一些評論直言:這種做法做開了很壞的先例。還有人質疑這一改動背後的動機,認為是部分開發者受到一些“比特幣生態”項目的影響,例如 Citrea 等。
個人觀點
從上面的討論,許多媒體都有不同的進一步解讀,例如比特幣是不是去中心化、是不是抗審查等。但筆者認為,只要對比特幣原理有進一步瞭解,(至少從目前的狀態來看)就不會太擔心,進而像對其他密碼貨幣一樣來糾結於是否去中心化。這次的爭論在一定程度上也是證偽了這些擔憂。
回顧整個事件,我很同意 Olaoluwa 的說法,這很像一次非受迫性失誤:沒人主動要求來變更;有的話也是開發者基於還沒部署的某個東西來做了一次搶先動作,而且近期也沒有太多非標準交易需求。但現在倒好了,開發者陷入到了進退兩難的境地。
抗審查 vs 垃圾交易
支持放寬限制的一個很重要觀點是,我們不應該對比特幣上有什麼交易做限制,讓市場來決定,否則就會造成事實上的交易審查。
筆者對此說法同意其中一部分。比特幣一個很優秀的經濟特性,不僅在於宏觀上的穩定(2100 萬發行上限),還在於微觀層面上交易手續費政策的統一(總是以交易體積大小來計算)。而反觀以太坊,不僅經濟體總量會變化(PoS、EIP-1559 修改整個經濟模型),手續費政策也會經常變化(Dencun 升級降低寫入數據操作的成本)。所以如果“看不見的手”能起作用,就不要讓“看得見的手”來攙和,因為它經常會變成“管不住的手”。
OP_RETURN 這次也沒有修改手續費政策,但修改的過程更多是通過“寫代碼的手”而不是通過“寫帖子的手”來推動的。
但審查交易的說法在筆者看來則站不住腳,核心區別是在於對內容還是對形式、對他人還是對自己。
比較典型的審查交易行為是,節點得知了發交易人的身份(攻擊者、洗錢團隊等)或資金來源(不符合一些法律規定),而不讓其發佈上鍊。也就是獲知了交易的內容、“語義”後,對他人主動造成影響。
而節點策略對 OP_RETURN 的限制,則是出於形式上的規範,只轉發上文提到的符合規範的標準交易,防止對網絡的濫用。一個比較典型的反例是區塊戰爭時期,Bitcoin 網絡曾遭受了嚴重的粉塵攻擊。如果你極端秉承“只要有人願意付費就行”的觀念,粉塵攻擊是不是也可以不算一種攻擊而是合理使用了?
另一方面,節點策略也更多是對自己的節點進行處理,比如過濾掉自己不關心的交易,來降低網絡和存儲壓力。
節點自治 vs 網絡效率
另一個爭論的焦點則是,是否應該更多支持節點自定義轉發與交易池策略,還是最好能一致以便提升網絡效率(礦工激勵相容、區塊傳播更快、費率更可預測)。
從效率上來說,更快的區塊傳播效率在技術上是令人信服的。儘管沒有統一的交易池,但如果節點間的交易池內容更一致,則節點自身就會保留更多未來會上鍊的交易,在緻密區塊(compact block)的機制下就會降低網絡開銷,讓區塊同步更快。同時,對於費率的預估也會更準確,這對於一些費率敏感的交易(如閃電網絡上預籤的交易)更加關鍵。
但問題是在於目前 OP_RETURN 類的交易是否很多,多到已經顯著影響到了緻密區塊傳播或費率預估?或者說迫切到需要用寫代碼的這種“看得見的手”來推動,而不是發帖呼籲大家修改默認配置?
這裡筆者也不想進一步上綱上線地擴展到節點多樣性對於網絡的重要性。僅作為一個節點運行者,PR #32406 就對筆者來說更可接受一些,起碼暫時保留了節點自主配置的選項。
節點實現 vs 網絡公共政策
正如前文所述,我們不能將這次修改稱為“比特幣的 OP_RETURN 升級”,這只是 Bitcoin Core 自身的策略的一次修改,其它一些客戶端實現並未跟進同樣的策略變更。但為什麼會引起如此大範圍內的爭論?恐怕一個原因仍然在於 Bitcoin Core 是目前最廣泛使用的客戶端,是事實標準。
一個可能不甚恰當的例子是美元,它既是美國國內的貨幣,也是事實上的國際通用貨幣。美國可以通過美元來對全球施加影響力,但在制定貨幣政策時,也自然需要考慮國內經濟狀況。
Bitcoin Core 在“事實標準”這個層面也有類似的矛盾情況:
一方面,Bitcoin Core 受制於此類定位,自身的策略(交易池管理、交易轉發)等都無法只考慮節點本身,而需要兼顧到整個網絡的情況。新的策略可能就會引起足夠大的影響,例如 v3 的交易轉發等。而這些策略也會很大程度上影響到其他的應用開發,例如閃電網絡等等。
另一方面,這種事實標準也有能力裹挾網絡協議。例如,Bitcoin Core 會按照規則來公開此前版本的漏洞。因此雖然用戶在理論上可以運行很久之前的客戶端,但這些安全漏洞會迫使用戶升級到新版本,接受的新功能,尤其在配置選項也被移除的情況下。
從這次的事件來看,Bitcoin Core 未來仍會在這兩種角色間進行平衡。而運行節點的用戶並不如一些開發者所想的,能那麼容易地用腳投票:指望每個運行節點的人都能修改代碼並不現實,而換用其他客戶端也要考慮到其他客戶端的開發和測試資源可能較少,並不足夠健壯和安全。那麼,留給異見用戶的選擇就比較尷尬。
這個問題目前看仍懸而未決。
(完)




