ブテリン: 取引確認時間を短縮するための 3 つの解決策! Layer2 の将来はどうなるでしょうか?

イーサリアムの共同創設者Vitalik Buterin氏は、以下のようなトランザクション確認時間を最適化する方法を提案しました:

1. シングルスロットファイナリティ(SSF)

• 代替Gasperコンセンサスメカニズムが決定ブロックが速くなります。
• すべてのステーカーは、12 秒ごとに 2 つのメッセージを送信する必要があります。
• スループットが向上し、ファイナライズが高速化されます。

2. ロールアップ事前確認

• メインチ​​ェーンの負荷を軽減するためのサイドチェーンのパッケージ化トランザクション。
• サイドチェーントランザクションを事前確認して、メインチェーントランザクションの確認時間を短縮します。
• スケーラビリティを向上させ、より多くのトランザクションをサポートします。

3. 事前確認メカニズムに基づく

• コンセンサスメカニズムに基づいて、トランザクションはメインチェーン上で事前確認されます。
• ロールアップ事前確認に似ていますが、サイドチェーンはありません。
• トランザクション確認の効率を向上させ、メインチェーンへの負担を軽減します。

スロットとエポックアーキテクチャ

• スロット: 12秒ごとの期間、通常は1つのブロックが生成されます。
• エポック: 6分24秒ごとに32個のスロットで構成され、ステータスチェックとバリデーターの報酬と罰を実行します。
• これらの構造により、迅速な取引確認が保証されます。

  

  SSF提案設計図
  Rollup pre-confirmation & Based pre-confirmation
  さらに、Buterin氏はRollup pre-confirmationとBased pre-confirmationの仕組みについても議論しました。イーサリアムは常にロールアップ中心の開発ルートをたどっており、データの可用性やその他の機能をサポートするように L1 を設計し、L2 はユーザーに大規模なサービスを提供しますが、これは避けられない問題に直面します。L2 がユーザーにサービスを提供していることを確認する必要があるということです。 5 ～ 20 秒より速い速度で。
  さらに、すべての L2 に分散型注文ネットワークの実装を要求するのは不公平であり、そのためには新しい L1 の作業のほとんどを L2 が実行する必要があります。
  この問題を解決するために、Justin Drake は、イーサリアムベースの事前確認に基づく共有事前確認メカニズムを立ち上げ、すべての L2 と L1 がアクセスできるようにしました。
  ベースの事前確認アプローチでは、イーサリアムの提案者は MEV (最大抽出可能値) 関連の理由から高度に洗練された参加者であることを前提としています。事前確認ベースのアプローチは、経験豊富な提案者に事前確認サービスを提供するよう奨励することで、この複雑さを利用します。基本的なアイデアは、トランザクションが次のブロックに含まれることの即時保証と、場合によってはトランザクションの実行結果に対する請求と引き換えに、ユーザーがプレミアムを支払うことができる標準化されたプロトコルを作成することです。提案者がユーザーとの約束を破った場合、その約束は切り捨てられます。
  要約すると、Based preconfirmation は L1 トランザクションを保証します。ロールアップが「ベース」の場合、すべての L2 ブロックは L1 トランザクションとなるため、同じメカニズムを使用して任意の L2 に事前確認を提供できます。
  L2 の 3 つの開発方向
  最後に、ブテリン氏は、L2 の 3 つの合理的な開発戦略を提案しました:
  1. 技術レベルと精神レベルの両方がイーサリアムに基づいています: これらの L2 は、イーサリアムのベース層の技術的特性と価値 (高度な分散化、検閲防止など）配信チャネル。簡単に言うと、これらのロールアップは「ブランド化されたシャード」と考えることができ、新しい VM 設計やその他の技術的改善に関する広範な実験が可能になります。
  2. サーバーベースのブロックチェーンアーキテクチャ: これらの L2 はサーバーから始まり、STARK の有効性の証明、取引を引き出しまたは強制するユーザーの権利、集団選択の自由 (大量引き出しの調整や注文者の機能の変更など) を追加します。大規模なオンチェーン操作のメリットを享受しながら、サーバーの効率を維持します。
  3. 妥協: イーサリアムは、100 ノードの高速チェーンを使用して、追加の相互運用性とセキュリティを提供します。これは、多くの L2 プロジェクトの実際のロードマップです。
  これら 3 つの戦略にはそれぞれ、異なるスロットアンドエポック アーキテクチャがあります:
  イーサリアム ネイティブ アーキテクチャ
  サーバーの事前確認
  委員会の事前確認
  Buterin が提起する重要な質問は、最初のカテゴリでどれだけのことができるかということです。最初のカテゴリーが非常に優れたものになると、3 番目のカテゴリーの重要性が薄れる可能性があります。 「イーサリアムベース」のソリューションはプラズマやバリジウムなどのオフチェーン データ L2 には適していないため、2 番目のカテゴリは常に存在します。
  Buterin 氏は、L2 開発者の作業を簡素化し、ユーザー エクスペリエンスを向上させるためには、より多くのオプションが必要であると結論付けました。

以上がブテリン: 取引確認時間を短縮するための 3 つの解決策! Layer2 の将来はどうなるでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。