您正在查看: Layer2 分类下的文章

cdk-erigon - ChainDB name is not recognized

https://github.com/0xPolygonHermez/cdk-erigon/blob/06e93d49704726977297cf1d5055f43185e313bd/cmd/utils/flags.go#L2253-L2295

    chain = ctx.String(ChainFlag.Name)
    if strings.HasPrefix(chain, "dynamic") {
        configFilePath := ctx.String(ConfigFlag.Name)
        if configFilePath == "" {
            Fatalf("Config file is required for dynamic chain")
        }

        // Be sure to set this first
        params.DynamicChainConfigPath = filepath.Dir(configFilePath)
        filename := path.Join(params.DynamicChainConfigPath, chain+"-conf.json")

        genesis := core.GenesisBlockByChainName(chain)

        dConf := DynamicConfig{}

        if _, err := os.Stat(filename); err == nil {
            dConfBytes, err := os.ReadFile(filename)
            if err != nil {
                panic(err)
            }
            if err := json.Unmarshal(dConfBytes, &dConf); err != nil {
                panic(err)
            }
        }

        genesis.Timestamp = dConf.Timestamp
        genesis.GasLimit = dConf.GasLimit
        genesis.Difficulty = big.NewInt(dConf.Difficulty)

        cfg.Genesis = genesis

        genesisHash := libcommon.HexToHash(dConf.Root)
        if !ctx.IsSet(NetworkIdFlag.Name) {
            cfg.NetworkID = params.NetworkIDByChainName(chain)
        }
        SetDNSDiscoveryDefaults(cfg, genesisHash)
    } else {
        switch chain {
        default:
            genesis := core.GenesisBlockByChainName(chain)
            genesisHash := params.GenesisHashByChainName(chain)
            if (genesis == nil) || (genesisHash == nil) {
                Fatalf("ChainDB name is not recognized: %s", chain)

新建的自定义链,名称需要以dynamic关键词,例如dynamic-bcskill-testnet, 否则会获取对应的hash进行比对

cdk-data-availability之TrackSequence参数分析

https://github.com/0xPolygon/cdk-data-availability/blob/e17fe08a81dee451636cadce04e568563d992d38/sequencer/tracker.go#L84-L113

// Start starts the SequencerTracker
func (st *Tracker) Start(parentCtx context.Context) {
    st.startOnce.Do(func() {
        ctx, cancel := context.WithTimeout(parentCtx, st.timeout)
        defer cancel()

        addr, err := st.em.TrustedSequencer(ctx)
        if err != nil {
            log.Fatalf("failed to get sequencer addr: %v", err)
            return
        }

        log.Infof("current sequencer addr: %s", addr.Hex())
        st.setAddr(addr)

        url, err := st.em.TrustedSequencerURL(ctx)
        if err != nil {
            log.Fatalf("failed to get sequencer addr: %v", err)
            return
        }

        log.Infof("current sequencer url: %s", url)
        st.setUrl(url)

        if st.trackChanges {
            log.Info("sequencer tracking enabled")

            go st.trackAddrChanges(parentCtx)
            go st.trackUrlChanges(parentCtx)
        }
    })
}

分析

当TrackSequence设置为true时,会在TrackSequencerPollInterval间隔内,检查L1合约内的TrustedSequencer地址和URL是否有变更,并更新本地

场景

因为TrustedSequencer地址和URL变更频率很低,默认情况下TrackSequence可以设置为false,对比变更比较频繁的场景,可以将TrackSequence改为true
注:当cdk-data-availability服务重启时,会自动对齐配置

使用Kurtosis快速验证Polygon CDK新版本

前置介绍

官方部署:https://docs.polygon.technology/cdk/getting-started/local-deployment/
Polygon CDK Kurtosis 包允许您轻松自定义和实例化 CDK 链的所有组件。它使用Kurtosis工具来协调 Docker 容器中链组件的设置,并使用Starlark脚本(一种 Python 方言)中定义的逻辑来定义设置链的分步过程。

Polygon CDK Kurtosis Package

https://github.com/0xPolygon/kurtosis-cdk
通过kurtosis{用于打包和启动临时后端堆栈的平台},通过Docker和k8s 部署私有、可移植、模块化的Polygon CDK开发网络

软件包将部署:

  1. 本地 L1 链,使用ethereum-package ,完全可定制并支持多客户端。
  2. 本地 L2 链,使用Polygon Chain 开发套件(CDK),具有可定制的组件,例如序列器、序列发送器、聚合器、rpc、证明器、dac 等。它将首先在 L1 链上部署Polygon zkEVM 智能合约,然后再部署不同的组件。
  3. zkEVM桥接基础设施,促进 L1 和 L2 链之间的资产桥接,反之亦然。
  4. Agglayer一种正在开发中的互操作性协议,它允许进行无需信任的跨链代币传输和消息传递,以及 L2 链之间的更复杂操作,并由 zk 证明保护。
  5. 附加服务,如交易垃圾邮件发送者、监控工具、无需权限的节点等。

模块版本对应关系

Fork ID CDK Erigon ZkEVM Prover ZkEVM Contracts Data Availability Bridge
13 v2.60.0-beta4 v9.0.0-RC1-fork.13 v8.1.0-rc.1-fork.13 0.0.10 v0.6.0-RC1
12 v2.1.2 v8.0.0-RC14-fork.12 v8.0.0-rc.4-fork.12 0.0.10 v0.6.0-RC1
11 v2.1.2 v7.0.4-fork.11 v7.0.0-rc.2-fork.11 0.0.10 v0.6.0-RC1
9 v2.1.2 v6.0.8 v6.0.0-rc.1-fork.9 0.0.10 v0.6.0-RC1

当前测试时,默认测试 fork12

部署测试

Kurtosis部署

环境准备

  • Docker
  • Kurtosis
    • echo "deb [trusted=yes] https://apt.fury.io/kurtosis-tech/ /" | sudo tee /etc/apt/sources.list.d/kurtosis.list
      sudo apt update
      sudo apt install kurtosis-cli
  • jq
  • yq (v3)
  • cast
    • curl -L https://foundry.paradigm.xyz | bash
      source ~/.bashrc
      foundryup
  • polycli
    • git clone https://github.com/0xPolygon/polygon-cli.git
      make install
      export PATH="$HOME/go/bin:$PATH"

部署

git clone https://github.com/0xPolygon/kurtosis-cdk.git
sudo su
kurtosis clean --all
ulimit -n 1000000
kurtosis run --enclave cdk .

默认部署包括cdk-erigon作为序列器,以及cdk-node作为序列发送器和聚合器。您可以通过查看 input_parser.star 来验证这些组件的默认版本和默认 fork ID。您可以通过查看input_parser.star来检查已部署组件的默认版本和默认 fork ID
当前cdk-erigon为v2.1.2版本,对应fork ID 12

查看网络布局

kurtosis enclave inspect cdk

L2 RPC 测试调用

export ETH_RPC_URL="$(kurtosis port print cdk cdk-erigon-rpc-001 rpc)"
cast block-number

默认情况下,CDK 处于test模式配置,这意味着地址为 的管理员账户中有一些预先存入的价值

cast balance --ether 0xE34aaF64b29273B7D567FCFc40544c014EEe9970

测试交易

private_key="0x12d7de8621a77640c9241b2595ba78ce443d05e94090365ab3bb5e19df82c625"
cast send --legacy --private-key "$private_key" --value 0.01ether 0x0000000000000000000000000000000000000000
blockHash               0xec514afabfa829f1b4e9339fd72e31fb2a1888a18046fe21743fe38b55bd24c3
blockNumber             45
contractAddress         
cumulativeGasUsed       21000
effectiveGasPrice       1000000000
from                    0xE34aaF64b29273B7D567FCFc40544c014EEe9970
gasUsed                 21000
logs                    []
logsBloom               0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
root                    
status                  1 (success)
transactionHash         0xa58b3383c1b1f53369723fdc537c88daa03585cb6a89aa49ebd493953d519fdf
transactionIndex        0
type                    0
blobGasPrice            
blobGasUsed             
authorizationList       
to                      0x0000000000000000000000000000000000000000

批量交易,需要安装polygon-cli

polycli loadtest --rpc-url "$ETH_RPC_URL" --legacy --private-key "$private_key" --verbosity 700 --requests 50000 --rate-limit 50 --concurrency 5 --mode t
polycli loadtest --rpc-url "$ETH_RPC_URL" --legacy --private-key "$private_key" --verbosity 700 --requests 500 --rate-limit 10 --mode 2
polycli loadtest --rpc-url "$ETH_RPC_URL" --legacy --private-key "$private_key" --verbosity 700 --requests 500 --rate-limit 3  --mode uniswapv3

获取输出日志

kurtosis service logs cdk agglayer --follow

排查错误

kurtosis service shell cdk contracts-001
jq . /opt/zkevm/combined.json

检查系统状态

cast rpc zkevm_batchNumber
cast rpc zkevm_virtualBatchNumber
cast rpc zkevm_verifiedBatchNumber

如果验证批次的数量不断增加,则表明系统运行正常

访问zkevm-bridge用户界面

open "$(kurtosis port print cdk zkevm-bridge-proxy-001 web-ui)"

查看cdk-erigon-rpc-001日志

kurtosis service logs cdk cdk-erigon-rpc-001 --follow

停止本地开发网络并将其删除

kurtosis clean --all

Babylon BTC 质押整合规范

Babylon 的比特币质押协议为比特币持有者提供了一种实用的解决方案,使他们可以直接在其他系统上质押他们的 BTC,而无需第三方托管、桥接或包装。该协议为消费者系统提供由 BTC 支持的经济安全保障。它被设计为通用和模块化插件,使其与各种消费者系统兼容。Babylon 的 BTC 质押协议也是一个支持进一步重新质押协议开发的原语,提供了一种直接且安全的方式来增强比特币在区块链生态系统中的功能。

此页面提供了 BTC 质押集成的完整规范,以指导消费者系统的实施工作。

系统概述

与 Babylon BTC 质押协议集成的消费者将具有以下架构。

在此架构中:

  • Babylon 链与比特币集成,用于 BTC 质押和 BTC 时间戳协议。 义务警员在 Babylon 和比特币之间传递信息,以保持同步。
  • BTC 质押者将其 BTC 委托给 Babylon 链的最终提供者和消费者。
  • 最终提供者参与其相应系统的最终投票轮次。
  • Babylon 链和消费者链通过中继程序交换有关 BTC 质押的信息。 如果消费者是支持 IBC 协议的 Cosmos SDK 链,则中继器可以是标准 IBC 中继器,如果消费者不支持 IBC,则中继器可以是专用中继器。
  • 如果消费者选择不信任 Babylon 链,BTC 质押监视器可以监视 Babylon 链中发生的安全/活跃性问题并向消费者发出警报。

本规范的组织

Babylon 团队开发并维护上述架构中的蓝色部分。

Babylon 和比特币

要将消费者与 BTC 质押协议集成,消费者需要开发以下软件(架构中的灰色部分),在以下每个文档中指定:

消费者系统中的模块

Finality Provider

BTC 质押Relayer

BTC 质押监控器 (WIP)

Babylon 团队将为 CosmWasm 智能合约中的消费者系统模块提供参考实现,以及相应的最终性提供程序。如果带宽允许,Babylon 团队将开发 BTC 质押中继器和 BTC 质押监控器。

术语

在本规范中,

原文:https://emphasized-acoustic-f68.notion.site/Specification-of-BTC-staking-integration-7534996979cc4117bfd0ba093e889308

Babylon OP-stack 链的 BTC 质押集成

上下文

Babylon 提供 比特币质押协议,允许比特币持有者在比特币链上质押 BTC,以保护任何 PoS 链。质押是无需信任的,因为 BTC 位于原生比特币网络上的自托管保险库中,而无需在其他地方进行桥接。

OP 堆栈链可以与 Babylon BTC 质押协议集成,以获得比特币安全性。这带来了以下好处。

  • 更好的经济安全性: 有原生 BTC 质押来保护汇总并提高其经济安全性。这对于采用较少的新 OP 堆栈链来说更为重要。此外,质押的 BTC 实现了 可削减安全性,这是一种强大的安全属性,即使 L2 序列器中的多数派持有相同的质押,L2 序列器的质押也会被追究责任,BTC 质押也是可削减的。
  • 快速终结:改进的经济安全性将使 OP 堆栈链受益,实现快速终结。如果用户愿意信任由 BTC 质押支持的投票,那么用户可以确认交易并做出决策,而无需等待乐观汇总中漫长的挑战期。
  • L2 交易的重组弹性:一旦交易被大多数 BTC 支持的终结性提供者签名的 L2 区块中包含,序列器就不能在 L1 上的同一高度发布不同的 L2 区块。

比特币质押的无分叉汇总 博客文章提供了更多详细信息。

系统架构

下图描述了系统架构。“→”箭头表示数据流;例如,X→Y 表示“Y 从 X 查询数据,数据从 X 流向 Y”。

系统组件

设计涉及以下主要组件:

  • 最终性小工具合约:CosmWasm 智能合约,用于维护从 OP-stack 最终性提供商提交的所有最终性签名。
  • 它将部署在 Babylon 链上。
  • 它将查询 Babylon 以确定最终性提供商的状态和投票权。
  • OP-stack 最终性提供商:守护程序,接收 BTC 质押并将最终性签名提交给 Babylon 上的最终性小工具合约。
  • 它连接到 Babylon 节点以查询自身的投票权。
  • 它连接到 Babylon 节点中的最终性小工具合约以提交最终性签名。
  • 它连接到 OP 节点以获取 L2 区块元数据。
  • 带有最终性小工具的 OP 节点:OP 节点将进一步配备一个最终性小工具,用于统计所有最终性签名、确定 L2 区块的最终状态,并仅将最终确定的 L2 区块通知给 OP-geth。
  • 它连接到 Babylon 节点,用于查询最终性提供者的投票权。
  • 它连接到 Babylon 节点中的最终性小工具合约,用于查询最终性签名。
  • 它连接到以太坊 L1 节点,接收批量数据以派生 L2 区块。

关键工作流程

  • 最终性提供者:不断向最终性小工具合约提交 L2 区块的最终性签名。

在 OP 堆栈链中出现新的 L2 区块时,

  • 获取 L2 区块元数据。
  • 查询 Babylon 链以确定其自身是否在此高度具有投票权。
  • 如果是,则签署最终性签名并将其提交给最终性小工具合约。
  • 最终性小工具合约:验证传入的最终性签名并识别模棱两可之处。

在最终性签名后,最终性小工具合约对其进行验证并检查其是否冲突。

  • 如果有效且与任何现有签名不冲突,则接受。
  • 如果无效,则拒绝。
  • 如果有效但与现有的最终性签名相冲突,则发出事件,以便任何人都可以削减最终性提供者及其下的 BTC 质押。
  • 具有最终性小工具的 OP 节点:持续统计从 L1 派生的 L2 区块,以了解最终性签名和最终性提供者的投票权分布,并确定 L2 区块的 BTC 质押最终状态。派生管道经过修改,因此它仅输出 BTC 质押最终化的 L2 区块。

在从 L1 派生出新的 L2 区块时,OP 节点执行以下操作

  • 查询最终性小工具合约以获取此 L2 区块的所有最终性签名。
  • 查询 Babylon 以获取此消费者的所有最终性提供者/BTC 委托,并使用 L2 区块的时间戳来确定此区块时的投票权表。
  • 统计最终性签名并确定 L2 区块是否获得法定人数。
  • 如果此 L2 区块获得法定人数,且其前缀为 BTC 质押完成,则将此 L2 区块标记为 BTC 质押完成,并将其输出到派生管道中。

实施

我们已经完成了 MVP 的实施。代码库包括

展望未来,我们将实现以下功能:

  • [ ] 削减模棱两可的最终性提供者
  • [ ] BTC 质押者和最终性提供者的奖励机制

原文:https://www.notion.so/BTC-staking-integration-for-OP-stack-chains-1-pager-f0574cd4e624475eb00d64912698a38c#cb340004c6cf48e2b9c9656bc5e59d8b