I. 隱藏的操作碼：中本聰原始代碼中的 OP_RETURN（2009 年）

在中本聰的第一個比特幣版本 v0.1.5 中，script.h 文件定義了完整的操作碼表。在算術運算子、堆疊操作和密碼學原語之中，存在著操作碼 0x6a——OP_RETURN。它在 script.cpp 中的實作極為簡單：

case OP_RETURN:
    pc = pend;
    break;

它只做了一件事：將程序計數器推進到腳本末尾，立即中斷執行。這使它實際上成為一個 return-false 指令——任何腳本在解鎖或鎖定腳本中遇到 OP_RETURN 都會停止評估，從而使該輸出在設計上就不可花費。

中本聰將 OP_RETURN 作為標準比特幣腳本操作碼集的一部分包含進來，但在將近六年的時間裡，它在主網上實際上處於休眠狀態。比特幣網路將任何包含裸 OP_RETURN 輸出的交易視為非標準——節點不會轉發，礦工也不被鼓勵挖礦此類交易。

原因是架構性的：比特幣的 IsStandard() 共識函數只接受符合特定模板的交易輸出——支付到公鑰、支付到公鑰哈希、支付到腳本哈希以及多重簽名。裸 OP_RETURN 不匹配這些模板中的任何一個，因此在網路的交易轉發層中被靜默丟棄。它在共識層面上技術上有效，但在功能上不可見。

II. 辯論：為何啟用 OP_RETURN？（2011–2013 年）

到 2011 年，開發者和使用者開始嘗試透過巧妙但有爭議的方法將數據嵌入比特幣區塊鏈。由於比特幣沒有原生元數據欄位，使用者將訊息編碼到：

• Coinbase 交易——每個區塊的第一筆交易（用於 The Times 03/Jan/2009 創世訊息及後續區塊題詞）
• 多重簽名輸出——濫用 M-of-N 腳本編碼任意字節
• 支付到公鑰輸出——在公鑰欄位中嵌入數據

這些方法都不是為數據儲存設計的，每一種都對網路造成了成本：它們用不可花費的輸出膨脹了 UTXO 集，每個全節點必須永遠追蹤這些輸出，即使它們代表的是數據而非可花費的幣。比特幣開發者社群認識到這是一個日益嚴重的問題。

2013 年 6 月，Bitcoin Core 開發者 Jeff Garzik 提交了 PR #2738，提議添加 TX_NULL_DATA 作為一種新的標準交易類型，允許花費到 OP_RETURN。關鍵的設計取捨：

• ✅ OP_RETURN 輸出被設計為不可花費——節點可以立即從 UTXO 集中將其剪除，不像隱藏在公鑰或多重簽名輸出中的數據
• ✅ 標準化——升級到 v0.9.0 的礦工將轉發和挖掘 OP_RETURN 交易
• ❌ 有限的數據容量——每個 OP_RETURN 輸出可以在操作碼之外攜帶數據，但整個交易將受到標準轉發限制

該 PR 在審查中擱置了四個多月。比特幣社群辯論是否應該標準化任何形式的區塊鏈數據儲存——一些人認為比特幣應該保持純貨幣，另一些人則視時間戳為合法用例。最終，實用主義的論點勝出：提供一個乾淨、標準化的數據輸出，總比驅使用戶使用污染 UTXO 的駭客技巧要好。

「將 OP_RETURN 數據輸出作為標準交易類型，為使用者提供了一個乾淨的方式將少量數據添加到區塊鏈，而不是使用更具破壞性的輸出類型。」— Jeff Garzik，Bitcoin Core PR #2738

PR #2738 於 2013 年 10 月 22 日合併，並隨 Bitcoin Core v0.9.0 於 2014 年 3 月 18 日發布。

III. 過渡期：OP_RETURN 正式上線（2013–2014 年）

有趣的是，第一個 OP_RETURN 輸出出現在 v0.9.0 正式發布之前。在 區塊 283,771（2014 年 2 月 2 日挖掘）中，礦工包含了帶有 OP_RETURN 輸出的交易——按轉發規則屬於非標準，但在共識層面上技術有效。選擇挖掘這些交易（或在自家記憶體池中發現它們）的礦工可以將其包含在區塊中，網路的其他部分會將該區塊視為有效。

存在證明（Proof of Existence），由開發者 Manuel Araoz 創建，於 2013 年 11 月上線，是第一個使用區塊鏈時間戳的主要服務。其概念優雅：對文件進行哈希，將哈希值（或多個文件的 Merkle 樹根承諾）嵌入 OP_RETURN 輸出，讓比特幣區塊鏈作為文件在特定時間點之前就已存在的永久證明。

Araoz 在 v0.9.0 可用之前數月就推出了該服務，依賴於願意包含非標準交易的礦工。這種早期採用展示了對區塊鏈時間戳的巨大需求，並幫助說明了 OP_RETURN 標準化的必要性。

IV. 大小限制的演變：520 → 40 → 80 字節

Bitcoin Core v0.9.0 發布時對 OP_RETURN 數據沒有明確的字節限制。唯一的實際約束是比特幣腳本的一般規則：任何單個腳本元素最多 520 字節——但這是共識層面的限制，而非轉發層面的策略。

v0.10.0 版本（2015 年 2 月）引入了 -datacarrier 和 -datacarriersize 配置選項，將預設最大 OP_RETURN 大小設為 40 字節。根據 v0.10.0 的更新日誌，這個保守的限制是作為安全起點，同時網路觀察 OP_RETURN 使用模式。

九個月後，Bitcoin Core v0.11.0（2015 年 7 月）中，Flavien 的 PR #5286 將預設值從 40 字節改回 80 字節。PR 的描述揭示了原因：

「OP_RETURN 的最大字節數原本是 80，後來為了安全改為 40。九個月過去了，沒有發生任何災難性事件。」

80 字節的限制是為了容納兩個 SHA-256 哈希輸出（各 32 字節 = 64 字節）加上 OP_RETURN 操作碼和數據推送的開銷。這個設計直接促成了 OpenTimestamps——Peter Todd 的將 Merkle 樹根（32 字節）提交到區塊鏈的時間戳協議。

V. 應用生態系統：從時間戳到 NFT

存在證明（2013）

第一個實用區塊鏈時間戳服務。使用者對文件進行哈希，將哈希值發送給服務，收到一筆在比特幣區塊鏈上嵌入承諾的交易。到 2026 年 6 月，存在證明已在科學研究、法律合約和創意作品中加蓋了數百萬份文件的時間戳。

Counterparty（2014）與 Rare Pepes（2016–2017）

Counterparty 於 2014 年 1 月推出，在比特幣區塊鏈之上建立了一個點對點金融平台，使用 OP_RETURN 嵌入資產元數據、代幣轉移和訂單簿數據。雖然 Counterparty 最初使用了不同的編碼機制，但後來在其許多操作中採用了 OP_RETURN。

Rare Pepes NFT 系列——第一個重要的區塊鏈收藏卡系列——於 2016 年左右在 Counterparty 上推出。每張 Rare Pepe 卡的元數據和所有權記錄都透過 Counterparty 基於 OP_RETURN 的協議嵌入比特幣交易中。在其高峰期，單張 Rare Pepe 卡的售價達數十萬美元，證明 OP_RETURN 元數據可以在以太坊的 ERC-721 標準誕生前多年就支援一個活躍的數位收藏品市場。

OpenTimestamps（2015–2016 年）

由 Bitcoin Core 開發者 Peter Todd 創建，OpenTimestamps 使用 OP_RETURN 將聚合的 Merkle 樹根提交到比特幣區塊鏈。該協議透過收集多位使用者的時間戳請求，構建 Merkle 樹，並將 32 字節的 Merkle 根嵌入單個 OP_RETURN 輸出中。任何個人時間戳都可以稍後透過包含證明與鏈上根進行驗證。

VeriBlock（2018–2019 年）：垃圾交易時期

並非所有的 OP_RETURN 使用都是有益的。2018–2019 年，VeriBlock 專案向比特幣區塊鏈發送了大量 OP_RETURN 輸出，用於其「工作量證明之證明」挖礦方案，高峰期每個輸出消耗 80 字節，每天數千筆交易。這個時期展示了 OP_RETURN 對垃圾交易的脆弱性，並引發了關於數據上限和轉發政策的新一輪討論。

VI. 考古意義：OP_RETURN 輸出作為鏈上文物

對於老幣考古學家而言，OP_RETURN 輸出代表著一類獨特的鏈上文物。與 UTXO 不同——它們可以被花費、移動或丟失——OP_RETURN 輸出是永久凍結的。在區塊 283,771（2014 年 2 月）中創建的 OP_RETURN 輸出將永遠以完全相同的形式存在，其數據字節作為不可篡改的時間戳證據保存。

OP_RETURN 操作碼從一個禁用的腳本指令到全球時間戳基礎設施的旅程，反映了比特幣本身的演變——從專注於點對點電子現金，到成為一個更廣泛的無信任時間戳、資產發行和數位來源證明平台。區塊鏈上的每一個 OP_RETURN 輸出都是一個微小的時間膠囊：一個無法被更改、無法被花費、無法被抹去的密碼學承諾。在老幣考古的世界裡，這些凍結的數據字節是存在於區塊鏈上最耐久的文物之一。

——加密典藏局 · coinage-history.com