ビットコインの取引容量問題 — なぜ巧妙なトリックを使っても回避できないのか

この記事では、ビットコイン ネットワーク、特にライトニング ネットワークのトランザクション容量を増やすためのいくつかの代替案を分析します。しかし、提示された議論は一般的なものであり、提案された他の代替案にも当てはまります。

マイク・ハーン著

まず、背景を説明します。

何年も前、サトシ・ナカモトはビットコインのソースコードに制限を追加しました。彼は、クライアントがビットコインのブロックチェーン全体をダウンロードする速度を非常に遅くすることで、マイナーが悪意を持って妨害するのを防ぐため、ビットコインの取引容量を人為的に制限しました。

この制限は当初削除される予定でした。実際、サトシは SPV ウォレットが開発され次第、それを削除する予定でした。

私がこれを知っているのは、2010 年後半に彼にメールで尋ねたからです。彼はこう答えた。

実際の使用量がその制限に近づき、それが機能することを確認できたら、より高いブロック制限を段階的に導入する可能性があります。

最終的には、クライアント専用のウォレットがあれば、ブロック サイズの制限は問題になりません。それまでは、ビットコインを使用するにはすべてのユーザーがブロックチェーン全体をダウンロードする必要があるため、適切なサイズを維持します。

私たちが議論したクライアント専用のウォレットは、Android ウォレット、MultiBit、BreadWallet などでした。当時は、SPV ウォレットは利用できませんでした。このフレーズは私が初めて使用しました。 （翻訳者注：著者は、SPVウォレットという名前を最初に発明した人物だと言っています。）

サトシ・ナカモトの当初の意図によれば、ブロックサイズの制限は数年前に増加されるべきでした。しかし、私たちはそれを最後の最後まで残しました。私の大まかな計算によると、ビットコインの使用量は冬に増加し、夏に停滞します。現在の傾向が続くと、ビットコインの容量は 2016 年の初冬までに枯渇し、おそらく数か月早く枯渇するでしょう。アップグレードには時間がかかるため、今から準備する必要があります。そこでギャビンはパッチを提案し、議論が始まりました。

この制限の変更を避け、ビットコインを拡大するための別の方法に頼ることができると信じることを好む人もいます。こういった人々は典型的には非現実的です。私はそれがうまくいくとは思わないので、その理由をこの投稿で説明します。

最後に、私のことを知らない人のために、私の経歴を簡単に説明します。私は過去 5 年間、Bitcoin ウォレットの実装に取り​​組んできました。その前は、Google で 8 年近く働いていました。私はそのうちの 3 年間を、世界で最も忙しい Web サイトの 1 つである地理グループ (マップ/地球) で過ごし、そこでプロのキャパシティ プランナーとして働いていました。現状では、キャパシティプランニングには長い時間がかかります。 Google の世界では、マシンを物理的に構築し、データセンターを物理的に構築する必要があるためです。ビットコインの世界では、人々がアップグレードするのに時間がかかるからです。ですから、私は現在の苦境について多くの経験を持っています。

ライトニングネットワーク

ライトニングネットワークとは何ですか?これは、支払いチャネルを使用して、信頼性の低いさまざまな仲介者間で支払いを送信するという古いアイデアの最新の名前です。支払いチャネルは、本質的には、ブロックチェーン技術の上に構築されたビットコインのプールであり、ビットコイン ブロックチェーン ネットワークの外部にメッセージを渡すことができます。しかし、最終的な決済はビットコインチェーン上で行われる必要があります。ビットコイン プロトコルには、信頼性の低い方法で支払いを可能にするために使用できるさまざまな機能があります。

この技術の最初の主な使用例はマイクロペイメントです。支払いは 2 人の間でのみ行われるため、支払い情報はビットコイン チェーンよりも高速かつ安価に送信できます。初期の観察では、これによりクライアント/サーバー間およびサーバー/サーバー間の信頼性の低い高速支払いが可能になることが示されました。事実上、決済ネットワークはこのブロックチェーン上で実行され、いつでも決済レイヤー決済を実行できるようになります。

このような決済ネットワークは他のネットワークよりも優れているはずです。なぜなら、この方法でのみ、このブロックチェーン（翻訳者注：ライトニングネットワークなどを指します）上の支払いが正直であることが保証されるからです。理論的には、ビットコイン ブロックチェーン上で確認する必要があるのは送信された合計金額のみであるため、ビットコイン自体よりも多くのトランザクションを処理できます。

それはすばらしい魅力的なアイデアです。ライトニングネットワークの開発者たちが注目を集めている一方で、そのアイデアは既にスウェーデンの企業「StrawPay」によって実装されているほど魅力的です。

StrawPay は Stroem (実際は STRöM ですが、入力方法や発音方法がわからない人が多いです) と呼ばれるプロトコルを設計しました。ウォレット、ハブ、取引所を定義し、それらの間の支払いチャネルを設定します。彼らはまた、実際にユーザーフレンドリーになるように、実際にクロスプラットフォームの GUI ウォレットを実装しました。

Stroem プロトコルは Lightning Network と同じではありません。技術的な詳細がいくつか異なり、特に Stroem は現在の Bitcoin プロトコルで動作し、Lightning Network が受け入れない警告を受け入れます。 Stroem は、後方互換性のある方法で実際にこのような支払いを行う方法など、他のすべての Lightning Network プロトコルが無視する詳細を指定します (これらのスキームでは Bitcoin アドレスは使用できません)。

私はStrawPayの人たちが好きで、彼らの成功を祈っています。 Stroem はマイクロペイメントのルーティングをより速く、より簡単にできる大きな可能性を秘めていると思います。ビットコインのエコシステムの中で居場所を見つける可能性は高いです。しかし、その使用は必須ではありません。

このスケーリングのアプローチがあまり効果的でない理由はいくつかあります。

まず、実装の複雑さにより分散化が損なわれます。

複雑さは初心者を排除する

問題に気づき、うまくいっている側面を無視するのは人間の性です。結局のところ、賞賛できる点には限りがあるのです。そのため、ビットコインのユーザーは、マイニング、トランザクション、支払い処理などを重視する傾向があります。私たちは成功を振り返る時間を取ることはめったになく、ウォレット市場は分散化にとって大きな成功です。

現在、支払いを実装するために数十種類の異なる基本アルゴリズムを使用する、おそらく何百種類もの異なるウォレット支払い方法があります。明らかに優勢な単一のウォレット決済方法はありません。彼らはダイナミックな市場でユーザー獲得を競っています。これは非常に重要です。ウォレット支払い方法が 1 つまたは 2 つしかない場合、これらのウォレット支払い方法がウォレット支払いシステムのコントローラーになり、さらに悪いことに、ビットコインのルールを気まぐれに変更する可能性があります。人々はウォレットの支払い方法を通じてのみブロックチェーンをほぼ独占的に使用するため、ブロックチェーンは無関係になります。

ウォレット決済方法の設定は決して簡単ではありません。私はそのことをよく知っています。過去 5 年間、多くの Bitcoin アプリケーションやサービスの中心となる再利用可能な「ウォレット エンジン」である bitcoinj を書いてきました。しかし、強力なチームなしでも、空き時間に bitcoinj を書くことは可能です。これを、大企業でしか実現できない HTML5 と比較してください。ビットコインのプロトコルは見た目ほど単純ではありませんが、十分に単純です。このシンプルさが、現在使用されているウォレット決済方法の多様性の鍵となっています。

残念ながら、支払いチャネルは単純ではありません。特に、Lightning Network で提案されている機能のような、より高度な支払いチャネルを導入すると、結果として、より大きく複雑なコード ブロックが生まれます。支払いチャネルのおもちゃのような実装を行っている人もいますが、実際に製品レベルの品質で実装しているのは bitcoinj だけです。おもちゃは、ドキュメント作成、ディスクへの状態のシリアル化、ユニット テスト、ユーザー インターフェイスの統合、エラー管理などの問題について心配する必要がありません。おもちゃと本物との違いは、オタクでない人に渡してアプリケーションに使用できるかどうかです。

Bitcoinj の支払いチャネルは、ダウンロードしたファイルの 1000 語ごとに支払いができる PayFile、WiFi マイクロペイメント用のさまざまな Android プロトタイプ、そして StrawPay 自体の作成に使用できます。 StrawPay の実装全体はこれに基づいて構築されており、bitcoinj と GUI ウォレットは MultiBit HD からフォークしたものです。したがって、このコードが機能することがわかります。つまり、私たちがどれだけの努力を注いだかもわかっているということです。幸いなことに、この作業の多くは企業の資金によって賄われました。

ご想像のとおり、来年の夏から全員が決済チャネルで支払いを完了するよう強制されると思うと、とてもうれしく思います。多くの開発者は、bitcoinj/StrawPay がすぐに自分のコードを置き換え、より多くのユーザーを獲得できるだろうと結論付けました。しかし、私は人々が私のコードを急いで使うように強制されることを望んでいません。それは私にとって開発サポートの大きな頭痛の種となり、たとえ bitcoinj をフォークするのは簡単だとしても、分散化が打撃を受けるのは見たくないのです。さらに、開発者は私のソフトウェアの使用を「強制」されることを好みませんし、私もそれを望んでいません。

したがって、ウォレットの設計が難しくなれば、ウォレットによる支払い方法が減ると考えるのが妥当です。 StrawPayの開発者はこう語った。

ウォレットが使用する Java で書かれたライブラリはありますが、まだ開発中です。 iOS をサポートするウォレットはまだありません (私の知る限り、支払いチャネルの実装すらありません)。

ウォレット開発者にとっては、たとえ開発者がライブラリを習得していたとしても、ウォレットが機能する前にライブラリ内で解決すべき GUI 作業や一般的な問題が数多くあります。

いずれにせよ、ゲーム業界が進化するにつれて、ウォレット市場は少数のエンジンを中心に統合される可能性が高いでしょう。しかし、この傾向を加速させる必要はありません。これらすべては存在しない問題を解決するものなので、これは必要ありません。ビットコインのコアテクノロジーは、外部からの支援なしにトランザクション容量を拡大できます。

新人が脱落する例

Lightning Network のホワイトペーパーより:

取引情報を適切なタイミングで伝達しないと、相手方に資金を盗まれる可能性があります。この問題は、指定された第三者に資金を送金してもらうことで軽減できます。出力料金を引き上げ、第三者がネットワークを監視するインセンティブを生み出します。

これは学術的な質問のように思えるかもしれませんが、「メッセージが適切なタイミングで配信されない」問題は、携帯電話のバッテリー切れや信号の弱いエリアへの移動などの一般的な問題によって発生する可能性があります。これは、完全に信頼されていないサードパーティを追加することで解決できますが、これにより複雑さの問題が再び発生します。

他の方法では実現できない非常に高速なマイクロ課金などの特殊なケースでは、そのようなことに我慢するしかありません。できればそれを避けるべきです。

別の例:

一方がデータを失うと、もう一方が資金を盗む可能性があります。

別の…

送信者と受信者に対する[ハッカーへの]脅威を軽減する方法はあるかもしれませんが、中間ノードはオンラインであり、トランザクションを自動的に処理する必要がある可能性があります。そのため、中間ノードが危険にさらされる可能性があるため、この「ホットウォレット」に多額の資金を残さないでください。

手数料が低いため、セキュリティが優れた中間ノードは他の中間ノードよりもパフォーマンスが優れ、長期的にはより大きな取引量を実行します。歴史的に、手数料/利益の最大の要素の 1 つは、さまざまな形態のカウンターパーティ リスクであり、ビットコイン手数料の最大の要素はセキュリティ リスク プレミアムから発生すると考えられます。

ハブアンドスポーク型の支払いチャネル ネットワークには、常にオンラインで機密性の高い署名キーを持つサーバーが必要です。これは、送信者のみが署名する必要があり、すべての署名をオフラインで行うのが一般的である通常のビットコインの使用法とはまったく異なります。これにより複雑さが増し、コストも増加します。

ビットコインノードはハブよりも簡単

ビットコインのスケーリングに関する一般的な不満は、フルノードの実行が難しくなることです。このような不満を持つ人々は、解決策として支払いチャネルを指摘しますが、切り替えは別のノードを介してフルノードを実行する方が簡単であること、つまり構築して実行するのがはるかに難しいことを無視しています。

主な理由は、支払いチャネル ネットワーク ハブはステートフルであるため、稼働時間が長く、信頼性が高く、バックアップが機能していることを確認する必要があるためです。対照的に、ビットコインのノードはほぼ完全にステートレスであり、P2P ネットワークにアクセスするすべてのソフトウェアは、突然消えたノードから回復する方法を知っています。これは常に発生しており、ユーザーにとっては透過的です。

これにより、フルノードの実行が簡単かつ安全になります。安価な 10 ドルの VPS がダウンして再起動しても、誰も気づかず、苦情も言いません。大量のデータが失われた場合は、ノードを再インストールすると、必要なすべてのデータが最初から再計算されます。ハッキングされても盗まれるものはありません。決済チャネルハブでは、これらのことを実際に実現することはできません。

高いパフォーマンスリスク

StrawPay では、チャネル リンクがハブに送信され、ハブがハブに送信され、ハブが受信者に送信されるという、直感的に想像できるような設計は使用されません。その後、ハブは受取人に対して約束手形を発行します。デザイナーのコメント:

この質問を待っていました。これはおそらく私たちが行った議論の中で最も長いものだった。理由は次のとおりです。

1) セキュリティ: 支払いチャネル サーバーを稼働させ続けることは複雑な問題です。安全でなければなりません。ほとんどの商人はこの知識を持っていないため、ウォレットがハッキングされる可能性があります。私たちがデザインした受領書は、商人以外なら誰でも使用できるので、盗んでも意味がありません。

2) パフォーマンス: ハブ ネットワーク内のハブからハブへの小規模なトランザクションが十分な速度で進行しないのではないかと懸念しています。販売者に受領書を保留させるよりも、消費者が支払ったことを販売者にできるだけ早く伝える方がよいでしょう。

これは非常に難しい選択です。

セキュリティについてはすでに説明したので、これは驚くことではありません。しかし、パフォーマンスに関しては、満足できないかもしれません。心配しないでください。支払いチャネル プロトコルには、メッセージの往復や署名/検証の作成が多数含まれます。これらのステップは個別には遅くなく、ミリ秒単位で測定されます。しかし、各ステップに 200 ミリ秒かかり、そのステップが 10 個ある場合、一度に支払いを行うと、少し遅くなります。

ビットコインの取引をネットワーク経由で渡すのも高速ではありませんが、少なくとも最適化の余地は十分にあります。ローカルトランザクションの検証は非常に高速ですが、伝播遅延の問題は重大です。ハブ/スポーク ネットワークを介した支払いはグラフ追跡であり、非常に異なります。

これに関する正しい説明は、非接触型 EMV 仕様では支払い時間が 500 ミリ秒未満であることが要求されているということです。この時間には、スマート カードの起動、ワイヤレス リンクの確立、ECDSA 署名の実装と支払いの承認、および端末の検証に必要な時間が含まれます。各サーバー要求のオンライン認証遅延タイムアウトはわずか 200 ミリ秒です。ロンドンの地下鉄網のいくつかの駅では、乗客が3秒以内にドアを通過することが求められています。したがって、パフォーマンスが重要です。

おそらく、StrawPay の人たちは保守的すぎるのでしょう。重要なのは、誰もそのようなネットワークを設定して展開しようとしていないので、まだ誰も知らないということです。その結果、多くの重要な疑問が未解決のまま残ります。

時間がありません

上記の問題をすべて無視して、支払いチャネル ネットワークが今日の支払いを行う最良の方法であると仮定しましょう。遅くとも来年の半ばまでには解決策が見つかり、提案されたネットワークはまだ存在していないので、問題にはなりません。

簡単に言えば、時間が足りないのです。誰もがすでに十分に理解し、実装している既存システムの支払い能力を単純に高める以外に、今後 12 か月以内に広く採用される確実な技術的ソリューションは存在しません。

小額の支払いを高速にルーティングするためのStroem/Lightningのアイデアが気に入っています。小額の支払いを直接送受信するための支払いチャネルのアイデアが気に入っています。いつか私たち全員がこれらのシステムをサポートするウォレットを使用するようになるかもしれません。しかし、これらのことについて話すことは、現在の問題を解決する上で意味がありません。

ビットコインの取引容量を制限しておけば、取引手数料は着実に上昇し、自由市場がすべてを処理するだろうと考える人もいるようです。この見解は正しくありません。次の記事では、この問題に早急に対処しないと実際に何が起こるのかについて書きます。

つづく …