xFeedBeta
xChar
·a year ago

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

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

1

为什么要选择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 vs. Validium

FeaturezkEVMValidium
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的关键组件

3

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

数据流

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

1697850863320
Polygon CDK 的整个数据流流程

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

Loading comments...
Crossbell Logo
Crossbell Chain
Ipfs Logo
IPFS
Source
Post on xlog