paint-brush
ZKBase のテクニカル分析: スケーラブルで安全な ETH トランザクションを実現する高性能 ZK ロールアップ@zkbase
2,865 測定値
2,865 測定値

ZKBase のテクニカル分析: スケーラブルで安全な ETH トランザクションを実現する高性能 ZK ロールアップ

ZKBase6m2024/08/07
Read on Terminal Reader

長すぎる; 読むには

ZKBase は、ZK スタックとマルチ GPU 証明器に基づく高性能 ZK-Rollup です。このソリューションは、トランザクション処理機能を強化し、コスト効率の高いネットワーク エクスペリエンスを提供します。その主な利点は、ゼロ知識証明 (ZKP) テクノロジの採用にあり、オフチェーン トランザクションを迅速に検証できます。
featured image - ZKBase のテクニカル分析: スケーラブルで安全な ETH トランザクションを実現する高性能 ZK ロールアップ
ZKBase HackerNoon profile picture


ZKBase は、ZK スタックとマルチ GPU 証明器に基づく高性能 ZK-Rollup です。このソリューションは、トランザクション処理機能を強化し、コスト効率の高いネットワーク エクスペリエンスを提供します。その主な利点は、ゼロ知識証明 (ZKP) テクノロジの採用にあります。これにより、トランザクションのプライバシーとデータの整合性を維持しながら、オフチェーン トランザクションを迅速に検証および確認することができます。すべての有効性証明は Ethereum 上で検証されるため、ユーザーは L1 と同じセキュリティ保証を享受できます。ZKBase は Ethereum と同様に動作しますが、スループットが高く、手数料が低くなっています。スマート コントラクトは Solidity/Vyper で記述されており、他の EVM 互換チェーンと同じクライアントを使用して呼び出すことができます。この記事では、ZKBase のコア エンジニアリングと技術実装を紹介します。

1. ZKBaseの主要コンポーネント

Tree および TreeBackup : これらのコンポーネントは、RocksDB を使用して L2 ストレージ ツリーのローカル コピーを維持します。データベースは最新の状態ルート ハッシュと同期された状態を維持し、現在のシステム状態を継続的に反映します。


StateKeeper/VM : トランザクションを実行し、囲まれたブロックをローカルの RocksDB データベースに安全に保存して、データの整合性と継続的な状態更新を保証します。


スマート コントラクト: Ethereum メインネットにデプロイされたこれらのスマート コントラクトは、オフチェーンから送信されたゼロ知識証明 (ZKP) を検証します。検証が成功すると、これらのコントラクトは Ethereum ネットワーク上のアカウント状態を更新します。


GPU 証明者: ゼロ知識証明を通じて安全で効率的なトランザクション検証を保証する ZK ロールアップ テクノロジー。Ethereum メインネット外でトランザクションのバッチが発生すると、ZK 集約システムは複数のトランザクションを Prover によって計算された単一の「有効性証明」に圧縮し、バッチの正しさを証明します。この証明はその後 Ethereum ネットワークに送信され、オフチェーンで発生する大量のトランザクションを迅速かつ安全に確認できるようになります。


ブリッジ: ZKBaseは、ZKBaseとEthereumメインネット間で資産を安全に転送するためのブリッジメカニズムを提供し、2つのプラットフォーム間の相互運用性と資産の流動性を保証します。

2. ZKBaseワークフロー

ユーザーは、アプリケーション プログラミング インターフェイス (API) または L1 にデプロイされたコントラクトを介して L2 リクエストを開始できます。送信されたリクエストはメモリプールに入り、実行を待機します。特に、L1 から発信されたトランザクション (入金など) は、迅速に処理されるように専用の L1 優先キューに保存されます。


メモリプールのストレージ構造は、btreeset (btree によって実装されたセット) です。インデックス構造は次のとおりです。



ここで、fee_data は実際のスコア計算には関与しませんが、手数料要件を満たさないトランザクションを除外するのに役立ちます。スコアはタイムスタンプでソートされ、タイムスタンプが同一の場合はアドレスでソートされます。

メモリプール内のトランザクションは、State Keeper 内のメモリプール フェッチャー コンポーネントによって管理されます。期限切れのトランザクションを除き、標準トランザクションは、Btree トラバーサルによって定義された順序でメモリプールからフェッチされ、データベースに記録されます。その後、標準トランザクションは State Keeper/VM によって処理され、実行され、状態ツリーの更新に使用されます。


ブロック レイアウト図は、ブロック内のトランザクションの構成と、L1 バッチ内の L2 ブロックの配置を示します。



各 L1 バッチを開始するには、オペレーターはバッチのタイムスタンプ、シーケンス内の位置、前のバッチのハッシュ値などの主要な詳細を入力する必要があります。



マークルツリーのルートハッシュは、このプロセスの基礎となるルートハッシュとして機能し、バッチの有効性とトランザクションの信頼性を保証します。同時に、State Keeper は特定の L2 ブロックまたは L1 バッチをいつ確定するかを決定する権限を持ち、それによってその状態を決定します。この決定は、conditional_sealer モジュールによって管理される一連の定義済み基準によって制御されます。これらの基準には、トランザクション数、サイズ制限、ガス使用量しきい値などのパラメータが含まれます。トランザクションを処理した後、State Keeper はどのシール条件が満たされているかを確認します。


conditional_sealer は、次のものを含む SealCriteria レジストリを管理します。


  • 取引数の制限、

  • L2ガス制限、

  • 公開されるデータの量の上限などの規制。


決定シナリオには、NoSeal、IncludeAndSeal、ExcludeAndSeal、および Unexecutable の 4 つがあります。最初の 2 つのケースでは、プロセスは同じで、実行後の状態が State Keeper で更新されます。ExcludeAndSeal は、トランザクション実行をロールバックし、次の L2 ブロックに含まれるようにキューに戻すことで、定義済みのバッチ制限を超えるトランザクションを処理します。Unexecutable 状況が発生した場合、トランザクションは実行できず、拒否されます。


各バッチの終了時に、ブートローダはプレースホルダ L2 ブロックを生成し、トランザクションを完了して次のサイクルに備えます。このブロックはほとんど空ですが、内部操作に不可欠であり、ブートローダとオペレータ間の手数料の移動を記録する転送イベント ログが含まれています。時間の正確性を確保するために、バッチと最後のサブブロックのタイムスタンプは、予想される L1 時間枠とクロスチェックされ、時間関連の問題に対するシステムの耐性が強化されます。


バッチが確定すると、証明者はブロックの実行を検証するための暗号証明を生成します。ZKBase では、証明者の責任は ZKBase Ethereum Virtual Machine (EVM) の正確な実行を証明することです。この証明は、Ethereum ネットワーク上のスマート コントラクトによって検証されます。証明が生成されると、証明者はそれを L1 トランザクションにパッケージ化し、ETH_Sender に送信します。ETH_Sender は、トランザクションを Ethereum メインネットにデプロイされた ZKBase コントラクトに転送し、さらに処理します。


Ethereum メインネットは証明の正確性を検証し、検証が成功するとそれに応じて状態を更新します。


プロセス全体を通じて、EthWatcher はデポジットやシステム アップグレードなどの特定の L1 イベントを継続的に監視し、Ethereum メインネットとの同期を確保します。

3. 複数のGPUプローバアーキテクチャ


このアーキテクチャは、Postgres データベースを活用してデータを共有し、複数の GPU 証明器間での並列計算を可能にして証明生成の効率を高めます。主なコンポーネントは次のとおりです。


オペレータ: レイヤー 2 サービスを提供するサーバー。


証明ゲートウェイ: オペレータと証明サブシステムを接続する通信モジュール。


Witness Generator : 証明計算タスクを生成し、中間成果物を保存します。


ベクトル ジェネレーター: すべての計算タスクを GPU 計算に適したベクトル形式に集約し、証明者に送信します。


証明者:証明の実際の計算と検証を実行します。


コンプレッサー:最終証明を SNARK 形式に圧縮します。

証明生成ワークフロー

バッチ生成: オペレーターはトランザクションを収集し、新しいバッチを生成します。


バッチ受信: 証明者ゲートウェイはオペレーターから新しいバッチを取得し、ゼロ知識証明を生成する準備を開始します。


データベース挿入: Prover Gateway はバッチ情報を Postgres データベースに挿入します。その後のデータ処理はデータベースと直接やり取りし、対応する入力テーブルからデータを取得し、処理されたデータを関連する出力テーブルに配置します。


証人生成: この初期段階は、ユーザーがトランザクションを開始し、証人を生成するときに発生します。証人は、トランザクションの詳細を一切明かさずに、ネットワークのコンセンサス ルールに基づいてトランザクションの有効性を証明します。新しいトランザクション証人は、バッチで収集され、処理されます。各バッチでは、次のプロセスが実行されます。


  • 基本回路ウィットネスジェネレータ

  • リーフ集約証人ジェネレータ

  • ノード集約

  • スケジューラ


ベクトル生成: ベクトル ジェネレーターは回路を統合して証拠ベクトルを生成し、GPU の計算能力の使用を最適化します。


証明計算: 証明者は GPU を利用してゼロ知識証明を計算し、証明計算の正確性を検証します。


圧縮: コンプレッサー モジュールは証明を圧縮してデータ サイズを縮小し、SNARK 形式に変換します。

4. 結論

ZK スタックとマルチ GPU 証明器上に構築された ZKBase は、高性能なレイヤー 2 スケーラビリティを実現します。ただし、Ethereum スケーリング ソリューション ZK-Rollup は、依然として多くの技術的課題に直面しています。今後も、ZKBase は、分散型シーケンスと分散型 ZK 計算パワー ネットワークの実装について研究と探求を続けていきます。