※本記事は、Bitcoin Tokyoによって公開されたYouTube動画 進化するビットコイン - 長期視点で事業を構築できる堅牢かつ安全な基盤 の文字起こし＆編集版です。
スピーカー
- Tadge Dryja氏（Lightning Network/DLC/Utreexo）
- 安土 茂亨氏（株式会社Chaintope CTO）
- 小川 裕也氏（株式会社Diamond Hands CTO）
モデレーター
- 宮本 丈氏（株式会社bitFlyer）
1. このセッションのスタンス
「技術者が何を考えているのか」を感じるための時間
【宮本氏】
このセッションでは、これまでよりも少し技術寄りの内容を扱います。全部を理解しきれなくても構いません。
大事なのは「普段プロトコルに携わっている開発者たちが、どんな問題意識で、何を議論しているのか」の“雰囲気”を感じてもらうことです。
今日は特に、次のような論点を扱います。
- ビットコインのスケーラビリティ問題（2種類）
- レイヤー2とライトニングネットワーク（LN）の現状と課題
- Utreexo によるフルノード軽量化
- ロールアップ／BitVM など新しい提案
- 研究・教育・開発者コミュニティをどう広げるか
RGBや「他アセット発行」の話はあえて扱いません。テーマはあくまで BTCそのものをどうスケールさせ、長期的な基盤にしていくか です。
2. ビットコインが直面している「2つのスケーラビリティ問題」
2-1. L1のキャパシティと手数料の問題
【宮本氏】
まず前提として共有したいのが、よく言われる「スケーラビリティ問題」です。
1つ目は、ブロックチェーン全般に共通するオーソドックスな問題です。ビットコインは「全世界で1つの共有データベース」を前提にしているため、そのままでは大量のトランザクション（取引）をさばくのに向いていません。
- ブロックサイズは上限がある
- 使いたい人が増えれば、1トランザクションあたりの手数料（fee）が高騰する
歴史的に見ても、ブロックサイズやトランザクション数の推移は右肩上がりで、「放っておけば自然に解決する問題」ではありません。
むしろ、放置すると必ず悪化していく構造 を持っています。
2-2. UTXOセットの肥大化という、もうひとつのスケーラビリティ問題
【宮本氏】
もう1つ、多くの人が見落としがちな問題があります。それが UTXOセットのサイズ問題 です。
ビットコインノードは、トランザクションを検証するために「今、誰がいくら持っているか」という“現在の状態”をUTXOセットとして保持しています。
- このUTXOセットは頻繁にアクセスされる
- できればメモリ上に全て載せたい
- しかし最近は急速に肥大化しており、2023年以降は特に伸びが急激
結果として、フルノード運用の負荷 がどんどん上がっている。将来を見据えると、ここをどうするかは避けて通れないテーマです。
この問題に対する大きなアプローチの1つが、のちほど詳しく触れる Utreexo です。
3. レイヤー2とは何か？
3-1. レイヤー2の定義
【宮本氏】
簡単にレイヤー2（L2）を整理しておきます。レイヤー2とは、ざっくり言うと：
「オンチェーンに毎回書かなくても、ビットコインの所有権を移動させる仕組み」
を指します。
ただし重要な条件があります。
- 参加者は「いつでも」「誰の許可もなく」
- 自分の資産を本物のビットコイン（L1）に戻せること
この条件を満たさない「取引所の内部DB上の残高移動」などは、レイヤー2とは呼びません。
代表例は：
- ライトニングネットワーク（LN）
- Ark（※発展途上の提案）
特にビットコイン圏では、「レイヤー2＝ほぼライトニング（ライトニングネットワーク）」といってよい状況です。
3-2. ライトニングネットワークをざっくりおさらい
【宮本氏】
LNの細かい仕組みは本やドキュメントに譲りますが、ポイントだけ挙げると：
- 2者間チャンネルを開く
- チャンネル内の残高をオフチェーンで更新し続ける
- 必要になったらオンチェーンで精算する
という動きをします。
興味がある人には、『Mastering the Lightning Network』（マスタリング・ライトニング・ネットワーク）を強くおすすめします。
GitHubで英語版の草稿も公開されています。
4. Tadge氏が見ている「ライトニングの本質的な難しさ」
4-1. 「秘密鍵さえあればOK」ではない世界
【Tadge氏】
みなさん初めまして。日本は約5年ぶりで、日本語は少し忘れましたが頑張ります。
10年ほど前、日本の三重大学で働いていましたが、ビットコインを見つけて「これをやりたい！」と思い、アメリカに戻りました。
- ライトニングネットワークの論文
- Utreexo
- DLC（Discreet Log Contracts）
などに取り組んできました。
ライトニングで最初から変わっていない「本質的な難しさ」は、「秘密鍵だけあれば十分」ではない という点です。
L1では：
- 秘密鍵を持っていれば、そのビットコインの所有者とみなせる
しかしLNでは：
- 秘密鍵だけでは足りない
- 相手側ノードやネットワーク上の「状態データ」も重要
取引所などが「ビットコインの秘密鍵はHSMに入れておけば安全」と考えるノリでライトニングを扱おうとすると、そこで齟齬が生まれます。
LNは、その設計上どうしても L1よりも複雑 であり、そこは「解消する」のではなく「付き合っていく」種類の問題だと考えています。
4-2. 手数料スパイクと、その後の改善
【Tadge氏】
もう1つ、大きな話題だったのが オンチェーンfee（手数料）の急騰 です。
- L1のfeeが激しく高騰すると、チャンネル運用が一気に難しくなる
- チャンネル開閉トランザクションのコストが読めなくなる
2023年のfeeスパイクでは、ライトニング実装側の多くのバグや設計不足が表に出ました。
ただ、そこから：
- ソフトウェア改良
- fee状況をみながら自動的にチャンネル戦略を変える機能
- より賢いルーティング
などが実装され、今は当時よりかなりマシになっています。
「feeが再び上がっても、以前ほど致命的ではなくなりつつある」
というのが、現時点での感触です。
5. 安土氏・小川氏が語る：ライトニングの「UX・手数料・プライバシー」の宿題
5-1. L1変更も視野に入る「fee問題」
【宮本氏】
ライトニングの課題として、feeやUXについてどう見ていますか？
【安土】
feeの問題で言うと、L1を変えないと根本的に解決できない部分 も残っていると感じています。
LNを含む「オフチェーンの仕組み」は、
- 事前に署名だけしておき
- 必要になったとき、オンチェーンにブロードキャストする
という構造を取ります。
ただし：
- 署名したときと、実際にブロードキャストする時点でfeeレートが大きく変わっている
- その差が大きすぎると、そもそもトランザクションをリレーできない
このギャップを埋めるために：
- feeレートの監視
- 状況が悪くなる前にチャンネルを閉じる
- ソフトウェア側での自動制御
などが日々実装されていますが、ユーザーから見ると
「勝手にチャンネルが閉じられた」
ように感じられてしまうこともあります。
LNを大衆に広げていくうえで、UXと内部の複雑さをどう橋渡しするか は、まだ課題が多いと思います。
5-2. 「1ユーザー1UTXO」がハードルになる
【小川氏】
実務的な視点で言うと、ライトニングの参入ハードルになっているのが：
- チャンネルを開くためにオンチェーンのトランザクションが必要
- 事実上「1ユーザー1UTXO」が必要と言われる構造
という部分です。
ビットコインやLNに詳しい人同士なら良いのですが、「ビットコインを持っていない人」「仕組みを知らない人」をLNに参加させようとすると、最初の一歩でつまずきやすい。
理想的には：
- 2人だけではなく、3人、4人、5人、10人、100人 といった単位でひとつの仕組みに参加できる
- 一般ユーザーでも、単純な操作だけでLN的なメリットを受けられる
そういった方向に進むと、もっと「サービスとしての使いやすさ」が上がるのではないかと考えています。
5-3. 送金失敗率とルーティング問題
【宮本氏】
実際のところ、ライトニング支払いの失敗率はまだ高いのでしょうか？
【小川氏】
体感では、まだ かなり失敗します。
【Tadge】
理由の1つは、ネットワークを構成するノードがすべてプロフェッショナルではないからです。
- 取引所など大規模ノードもあれば
- 個人が趣味で立てている小さなノードもある
ルーティングでは：
- ある経路（path）で送金を試す
- 失敗したら別の経路に切り替える
ということを自動で繰り返しますが、ノード品質にばらつきがあるため、どうしても一定の失敗率は残ります。
また、プライバシー保護とユースビリティのトレードオフも大きいです。
- エラー内容を詳細に返すと、ルーティング状況の「プロービング」が容易になり、プライバシーが弱くなる
- 逆に、情報を絞ると、デバッグも改善も難しくなる
この「プライバシー vs. 使いやすさ」のバランスは、いまだに難しいテーマです。
6. ライトニング以外のL2：Ark・ロールアップ・BitVM など
6-1. Ark の特徴：失敗しない送金とソフトフォーク依存
【宮本氏】
ライトニング以外のL2として、Ark についてはどう見ていますか？
【小川氏】
Arkをユーザビリティ面から見ると：
- ユーザーは「ASP（Ark Service Provider）」に自分の送金データを渡す
- ASPがそれらをバンドル（束ね）て、一定間隔ごとにオンチェーンに流す
という構造になっていて、
- マルチホップのルーティングが不要
- 「送金が失敗する」という概念が基本的にない
というのが大きな特徴です。
ただし現在の提案では：
- 本格的に使いやすくするには 新しいOPコード（OP_CTVなど）の導入
- つまり ソフトフォークが前提
という側面もあり、実用化には「プロトコルレベルの合意」が必要になります。
6-2. BitVMとロールアップの可能性と違和感
【宮本氏】
BitVMやロールアップ周りについてはどう見ていますか？
【安土氏】
BitVMまわりでは、「任意計算の検証をビットコイン上でどう行うか」に注目した提案がいくつも出てきています。
- BitVM0 / 1 / 2 / X … と派生が増えている
- ZK検証に特化した提案も出てきている
目的の1つは、ロールアップをビットコインの上で実現すること です。
【Tadge氏】
ロールアップは面白い一方で：
- トラストモデルがLiquid (Blockstream) のような「信頼されたマルチシグ」に近づくもの
- 特定のハードウェア（SGX）の信頼に依存するもの
なども多く、「どこまでをビットコインに持ち込むべきか」は慎重に見ています。
個人的には：
- なるべく「自分のPCだけ」で完結する
- P2Pらしいモデルを維持する
という方向を重視していて、SGX的な前提に過度に依存する設計には、あまり前向きではありません。
7. Utreexo：フルノードを小さく、軽くする試み
7-1. Utreexoとは何か
【宮本氏】
Utreexoは、UTXOセット問題の「唯一の解」なのでしょうか？
【Tadge氏】
いいえ、「唯一」ではありません。ただし、非常に有力なアプローチの1つだと思っています。
Utreexoは簡単に言うと：
「UTXOセットを圧縮し、小さな証明構造として扱う手法」
です。
- ユーザーの見た目は、ほとんど変わらない
- 変わるのは「フルノード内部の構造」
- ノードのディスク容量とメモリ負荷を、大幅に減らせる可能性がある
Utreexo自体はL2ではありません。ビットコインコア側のノード実装を変える話であり、L1の“土台”を軽くするための技術 です。
7-2. ブリッジノード問題とインセンティブ
【小川氏】
Utreexoを実務で試していない大きな理由の1つは、「ブリッジノードの単一障害点リスク」です。
- ビットコインコアからデータを受け取り
- Utreexo形式に変換する「ブリッジノード」が必要
- そのノードが落ちたらどうなるのか？
そこがまだ不安で、積極的に本番導入するところまでは至っていません。
【Tadge氏】
現在、世界には Utreexoのブリッジノードが2台しかないはずです。1つは私、もう1つは開発者の Calvin です。
ただし最近の研究では：
- どのノードがブリッジなのか、ネットワーク上から識別できない構造
- つまり「ブリッジだけを狙った攻撃」が難しい状態
を目指した改良も進めています。
また、UTXOセットの肥大化自体は：
- 今すぐ致命傷になるほどではない（まだ十数GBレベル）
- しかし、100年スパンで見れば確実に問題になる
という「長期の宿題」です。
「UTXOセット問題を誰も気にしなくなったら危険だけれど、今は『Tadgeがやってるから大丈夫』という空気がビットコイン界隈にある」
というジョーク混じりの本音も語っていました。
8. 研究・教育・人材：「ビットコインで1バイトを削る」ことの価値をどう伝えるか
8-1. 出口から考える研究と、「1バイト」の重さ
【宮本氏】
大学などで「ブロックチェーン研究」をしている人は増えましたが、「ビットコインを改善するための研究」はまだ少ないように感じます。
- ゼロ知識証明を使いたいからZKロールアップを研究する
- ビットコインやUTXOセットのサイズ削減をゴールに据えているわけではない
というパターンが多い印象です。
【安土氏】
ビットコインコアの改善は、
- 署名データを1バイト減らす
- UTXOセットの成長を少しでも抑える
といった地味な仕事の積み重ねです。
派手な新機能ではないため、注目されにくい反面、長期的な分散性やノード運用のしやすさ に直結します。
他チェーンの研究者にとっても：
- ビットコインがなぜこういう改善を続けているのか？
- どのように分散性を維持しようとしているのか？
を参考にする価値は大きいはずです。
本来、暗号技術は「使う技術が少ないほど安全」な側面もあるので、“難しい技術を使うこと”を目的化しない研究姿勢 が重要だと思います。
8-2. 開発者をどう増やすか：「大企業に入る」以外のキャリアパス
【宮本氏】
ビットコインコアやUtreexoにコントリビュートする人を増やすうえで、どんな苦労がありますか？
【Tadge氏】
MITで働いていたときもそうでしたが、大学の先生たちの多くはビットコインにあまり前向きではありません。
結局、今活躍している開発者の多くは：
- 大学や会社ではなく、自分でビットコインを学び
- 自主的にコミュニティに参加し
- そのあとグラントなどの支援を受けて活動している
というパターンが多いです。
今は以前よりも：
- Brink, OpenSats などのグラント
- 企業やファンドによる開発者支援
が増え、「インディペンデント開発者（宮本氏）」としてやっていける環境 は整いつつあります。
ただし、これは日本の文化とは少し相性が悪い部分もあるかもしれません。「大きな会社に入る」以外のキャリアを選びにくい空気もあるので。
それでも、
「自分で学び、自分でプロジェクトを始める人」が増えることが、ビットコインの健全性にとって非常に重要だと思います。
8-3. 現場での「教育が進まない」リアル
【小川氏】
僕自身も、会社の中で：
- ビットコイン特有の部分は自分が全部やってしまい
- 他のエンジニアには、通常のアプリケーション部分だけを任せる
という形になりがちです。
本当は教育して広げないとスケールしないのですが、そこに割ける体力・時間が限られているのが現実です。
【宮本氏】
取引所や事業会社でも同じ問題があります。
- 「詳しい人に全部寄せる」のが短期的には早い
- しかしそれでは長期的にリスクが高い
ビットコイン開発だけでなく、「問題意識を共有できる人」を増やすこと自体が課題 になっています。
9. Q&Aハイライト：Fedimint・Greenlight など周辺技術
最後に、会場とのQ&Aから印象的だったやりとりを2つだけ抜粋します。
9-1. Fedimint（フェディミント）について
【質問者】
Fedimint でライトニングを使うことについて、どう思いますか？
【Tadge氏】
Fedimint と E-cash の仕組みは、とてもクールだと思います。
ただし：
- 本質的に「カストディアル」な仕組みである
- 小さなコミュニティや家族・グループには向いている
が、グローバルなライトニングと同じものとして捉えるべきではない
【宮本氏】
取引所レベルでFedimintを使うと面白い構造も作れますが、
- プライバシー（匿名性）が高くなる
- 規制やコンプライアンスとの整合性
など、別の難しさも出てきます。
9-2. Greenlight（鍵分離型ノードサービス）について
【質問者】
Greenlight を使っていて、どんな課題がありますか？
【小川】
Greenlight は：
- 秘密鍵はユーザー側
- ノード運用はクラウド上のサービス側
という形で、アプリ開発者がノード管理を意識せずにライトニング対応アプリを作れるのが魅力です。
一方で、現状では：
- ルーティングアルゴリズムがまだ洗練されておらず、送金失敗も多い
- 成功した支払い経路をキャッシュせず、毎回ランダム探索するため
安定性に欠ける部分があるといった課題もあります。
とはいえ、今後：
- ルーティング特化のプラグイン
- アルゴリズム改善
が入ってくれば、「アプリ側はLNの細部を意識しなくていい」世界 に近づいていく可能性があります。
まとめ：「1バイト削る」タイプの地味な進歩が、ビットコインを「堅牢な長期基盤」に変えていく
このセッション全体を通して、強く浮かび上がってきたメッセージは次の3点です。
- スケーラビリティ問題は2層構造
- L1のキャパシティ／fee問題
- UTXOセット肥大化というフルノード問題
- ライトニングネットワークは「まだ道半ば」だが、着実に改善している
- feeスパイクで多くの課題が露呈
- それを受けて実装・運用がブラッシュアップされてきた
- それでもUX・プライバシー・ルーティングは、なお大きな宿題
- ビットコインの強みは、地味で執拗な改善の積み重ねにある
- 1トランザクションの1バイトを削る
- UTXOセットの数GBを未来のために削る
- そうした取り組みに「出口」を見出している研究者・開発者がいる
L2・ロールアップ・BitVM といった派手なキーワードに目が行きがちな中で、このセッションはあらためて
「ビットコインを長期のビジネス基盤にするための“土台づくり”」
に焦点を当てた、非常に示唆の多い内容でした。
事業者の立場からビットコインを使う人ほど、
- L1の制約
- L2のトレードオフ
- フルノードやUTXOセットの話
といった“地味な層”に触れておくことで、長期視点での戦略設計に厚みが出てくるはずです。
