DeFiがロールアップと出会うとき
編集者注: この記事は以下から引用しましたクリプトバレーライブ (ID:cryptovalley)編集者注: この記事は以下から引用しました
クリプトバレーライブ (ID:cryptovalley)"DeFi "クリプトバレーライブ (ID:cryptovalley)
、著者: Ryan Sean Adams、翻訳: Ziming、Odaily が許可を得て転載。
今年（2020年）、最近のDeFiエコシステムの継続的な発展とメインネットへのロールアップの継続的な影響により、当然の疑問が生じます：この2つはどのように出会うのでしょうか？
概要
ロールアップを使用して DeFi エコシステムの規模を拡大できますか?私たちはどんな課題に直面しているのでしょうか？"最初のレベルのタイトル"概要
Optimistic Rollups は、イーサリアム メイン チェーンの負担を軽減するために設計されたレイヤー 2 アーキテクチャです。基本的な考え方は、メイン チェーンはロールアップ サイド チェーン上のすべてのトランザクションを検証するのではなく、単にトランザクションを公開するだけであるということです。
ロールアップを採用する主な利点は、ユーザーのガスコストが削減されることです。これは、ネットワーク全体で 1 秒あたりのトランザクション数が増加すること (少なくとも数百 TPS) を意味します。これは、ガスを大量に消費する特定のアプリケーション (複雑な暗号化を使用したプライバシー ソリューションなど) が実現可能になることも意味します。したがって、Rollup 自体にはプライバシー保護という固有の利点はありませんが、プライバシー保護テクノロジを構築するための適切な基盤となります。繰り返しますが、ロールアップ自体はトランザクションのレイテンシを短縮しませんが、ほぼ瞬時のトランザクションを提供できるチャネルを構築できる優れた環境を提供します。
ユーザーの視点
オプティミスティック ロールアップがデータを処理する方法により、特に他のレイヤー 2 プロトコルと比較して、アプリケーションの構築が簡素化されます。重要なことは、これにより、エンドユーザーにレイヤー 1 プロトコルを使用するのとほぼ同じユーザー エクスペリエンスがもたらされるということです。同様に、開発者やプロトコル設計者にとっても、使い慣れたツールや考え方を引き続き使用できます (ただし、後で説明するように、構成可能性に関するいくつかの課題を解決するには追加の作業が必要になる場合があります)。
最初のレベルのタイトル
ユーザーの視点"ユーザーの観点から見ると、ロールアップ上で DeFi アプリやその他の操作を行うことは、レイヤー 1 で DeFi を使用するのとほぼ同じように感じられます。 Metamask や Burner などの人気のあるウォレットをサポートするだけでなく、ロールアップ アクティビティを監視するエクスプローラーをブロックすることもできます。"Rollup を使用した DApp の基本的なライフサイクルは次のとおりです。
まず、ユーザーはいくらかの資金を入金します（
ETH、ERC20、ERC721 など) をロールアップに追加できます。この最初のステップは、多くの第一層 DApp ユーザーのユーザー エクスペリエンスと同じです。つまり、ユーザーは使用する前にコントラクトに資金を移す必要があります。この時点で、ユーザーは通常どおりアプリにトランザクションを投稿できます。Rollup が検閲への耐性を優先するように設計されている場合、自分のトランザクションを Rollup に含めるには、それ以上の信頼、評判、ビジネスに依存する必要はありません。レイヤ 1 トランザクションを投稿する場合と同様に、潜在的な精査に直面する必要はありません。
T-word
ユーザーが資産をレイヤー 1 に戻したい場合は、特別な引き出しトランザクションを発行します。この時点で、潜在的な違いが観察されます: Optimistic Rollup のセキュリティ モデルは、チャレンジを発行するすべての当事者の能力に依存していることを思い出してください。したがって、不正行為の検出と証明のプロセスには時間がかかります。これは、出金が要求されると、ユーザーはレイヤー 1 で資金を再び取得できるようになるまで待機する必要があることを意味します。このメカニズムによって提供される経済的安全性は、実際にはブロックに必要なステーク量と待機の長さの関数です。上記の期間 (Ed Felten は実際には 3 時間で十分だと思います)。
そうは言っても、私たちが望んでいるのは、ユーザーがそのような待ち時間を経験しないことです。たとえば、サードパーティがレイヤー 1 で同額の資金を送信し、関連手数料を差し引くことで、待つことなく資金の所有権を取得できます。したがって、このような流動性プロバイダーと、複雑なことを簡素化する対話型インターフェイスがある限り、レイヤー 2 での出金であっても、レイヤー 1 でのユーザー エクスペリエンスと大きな違いはありません。
副題"そうですね、しかしオプティミスティックロールアップは本当にトラストレスなのでしょうか?確かに。"信頼の危険を排除するために、誰でも（ユーザーかどうかに関係なく）バリデーターになることができ、誰も不正行為をしないこと、不正行為を試みた場合には時間内に阻止されることを自分で検証できます。これは、いくつかのコマンドを実行することと同じです。
一度確認してください
追加のプログラム。バリデーターを実行していないユーザーの場合、すべてのバリデーターが違法行為に関与し、互いに共謀した場合にのみ、不正な取引 (資金の窃取など) が可能になります。言い換えれば、そこに正直な検証者がいる限り、それが他のユーザーであれ、取引所であれ、アプリ開発者であれ、ブロックエクスプローラーであれ、ウォレットプロバイダーであれ、地下室にいる匿名のティーンエイジャーであれ、関係者はすべて悪意がありますが、彼らが共謀しない限り、つまり一斉に嘘をつかない限り、ロールアップ全体に不正行為が含まれることはありません。不正行為が証明されると、悪意のある行為者はデポジットから差し引かれ、その一部が不正なバリデーターに与えられます。これにより、これらの誠実さの検証が奨励され、悪意のある行為者が他のバリデーターに不正行為を与えることが可能になり、不便の対価を支払うことになります。
開発者の視点
次に、アプリケーション開発者の視点に移りましょう。ロールアップ DApps の構築と展開のプロセスにおいて、多くの開発者が truffle、web3、ethers.js などの開発者ツールやライブラリに精通していることを知って大変うれしく思います。 、ロールアップ環境での開発に再適用できます。さらに、Rollup にデプロイされたコントラクトは、いくつかの制限はありますが、Solidity で引き続き作成できます。
次に、ロールアップ アプリケーションを設計するときの最大の違いは、構成可能性の問題です (これは特に DeFi アプリケーションに関連します)。"副題"構成可能性の課題について
DeFi アプリケーションの最も有名な (そして、時には衝撃的な) 機能の 1 つは、相互に連携して他の金融サービスを直接かつ許可なく統合できることです。この一見根本的な相互運用性は、実際にはレイヤー 1 でイーサリアム コントラクトを提供します。
無料
サービスの欠点は、当然のことながら、アプリケーションのスケーリング (スケーリング) がボトルネックに遭遇することです。アクティビティを独立したレイヤー 2 環境に分割すると、異なるレイヤー 2 チェーン間の相互運用性が失われるわけではありませんが、より困難になります。
PoolTogether を例に挙げると、PoolTogether はハズレなしの宝くじ DeFi アプリケーションです。 PoolTogether の契約は、ランダムな宝くじ当選者の選択と資金の分配を管理します。資金は Compound (別個の (既存の) アプリケーションです) によって生成された利息で構成され、その資金形式 (プールの 1 つに対する) は Dai (発行者によって発行されます) です。別途契約）。この相互運用性は、レイヤー 1 の 3 つによって示された相互運用性と何ら変わりません。"更新する"しかし、3 つの契約すべてが個別のロールアップに含まれている場合はどうなるでしょうか?
DAI などの資産をあるロールアップから別のロールアップに移行するのは難しい作業ではなく、通常のレイヤー 1 契約間の資産の移行と非常によく似ています。ただし、PoolTogether ゲームを購入するには、まず PoolTogether を使用してアセットを Compound に入金する必要がありますが、PoolTogether と Compound が異なるチェーン上にある場合、単純なトランザクションを渡すことは不可能です。 PoolTogether Rollup には、Compound Rollup の更新に関するニュースにアクセスして最新情報を入手するための新しい戦略が必要でした。他のケースでは、両方の契約が、これらの更新スケジュールを適時に取得するために、他の契約と双方向に対話する権限を必要とする可能性があると想像できます。
更新する
の発表。
ここで設定するRollup通信ツールは、イーサリアム2.0のようなシステムにおける異なるシャード（シャード）間の通信配置など、レイヤー1ブロックチェーン間の通信方式に似ています。つまり、さまざまな用途に合わせてさまざまなアプローチが用意されており、それぞれのアプローチには、特定のニーズに応じて独自の技術的な複雑さやユーザー エクスペリエンスのトレードオフがあります。この記事では技術的な詳細には触れませんが、UX のトレードオフには、トランザクションが確認されるまでユーザーに長時間待つことを要求したり、目的の操作を完了するために複数のトランザクションを投稿したりすることが含まれることがよくあります。
このたとえをもう少し誇張してみましょう。すでに同じ空間に住んでいる友人は、別の家に移動して、窓の外に大声で叫んで互いにコミュニケーションする必要がありますか?それとも、中間の場所や共有ルームを介して通信しますか?それともデジタルでチャットするだけですか (高速ですが、より高度な電話技術が必要です)?
可能性はたくさんありますが、要するに、ロールアップのコミュニケーションは「対面でチャットする」ほど単純なものではありません。
このような極端な状況を想像することができます。つまり、多数のアプリケーション (すべての DeFi など) を巨大なロールアップに配置します。この時点で、ロールアップ間の相互運用性の複雑さはなくなり、Compound と PoolTogether はレイヤー 1 と同様にレイヤー 2 でも自由に相互作用できるようになります。
しかし、このビジョンの唯一の問題は、私たちが開始したときに追い求めていたスケーラビリティの向上を台無しにしてしまうことです。レイヤ 2 のスケーラビリティは主に、グローバルに実行する必要がある作業のパーティショニングとローカライズによって実現されます。単一のビジーなロールアップでは検証が難しくなり、最初に避けようとしていた問題にさらに直面することになります。 。言い換えれば、すでに過密な家から新しい家に引っ越したくないのです。
その場合、おそらく理想的な実装は妥協の立場で動作します。つまり、相互コンポーザビリティの恩恵を受ける (または必要とする) アプリケーションは、必要に応じて適切な方法で他のロールアップ チェーンと通信しながら、共通のロールアップで実行することを選択できます。
画像の説明
