Bitcoin Unlimited開発者アンドリュー・ストーン氏へのインタビュー

ジェイミー・レッドマン – 2016年11月25日

最近、Bitcoin.com は、競合する Bitcoin クライアントと現在のブロックサイズに関する議論について、Bitcoin Unlimited (BU) 開発者の Andrew Stone 氏に話を聞きました。暗号通貨コミュニティでは、BU の開発者は誰なのか、開発者になるための資格は何かと質問されています。このインタビューは、BU の開発について知ってもらうためのものであり、BU チームは開発チームの目標を達成するために最善を尽くします。

Bitcoin Unlimited 開発者 Andrew Stone との詳細なディスカッション

Bitcoin.com: BU について、また BU がスケーラビリティをどのように解決するかについて、読者に簡単に紹介していただけますか?

Andrew Stone (AS): BU は、Nakamoto Consensus (作業証明) が唯一の信頼できるコンセンサスメカニズムであると認識しており、Core のブロックサイズが 1 MB であることは単なる「社会的コンセンサス」です。 BU は、ビットコインが分岐した場合、この分岐がビットコインの通貨機能を保証しない限り、ユーザーは小さな分岐チェーンに興味を持たないだろうと考えています。

「短期的には、BU はマイナーが 1MB を超えるブロックを採掘できるようにすることでスケーラビリティの問題を解決します。中長期的には、BU はLightning Network やその他のオフチェーン技術をサポートします。ビットコインの開発に最適な技術はどれか、市場に決めてもらいましょう。」

BC: BUプロジェクトに参加するようになったきっかけは何ですか? BUチームの開発者は他に誰ですか?

AS:BU のアイデアの多くは、ビットコインフォーラムの「金の崩壊、ビットコインの上昇」という投稿での議論から生まれたものです。その間、フォーラムでアイデアを提案したすべての人は称賛に値し、感謝されるべきです。私も当時の議論に参加しており、フォーラムで「エマージェント・コンセンサス」アルゴリズムを提案しました (当時はそう呼んでいませんでした)。その後、私は BU 共同憲章 (私たちの憲章) を作成し、クライアントの初期バージョンをリリースしました。その瞬間、私は本質的に慈悲深い独裁者でした。その後、私はBU憲章に定められた選挙に参加し、勝者に与えられるべき権利を付与されました。

Peter Tschipper 氏と Andrea Suisani 氏は初期の開発者であり、BU の開発の初期段階で洞察力と分析力で BU に多大な貢献をした Peter Rizun 氏にも特に言及したいと思います。

BU は 2 つのマイニングプールに採用されました。新しい貢献者がたくさんいるので、ここで全員をリストすることはしません。

BC: Bitcorn Core開発者がBUのような競合クライアントに反対するのはなぜだと思いますか?

AS: 特定の人が競合するクライアントに反対する理由がわかりません。しかし、ほとんどの人が競合クライアントに反対する理由を私は挙げることができます。

まず、もっと早くてシンプルな時代を願うかもしれません。たとえば、2012 年、ビットコインの市場価値は 5,000 万ドルでした。単一クライアント環境では、特にそのクライアントを担当している場合は、いくつかのことがより簡単になります。しかし、そんな時代は終わりました。状況は今さらに悪化しています。当社には、Nakamoto クライアントの P2P プロトコル、ファイバーネットワークブロードキャストプロトコル、Falcon ネットワークなど、複数のプロトコルがあります。マイニング機器は、「Stratum」と呼ばれる独自のカスタマイズされたプロトコルを使用します。多様性により、ビットコインネットワークはより堅牢になり、1 つのクライアントのエラーがネットワーク全体を危険にさらすことがなくなります。

2 点目は、自分の本当のニーズ (より大きなブロック) を正当化できない場合、競合他社を批判する方が競合他社にとって有益だということです。

3 点目: 人々は「FLP」の結果をあまり理解しておらず、特定の業界のプロトコルについて合意に達するためにすべての開発者が「集まって」下した決定に過ぎないと考えていました。 (翻訳者注: FLP とは、「非同期通信シナリオでは、到着の一貫性を保証するアルゴリズムがない」という意味です) ただし、メンバーシップと参加資格を厳密に制御しなければ、これは単なる幻想にすぎません。プロトコルには必然的に競合相手や不完全な点が存在します。 USB 識別番号の割り当てが良い例です。 USB ID を取得するには、USB Alliance に加入する必要があります (会員費は数千ドルかかります)。このモデルは、個人の創造性は非常に高いものの、デバイスの市場が非常に小さいオープンソースハードウェアコミュニティではうまく機能しません。やがて人々は情報は無料であることに気づき、USB ロゴを製品に表示しない限り USB Alliance がそのような制限を合法化することは不可能だったため、人々は任意に選択した識別コードを使い始めました。

代わりに、重要なソフトウェア開発タスクでは、複数の完全な部分を作成し、それらを同時に実行することが「黄金律」となります。これにより、ミッション全体の失敗につながる可能性のあるエラーが発生する可能性が低減されます。

BC: Adam Back氏らが、 BU はセミベータ版であり、 BU開発者は資格がないと言っていることについてどう思いますか?

AS: これらの人々はそのようなコメントをする資格がないので、私はイライラしています。そんなことを言うつもりはなかった。これらの人々は、批判しているコードを一度もレビューしたことがないと私は思います。

明らかに、Core 開発者として働いている人や、Core 開発者を雇用している他の企業は、Bitcorn Core が唯一の主要顧客であり続けることで利益を得るでしょう。したがって、個人と彼らの間には大きな利益相反が生じる可能性があります。ですから、これらのレポートを読む人たちにお願いしたいのですが、彼らが真実かつ信頼できるデータを提供しない限り、誰もが彼らを疑り深く、恐れていて、誤った情報を提供していると非難することしかできません。

Core のコードには重大かつ継続的な (最近追加された) 欠陥があるという Adam の批判に、私はついに応えました。これは開発者のエラーなので、返信するのは非常に気が進みません。プログラミングのバグは、今日でもソフトウェア開発の残念な部分として残っています。ただし、これを行うことで、BU が Core よりもテストされていることを実証できます。 Bitcoin Core のコードと開発者が、Bitcoin ソフトウェアを開発するのに何らかの特別な資格を持っているという神話は、もはや存在しません。実際、ビットコインのコード品質は、私がこれまで見てきた多くのミッションクリティカルなアプリケーションよりも劣っています。

BC:あなたとあなたのチームメンバーがビットコインプロトコルに取り組むのに特別な資格を持っている理由を教えていただけますか?

AS: BU チームの他のメンバーについてはコメントできません (彼らの過去を知らないため)。ただ、個人的に彼らの仕事をレビューし、非常に優れていると感じたとだけ言えます。

私はこれまでのキャリアを通じて、信頼性が高くミッションクリティカルなアプリケーションに取り組んできたため、この種のコード開発には慣れています。私は OpenClovis を使っています。つまり、私のソフトウェアは世界中のほとんどの通信会社で使用されており、多くの通信デバイスに組み込まれています。当社のユーザー統計は OpenClovis ソフトウェアのみに基づくものではなく、実際に当社が利用しているユーザー数に基づいており、ユーザー数は数億人に達すると思われます。韓国で携帯電話をお持ちの方は、私が書いたソフトウェアをお使いです。 Verizon ブランドの携帯電話をお持ちの場合は、私が作成したソフトウェアを使用している可能性が高いです。自宅の電話に内線電話がある場合は、おそらく私が作成したソフトウェアをまだ使用しているでしょう。貴社が SIP ベースの電話機や多数のイーサネットエンタープライズクラスのスイッチを所有している場合でも、弊社のソフトウェアを使用できる可能性があります (貴社が購入したブランドによって異なります)。

BC: 「 Bitcoin Coreの簡単な歴史」と題した最近の記事で、 Coreクライアントで発見されたさまざまな脆弱性について説明しました。 コミュニティはこれらの脆弱性をもっと真剣に受け止めるべきだと思いますか?

AS: そうですね。高可用性業界には、「5,000 年」の脆弱性という概念があります。これらの脆弱性は通常はまれです。ただし、5,000 台のクライアントを実行している場合や、異常な動作条件が発生した場合は、これらのまれな脆弱性が突然頻繁に発生し始める可能性があります。通信業界では、すべてのクラッシュやコアダンプを追跡して考えられる根本原因を見つけ出します。そのためには、何時間もかけて手動でコードを確認したり、条件付きの「強制」コマンドを追加して、通常は外部入力ではトリガーできない特定のコードフローをトリガーしたりする必要があります。 Bitcoin コードでも同様の対策が必要です。

この仕事の目的の一部は、個人が自分の強みを発揮できるようにすることです。実際の証拠もなく調査を拒否したり、「これはデバッグモードでのみ発生します」などの言い訳をしたりするのは、非常に大きな問題です。率直に言って、私の投稿に対する一部の人々の反応は、私の批判よりも Core の開発アプローチについて心配させるはずです。すべてのソフトウェアには脆弱性があるため、私がそのうち 3 つを指摘しただけで、BU がコードベースとテストに責任を持っていることが証明されるはずです。 Core がどれだけ悪いかを言っているのではありません。

しかし、貢献者が私が提起した脆弱性を確認せずに否定した場合、それは問題です。他にはどのような抜け穴が同様に否定されているのでしょうか?最もひどい否定の 1 つは、「（一見無関係な）X、Y、Z のせいで A は起こり得ない」というものです。問題は、この哲学がコードベースに浸透すると、元の作成者またはプロジェクトに長期間関与してきた人物だけが開発および保守できる隠れた依存関係が多数発生してしまうことです。

保護されたデバッグモードで未定義の動作を生成するコードを実行することは、実際に問題になります。開発者がデバッグモードで実行しているためです。脆弱性の 1 つがデバッグモードで問題を引き起こす場合、開発者がその問題を「修正」して、実稼働コードに脆弱性を引き起こす可能性があります。たとえば、ノードクリーンアップコードの周囲にロックがないことが、この状況の考えられる例です。デバッグモードでロックが削除され、dd_mutex がクリーンアップされたためにプログラムが中断された可能性があります (無効なミューテックス)。しかし、ロックを解除すると、(テストで確認したところ) コアダンプが取得され、まれに、接続を閉じた瞬間にピアが接続を切断することがあります。

BC: BU はコアプログラムエラーを改善するために何を行いますか?

AS: 問題を見つけて解決します。もちろん、私たちはこれらのバグの導入を防ぐための独自の開発方法を持っており、これらの種類の問題に対処するためにコードを再構築（そしてできれば基礎をある程度変更）しているところです。

BC: BU がブロックサイズのハード制限を撤廃し、ユーザーがブロックサイズを選択できるようにしたというのは本当ですか? この場合、システムはどのように機能するのでしょうか?

AS: はい、ピーター・リズン氏が「エマージェント・コンセンサス」アルゴリズムについて非常に詳しく説明した論文を書いています。すべてを説明するには記事全体が必要になるので、このファイルだけを紹介します。

私たちはこのアイデアを実証するために理論的かつ分析的な作業も行いました。その内容は、ピーターの「手数料市場」論文と私の「単一トランザクション（空）ブロック」論文に記載されています。私たちの研究は、一言でまとめることができます。「ネットワークの伝播とブロック検証の遅延により、トランザクションコストがゼロではなくなり、平均ブロックサイズが基盤となる物理ネットワークの平均容量に制限されます。」

BC: BUクライアントとBitcoin ClassicおよびXTの違いは何ですか?

AS:BU は、ナカモト合意に基づくアルゴリズムによる「ステークホルダー合意」は実際には不可能であると考えています。たとえば、Classic と XT に対する大きな批判の 1 つは、「マイナーが大きなブロックを誤って通知している場合、いつ拒否すればよいのか」というものです。BU は、この上位レイヤーのコンセンサスが不可能であることを認識しています (より正確には、ナカモトコンセンサスは、これを実現する唯一の既知のアルゴリズムです。ちなみに、理論的な観点からは、実際にコンセンサスに達したことがないため、FLP の結果は回避されます。超技術力を持つエイリアンがジェネシスブロックからブロックチェーンを書き換えた場合、ナカモトコンセンサスはそのチェーンに切り替わります)。そのため、コンセンサスを自動的に変更する調整アルゴリズムは存在しません。

対照的に、BU はコンセンサスレイヤーからほとんどの非金銭的機能保護パラメータを削除します。したがって、ネットワークに大きなブロックが突然現れた場合は、注意を払うことになります。しかし、誰かが他人のお金を使ったり、報酬として自分自身に大きなブロックを与えたりした場合、あなたはそれを拒否するでしょう。

そして、最初の大きなブロックを生成するには、オペレーターの実際の参加が必要です。これにより、他のマイナーが誤ったシグナルを送信した場合（FLP 用語では「障害のあるプロセス」と呼ばれます）、マイナーはすぐに撤退することができます。

BC:最近、ビットコインコミュニティはプロトコル開発に120万ドルの投資を発表しました。この寄付と、寄付に述べられている原則についてどう思いますか?

AS:ビットコイン開発のために開発資金を設立する意思のある人がいるのは、非常に良いことです。これは絶対に正しいことです。営利目的の商業会社が開発を主導する「ブロックストリームモデル」は、通貨としてのビットコインとビットコイン通貨保有者にとって最善の利益ではないようです。

BC: BU チームは Segregated Witness についてどう思いますか?

AS:私はチームを代表して話すことはできませんし、さらに重要なことに、BU チームのメンバーを代表して話すことはできません。私の個人的な意見は次のとおりです。

ブロックチェーンの場合、Segregated Witness はブロックチェーンに不必要な複雑さを追加するだけです。

SegWit が達成できる規模は、ビットコイン上に製品やサービスを構築することに関心を持つ企業にとって十分ではなく、それがもたらす規模はオフチェーンのスケーリング方法のニーズを満たすのにさえ十分ではありません。

SegWit の最終的なサイズは 1.7MB のトランザクションブロックサイズですが、4MB のブロックサイズが必要です (これは、2MB を追加する単純なハードフォークで合計ブロックサイズが 8MB になることを意味しますか? 今日のネットワークでは、2MB は簡単ですが、8MB は「かろうじて」である可能性があります)。 Segregated Witness では、既存の問題 (スケーラビリティなど) がすべて解決されるわけではありません。古いトランザクションは常に生成され、古いトランザクションによって多くの「技術的負債」が生じ、将来的に Bitcoin の維持と拡張が困難になるためです。

しかし、SegWit トランザクションが使用される限り、SegWit は既存の問題のいくつかを解決します。しかし、他の多くの既知の問題は解決されませんでした。 (実際、他の問題や機能も約束されていましたが、最終的には SegWit 実装には組み込まれませんでした)。完全に新しいトランザクション形式により、Segregated Witness が解決するはずだった問題を、はるかにシンプルかつエレガントに解決できる可能性があります。

Segregated Witness では、すべてのウォレットでコードの変更が必要になります。