How to fork mainnet L1 into a devnet?

Hey all :hugs:

I need to simulate some scenarios with a lock that is already deployed on L1 and that has complex interactions with other locks already deployed.

So basically I need to fork mainnet L1 into a devnet, how should I proceed?

Phroi

1 Like

Normally, ckb-transaction-dumper will be enough. Then you can run scripts via ckb-debugger.

2 Likes

Honestly I’m a bit confused :sweat_smile:

Can you make an example of use?

1 Like

this looks like a decent example

2 Likes

Do you mean run a devchain using existing mainnet data?

Run a local CKB dev chain using existing testnet/mainnet data

  1. Copy the data directory to a new directory. The following steps will be done in this new directory.

  2. Download the corresponding chain spec file based on testnet or mainnet

    1. testnet https://github.com/nervosnetwork/ckb/blob/develop/resource/specs/testnet.toml
    2. mainnet https://github.com/nervosnetwork/ckb/blob/develop/resource/specs/mainnet.toml
  3. Initialize dev chain and import testnet or mainnet chain spec, taking mainnet as an example

    ckb init -c dev --import-spec /path/to/downloaded/mainnet.toml --force
    
  4. Modify the imported specs/dev.toml

    [params]
    genesis_epoch_length = 1743
    # params can add the following options for configuration, keep genesis_epoch_length the same as original file
    initial_primary_epoch_reward = 1_917_808_21917808
    secondary_epoch_reward = 613_698_63013698
    max_block_cycles = 10_000_000_000
    cellbase_maturity = 0
    primary_epoch_reward_halving_interval = 8760
    epoch_duration_target = 14400
    # For development and testing purposes only.
    # Keep difficulty be permanent if the pow is Dummy. (default: false)
    permanent_difficulty_in_dummy = true
    
    # Change pow.func to Dummy
    [pow]
    func = "Dummy"
    
  5. Now CKB can be started, need to add parameters -skip-spec-check --overwrite-spec for the first run

    ckb run --skip-spec-check --overwrite-spec
    

I previously suggesting change the spec name to ckb_dev:

# change name in the first line to ckb_dev
name = "ckb_dev"

However, this will use the softfork and hardfork configurations for dev chain, to follow the mainnet or testnet forks configurations, just keep the original values.

2 Likes

This is the information I was actually asking for, thanks @doitian!! :pray:

1 Like

About this other tool, ckb-debugger, thanks @matt.bit for pointing me out that example, maybe that could have been the response right away! :hugs:

At the beginning I didn’t understand how to use it because I was believing that it would revalidate the entire transaction. Then again carefully looking at ckb-debugger --help:

--cell-index <cell-index> Index of cell to run

This implies that it only validates the script indicated by the parameters.

Understood this, it was easy to solve my problem with it, thanks @xjd for pointing out ckb-debugger :pray:

1 Like

Hey @doitian, I followed these steps for forking mainnet into devnet and it worked like a charm, thanks!

Now I want to speed up this devnet to test dCKB and NervosDAO interactions, so I followed the steps you previously suggested, but the epoch length doesn’t seem much affected by them. Currently one epoch is more than 16 minutes.

As indicated in your current answer, I didn’t change the genesis_epoch_length. To fully reproduce this issue follow the steps indicated on the Readme.

How should I proceed?

1 Like

It seems we need a feature to lock the epoch length since a starting epoch for dev environment. Could you post it into the Github repo?

1 Like
3 Likes

Can we use capsule/crates/testtool to develop a tool that can setup a node quickly just like anvil Reference

If you are using the ckb111+ version,

  • The first point is that you need to consider the hardfork compatibility configuration. In specs/dev.toml, append the following hardfork configuration

    [params.hardfork]
    ckb2023 = value
    

    Usually this value can be set to a number larger than the latest epoch sequence number;

  • The second point is to consider that locking the epoch length when starting the ckb node in the dev network requires permanent_difficulty_in_dummy = true, and the length of epoch_duration_target is not greater than 14400 and not less than 8. If it cannot be divided by 8, it will be rounded up as an epoch. The maximum number of blocks, the complete configuration is as follows:

    # Change the first line name to ckb_dev
    name = "ckb_dev"
    
    [params]
    genesis_epoch_length = 1743
    
    # params can add the following options for configuration, keep the original genesis_epoch_length value
    
    initial_primary_epoch_reward = 1_917_808_21917808
    
    secondary_epoch_reward = 613_698_63013698
    
    max_block_cycles = 10_000_000_000
    
    cellbase_maturity = 0
    
    primary_epoch_reward_halving_interval = 8760
    
    epoch_duration_target = 14400
    
    # For development and testing purposes only.
    # Keep difficulty be permanent if the pow is Dummy. (default: false)
    permanent_difficulty_in_dummy = true
    
    [params.hardfork]
    # Modify ckb2023 start time
    ckb2023 = 0
    
    # Change pow.func to Dummy
    [pow]
    func = "Dummy"