サトシナカモトが、ビットコインの決済スピードを語る

※写真はイメージです

ビットコインを発明し、未だその正体が分かっていないサトシ・ナカモト。そんなサトシが残した約2年間の文章を、小宮自由氏の解説と共に紹介する連載「サトシ・ナカモトが残した言葉～ビットコインの歴史をたどる旅」の第45回。 まずサトシのメールの前に、本連載の元になっている書籍『ビットコイン バイブル：サトシナカモトとは何者か？』の著者フィル・シャンパーニュ氏の解説も掲載する。 ●フィル・シャンパーニュ氏の解説 ここで、サトシは、支払処理会社がビットコインのネットワークを監視し、販売者に関連する取引や矛盾する取引をチェックする、と説明している。ノードが承認するのは最初の取引のみであり、それと矛盾する取引は拒絶するので、販売者の取引を最初に閲覧してもらう必要がある。矛盾する取引が支払処理会社で確認されれば、販売者にこの取引は問題ありと通知される。もちろん、正常な取引が公式に承認されれば、販売者は顧客に弁済したり、販売手続きを進めたりできる。 ●サトシ・ナカモトの投稿 それではサトシの投稿をみていこう。 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ Re：ビットコインのスナック販売機（取引のスピードの問題） サトシ・ナカモト　2010年07月17日　午後10時29分13秒 （注：>> << 部分は、サトシ以外の者の質問を指す） >> 引用：Insti　2010年07月17日　午前02時33分41秒 << >> ビットコインの菓子販売機があったらどんな風になりますか？ << >> 1.販売機に近寄ります。販売機にビットコインを送ります。 << >> 2.？ << >> 3.甘くておいしいお菓子を食べながら去ります（お得！）。　 << >> 取引の確認に一時間も待たなくて大丈夫です。販売機の会社は無料のキャンディーを大量放出しようとは思わないでしょう。 << >> 二番目のステップはどんな感じですか？ << 支払処理会社の方では、十秒以下で十分なチェックを終える迅速な取引の配給を、サービスとして提供できると思います。 ネットワークノードでは、最初に受信した取引のみを承認し、生成途中のブロックに編入します。取引をブロードキャストするときに、それと同じ瞬間に別のノードが二重支払をブロードキャストすると、どちらが先に過半数のノードに伝達できるかの競争になります。わずかでも先にスタートした方が、幾何学的に速くネットワークに行き渡り、大半のノードを獲得できます。 簡単な計算で済む大雑把な例です。 1 0 4 1 16 4 64 16 80% 20% ですので、二重支払をした人が一秒でも待たなければならないとすれば、大きく不利になります。 支払処理会社は多くのノードに接続されています。取引を受け取るとこれをブロードキャストし、それと同時に、二重支払がないかどうかネットワークを監視します。もし支払処理会社が多数のリッスンノード*1 で二重支払を受信すると、この取引には問題があると警告します。二重支払の取引は、受信するリスナー*2 がいないと、あまり広くは行き渡りません*3 。二重支払を行った人はリッスン段階が終わるまで待つ*3 必要がありますが、終わる頃には、支払処理会社のブロードキャスト情報が大半のノードに届いているか、相当広く伝達済みの状態になっているため、二重支払を実行した人には、残りのノードのかなり多くの割合を獲得する望みがなくなります。 後に、別のスレッドでも、スケーラビリティと取引速度の問題に触れている。サトシは上記のスレッドを再度取り上げている。*4 ------ Re：スケーラビリティと取引速度 サトシ・ナカモト　2010年07月29日　午前02時00分38秒 >> 引用：Red　2010年07月22日　午前05時17分28秒 << >> 開発者がスケーラビリティをどう考えているか、知りたいと思っています。例えば、百万の利用者がいて、各利用者が一日当たり五つの取引を行えば、一日当たり500万の取引になり、これは10分当たり約35,000の取引になりますが、システムではこれを処理できますか？ << >> ブロック生成のために、35,000の取引を百万のノード*5 に伝達する点がボトルネックとなりませんか？ この問題も設計上、想定済みですか？ << 現行のシステムでは、利用者全員がネットワークノードになっていて、大規模のスケールを意図した設定になっていません。ちょうど、ユーズネットの利用者全員がそれぞれ、NNTP（ネットワーク・ニュース・トランスファー・プロトコル）サーバーを稼動するのに似ています。設計上は、利用者はあくまでも利用者にすぎないという前提でサポートしています。ノードの稼動による負荷が増えるほど、ノードの数は減っていきます。残った数少ないノードが大規模のサーバーファームになります。残りはクライアント・ノードになって取引の実行のみを行い、ブロック生成には加わりません。 >> 引用：bytemaster　2010年07月28日　午後08時59分42秒 << >> その他の点として、支払の正常性を検証する時間としては、10分は長すぎます。今日のクレジットカードの読み取りと同じぐらい速くないといけません。 << 菓子販売機のスレッドを見て下さい。支払処理会社が実際に支払検証を十秒以下で首尾よく（クレジットカードよりもずっと低い詐欺の確率で）終える手法を概説しています。私を信じられなかったり、説明を理解できないようなら、これ以上説得する時間はありません、すみません。 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 【訳注】 *1 Listen Node ビットコインや他のブロックチェーンネットワークにおいて、トランザクションやブロックの伝播を聞く（受信する）ために存在するノードのこと。これらのノードは、ネットワーク上で送信されるトランザクションや新しく生成されたブロックを監視し、それらを受信することでネットワークの全体的な状態を把握する。 *2 リスナー Lister とは、リッスンノードと同義 *3 先に行われた取引を受け入れたリスナーは、後に行われた二重支払の取引を受け入れないため、必然的に受信するリスナーは先の取引より少なくなる。「リッスン段階が終わるまで待つ」とあるが、実際は前の取引と矛盾する二重支払が受け入れられることは永久にないため、「永遠に待つ」つまり二重支払が受け入れられる余地はないということを言っている。 *4 これは Phil 氏の発言。 *5 直後にサトシが指摘しているように、百万の利用者が用いてるノードのほとんどはクライアントノード（取引のみを行うノード。スマホウォレットなどが典型的）と想定されるため、ブロックの生成（マイニング）は行わない。これらはリッスンノードでもないため、取引を伝達する対象にもならない。 ●解説 「ビットコインは支払いの検証が10分（場合によっては60分）かかるので実用的ではない」という意見は、よくある勘違いです。低速でないインターネット回線を通じて適切な設計をしていれば、実際には取引は10秒もあれば覆すのが極めて難しいレベルで取引は伝搬します。「検証が10分かかる」というのは、間違いを恐れずにわかりやすく表現すれば「99.99% を100%にする」行為であり、実際には10分よりかなり前に取引は事実上確定しているのです。 数多くの悪意のあるノードが結託すれば、後の二重支払取引を優先的に取り込むことは理論上可能ですが、そのためには数多くのノードを買収するか所有しなければならず、膨大なコストがかかります。自動販売機レベルの少額でそれを行う経済的合理性はありません。 逆に言うと、例えば100億円の不動産取引のような高額取引においては、長時間待った方が無難だということです。その場合でも60分も待てば十分であり、これは100億円の取引の安全のために費やす時間としては全く長くないでしょう。 小宮自由