ライトニングネットワーク誕生秘話：ビットコインを支えたもう一人の立役者【後編】

イザベル：
Utreexoって何？そこから教えてもらえない？

タッジ：
オーケー、まずはそこから始めよう。

こんにちは！yutaro です。

本日のPro向け「BTCインサイト」では、ライトニングネットワーク論文（ホワイトペーパー）を共同執筆したひとり、Tadge Dryja氏へのインタビュー後編です。

Utreexo、任意データ戦争、マークルツリー、量子コンピューター論とLifeboatなど、本日もとても興味深く面白い話題が満載です。

(※本日は最終章です… 前編 | 中編)

---

Utreexo、そして「任意データ」論争

イザベル：
Utreexoって何？そこから教えてもらえない？

タッジ：
オーケー、良い説明の仕方としては——ノードを走らせるとき、
大きなデータが入ったフォルダが二つある。一つは「chainstate」、もう一つは「blocks」。
「blocks」フォルダはブロックチェーン。ビットコインでこれまで起きた全トランザクションが入ってる。
今は700何十ギガとか？
で、「chainstate」は、その結果——つまり、今どのビットコインが存在するか、ってやつ。
こっちはずっと小さい。15ギガとか、そのくらい。
実際、小さくなったりもする。上がったり下がったりする。

ブロックチェーンは増える一方。新しいブロックが出るたびに増える。
一方は全トランザクションのデータで、もう一方は、
「この瞬間みんなのウォレットに何があるか」のスナップショット、みたいなもの。

イザベル：
そうだね。残高が残っている、ということ。

タッジ：
ブロックチェーンをざっと走査すれば、その結果としてchainstateが得られる。
で、スケーリングは最初から課題だった。
サトシの論文に対する最初のコメントも「これはスケールしない」だったし。

でも直感に反するのは、巨大な700ギガの方——ブロックチェーンは、
chainstateに比べると、本質的なボトルネックではない、ってこと。
実際のボトルネックはchainstateの方。

今のビットコイン・コアでは、ブロックチェーンは剪定（prune）できる。
「2009年から2017年までのブロックを全部消す」みたいなことができる。
必要ないからね。もう走査したんだし。
必要なのは、まだ使ってる他の人にそれを供給するためだけ。

イザベル：
ちなみに、今みんなが言い争ってる任意データも、同じように剪定できるのよね？

タッジ：
あるよ——言いたくないけど——
データをブロックではなくchainstate側に入れるプロジェクトがある。

イザベル：
剪定できないようにするため？

タッジ：
バカげてる。Utreexoなら剪定できるから。
でも現状のままだと剪定できない。

とはいえ、ビットコインに載せられてる任意データの大半は剪定できる。
セグウィットの割引があるから。ウィットネスは重みが1/4で数えられる。

イザベル：
ここで大穴に落ち込みそう。「なぜ人々はフィルタリングとかじゃなくて、
単に剪定しないの？」って質問を延々したくなる。

タッジ：
みんなやってるよ。
いや、剪定って「一切触らない」って意味じゃない。
剪定は「メンプールで受け取り、ブロックで見る」ってこと。

イザベル：
でも剪定はノードの負荷を軽くする、ってことよね？

タッジ：
ディスクから消すだけ。けど、処理はする。
ネットワークで受け取る。
つまり時間の問題。状態をノードに取り込むのに時間がかかる。
でも保存はしない、ってだけ。

しばらくは持つけどね。
大抵のノードは数週間分は持って、その後古いのを消せる。

イザベル：
つまり基本的には時間の問題。ノードの同期に時間がよりかかる、ってこと？

タッジ：
そう、でもインスクリプションやJPEGは、バイトあたりの検証はすごく速い。

イザベル：
本当に？署名がないから？

タッジ：
そう、「300KBのJPEGがあります」ってきたら、ノードは「ハッシュ一致、終わり」。
一方、300KBの署名があると——検証でガリガリ回す。

イザベル：
じゃあ速度の議論はそこまで強くない？

タッジ：
個人的には気にしてない。オーディナルズを見ても「これは馬鹿げてる」って思った。
でも、「ビットコインへの攻撃だ」とまでは思わない。
やりやすい攻撃ではあるけど、そんなに心配してない。

僕が理解する限りでより厄介なのは——
「偽（Fake）の公開鍵」を使うやつ。

ウィットネス領域にJPEGを置く代わりに、JPEGを公開鍵っぽい小片に切って、
アウトプットに入れる。

イザベル：
誰がそんなことを？

タッジ：
たぶん、JPEGが悪だって証明したい人たち。

イザベル：
理論上の話でしょ？本物のデジェンがやってるわけじゃないよね。

タッジ：
いや、かなり大きい。何十メガもある。たくさんある。

イザベル：
でも、それって本当のプロジェクトがやってるの？

タッジ：
たぶん「Stamps」って呼ばれてる。

イザベル：
ああ、Stampsね。オーケー、分かった。まさにそれね。
彼らはただトロールしてるんだと思う。

タッジ：
でも——ああ、そうだ。Stampsは剪定できない。

イザベル：
了解。

タッジ：
chainstateに入ってるから、Stampsは剪定できない。
UTXOセットにね。

ノードはそれをUTXO——未使用トランザクションアウトプットだと思う。
それが「使えない」なんて分からない。
僕が見れば「これは本物のトランザクション・アウトプットじゃない」って分かる。

イザベル：
Stampsのデータはどこに入ってる？

タッジ：
アウトプット。

イザベル：
つまり、アドレス自体ってこと？

タッジ：
ウィットネスとは対照的にね。基本的には。

タッジ：
ウィットネスは完全に普通。
でも発想はこう。「JPEGを持ってる。これを32バイトのチャンクに切る。
アウトプットは32バイト。その中に入れる」。
だから君のコンピューターは「これは公開鍵だ」と思う。
「誰かが次の10分でこれを使うかもしれない」。
だからメモリ上、あるいはUTXOセットに保持しないといけない。
でも見れば「これは鍵じゃない」。見た目が鍵じゃない。でも鍵「かもしれない」。
「鍵じゃない」とは証明できない。

イザベル：
そうね、「鍵じゃない」は証明できない。
だから、ノードを作って「これらは剪定する」ってやろうとしても——

タッジ：
アウトプットは基本的に剪定できない。

イザベル：
OP_RETURNならできるでしょ？

タッジ：
できる。OP_RETURNの発想は、「アウトプットにこの1バイト（を先頭に）入れたら、
それは使えない」ってこと。
だからOP_RETURNを置いて好きなデータを置く。
するとノードはOP_RETURNを見て、「オーケー、これはchainstateフォルダには保存しない。
無視する。だってこれは絶対に使えないから」となる。
だから追跡する必要がない。

でも、もしアドレス側——つまりトランザクションのどの部分かというと、
基本的にアドレスになるけど——そこに入れて、
実在しないアドレスに送る、って形にして、データをエンコードしちゃえば——

イザベル：
分かった。
私はStampsを知ってて、剪定できないってのも知ってた。
まさにあなたの言う通り、それが彼らの主張の核だった。
だからアドレスに入れるって決めたのね。

タッジ：
ナンセンスだと思う。だってそれは要求できないから。
ウィットネスデータなら要求できる。
同じやり方で要求できるんだ。
「ブロックチェーンからこのJPEGを取得したい」って言うなら、
（そんなこと本当にやる人がいるか分からないけど）任意のノードに接続して、
「提供可能な履歴、全部ちょうだい。あのブロック、くれる？」って聞ける。
そしたらブロックをくれる。で、JPEGが見られる。

アウトプットを要求する方法はない。
「UTXOセットのこの部分を見せて」って言えない。
だからどっちにしても、まったく同じコマンドでデータを要求することになる。

つまり、Stampsは、現状では剪定できない任意データの良い例だけど、
Utreexoがあれば無意味になる。

イザベル：
うん、うん、うん。オーケー。

タッジ：
つまり、chainstate——UTXOセットは、分からない、
いつも変わるけど、1億何千万という小さなUTXOで構成されてる。
で、遅い理由はまさにそこ。ビットコインのスケーリングの制限要因になってる。

イザベル：
UTXOセットが、ね。

タッジ：
そう。だから、オーディナルとかインスクリプションが原因じゃなくて、
本質的にUTXOセットこそが、長期的にノードを膨らませる問題になる。

イザベル：
そう言っていいと思う？

タッジ：
言えると思う。もちろん物事は複雑だけど、だいたいそんな感じ。

イザベル：
オーケー。

タッジ：
今はUTXOセットはブロックチェーンに比べればかなり小さい。
でも、そうであり続ける必要はない。
もし誰かが——アイデアを与えたくないけど——
大金を持ってビットコインを攻撃したいなら、
UTXOセットを10分ごとに1MBずつ膨らませることができる。
そうすれば、剪定できない100GBのUTXOセットにだってできる。
で、それを全部保持してトランザクションを検証しなきゃいけない。しかも速く。

もし君がマイナーなら、ブロックを見て、UTXOセットに照らしてチェックして、
「オーケーかどうか」を素早く判断しないと、競争で勝てない。

イザベル：
で、さっき言ってたように、署名の検証は遅い。
でもそれは別問題でしょ？

タッジ：
そう、CPU時間の話。署名検証のための。
もう一つ遅いのはディスクI/O。
つまり、UTXOセットがあって——たとえば1億5千万個の小さなエントリ。
一つ一つは60バイトくらい。
で、ブロックが来ると、5,000とか6,000個の小さなエントリを参照しないといけない。

タッジ：
もしスピニングHDDなら、物理的にヘッドを5,000回も動かすことになる。
すごく小さなエントリを探すためにね。だからめちゃくちゃ時間がかかる。
誰もHDDは使わない。だからSSDを使う。
でもSSDでも、すごく小さな読み出しが大量に発生する。これはコンピューターにとって遅い。
そういうものなんだ。
だから、これが速度とスケーラビリティの制限要因になることが多い。

---

ブリッジノードと「圧縮されたUTXO」案

タッジ：
で、Utreexoのアイデアは——いや、昔からあるアイデアだけど——
たぶん僕を動かしたのは、Financial Cryptoってところにいた時。
暗号通貨の「クリプト」じゃない、ビットコインよりずっと前からあるカンファレンスで、
金融暗号（Financial Cryptography）のこと。
大体いつも、ビーチとかでやるんだけど。
そこでsipa、Pieter Wuilleと話してて、彼が言ってたのは——

彼はこのアイデアはうまくいかないと思ってる。つまり、アキュムレータ（累積器）という発想、UTXOセット全体を保存する代わりに、ギュッと潰した表現だけを保存して、人々が自分のコインがその集合に入っていることを証明する、というやつ。

彼いわく、「ブリッジノードが必要だから無理だ」。わかると思うけど、ゼロから始めるなら動く。みんなが「オーケー、これが俺たちのビットコインの使い方。UTXOセットは持たない。小さな累積値だけ追跡する」って合意できるならね。

で、みんなのウォレットが証明を持つ。だからウォレットでトランザクションを作るとき、所有の署名をするだけじゃなくて、それが存在することも証明する。

イザベル：
どうやって、自分のUTXOがその圧縮状態に含まれているって証明するの？さっきあなたに聞こうとしてた質問はそれ。

タッジ：
うん、当初のアイデアでは——こういうアキュムレータと呼ばれるものに関する研究の大半はRSAアキュムレータなんだ。特性が良いからね。証明がとても小さい。ひとかけらの小さな証明でブロック全体を証明できる。だから、それは本当に良さそうに見える。

でも問題は、その証明を更新しないといけないこと。誰もが証明を受け取れるように、証明を提供するコンピュータが必要になる。全員に「ウォレットで自分の証明を持ってね」と要求しない限りはね。で、RSAの証明は十分な速さで更新できない。だからUtreexoがやっているのは、マークルツリーを使うこと。

そう、Utreexo。つまり、UTXOセット全体をマークルツリーの集合に入れる。

---

なぜ複数のマークルツリー？木の本数と二進数

イザベル：
なぜマークルツリーの“集合”なの？木はいくつ必要？

タッジ：
だいたい20本。

イザベル：
オーケー、20本のツリー。なぜ20本？UTXOセットを20本のマークルツリーに入れる必要があるの？

タッジ：
オタクっぽく説明すると、必要な木の本数は、UTXO数の二進数表現における1の個数なんだ。だから、もしUTXOが16個なら、必要なのは1本だけ。17個なら2本必要。65,535個なら15本必要、みたいな。

イザベル：
なるほど。

タッジ：
そう、二進数で書いて1の数を数える。それが必要な木の本数。

イザベル：
じゃあ、これは設計上の選択ってことね。技術的な制限じゃなくて。そういう設計にしたってこと？

タッジ：
ある意味、そう“せざるを得ない”。Utreexoは、やってると宇宙に「いや、それがやり方だよ。他に道はない」って言われてる感じがするやつなんだ。つまり、「log⁡nlogn 個（正確にはおよそその半分）のルートが要る」って世界が決めてるみたいな。

じゃあどうやるの？って言われたら、自然にそうなる。そこが取り組んでて楽しいところで、Utreexoには自然なエレガンスがある。いや、エレガントかは分からないけど、「そう、こうしないと……」みたいな。

イザベル：
Sjors Provoostは、Bitcoin ExplainedのUtreexo回で「エレガント」って評してたよ。あれはすごくオススメ。

タッジ：
うん。ライトニングやDLCよりも、数学的に「おっ、ここハマるね」って楽しいところがある。最初にUtreexoに取り組んだときは本当に楽しかったよ。「こうやればいい」って手がかりがあって、「あ、動くじゃん」ってなって、さらに「あ、これも」って続く感じ。

---

「読むのは削除時だけ」—ビットコイン特有の整合

タッジ：
それに、ビットコイン特有で良い点がある。ビットコインでは、UTXOセットは普通はHDD上にあって、新しいUTXOは書き込まれる。誰かがトランザクションを作ると、出力が保存される。誰かがそれを使うと、読み出されて、削除される。

で、良いのは、「読む」のが必要になるのは削除するときだけ、ってこと。Utreexoではこれが本当にうまく噛み合う。証明するときに、その証明が削除に必要なデータにもなっている。全体として気持ちよくハマるんだ。ちょっと楽しい。

イザベル：
そこが「エレガント」だって言われてた部分ね。

タッジ：
そう。自然にそうなった。狙ってやったわけじゃない。「お、動いた、クール」って感じ。僕について「クールなアイデアをいっぱい持ってる」みたいに言う人もいるけど、実際は多くが「早く始めた」ってだけだと思う。

もし僕がライトニングに取り組まなかったら、誰かが1年後に同じことを思いついてたはず。

---

なぜ「RSA式」はダメで、UtreexoはOKなのか

イザベル：
じゃあ、これが良い前振りなんだけど、Pieter Wuilleが「これは動かない」と言った理由は？

タッジ：
みんながRSAベースとか、他の——「派手」とは言いたくないけど——圧縮可能な証明を持つアキュムレータで考えていたから。例えば、「証明が必要です。はい、ブロックが出ました。入力が6,000個あります。6,000のUTXOが使われてます」。RSAアキュムレータなら、数百バイトの小さな証明ひとつで済む。「6,000全部証明しました。終わり」。それは素晴らしい。

でもUtreexoはそういう動き方をしない。Utreexoでは、基本的に6,000全部に対して証明が要る。これは欠点、完全に認めるよ。だけどトレードオフとして、オンデマンドで何でも証明してくれる「ブリッジノード」は、ラップトップでも全然やれる。RSAの方だと、それが……。

イザベル：
理屈ではブリッジノードは1つあれば足りるのよね？すごく中央集権的だけど。

タッジ：
ただ、とても脆い。だから、たくさん欲しい。できるだけ多くのブリッジノードが欲しい。
でも、RSA式でもハッシュ系アキュムレータでも、技術的には1個のブリッジノードで回るのは確か。みんなが使い始めたら、ブリッジノードは要らなくなる。みんながUtreexoノードを走らせるのが当たり前になればね。

でも、それってどうやって起こるの？文字どおり「全員」じゃないといけない。ブリッジノードがなくなって、誰か1人が「コインを使いたい」ってなったら、「え、証明は？」って言われる。「証明って何？」みたいな。

だから、おそらくブリッジノードは永遠に必要。ブリッジノードが必要——明確に言うと、ブリッジノードってのは両方のソフトを動かしてるノード。古いUTXOセットも持ってて、フルのマークルツリーも持ってるから、何でも証明できる。

イザベル：
でも、みんながそのブリッジノードに接続するって、どうやって分かるの？

タッジ：
今のソフト（ちゃんと動く）では、ブリッジノードは自分がブリッジだと広告しない。完全にステルスで見抜けない、とは言わないけど、「やあ、ブリッジノードだよ」とは名乗らない。

イザベル：
じゃあ、誰に接続すればいいか、どうやって分かるの？

タッジ：
普通にピアに接続して、トランザクションを中継し合うだけ。例えば、ブリッジノードがあるとして、そいつは通常の非Utreexoトランザクションを見る。メンプールで見かけた非Utreexoトランザクション全部に証明をくっつけて、反対側（Utreexo側）に流す。だから、必ずしもブリッジノードから直接情報をもらう必要はない。ブリッジから受け取った別のノードからもらってもいい。

つまり、通常のメンプールと同様に、ピアツーピアのゴシップネットワークになる。他の人とゴシップできる。それが重要だと思ってる。そうしない方が楽だけど、あえてそうした。最初はブリッジノードが10〜20しかないかもしれない。利用者が少ないからね。そういうのを、Electrumノードみたいな「狙われる的」にしたくない。

---

RSAアキュムレータが抱える“更新”の壁と論文の示唆

イザベル：
Pieter Wuilleは、なぜブリッジノードが「致命的」とは思わなかったの？

タッジ：
RSAアキュムレータの場合は、ちょっと混乱するんだけど……いや、複雑すぎるってこと。要するに、UTXOごとに証明を個別に更新しないといけない。

イザベル：
なるほど。

タッジ：
他にも緩和策になり得るテクニックはあるけど、本質的にはこう。「1億5,000万UTXOがあって、ブロックが出ました」。これは不利だよね。で、ジョー・ボノーの2～3年前の良い論文があって、これはハードリミットだ、回避策はないって示している。証明の変更をゼロにはできない、みたいな。僕は証明の仕方は分からないけど、彼は「Utreexoがほぼ最善」だと言ってくれてる感じ。

つまり、「証明が変わる」という現実がある。それは悪い。なぜならビットコインの最大の成功パターンの一つは「シードフレーズを持って、ビットコインを持って、覚えるなり金庫に入れるなりして、10年後に取り出す」。保持するのはシードフレーズだけ、というモデル。

「ビットコインを使うために、変わり続けるデータを追いかけなきゃいけない」という発想は良くない。ライトニングネットワークの最大の問題の一つも、まさにそれ。

イザベル：
解決策はないの？

タッジ：
アキュムレータでは、ない。

イザベル：
ソフトフォークで解ける、とかでもなく？コアのブロックチェーン側に焼き込む形で？

タッジ：
いや。ブリッジノードが解決する。発想はこうだ。「証明を自分で追わない。他の誰かが自分のためにやってくれる」。だって今は全員がそうしてる。全員がUTXOセット全部を持ってる。だから、「それを持って証明できるノードが限定的に存在する」って状態にするだけ。

RSA設計だとそれは非現実的だった。ブロックが出るたびに1億5,000万回みたいなオペレーションが必要になるから。Utreexoだとそうじゃない。必要なのはアキュムレータの変化分に対する操作だけ。つまり、6,000に対して2～3倍くらい。数千回の操作で済む。何億回でもない。

---

量子耐性「Lifeboat」へ—量子コンピュータ観と備え

イザベル：
ソフトフォークの話で言うと、時間のあるうちにLifeboatの話まで行きたい——

というか、そう。理論的にはLifeboatはソフトフォーク提案になる。Lifeboatを機能させるにはソフトフォークが必要。

タッジ：
そこは触れないでおく。

イザベル：
その前に——これが最後のトピックにするって約束するから。Lifeboatに入る前に、これは量子への解決提案よね。なぜ、というか、量子と、今のビットコイン界の量子への注目について、あなたの見解は？

タッジ：
僕はね……そう。昨年のTabConfで誰かに言ってたんだけど、「自分が生きてるうちに量子コンピュータは存在しない」と思ってる。賭けてもいい。「僕の生きてる間に量子コンピュータは現れない」に賭けるよ、って。

---

DH Magazine Proへの招待

月7ドルでDH Magazine Proに参加して、より詳細な情報を受け取りつつ、Diamond Handsの活動を支援しよう！


詳細は以下のPro版の内容紹介記事をご確認ください。

DH Magazine Proに参加して、ビットコインライフをさらに楽しもう

---