zkSync 2.0: こんにちは、イーサリアムファイナンス

※自動翻訳

前書き
主な成果
zkSync 2.0とイーサリアムの比較

前書き

最大の技術的課題に直面し、EVM 互換環境でのスマートコントラクトの展開に向けて全力で取り組み始めています。テストネットの最初のバージョンがリリースされました。すでにブロックエクスプローラーを使用して、zkSync 2.0 のアクティビティを表示できます。この記事では、各主要コンポーネントについて詳しく説明し、進捗状況の更新を提供し、次のバージョンの計画を立てます。

主な成果

暗号化に関しては、zkEVM の命令セットが完成し、回路と実行環境の両方の実装が完了しました。

コンパイラに関しては、Solidity と Zinc で記述されたスマートコントラクトを zkEVM バイトコードにコンパイルできるようになりました。

コアインフラストラクチャに関しては、フルノード統合が完了し、コンパイルされたスマートコントラクトを正常にデプロイして実行できます。

zkEVM とコア 2.0 インフラストラクチャは公開する準備ができていますが、すべてのエッジケースを適切にカバーするには、コンパイラがさらに作業を行う必要があります。より包括的な開発者体験を提供するために、コンパイラーが 100% 信頼できるようになった直後に、zkEVM、コンパイラー、およびコア SDK へのアクセスをオープンにすることにしました。

zkSync 2.0とイーサリアムの比較

ほとんどのものは同じように見え、同じように感じます。いくつかの重要な違いを次に示します。

Solidityスマートコントラクト

イーサリアムのほとんどのオペコードをサポート!ただし、いくつかの例外があります。

このバージョンは ADDMOD、SMOD、MULMOD、EXP、および CREATE2 オペコードをサポートしていませんが、将来的にはサポートされる予定です。
現時点では KECCAK256 オペコードをサポートしていませんが、そのすべての呼び出しを別の衝突防止ハッシュ関数の呼び出しに自動的に置き換えます。 KECCAK256 は、後でプリコンパイラとして導入される予定です。
イーサリアムが削除する予定であるため、SELFDESTRUCT オペコードを含めないことにしました。
完全な 256 ビット XOR/AND/OR オペコードのサポートを削除する可能性があります。これらは、ビットマスク用にコンパイルされた Solidity コードにのみ存在するためです。これは、コンパイラが他のオペコードを使用して実行できます。

費用

zkSync 2.0 では、ガスの概念が異なります。取引価格は、現在のL1ガス価格（通話データ公開による）とZKPの発電コストにより変動します。スマートコントラクトの呼び出しには、最大数の zkEVM ステップとストレージ書き込みパラメーターがあります。

Web3 API

次のバージョンには、Ethereum ドキュメントで定義されている Web3 標準と互換性のある Web3 API 実装が含まれます。イベントはすぐに利用でき、すべてのサービスを簡単に統合できます。

zkSync には、コミットされたブロックと最終ブロックの概念など、L1 にはない機能が含まれています。したがって、開発者がデータをより正確に制御できるようにする他の方法があります。 Web3 クライアントコードはイーサリアムと同じデータを受け取りますが、「zksync_」名前空間を使用して特別な情報を要求できます。

zkSync には複数のトランザクションタイプがあり、EIP712 署名を使用しているため、「eth_sendRawTransaction」データの形式は L1 とは異なります。ただし、エンコーディングはイーサリアム ABI に対応しているため、サポートすることは難しくありません。

取引に署名する

zkSync 2.0 のトランザクションは、次の 2 つの方法で承認できます (優先度キューメカニズムを除く)。

ユーザーは、EIP712 メッセージに署名することで、通常の Ethereum ウォレット (Metamask や WalletConnect ウォレットなど) を使用してトランザクションに署名できます。
どのアカウントでも公開鍵を設定して、トランザクションに署名するための内部 Schnorr 署名を作成できます。これにより、スマートコントラクトベースのウォレットは、L1 メッセージを送信するための追加コストなしで zkSync 2.0 と対話できます。

ストレージ効率の向上

ストレージスロットカバレッジは、ブロックごとに 1 回だけ適用されます。つまり、複数のユーザーが 1 つの AMM コントラクトを操作する場合、AMM コントラクトのストレージスロットは 1 回だけ上書きされます。これにより、シーケンサーは後でユーザーに 1 回の書き込みの共有コストを払い戻すことができます。

プリコンパイル済み

「事前コンパイル」メカニズムは計画されていますが、後でリリースされます。最初に、keccak256、sha256 ハッシュ、および ECDSA 回復プリミティブをサポートする予定です。要件と複雑さに応じて、Blake2f ラウンド関数 (現在の形式ではイーサリアムではほとんど使用できません) など、他のプリコンパイルを検討できます。

さらなる制限

zkSync 2.0 の最初のイテレーションでは、適切なアカウンティングメカニズムが実装されるまで、トランザクションごとに 32 のスマートコントラクト呼び出しの追加制限が課される場合があります。

実行追跡には厳しい制限がありますが、これは Ethereum ブロックサイズの現在の制限に匹敵するものであり、ほとんどのプロトコルには影響しません。

より多くの制限があるかもしれませんが、私たちの目標は、最終バージョンでそれらを最小限に抑えることです。

zkSync 2.0 アーキテクチャの詳細な理解

ブロックチェーンのトリレンマについて聞いたことがあるかもしれませんが、イーサリアムを拡張する場合、4 番目の要素であるプログラマビリティがあります。現在のすべてのスケーリングソリューションは、スケーラビリティのためにセキュリティ、分散化、およびプログラマビリティをある程度犠牲にする範囲内に存在します。 zkSync 2.0 の設計は、次の 2 つの技術的ブレークスルーを組み合わせて、4 つの機能すべてを最大化します。

zkEVM: EVM 互換の zkRollup を駆動するエンジンであり、L1 セキュリティと信頼性のスマートコントラクトをサポートする唯一のソリューションです。
zkPorter: スケーラビリティが集約よりも 2 桁高いオフチェーンデータ可用性システム。

現在のコンセンサスは、Eth2 データシャーディングが 2022 年末に到着し、分散化を犠牲にすることなく、指数関数的に大きなデータ可用性レイヤーを提供するというものです。 Eth2 データスライスと組み合わせた zkSync の zkRollup テクノロジは、4 つの要素を犠牲にすることなく 100,000+ TPS に到達する究極の目標です。

状態ツリー

zkSync 2.0 ステートツリーは、イーサリアムの完全な 160 ビットアドレス空間をカバーしています。各アカウントは、状態の zkRollup 部分または zkPorter 部分に存在します。 zkRollup と zkPorter のアカウントは、データの可用性を確保するという 1 つのコンポーネントを除いて、まったく同じです。 zkRollup トランザクションデータは calldata を通じて Ethereum に公開され、zkPorter トランザクションデータは zkSync Guardian ネットワークに公開され、zkSync トークン所有者はエクイティの証明に参加します。

データが公開される場所は、コストとセキュリティのトレードオフです。 zkPorter トランザクションは、集約トランザクションよりもはるかに安価ですが、資金が凍結される可能性があります。ただし、zkRollupとzkPorterのアカウントの有効性は、ゼロ知識証明とイーサリアムによって保証されています。つまり、zkPorter の資金は凍結することしかできず、盗むことはできません。

zkRollup アカウントと zkPorter アカウントの相互運用性と構成可能性により、すべてのユーザーが zkSync の第一級市民になる機会が得られます。 zkRollup 側にデプロイされた Uniswap は、最低の手数料と引き換えに zkPorter アカウントからアクセスできます。 zkSync 2.0 は、金融セクター全体のユーザーが参加できるように設計されたシステムです。

暗号化

ほとんどの場合、zkEVM と呼ばれる私たちの VM は、EVM の 1 対 1 のコピーではありませんが、Solidity で記述されたコントラクトの 99% を実行し、回復中や例外中など、同じ動作を維持できるように設計されています。同時に、zkEVM は、回路でゼロ知識証明を効率的に生成するために作成されました。

これは、私たちの証明システムに大きな変更を加えることなく行われ、カスタムゲートとルックアップテーブル (UltraPLONK と呼ばれることが多い) と Ethereum の BN-254 曲線を備えた PLONK を引き続き使用します。これは、2020 年 6 月以降、zkSync 1.0 および同じ認証システムを使用する他のプロジェクトで実際の戦闘で認証システムがテストされているためです。

繰り返しになりますが、何ヶ月にもわたる苦労の末に、zkEVM の命令セットが完成し、回路と実行環境に実装されたことをお知らせできることを嬉しく思います。

ここには重要な違いがあります。実行環境の回路と実装は分離され、異なる目的で使用されます。回路の仕事は、実行追跡の証拠を生成し、証人を提供することですが、これは非常に遅いです。一方、実行環境は、Rust での zkEVM の直接実装であり、効率的で高速です。証明を生成して実行するために回路に依存している場合、トランザクションが完了するまでに数時間かかります。証明の生成と単純な実行の分離により、zkSync でのトランザクションの即時決済が可能になります。

次に、zkEVM とコンパイラを組み合わせ、再帰を組み合わせることに焦点を当てます: N ブロックの証明を発行できるブロック間の再帰と、ブロック間の違いを集約するブロック内の再帰論理部分のサブ証明.は簡単な部分です！ 2020 年 6 月以降、zkSync 1.0 のメインネットは、ブロック間の再帰的集約の証明を使用しています。ブロック内再帰と zkEVM の仕組みの詳細については、このビデオの説明をご覧ください。

翻訳者

コンパイラはLLVMフレームワークを利用して構築されているため、フロントエンドはYul→LLVM IR、バックエンドはLLVM IR→zkEVMバイトコードと見なすことができます。 LLVM の採用には、いくつかの主要な利点があります。

LLVM 最適化フレームワークは比類のないものです。LLVM IR から最も効率的な zkEVM バイトコードを生成します。
Solidity または Zinc の新しいバージョンでは、コンパイラのフロントエンドがすべての変更を処理し、LLVM によってコンパイラのバックエンドを変更する必要がなくなります。
将来的に、開発者がネイティブの Rust または Javascript でスマートコントラクトを記述したい場合、言語のコンパイラフロントエンドを構築するだけで済み、スマートコントラクトは zkSync でそのまま使用できます。

コンパイラの安全性は私たちにとって最も重要であり、複数のテストに合格しています。

Zinc および Yul コンパイラでの字句、文法、意味のテスト。
当社独自の Zinc と Solidity の統合テストは、ソースコードの解析からコントラクトの展開、zkSync でのトランザクションの実行まで、スマートコントラクトのライフサイクル全体で実行されます。
統合テストツールに適した、Solidity リポジトリから統合された広範なテストスイート。

各キットにはすでに何千ものテストが含まれており、この数を少なくとも 1 桁増やす予定です。

私たちの 2 つのコンパイラは、2 つの言語でシンプルなスマートコントラクトを正常にデプロイして実行しました。ただし、完了する必要がある最適化が他にもあります。また、いくつかの複雑な LLVM IR ステートメントを zkEVM バイトコードに変換する必要があります。したがって、コンパイラがより堅牢な状態になるまで、リリースしないことにしました。

コンパイラーが完成したら、Zinc をより表現力豊かで機能豊富にすることに集中し、ネイティブ Rust を使用してスマートコントラクトを記述できるように、Rust コンパイラーフロントエンドを構築します。

コアインフラ

zkSync 2.0 のコアは、いくつかの主要な役割で構成されています。

フルノード