ビットコインやライトニング上のプロダクト開発は難しすぎる？

加藤規新 • 2023年08月04日

もうずっとWeb3やクリプトと呼ばれる業界がビットコインより盛り上がっています。数十倍、下手すると数百倍のエンジニアがWeb3系のプロダクト開発に携わっているところを見ると、ビットコインやライトニングをフル活用したプロダクトの開発は難しすぎるのでしょうか？

ちょうど先月末、PaypalやDiem (Libra)のトップを経てライトニングインフラ企業Lightsparkを立ち上げたという経歴を持つDavid Marcus氏が、ビットコインとライトニングを活用したプロダクトを設計する上で直面した困難についてスレッドをつぶやいていました。

I’ve decided to talk more about our inner workings at @Lightspark to share more of the journey with the community of builders out there. In that spirit, this week, we spent time challenging ourselves quite hard on our choice to build on Lightning. Here’s what happened 🧵 1/12
— David Marcus (@davidmarcus) July 29, 2023

もちろん、Web3とビットコインの根本的な違いにイージーマネーによる前者の金回りの良さがありますし、個人的にはその影響が一番大きいのではないかと考えています。とりあえず今回はその違いは無視して、技術的にビットコインやライトニング上でのプロダクト開発がどのように難しいか、そしてどのような対策が進んでいくか考えてみましょう。

・オンチェーン利用の制約が非常に厳しい

・ノード/サーバー管理など多様なスキルが必要

・Developer Experienceを改善する試みはある

オンチェーン利用の制約が非常に厳しい

スマートコントラクトが書きたい→ビットコインは除外、というふうに門前払いされる場合が多い原因です。確かにビットコインでスマートコントラクトを用いた開発はかなりチャレンジングになってしまいます。

ビットコインのオンチェーントランザクションに課すことができる制約が非常に限られていることは有名な話で、スマートコントラクトチェーンという概念の存在自体がビットコインの制約に対するアンチテーゼのようなところがあります。例えばビットコイン上でトラストレスな取引をオンチェーンで完結させるにはアトミックスワップのような工夫が必要になります。スクリプトのコードも逆ポーランド記法という馴染みの薄い書き方をします。

また、この制約はそのままレイヤー２の設計にも関わってきます。ライトニングはオフチェーンのプロトコルではありますが、「単独で資金をオンチェーンに戻して動かすことができる」というレイヤー２の定義を採用すると必然的にオンチェーンで表現できる範囲のことに限られることがわかります。オフチェーンでなら自由にスマートコントラクトを扱えるわけでもないのです。

ただし、クライアントサイドバリデーションと呼ばれる、ビットコインでは検証されないがユーザー同士が合意した独自ルールを勝手に検証するという仕組みでこの制約を迂回することはできます。例えばRGB, Taro/Taproot Assets, Ordinal Inscriptionsはこのように実現しています。

ビットコインのコンセンサスコードに新しい機能が追加される間隔は長いため、自分のアプリケーションに必要な機能の導入に数年かかる、あるいは待てど暮らせど導入されないということもあるでしょう。現在だと流行りのコベナンツ系のアプリケーションを検討している人たちがこれから直面する問題です。

ノード・サーバー管理など多様なスキルが必要

こちらの方が大きな技術的負担となっているケースが多いと感じます。

基本的には「ブロックチェーン(他人のノード)が勝手に実行してくれる」スマートコントラクトとは異なり、ビットコインやライトニングを使ったアプリケーションやプロダクトにはサーバーサイド開発の知識が必要になります。また、ユーザーがセルフホストできるようにする、コードはオープンソースにするなどの配慮を求められることが多いという特徴があります。

また、ビットコインノードは非常に安定しているため比較的簡単ですが、ライトニングノードはホットウォレットであるためセキュリティ対策の知識が必要なほか、流動性のマネジメントや定期的なバージョンアップ、場合によってはTorの併用などニッチな知識が必要です。

もしビットコイントランザクションやライトニングの詳細な挙動に関わるプロダクトを開発するのであれば実はビットコインノードについての知識もかなり求められます。なぜならソフトウェアのある程度細かい挙動を理解していないと落とし穴にはまることがあるためです。例えばメモリプールの仕様や設定によって本来必要な未承認トランザクションが手元になくなった場合にアプリケーションがどう動作するかなど、コンセンサスルールとは関係ない部分でもバグが入り込む余地が大いにあります。

難解だからといってノードの運用を諦めたりカストディアルな業者を利用するとせっかくビットコインを使って得られる無類のトラストレス性や検閲耐性が毀損してしまいやすいなど、妥協することもビットコインを使うプロダクトにとって本末転倒にならないか考えものです。(もちろん、それでも問題ないようなプロダクトも多数あるでしょう。)

セキュリティ面での懸念もノードだけの話ではありません。「いやいや、自分のサービスはライトニングの仔細に立ち入らず、単純にカストディアルサービスの入出金に使うだけ」という場合でもアプリケーションロジックのバグなどによる誤出金や不正出金を防ぐ仕組みを充実させないと心許ないです。例えば最近はStacker Newsがバグで0.2 BTCを不正出金されていました。

ここまで書くと確かになかなか厄介に感じますね。

Developer Experienceを改善する試みはある

さて、ビットコイン・ライトニングに深煎りしていくと非常にとっつきにくい感じが出てきました。オンチェーンのスマートコントラクト機能が突然充実することはないと思われますが、特にライトニング関連でDeveloper Experienceを改善するプロダクトは色々出てきています。

例えば冒頭でスレッドを紹介したDavid Marcus氏のLightsparkは法人向けのライトニングノード管理ソリューションやアプリケーション開発・ウォレット開発に利用できるソフトウェアライブラリを提供しています。

またツイッター創業者のJack DorseyがBlock (旧Square)を通してBDK・LDKという２つのライブラリを送り出しています。Bitcoin Dev Kitはウォレットやアプリケーションを作成するときにビットコインプロトコルの必要な部分だけを導入するのに便利です。Lightning Dev Kitも同様にウェブアプリケーションやネイティブアプリにライトニング関連の機能を導入するのに使われており、最近紹介したPWAであるMutiny Walletも利用しています。他にもLNDなどのライトニングノードに他の実装にしかない機能を追加するのに使っている場合もあります(LNDK)。

ただし、これらのライブラリは細心の注意を払って一から実装するコードを減らせるという大きなメリットがありますが、ノード自体について深い知識がないとライブラリの組み合わせ方がわからないという面では開発者を選びます。

Blockstream Greenlightはライトニングノードの秘密鍵以外の部分をBlockstream社が提供するクラウドサーバーで動かし、鍵だけはユーザー(事業者含む)の手元で管理して必要なときのみ署名を行うというコンセプトのサービスです。結構前からフォローしていますが、クローズドβテストが開始するなど正式リリースが近づいてきています。

ほかにも多数の開発者向けAPIやSDK (e.g. Breez SDK)、ノード管理サービス(e.g. Voltage)が充実してきており、現状のマーケットサイズに対してはやや飽和状態と言わざるを得ませんが、ライトニングを使っている開発者も「難度が高い」ことを問題視しているからこそでしょう。

ビットコインやライトニングの根底にある分散性へのこだわりとそのために存在するやや直感的でない仕様について全く理解しないままアプリケーションを開発することはトラブルを生むので考慮する必要はないと思いますが、開発者向けツールや事業者向けサービスが充実していくことで一般的なフルスタックエンジニアが扱えるレベルになればもう少しマスアダプションが近づくかもしれません。

加藤規新

1994年生まれ、シカゴ大学でGISやコンピューターサイエンスを学び学士号取得。2016年末よりビットコインに関するリサーチや実験的な開発をしており、今までにいくつかのブログやサロンで解説を担当。ビットコインについて一番好きなところはパーミッションレスに誰でも使うことができること。 2024年11月より日本ビットコイン産業株式会社取締役。