第8章 · Bitcoin、Ethereum、Solanaはなぜ違うのか
TPS以外に、二つのチェーンをどう比較できるでしょうか?
- 練習する能力
- Protocol LiteracySystem Thinking
- 実践
- 3 本のチェーンについて、ブロック時間、ファイナリティまでの時間、ノード数、ノード運用のハードウェア要件を調べ、表にまとめる。
- AI Lab
- AI に 3 つのチェーンの比較表を作らせ、各項目を公式文書と照合して誤った数字を示す。
現実の問題
ソーシャルメディアで二つの図を見ました。
一つ目は、Aチェーンは毎秒数万件、Bチェーンは十数件しか処理できず、Aの圧勝だと言います。別の人たちが作った二つ目は、Bは十数年安全に動き、一度も破られていないが、Aは何度も止まったと言います。
どちらも本物のデータを使い、結論は正反対です。
現実はさらに戸惑わせます。世界で最大級のオンチェーン資産は、長年、その「遅い」チェーンに置かれてきました。 速ければよいなら、説明がつきません。
初心者は誰もがこの状況に出会います。「どのチェーンがよいか」と尋ねられ、TPSだけで決めるべきではないと分かっていても、何を見るべきか説明できません。
この章で渡すのは答えではなく、問い方です。
思考実験
チェーンの名前をすべて忘れましょう。世界中で共有する記帳室を、ゼロから設計するとします。
ルールを決められますが、調整できるつまみは四つだけです。
- 誰が記帳できるか:誰でもよいのか、選ばれた人だけか?
- 記帳にどの程度の機材が必要か:古いノートパソコンか、専門サーバーと優れた通信回線か?
- いつ記録が有効になるか:書いたらすぐか、全員の確認後か?
- 記録をどこまで複雑にできるか:誰が誰にいくら払ったかだけか、任意のプログラムの実行結果も書けるか?
すぐに、四つが連動していると分かります。
- 機材の要件を上げる → 処理は速くなりますが、買える人が減り、最後は数十の組織だけが記帳するかもしれません。
- 記録の複雑さを上げる → できることは増えても1件に時間がかかり、遅くするか、機材の要件を上げる必要があります。
- 有効になる速さを上げる → 使い勝手はよくなりますが、照合する時間が減り、優れた回線が必要になって遅い人が脱落します。
- 記帳資格を誰にでも開く → 参加を阻止されませんが、最も遅い人たちに合わせる必要があります。
さらに進むと、もっと根本的な問いにぶつかります。「この部屋は安全」とはどういう意味でしょうか?
暗号が解読されていないという意味ではありません。すでに書かれた記録を改ざんするため、攻撃者がどれだけの費用を払うかです。その費用は、記帳参加者がどれだけ資源を投入するかから生まれます。投入が多いほど、履歴の書き換えは高くなります。
したがって五つ目のつまみは、前の四つで決まります。安全のためにどれだけの予算を用意するかです。
四つの調整できるつまみと、それらで決まる結果がそろいました。すべてを同時に最大にできる設定はありません。
あなたが決める
部屋へ入れたい用途が三つあります。それぞれ別の部屋でも、すべて同じ部屋でも構いません。
- 甲:10年間動かさない予定の大きな貯蓄。
- 乙:プレイヤーが毎秒少額の操作を行うゲーム。1件の価値は低い。
- 丙:巨額の資金を管理する貸借ルール。一度の障害で多くの人が損をする。
結果を観察する
四つを並べると、同じことが分かります。
三つの用途すべてに最適な設定はありません。 甲は10年間無事であること、乙は安さと即時性、丙は止まらないこととルールの信頼性を求めます。この三組の要件は衝突します。
「どのチェーンがよいか」という問い自体が適切ではありません。答えられるのは、この用途に対し、どのチェーンの取捨選択が合うかです。
比較の前に、さらに厄介な問題を解決します。同じ言葉でも、チェーンごとに意味が違います。
| 言葉 | 言っているように見えること | 実際に指し得ること |
|---|---|---|
| 毎秒の取引数 | 本当の処理能力 | 理論上限、実験室の値、過去30日の実測中央値のどれか? 単純な送金と複雑なコントラクト呼び出しを同じ1件に数えるか? |
| 承認時間 | お金が届くまでの時間 | ブロックに入るまでか、もう巻き戻らなくなるまでか? 差が数秒のチェーンも、数十分のチェーンもある |
| ノード数 | 維持する人の数 | データをダウンロードできる全ノードか、実際にブロック生成や投票を行うノードか? 桁が違うことが多い |
| 分散性 | 点数で表せる指標 | 少なくとも、ブロック生成者、プロトコル変更者、ノード運用者、その分布という四つのこと |
この表が最も実用的な部分です。定義をそろえるまでは、チェーン間の比較は成立しません。
冒頭の図が本物のデータから反対の結論を出した理由もこれです。それぞれ有利な定義を選び、しかも明記していません。
モデルを作る
ランキングを六つの軸に置き換えます。各軸で、何を尋ねるかと、上げる代償は何かを考えます。
| 軸 | 尋ねること | 上げる代償 |
|---|---|---|
| 安全性 | 承認済み記録を書き換える費用はいくらか? 予算はどこから来るか? | 実際の投入が継続して必要で、最後は手数料かトークン追加発行で支払う |
| 実行能力 | どれほど複雑なルールを表せ、単位時間にどれほど動かせるか? | 複雑で速いほど、機材と回線の要件が高まる |
| 状態 | 長期保存データの量と成長速度は? 誰が保存費用を払うか? | 大きいほど新規参加が難しくなり、長期には分散性を弱める |
| 遅延 | 送信からブロックに入るまで、そこから巻き戻らなくなるまで何秒か? | 低遅延を求めると検証と伝播の余裕が減り、回線品質の要件が上がる |
| 分散性 | 誰がブロックを作り、ルールを変えるか? 生成者とノードはどこにいるか? | 多く広く分散するほど調整が遅く、性能の上限が下がる |
| 機材の敷居 | フルノードに必要な構成は? 普通の人が動かせるか? | 低いほど能力の上限も低く、高いほど少数の人が運命を握る |
六つ目を強調します。機材の敷居は、前の五つの現実的な制約です。最も見落とされやすい項目でもあります。専門のデータセンターだけが検証できるなら、誰でも独立して照合できるという言葉は実際には成り立ちません。それこそが第3章の核心的な価値でした。
六つを結ぶ手順も示します。
- まず用途を尋ねる
- 用途に応じて六つの軸に優先順位を付ける
- 定義をそろえる
- 各項目のデータを取り、時点を記録する
- 判断と不確かな点を書く
分散性、安全性、拡張性をすべて得られないという「ブロックチェーンのトリレンマ」を聞いたことがあるでしょう。間違いではありませんが、粗すぎます。三つのうち二つは複合概念で、直接比較できません。六つの軸なら、どれも調べられる具体的なデータに対応します。
持ち帰ってほしい判断基準です。
チェーンの違いは、ランキングではなく取捨選択の組み合わせです。
ある軸で劣るのは、通常、別の軸へ予算を使ったからです。順位を覚えるより、何を得たか尋ねる方が役立ちます。
何と呼ぶか
チェーンにおける安全性は、承認済み履歴を書き換える費用です。コードに欠陥がないという意味ではありません。
守る人が投入する資源の量と、その分散度で決まります。前者は攻撃費用を決め、後者は少数を買収して費用を回避できるか決めます。
安全予算は手数料という実収入か、トークン追加発行から来ます。追加発行で維持する安全は、実質的に保有者が支払っています。
ルールに従って新しい状態を計算する能力です。表現できる論理の複雑さと、単位時間の処理量を指します。
比べる前に必ず定義を尋ねます。理論最大値、負荷試験の値、継続的な実測中央値のどれですか? 桁が違うこともあり、公に広まるのは最初の値であることが多いのです。
チェーンが現在保持し、全バリデーターが参照できる必要のある全データです。各アドレスの残高、各コントラクトの保存内容などです。
履歴とは違います。履歴はアーカイブできますが、状態は常に読めなければなりません。 増え続けると新規参加の敷居が上がります。数年かけて現れる慢性的な問題で、一度現れると逆転が難しくなります。
取引を送ってから有効になるまでの時間です。
少なくとも、ブロックに入る時間と、ファイナリティに達する時間に分けます。後者はブロックがもう巻き戻らなくなるまでです。第6章で学んだように、一瞬ではなく徐々に強まる確率です。
二つが近いチェーンも、遠いチェーンもあります。最初の数字しか示さない比較表は、参考程度にしてください。
一つの数字ではありません。誰がブロックを作れるか、誰がプロトコルを変えられるか、誰が独立したノードを動かすか、地理と法域でどう分布するか、最低四つに分けます。
最初は分散していても、二つ目は少数の中核開発者と財団に集中している場合があります。非常によくあるのに、比較表にはほとんど出ません。
分散性自体が目的ではありません。誰も記録を変えられないという言葉を本当に成立させるためのものです。第9章でコントラクト層の同じ問題を扱います。
実践
ステージの最初の成果物です。既存の比較表を写さないでください。導入でも注意した通り、広く出回る数字のかなりの部分は誤りか古いものです。
チェーンを三つ選びます。 安全と単純さを優先するもの、プログラム可能性を優先するもの、低遅延を優先するものなど、取捨選択が明確に異なる三つがおすすめです。
先に定義を書き、それからデータを取ります。 表の上に四つの定義を明記してください。
- ブロック生成時間は目標値か、最近の実測中央値か?
- ファイナリティはどの承認基準か?
- ノード数はどの種類を数え、どのページを使うか?
- 機材要件は公式推奨構成か、最低構成か?
表を埋めるより大切な段階です。 明記しなければ、ネット上の図と変わりません。
項目ごとに取得し、出典リンクと確認時刻を記録します。
| チェーンA | チェーンB | チェーンC | |
|---|---|---|---|
| ブロック生成時間 | |||
| ファイナリティ到達時間 | |||
| ブロック生成・投票に参加するノード数 | |||
| 独立して検証できるノード数 | |||
| 公式推奨の機材構成 | |||
| 過去の停止の有無 | |||
| プロトコル更新を決める人 |
最後の二行は大半の比較表になく、前の項目以上に多くを示すことがあります。
見つからない欄に印を付けます。 公式が提供しないデータや、曖昧な説明しかないデータもあります。
見つからなければ「未発見」と書き、他人の二次情報で埋めないでください。 空欄自体が発見です。チェーンがどこで透明性に欠けるか示します。
三つの判断を書きます。 表を使って答えてください。
- 各チェーンはどの軸に予算を使っていますか?
- 10年間動かさない資産なら、どれを選び、なぜですか?
- 高頻度の少額アプリなら、どれを選び、なぜですか?
表を保存してください。3か月後に再取得すると、変わる数字と変わらない数字が直感的に分かります。 この比較自体が、本章の最も価値ある収穫です。
AI Lab
まずAIにやらせます。
三つのブロックチェーンを比較し、次の項目を含む表を作ってください。
- ブロック生成時間(目標値か実測中央値か明記)
- ファイナリティ到達時間(承認基準を明記)
- ブロック生成または投票に参加するノード数
- 独立して検証を行えるノード数
- フルノード運用の公式推奨機材構成
- 過去の停止や再編の事例
- プロトコル更新の意思決定手順と決定者
ルール:
1. すべての数字に出典リンクとデータの日付を添える
2. 見つからない項目は「未発見」と書き、推定や常識で補わない
3. 出典間で数字が食い違えば列挙し、自分で一つを選ばない次に本当の作業です。すべてのリンクを開き、各項目を照合します。
二つ目の表に、公式文書で確認できた数、数字は合っても時点が違う数、開けないリンクの数、もっともらしい数字を作った数を記録します。
モデルを困らせるためではありません。この種類の問いで、出力のどこを直接使え、どこを自分で調べる必要があるか、調整された直感を作ります。
特に起こりやすい誤りは、理論最大値を実際の処理量にする、ブロックに入ることをファイナリティにする、書式は正しいが存在しない文書リンクを示すことです。
第1章からモデルのよくある誤りを記録していれば、この章で数項目増えるでしょう。
AI の回答後、自分で必ず検証すること
- 各数字に対応する原文が、示されたリンクにあるか
- ブロック生成時間とファイナリティ到達時間を一つにしていないか
- ノード数は何を数えているか、定義を明記しているか
- 機材要件は最低か推奨か、出典は公式文書か
- データはいつのものか、異なる時点を同じ表に並べていないか
- プロトコル更新を誰が決めるかという行があるか。ほぼ必ず抜ける項目
- リンクを実際に開け、主張を本当に裏付けるか
実例
ある人々は、ブロックを大きくして手数料を下げ、取引を増やすべきだと主張しました。他の人々は、ノード運用の敷居が上がり、誰でも独立して検証できるという前提を長期に弱めると考えました。
論争は2年以上続き、最後はチェーンの分裂で終わりました。
誰が正しいかより、本章の取捨選択を表に出したことに価値があります。ブロックサイズは技術パラメーターだけでなく、安さと参加できる人の間の選択です。 第7章の最後の変数と第11章全体は、この論争の続きです。
遅延と処理量を最優先に設計するチェーンがあります。高負荷時に代償が現れました。取引の急増でバリデーター間の合意ができず、数時間ブロック生成が止まり、調整して再起動する必要がありました。
見落とされがちな点を示します。可用性と処理量は別です。 普段は速くても時々完全に使えないチェーンは、清算などでは、速くなくても止まらないチェーンより危険です。
その後も重要です。これらのチェーンは多くの技術改善を行いました。2年前の事故だけで現在を評価するのは、理論最大値だけで評価するのと同じくらい不確かです。
プログラム可能なチェーンでは、新しいコントラクトやアドレスが状態に内容を追加します。状態は全バリデーターがいつでも参照する必要があります。
ある日突然破綻するのではなく、新規参加の費用が年々上がります。そのため多くのチェーンは、長く使わないデータの失効、状態使用への継続課金、専門のアーカイブノードへの履歴移管などを検討しています。
年単位で観察する軸なので、比較図にはほとんど出ません。しかし10年存在する予定のチェーンには、TPSよりはるかに重要です。
主要なチェーンが、計算力を消費する合意方式から資産のステークへ移り、エネルギー消費が数桁減りました。
本章で重要なのは、六つの軸の複数を書き換えたことです。安全予算の源が電気代と採掘機材からロックした資産へ変わり、参加の敷居もファイナリティの定義も変わりました。
同じチェーンでも、時期によって取捨選択の組み合わせは違います。 数字に時点を書くよう繰り返し求める理由です。
変数を一つ変える
実行能力と処理量が大きく上がり、使い勝手はよくなります。
代償は独立して検証できる人が減ることです。最後には組織と専門事業者しか残らないかもしれません。その段階で、誰も信頼する必要がないという性質は、この少数が結託しないと信頼する性質へ変わります。
それでも合理的な選択になり得ます。ただし、何を手放したか知る必要があります。
決済や取引の体験が従来のシステムに近づき、大きな改善になります。
代償は通常二つの場所に隠れます。より優れた回線と強い調整が必要で、参加者の集合が狭まること。そして極端な通信状況では、すぐ確定したという結論が覆りやすく、停止や巻き戻りの確率が上がることです。
速度の代償は、普段より最悪の日に現れます。
状態の成長に直接価格が付き、使わないデータは削除されるか、払い続ける必要があります。
ノードの長期負担を制御でき、新規参加が楽になります。一方、開発者の考える負担は大きく増えます。どのデータも、気付かないうちに消える可能性があり、長期保存に依存するアプリは再設計が必要です。
多くのチェーンが議論しましたが、全面的に実施したものは少ない方式です。なぜか考えてください。
分散性の最初の問いは改善し、少数の買収で履歴を書き換えるのが難しくなります。
ただし調整費用が上がります。集めて伝播するメッセージが増え、合意が遅く、性能の上限が下がります。人数が多いだけでは分散とは限りません。同じクラウドの同じ地域なら、何人いても同時停止を防げません。
ノードを数えるのは簡単で、分布を見抜くことこそ課題です。
持ち帰る問い
この章で、問いはさらに鋭くなりました。どの種類のチェーンが必要ですか?
10年改ざんされないことが不要で、安さと速さだけが必要なら、最も安全なチェーンは不要かもしれず、チェーン自体も不要かもしれません。用途を考えることが比較より先です。
六つの軸の優先順位は、ユーザーが決めます。
国際決済ならファイナリティと検閲耐性、ゲームなら遅延と費用、組織なら停止履歴と規制対応の接点を重視します。ユーザーが誰か説明できなければ、優先順位を決められません。
チェーンが止まると誰がリスクを負いますか? 通常は、未決済のポジションを持つ人、清算中の人、出金しようとしていた人です。
普段は単なるパラメーターに見える六つの軸が、事故の日には誰が損をするか正確に決めます。第24章で統一リスクモデルに入れます。
ここでは直接的な答えがあります。安全予算はトークン価格と結び付いています。
価格がゼロなら守る人は報酬を得られず、攻撃費用が下がります。すぐ止まるとは限りませんが、改ざんできないという売りが先に失われます。新しいチェーンを見る際、必ず尋ねてください。
章末チェック
三つの理由があり、一つだけでも十分です。
- 定義が統一されていない。 理論最大値、負荷試験値、実測中央値は別で、広まるのは通常最大の値です。
- 取引は同等ではない。 単純な送金と複雑な呼び出しでは資源が大きく違い、件数で数えると単純なチェーンが有利です。
- 六つの軸の一つしか見ない。 処理量の優位は、機材の敷居や分散性を譲った結果であることが多いのです。
正しい問いは、誰が速いかより、速さのために何を手放したかです。
承認済み履歴を書き換える費用です。コードに欠陥がないという意味ではありません。
守る人が投入する資源と、その分散度で決まります。少なければ安く攻撃でき、集中していれば資源を迂回して少数を買収できます。
安全予算は最後に誰かが払います。ユーザーの手数料か、追加発行です。後者では既存保有者が希薄化されます。
ブロックに入っただけでは、状況によってそのブロックが置き換わる可能性があります。ファイナリティは、もう巻き戻らないことです。
日常の少額決済なら通常はブロックに入れば足ります。大口送金、クロスチェーン、取引所への入金ではファイナリティを待つ必要があります。チェーンごとに取引所の必要承認数が違う理由でもあります。
第6章で学んだように、ファイナリティは一瞬ではなく徐々に強まる確率です。強まる速さはチェーンごとに大きく違います。
必ずしもそうではありません。少なくとも三つ尋ねます。
- 実際にブロック生成や投票を行うのはいくつか。データ同期だけのノードは合意を決めません。
- どこで動くか。少数のクラウドと地域に集中すれば、多くても同時に止まり、協力を要求される可能性があります。
- 更新を誰が決めるか。ブロック生成が分散していても、ルール変更権は集中できます。比較表ではほぼ常に抜ける項目です。
標準の答えはありませんが、次が含まれるか確認してください。
- 先に用途を尋ね、軸の優先順位を決めたか?
- 取得前に定義を決めたか?
- 更新を誰が決めるかと、停止履歴があるかを調べたか?
- 全数字に出典と時点を添えたか?
- 「未発見」の欄を正直に残したか?
最後が最も省かれやすく、調査と受け売りの境界です。第25章で30分の正式な手順にします。
要点
チェーン間の違いは一連のトレードオフであり、順位表ではない。