Discover how to utilize Avail as a data availability layer.
Introduction
Embark on setting up your own Polygon zkEVM network, leveraging Avail as the data availability layer. This guide is tailored for deploying on Ethereum's Sepolia testnet and integrating with the Avail Turing testnet. To gain a comprehensive understanding of Polygon zkEVM, review the Polygon zkEVM documentation.In this guide, you will conduct the following:
Both the real and mock provers are compatible exclusively with x86 architectures. They are not designed to operate on ARM architecture machines, including Apple Silicon devices, even within Dockerized environments.
Component
Minimum Requirements
Recommended Setup
Suggested AWS Instance
Mock Prover
4-core CPU, 8GB RAM, 50 GB SSD
8-core CPU, 16GB RAM, 60 GB SSD
r6a.xlarge
Real Prover
96-core CPU, 768GB RAM, 120 GB SSD
96-core CPU, 1000GB RAM, 140 GB SSD
r6a.24xlarge
Running the Polygon zkEVM solution suite may lead to storage issues, primarily due to excessive Docker logs. To mitigate this, you can customize the Docker daemon's behavior by referring to the first answer here. Choose a configuration that best suits your needs.
For a devnet setup with limited state growth and Docker logs, we recommend a minimum disk size of approximately 50GB.
If you plan to run a real prover, it's advisable to allocate a minimum disk size of around 120GB for your devnet setup.
Keep in mind that these recommendations may vary based on your specific use case and requirements.
Note
ADDITIONAL STORAGE CONSIDERATIONS
In production environments with a high transaction volume, your storage requirements may increase significantly. It's recommended to utilize an EBS-like data storage solution to ensure scalability, allowing you to add more storage as needed.
Network Details
Before diving into the setup, ensure you have the following network details:
USAGE DISCLAIMER
The prover and verifier components maintain their original security guarantees. However, please note that the data attestation verification during sequencing or any aspect of the validium-node related to data availability on Avail has not undergone an audit. Exercise caution when using this program. It is distributed without any warranty, nor an implied warranty of merchantability or fitness for a particular purpose.
Please be aware that some aspects of this guide may differ from the original source due to the unique nature of the Avail validium implementation. For zkEVM node-specific configurations and troubleshooting, refer to the official Polygon documentation.
Deploy the Contracts
Clone the validium-contracts repository and install dependencies:
git clone git@github.com:availproject/validium-contracts.gitcd validium-contractsnpm i
Fill in deploy_parameters.json following deploy_parameters.json.example:
Specify the trustedSequencer address. This address represents the Sequencer that is responsible for sequencing batches.
Define the trustedAggregator address. This address represents the Aggregator that handles the submission of proofs.
Fill in the following fields with the respective addresses that will control the contracts: admin, zkEVMOwner, timelockAddress, and initialZkEVMDeployerOwner.
Enter the private key for the deployer in the deployerPvtKey field.
GENERATING A NEW CONTRACT SUITE To create a fresh set of contracts, you can either employ a new private key or increment the value of the salt parameter in your configuration. After making this change, simply re-execute the deployment commands to generate the new contract suite.
Deploy the Node
⚠️Warning
MOCK PROVER FUNCTIONALITY
The Mock Prover does not generate any zero-knowledge proofs. Instead, it simply validates any generated state root as correct. The mock verifier contract operates similarly, accepting all validity proofs without actual verification.
Clone the validium-node repository for node setup:
Generate a secure account keystore file for Ethereum L1 transactions:
docker run --rm hermeznetwork/zkevm-node:latest sh -c "/app/zkevm-node encryptKey --pk=[your private key] --pw=[password to encrypt file] --output=./keystore; cat ./keystore/*" > account.keystore
Replace [your private key] with your Ethereum L1 account private key.
Replace [password to encrypt file] with a password used for file encryption. This password must be passed to the Node later via the env variable ZKEVM_NODE_ETHERMAN_PRIVATEKEYPASSWORD.
Update configuration files for the node:
Modify test.avail.config.json, test.node.config.toml, and test.genesis.config.json based on the provided example files.Click to view the avail configuration example
{ "seed": "test test test test test test test test test test test junk", "api_url": "wss://turing-rpc.avail.so/ws", "app_id": 1, "destination_domain": 1000, "destination_address": "0x000000000000000000000000305222c4DdB86FfA9fa9Aa0A479705577E3c4d33", "timeout": 200}
The zkEVM bridge service is a microservice that simplifies bridging between L1 and L2 by auto-claiming L1 transactions on L2 and generating necessary Merkle proofs. While optional for running a Validium, it enhances the ease of bridging transactions.
The Nomad DA bridge is only operational on Sepolia, limiting validium's data attestation to this chain. Alternatively, you can simulate data attestation and deploy on your preferred blockchain
Fill in config/config.local.toml following config.local.example.toml:
Unless you changed the genesis file, the L2 bridge address should remain the same.
The address provided by default in the configuration is allocated ETH in the validium test setup for autoclaiming on L2. If a different address is used, it might require ETH. Similarly, in a production setup where ETH is not arbitrarily minted, you will need to manually fund the zkevm-bridge-service autoclaiming account.
Build and run the Docker image using the following commands:
make build-dockermake run
Once the Docker image is running, it serves as a microservice to detect L1 and L2 bridge transactions. You can check if the API is active by accessing the /api endpoint.
Generate Merkle Proofs: Use the /merkle-proof endpoint to generate the necessary Merkle proofs for bridging transactions.
Additional Endpoints: The microservice provides other endpoints for various functionalities, such as detecting bridge transactions for specific accounts.
Updating Code: If you need to modify any part of the code, remember that each change necessitates a new build. To update and rerun the service, execute the make build-docker && make run commands.