イーサリアムの拡大への道:未来はどのソリューションになるのか?
先知实验室
2022-03-21 07:51
本文约13886字,阅读全文需要约56分钟
イーサリアム拡張ソリューションの長所と短所に関する詳細な調査。

研究機関:シーア・ラボ

序文

序文

あなたがブロックチェーン技術の専門家であるかどうかに関係なく、暗号通貨の世界に十分長く滞在している限りは問題ありません。イーサリアム拡張、レイヤー2、ロールアップという言葉はよく知られています。多くの人はこれらの概念の 1 つ以上をよく知っていますが、それらはどのように関連しているのでしょうか?なぜこれらのテクノロジーが必要なのでしょうか?彼らはどのような問題を解決しようとしているのでしょうか?

上記の質問に対する答えを知りたい場合は、この記事が役立つことを願っています。

文章

文章

以来CryotoKittyイーサリアム チェーンの輻輳が発生した日以来、イーサリアム開発者はイーサリアムのスループットを向上させるソリューションを常に模索してきました。

原則として、次の 2 つのカテゴリに分類できます。

(1) Ethereum ブロック自体を変換することです (これを Layer1 ソリューションと呼びます) ここでの主なソリューションはシャーディングです。

(2) イーサリアムの使用方法を変更し、トランザクションの実行と処理をオフチェーンに配置することであり、イーサリアム自体はトランザクションの正当性を検証し、セキュリティを提供するためにのみ使用されます。これは、Layer2 についてよく聞かれることです。

Layer2 の中心となるアイデアは、オフチェーンで多数の実際のトランザクションを実行および計算し、イーサリアム上の非常に少数のトランザクションを通じてトランザクションの最終的な有効性を検証することです。ステート チャネル、プラズマ、ロールアップのいずれであっても、これらはすべてこの原則に従います。

副題

1. ステータスチャンネル

以下は、状態チャネルの最も原始的な構造です。

ステート チャネルは、古くから存在するブロックチェーン スケーリング ソリューションであり、最も有名なアプリケーションはビットコインのライトニング ネットワークです。

彼の原理を説明するのと比べて、例は、状態チャネルとは何かをよりよく説明します。

あなたは階下の理髪店がとても好きで、理髪店に行くたびに、トニー先生はいつも耳元でカードを申請するように頼みます。

いつかあなたが最終的に決めたら、カードを申請するだけです。とにかく、私は将来来ます。そこで理髪店に1,000元を送金してカードを入手します。

今後、ヘアカットに行くたびに理髪店にお金を振り込む必要はなく、カード残高が引き落とされると同時に理髪店との実際の取引が完了します。髪を切るたびに。

1か月後に引っ越しをする予定ですが、カードの残高がまだ使い切れていません。そこで理髪店にカードの返却を申請すると、理髪店のトニーさんが200元を返金してくれます。

この 1 か月間、あなたは理髪店で十数回お金を使いましたが、実際にあなたと理髪店が相互にお金を送金したのは 2 回だけです。

このプロセスをブロックチェーン上に置くと、カードを購入するプロセスは実際にスマートコントラクトにお金を入金し、同時にあなたと理髪店の間に国家チャネルを開くことになります。カードを返却するプロセスにより、あなたと理容師の間の「ステータス チャネル」が閉じられます。あなたと理髪店の間の相互送金は、イーサリアムメインチェーン上の2つのトランザクションに相当します。

カードを持っておらず、ヘアカットが終わるたびに理髪店に口座を送金する必要があると想像してください。

アプリケーションシナリオ

アプリケーションシナリオ

(1) ステート チャネルは、ストリーミング支払いなどのいくつかの単純なシナリオで非常に重要な役割を果たすことができ、チェーンからメッセージに署名することでトランザクション データを記録し、発生した多数のトランザクションを論理的にメインの 2 つのトランザクションに単純化します。鎖。

(2) ステート チャネルはコストが低いため、ETH または BTC で朝食用コーヒーを購入するなど、一部の少額決済シナリオに非常に適しています。

制限

副題

2. プラズマ

1: 原則

今では私たちは皆、状態チャネルの限界を知っており、この問題を解決するためにプラズマが登場しました。これにより、任意の対象者にアセットを送信する問題が解決され、TPS の向上も確実に実現できます。実際、開発者が Layer2 ソリューションを研究し始めた長い間、Plasma が「その 1 つ」であると考えられていました。

プラズマを理解するには、まずプラズマが実際のテクノロジーではなく、設計アイデアまたは技術アーキテクチャに近いものであることを理解する必要があります。

プラズマは通常チェーンであり、メインチェーンとは異なるコンセンサスメカニズムを持つことも、独自のマイナーを持つこともできます。しかし、最も重要なことは、「」と呼ばれるプラズマチェーンが存在するということです。Operator「を生成する」という役割マークルツリー、このマークル ツリーのルート ハッシュ値を検証と記録のためにメイン チェーンに送信します。マークル ツリーとそのルート ハッシュが状態遷移の検証として使用できる理由については、このアプリケーションも使用する Rollup で説明します。

このように、2 回の送信中にサブチェーン上でどれだけ多くのトランザクションが発生しても、サブチェーンはトランザクションの実行によって生じた状態情報をメイン チェーンに送信するだけで済みます。

以下は、Plasma メカニズムの使用を示す簡単な図です。

プラズマチェーンに参入したいユーザーは、イーサリアムのメインチェーンに資産をマッピングする必要があり、プラズマチェーンまたはメインチェーンに資産を移管する必要がある場合、他のユーザーが「不正証明」を使用できるようにするための挑戦期間を経る必要があります。 「資産譲渡の正当性を確認する仕組み。

「詐欺の証明」これは、この異議申し立て期間内 (通常は 7 日以上) であれば、誰でもマークル ツリー検証を通じてユーザー資産の引き出しが違法であるという証拠を提出できることを意味します。

しかし、これにより次の 2 つの問題が生じます。

(1) この引き出しが正しいことを検証したい場合は、トランザクションと状態情報をレイヤー 2 に保存するノードが必要です。プラズマは状態転送の結果のみを送信するため、レイヤー 2 の情報が必要です。不正行為の証拠を提出する必要があり、検証者の役割のコストが大幅に増加します。

(2) と呼ばれます「データが利用できません」副題

3. ロールアップ

Plasma の非常に重要な問題は、その「データが利用できない」ことであることがわかります。メイン チェーンは、オペレーターによって送信された状態転送結果のみを受信し、誰かがトランザクションと状態の情報を以下に保存していることのみを期待できます。証明メカニズムは、サブチェーンの送信の信頼性を保証するために使用されますが、このプロセスでは確認者の役割のみを担うだけであり、そのセキュリティ レベルは低いです。

1.「データが利用できない」についての具体的な理解

イーサリアムはそのチェーン上で発生するすべてのデータを公開し、誰もがそれをクエリできます。ただし、Plasma はこれらのトランザクションデータをメインチェーンに送信せず、実行結果のみを送信するため、効率は大幅に向上しますが、その代償として、Plasma はイーサリアムのメインチェーンと同じレベルの信頼を確立できません。

Rollup は、実際には、元のメイン チェーンの処理方法と Plasma 方法の間の妥協点とみなすことができます。データをメイン チェーンに送信しますが、賢いコーディング方法を通じてこれらのデータの圧縮を最大限に高め、同時に削除や削除を行います。最終提出物が誰でも検証できる限り、ロールアップ自体の特性に基づいて適切に削減されます。 データの一部。

トランザクションデータがチェーンにアップロードされると、誰でもこのデータに基づいてロールアップによって送信された結果が正しいかどうかを検証できます。したがって、ロールアップはプラズマよりも安全です。

データの可用性データの可用性」を実行すると、データがメインチェーンに送信され、セキュリティが大幅に強化されます。

では、ロールアップは正確にどのように実装されるのでしょうか?

2. 原則

(1) ステート ルート: まず、ロールアップにはメイン チェーン上に 1 つの (または相互に関連する一連の) コントラクトがあります。

この契約は、ロールアップ層で状態レコードを維持するために使用されます。この状態レコードは、実際にはマークル ツリーのルート ノードに保存されているハッシュ値です。このハッシュ値はと呼ばれます。state root

そして、このマークルツリーのリーフノードがロールアップのアカウントステータス情報になります。マークル ツリーが何なのかわからない場合は、簡単な例を次に示します。

これはバイナリ ツリーであり、現在のロールアップ層アカウントのステータス情報がバイナリ ツリーのリーフ ノードに記録されていることがわかります。

2 つの状態情報 (状態 1/状態 2 など) ごとに、これら 2 つのリーフ ノードの親ノードとして特定のハッシュ式に従って一意のハッシュ値 (例: Hash(1,2) ) を計算できます。 1 つなど、最後にルート ノードに保存されているハッシュ値を取得します。

ハッシュの計算方法を知る必要はありません。いくつかのことを覚えておくだけで済みます。

1 リーフ ノードを変更すると、ルート ノードの値も変更されます (状態が変化すると、ルート ハッシュが変化します)

2 2 つのツリーのルート ハッシュ値が同じ場合、葉ノードに格納されている情報がまったく同じであることを意味します(したがって、基になる状態情報の一貫性を確認するには、2 つのルート ノードのハッシュ値を比較するだけで済みます)

文章

文章

キーはアカウントアドレスで、値には残高/ノンス/契約コード/ストレージ(契約アカウントの場合)などのステータス情報が含まれます。

ロールアップでトランザクションが発生すると、明らかに、これらのアカウントのステータスが変更され、その結果、新しいステート ルートが作成されます。

これにより、ロールアップでの最新の状態変化の非常に正確かつタイムリーなフィードバックが提供されますが、トランザクションが発生するたびにメイン チェーン上で状態ルートが更新される場合、発生するコストはレイヤー 1 でこれらのトランザクションを実行する場合よりも高くなります。

したがって、この問題を解決するために、ロールアップで生成されたトランザクションがパッケージ化されてバッチに集約され、このバッチ内のすべてのトランザクションが実行された後の状態に応じて新しいステート ルートが生成されます。メインチェーン上のスマートコントラクトにトランザクションパッケージを送信する人が誰であっても、この新しい状態ルートを計算し、以前の状態ルートとトランザクションデータと一緒に送信する必要があります。

パッケージ化のこの部分は「バッチ」と呼ばれます。送信者がバッチをロールアップ コントラクトに送信した後、メイン チェーンは新しい状態ルートが正しいかどうかを検証します。検証に合格すると、状態ルートが更新されます。最後に送信されたステート ルート、そして最後にロールアップでステート転送の確認を完了します。

文章

したがって、Rollup の本質は、実際に生成された大量のトランザクションをメイン チェーン上のトランザクションに集約することです。これらのトランザクションは、Rollup チェーンによって実行および計算されますが、データはメイン チェーンに送信され、メイン チェーンに送信されます。 「最高裁判所判事」の役割は、最終的にこれらの取引を確認するものとなる。したがって、メインチェーンのコンセンサスとセキュリティを活用しながら、実際の取引効率を向上させ、取引コストを削減します。

3: 疑問

上記の説明を読んだ後、いくつかの質問があるかもしれませんが、心配しないでください。段階的に推測して説明します。

(1) 取引データを全量提出しても、やはり拡張は難しいですよね。前述のデータ圧縮はこの問題を解決しますか?どうやってやるのですか?

これら 2 つの技術ソリューションは拡張を実現でき、その中心となるのはトランザクションの圧縮とパッケージ化です。これは、イーサリアムのブロックガス制限には上限があり、圧縮されたトランザクションが小さいほど、一度に多くのトランザクションをメインチェーンに送信できるためです。では、どうやってこれを行うのでしょうか?

以下は、理解に役立つ例として、Vitalik 氏の記事で説明されている圧縮モードです。

イーサリアム メイン チェーン上の単純なトランザクション (ETH の送信など) は通常、約 110 バイトを消費します。ただし、ロールアップでの ETH の送信は約 12 バイトに削減できます。

このような圧縮効果を実現するために、一方ではよりシンプルかつ高度なエンコーディングが採用されており、現在のイーサリアムの RLP では各値の長さで 1 バイトが無駄にされています。一方で、巧妙な圧縮テクニックもいくつかあります。

ナンス: ロールアップではナンスを完全に省略できます

ガス価格: ユーザーが 2 の 16 乗などの固定範囲のガス価格で支払うことができるようになります。

ガス: ガスを 2 の倍数に設定することもできます。さらに、バッチ レベルでガス制限を設定することもできます。

To: アドレスはマークル ツリーのインデックスによって識別できます。

値: 値を科学的表記法で保存できます。ほとんどの場合、転送に必要な有効数字は 1 ~ 3 桁のみです。

署名: BLS 集約署名を使用して、複数の署名を 1 つに結合できます。

これらの圧縮技術がロールアップ拡張の鍵となります。トランザクションデータを圧縮しなければ、メインチェーンベースではロールアップの効率は10倍程度しか向上できませんが、これらの圧縮技術を使用することで50倍の効率化が可能になります100倍以上の圧縮効率。

同時に、ガスを節約するために、これらの圧縮されたトランザクション データは calldata パラメータに保存されます。有名な EIP-4488 は、メイン チェーン トランザクションで伝送できるロール層のトランザクション データの量をさらに最適化するために、calldata のデータの各バイトのガス消費量を削減することを提案しました。具体的な圧縮効果については、以下に 2 つの異なる ZK ロールアップを比較したときの簡単なデータを示します。

(2) 提出された検証可能な情報が正しいことをどのように検証しますか?

最終的な状態遷移確認(トランザクションの確認も意味する)はステートルートの更新で決まるのですが、Rollup上のサブミッターは任意にトランザクションデータとステートルートを提出できるようですので、どうするか彼が提出した情報を確認してください。この情報は正しいですか?

この問題には通常 2 つの解決策があり、さまざまな解決策に応じて、ロールアップも 2 つのカテゴリに分類されます。

4:Optimistic Rollup

その名の通り、このソリューションは、送信者が実際に間違ったバッチを送信した悪者であることを不正証明によって証明しない限り、送信者によって送信されたバッチが正しいと楽観的に信じることを選択します。

(1) 以下は不正防止構造の簡単な例です (Vitalik に改めて感謝します):

提出されたバッチが間違っていることを証明するために不正証明を提出するには、以下の図の緑色の部分に含まれる情報が必要です。

1. 提出者によって提出されたバッチ

2. 前の状態ルートによって表されるマークル ツリーの一部 (実際には実際のアカウント ステータス情報を表す) と、この部分に基づいて完全なマークル ツリーを構築できます。

  • 2 番目の部分で構築されたマークル ツリーに基づいて、バッチで送信されたトランザクションの実行をシミュレートし、それによって新しいアカウントの状態、新しいマークル ツリー、および新しい状態のルートを取得しました。

  • 前の手順で取得した状態ルートとバッチ内の状態ルートを比較して、バッチが正しいことを確認します。

(2) 検証プロセス

私たちは、ステート ルートの信頼性を確保するために Optimstic のプロセスを論理的に整理しました。実際、提出者が悪事を阻止できるようにするために、提出者は資金を約束する必要があることがよくあります。彼の提出が間違っていると確認されたとき、約束した資金の一部が罰として減額されます。同時に、一部のソリューションでは、対応する不正証明を提出した検証者に資金が差し引かれ、不正証明を監視して提出する行動を奨励します。

OR と Plasma を比較すると、いくつかの類似点が見つかります。たとえば、どちらも不正防止メカニズムを使用しており、メイン チェーンへの OR の送信を監視するバリデーターの役割が必要です。ただし、OR はトランザクション データを同時にメイン チェーンに送信するため、OR の検証者は OR 自体にトランザクションを保存して記録する必要はありません。比較のために、読者が比較できるように、上の単純なアーキテクチャ図をここに示します。

5:ZK-Rollup

(1) Zk-rollup の核心

もう 1 つのタイプのソリューションは ZK ロールアップです。OR (楽観的ロールアップ) とは異なり、ZK ロールアップでは次のような基本的な仮定が行われます。

提出者が積極的に正しいバッチを提出できるとは思えません。さもなければ、それは法学における「有罪の推定」に似ています。トランザクション データと事後/前の状態のルートに加えて、送信者はバッチを送信するときに ZK-SNARK 証明書を保持する必要もあります。

有効性証明書有効性証明書"、送信されたバッチが正しいことを検証するために直接使用できます。この証明がロールアップ コントラクトに送信された後は、誰でもそれを使用してロールアップ レイヤー内のトランザクションの特定のバッチを検証できます。これは、ロールアップが実行されないことを意味します。確認のために送信してから 7 ~ 14 日待つ必要があります。

(2) 正当性証明と不正証明の違い

では、ZK-Rollup のような「有効性の証明」と、Plasma/Optimsitic Rollup で使用される「不正な証明」の違いを一般に理解するにはどうすればよいでしょうか?

まず、3 つのソリューションはすべて、レイヤー 2 でトランザクションを並べ替え、実行し、パッケージ化する必要があります。この役割を「実行者」と呼びます。

Plasma の実行者は実行結果のみを提出します。他人が信じるか信じないかの原則に従って、私を信頼できない場合は、チャレンジを開始する必要があります。チャレンジを開始するには、基礎となるトランザクション データを保存する必要があります。あなた自身。

ORも同様ですが、執行者は提出時に取引データも載せますので、それを信じるか信じないかの問題でもありますが、信じられない場合は取引データを基に自分で検証することも可能です。

しかし、ZK は違います。ZK は、あなたが私に挑戦するまで数日間待ちたくない、時間の無駄だと言いました、私は取引を確認するために急いでいたのです。したがって、ZK は送信時に証明書を直接生成し、この証明書をそれに配置し、送信中に検証を完了します。

同時に、プラズマ/OR の両方は、悪事を行った場合に執行者が損失を被ることを保証することを誓約する必要がありますが、ZK はそうではありません。なぜなら、他人にそれを信じる必要がなく、彼は罪を犯すたびに自分の無実を証明するからです。 。

この違いに加えて、もう 1 つの重要な点は、ZK-SNARK を使用すると、すべてのトランザクション データを送信することなく、このバッチのトランザクションの正当性を証明できることです。これは、ロールアップにとって非常に重要です。これについては、以下で説明します。

(3) ZK-Rollupの実装ロジック

まず、ZK-Rollup は本質的にロールアップ ソリューションであるため、引き続き次の 2 つのことを行う必要があります。

  • トランザクション データのバッチをパックして圧縮する

  • 新しいステートルートを生成する

唯一の違いは検証方法です。ZK-Rollup は検証者が不正証明プロセスを開始するのを待ちませんが、ZK-SNARK 証明を直接生成してバッチに追加し、メイン チェーン ロールアップ コントラクトに送信します。

図に示すように、提出されたコンテンツには OR と比較して ZK-Proof が追加され、検証者の役割は隠蔽されます。

ロールアップ コントラクトに送信すると、誰でも検証できるようになり、検証が成功すると、メイン チェーンのロールアップ コントラクトによってステート ルートが最新の送信データに更新されます。

(4) ZK-SNARK の有効性証明を生成するにはどうすればよいですか?

A ZK-SNARKとは何ですか?

ZK-SNARKの正式名称は「Zero-Knowledge Succinct Non-Interactive Argument of Knowledge」です。

簡潔な非インタラクティブなゼロ知識証明。それぞれの部分が何を意味するのか説明してみます。

Succint (簡潔): 実際に証明されたデータの量と比較して、この方法で生成される証明ははるかに小さくなります。

たとえば、一連のトランザクションが実際に存在し、発生していることを証明したい場合、生成される証明データの量は、これらのトランザクション自体のデータ量よりも少なくなければなりません。

非対話型 (対話なし): 証明が構築された後、証明者は検証者に簡単なメッセージを 1 回送信するだけでよく、通常は誰でも許可なく検証できます。

これは、ブロックチェーン上の ZK-Rollup または ZK アプリケーションにとって非常に重要です。一部の ZK 証明では、証明者と検証者の間で複数の対話が必要であり (色の問題が典型的な例です)、それをチェーンに置くと、ZK 証明が開始されることを意味します。複数のトランザクションが発生するため、コストの点で耐えられません。

引数: 限られた計算能力で証明者の攻撃に抵抗できる

この部分は、証明を生成するために使用される暗号化アルゴリズムの複雑さは、既存のコンピューティング能力条件下では許容可能な時間と経済的コストでは激しく解読できないことを意味します。

知識の理解: 何が証明されているかを知らずに証明を構築することは不可能です

これは ZK-Rollup にとっても非常に重要です。なぜなら、誰かが非トランザクション データに基づいて ZK Proof を作成し、それをメイン チェーン コントラクトに提出することを許可することができないからです。

最後になりましたが、重要なことです"Zero-Knowledge”:

ゼロ知識とは、証明者が検証者に対してステートメント(Statement)を証明する際に、有用な情報や証明されたエンティティ自体に関連する情報を一切開示しないことを意味します。

B 最も単純なゼロ知識証明の例の 1 つはこれです。

アリスは、ある金庫のパスワードを知っていることをボブに証明したいと思っています。そのパスワードが金庫を開ける唯一の方法ですが、ボブには金庫のパスワードを教えたくありません。どうすればよいですか?

偶然、ボブは、金庫の中にボブの元ガールフレンドが書いたラブレターがあり、ボブと元ガールフレンドの指紋が付いていることを知っていました。

そこでアリスはボブの後ろにある金庫を開け、ラブレターを取り出してボブに渡しました。

これは、アリスが金庫のパスワードを知っており、アリスがボブにパスワードを教えていないことを証明します。成功です。

C ZK-Rollup の ZK-SNARK プルーフを生成するにはどうすればよいですか?

簡単に言うと、ZK-SNARK プルーフの生成は次の手順に分かれています。

問題の論理検証ルールを決定します(残高やナンスが要件を満たしているかどうかのチェックなど)

論理検証ルールをゲート回路に変換 サークル問題

ゲート回路円問題を R1CS (ランク 1 制約システム、一次制約システム) 形式に変換します。

R1CS を QAP (二次演算プログラム) に変換する

この記事この記事

この部分がこれまでのすべての部分よりも複雑だと思われるのは、その通りです。また、複雑なのは、現在の ZK-Rollup ソリューション プロバイダーです。これが、現在の ZK-Rollup 研究開発の進捗と実際の適用が Optimstic Rollup よりも遅い理由の 1 つです。数学や暗号の専門家や Matter Labs の開発者ではない場合、知っておくべきことがいくつかあります。

  • ZK-SNARK 証明の生成は、マークル ツリーの検証よりもはるかに多くの計算と時間がかかります。

  • どの言語、コンパイル環境、仮想マシン、命令セットでも上記のプロセスの完了をシームレスにサポートできるわけではなく、追加の適応が必要です。

1点目ですが、これは大手ZKソリューションプロバイダーが現在取り組んでいる方向性です。 1 つ目は時間コストで、使用可能な ZK-Proof を生成するのに 1 時間かかる場合、間接的なユーザーの引き出し時間も長くなります。計算コストには 2 つの部分が含まれます。1 つは生成された ZK-Proof のデータ量、もう 1 つは Proof を検証するために必要な計算能力です。これら 2 つの部分が大きいほど、イーサリアムでより多くのガスを消費する必要があり、ZK-Rollup の最適化パフォーマンスに影響します。

2 番目の点については、これが現在 ZK-Rollup の開発を制限している主な理由です。 EVM 設計の開始時点では、開発者は ZK テクノロジが後に使用されることになるとは考えていませんでした。したがって、EVM 操作に使用可能なゼロ知識証明を生成することはほぼ不可能であるため、ZK-EVM の必要性が生じます。

D ZK が EVM と互換性を持つのはなぜそれほど難しいのですか?

DeFillama を開くと、TVL の最上位のレイヤー 2 ソリューションがすべて OR であることがわかります。これは、これらの OR ソリューションがすでに独自のネットワークを持っており、これらのネットワークが EVM 互換であるためです。開発者はシームレスに統合できます。イーサリアム上のスマート コントラクトは、ユーザーはネットワーク上でスワップ、モーゲージ、流動性の提供などの操作を実行することもできます。

ただし、ZK-Rollup でこれを達成するのは依然として難しく、多くの既存のソリューションは単純な支払いとスワップのシナリオしかサポートできません。

これはなぜでしょうか? まず、レイヤー 1 では、デプロイされたスマート コントラクトのバイトコードがすべてイーサリアム ストレージ (ストレージ アイテム) に保存されていることを明確にする必要があります。その後、トランザクションはピアツーピア ネットワークに伝播され、各トランザクションについて、各フル ノードは対応するバイトコードをロードし、EVM 上で実行して同じ状態を取得する必要があります (トランザクションは入力データとして使用されます)。

レイヤ2でもスマートコントラクトのバイトコードが格納項目に格納されますが、ユーザーの操作方法も同様です。ただし、そのトランザクションはチェーンの下にある集中型の zkEVM ノードに送信され、同時に zkEVM はバイトコードを実行するだけでなく、トランザクションの完了後に状態が正しく更新されたことを示す Proof を生成する必要もあります。最後に、レイヤー 1 コントラクトは証明を検証して状態を更新できます。この時点では、レイヤー 2 でトランザクションを再実行する必要はありません。

つまり、zk-Rollup でのトランザクションの実行は、まったく異なるロジックとパスです。同時に、zkEVM は、トランザクションの実行中に zk 回路証明を生成するようにも適応します。既存の EVM は、次のように ZK-SNARK 証明を生成します。質問:

  • ZK-SNARK に必要な一部の楕円曲線演算はサポートされていません

  • 従来の仮想マシンと比較して、EVM には独自のオペコードが多く、回路設計が困難です。

  • EVM は 256 ビット整数で実行され (ほとんどの一般的な仮想マシンが 32 ~ 64 ビット整数で実行されるのと同様)、ゼロ知識証明は「自然に」素数フィールドで実行されます。

これらは、EVM で ZK Proof を生成する際の問題の一部にすぎません。OR は、EVM 操作を実行するために仮想マシンを構築する必要もありますが、トランザクションの実行に基づいてトランザクションのパッケージ化とその他の機能を完了する必要があるだけであるため、はるかにシンプルです。 ZK-Rollupの場合、EVMと互換性を保ちながらZK-Proofを生成することが難しいことに加えて、この証明をLayer1で検証することは容易ではありません。

ZK-EVM の難しさについて詳しく知りたい場合は、この記事を読むことができます: https://hackmd.io/@yezhang/S1_KMMbGt

上記の内容を読むと、zk-Rollupの実装が技術的に高い難易度であることは否定できないので、より「単純な」Optimistic Rollup技術を直接使用してはどうでしょうか?

次に、これら 2 つのロールアップ手法を簡単に比較してみましょう。

6:Optimstic VS ZK

(1) 効率化(TPS・取引手数料)

ソース

ソース

@W3.Hitchhiker チームの貢献に感謝します。

この図から、ZK スキームが OR スキームよりも効率的であることがわかります。

ロールアップ スキームの場合、最も重要なことは、イーサリアム トランザクションでどれだけのレイヤー 2 トランザクション データを伝送できるかということであり、これは次の 2 つのパラメーターに関係します。

  • ロールアップによって圧縮されたトランザクションのガス消費量

  • イーサリアムブロックの最大ガス制限

このうち、Rollup は最初の点を解決できますが、ZK-Rollup 証明の保存と検証にはある程度のストレージ容量とガス (信頼できるデータは約 500K) を消費する必要があります。ただし、トランザクション圧縮が向上し、トランザクション データ ストレージの消費がガス消費の大部分を占めているため、ZK-Rollup は OR 効率の最適化よりも優れたパフォーマンスを発揮します。

さらに、表の中で ZKPort が最高の TPS とトランザクション コストの最適化を実現していることに気づくかもしれません。これは主に、ZKPort が使用する Validium が本質的に不正証明を ZK Proofs に置き換えるプラズマ ソリューションであるためです。ZKPort はトランザクション データを送信しません。その効率性ははプラズマチェーンの処理効率によって完全に決まりますが、セキュリティの観点からデータが利用できないという問題にも直面しています。

上記の計算はガス価格を 30 グウェイと仮定しており、イーサリアムの活動が急増するとガス価格がどのくらいになるかは誰もが知っています。このとき、Rollup、特に ZK スキームのコスト最適化効果がより顕著になります。

(2) 時間コスト

他の人が不正行為の可能性を反証するための不正防止メカニズムのため、Optimtisc Rollup での出金には 7 ~ 14 日間の提出期間が必要であると前述しました。

もちろん、ボバネットワークなどのオプティムスティックロールアップソリューションによって提案されている流動性プールメカニズムと同様に、ロールアップメカニズム自体とは独立したいくつかの動作を通じて引き出し期間を短縮することができます。

このようなシナリオを想定してみましょう。

アリスは、L2 に 5ETH 資産を持つ OR ユーザーです。

L1 上の別の流動性プール B は、ALice のような OR ユーザーに流動性を提供するために使用されます。

ここで、アリスは OR からすべての資産を取り戻したいと考えており、B とトランザクションを作成します。

アリスはボブから直接5ETHを受け取り、同時に一定の手数料を支払うことができます

7日後、アリスの資産のロックが解除され、アリスが取得した5ETHがプールに戻されます。

これは流動性プールにとって一定のリスクを伴うため、OR 契約を監視し、不正な提出に対してペナルティを得ることでリスクをヘッジすることができると同時に、請求される手数料はリスクを軽減するための準備金でもあります。

ただし、NFT は分割できず、流動性プールは単純に NFT をユーザーにコピーできないため、この方法は NFT には適していません。

ただし、ZK-Rollup にはこの問題はありません。送信者は送信時に無実を証明し、検証可能な ZK-SNARK 証明書を提供する必要があります。現在の ZK-SNARK 証明書の生成時間は数分かかる場合があります。ユーザーは、次のバッチが送信されて検証されるまで待つだけで済みます。

時間コストは OR の欠点ですが、ZK ロールアップの大きな利点の 1 つでもあります。

(3) 適応性

Optimsitic と ZK は両方とも、複雑な EVM コントラクト呼び出し操作への互換性と適応の問題に直面していますが、明らかに Optimsitic の方が実装が簡単です。

Arbiturm や Optimsim などの OR ソリューションには EVM 互換の仮想マシンがあり、イーサリアム メイン チェーンで発生するすべてのトランザクションを処理できます。 Uniswap/Synthetix/Curve などの一部の OG レベルの DeFi プロトコルも OR ネットワークに導入されています。

EVM 互換の ZK-SNARK を構築することは非常に難しいことが判明しており、これまでのところ、公的に利用可能な ZK-Rollup ソリューションはありません。ただし、最近良いニュースがあります。zkSync 2.0 パブリック テストネットは 2 月末に正式に開始されました。これは、イーサリアム テストネット上での最初の EVM 互換 ZK ロールアップでもあります。おそらく、ZK Rollupの正式な大規模な実際の使用は、私たちが思っているよりも早く行われるでしょう。

(4) セキュリティ

この質問に対する答えは明白で、OR の安全性は経済学から来ています。 OR がうまく機能するためには、メイン チェーン上のバリデータのグループを駆動して、いつでも送信者を監視し、不正証明の送信に備えるための合理的なインセンティブ メカニズムを設計する必要があります。送信者に関しては、ノードが誓約やその他の方法を通じて悪事を行ったことに応じた代償を支払うことを保証する必要もあります。

ZK のセキュリティは、ブロックチェーンの信頼の基盤と同様に、数学または暗号学に基づいています。つまり、コードが悪さをすることはありません。数学と暗号によって提供される保証は、人間の本性が悪さをしないという楽観的な信念よりもはるかに安定しています。

もちろん、現在のロールアップ メカニズム自体にはセキュリティ上の問題がありますが、ロールアップはデータをメイン チェーンに送信してデータの可用性の問題を解決します。しかし、トランザクションの処理、注文、圧縮、パッケージ化、送信の責任者が誰であるかについては議論していません。 Arbitrum、Optimism、StarkNet などの一部の現在の主流ソリューションは、シーケンサーと呼ばれる役割を使用します。シーケンサーは、独自に実行される単一ノードです。このアプローチの結果、高度な集中化が実現します。

分散化がすべてのセキュリティの前提であることはわかっています。このシーケンサー モデルの利点は、効率が高いことです。ロールアップがまだ探索段階にある場合でも、迅速に反復できます。これらのソリューションは、シーケンサーの分散化プロセスが次のように行われることも宣言しています。今後順次実施してまいります。たとえば、PoS または dPoS を使用してシーケンサー ノードを選択する、Metis のような新しいソリューションが検討されています。

(5) まとめ

上記の議論を表で視覚化してみましょう。

全体として、OR は現段階ではより成熟したソリューションであり、実際にそうです。Optimstic と Arbiturm の製品はすでにイーサリアム開発者に利用可能です。ただし、不正防止の仕組みを採用しているため、出金時間や安全性に疑問があり、コストの最適化もZKに比べて若干劣るのが現状です。

ZK Rollup の弱点は基本的に技術的な問題ですが、多くの優秀な開発者が関連研究に投資しているため、Vitalik を含むほとんどの人が、ZK Rollup が将来的にはより優れた拡張ソリューションになることに同意しています。

7: ロールアップは完璧ですか?

以上、3 種類のレイヤ 2 ソリューションについて説明しましたが、すでにある程度は理解できたと思います。実際、記事が書かれる順序は、開発者がレイヤー 2 拡張ソリューションを研究する順序でもあり、多くの場合、特定のソリューションの問題を発見した後、関連する問題を解決するために別のより良いソリューションが提案されます。このプロセスは、暗号化研究の分野だけでなく、すべてのエンジニアリング問題に拡張できます。

最も実行可能なソリューションが見つかるまで、アイデアが開発、テスト、反復、最適化されます。

ロールアップは、普遍性とデータの可用性の問題を解決すると同時に、セキュリティと効率の点でも優れているように思えます。それで、それは完璧なものですか?

答えは「いいえ」です。完璧な解決策は存在しません。ロールアップにも多くの問題があります。より優れているように見える ZK ロールアップでも、それらを回避することはできません。

(1) 効率の最適化には上限があります。

ロールアップとプラズマの主な違いについて話したとき、データの可用性の確保について話しました。ロールアップはトランザクション データをメイン チェーンに送信する必要があります。これが、ロールアップ スキームがプラズマに勝る主な理由です。

しかし、その一方で、オンチェーントランザクションは、ロールアップが依然としてイーサリアムメインチェーンの容量によって制限されることを意味することを確認する必要があります。

単純な計算:

現在のイーサリアムブロックの最大ガス制限: 12.5M ガス

オンチェーンに保存されるバイトあたりのデータコスト: 16 ガス

ブロックあたりの最大バイト数: ~781,000 バイト (12500000/16)

ETH 転送を実行するためにロールアップに必要なデータ量: 12 バイト (前のセクションのガスコストを参照)

ブロックあたりのトランザクション数: ~65,000 (781,000 バイト/12 バイト)

イーサリアムでの平均ブロック時間: 13 秒

TPS:~5000(65,000 tx/13 s)

ここでは多くの仮定を立てます。たとえば、すべてのトランザクションが単純な ETH 送金であると仮定します。実際のトランザクションには複雑なコントラクト呼び出しが多数含まれており、ガス消費量は多くなります。また、ZK-Rollup の場合は、ZK-Proof を検証するコストも計算する必要があります (コストの半分は約 500K ガスです)。

それでも、Rollup が達成できる TPS はわずか約 5000 です。また、Plasma メカニズムの使用によってもたらされる直接的な効率の最適化が Rollup よりもはるかに高いこともわかりました。

イーサリアム財団もこの問題をよく認識しており、現時点での主な解決策はシャーディング + ロールアップであり、ロールアップによってもたらされる TPS はさらに 1 桁増加します。

(2) 流動性の断片化:

現在のマルチチェーン構造の影響で、チェーン自体の流動性の細分化がますます深刻になっています。

しかし、複数の技術的ソリューションと複数のソリューションが存在するため、ロールアップネットワークの数は今後も増え続ける一方、より深刻な流動性の断片化を引き起こすことになります。

イーサリアムとそのレイヤー2ネットワークの現在のTVLの概要

良いニュースは、クロスチェーン通信がこの問題を解決できるということであり、その代表的な出来事は、Synthetix がすでにイーサリアムメインチェーンとオプティミズム上の負債プールの統合に取り組んでいることです。このプロセスが円滑かつ円滑に完了すれば、メインチェーンとサブチェーンの流動性融合の動きが一定程度促進されるものと考えられる。

結局のところ、合成資産プロジェクトの負債プールモデルは、現在より一般的な流動性プールモデルよりもはるかに複雑であり、Uniswapなどの主流のDeFiプロジェクトがこのプロセスを継続することが予測されます。

(3) コミュニケーションの困難や技術的な障害による構成可能性の低下:

前の質問では、流動性を分割する通信の問題について話しました。この現象は、メインチェーン dapp とサブチェーン dapp の間の相互作用にも当てはまります。イーサリアム上に構築されたすべての新しいプロトコルは、レゴ ブロックのようなものです。その他のプロトコルは、その上に簡単に構築できることが、DeFi が急速に成長している理由の 1 つです。

通信の問題を解決できない場合、サブチェーン上の dapps は独自のエコシステムを再確立する必要があり、これによりリソースの浪費が増大します。サブチェーンとメインチェーンの間だけでなく、サブチェーンとサブチェーンの間でも通信メカニズムを構築する必要があります。

繰り返しになりますが、優秀な開発者もこれに取り組んでいます。彼らがこれらの操作とプロセスを簡素化してくれることを願いましょう。結局のところ、Layer1 自体の操作が十分に面倒であり、Layer2 の複雑さが加わると、Web3 の世界の敷居はさらに高くなります。

(4) 集中化リスク

エピローグ

エピローグ

全文は10,000文字を超え、私の予想をはるかに上回りました。イーサリアム自体の拡張は非常に壮大かつ複雑なテーマです。この記事では、Layer2 ソリューションの一部のみが関係します。 Layer1 拡張ソリューション (シャーディング)、および Side Chain、Validium などの他の Layer2 ソリューションについては言及されていません。実際、イーサリアムの拡大は、一度に解決できる単一の解決策ではありません。多くのソリューション プロバイダーも複数の道を模索しており、Polygon のような企業は、多数の異なるタイプのレイヤー 2 ソリューションに投資しています。

同時に、記事内の多くの内容は記事の長さによって制限されており、レイヤー 2 とレイヤー 1 間の送信にどのような通信サポートが必要かなど、まだ検討する必要があります。不正証明/有効性証明がレイヤー 1 でどのように実装されるか、さまざまな ZK/OR 実装スキーム間の具体的な違いなど。これらのことを理解することは、Layer2、特にロールアップ展開を理解したい研究者にとって非常に重要です。記事内のいくつかの概念の理解と整理を容易にするために、より一般的な概要を作成しました。たとえば、OR/ZK はトランザクション データ圧縮などの点で非常に異なるソリューションを持っています。記事で使用されている Vitaik の例は次のとおりです。 ZK ソリューションにさらに偏っています。執筆の過程で、いくつかの優れた Layer2 コンテンツも参照し、本文中と本文の最後にマークを付けましたが、皆様が関連する認識をさらに確立するのに役立つ、より良いコンテンツがより多く登場することを期待しています。

最後に、紹介した 2 つのロールアップ ソリューションの観点から、Optimistic Rollup が市場をリード、利用可能な製品を発表しながら、徐々に主流の Dapps をエコロジーに統合するように引き付けています。関連する開発者の多大な貢献がなされていることは否定できません。しかし参考文献:

参考文献:

1.An Incomplete Guide to Rollups (Vitalik)

2.W3hitchhiker チームによる 4 つのレイヤ 2 ソリューションのコスト比較

3.Scorll Tech による zkEVM 実装の解釈

先知实验室
作者文库