Conversation
hexoscott
left a comment
hexoscott
left a comment
There was a problem hiding this comment.
I think we don't need the changes to package.json and in turn the yarn.lock files, we can always update these dependencies in another PR to ensure there are no side effects from that.
The kurtosis write up is great and was easy to understand, but I feel the manual deployment document needs some changes, I've dropped some comments in line.
| ## What is a Validium Setup? | ||
|
|
||
| A validium is a Layer 2 scaling solution which stores data off-chain. This approach offers high throughput and low costs. | ||
| The goal is to set up a functional L2 **zkEVM** network with `cdk-erigon` as the sequencer and execution environment. Transaction data will be managed by a DAC, with attestations anchored to Sepolia L1 for data availability guarantees. This involves deploying L1 contracts (including those specific to Validium and DAC management from the `zkevm-contracts` repository, and `PolygonRollupManager` from `zkevm-contracts`), configuring and running DAC nodes, and then setting up the L2 components (`cdk-erigon`, `cdk-node`). |
There was a problem hiding this comment.
The DAC doesn't really handle transaction data.
| To quickly deploy a CDK network with default settings (works on both macOS and Linux): | ||
| ### Software: | ||
| * **Git**: For cloning repositories, and package installation. | ||
| * **Go**: Version 1.21+ (for `cdk-erigon`, `cdk-node`, DAC nodes). |
There was a problem hiding this comment.
Worth updating to 1.24 as the latest versions are using this now.
| ### Part 1.C: Consolidated L1 Contract Addresses | ||
|
|
||
| (List of contracts remains similar, but source and genesis file are now clearer) | ||
|
|
||
| ```bash | ||
| kurtosis run --enclave cdk github.com/0xPolygon/kurtosis-cdk | ||
| --- | ||
| (Rest of the guide for Phase 2 onwards will need to be updated to use addresses and the genesis file from `zkevm-contracts` for cdk-erigon setup.) | ||
|
|
||
| This revised structure should be more accurate. The main remaining challenge is ensuring `3_deployContracts.ts` in `zkevm-contracts` can be controlled to only deploy `PolygonRollupManager` without conflicts if its verifier/bridge/GER are not needed. |
There was a problem hiding this comment.
Do we need this part? It seems to be some comments on the document itself and a not about only deploying PolygonRollupManager which is covered in line 149 as well.
| { | ||
| "root": "0xYOUR_EXTRACTED_ROOT_HASH_FROM_GENESIS.JSON_HERE", | ||
| "chainId": 20240517, // Replace with your L2 Chain ID (must match create_rollup_parameters.json) | ||
| "forkID": 13, // Replace with your ForkID (must match create_rollup_parameters.json and CDK_VERSION_MATRIX.MD) |
There was a problem hiding this comment.
Does the chainspec file have this? I don't have this in my own configs.
| ``` | ||
| * **Crucially, replace `0xYOUR_EXTRACTED_ROOT_HASH_FROM_GENESIS.JSON_HERE` with the actual `root` value you copied.** | ||
| * Ensure `chainId` and `forkID` precisely match what you used in `create_rollup_parameters.json` and what your L1 contracts were deployed for. For example, if your `create_rollup_parameters.json` had `chainID: 20240517` and `forkID: 13`, use those exact values here. | ||
| * The hardfork activation blocks/times (e.g., `homesteadBlock`, `shanghaiTime`) should generally be set to `0` for a new custom chain, meaning all features are active from genesis. Consult `cdk-erigon` documentation or examples for specific version recommendations if you have different requirements. |
There was a problem hiding this comment.
For a validium network running type 2 which will be the default london, shanghai, cancun, and prague should all be set to 9999999999999999999999999999999999999999999999999 not 0 as these features aren't enabled for networks running hermez forks.
|
|
||
| ### 3. `cdk-node` Configuration (Sequence Sender / Aggregator) | ||
|
|
||
| The `cdk-node` component (from `0xPolygon/cdk` or `0xPolygonHermez/zkevm-node` if using older stack) is responsible for preparing batches of L2 transactions and submitting them to the L1. If `cdk-erigon` is not set as the sequencer, `cdk-node` can also take on the sequencer role. Additionally, if a prover is integrated, `cdk-node` can manage the aggregation of proofs. |
There was a problem hiding this comment.
"preparing batches from the L2 into sequences to be posted to the L1" would be a better description here.
| # Path to your cdk-erigon binary and config file | ||
| /path/to/cdk-erigon/build/bin/cdk-erigon \ | ||
| --config=/path/to/my-cdk-chain-config/dynamic-{yournetwork}.yaml \ | ||
| --zkevm.genesis-config-path=/path/to/my-cdk-chain-config/ # Directory of allocs, chainspec etc. |
There was a problem hiding this comment.
We can drop this flag and just rely on those files being relative to the yaml file
| * If `cdk-erigon` is *not* the sequencer, `cdk-node` itself will sequence transactions from the L2 tx pool. | ||
| * It will start processing L2 transactions, forming batches, and sending them to L1 (or to DAC for Validium). Monitor its logs. |
There was a problem hiding this comment.
I'm not sure this is accurate, there are only two sequencers for these networks, zkevm-node which is deprecated now and doesn't support the latest forks, and cdk-erigon. Let's remove these lines.
|
|
||
| * **Mock Prover**: | ||
| * The `kurtosis-cdk` package typically deploys a mock version of the `zkevm-prover` (`0xPolygonHermez/zkevm-prover`). | ||
| * `cdk-erigon` (if sequencing and configured for it) or `cdk-node` (if aggregating) needs to be configured with the mock prover's endpoint (e.g., `zkevm.executor-urls` in `cdk-erigon.yaml` or `ProverURL` in `cdk-node.toml`). |
There was a problem hiding this comment.
cdk-erigon isn't aware of a prover existing or not, it just supplies the RPC endpoints for the aggregator to get data to send to the prover.
| * **CDK Version Compatibility**: Your CDK stack (execution client, consensus, contracts) must be compatible with the AggLayer's current requirements. This might involve specific fork IDs or component versions. | ||
| * **Data Availability**: The AggLayer will need to be able to verify the data availability of your chain. For Validiums, this means your DAC mechanism must be robust and auditable. | ||
| * **Proving**: Your chain must be producing valid ZK proofs for its state transitions, and these proofs must be verifiable by the AggLayer's contracts. | ||
| * **Permissioning**: Initially, connecting to the AggLayer is likely a permissioned process, coordinated with the Polygon Labs team. |
There was a problem hiding this comment.
This is definitely true so we can remove the "likely" part
3 participants
Initial changes updating to suit the new contract fork