Albert

Polygon Chain Development Kit、オープンソースフレームワークで、Ethereum 上で ZK 駆動の L2 を迅速に展開するためのものです。

Polygon CDK で開発されたチェーンの高度なアーキテクチャは、L1 ブロックチェーンのようにビジネスルールをカスタマイズできます。

なぜ Polygon CDK を選ぶのか？#

Polygon CDK の設計原則

• 高度にモジュール化されており、開発者は実行環境からガストークンまで、自分のニーズに応じてチェーンをカスタマイズできます。
• 高度なスケーラビリティ、CDK で開発された L2 は取引速度を向上させることができます。
• 統一された流動性、CDK で開発されたチェーンは、Polygon 2.0 L2 エコシステム内でのチェーン間の資産移転を保証します。
• 独立した DA、CDK で開発されたチェーンは専用の DA と DAC を持ち、強力なチェーン外データアクセスと信頼性を提供します。
• 組み合わせ可能な操作性、LXLY Bridge を利用して、チェーン間のシームレスな相互作用と資産交換を実現します。
• ほぼ瞬時の最終確認、Polygon CDK で展開されたチェーンは暗号的に安全で、完全なノードなしで取引の完全性を確保します。

主要な要素

• Ethereum のスケーラビリティ、 CDK チェーンは Ethereum を拡張します。
• ビジネスロジックのカスタマイズ、CDK チェーンは EVM を完全にサポートし、カスタムガスリミット、op コードの互換性、技術統合を許可します。
• プライバシーオプション、CDK チェーンはプライベートなアプリチェーンを作成できます。プライバシーを優先する人々に選択肢を提供し、顧客がアプリデータの機密性を維持しながら、ブロックチェーン技術の利点を享受できるようにします。
• コンプライアンス指向、CDK チェーンはネットワーク主権とコンプライアンスを実現し、ネットワークの管理者が地元の規制に準拠した管理者を選択できるようにし、地域の規制要件を確保します。
• 幅広い Web3 サポート、CDK チェーンは zkEVM スタックの直接フォークであり、サービスの移植が容易で、包括的なエコシステムを活用しています。

Polygon CDK データ可用性#

データ可用性は取引の実行とデータストレージを分離し、取引データがチェーン外（off-chain data）に留まることを許可しながらも、検証に使用できるようにし、スケーラビリティを大幅に向上させ、コストを削減します。

Polygon CDK Validium は、zkEVM 基盤に基づくユニークな拡張ソリューションで、zkEVM に DAC を統合した独自のデータ可用性手法です。

Polygon CDK フレームワーク内で、データ可用性委員会（DAC）メンバーは DA ノードを運営し、チェーン外データの安全性、可用性、完全性を確保します。チェーン外データは DAC によって管理され、可用性が保証されます。

データ可用性委員会は、全員がチェーン上のイベントに基づいて L2 状態を再構築するために必要なデータにアクセスできることを確認するという核心的な責任があります。これは、L2 オペレーターがオフラインであっても、ユーザーがその資産のデータにアクセスできることを意味します。

CDK で開発されたチェーンでは、DAC が安全なノードの連合として機能し、チェーン外データアクセスを確保します。

DAC の利点：

• 取引手数料の低下 計算要件が減少し、手数料も低下します。
• 状態プライバシー データの完全性を確保します。

DAC メンバーは L1 上のスマートコントラクトによって管理されます。シーケンサーは L2 バッチデータを DAC メンバーに送信し、L1 にハッシュ値（accumulated input hash）をアップロードするだけで、完全な L2 取引データは送信しません。

• シーケンサーは ECC 秘密鍵を持ち、L2 バッチデータを DAC に送信する前に、自分の秘密鍵で署名します。

// シーケンサー署名付きのシーケンス
type SignedSequence struct {
	Sequence  Sequence       `json:"sequence"`
	Signature types.ArgBytes `json:"signature"`
}

// シーケンサーがL1に送信するデータといくつかのメタデータ
// 整理された取引リスト、シーケンスと呼ばれます
type Sequence struct {
	Batches         []batch.Batch `json:"batches"`
	OldAccInputHash common.Hash   `json:"oldAccInputhash"`
}

// バッチ構造体
type Batch struct {
	Number         types.ArgUint64 `json:"number"`
	GlobalExitRoot common.Hash     `json:"globalExitRoot"`
	Timestamp      types.ArgUint64 `json:"timestamp"`
	Coinbase       common.Address  `json:"coinbase"`
	L2Data         types.ArgBytes  `json:"batchL2Data"`
}

• DAC メンバーはシーケンサーに API（datacom サービス）を提供します。
  • L1 コントラクトからシーケンサーアドレスを読み取ります（更新があれば、コントラクトを監視して更新します）。
  • シーケンサーから送信された L2 バッチデータを受信および保存します（CDK ではこの部分を offchain data と呼びます）。
    • シーケンサーアドレスを検証します（シーケンサーの ECC 署名を復元します）。
    • データを保存します。
    • Copy

      func (db *DB) StoreOffChainData(ctx context.Context, od []offchaindata.OffChainData, dbTx pgx.Tx) error
      

  • 保存に成功した後、accumulated input hash に署名し、シーケンサーに返します（各 DAC メンバーは ECC 秘密鍵を持っています）。
  • コアコード
    • Copy

      func (d *DataComEndpoints) SignSequence(signedSequence sequence.SignedSequence) (interface{}, types.Error)
      

zkEVM と Validium の展開の違い#

• zkEVM 展開

  • zkEVM ノード、Polygon zkEVM ネットワークを管理し、取引を処理し、状態を維持し、L1 と相互作用します。

    • コンポーネントには、JSON RPC、プール DB、シーケンサー、状態 DB、同期者、集約者、証明者が含まれます。
    • コードベース：https://github.com/0xPolygonHermez/zkevm-node

  • zkEVM コントラクト、Ethereum 上に展開された一連のコントラクト、主にPolygonZkEVM、PolygonZkEVMBridge、PolygonZkEVMGlobalExitRootがあります。

    • コードベース：https://github.com/0xPolygonHermez/zkevm-contracts

• Validium 展開

  • データ可用性層
    • コードベース：https://github.com/0xPolygon/cdk-data-availability
  • Validium 拡張を持つ zkEVM ノード
    • コードベース：https://github.com/0xPolygon/cdk-validium-node
  • Validium 専用 DAC コントラクト、主に **CDKDataCommittee.solとCDKValidium.sol** があります。
    • コードベース：https://github.com/0xPolygon/cdk-validium-contracts

zkEVM vs. Validium

zkEVM ノードの主要コンポーネント#

• 集約者
  • L2 の状態の有効性証明を L2 に提出する責任があります。
    • シーケンサーから取引のバッチを取得する必要があります。
    • プローバーと相互作用して zk 証明を取得し、複数の証明を単一の証明にまとめます。
    • EthTxManager を使用して、集約された zk 証明を L1 に送信します。
• プローバー
  • バッチ取引の zk 証明を生成する責任があり、これらの証明は L1 で L2 の状態を検証するために使用されます。
• シーケンサー
  • L2 取引の順序付けを担当し、L2 状態を前進させます。
    • 取引の順序付け、tx プールから取引を取得し、状態に追加します。
    • 状態遷移、エグゼキュータと協力して取引を実行し、状態を更新します。
    • 信頼できる最終確認、シーケンサーが取引を状態に追加すると、その情報を他のノードと共有し、取引が最終確認されます（シーケンサーの信頼レベル）。
      • 他のノードは zkp 確認を受け取った後に最終確認されます。
• SequenceSender
  • 整理された取引リスト（シーケンスと呼ばれます）を L1 に送信します。
    • 実際に送信されるのはシーケンスのフィンガープリント（ハッシュ値と理解できます）。
    • EthTxManager を使用して L1 取引を処理します。
  • また、データ可用性層と協力して、すべての取引データがチェーン外でアクセス可能であることを確認します。
• 同期者
  • ノードのローカル状態と Ethereum L1 を同期させる役割を果たし、L1 と L2 ノードの間の橋渡しをします。
    • L1 コントラクトのイベントを監視します。
    • L1 イベントに基づいて、データ可用性層からデータをダウンロードします。
    • 状態を更新し、ローカル状態をメインネットと一致させます。
    • L1 ブロックの再編成を処理します：ブロックチェーンの再編成を検出し、データの完全性を維持します。
• エグゼキュータ
  • 状態遷移の実装、すなわち VM の実装です。
    • バッチ実行：一連の取引の実行要求を受け取ります。
    • EVM 互換の取引処理。
    • 実行から必要なメタデータを抽出します（状態ルート、取引レシート、ログ（イベント）など）。
• EthTxmanager
  • ETH メインネットと相互作用するために使用されます。
    • SequenceSender と集約者が L1 に取引を送信する要求を管理します。
    • 取引に関与するアカウントの nonce を管理します。
    • 取引が適時にパッケージ化されるように、ガス価格を動的に調整します。
• 状態
  • ノードデータ管理の重要なコンポーネントです。
    • 状態管理、バッチ、ブロック、取引を含むすべての状態関連データを処理します。
    • エグゼキュータと通信し、取引を処理し、状態を更新します。
    • StateDB は状態の永続化に使用されます。
• プール
  • 取引の一時保存に使用される取引プールです。
    • RPC で送信された取引を一時的に保存します。
    • シーケンサーに取引を提供し、取引の順序付けとバッチのパッケージ化を行います。
• JSON RPC
  • ユーザーとのインタラクションのための HTTP インターフェースです。
• L2GasPricer
  • L1 のガス価格に基づいて L2 のガス価格を計算します。

コントラクト#

主に 3 つのコントラクトがあります。

CDKDataCommitteeコントラクト#

CDKDataCommitteeコントラクトは DAC メンバーを管理し、DAC 署名を検証します。主に 2 つのメソッドがあります。

• 管理者は DAC メンバーと N/M マルチサインを設定できます。

  Copy

  function setupCommittee(
          uint _requiredAmountOfSignatures,
          string[] calldata urls,
          bytes calldata addrsBytes
      ) external
  

• DAC 署名を検証します。

  • signedHashが十分な署名閾値に達しているかを検証します。
  Copy

  function verifySignatures(
          bytes32 signedHash,
          bytes calldata signaturesAndAddrs
      ) external view
  
  // signedHashはBatchDataに基づいて計算され、transactionsHashではありません。
  

CDKValidiumコントラクト#

L2 の状態を管理および更新します。

• trusted sequencerがこのコントラクトに取引バッチを提出します。

  • sequenceBatchesはCDKDataCommitteeコントラクトのverifySignaturesメソッドを呼び出し、DAC 署名が閾値に達しているかを検証します。
  Copy

  function sequenceBatches(
          BatchData[] calldata batches, // BatchDataにはtransactionsHashが含まれます。
          address l2Coinbase,
          bytes calldata signaturesAndAddrs
      ) external ifNotEmergencyState onlyTrustedSequencer
  
  struct BatchData {
          bytes32 transactionsHash; // L2取引のkeccak256
          bytes32 globalExitRoot; // このバッチのGlobal exit root、L1引き出しに使用されます。
          uint64 timestamp;
          uint64 minForcedTimestamp;
      }
  

• verifyBatches 取引バッチを検証します。

  • zk 証明を提供し、一連の取引を証明します。
  Copy

  // TrustedAggregatorのみが呼び出すことができます。
  function verifyBatchesTrustedAggregator(
          uint64 pendingStateNum,
          uint64 initNumBatch,
          uint64 finalNewBatch,
          bytes32 newLocalExitRoot,
          bytes32 newStateRoot,
          bytes32[24] calldata proof
      ) external onlyTrustedAggregator
  
  function verifyBatches(
          uint64 pendingStateNum,
          uint64 initNumBatch,
          uint64 finalNewBatch,
          bytes32 newLocalExitRoot,
          bytes32 newStateRoot,
          bytes32[24] calldata proof
      ) external ifNotEmergencyState
  

PolygonZkEVMBridgeコントラクト#

L1 と L2 に展開されたブリッジで、資産のクロスチェーンに使用されます。

データフロー#

1. バッチの組み立て、シーケンサーはユーザー取引を収集し、バッチに整理します。
2. バッチの認証、バッチが組み立てられた後、シーケンサーはバッチデータとその対応するハッシュ値を DAC に送信します。
3. データの検証と保存、各 DAC ノードは独立してバッチデータを検証し、検証が通った後、ハッシュ値が各ノードのローカルデータベースに保存されます。
4. 署名生成、各 DAC ノードはバッチハッシュ値に署名を生成し、バッチの完全性と真実性を認めます。
5. Ethereum との通信、シーケンサーは DAC メンバーの署名と元のバッチのハッシュ値を収集し、Ethereum ネットワークに提出して検証します。
6. Ethereum 上での検証、Ethereum 上のロールアップコントラクトは有効な DAC メンバーリストに基づいて提出された署名を検証し、バッチハッシュ値が十分に承認されていることを確認します。
7. ZKP を使用した最終確認、集約者はこのバッチの取引のために ZKP を準備し、Ethereum に提出します。この証明は取引の有効性を確認しますが、取引の詳細は開示されず、Ethereum 上の CKD チェーンの状態を更新します。

Polygon CDK の全データフロープロセス

[以上は純粋な個人的理解（転載）であり、誤りがあればご指摘ください！]