Polygon CDK研究

Polygon Chain Development Kit，一个开源框架，用于在以太坊上快速部署由 ZK 驱动的 L2。

使用 Polygon CDK 开发的链的高级架构，可以像 L1 区块链一样定制业务规则

为什么要选择 Polygon CDK ?#

Polygon CDK 的设计原则

高度模块化，开发人员可以根据自己的需要定制链，从执行环境到 gas token
高度可扩展性，CDK 开发的 L2 可提高交易速度
统一的流动性，CDK 开发的链可确保在 Polygon 2.0 L2 生态系统内链间的资产转移
独立的 DA，CDK 开发的链具有专用的 DA 和 DAC，可提供强大的链外数据访问和可靠性
可组合可操作性，借助 LXLY Bridge, 实现链间的无缝互动和资产交换
近乎即时的最终确认，使用 Polygon CDK 部署的链依赖于加密安全，无需完整节点即可确保交易完整性

CDK 开发的链如何融入整个 Polygon 2.0 生态系统

Key Factors

Scalability for Ethereum， CDK 链可扩展以太坊
业务逻辑定制，CDK 链完全支持 EVM，允许自定义 gas limit，op code 兼容性和技术集成
隐私选项，CDK 链可以创建私有的 app chain。为优先考虑隐私的人提供一种选择，支持客户维护其应用数据的机密性，同时享受区块链技术带来的好处
以合规为导向，CDK 链可实现网络主权和合规性，允许网络维护者选择符合当地法规的管理员，确保符合地区法规要求
广泛的 Web3 支持，CDK 链是 zkEVM stack 的直接分叉，便于服务的移植，利用了一个全面的生态系统

Polygon CDK Data Avalilablity#

数据可用性将交易的执行和数据存储分离，允许交易数据驻留在链外 (off-chain data)，同时仍可用于验证，大大提高了可扩展性，降低了成本。

Polygon CDK Validium 是一种基于 zkEVM 基础的独特的扩展方案，它为 zkEVM 整合了 DAC，一种独特的数据可用性方法。

Polygon CDK 框架内，数据可用性委员会 (DAC) 成员运行 DA 节点，以确保链外数据的安全性、可访问性和完整性。链外数据由 DAC 管理，确保可用性。

Data Availability Committees 数据可用性委员会，有一个核心职责：核实每个人都能访问根据链上事件重建 L2 状态所需的数据。这意味着，即使 L2 运营商离线，用户仍可访问其资产的数据。

在 CDK-developed 链中，DAC 作为一个安全的节点联盟，确保链外数据访问。

DAC 的优势：

Lower Transaction Fees 计算要求降低，费用也随之降低
State Privacy，确保数据完整性

DAC 成员由 L1 上的智能合约进行管理。sequencer 将 L2 batch 数据发送给 DAC 成员，只在 L1 上传 hash 值 (accumulated input hash)，而不是完整的 L2 交易数据。

sequencer 有一个 ECC 私钥，在将 L2 batch 数据发送给 DAC 之前，会用自己的私钥签名。

// 带有sequencer签名的sequence
type SignedSequence struct {
	Sequence  Sequence       `json:"sequence"`
	Signature types.ArgBytes `json:"signature"`
}

// sequencer需要发送到L1的数据，以及一些metadata
// 排好序的交易列表，称为sequence
type Sequence struct {
	Batches         []batch.Batch `json:"batches"`
	OldAccInputHash common.Hash   `json:"oldAccInputhash"`
}

// batch结构体
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 成员向 sequencer 提供 API (datacom 服务)
- 从 L1 合约中读取 sequencer 地址 (如果有更新，会监听合约进行更新)
- 接收 & 存储 sequencer 发过来的 L2 batch 数据 (CDK 称这部分为 offchain data)
  - 验证 sequencer 地址 (通过 sequencer 的 ECC 签名恢复)
  - 存储数据
  - func (db *DB) StoreOffChainData(ctx context.Context, od []offchaindata.OffChainData, dbTx pgx.Tx) error
- 存储成功后，对 accumulated input hash 进行签名，并返回给 sequencer (每个 DAC 成员有一个 ECC 私钥)
- 核心代码
  - func (d *DataComEndpoints) SignSequence(signedSequence sequence.SignedSequence) (interface{}, types.Error)

zkEVM 和 Validium 在部署上的区别#

zkEVM 部署
- zkEVM Node，管理 polygon zkEVM 网络、处理交易、维护状态并与 L1 交互
  - 组件包括：JSON RPC, Pool DB, Sequencer, State DB, Synchronizer,Aggregator, Prover
  - 代码库：https://github.com/0xPolygonHermez/zkevm-node
- zkEVM Contracts，部署在以太坊上的一系列合约，主要有PolygonZkEVM,PolygonZkEVMBridge和PolygonZkEVMGlobalExitRoot
  - 代码库：https://github.com/0xPolygonHermez/zkevm-contracts
Validium 部署
- Data Availability Layer 数据可用性层
  - 代码库：https://github.com/0xPolygon/cdk-data-availability
- zkEVM Node with Validium Extensions 带有 Validium 扩展的 zkEVM Node
  - 代码库：https://github.com/0xPolygon/cdk-validium-node
- Validium-specific DAC Contract Validium 专用的 DAC 合约，主要有 **CDKDataCommittee.sol 和 CDKValidium.sol**
  - 代码库：https://github.com/0xPolygon/cdk-validium-contracts

zkEVM vs. Validium

Feature	zkEVM	Validium
Transaction Data Storage	所有交易数据保存到 L1	只将交易数据 hash 保存到 L1
Data Availability	所有数据都在链上提供，数据可用性高	链外数据可用性由 DAC 管理，DAC 负责验证交易数据的哈希值
Security	由于链上数据的可用性和零知识证明（ZKPs）的使用，它具有很高的安全性	DAC 成员可能会串通，降低安全性。不过通过使用 ZKP，安全性仍然可以得到保证。
Gas Fees	高 gas 费	gas 费低，因为链上只存储了交易数据 hash
Proof Generation	使用 Prover 生成批处理事务的 ZKPs 以进行验证	使用 Prover 生成批处理事务的 ZKPs 以进行验证
Transaction Validation	验证通过以太坊上的智能合约实现	验证涉及一个附加层，由 DAC 成员签署交易数据的哈希值
Final Settlement	交易批次及其相应的 ZKP 被添加到以太坊状态中	交易数据的哈希值及其 ZKP 被添加到以太坊状态

zkEVM Node 的关键组件#

Aggregator 聚合器
- 负责向 L2 提交 L2 state 的有效性证明。
  - 它需要向 sequencer 获取交易的 batch
  - 并和 prover 交互获得 zk proof，将多个证明汇总成单个证明
  - 使用 EthTxManager 将聚合的 zk proof 发送到 L1
Prover
- 负责为 batched transactions 生成 zk proof，这些 proof 用于在 L1 上验证 L2 state。
Sequencer
- 负责对 L2 交易进行排序，推动 L2 状态向前。
  - Transaction Ordering 交易排序，从 tx pool 中获取交易，并添加到 state 中
  - State Transition 状态转换，与 Executor 协作，执行交易，并更新 state
  - Trusted finality 可信的最终性确认，一旦 sequencer 将交易添加到 state 中，就会与其它节点共享该信息，使交易最终确认 (排序器级别的信任)。
    - 其它节点在获得 zkp 确认之后，才是最终级别的确认。
SequenceSender
- SequenceSender 将排好序的交易列表 (称为 sequence) 发送给 L1
  - 发送的其实是 sequence 的 fingerprint（可以理解为一个 hash 值)
  - 使用 EthTxManager 来处理 L1 交易
- 它还与数据可用性层协作，确保所有交易数据能在链外访问
Synchronizer
- Synchronizer 使节点的本地状态和以太坊 L1 保持同步，是 L1 和 L2 节点之间的桥梁
  - 监听 L1 合约的事件
  - 根据 L1 事件，从数据可用性层下载数据
  - 更新状态，使本地状态和主网保持一致
  - 处理 L1 区块重组：检测和管理区块链重组，以保持数据的完整性
Executor
- 状态转换 (state transition) 的实现，也即 VM 的实现
  - Batch execution: 接收一批交易的执行请求
  - EVM-compatible 的交易处理
  - 从执行中提取必要的 metadata，如 state root, transaction receipts, logs (events)
EthTxmanager
- 用于和 ETH 主网交互，包括：
  - 管理 SequenceSender 和 Aggregator 向 L1 发送交易的请求
  - 为交易涉及的账户管理 nonce
  - 动态调整 gas 价格，以确保交易被及时打包
State
- 是节点数据管理的重要组件。
  - 状态管理，处理所有状态相关的数据，包括 batch, block 和 transaction
  - 与 Executor 通信，以处理交易和更新状态
  - StateDB 用于状态持久化
Pool
- 交易池，用于交易的临时存储
  - 临时存储经过 RPC 提交的交易
  - 为 Sequencer 提供交易，以进行交易排序和打包 batch
JSON RPC
- 给用户交互的 HTTP 接口
L2GasPricer
- 根据 L1 gas price 计算 L2 gas price

合约#

主要有 3 个合约

`CDKDataCommittee`合约#

CDKDataCommittee合约用于管理 DAC 成员、验证 DAC 签名。主要有 2 个方法：

admin 可以设置 DAC 成员和 N/M 多签

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

验证 DAC 签名

验证signedHash是否达到足够的签名阈值

function verifySignatures(
        bytes32 signedHash,
        bytes calldata signaturesAndAddrs
    ) external view

// signedHash是根据BatchData计算得到，并不是transactionsHash

`CDKValidium`合约#

管理和更新 L2 的状态。

trusted sequencer向该合约提交交易 batches

sequenceBatches会调用CDKDataCommittee合约的verifySignatures方法，验证 DAC 签名是否达到阈值

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 验证交易 batches

提供 zk proof，证明一批交易

// 只有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 上的桥，用于资产跨链。

数据流#

批次 (batches) 组装，Sequencer 收集用户交易，并将其整理成批次 (batches)
批次认证，批次组装完成后，Sequencer 将批次数据及其对应的 hash 值发送给 DAC
数据验证和存储，各 DAC 节点独立验证批次数据，验证通过后，哈希值会存储在每个节点的本地数据库中
签名生成，每个 DAC 节点都会为批次 hash 值生成一个签名，这是对批次完整性和真实性的认可
与 Ethereum 通信，Sequencer 收集 DAC 成员的签名和原始批次的 hash 值，并提交给 Ethereum 网络进行验证
Ethereum 上的验证，Ethereum 上的 rollup 合约会根据有效的 DAC 成员列表验证提交的签名，并确认批次 hash 值得到足够的批准
使用 ZKP 进行最终确认，聚合器为该批次的交易准备 ZKP 并提交给 Ethereum。该证明确认批准交易的有效性，但不透露交易细节，从而更新 Ethereum 上 CKD 链的状态。

1697850863320
Polygon CDK 的整个数据流流程

[以上纯个人理解 (搬运)，如有错误，欢迎指正！]