Solana と Ethereum: トランザクション速度が異なるのはなぜですか?

コンセンサスメカニズムのアーキテクチャ

1. Solana は、トランザクションがコンセンサス層に入る前に暗号的にタイムスタンプを付ける検証可能な遅延機能である Proof of History (PoH) を採用しています。この事前順序付けにより、バリデーターがブロックの生成中に順序をネゴシエートする必要がなくなります。

2. イーサリアムは提案者と構築者を分離したプルーフ オブ ステーク (PoS) に依存しており、ブロック構築者は最適なブロックを構築するために競合し、提案者はその中から選択します。トランザクションの順序は、スロットの実行中に動的に決定されます。

3. PoH により、Solana バリデーターは相互バリデーター調整のオーバーヘッドなしで数千のトランザクションを並行して処理できるようになり、1 秒未満のファイナリティに直接貢献します。

4. イーサリアムのコンセンサス設計は、生のスループットよりも検閲耐性と分散化を優先しており、各ブロック内のトランザクション効果を逐次検証する必要があります。

5. Solana のアーキテクチャにはグローバル ステート ロックがないため、重複しないアカウント セット間での同時実行が可能ですが、Ethereum の EVM はブロックごとに厳密なシリアル実行を強制します。

実行エンジンの設計

1. Solana の Sealevel ランタイムは、スケジュール設定の前に命令レベルで読み取り/書き込みアカウントの依存関係を分析することにより、トランザクションを並列実行します。

2. イーサリアムの EVM は、ガス順序でトランザクションを一度に 1 つずつ処理し、基盤となるハードウェア機能に関係なく実行を本質的に線形にします。

3. Sealevel では、開発者がアカウント アクセス パターンを明示的に宣言することを要求しており、実行開始前に決定的な競合検出を可能にします。

4. EVM ではそのような宣言は必要ありません。競合は実行時にのみ発生し、状態の不一致が発生すると再実行または拒否が強制されます。

5. Solana での並列実行により、トランザクションごとの平均レイテンシは短縮されますが、明示的な同時実行管理によりスマート コントラクト開発の複雑さが増加します。

ネットワークレベルのスループット制約

1. Solana は、理想的な条件下で 65,000 TPS を目標とし、GPU とカスタム暗号化ライブラリを使用したハードウェア アクセラレーションによる署名検証によってサポートされます。

2. デネブ後のイーサリアムの現在の容量は、L1 の 100 TPS 近くに制限されたままであり、大容量アクティビティのほとんどは、ベース層のボトルネックとは独立して動作するロールアップに移行しています。

3. Solana のバリデータ セットは、高周波数のリーダー ローテーション全体で同期を維持するために、厳しいハードウェア要件 (ノードは 10 Gbps の帯域幅と NVMe ストレージを維持する必要がある) で動作します。

4. イーサリアムバリデーターは、I/O 要求が緩和された汎用ハードウェアで動作し、生の速度と引き換えに、より広範な参加とフォールトトレランスを実現します。

5. Solana でのネットワーク伝播遅延は、ブロックをより小さなパケットに分割し、地理的領域間で同時にマルチキャストするブロック分散プロトコルである Turbine によって最小限に抑えられます。

トランザクション障害のダイナミクス

1. Solana は約20%のトランザクション失敗率を示します。これは主に、ピーク負荷時のリソース枯渇、タイミング違反、アカウント ロックの競合によって引き起こされます。

2. イーサリアムの失敗率は0.1%近くにあり、保守的なガス推定手法と EVM 設計から継承された組み込みの実行保護手段を反映しています。

3. Solana で失敗したトランザクションは、元に戻した場合でもコンピューティング バジェットとネットワーク帯域幅を消費し、ユーザーとバリデーターの両方に測定可能なコストを課します。

4. イーサリアムのガスメカニズムにより、失敗したトランザクションは実行試行に対して支払われたガスのみを消費し、経済的インセンティブへの巻き添え被害を制限します。

5. Solana での高い障害率は、メモリプールの輻輳やリーダーの急速な移行の期間と強く相関しており、リアルタイムのネットワーク変動に対するアーキテクチャの敏感性が明らかになります。

ゼロ値の転送動作

1. すべての Solana トランザクションの約7.6%にはゼロ価値があり、アカウントの初期化、プログラムのアップグレード、または CPI 呼び出しのスキャフォールディングによく使用されます。

2. イーサリアムのトランザクション モデルは、値の転送と実行意図を密接に結び付けるため、ゼロ値の転送は0.66%のみ記録されます。

3. Solana のアカウント モデルは、すべての命令をファーストクラスのトランザクション エンティティとして扱い、ネイティブ値の移動なしでアトミックな複数命令バンドルを可能にします。

4. イーサリアムのトランザクション中心モデルでは、単純な状態の変更であっても明示的な ETH 転送または ERC-20 の承認が必要であり、ゼロ値の使用パターンを妨げます。

5. Solana でのゼロ値トラフィックの蔓延は、アプリケーションがチェーン状態とインターフェイスする方法とユーザーがアクションを開始する方法の深い構造的な違いを反映しています。

よくある質問

Q: Solana の高い TPS は分散化を犠牲にして実現していますか? A: はい。高帯域幅の接続、低遅延の NVMe ストレージ、GPU アクセラレーションなどの Solana のバリデーター要件では、低リソースの参加者が除外されているため、バリデーター セットはイーサリアムのものより大幅に小さくなります。

Q: イーサリアムは速度を上げるために単に PoH を採用できないのはなぜですか? A: PoH は、同期されたクロックと決定論的なネットワーク遅延を前提としています。これは、敵対的な異種ネットワーク条件下でも確実に動作するというイーサリアムの設計原則に矛盾します。

Q: Solana の並列実行の利点は、すべての開発者が利用できますか? A: いいえ。開発者は実行時の競合を避けるために、アカウントのアクセス パターンと構造ロジックに手動で注釈を付ける必要があり、イーサリアムのプラグ アンド プレイ EVM 互換性と比較して参入障壁が高くなります。

Q: イーサリアムはスケールを L2 に委任しながらセキュリティをどのように維持しますか? A: イーサリアムは、通話データの投稿と不正/正当性の証明を通じて L2 データの可用性を確保し、L2 状態遷移が L1 決済層に固定され、L1 決済層によって検証可能であることを保証します。