さまざまな Ethereum Layer 2 拡張ソリューションの評価と比較
編集者注: この記事は以下から引用しましたデンリアンコミュニティ編集者注: この記事は以下から引用しました
デンリアンコミュニティ
、著者: Alex Gluchowski、Odaily の許可を得て転載。
これらの主張を単に事実として受け取るべきではなく、各ソリューションがもたらす避けられないトレードオフを調査するために徹底的なデューデリジェンスを行う必要があります。
概要
最初のレベルのタイトル
概要
問題を単純化するために、評価は次の 4 つの側面から開始します。
1. セキュリティ 2. パフォーマンス/経済性 3. 使いやすさ 4. その他
これらの質問に加えて、ソリューション プロバイダーとの会話の出発点として使用できるチェックリストをまとめました。私たちは比較を中立かつ客観的に保つよう最善を尽くしましたが、さまざまなアプローチのニュアンスを表で簡潔に表現することは依然として困難な作業です。より多くのコンテキストを使用してこの問題を解決できることを期待しています。
最初のレベルのタイトル
1. セキュリティ
副題
オンラインの仮定 (例: 監視塔)
場合によっては、オンライン委任は、サービスのユーザーに合わせたインセンティブを備えた信頼できる当事者に委任できます (保証などを通じて)。ただし、信頼できる代理人が不正行為をした場合、損失額は常に保証金と同額になることに注意することが重要です。
信頼できる代理人が保証金を超える価値を盗む機会があるかどうか、またこのリスクはどの程度まで許容できるかを検討する必要があります。
副題
大量離脱仮説
拡張ソリューションのセキュリティの前提には、すべてのユーザーが短期間で正常に L1 層に撤退できる (ユーザーの撤退) ことが含まれますか?
埋め込む
これは、セキュリティ上の理由から、L2 スケーリング ソリューションのすべてのユーザーが短時間内に L2 を終了する必要がある場合に発生します。留まることを選択した場合、オペレーターは L2 に残っている資金を排出するためにいくつかの操作を実行する可能性があります。たとえば、Matic スキームでは、すべてのユーザーがログアウトできる期間は 1 週間です。
これは、ネットワークの輻輳や DoS 攻撃により、非常に問題となる可能性があります。たとえば、特定の時間枠内で大規模な終了が発生すると、イーサリアム ネットワークが非常に混雑する可能性があり、その結果、トランザクションがタイムリーにパッケージ化されない可能性があります。輻輳がない場合でも、攻撃者はトランザクションが適時に処理できないようにガス価格を操作しようとする可能性があります。これは検討する価値のある攻撃ベクトルです。
副題
L2 バリデーターのクォーラムにより、ユーザーは一定期間資金にアクセスできなくなりますか?ユーザーの資金を受け取ることはできますか?
これは、プロジェクトを検閲不能のままにしたい場合に特に重要です。
副題
ホットウォレットキーのデメリット
システムを稼働し続けるには、キーが常にオンラインである必要がありますか?
ホットウォレットは、実際の保護を得るのが難しいことで知られています。
副題
暗号経済攻撃に対して脆弱
L2 バリデータ [1] (またはそのオペレーター) のフレーミング、L1 のマイナーへの賄賂 [2]、ダーク DAO [3] の作成など、暗号経済的インセンティブを伴うさまざまな攻撃があります。これらの攻撃手法は急速に発展しており、ゲーム理論の仮定に基づいたシステムの拡張によってこれらの攻撃を根絶できることを証明するのは困難です。
技術的には盗難ではないが、実質的に同等のシナリオも含まれています。たとえば、Validium の二重支出攻撃 [4] の場合、攻撃者は設計上、他人の資金を盗むことはできませんが、二重支出は可能です。
パスワードの原則
最初のレベルのタイトル
パフォーマンス/経済性
副題
Ethereum 1.0 でのスケーリング ソリューションの最大可能スループットはどれくらいですか?イーサリアム 2.0 についてはどうですか?
現在のソリューションのスループットは満足のいくものかもしれませんが、将来に目を向けて、追加のスループットの必要性と、計画されたソリューションが将来も使用できるかどうかを予測するのが合理的です。
副題
スケーリング ソリューションの資本効率はどの程度ですか?運営するには多額の資本が必要ですか?
資本効率の低いシステムはユーザーにとってコストが高くつき、即時の流動性の欠如により運用の中断につながる可能性があります。たとえば、決済チャネルは、チャネルがキャパシティに達しないようにチャネル運営者が平均チャネル数の倍数を固定する必要があるため、資金の使用が比較的非効率的です。
副題
L2 で新しいユーザーの使用を開始するには、L1 チェーンでトランザクションを送信する必要がありますか?
最初のレベルのタイトル
使いやすさ
引き出し時間
L1 に資金を引き出すのにどれくらい時間がかかりますか?一部の和解での引き出しは、紛争を解決するために 1 週間以上待たなければならない場合があります。この長い待ち時間を軽減するために、リスクプレミアムと引き換えにユーザーに流動性を提供する流動性プロバイダーはいますか?そのような流動性プロバイダーが存在する場合、その信頼性とコストはどのくらいでしょうか?迅速な引き出しには代償が伴いますが、このソリューションを使用する場合の実際のコストはいくらですか?
副題
プロトコルのセキュリティの前提のもとで、トランザクションが L1 で元に戻せない状態に達するまでにどれくらいの時間がかかりますか?
主観的な最終性とは、L1 スマート コントラクトがまだこの状態に依存できない場合でも、外部の観察者がトランザクションの不可逆性を確信できることを意味します。たとえば、Optimistic Rollups では、L1 ファイナリティに達するまでにイーサリアムで 1 回の確認が必要で、完全なファイナリティには約 1 週間かかります。
副題
ライトクライアント (ブラウザ/モバイルウォレット) は、主観的な確実性に達した時点を検証できますか (前の質問を参照)。
上記の例を続けると、オプティミスティック ロールアップでは、L1 ファイナリティに達するには 1 回の確認で十分ですが、トランザクションが最終的なものであることを確認するには、ロールアップの状態全体をダウンロードし、先週のすべてのトランザクションを実行して、すべてのオプティミスティック ロールアップが確実にブロックされるようにする必要があります。は正しいです。
副題
即時取引確認
ほとんどの L2 プロトコルは「即時見かけのファイナリティ」を実装しています。つまり、トランザクションは UX (ユーザー) 上で即座に確認されたように見えます。これらの確認に対して完全なセキュリティ保証を提供するのは支払いチャネル (状態チャネル) のみですが、他のプロトコルでは、L1 で確認される前にこれらのトランザクションを取り消すことができます。ただし、取り消しには(成功するかどうかにかかわらず)、保証金(つまり、担保金)を失うというコストがかかります。
他の側面
スマートコントラクト
スマートコントラクト
L2 層は、任意にプログラム可能なスマート コントラクトをサポートしますか、それとも特定の述語を使用して実装された限られたサブセットのみをサポートしますか?
EVM バイトコードの移植性
既存のイーサリアムコントラクトをほとんど変更せずに移植できますか?
副題
このプロトコルはプライバシーをネイティブにサポートしていますか?
デフォルトで低コストのシールドされたトランザクションがなければ、プライバシーは十分に保護されません[5]。これは、さまざまなプラットフォームで実施された匿名化解除に関する複数の研究で雄弁に証明されています (参考文献 1、2)。
最初のレベルのタイトル


