今年も1年を振り返る時期になってまいりました。私は久しぶりの海外旅行やカンファレンス登壇などで充実させた一年でした。皆さんの2023年はどうでしたか?

先週、読者様から以下のようなリクエストが寄せられていました。

Bitcoin Optech Newsletterの2023年まとめ(https://bitcoinops.org/ja/newsletters/2023/12/20
)を読みましたが、ソフトフォーク提案が様々あり、どのOPコードがメインで議論されているかなど、開発の方向性がよく理解出てきていません。
今年の開発の総括や、来年以降の展望などこちらでもおまとめいただけると大変ありがたいです。

ちょうど年の瀬で振り返りに最適な時期でもあるので、今日は今年のビットコイン開発をまとめ、そのうちいくつかのトピックについて来年の予想をしていこうと思います。他にもご質問やご要望などあれば歓迎致しますので、どしどし教えていただければ幸いです!

・たくさんの新型L2が乱立、ソフトフォーク議論が再燃

・粗雑なプロトコルも複数登場、議論の的に

・ライトニングはLSPの時代へ本格突入

たくさんの新型L2が乱立、ソフトフォーク議論が再燃

この1年のビットコイン開発で一番印象的だったのはこれまでライトニングネットワーク以外のレイヤー2プロトコルの開発はごく一部のマニアックな開発者を中心としたニッチな話題だったのが、新しいタイプのレイヤー2の発明や歴史あるコンセプトの再燃などによって一転して脚光を浴びるようになったことです。

特にコベナンツ機能の導入に関しては2022年にJeremy Rubin氏がOP_CTVの導入を強く要望してコミュニティから反発を受けたときと比べると、Arkという新型レイヤー2の発明などによって有用性が再評価されてきています。以下、ソフトフォークの必要性に着目したレイヤー2技術のまとめです。

ソフトフォークが不要なレイヤー2

MercuryLayerはステートチェーンと呼ばれる、主にRuben Somsen氏が以前より提案・応用しているコンセプトを実装したレイヤー2で、広くアダプションしているというよりは実証実験のような状態というのが現状を一番表しているかもしれません。それでも今年は知名度的にある程度伸びた印象があります。

MercuryLayerについて書いた記事は↓

Statechainsを実装したMercury Layerはどのようなレイヤー2なのか?
BRC-20トークンブームの再来によりビットコインの送金手数料が再び高騰している今月、ライトニングネットワークでは送金トラブルなどによるチャネルの強制閉鎖によって大きな出費を強いられるノード運用者が目立ちました。 背景としては送金手数料の高騰以外にもライトニングウォレットのZeusがHodl Invoiceというテクニックを使ったオフライン受け取りを実装したところ、Mutinyというブラウザウォレットとの相性が悪く強制閉鎖を招きやすかったという事情があります。また、Phoenixなど必要に応じてオンチェーントランザクションでライトニングチャネルの容量を拡張するウォレットは当然手数料高騰のあおりを受けてしまいます。いずれにせよ、手数料高騰時の強制閉鎖は金額的なインパクトも大きく、話題になりやすいものです。 Just one FC. 250k+ sats for one sweeped expired HTLC. One of seven. There are no words. I’m thinking. pic.twitter.com/EUqABPV3k0 — SunnySar

また、もちろんライトニングネットワークもソフトフォークが不要なレイヤー2の代表例です。しかし、後述するソフトフォーク提案が実装されればスケーラビリティ面、セキュリティ面などでメリットを享受できる可能性も指摘されています。

元々あったソフトフォーク提案

OP_CTV (BIP119)

コベナンツとは「送金権限にとどまらず、送金内容にも条件を課す」ビットコインスクリプトのことを言います。従来のマルチシグなどを使ったスクリプトは送金を行う権限は既定できますが、その権限で実行できる内容を制限することはできません。コベナンツの導入によって送金内容に条件分岐を作ることができるとビットコインスクリプトのプログラマビリティが大幅に改善し、スマートコントラクトとして表現できる内容の幅が大きく広がります。(実装方法によってDLCやライトニングチャネルなどにもメリットがあると考えられます)

OP_CTV (CheckTemplateVerify)はコベナンツを実装するオペコードの代表例で、OP_CTVでロックされたコインは送金時にそのトランザクションの出力値が予め規定した条件と合致するかを照らし合わせます。事前にこのテンプレートを用意しておけばいろんな条件を表現できるという汎用性を保ちつつ、機能自体は非常にシンプルで好ましくない副作用が発生する可能性を抑えています。

発案者のJeremy Rubin氏がOP_CTVの導入について少し強引に支持を集めようとしていた時期の記事で詳細をご確認ください。結局彼はコミュニティからの反発に遭い、ビットコイン開発から距離を取ってしまいました↓

OP_CTVとソフトフォーク導入方法
先週は寄稿をお休みさせていただいたので前回から間隔が空いてしまいましたが、その間にビットコインの世界は一大論争が巻き起こっています。本稿でも何度か登場している独創的なビットコイン開発者、Jeremy Rubin氏が自身の提案するOP_CTVという機能のソフトフォークによる導入をSpeedy Trial方式で目指すと発表したのです。 ところが同じくSpeedy Trial方式で導入されたTaprootと異なり、まだユーザーやビットコイン開発者の中でOP_CTVに対して広く支持が得られていないこと、Speedy Trial自体がソフトフォークの導入方法として好ましくないことが意見の対立につながっています。 今日はOP_CTVの概要と論争となっているポイントを整理し、個人的な意見も交えながら現在の論争がビットコインの将来にどのような影響を与えうるかを考察します。 TAPROOT導入時のおさらい Taprootの導入にあたって、2017年にユーザーの大半が支持したSegwitの導入にマイナーが抵抗したことを踏まえ、導入に際してマイナーに依存しないソフトフォークのアクティベーション方法

OP_Vault, OP_CAT

個人的にはコベナンツ関連のソフトフォーク提案で最有力なのはCTVだと思っているので、コベナンツの実現を目的としたその他のソフトフォークは1つのエントリにまとめました。

OP_Vaultはその名の通りユーザーが自身のコインを守るために「一定期間内は送金してもセキュリティのより高いアドレス宛の送金に変更可能」なコントラクトであるVaultsを実現することを主眼においたコベナンツ提案です。応用次第でDLCなどにも活用できるようです。Vaultsについてはこちらの記事(Facebook)を昔書きました。

OP_CATは実は2010年に削除されたオペコードですが、これを復活させてあるテクニックを使うとスクリプト内でトランザクションハッシュを確認できる、つまりCTVと同様の機能が実現できます。ただしそのテクニックの実行には次のSighash_Anyprevoutも必要となるため、2つの提案を実装しないと実現しないという不利な立ち位置です。

Sighash_Noinput/Anyprevout (APO) (BIP118)

ビットコインではトランザクションに署名する際に、「どの範囲に署名するか」をSighashフラグというもので決めます。Sighashフラグについては以下の記事で詳しく説明しました:

PSBTを利用したOrdinal Inscriptionsのダッチオークション
オークションって面白いですよね。アート、中古車、不用品、鮮魚、公共事業など様々なものがオークションで値付けされています。ゲーム理論を勉強するのにうってつけの題材でもあります。 自分はこの興味からライトニングのいわゆるHodl Invoiceを利用したオークションサイトを作ったりしました。(今はたぶん改修しないと使えません) さて、オークションといえばアートと連想する方も少なくないように、NFTなどの世界でも日常的にオークションが開催されていて、最近ではBitcoin上のOrdinal Inscriptionもオークションで売買されていたりします。その中で面白いと思ったのはPSBTを使ったダッチオークションです。詳細を見ていきましょう。 PSBTとは PSBTとはPartially Signed Bitcoin Transaction (部分的に署名されたビットコイントランザクション)の略で、複数のウォレットが1つのトランザクションに署名する際に署名途中のトランザクションデータをやり取りするための規格のことです(BIP-174)。シンプルな利用例の1つにマルチシグからの送金があ

Anyprevout (Noinput)というSighashフラグは使用するUTXO自体を署名対象に含めないことによって、同一内容のスクリプトでロックされる任意のUTXOに対してその署名が有効となるSighashフラグです。逆に言えばトランザクションの内容に応じて予め署名を生成できるということで、広義のコベナンツに含められることがあります。Rusty Russelのブログ記事(英語)が簡潔に説明してくれています。

APOはEltooと呼ばれるライトニングチャネルの簡略化にも使えるため、最近まで次の機能追加として最有力視されていたような印象がありましたが、近頃は人気がOP_CTVに押されている気がします。

ちなみに新しいレイヤー2提案が増えることでポジトーク的にライトニング優遇に対する不満も出てくるため、「ライトニングが便利になるから」という理由で導入を推し進めるのは難しくなっていくかもしれません。

Drivechains (BIP300, 301)

こちらも一時期物議を醸しましたが、提案からかなり時間が経っている入出金可能なサイドチェーンを実現するプロトコルです。コミュニティに対して敵対的なマーケティングやビットコインユーザーに響きにくいユースケース(草チェーン作り放題)などの特徴から正直なところ、現時点では実現する見通しはないのではないかと感じています。

新しく提案されたL2と、それらに関連するソフトフォーク提案

Ark

今年圧倒的に話題をさらっていったのは春に発表されたニュータイプのレイヤー2「Ark」です。残念ながらまだ解説記事を出せていないのですが(私自身が納得する記事が書けるレベルの理解度に達していないため)、おおまかに言うとArkと呼ばれるサービスプロバイダーのユーザーが協力的にCoinjoinのようなトランザクションのやり取りをオフチェーンで行い、オンチェーンにはそれらにまとめてコミットするトランザクションが短い間隔で提出されるというものです。ユーザーはArkサービスプロバイダーの同意なしでもオンチェーントランザクションによって出金できるため、レイヤー2というカテゴリに含まれます。

内容が斬新で分析が難しいという問題がありましたが、タイムロックの都合上Arkサービスプロバイダーが非常に大きな金額をホットウォレットとして運用しなければならないこと、1つのArkが必要とするブロックスペースがかなり大きいこと、受け取る側からすると決済までの時間が長いことなどが指摘されていますが、それらの条件さえ飲めば理論上無制限にスケーリングできると主張されてもいます。

設計的にはユーザー同士の頻繁な通信が可能でさえあれば特にソフトフォークの必要なく実装できるようですが、コベナンツ系のいずれかの機能追加がなされればユーザーは送金時など限られたタイミングのみオンラインになれば十分になるということです。2024年はArkがもう少し具体化して議論が進んでいくことに期待しています。

粗雑なプロトコルも複数登場、議論の的に

さて、ビットコインのスケーリングや機能追加を目的としたレイヤー2は一般的には効率性を重視して設計されるものですが、効率性をあえて度外視する粗雑なプロトコルも話題になった1年でした。本稿で何度もカバーしているOrdinals InscriptionsやBRC-20、特段取り上げてはいませんがStampsなどビットコイン・ブロックチェーンに任意のデータを書き込む方法が盛り上がり、NFTブームや草コイン投機に乗っかって一定のプロダクトマーケットフィットを実現してしまいました。

ブロックチェーンへのデータの様々な埋め込み方については最近記事にしています↓

Bitcoinホワイトペーパーをブロックチェーンから抽出する
先週はLuke Dash Jr氏が運営する新興マイニングプールがOrdinals Inscriptionsを検閲していることが話題になっていましたが、今週も引き続きLuke Dash Jr氏がビットコインをデータ置き場に使うユースケースに対する反発を行動に移しており、Bitcoin Coreのトランザクションリレーポリシー (ノードが隣のノードから受け取ったトランザクションを他のノードに転送する際の条件) のうちトランザクションに関係ないデータ量を判定するコードがInscriptionsのデータサイズを見落としているのはバグだと指摘し、修正案を提出するなどしています。 先週の記事↓ マイニングプールによる検閲の影響力をおさらいするここ最近マイニングプールによる検閲が熱いトピックとなっています。9-10月にかけて業界3番手のマイニングプールであるF2PoolがOFAC規制に基づき制裁対象となっているアドレスからのトランザクションを意図的に含めていなかったことをリサーチャーの0xB10C氏が検知し公表しました。 Bitcoin’s Anti-Censorship Ethos Surfa

もし相場の盛り上がりが来年も続くようであれば、いくらナンセンスな設計だとしてもこれらのプロトコルは引き続き手数料の高騰を招き続けると予想しています。ただ、それがライトニング等のレイヤー2の開発や普及にとっては追い風になるでしょう。(仮に市場が盛り下がった場合は、これらのプロトコルの利用が急速に萎むことも予想されます。)

ライトニングはLSPの時代へ本格突入

ライトニングネットワーク関連の開発動向については比較的地味な1年だったかもしれません。目玉機能の追加や革新的なユースケースの登場というよりはライトニングウォレットの安定性やUXの改善といった裏方のアップデートが多かった印象があります。

それ以外だとオフライン支払いの受け付け方、セキュリティの改善、Taprootチャネルの簡易的な採用などについて技術的な議論や進捗がありました。また、バイナンスのライトニング入出金対応など、少しずつ取引所への導入も進んでいます。

特に個人的にはLSP-SpecというLSP (ライトニングサービスプロバイダー)のAPI共通化の話が気になりました。最近のモバイルLNウォレットの主流はLSPと呼ばれる主体にチャネルを開いてもらい、流動性の管理などを任せる方式ですが、このバックエンドを共通規格に乗せることでユーザーがLSPを選べるようにするのがLSP-Specの目標です。ユーザーがお気に入りのフロントエンド(ウォレットUI)をお気に入りのLSPと組み合わせられるようになれば競争が発生し、規制の影響も限定できる(あるいはコンプライアンスを売りにできる)と期待されています。

2024年に期待しているのは時間がかかっていたBOLT12対応の完了と、手数料高騰に直面することによってコスト削減を実現する新しい方法の登場などです。相場が盛り上がることでライトニングもユーザーが増えてくることが予想されるので、ネットワーク全体が大きく成長できる年になるでしょう。

とりとめのない長文になってしまいましたが、今年はこんなところで納めさせていただこうと思います。また来年も宜しくお願い致します。