この記事では、ロールアップ拡張ソリューションの進化のアイデアと設計理由について説明します。

原作者:オルフェオ

出典: SeeDAO

L2 プロジェクトが再び注目を集めています。

L2 におけるロールアップ拡張ルートの代表として、Arbitrum エアドロップ後に zkSync Era が開始されます。終わりのない新しいデザインとロードマップの背後にある、Rollup の主力ラインと進化的思考とは何でしょうか? 今日は見てみましょう。

この記事の要点:

※3年生向けに書いたL1の拡張アイデア

  • ロールアップ ソリューションをゼロから設計する
  • ゼロ知識証明を使用してロールアップを再び進化させる方法

たとえ話から始める

ビットコインとイーサリアムには、誕生以来、一般ユーザーからの最大の批判が 2 つあります。

※遅い:もともと車線が狭いので、車が多いと渋滞してしまいます。

  • 高い: 平坦な山の通行料金は決して安くはありません。ピーク期間中に素早く通過したい場合は、「マネー アビリティ」を使用してお金を追加し、鉱山労働者にヘリコプターを飛ばしてもらいます。

これら 2 つの批判は、ブロックチェーンの設計における 2 つの要因から生じています。

  • ブロック容量: 車線に似ており、ブロック容量が大きいほど、より多くの車を収容でき、ブロックされる可能性が低くなります。 ※インセンティブの仕組み:どんなに大きな私道であっても、渋滞する可能性はありますが、その場合、誰が先に通れるかは、誰が急いでいるかにもよりますが、人の言うことを聞いているだけではダメです, 救急車を呼ぶなどの支払い意思によりますが、数百円になります。

ブロックチェーンが本当に私道のようなものであるならば、根本的な解決策は当然、私道を拡張すると同時に、価格手段と連携して外出時間を誘導し、状況にない場合は外出しないことである。忙しい。

ただし、車線を広げてブロック容量を増やすことは魅力的な交通効率のソリューションではありますが、ブロックチェーン設計における最後の手段です。ブロックサイズが大きくなると、マイナーのハードウェア要件が高くなり、要件を満たすことができるマイナーの数が減ります。この考えによると、Visa のように 1 秒あたり数千のトランザクションを処理したい場合は、別のトランザクションを作成するだけになります。中央集権的なVisaは、ブロックチェーンのトラストレス性という中心的な目的に反しています。

他に解決策はありますか?はい、時間のガイダンスに加えて、次のようなスペースを最適化することもできます。

  • 大型トラック用、乗用車用、バス用の異なるレーンを相互に干渉せずに開く — この考えに基づいて、いくつかのメインチェーン、サイドチェーン、またはプラズマがそれぞれの強みを持ったものになります。
  • ルート設計を最適化する、交通を適切に迂回する、何もするために街に行かない、この幹線道路を通らなければならない、ここのチェックポイントを通過しなければならない —— この考えに基づいて、シャーディングが可能です。
  • なぜ外出しなければならないのですか?リモート会議を開いて合意に達するのに遅すぎることはない、オフラインで合意に署名するのに遅すぎることはない——この考えに基づいて、国家チャネル(State Channel)を設けることができます。 ※外出時は必ずしも自分で車を運転する必要はなく、相乗りや公共交通機関を利用することもできる —— この考えのもと、今回の主人公であるロールアップが誕生しました。

ブロックチェーン上のバスとして、Rollup の鍵はスペースとガソリン (ガソリン、冗談です) を節約することです。

  • スペースを節約できるため、立ち往生しにくく、各人が負担する通行料金は自分で運転するよりもはるかに少なくなります。 ※ガソリン代が節約できるので、チケット代も国民に近く、誰もが手に入れることができます。

このように「遅い」と「高い」という2つのスロットはRollupによって解決されます。

ブロックチェーンに戻って、Rollup の具体的な計画を見てみましょう。

ロールアップを最初から設計します。

標準的な答えを覗き見るより (もちろん、答えがないわけではありません)、少し緊張して、イーサリアムのロールアップを設計するという任務を与えられたときに何をするかを想像したほうがよいでしょう。

コンピューティング コストの削減 (ガソリンの節約) とストレージ コストの削減 (スペースの節約) という 2 つの観点から開始し、最初に Rollup 1.0 と呼ばれるより抜本的なソリューションを提案することも考えられます。

ロールアップ 1.0;

Rollup 1.0 は 3 つの主要なポイントで構成されます。

  • 全員の「相乗り」トランザクション (トランザクション) を収集し、相乗りが満席かどうかにかかわらず、価格と適時性を考慮して合意された時間が過ぎたときに「注文を送信」するサービス プロバイダー (オペレーター) があります。
  • 全員が送信したトランザクションに含まれるすべての計算は、このサービス プロバイダーによってオフチェーンで実行されます。オフチェーンの計算はオンチェーンよりも高速であり、多くの場合、計算はオンチェーンのコストの大部分を占めるため、大幅に節約できます。お金;
  • 計算後、更新されたステータス (アカウントの最新の残高など) を取得してチェーンに保存すると、ストレージ コストが大幅に低くなります。

簡単に言うと、皆さんのトランザクションリクエストを定期的かつ定量的に収集し、オフチェーン計算を経て、計算結果だけをチェーン上に固めるというものです。

このソリューションは、「遅い」と「高価」という 2 つの大きな問題点を完全に解決しますが、新たな問題が発生するようです。

※インセンティブ:「相乗り」サービスを誰が提供し、どのようなメリットがあるのか。

  • レビューの問題 (検閲): サービス プロバイダーが意図的に私の注文を処理しません (または電話を切るか終了します)。どうすればよいでしょうか。 ※不正問題(Fraud):サービス提供者が計算結果を不正に改ざんして他人に送金させられ、そのお金を横領されてしまった場合はどうすればよいでしょうか。

これら 3 つの新しい問題については、計画のバージョンを繰り返すことができます。

ロールアップ 2.0;

モチベーションの問題を解決するのが最善であり、お金で解決できる問題は問題ではありません。サービス提供者は、「相乗り」の費用を平等に負担し、少し多めの「チップ」を請求することができますが、それでも、「相乗り」をする側にとっては有利な状況です。

レビューの問題はもう少し厄介ですが、解決策はブロックチェーン分野では非常に一般的であり、それが分散化です。人々のグループはサービス プロバイダーであり、これは 1 人のサービス プロバイダーよりも優れており、誰でもサービス プロバイダーになれるため、固定されたグループの人々よりも優れています。後者のプレイ方法では、すべてのサービス プロバイダーが良好でない場合、自分自身がサービス プロバイダーになることも、直接 L1 に移動して調停を開始することもできます。

詐欺はもう少し難しいです。それは 2 つの問題に分類できます。1 つは不正行為を特定する方法であり、もう 1 つは不正行為を防止する方法です。

まず、不正行為を特定するには、全員のトランザクション (Transaction) データとトランザクション前の状態 (State) を把握し、トランザクション後の新しい状態 (State') を計算し、新しい状態と比較する必要があります。サービス プロバイダー チェーンに保存されており、同じであれば、サービス プロバイダーは正直であることを意味し、そうでない場合は、サービス プロバイダーが嘘をついていたことを意味します。ただし、トランザクションデータはオンチェーンではないためわかりません。その結果、私たちは疑念を抱くことしかできず、サービスプロバイダーが誠実であるかどうかを判断できません。

となると、不正を防ぐ最善の方法は、不正が起こらないようにすることです。これは、サービスプロバイダーの計算をチェーン上で毎回チェックしない限り、比較的困難ですが、この方法では、「」の利点はなくなります。相乗り」。したがって、一歩下がって不正行為のコストを非常に高く設定し、不正行為が見つかった場合に没収されるデポジット (賭け金) を支払うなど、サービスプロバイダーがゲームに参加できるようにするしかありません。 (この手法はソーシャルコンセンサスと呼ばれるもので、ゲームベースセキュリティに属し、「週刊#3;」でも取り上げられています。)

ロールアップ 3.0;

Rollup 2.0 は悪くありませんが、不正行為を特定するという問題は解決されていません。

前の推論によれば、不正行為を特定するにはトランザクション データを知る必要があるため、データのこの部分は状態データと同じチェーン上に存在する必要があります。

彼らが詐欺であることを誰が発見するでしょうか?誰もがサービス プロバイダーのあらゆる動きを 7; x; 24 時間監視することは不可能であるため、これが通常のユーザーである可能性は低いため、プロの「賞金稼ぎ」 (バリデーター) のみが可能です。サービスプロバイダーが「注文を送信」してから 7 日以内に「賞金稼ぎ」が詐欺を報告し、それが真実であると確認した場合、取引はロールバックされ、サービスプロバイダーは処罰されます。もちろん、「賞金稼ぎ」にも同様にインセンティブが必要で、例えば、不正行為が発覚した場合、サービス提供者の保証金の一部が「賞金稼ぎ」に渡される(一部のみ、賞金稼ぎ同士の癒着を避けるため)。サービスプロバイダーと賞金稼ぎ)。

ロールアップ 4.0;

ロールアップ 3.0 段階までに、ソリューション全体がスムーズに実行できるようになりましたが、新たなコストが発生しました。これまでの費用には次のものが含まれます。

  • サービスプロバイダーへの料金(費用と「チップ」を含む)。
  • トランザクションおよび状態データのオンチェーン ストレージ コスト。
  • 「賞金稼ぎ」がサービスプロバイダーが詐欺的であると信じた場合、彼の発言がチェーン上で真実であることを検証するための計算コストがかかります。

どのようなコストを最適化できるかを見てみましょう。

取引データ

特定の方法では、複数のトランザクションが集約され、占有されるスペースは各トランザクションが占有するスペースの合計よりも小さくなる可能性があります。

最も単純なETH送金トランザクションを例に、各トランザクションの内容構成を分解すると、署名スペースが最も大きな割合を占めていることがわかります。すべてのトランザクションの署名を 1 つに結合することができ (キー集約)、これによりストレージのオーバーヘッドが大幅に節約されます (ビットコインの Schnorr と同様)。さらに、ナンスを排除したり、「相乗り」スペースを最大限に活用するために、「相乗り」の際にぴったり合う「太った、痩せた」「相乗り者」を選択したりするなど、他の部分も最適化できます。

この記事では、ロールアップ拡張ソリューションの進化のアイデアと設計理由を検討します

ソース:

わずか 3 ~ 2 回で、各 ETH 送金トランザクションのサイズは 112 バイトから 12 バイトに減少し、以前の 10 分の 1 近くになりました。もちろん、トランザクション データをさらに圧縮する手段は他にもあります。

実際の運用では、チェーン上にデプロイされたコントラクトにそのようなメソッドをインストールできます。

function storeTxData(bytes calldata data) external {;// 何もしない}

その後、「カープール」が成功するたびに、マージおよび圧縮されたトランザクション データが calldata としてこのメソッドに渡されます。 Calldataは永続的に保存する必要がなく、社会的コンセンサス広報チャレンジ期間(Challenge Period)終了後は枝刈り(Prune)しても問題なく、価格自体は非常に安価であり、実装によりさらに安くなるDanksharding や Data Blob などの EIP、データ ストレージ分散 (データ可用性) に L1 を適用するこの形式も、より正式になります。

ステータスデータ

トランザクションデータがチェーンにアップロードされたので、誰でもトランザクションデータから更新された状態を計算でき、状態データはそれほど必要ありません。私たちが保持できるのは、国家データのメルケル ルートのみです。これは、サービス プロバイダーが協力しない場合に一般ユーザー (「相乗り者」) が L1 に直接引き出しを申請できるようにするために使用され、お金を持っていることを証明するためにメルケル プルーフに依存します。彼らのアカウントに。

不正仲裁費用

「賞金稼ぎ」がサービスプロバイダーに不正行為を報告する際、オンチェーンでの契約計算(リプレイ)を一度実行し、ステータス結果を比較することは理論的には可能です。ただし、そうするためのコストは低くはなく(すでに良いことですが)、2つ目は、ロールアップ「相乗りリスト」に含まれるトランザクションのGasの合計がEthereumのGas制限を超える可能性があり、それが不可能になることです。検証します。

したがって、アービトレーションの負担を軽減する必要があり、負担を軽減する方法は当然、不要な計算演算をオフチェーンに置くことになります。ソリューションの 1 つは対話型証明と呼ばれ、一般的なプロセスは次のとおりです。

  • 「バウンティ ハンター」は、デポジットを支払って報告し、計算プロセス全体を順番に n 個のセグメントに分割し、サービス プロバイダーがセグメント k (1;≤k≤n) で不正行為を行っていることを指摘します。
  • サービスプロバイダーは、セグメント k をセグメント k にドリルダウンして分解し、「賞金稼ぎ」のどのセグメントが間違っているかを指摘しました。
  • つまり、計算操作をドリルダウンしたり分解したりすることはもうできないことがわかっているので、行ったり来たりします。たとえば、「賞金稼ぎ」が 1+;1;=;2; と考えるとき、サービス プロバイダーは 1+;1;= と考えます。 ;3;; ※このとき、チェーン上のコントラクトが介入し、1+;1;を計算して2;を求めることで、サービス提供者が不正であると判断し、デポジットを没収し、その一部を「賞金稼ぎ」に報酬として与える。

(プロセス全体で、一方の当事者がタイムアウト後に応答できなかった場合、その当事者は失敗します。)

このようにして、チェーン全体の仲裁コストは非常に低くなります。

そうは言っても、私たちはロールアップ ソリューションを完全に構築しました。このスキームは、「賞金稼ぎ」レポートがない限り、サービス プロバイダーがデフォルトで正直であることを前提としているため、この派閥は楽観主義者のロールアップ、いわゆる楽観的ロールアップと呼ばれます。

では、Rollup 4.0; は最良のソリューションなのでしょうか?

ロールアップの再進化

何度も繰り返した後でも、Rollup 4.0 にはまだいくつかの不完全な点があります。

※不正行為は「賞金稼ぎ」が発見する必要がありますが、長期間不正行為がない場合、「賞金稼ぎ」は採算が取れず廃業する可能性があり、穴が開きます(可能性は低いですが、ロールアップ チェーン アプリケーション ベンダーなどの利害関係者は、おそらく「賞金稼ぎ」として行動します)。 ※社会的コンセンサスに基づき、不正行為が無いことを確認するためには数日間待つ必要があり、出金等の業務に影響が出る可能性がございます。

  • チェーン上には大量のデータがあり、コストは依然として存在します。
  • 現在、ロールアップ拡張のレイヤーに依存しているため、スループットは 10 倍に増加する可能性があります。

不正行為をまったく不可能にし、ファイナリティ (ファイナリティ) を高速化し、チェーンにアップロードする必要のあるデータを減らし、拡張を桁違いに大きくすることができるソリューションはありますか?あまり多くは望みませんが、ほぼすべての想像力を満たすことができる一種のソリューションがあります。それが、Zero Knowledge Rollup (略して ZK-Rollup) です。

ZK-Rollup は、ゼロ知識証明 (ZKP) を使用したロールアップのアイデアです。いわゆる ZKP は、機密情報を漏らすことなく、相手にその情報を知っていると信じ込ませるテクノロジーを指します。 ZKP を説明するために、私のお気に入りの例を 2 つ挙げます。

*中世ヨーロッパの町で、宝がマークされた宝の地図があると想像してください。私が宝の地図を持っていることを証明するために、宝の正確な場所は知らせずに、あなたに目隠しをして馬車に引きずり込み、町中を30分ドライブして確かめます。方向感覚を失い、ようやく目的地に到着し、車から降りてお宝を見せてもらい、また連れて行ってもらいます。これは ZKP の単純な形式です。

  • 別のたとえがより一般的です。数独パズルがあるとします。私は答えを知っていますが、あなたは知りません。しかし、あなたは私が知っていると信じていません。私はあなたに私が知っていることを証明したいのですが、あなたには答えを知ってほしくないのです。何をすべきか?テーブルに数独とカードを置き、空いている数字を上に、記入する必要のある数字を下に置き、行または列ごとに答えをチェックすることを選択させることができます。行ごとの場合は、各行の数字をグループ化して分割し、各行が 1 ~ 9 であることを示します。何度か繰り返しても大丈夫なので、本当に高い確率で答えを知っていると思っていただいて大丈夫です。これは、ZKP のインタラクティブな証明方法の 1 つです (ブロックチェーンではリアルタイムのオンチェーン インタラクションを実現することが難しいため、一般的には非インタラクティブな証明が使用され、ハッシュ関数によってランダムなチャレンジが生成されます)。

それほど厳密ではない言葉で言えば、ZKP の中心的な考え方は、証明者 (Prover) が最初に秘密の知識を隠し、「コミット」(Commit) し、次に検証者 (Verifier) がランダムなチャレンジ (Challenge) を開始するというものだけです。もし彼がこの課題にうまく合格できれば、彼は対応する秘密の知識を持っている可能性が高くなります。

ZKP は 3 つの要件を満たす必要があります。

  • 証明者が嘘をついている場合、チャレンジは失敗する可能性が高くなります (健全性)。
  • 証明者が知識を持っていれば、チャレンジに合格することができます (完全性)。 ※両者間の対話中、証明者は有益な情報を一切公開しません(ゼロ知識)。

これら 3 つの要件を満たすために、ZKP では、最も単純な素数分解や離散対数 (Schnorr など) などのさまざまな NP 問題が使用されます。

ZKP はブロックチェーンのために生まれたテクノロジーではありませんが、主に優れた ZKP には次の便利な特性があるため、L2 拡張に使用できます。

  • 証明者 (サービスプロバイダー) は、チェーンの下での計算効率が非常に高くボトルネックにならないように、迅速に証明を行うことができます。
  • 証明のサイズが小さいか、少なくとも証明される計算量に比例し、データ量の影響が可能な限り小さいため、チェーン上のストレージ コストが低くなります。 ※検証者(L1コントラクト)は証明が有効かどうかを迅速に検証できるため、チェーン上の計算コストが低くなります。

これらの機能を使用すると、ロールアップ ソリューションでは次のことが可能になります。

  • 「賞金稼ぎ」は必要ありません。L1 コントラクトはそれ自体で不正行為をその場で検出できます。
  • ZKP 認証が有効である限り、出金はすぐに行うことができ、ファイナリティは数日から数分に短縮されます。
  • チェーンでは状態間の差分のみが必要で、スペースは非常に小さく、ストレージ コストは非常に低くなります (追加のボーナス - プライバシーも向上します)。
  • 証明および検証プロセスのカスタマイズされたソフトウェアとハードウェアの最適化を通じて、拡張容量をさらに一桁増やすことができます。

もちろん、どのセキュリティ メカニズムにも潜在的な前提条件があり、ZKP はブロックチェーンの万能薬ではありません。 ZKP には現時点でも多くの制限があり、次のような制限を段階的に克服する必要があります。

  • ブロックチェーン上で最も一般的に使用されている zk-SNARK を例に挙げると、多くのスキームでは最初にできるだけ多くの著名な人物や企業を紹介し、真の乱数を生成して保証するために信頼できるセットアップを行う必要があります。検証可能だが完全には公開されていない(タウの力の儀式のように、一方の当事者が信頼できる限り、それでも欠陥とみなされます)。もちろん、いくつかの新しい zk-SNARK スキームとその後改良された zk-STARK はこの問題を解決できますが、場合によっては新しい問題が発生することがあります。 ※ZKPの問題としてまとめにくい問題が多く、そのためプログラマビリティが長らく解決されていない イーサリアム上でEVMと完全互換のZKPを実現することは困難、あるいは実現できたとしてもただし、他の側面 (検証効率など) は影響を受けます。

この記事では、ロールアップ拡張ソリューションの進化のアイデアと設計理由を検討します

ソース:

だからこそ、未来志向の拡張分野である ZK-Rollup では、あらゆる進歩が賞賛に値し、喜ばしいことなのです。

この記事では、ロールアップ拡張ソリューションの進化のアイデアと設計理由を検討します

ソース:

最後に書きます

今後の容量拡張については、L1のネイティブ容量拡張と比較して、Rollupを含めた階層化設計の方が確実であると筆者は考えている。モジュール化により、各層の懸念事項が解決され、すでに「モノリシック」な L1 に連続的に積み重ねるよりもリスクが少なく、さらに、容量拡張による基礎となる L1 の分散化は理論的に起こりにくいです。それをアップします。さらに、この階層化された設計アイデアは、ブロックチェーン以外の分野でも応用で成功しているようです。この視点は必ずしも正しいとは限りませんが、これが著者の現時点での認識です。

この記事では、ロールアップ拡張ソリューションの考え方と設計理由をプロジェクトにとらわれない形で整理しようとします。レベルが限られているため、まだ単刀直入なところもあり、説明が不十分なだけでなく、理解がさらに難しくなっている可能性があります。また、日ごとに変化する垂直領域であるため、作者が気づいていない可能性があります。の多くの新たな展開を考慮に入れます。友達の修正やコミュニケーションを心から歓迎します。

原文表示
内容は参考用であり、勧誘やオファーではありません。 投資、税務、または法律に関するアドバイスは提供されません。 リスク開示の詳細については、免責事項 を参照してください。
  • 報酬
  • コメント
  • 共有
コメント
0/400
コメントなし
  • ピン
いつでもどこでも暗号資産取引
qrCode
スキャンしてGate.ioアプリをダウンロード
コミュニティ
日本語
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • ไทย
  • Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)