レイヤ 2 相互運用性への道

以太坊爱好者

特邀专栏作者

2020-10-25 14:00 (UTC+8)

この記事は約2867文字で、全文を読むには約5分かかります

流動性プロバイダー。L2 資金移行問題を解決します。

AI要約

流動性プロバイダー。L2 資金移行問題を解決します。

編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfans)イーサリアム愛好家 (ID: ethfans)

、著者：Tom Brand & Uri Kolodny、翻訳：A Jian、Odaily が許可を得て転載。

四文要約
レイヤ 2 の相互運用性とは、ユーザーがレイヤ 1 での摩擦を最小限に抑えながら、レイヤ 2 システム間で資金を移動できることを意味します。
この記事で説明したレイヤー 2 相互運用性ソリューションはすべて、以前に提案した「条件付きトランザクション暗号化要素」に基づいています。
StarkEx 3.0 (2020 年 12 月にリリース予定) は、オフチェーンの条件付きトランザクションを使用して、レイヤー 2 間の相互運用性 (高速引き出し) を提供します。

背景

レイヤ 2 (L2) スケーラビリティソリューションは急速に進歩しています。イーサリアムのメインネットにはすでに多くの正当性証明システムがあり、テストネットには多くの不正証明システムが立ち上げられています。 L2 スキームはスケーラビリティを提供しますが、トレードオフが伴います。L2 スキームでは、完全に L1 で実行する利点の一部が損なわれるか、少なくとも減少します。私たちは、1 つの L2 ソリューションがすべてのニーズに完璧であるとは考えていません。アプリケーションが異なれば、スループットスケーリングに対するニーズも大きく異なります。アプリケーション自体は、豊富な L2 デザインライブラリから適切なものを選択します。

先に進む前に、2 つの重要な用語を定義しましょう。
相互運用性: ユーザーがアプリケーション 1 (初期環境) とアプリケーション 2 (ターゲット環境) の間で資金を効率的に送金できるようにします。

構成可能性: App_1、app_2、...、app_n は 1 つのトランザクションで操作できます。 (構成可能性はこの記事のテーマではありません。これについては次回説明します。)

これらの大まかな定義に加えて、条件付きトランザクションの拡張バージョンも必要です。この重要な要素が相互運用性の鍵となります。

文章

一歩ずつ

これは、トラストレスブロックチェーン上で相互運用性を実現するために使用できる暗号要素 (ここで初めて提案します) です。条件付きトランザクションは、いくつかのイベント (例: 特定の支払い、特定の状態変化) の発生または不発生に依存して、それが有効になるかどうかを決定するトランザクションです。基本的な概念は、初期環境で条件付きトランザクションを定義し、そのトランザクションで指定された条件が別の環境 (つまり、ターゲット環境) で満たされるのを待ってから有効にするというものです。

一歩ずつ

これより良いソリューションが存在しない場合でも、少なくともユーザーはいつでも資金を最初の L2 から L1 に戻してから、ターゲットの L2 に投資することができます。この粗雑な方法は遅くて高価であり、需要が増加するにつれて遅くなり、費用も高くなります。

だから私たちはもっと良くしなければなりません。実際、より良い解決策を段階的に達成するために、以下の手順に従う予定です。

フェーズ I: StarkEx (L2) → イーサリアム (L1) — 高速引き出し

参加者：

「クイック引き出し」は、ユーザーが StarkEx システムから L1 に資金を素早く引き出す必要があるという問題を解決できます。ユーザー自身の L1 アドレスに資金を送信するだけでなく、Compound、Aave などの L1 の任意のターゲットアドレスに資金を送信することもできます。重要なのは、ユーザーの出金の待ち時間は、StarkEx がトランザクションのバッチのプルーフを生成する頻度とは無関係に、「ブロック時間」で測定されることです。
使用シナリオ: アリスは、L2 の dYdX アカウントの 1eth を L1 のアドレスに送信したいと考えています。
アリス（L2にデポジットを持っているユーザー）

LP (L1 に資金を提供する流動性プロバイダー)

初期環境の StarkEx オペレーター (上記の例では dYdX)

- 図 1: クイック出金プロセス -

Phase II：StarkEx (L2) → StarkEx (L2)

プロセス: (1) ユーザーは、LP が L1 上のアリスの L1 アドレスに 1eth を呼び出すことを条件に、1eth (プラス LP の手数料) を支払うことを約束する条件付きトランザクションを LP に送信します。アリスに送金した後、条件付きトランザクションが有効になります。 ; (3) LP は条件付きトランザクションをオペレーターに送信し、証明されるトランザクションの次のバッチにパッケージ化されるのを待ちます; (4) 次の証明を待ちます L1 にコミットされ検証された後、LP の L2 残高が増加しますアリスから受け取った資金を反映させるためです。

副題

参加者：

元の StarkEx は、インスタンスごとに 1 つのアプリケーションをホストしていました。現段階では、ユーザーがこれらの異なるアプリケーション間で資金を迅速に移動できるようにしたいと考えています。高速出金と同様に、ユーザーがチェーン上のオーバーヘッドを可能な限り削減し、出金トランザクションがパッケージ化されて L2 で証明されるのを待つ必要がなくなるように支援したいと考えています。
使用シナリオ: アリスは、L2_1 の dYdX アカウントから L2_2 の DeversiFi アカウントに 1eth を転送したいと考えています。
アリス (L2_1 にデポジットを持つユーザー)

LP (L2_2 に資金を提供する流動性プロバイダー)

初期環境の StarkEx オペレーター (上記の例では dYdX)

画像の説明

プロセス: (1) アリスは、LP がアリスの L2_2 アカウントに 1eth を転送するという条件で、L2_1 で 1eth (プラス LP の手数料) を支払うことを約束する署名付き条件付きトランザクションを LP に送信します。( 2) LP は、L2_2 でアリスに支払います。 3) L2_2 のオペレーターは支払いトランザクションをバッチにパックし、証明書を送信し、L1 で検証されます。トランザクションのバッチが L1 で公開された後、条件付きトランザクションが有効になります。(4) LP が条件付きトランザクションを送信します。 L2_1 のオペレーターに送信し、後者はそれを証明したい次のバッチにパッケージ化します (5) など L2_1 のトランザクションの次のバッチが L1 で公開され、その証明が契約によって検証された後、アカウントはL2_1 上の LP の残高は、Alice から受け取った TA の量を反映するように更新されます。