未来を予想し、サトシがプログラムしていたビットコインの設計
ビットコインを発明し、未だその正体が分かっていないサトシ・ナカモト。そんなサトシが残した約2年間の文章を、小宮自由氏の解説と共に紹介する連載「サトシ・ナカモトが残した言葉〜ビットコインの歴史をたどる旅」の第39回。
まずサトシのメールの前に、本連載の元になっている書籍『ビットコイン バイブル：サトシナカモトとは何者か？』の著者フィル・シャンパーニュ氏の解説も掲載する。
フィル・シャンパーニュ氏の解説
この投稿は本書に収録した他の投稿よりもややテクニカルな内容になっている。それでもこれを選んで収録したのは、サトシによる中核的な設計の最初の実装が将来の重大な修正を回避するために、多様なタイプの取引をサポートしていたことを説明するのに役立つためである。
サトシ・ナカモトの投稿
それではサトシの投稿をみていこう。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Re：取引とスクリプト：DUP HASH160…EQUALVERIFY CHECKSIG
サトシ・ナカモト 2010年06月17日 午後06時46分08秒
（注：斜体部分は、サトシ以外の者の質問を指す）
引用：Gavin Andresen 2010年06月17日 午前11時38分31秒
ですので、ビットコインの動作を厳密に理解したいので、ビットコインのwallet.datを解析できるちょっとしたツールを書いています。
取引の出力を見ると、値段（ビットコインの数）が含まれているのが分かりますし、ビットコインにはちょっとForthに似たスクリプト言語が内蔵されていますが、そのスクリプト言語で稼働するバイト数が書かれているのが分かります。例えば、[‘TxOut: value: 100.00 Script: DUP HASH160 6fad…ab90 EQUALVERIFY CHECKSIG’]です。
まず最初に、私は、ビットコインにスクリプト言語が内蔵されていることに少し神経質になっています。本当に単純なスクリプト言語なんですけど（ループやポインターがなく、数学と暗号以外は使われていません）。神経質になるのは、この言語は複雑なものであり、複雑さが安全性の敵だからです*1。また、スクリプト言語の存在により、互換性のある第二の実装の作成も困難になっています*2。でも、それは乗り越えることができると思います。
コードを見ると、新しい取引の検証にはインタプリタのスタックに署名と公開鍵をプッシュし、TxOutスクリプトを稼働します（正しく理解できていますか？）。
有効なスクリプトを持つ取引を作成するコードをTxOutに書けますか？例えば、誰でも使えるコインを作るのに、「OP_2DROP OP_ TRUE・・・」のスクリプト*3でTxOutを作れますか？
このようなコードになっているのは、生成コインのタイプに柔軟性を持たせるためですか？
ビットコインの特徴は、バージョン0.1のリリース後は、設計の中核部分が残りの存続年数を見越して変更不可能*4とされている点です。そのため、想定される全てのタイプの取引をサポートできる設計にしたかったのです。問題は、個別のケースにはそれぞれの特殊なサポートコードが必要な点、使うかどうかに関係なくデータフィールドが必要な点、一度に一つの特殊ケースしかカバーできない点でした。これでは特殊ケースの爆発的増加になってしまいます。その解決にはスクリプトが必要で、それは、取引の当事者が、ノード・ネットワークによって評価される叙述関数として取引を説明できるよう、問題点を一般化したスクリプトでした。ノードに必要な作業は、送金人の条件が満たされているかどうかの評価に応じて取引を理解することのみです。
実際、スクリプトは叙述関数です。真偽を評価する方程式にすぎません。「叙述関数（predicate）」は長くて馴染みの薄い言葉なので私は「スクリプト（script）」と呼びました。
支払の受取人はスクリプトのテンプレートを照合します。現行では、受取人が承認するテンプレートは二つのみです。直接の支払とビットコインアドレスです。将来のバージョンでは、取引タイプのテンプレートを増やせますし、それを受け取れるのはそれ以降のバージョンを稼働するノードです。たとえその読み方を知らなくても、ネットワーク内の全てのバージョンのノードが新たな取引を検証し、ブロックへの編入を進めることができます。
設計では、私が数年前に設計したおびただしい数の取引タイプのバリエーションをサポートしています。エスクロー取引、履行保証契約、第三者の仲裁、複数の当事者の署名、など。将来、ビットコインが大規模に流行るようになれば、私たちはこれを開拓したくなるでしょう。しかし、後々確実に利用できるように、最初に全てを設計しておく必要がありました。
互換性のある第二のビットコイン・バージョン*5の実装が良い考えだとは思いません。設計の多くは、全てのノードがロックステップで精密に同一の結果を得ることに依存しているので、第二のバージョンの実装はネットワークへの脅威になります。MITライセンスは他の全てのライセンスや商用利用と互換性があるので、ライセンスの観点からは書き換えの必要はありません。
第二のバージョンは巨大な発展となり、私にはメンテナンスの手間になります。第二のバージョンをロックインせずに、ネットワークをアップグレードしながら後方互換性を維持するのは困難です。第二のバージョンが失敗に終われば、利用者の体験はどちらのバージョンに対しても悪い印象になりますが、少なくとも利用者にしてみれば、公式バージョンにとどまる大切さを再認識するでしょう。誰かが第二のバージョンをフォークしようとすれば、多くの免責宣言を出して少数派バージョンの利用によるリスクを周知しなければなりません。これは、意見の不一致があったときに多数派バージョンが勝つ設計で、こうなると、少数派バージョンにはかなり醜悪な事態となり、私はそこには参加したくありませんし、バージョンが一つのみである限りは参加の必要もありません。
大半の開発者は自分のソフトウェアがフォークされるのは嫌なことはよく知ってますが、このケースでは真にテクニカルな理由があります。
引用：gavinandresen 2010年06月17日 午後07時58分14秒
取引内スクリプトの仕組みの柔軟性は賞賛しますが、私の邪悪で狭量な頭はすぐに悪用の方法はないかと考え始めます。TxOutスクリプトにはあらゆる種類の興味深い情報を暗号化できますし、もし、ハッキングされていないクライアントがこの取引を有効化し、すぐ無視すれば、密かに使える有益な同報チャンネルになります。
それはクールな機能です。これはすぐにポピュラーになり、支払ネットワークを数百万の取引であふれさせ、最新のレディーガガのビデオを友人全員に送ったら愉快だと誰かが気づくでしょう*6。
それが取引手数料を導入する理由の一つです。必要なら他のこともできます。
引用：laszlo 2010年06月17日 午後06時50分31秒
どのくらい長くこの設計の作業をしていましたか、サトシ？とてもよく考え抜かれていると思います。最初に頭脳の突き合わせや議論をせずにただ座ってコード作成をしただけのものではないです。みんなあら探しをして見え透いた質問をしてきますが、よく持ちこたえています: – )
2007年からです。ある時点から、これが信用抜きでできると確信するようになり、考察を進めずにはいられなくなりました。作業はコーディングよりも設計の方が多かったです。*7
幸い、出てきた問題点は全て、私が事前に考えて計画していたものばかりでした。*7
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
【訳注】
*1 スクリプト言語のバグがセキュリティホールとなりうるから。
*2 プログラミング言語の実装は基本的に複雑であって、同一の挙動を別の実装で実現するのは一般に困難である。
*3 「スクリプトのスタックから2つのデータを削除し(drop は popと同じ。pop という表現もスタックからデータを削除する際によく使われる)、1 をデータに追加する(push)というスクリプト。スタックの概念は以下に詳しい。https://ja.wikipedia.org/wiki/%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF
*4 中核部分以外のみを修正し新しいバージョンをリリースすることをソフトフォーク、中核部分を含む修正をし新しいバージョンをリリースすることをハードフォークという。両者の違いは以下に詳しい。https://coinpost.jp/?p=3143
*5 ここで言う第二のビットコイン・バージョンとは、主に別の言語によるビットコインの実装が想定されており、ビットコインキャッシュのようなハードフォークしたブロックチェーンを指しているのではない。
*6 ビットコインネットワークを海賊版データの配信に使うという意味。サトシは直後に取引手数料が膨大になるため(取引1つごとに送信できるデータ量は小さい)それはできないと指摘している。
*7 これらは原文では laszlo の発言とされているが、誤記と考えて訳文では修正した。
解説
フィル・シャンパーニュ氏が最初に述べているように、この記事はかなり技術よりの内容であり、プログラミングの知識がなければ完全な理解は難しいでしょう。要点を絞って説明します。
ビットコインは様々な取引を効率よく実現するために、様々な命令を柔軟に記述できるプログラミング言語を内部に実装しました。しかし他の人はそれがセキュリティホールにならないかどうかの懸念を示します。サトシは十分に考えられて設計されているから問題ないと述べました。
実際にビットコインネットワークは2024年1月現在破綻していないので、これは正しかったという意見を持つ人も少なくないでしょうが、設計の妥当性に関しては以前から根強い異論があります。ビットコインには、トランザクション展性やスケーラビリティの低さを代表とした問題点がいくつかあり、これはサトシ・ナカモトの初期の設定に起因する、つまり設計上の問題だと言われることがあります。トランザクション展性は Segwit で解決しましたが、スケーラビリティ問題はSegwit でも根本的な解決に至らず、Lightning Network というレイヤー2技術(全く別のブロックチェーンを作ってそれとデータを相互にやり取りする方式)で解決を試みています。これは技術的に相当複雑な試みです。イーサリアムのLayer2ブロックチェーンがリリースされたのはビットコインよりずっと後ですが、普及はイーサリアムLayer2 の方が圧倒的に早いのは、ビットコインLayer2 エコシステムが過度に複雑なことに起因しているのは間違いないでしょう。
良くも悪くもサトシ・ナカモトの評価はまだ定まっていないと言えます。
小宮自由