# Documentation ## Quick links {% content-ref url="/pages/cngdhSLvoH9CYHiPX9R9" %} [FAQ Presto](/overview/faq-presto) {% endcontent-ref %} {% content-ref url="/pages/uQuC3SwzMeOcoY57wFOa" %} [FAQ CDK Erigon](/overview/faq-cdk-erigon) {% endcontent-ref %} {% content-ref url="/pages/St5eayyKzEu3luUQpHNs" %} [CDK Erigon RPC Methods](/overview/cdk-erigon-rpc-methods) {% endcontent-ref %} {% content-ref url="/pages/mgOew7oKU8ionJB353Yz" %} [FAQ Arbitrum](/overview/faq-arbitrum) {% endcontent-ref %} {% content-ref url="/pages/1y3W1i7JKZUwcmXB1wPV" %} [FAQ Optimism (OP)](/faq-optimism-op) {% endcontent-ref %} {% content-ref url="/pages/LbZ10pGNsrnJJ5VoaTHJ" %} [What is Presto?](/overview/what-is-presto) {% endcontent-ref %} {% content-ref url="/pages/BFgWjACrfzJRDx0PDUDr" %} [How-To Guides](/overview/main-functionality) {% endcontent-ref %} {% content-ref url="/pages/fw0a9MeisTxeck6JpqNU" %} [Features for Developers](/overview/features-for-developers) {% endcontent-ref %} ## ## Get Started We've put together some helpful guides for you to get setup with our product quickly and easily. {% content-ref url="/pages/zc9BF8Lu2qwUtLBq9TA7" %} [Getting set up](/fundamentals/getting-set-up) {% endcontent-ref %} # What is Presto? Presto is a cutting-edge platform designed specifically for web3 applications. It serves as a comprehensive solution that enables developers to quickly and effortlessly deploy their very own zkEVM Rollup, a powerful scaling solution on the Ethereum network. By utilizing Presto, developers gain access to a wide range of tools and functionalities that significantly streamline the deployment process. This includes seamless integration with both Ethereum and Gnosis Chain, ensuring compatibility and interoperability with existing ecosystems.
With Presto, developers can take full advantage of the benefits offered by zkEVM Rollup technology, such as enhanced scalability, reduced transaction costs, and improved transaction speeds. Additionally, the platform provides a user-friendly interface for managing and monitoring your deployed zkEVM Rollup, allowing for easy customization and optimization. In summary, Presto serves as a powerful and versatile platform that empowers developers to effortlessly deploy their own zkEVM Rollup on either Ethereum or Gnosis Chain, unlocking the full potential of web3 applications. ## What is Stavanger Testnet? Page actionsStavanger testnet is a public testnet, it is shared across all Presto accounts.CommentIt is static and permanent and has a real ZK-prover attached to it.CommentAlways available at the URL # How-To Guides # How to Create a Rollup This guide shows how to create a rollup on Ethereum or Gnosis Chain with the native gas token and the default gas fee marketplace: * ETH for Ethereum * xDAI for Gnosis Chain ### Steps 1. Sign in to[ presto.gateway.fm](http://presto.gateway.fm) with your Google account. 2. Click ‘+ Deploy’ in the upper right corner.
3. Click ‘Deploy’ or go to expert settings for ‘Configure’
4. When the status turns to ‘Active’ in a few minutes your rollup is live.
5. The menu gives you immediate access to settings and overview of the rollup.
6. Your Rollup is ready. # How to Deploy a gasless rollup ## What is a Gasless Rollup? In a gasless rollup, users can opt-out to set up gas price to 0. That way they don’t have to even have tokens to be able to transact on the gasless blockchain. Gas fees are covered by the user then. Downsides of this approach is opening up to spamming the network. 1. Deploying a gasless rollup follows the same process as How to [Create a Rollup](/overview/main-functionality/how-to-create-a-rollup), except you select "Configure" before deployment as seen in the screenshot below.
2. In there select "Gas fees" then "Gasless" and click "Save".
# How To Delete A Rollup Click on the gear ⚙ in the upper right corner, then choose ‘Delete Rollup’.
# How To Deploy Mainnet Currently this is impossible to do through the UI. Contact `sales@gateway.fm` Coming soon to the UI, stay tuned! # How To Add a Prover Contact `sales@gateway.fm` for that. Currently it is impossible to do through the UI. Stay tuned for the updates, it is on our roadmap! If you want to test your code with the real prover, you can consider using Stavanger Public Testnet ([What is Stavanger Testnet?](broken://pages/0JWN0agutnvtfOPxPPUW)) # Can I Change The Name of My Rollup? ## Enterprise Customer If you are an [Enteprise Customer](broken://pages/NCse6WWBjO03FRN4AW9m) — yes, you can ask `support+presto@gateway.fm` to change your name. ## Trial / Paid Customers Otherwise, the name is auto-generated. You can try to delete and re-create a rollup a few times to make sure you are happy with your name. **Why?** The implementation of this measure is driven by a strong focus on security and the prevention of fraudulent activities. By disallowing the use of similar names for rollups, we effectively mitigate the risk of scams and protect your customers from potential deception. This security measure ensures that your customers can confidently interact with your rollups without being tricked or misled by imposters. It serves as a safeguard against malicious actors attempting to exploit similarities in rollup names for their own nefarious purposes. ## Future Plans We will offer **linking your own domain** to Presto later. Keep in touch on our [Twitter](https://twitter.com/gateway_eth) or [Discord](https://discord.com/invite/3Edt7BCKyv). # How To Use Metamask with Presto ## How To Use Metamask with Presto ## Option 1: Use “Add to Metamask” button {% hint style="info" %} ☝ This also works for Brave and some other wallets. {% endhint %} 1. From the Presto Home page, click ‘View All’ on the rollup of choice. [Dashboard](/overview/presto-ui-dashboards/presto-l2-dashboard))
2. In the Dashboard, click on the arrow ➔ on the right side of Add to Metamask section. (See also[ Presto List Of Projects](https://docs-presto.gateway.fm/overview/presto-ui-dashboards/presto-list-of-projects),[ Presto L2 Dashboard](https://docs-presto.gateway.fm/overview/presto-ui-dashboards/presto-l2-dashboard)).
## Option 2: Add Manually 1. Repeat step 1 from above and in your Dashboard you can find the RPC section. There you can copy the Chain id and URL. (See also[ Presto List Of Projects](/overview/presto-ui-dashboards/presto-list-of-projects),[ Presto L2 Dashboard](/overview/presto-ui-dashboards/presto-l2-dashboard)).
2. In the ‘Block Explorer’ section, you can copy ‘Explorer URL’.
# How to use a Faucet ## How to use a Faucet {% hint style="info" %} ☝ Available only on testnets! {% endhint %} ## What is a Faucet? A testnet faucet provides developers and builders with test tokens for deploying, testing and optimizing smart contracts on public blockchains without having to spend real ETH tokens. Smart contracts on mainnet blockchains like Ethereum and Gnosis require gas fees to run smart contracts and incentivize validators to process and validate transactions accurately. Testnets help mirror the functionality of the main blockchain. The faucet on Presto is not gasless as each testnet provisioned with Presto has a faucet built-in and pre-funded. Also see: * [How To Deploy A Smart Contract](/overview/features-for-developers/how-to-deploy-a-smart-contract) * [How To Create & Use a Gasless Rollup](/overview/main-functionality/how-to-create-and-use-a-gasless-rollup) ## How To Use a Faucet? This shows to to request 1 test ETH on the faucet. 1. Navigate to “**Faucet**” in the L2 [Presto L2 Dashboard](/overview/presto-ui-dashboards/presto-l2-dashboard).
2. Open [Faucet](https://sn2-stavanger-faucet.eu-north-2.gateway.fm/), enter your wallet address and press 'Request'.
3. Confirm on the [block explorer](https://sn2-stavanger-blockscout.eu-north-2.gateway.fm/) and in the wallet.
Congratulations, we have successfully received testETH from the faucet. We recommend checking the guide below: * [How To Use Metamask with Presto](/overview/main-functionality/how-to-use-metamask-with-presto) * [How to use a Block Explorer](/overview/main-functionality/how-to-use-a-block-explorer)
# How to Access the Block Explorer \ Each Layer 2 blockchain on Presto comes with a pre-bundled block explorer, which is a powerful tool used to explore and analyze blockchain data. 1. Click on the Block explorer in the menu and you will be directed to the Block Explorer section. There click on -> to be directed to the blockchain explorer.
Use the block explorer to enter a transaction or block hash, explore detailed transaction or block information, navigate through the blockchain's history and check wallet balances. # How to Use a Bridge ## How to Use a Bridge Each Presto L2 comes with pre-built in Bridge to the rootchain (L1), protected by zk proofs. ## **What is a blockchain bridge?** A blockchain bridge is a technology that enables the transfer of digital assets or data between different blockchain networks. It acts as a connection or link between two or more blockchains, allowing them to communicate and interact with each other. When using a bridge in the context of ZK-rollups, such as Presto layer 2, the bridge serves as a connection between the layer 2 (L2) ZK-rollup and the root chain or layer 1 (L1) blockchain. The main purpose of a blockchain bridge is to facilitate interoperability and enable the seamless transfer of assets or information across different blockchain platforms. It helps overcome the limitations of isolated blockchains and opens up opportunities for cross-chain transactions and collaborations. With Presto Platform users can deploy their own zkEVM Rollup on either the Ethereum network or the Gnosis Chain. This rollup will form the basis for creating bridges and achieving scalability. Blockchain bridges typically consist of a set of smart contracts or protocols that establish trust and enable the secure transfer of assets between blockchains. These bridges ensure that the transferred assets maintain their integrity and security throughout the process. By using a blockchain bridge, users can leverage the unique features and capabilities of multiple blockchain networks. For example, transfer tokens from one blockchain to another, access decentralized applications (DApps) across different chains, or take advantage of specific functionalities provided by each blockchain. Blockchain bridges play a crucial role in the development of decentralized finance (DeFi) applications, as they enable the movement of assets between different blockchain-based financial protocols. They also facilitate cross-chain collaborations in various industries, such as supply chain management, gaming, and healthcare. In summary, a blockchain bridge acts as a vital infrastructure component that fosters interoperability and connectivity among different blockchain networks. It enables the exchange of assets, data, and functionalities, expanding the possibilities and potential of blockchain technology. ## Bridge Functionality in Presto Blockchain rollups consolidate multiple transactions, processing these transactions off-chain and only forwarding the resultant data to the root chain that can enhance the network's transaction throughput and reduce the cost.It reduces the on-chain transaction load and improves scalability by bundling multiple transactions into a single proof. ZkRollups facilitate scalability of chains by relocating computation from L1 to L2. In Presto we will provide the following options: zkEVM Validium (Proofs on L1): recommended for testing and simple games zkEVM Rollups (Proofs and DA (data availability) on L1): recommended for projects requiring higher security. Presto offers easy access to blockchain bridges by facilitating the setting of ZK-rollup. This solution enables quick and effortless deployment of a ZK-EVM rollup, a powerful scaling solution, on either the Ethereum network or the Gnosis Chain. Where you can within minutes get started with: Deploying private ZK-rollups Access to block explorers, KYC, indexers & more L2s & L3, rollups & validiums For the setup, here’s a documentation guide on [‘How to Create a Rollup’](/overview/main-functionality/how-to-create-a-rollup). Each Presto L2 comes with a pre-built bridge to the rootchain (L1), which is protected by ZK-proofs. With Presto, you don't need to manually submit the generated proofs-of-validity or directly interact with the bridge contract on the L1 blockchain. Presto automates this process for you. It handles the submission of proofs-of-validity to the bridge contract and verifies them internally. Once verified, Presto executes the corresponding transactions on the L1 blockchain seamlessly and securely. Presto automatically deploys a bridge contract on the main blockchain (layer 1) to serve as an interface between the ZK-rollup and the main chain. The bridge contract defines the rules and protocols for transferring assets or executing transactions between the two chains. As seen in [this bridge contract example on Seopolia Blockscout](https://eth-sepolia.blockscout.com/address/0x8DA0B6b941B8c70827081Be613fC8b0eA1f0a9F6?tab=txs). General process for how a Presto ZK-rollup can connect to a blockchain bridge: 1. Setup Presto Bridge: The ZK-rollup contract sets up a bridge contract on the main blockchain. This bridge contract is responsible for receiving and validating proofs from the ZK rollup. 2. Off-chain Transaction Processing: When users initiate transactions on the ZK-rollup, the transactions are aggregated and bundled into batches off-chain. 3. Generating Proofs-of-Validity: Once the transactions are bundled, the ZK-rollup generates a cryptographic proof-of-validity. This proof demonstrates that all the transactions within the rollup are valid according to the ZK-rollup’s rules and protocols. 4. Proof Submission: The ZK-rollup submits the proof-of-validity to the bridge contract on the main blockchain through the blockchain bridge. 5. Proof Verification and Execution: The bridge contract, facilitated by Presto, verifies the proof-of-validity and ensures that all the transactions within the ZK-rollup are valid and comply with the main blockchain's rules. If the proof is valid, the bridge contract executes the transactions on the main blockchain. 6. User-Friendly Interface: Presto offers a user-friendly interface that simplifies the interaction with the blockchain bridge. Users can easily initiate transactions, monitor their progress, and track their transaction history within the Presto platform. The intuitive design and comprehensive features make it accessible even for non-technical users. With Presto, the ZK-rollup achieves seamless connectivity to the main blockchain through the blockchain bridge. The bridge, enabled by Presto, acts as an intermediary facilitating secure communication and data transfer between the ZK-rollup and the main blockchain. Users can explore and analyze the executed transactions and associated data using Presto's built-in default explorer Blockscout, a powerful tool for blockchain data analysis. For custom solutions, any other block explorer can be integrated. ### How to Use A Presto Bridge (Bridging L2 to L1) After you’ve connected to the public rollup sn2-Stavanger (root chain Ethereum Sepolia) Testnet with your MetaMask wallet, the next step is to send ETH via Faucet. When transferring from L2 to L1, the bridge on L1 can’t mint tokens. Therefore, the bridge smart contract must be funded before bridging can occur. For example, you can’t bridge from L2 to L1 until you send test Sepolia tokens to this bridge smart contract via a faucet. After the bridge smart contract has been funded, you can bridge a maximum amount equal to the amount funded from L2 to L1. On the other hand, when transferring from L1 to L2, you don’t need to fund the bridge smart contract. 1.Go to Bridge Section in presto.gateway.fm:
2..Go to a Bridge URL and Add your rollup/validium to your wallet
3. Go to ETH Faucet and type your address to receive 1 ETH.
4. Bridge 1ETH to Ethereum Sepolia
5. In your Presto Bridge you will see the funds and from here you can bridge your ETH. Choose from where and the amount. Click ‘bridge’ and then confirm in your MetaMask wallet. Within Presto L2, you can execute off-chain transactions. These transactions are processed and verified using ZK-proofs, which ensure the validity and integrity of the transaction history. Once the transactions are processed, cryptographic proofs-of-validity are generated. 6. The activity will be processed and after that you can see the Bridge details.
7. The details are also available on the blockchain explorer. Once the proofs are validated, the transactions are executed on the L1 blockchain, providing trust and security. This can be observed by examining the transaction history and state changes on the L1 blockchain via block explorers or any other interface provided by the blockchain network.
By using the bridge on Presto, you get the benefits of increased scalability, reduced transaction fees, and improved privacy, as most of the transaction processing occurs off-chain within the ZK-rollup. ### How to Use A Presto Bridge (Bridging L1 to L2) This guide will reverse the process from above by bridging from L1 to L2. The Presto bridge enables seamless connectivity and secure transfer of assets between L1 and L2 blockchain. 1. Use Sepolia to send ETH to your MetaMask. Before you can bridge from L1 to L2, ensure that you have received ETH in your MetaMask wallet, which is connected to the Presto Bridge.
Upon receiving the ETH in your MetaMask wallet, since it’s connected to the Presto Bridge it will automatically proceed the bridging. 2. Select the 'from' and 'to' options, along with the desired amount to be bridged. Click 'bridge' to initiate the process.
3. This prompt will ask you to write “I Understand” before continuing. In your MetaMask wallet, confirm the bridge transaction by following the prompted instructions.
4. Once the bridge transaction is completed, you can view the details of the bridged transaction on the built-in blockchain explorer.
With Presto, you can enjoy increased scalability, reduced transaction fees, and improved privacy. The majority of transaction processing occurs off-chain within the ZK-rollup, providing a secure and efficient user experience. #### Summary: How to use a bridge in ZK-rollups: In Presto L2, off-chain transactions can be executed. These transactions are processed and verified using ZK-proofs, ensuring the validity and integrity of the transaction history. Besides proofs, for rollups, data availability (DA) is also sent to L1. This means that not only cryptographic proofs-of-validity are generated, but also the necessary data is made available on the Layer 1 blockchain. Presto L2 is equipped with a pre-built bridge that connects the ZK-rollup to the root chain/ L1 blockchain. The bridge is responsible for receiving and validating the generated proofs-of-validity before executing the transactions on the L1 blockchain. Once the proofs are validated, the transactions are executed on the L1 blockchain, providing trust and security. This can be observed by examining the transaction history and state changes on the L1 blockchain via block explorers. Presto Layer 2 (L2) solution includes a built-in block explorer, providing users with a robust tool to effortlessly explore and analyze blockchain data. By using the bridge on Presto, you get the benefits of increased scalability, reduced transaction fees, and improved privacy, as most of the transaction processing occurs off-chain within the ZK-rollup. # Inactivity Period (for Trial) Rollups without activity for 3 hours will be automatically deleted. All free rollups will be automatically deleted 12 hours after creation unless upgraded to a paid plan. # Features for Developers # What Is RPC To interact with the Presto L2 blockchain, developers can use JSON-RPC (Remote Procedure Call), a protocol for making remote procedure calls using JSON (JavaScript Object Notation) over HTTP or other transport protocols. JSON-RPC allows developers to send requests to the Presto L2 network and receive responses, enabling them to read data from the blockchain, send transactions, and execute smart contracts. Blockchain JSON-RPC offers a comprehensive set of methods and APIs that allow developers to seamlessly interact with the Presto L2 blockchain. These methods include querying account balances, retrieving transaction details, deploying smart contracts, and invoking contract functions. By leveraging the power of JSON-RPC, developers can integrate Presto L2 functionality into their applications, enabling efficient and secure interaction with the blockchain. Developers can take advantage of zkEVM's privacy and scalability features to build privacy-preserving and high-performance applications on the Presto L2 blockchain. zkEVM uses zero-knowledge proofs to ensure the confidentiality of transactions and computations, while still maintaining the decentralized nature of the blockchain. In summary, Presto L2 and Blockchain JSON-RPC provide a powerful combination for developers to build and deploy smart contracts on a decentralized blockchain. With zkEVM as the underlying virtual machine, developers can create privacy-preserving and scalable applications. Stay tuned for more articles and resources in our knowledge base to explore the potential of Presto L2 and make the most out of Blockchain JSON-RPC! To interact with Blockchain JSON-RPC, developers can use various libraries and frameworks. Some popular ones include: * Web3.js ([How To Use Presto with web3.js](/overview/features-for-developers/how-to-use-presto-with-web3.js)) A JavaScript library that provides a simple and consistent interface for interacting with JSON-RPC based blockchains like Ethereum. * ethers.js ([How To Use Presto with ethers.js](/overview/features-for-developers/how-to-use-presto-with-ethers.js)): Another JavaScript library that offers a complete set of tools and utilities for interacting with JSON-RPC based blockchains. * [web3.py](http://web3.py/) ([How to use Presto with web3.py](/overview/features-for-developers/how-to-use-presto-with-web3.py)): A Python library that allows developers to interact with JSON-RPC based blockchains using Python code. These libraries provide convenient abstractions and helper functions to simplify the process of sending requests, handling responses, and working with blockchain data. Developers can choose the library that best suits their programming language and requirements to interact with Blockchain JSON-RPC effectively. # How To Deploy A Smart Contract Deploy your smart contract to this L2 (validium/rollup) using Ethereum development environment Hardhat. {% embed url="" %} # How to use HardHat with Presto To use HardHat with Presto and deploy a smart contract, follow these steps: 1. **Setup HardHat:** * Install HardHat globally by running `npm install -g hardhat`. * Create a new directory for your project and navigate into it. * Inside the project directory, run `npx hardhat init` to initialize a new HardHat project. 2. **Download Custom Config File:** * Visit the Presto website and download the custom config file for your specific network. * Save the config file in your project directory. 3. **Add private key to .env** 4. **Add .env to .gitignore** 5. **Configure HardHat:** * To provide HardHat with a command-line flag for a custom config and the network name, you can use the `--config` flag followed by the filename of the custom config file, and the `--network` flag followed by the network name. * For example, if you have a custom config file named `hardhat.config.ts` and the network name is `yourL2Name`, you can run the following command: ``` npx hardhat --config hardhat.config.ts --network yourL2Name ``` * This command will run HardHat with the specified custom config file and connect to your L2 network.
6. **Write Your Smart Contract:** * Create a new Solidity file (e.g., `MyContract.sol`) in the `contracts` directory of your project. * Write your smart contract code in the Solidity file. 7. **Compile Your Smart Contract:** * In your project directory, run `npx hardhat compile` to compile your smart contract. 8. **Deploy Your Smart Contract:** * Write a deployment script in the `scripts` directory to deploy your smart contract. * Inside the deployment script, use the HardHat API to deploy your contract to the Presto network. * Run the deployment script by executing `npx hardhat run scripts/deploy.js` in your project directory. Make sure to reference the HardHat and Presto documentation for more detailed information and additional configuration options. # How To Use Presto with web3.js Using web3.js with a custom RPC endpoint allows you to interact with your Presto L2 and perform various operations on the network. You can retrieve information like the latest block number, check balance, and send transactions. To use web3.js with a custom RPC endpoint, you can follow the steps below: 1. Install web3.js package: ```bash npm install web3 ``` 2. Import web3.js into your project: ```jsx const Web3 = require('web3'); ``` 3. Create your rollup ([How to Create a Rollup](/overview/main-functionality/how-to-create-a-rollup)), open it and get the RPC url ([What Is RPC](/overview/features-for-developers/what-is-rpc))
3. Set up a custom RPC endpoint: ```jsx const rpcEndpoint = ''; // Replace with your custom RPC endpoint const web3 = new Web3(rpcEndpoint); ``` 5. Use web3.js methods to interact with your local geth node: ```jsx // Get the latest block number web3.eth.getBlockNumber() .then(blockNumber => { console.log('Latest Block Number:', blockNumber); }) .catch(error => { console.error('Error:', error); }); // Get balance of an address const address = '0x1234567890abcdef...'; // Replace with the desired address web3.eth.getBalance(address) .then(balance => { console.log('Balance of', address + ':', balance); }) .catch(error => { console.error('Error:', error); }); // Send a transaction const from = '0x9876543210fedcba...'; // Replace with the sender's address const to = '0xabcdef1234567890...'; // Replace with the recipient's address const value = web3.utils.toWei('1', 'ether'); // Replace with the desired value web3.eth.sendTransaction({ from, to, value }) .then(transactionHash => { console.log('Transaction Hash:', transactionHash); }) .catch(error => { console.error('Error:', error); }); ``` Remember to replace the placeholders with your own values. # How To Use Presto with ethers.js To use Presto with ethers.js using a custom RPC endpoint, follow these steps: 1. Install the ethers.js library by running `npm install ethers` in your project directory. 2. Create your rollup ([How to Create a Rollup](/overview/main-functionality/how-to-create-a-rollup)), open it and get the RPC url ([What Is RPC](/overview/features-for-developers/what-is-rpc))
3. Set up a provider to connect to your Presto L2 network using your custom RPC endpoint 4. Make sure to replace `YOUR_CUSTOM_RPC_ENDPOINT` with the URL of your custom RPC endpoint. ```jsx const { ethers } = require('ethers'); const provider = new ethers.providers.JsonRpcProvider('YOUR_CUSTOM_RPC_ENDPOINT'); async function getBlockByNumber(blockNumber) { try { const block = await provider.getBlock(blockNumber); console.log(block); } catch (error) { console.log(error); } } getBlockByNumber(12345); ``` # How to use Presto with ethers.py 1. Create your rollup ([How to Create a Rollup](/overview/main-functionality/how-to-create-a-rollup)), open it and get the RPC url ([What Is RPC](/overview/features-for-developers/what-is-rpc))
2. Set up a custom RPC endpoint: To use Presto with [ethers.py](https://pypi.org/project/ethers/), you can set up a custom RPC endpoint using the following code: ```python from ethers.providers import HTTPProvider url = "" gatewayHttpProvider = HTTPProvider(url) block_number = await gatewayHttpProvider.get_block_number() ``` # How To Use Presto with viem.sh To use Presto with [viem.sh](http://viem.sh/) library using a custom RPC endpoint, follow these steps: 1. Install the [viem.sh](http://viem.sh/) library by running `npm install viem.sh` in your project directory. 2. Create your rollup ([How to Create a Rollup](/overview/main-functionality/how-to-create-a-rollup)), open it, and get the RPC URL ([What Is RPC](/overview/features-for-developers/what-is-rpc)).
3. Set up a provider to connect to your Presto L2 network using your custom RPC endpoint. 4. Make sure to replace `YOUR_CUSTOM_RPC_ENDPOINT` with the URL of your custom RPC endpoint. ```jsx const { viem } = require('viem.sh'); const provider = new viem.providers.JsonRpcProvider('YOUR_CUSTOM_RPC_ENDPOINT'); async function getBlockByNumber(blockNumber) { try { const block = await provider.getBlock(blockNumber); console.log(block); } catch (error) { console.log(error); } } getBlockByNumber(12345); ``` # How to use Presto with web3.py 1. Create your rollup ([How to Create a Rollup](/overview/main-functionality/how-to-create-a-rollup)), open it and get the RPC url ([What Is RPC](/overview/features-for-developers/what-is-rpc))
```python from web3 import Web3 presto = Web3( Web3.HTTPProvider( "" ) ) ``` # Presto UI/Dashboards # Presto L2 Dashboard Dashboard is your go-to place to manage and review all the information about your L2. Top to bottom it consist of: * name of the L2 and its type * “gear” menu with options to delete the L2 ([How To Delete A Rollup](/overview/main-functionality/how-to-delete-a-rollup)) * navigation strip * rootchain, location, status and zkEVM logo * sections
### Getting Started Here you can add your chain to a wallet ([How to use MetaMask with Presto](https://docs-presto.gateway.fm/overview/main-functionality/how-to-use-metamask-with-presto)) and also download the config for Hardhat to deploy smart contracts ([How to use HardHat with Presto](https://docs-presto.gateway.fm/overview/features-for-developers/how-to-use-hardhat-with-presto)).
### RPC Here is all the necessary info about the RPC, is it public or private, chain id and the RPC url.
### Gas Fees Here is the overview and settings for the gas fees.
### Bridge Here is the link to the UI (and visibility settings) for the LX-to-LY bridge from Polygon CDK. (See [How to use a Bridge](https://docs-presto.gateway.fm/overview/main-functionality/how-to-use-a-bridge)).
### Block Explorer Each rollup comes with the blockscout instance. (See[ How to use a Block Explorer](https://docs-presto.gateway.fm/overview/main-functionality/how-to-use-a-block-explorer)).

Block explorer

### Faucet Each testnet comes with a faucet where you can get test gas tokens for smart contract deployments.
### Diagnostics This section contains information about smart contracts on L1.
### Data center info basic info about the datacenter

Data center info

## Enterprise customers Enterprise customers might have extra sections or other set of sections dependent on what customizations are chosen. See ([Enterprise vs Paid — what is the difference?](broken://pages/xNRxh62o3M1sLk0b0bBW)). # Presto List Of Projects 1. Username and deploy button 2. Private testnet listed 3. Help Section consisting of - Documentation, Integrations and Contact Us 4. Public testnet listed 5. Chat support Widget
Details of the active blockchain deployments.
1. Name of the L2 and status 2. Directly copy RPC URLs to clipboard ([What Is RPC](https://docs-presto.gateway.fm/overview/features-for-developers/what-is-rpc)) 3. Jump to the block explorer ([How to use a Block Explorer](https://docs-presto.gateway.fm/overview/main-functionality/how-to-use-a-block-explorer)) 4. Wallet UI 5. Jump to the bridge ([How to Use a Bridge](https://docs-presto.gateway.fm/overview/main-functionality/how-to-use-a-bridge)) 6. Wiev all settings (Presto L2 Dashboard) # Where To Get Support ## Discord Our team members are available in the [Gateway.fm Discord server](https://discord.gg/77vtmKNbkf). ## Social Media You can also reach out and follow us on [X](https://x.com/gateway_eth), [LinkedIn](https://www.linkedin.com/company/gateway-fm/) and [Warpcast](https://warpcast.com/gateway-fm). ## Email Contact us via email at `support+presto@gateway.fm` # FAQ Presto Here you can find answers to commons questions about Presto. *** ## Performance & Scalability
Is WebSocket (WS) support available for Erigon devnet rollups? Yes is available for all deployed rollups.
Can WebSocket support be enabled for a paid public testnet rollup? Yes is available for all deployed rollups.
*** ## Maintenance
Is the downtime during the Erigon migration a "hard" downtime? Yes, during the migration, the sequencer and all the services will be completely shut down.
Why does Blockscout show only 19K wallet addresses when the actual count is 150K? Blockscout counts all addresses that have either originated or received a transaction. In contrast, the 150K figure refers to entries within the projects custom smart contract. Which Blockscout doesn’t natively index or display. To show the true number of active users from the custom contract, Blockscout would need to be customized. To display active users from contract, a possible solution is to: 1. Query the custom smart contract to define "active users." 2. Create a custom indexer that tracks this data and exposes an API. 3. Fork the Blockscout frontend to query the custom indexer API instead of Blockscout’s API.
Why are eth_getLogs requests not returning results and how can this be resolved? The issue may arise due to the rollup's batch sealing process. Logs are typically indexed after the batch is sealed, meaning that until the batch is closed, `eth_getLogs` requests might not return results. This delay can be caused by the batch timing configuration, which determines how frequently batches are closed and logs are indexed.
What versions of Erigon should be used for different CDK-Erigon forks and are beta26 and beta27 compatible? For CDK-Erigon deployments: * Forkid.11 and below should use Erigon 2.0.0 (beta27). * Forkid.12 requires Erigon 2.1.0. * The upcoming Erigon release, 2.60.0, will support forkid.13 and include performance fixes for real provers. If you’re using beta26, it’s recommended to upgrade to beta27 for 2.0.0 compatibility, as the difference is minor and easily applied.
What is the upgrade path for forkid support in CDK-Erigon, and what improvements does forkid.13 introduce? Forkid.13, which includes **EIP-7212**, significantly reduces gas usage and counters for some signature verifications and is prioritized for use with the OKX pay product. The supported upgrade path for CDK-Erigon deployments is as follows: * Current tested paths: **9 -> 11 -> 12** * In testing: **9 -> 12** * Planned: **12 -> 13** The recommended sequence for customer upgrades will be **9 -> 12 -> 13** to ensure compatibility and optimal performance.
*** ## Use Cases & Considerations
Is a Private zkRollup a viable solution for my use case compared to public networks like Polygon or BNB? **Question:** How many transactions per month do I need for a Private zkRollup to be a viable solution? For example, if I have 10 million transactions per month on Polygon or BNB, should I consider using a private zkRollup instead? **Answer:** * **Break-even point**: You should have more than **1 000 transaction per hour** for a Private zkRollup to be cost-effective. If your transaction volume is lower than this, L1 may offer similar costs. * **Customization**: One of the key selling points (KSP) of private zkRollups is customization. For instance, you can have **zero transaction fees** or redistribute collected fees as rewards within your community. * **Transaction speed**: L1 transaction confirmation takes minutes, while on L2 like private zkRollups, confirmation occurs in milliseconds. However, private zkRollups may not match the transaction speed of public chains like BNB or Polygon, but you won’t be competing with other users for network space. * **Cost comparison**: **BNB and Polygon** are generally cheaper than private zkRollups for now. * **Settlement**: Transactions on private zkRollups are settled on a **root L1 chain** ensuring security and finality. * **Flexible fees**: In a private zkRollup, the **owners pay the fees** instead of the users and the fee structure can be highly flexible. * **Low confirmation time**: The average transaction confirmation time on a private zkRollup is very low. * **Use case for small games**: Private zkRollups can handle transactions with **database-like speed** (e.g., token minting or sending tokens in 100ms). * **Custom tokens**: You can build your own token on a private zkRollup using tools like **OpenZeppelin**, similar to how tokens are created on Ethereum. * **Use Cases**: Ideal for **bonus points**, **cashback programs** or digital currency for **in-app purchases** and mobile app top-ups.
What are the benefits of using ZK rollups compared to Optimistic rollups like Arbitrum? How do their costs and use cases compare? **ZK Roll-ups Benefits:** 1. **ZK Rollups can run OP node without a prover**: Just like Optimistic Rollups, ZK Rollups can initially run without a prover and you can connect the prover later for enhanced security. The prover ensures secure bridging and semi-permissionless operations, making it more secure and ideal for audits. 2. **Better security**: ZK Rollups provide a higher level of security since transactions are verified cryptographically, unlike OP Rollups, which rely on fraud proofs and have a longer dispute period. 3. **L1 fallback**: If something goes wrong on a ZK Rollup, you can fall back to L1 and recover funds or make transactions. This option provides added security compared to other solutions. 4. **Decentralization support**: If the L1 blockchain is decentralized, your private rollup will benefit from that decentralization adding another layer of security. 5. **Faster finality**: With ZK Rollups, transaction finality is quicker compared to OP Rollups since there is no waiting period for fraud proof disputes. **Use Cases:** * ZK Rollups are ideal for applications that require high security, auditability and faster finalit. Such as financial applications, enterprise solutions and private chains. **Costs:** * ZK Rollups generally have higher initial setup costs due to the complexity of zero-knowledge proofs. However, they can become more cost-effective at higher transaction volumes compared to OP Rollups, which may have lower upfront costs but longer transaction finality due to the challenge period. **Drawbacks of ZK Rollups:** * **Decentralized Sequencers**: If using a decentralized sequencer, it may slow down transaction processing. However, this trade-off improves security and resilience.
Do I need to use bridges? Yes, **bridges are essential** for interoperability between different blockchain networks. Here’s why: 1. **NFT Interoperability**: If you mint an NFT on your private rollup and want to sell it on an NFT marketplace (like one on Ethereum), you need a bridge to connect the two networks. 2. **DeFi Participation**: If you want your token to participate in DeFi, such as bridging a stablecoin (e.g., USDT) to your private rollup, a bridge is necessary. 3. **Cross-chain Settlements**: Bridges enable transactions or settlements across different chains, like Ethereum or other EVM-compatible chains. 4. **Two-Step Settlement Process**: The settlement process includes: * **Data Availability (DA)**: Ensuring that the necessary transaction data is available. * **Proof**: Verifying the transaction through a proof mechanism. Bridges facilitate these interactions, making them critical for rollup functionality and cross-chain transactions. In summary, to use assets like NFTs or tokens across multiple networks, such as Palm, Ethereum, or Polygon, a bridge is needed to facilitate inter-chain transfers and ensure settlement.
How does Presto differ from other platforms that offer roll-up creation or similar services? 1. **Fast Deployment with ZK-EVM Technology:** * Presto offers quick and easy deployment using zkEVM technology, providing a complete package with 35+ third-party integrations, a shared sequencer and customization options. It supports decentralized and on-premise deployments. 2. **Types of Similar Services:** * **Fully Automated Services:** Presto offer fully automated roll-up creation. This is seamless and fast, requiring minimal user input. 3. **Mass Adoption with Good UI/UX:** * Presto’s main advantage is its focus on mass adoption through a user-friendly interface and solid user experience (UI/UX). It is designed to be accessible even for non-experts. 4. **Evolution Towards Mobile SDK:** * Presto is moving towards offering a mobile SDK, similar to what Firebase does. This will further streamline development for mobile platforms and enhance ease of use. 5. **Simple, Click-Based Setup:** * With just a few clicks, users can deploy their own roll-up. While it's not entirely no-code, Presto provides templates and tools to simplify smart contract deployment for non-technical users. In summary, Presto stands out for its fast, automated deployment process, focus on user experience and future evolution towards mobile SDKs, differentiating it from more manual or incomplete solutions in the market.
Does a private rollup support smart contracts? If so, in what languages? Yes, private rollups support smart contracts, just like any EVM (Ethereum Virtual Machine) chain. The primary language for writing these smart contracts is **Solidity**.
How often do we need to release updates for private roll up? Who will take care of it? It will be up to date. Gateway will handle this.
*** ## Security & Monitoring
What measures did you take to ensure the security of the cloud deployment? * Regularly backup data and test the restoration process * ACL and limitation access for users * 2FA is mandatory * Monitoring updates and patches for all software and applications * Encrypted EBS * Implement network security measures such as firewalls * Bounty programs (white hat)
How would you do a software upgrade? * Use redundant nodes to ensure high availability during the software upgrade process. * Implement a canary approach, where a small portion of the system is upgraded first and monitored closely before rolling out the upgrade to the entire system. * for CDK and Presto — first test on free tier users, then enterprise users gets that * for backend software, use canary deployment
Who controls the keys in a L2 Rollup? Is this an industry standard and does it pose any risks to customers? **Key Ownership:** * **Admin Key**: We currently control the admin key. This key is primarily used for upgrades and system-wide changes. A safe multisig implementation for the admin account is planned for the future to improve security. * **Sequencer Key**: The sequencer key is controlled by the entity running the sequencer, which organizes transactions and sets the order in which they are executed. This key also allows control over receiving L2 gas fees. But a proof-of-concept is in progress to potentially allow customers to receive gas fees directly to their accounts. * **Aggregator Key**: Similar to the sequencer, the aggregator key is managed by the party running the aggregator. This key is responsible for bundling and submitting batches of transactions to the L1 blockchain. * **ClaimTxManager Key**: This key is also controlled by the party operating the system and manages transaction claims related to deposits and withdrawals on the L2 rollup. **Is this industry standard?** Yes, it is standard practice that the entity running the rollup possesses the private keys for components like the sequencer, aggregator and claimtxmanager. This is necessary for operating the system effectively. **Risks to customers:** There is a potential risk associated with key management since the party holding the keys controls essential parts of the rollup, including receiving gas fees and managing transaction order. However, the planned multisig admin account will mitigate some of these risks by adding a layer of security for upgrades and key actions. **Ideal Solution:** The long-term goal is to offer more flexibility and security, such as allowing customers to receive gas fees directly and reducing the dependency on centralized keyholders through multisig solutions.
What happens if Presto experiences downtime or other issues? * **Running Your Own Node:** If you have your own node, you can continue operations independently even if Presto is down. * **Centralized Sequencer Issues:** If the centralized sequencer experiences downtime, no transactions can be processed until it's recovered. During this period, there's nothing you can do on the network. * **Prover Downtime:** If the prover goes down, the network will still function, but certain operations like **bridging** will be affected until the prover is back online. **Recommendation:** To minimize risk, it’s advisable to run your own node for added resilience during downtime.
Is there a recovery plan in case of network data loss or progress disruption? Yes, Gateway has implemented a disaster recovery plan. The **CDK-Erigon architecture** allows any node to be quickly promoted to sequencer status if the active sequencer fails, ensuring continuity and minimizing downtime.
*** ## Tech Details
Has the EVM been modified in any way, such as new opcodes or precompiles? **Question:** Have you made any modifications to the EVM, such as: * Added new opcodes (e.g., to support EIP-3074)? * Changed gas costs of opcodes? * Modified context variables? * Does the chain use native EVM, or is bytecode/solidity transpiled into a different language? **Answer:** Yes, the EVM has been modified. **Details:** zkEVM is a standard EVM implementation with some zk-specific tweaks. These modifications allow the system to integrate with zero-knowledge technology while maintaining compatibility with the Ethereum Virtual Machine (EVM). More details on the specific modifications can be found here: [zkEVM Architecture Overview](https://docs.polygon.technology/zkEVM/architecture/protocol/etrog-upgrade/#zkevm-is-almost-type-2).
Does your EVM support deploying existing compiled contracts with an EVM version of ‘Paris’ or later, without additional code modifications? Yes. Latest supported HF for zkEVM is Berlin + PUSH0 opcode. EIP-3198 is not supported EIP-3529 is not supported EIP-4399 is set to 0 Other EIPs from Paris are supported on zkEVM
Do you support the ecrecover precompile at address(1)? Yes.
Are stateOverrides supported in eth_call? Yes.
Are custom call tracers supported in the debug_traceCall API? Yes.
Can a rollup be modified to include custom gas fee management after it has already been deployed? No, once a rollup is deployed, the gas token can’t be changed. To implement custom gas fee management, such as using a custom gas token or burning part of the fees, a new rollup must be deployed. After that, a custom gas-handling contract can be applied to manage the gas fees.
What customization options are available for a Block Explorer? Blockscout offers limited out-of-the-box customizations that includes: * Branding options, such as a logo (SVG), background for the faucet (JPG/PNG) and a favicon (ICO). * Additional customizations, such as a hero plate background, may be possible. However, more advanced customizations, like interactive elements, custom color schemes or charts on the homepage require a custom build of Blockscout. Along with new front-end development, which would involve ongoing maintenance and rebuilds for each version update.
Can existing chains be added to AggLayer? Existing chain cannot be added to agglayer, a restart from genesis is required
Can custom chain id l2_chain_id be set for testnet deployments, or is it restricted to mainnet only? Custom `l2_chain_id` settings are generally restricted to mainnet to maintain consistency, with autogenerated IDs recommended for testnet. If a specific chain ID is required for testnet please contact us.
Should I use an autogenerated or requested chain ID for testnet? Autogenerated IDs are preferred for testnet. However, if there’s a specific requirement, custom chain IDs can be used as long as they’re approved.
Why am I getting an error with dynamic fee-type transactions? Dynamic fee-type transactions (EIP-1559) are currently unsupported. Only legacy transactions are compatible with this setup. Use legacy transactions to avoid the error.
Do we currently support EIP-2718 (Typed Transaction Envelope) in legacy vdk-validium-node and cdk-erigon? No, as of now, EIP-2718 support is not available. While `cdk-erigon` technically supports envelopes, they are currently disabled for the active fork configuration. With future Proverless Protocol (PP) testing features may expand. Allowing potential support for vanilla clients. ***
# FAQ CDK Erigon Here you can find answers to commons questions about CDK Erigon ## CDK Erigon FAQ ### Token Bridging and Claims
Who performs the automatic claims on L1->L2 deposits and who pays for them? The `claimtxmanager` service performs automatic claims for L1->L2 deposits. Gas fees for these transactions are paid by the `claimtxmanager` wallet on L2. It's the customer's responsibility to keep this wallet funded. Additionally, the sequencer wallet on L2 accumulates gas fees, which can be transferred to a customer's wallet upon request.
Why can’t I use bridgeAsset for custom tokens when bridging from L2 to L1? This issue is often due to low balances on the sequencer and aggregator accounts on L1. To ensure smooth bridging, maintain sufficient ETH and POL tokens in these accounts. The bridge becomes ready to claim after the L2 transaction batch is verified on L1.
What are we waiting for when the API returns `ready_to_claim: false` during bridging? For L1->L2 bridging, readiness occurs after the L1 block with the bridge transaction is finalized. For L2->L1 bridging, readiness is achieved after the batch with the L2 bridging transaction is verified on L1.
Why does `deposit_cnt` sometimes equal `globalIndex` in the bridge and other times it doesn’t? This behavior depends on the network and transaction details. Specific cases require clarification from Polygon.
Is EIP-1559 supported on CDK-Erigon? No, EIP-1559 is not supported on CDK-Erigon.
Does CDK-Erigon support State Override? Yes, CDK-Erigon supports State Override functionality. *State Override Functionality refers to the ability to temporarily modify the state of the Ethereum Virtual Machine (EVM) for testing or debugging purposes without permanently altering the blockchain's actual state.*
Which Ethereum Virtual Machine (EVM) version is supported on CDK-Erigon? CDK-Erigon supports compiling contracts using the Shanghai EVM version. However, certain opcodes are not supported. For more information on the capabilities and differences between zkEVM and standard EVM, refer to the official \[Polygon zkEVM Documentation]\().
### Error Handling and Debugging
Why do some calls, like `estimateGas`, fail without a revert reason? Transactions may fail due to counter overflows or insufficient allowances, but revert reasons might not be displayed. This requires individual troubleshooting with the \*\*\`cdk-erigon\`\*\* team.
How can I diagnose delayed or stuck transactions in CDK-Erigon? If transactions appear delayed or stuck: 1. **Check ZK counter usage**: Use `zkevm_estimateCounters` to identify high counter-consuming transactions. 2. **Monitor block times**: Ensure block times are optimized to match the network load. 3. **Verify elastic block settings**: Confirm elastic block times are enabled to adjust block production dynamically.
### Gas and Network Configuration
How is gas price determined on the network? Gas prices are mirrored from L1 and cached for 3 seconds. They can be adjusted with the following parameters: * **`zkevm.gas-price-factor`**: Adjusts the L2 gas fee (increase or decrease). * **`zkevm.effective-gas-price-*`** values: Reduce fees for specific transaction types. Configuration changes require a sequencer restart.
What happens if I reduce block times in CDK-Erigon? Reducing block times results in: * **Higher throughput**: More blocks are produced per minute, allowing more transactions. * **Higher L1 posting costs**: More frequent batches are sent to L1, increasing gas fees. While CDK-Erigon supports reducing block times, ensure it aligns with your network’s cost and activity levels.
What is the gas limit per block in CDK-Erigon? There is no explicit gas limit per block in CDK-Erigon. Instead, \*\*ZK counters\*\* act as the limiting factor for block execution. * **How to check?** Use the `zkevm_estimateCounters` RPC method to estimate counter usage for your transactions, similar to `estimateGas`. Example: ```bash curl -X POST --data '{"jsonrpc":"2.0","method":"zkevm_estimateCounters","params":[],"id":1}' ```
### System Behavior and Issues
Why do some faucet transactions fail to appear in Blockscout? This is due to nonce management issues in the faucet software. A fix is planned in the roadmap.
Why does the network stall during certain operations and how can it be fixed? Network stalls often relate to transaction replacement or nonce management issues. Improved logging and debugging tools are necessary to address these problems effectively.
### Miscellaneous
Why can’t I read as proxy or simulate transactions in Blockscout? This was due to a minor issue with Blockscout’s URL formatting, which has been fixed.
Are there any resources for bridging API documentation? Since the bridge service is unmodified from Polygon’s implementation, documentation is limited. Feedback has been forwarded to Polygon for additional resources.
Is the current Blockscout pagination implementation standard? Yes, the pagination method is consistent with Blockscout instances on other networks, such as Sepolia.
Will CDK Erigon start without specifying L1 contract? No, as of now it’s not possible in production. There is work in progress for this.
How do shorter block times (e.g. 250ms) impact real-world use cases? Shorter block times can benefit high-frequency trading dApps and other applications requiring low-latency transactions. However, these are still being tested in production due to the impact of L1 fees.
Are there trade-offs with shorter block times? \- While shorter block times improve responsiveness, they can increase L1 costs due to the higher number of batches being posted to the L1 chain. - Elastic block times aim to balance this by adapting to the network’s activity level.
Is 250ms block time achievable in production? Tests have proven it feasible, but it's not widely adopted in production yet due to L1 fee implications. Elastic block times are being implemented to optimize costs and efficiency.
What is the current ZK counter limit, and what will it be on the Erigon stack? On the Erigon stack, the ZK counter limit is expected to increase to about 130-150% of the current counters. December 2024.
Why is the block speed restricting transaction throughput in CDK-Erigon? The current transaction throughput is influenced by: * **ZK counter limits**: Blocks are constrained by counter usage, not gas. * **Block times**: Block speeds can be adjusted in CDK-Erigon to increase throughput. For instance, block times can be reduced to under **1 second** and tested at **250ms**. **Elastic block times** in CDK-Erigon further optimize throughput: * Block times **increase** during inactivity to reduce costs. * Block times **decrease** when there is a transaction queue to improve throughput.
Are orphan blocks a concern in CDK-Erigon? No, CDK-Erigon does not produce orphan blocks. The zero-knowledge proofs ensure all blocks are valid and finalized, eliminating the concept of orphaned blocks.
Why is the proof generation time slower on ForkId 12 in CDK-Erigon? In CDK-Erigon, proof generation time depends on the \*\*ZK counters\*\*: * ForkId 12 introduces increased counter capacity, which allows for more complex blocks but also leads to **longer proof generation times**. * This is an expected behavior due to the additional counter load in ForkId 12.
Can faster block times in CDK-Erigon increase costs? Yes. Faster block production leads to: * More frequent L1 batches. * Higher gas costs for batch submissions. To manage this: * Use a **burn mechanism** to charge slightly higher fees and offset L1 costs. * Regularly monitor L1 costs and adjust block production parameters as needed.
What is the role of CDK-Erigon compared to the legacy stack? CDK-Erigon is the more modern and scalable implementation of Polygon CDK. It provides: * Greater confidence in **block speed optimizations**. * Support for features like **elastic block times** and **ZK counter management**. * Improved performance for handling high-frequency transaction workloads.
Differences between CDK-Erigon and OP for rollups 📌 **Note:** If integration with AggLayer is a requirement, CDK-Erigon is currently the preferred choice. If extensive precompile support is critical, OP Stack may need further evaluation.
What Precompiles does CDK-Erigon support? CDK-Erigon supports most Ethereum precompiled contracts, except RIPEMD-160 and BLAKE2F. Below is a comparison of precompile support across different forks:
### Optimization
How can I optimize throughput and block speed in CDK-Erigon? \- **Lower block times:** Block times can be reduced to as low as 250ms for high-frequency use cases. \- **Use elastic block times:** \- Low activity = increased block time → fewer batches → reduced costs. \- High activity = decreased block time → improved throughput. \- **Balance counter usage:** Monitor and optimize the ZK counters to ensure efficient block production.
Can block times be adjusted on the Erigon stack? Yes, block times are adjustable. Tests show block times can go down to under 1 second with experiments reaching as low as 250ms. This is achievable alongside features like elastic block times (no new blocks if there are no transactions).
# CDK Erigon RPC Methods ## CDK-Erigon RPC Methods ### Transaction Pool (`txpool`)
txpool_content #### Description: Returns details of all pending and queued transactions in the transaction pool. #### Parameters: *None* #### Response: Returns an object containing: * **pending** – A list of transactions waiting to be included in a block. * **queued** – A list of transactions that are queued due to nonce gaps. #### Example: ```json { "pending": { "0xSenderAddress": [ { "to": "0xReceiver", "value": "0x10" } ] }, "queued": { "0xSenderAddress": [ { "to": "0xReceiver", "value": "0x20" } ] } } ```
txpool_contentFrom #### Description: Fetches all pending and queued transactions from a specific sender. #### Parameters: * `address` *(string)*: The sender’s Ethereum address. #### Response: Returns the list of transactions originating from the specified sender. #### Example: ```json { "pending": [{ "to": "0xReceiver", "value": "0x10" }], "queued": [{ "to": "0xReceiver", "value": "0x20" }] } ```
txpool_limbo #### Description: Returns transactions that are stuck in limbo due to missing dependencies or nonce gaps. #### Parameters: *None* #### Response: Returns an array of transactions that are unprocessable. #### Example: ```json { "limbo": [{ "from": "0xSender", "nonce": 5, "to": "0xReceiver" }] } ```
### zkEVM Methods (`zkevm`)
zkevm_batchNumber #### Description: Returns the latest batch number finalized on L1. #### Parameters: *None* #### Response: * `batchNumber` *(integer)*: The latest verified batch. #### Example: ```json { "batchNumber": 10045 } ```
zkevm_batchNumberByBlockNumber #### Description: Fetches the batch number corresponding to a specific block number. #### Parameters: * `blockNumber` *(integer)*: The L2 block number. #### Response: * `batchNumber` *(integer)*: The batch associated with the block. #### Example: ```json { "batchNumber": 9998 } ```
zkevm_consolidatedBlockNumber #### Description: Retrieves the latest L2 block that has been consolidated. #### Parameters: *None* #### Response: * `blockNumber` *(integer)*: The latest consolidated L2 block. #### Example: ```json { "blockNumber": 105432 } ```
zkevm_estimateCounters #### Description: Estimates the counter usage for a given transaction, similar to `estimateGas` but for zkEVM. #### Parameters: * `transaction` *(object)*: The transaction object to analyze. #### Response: * `counterEstimate` *(integer)*: Estimated zk-counter usage. #### Example: ```json { "counterEstimate": 25000 } ```
zkevm_getBatchByNumber #### Description: Returns details about a specific batch by its number. #### Parameters: * `batchNumber` *(integer)*: The batch ID to fetch. #### Response: Batch details, including block range, state root, and L1 commitment status. #### Example: ```json { "batch": { "batchNumber": 10045, "blockRange": "100430-100450", "stateRoot": "0xabcdef" } } ```
zkevm_getBatchCountersByNumber #### Description: Retrieves the counter usage details of a specific batch. #### Parameters: * `batchNumber` *(integer)*: The batch ID. #### Response: A list of counter values for that batch. #### Example: ```json { "counters": { "zkCountersUsed": 14000, "gasUsed": 8000000 } } ```
zkevm_getBatchWitness #### Description: Returns the witness data used to generate a zk-proof for a batch. #### Parameters: * `batchNumber` *(integer)*: The batch ID. #### Response: A large witness dataset used in zk-proof computation. #### Example: ```json { "witnessData": "0xabcdef12345..." } ```
zkevm_getExitRootTable #### Description: Returns the global exit root table. #### Parameters: *None* #### Response: A mapping of all exit roots across different rollups. #### Example: ```json { "exitRoots": { "rollup1": "0x123abc...", "rollup2": "0x456def..." } } ```
zkevm_isBlockConsolidated #### Description: Checks if an L2 block has been consolidated into a batch. #### Parameters: * `blockNumber` *(integer)*: The L2 block ID. #### Response: * `boolean` *(true/false)*: Whether the block is consolidated. #### Example: ```json { "isConsolidated": true } ```
zkevm_verifiedBatchNumber #### Description: Returns the last verified batch number on L1. #### Parameters: *None* #### Response: * `batchNumber` *(integer)*: The latest verified batch. #### Example: ```json { "batchNumber": 10432 } ```
### Other zkEVM Methods | Method | Description | | -------------------------------- | ----------------------------------------------------- | | `zkevm_getForkById` | Fetches details of a specific fork by its ID. | | `zkevm_getForks` | Lists all available forks in the zkEVM environment. | | `zkevm_getLatestDataStreamBlock` | Retrieves the latest block in the data stream. | | `zkevm_getLatestGlobalExitRoot` | Returns the latest exit root for rollup transactions. | | `zkevm_getRollupAddress` | Fetches the rollup contract address. | | `zkevm_getRollupManagerAddress` | Retrieves the address of the rollup manager contract. | | `zkevm_getVersionHistory` | Returns a list of version upgrades and changes. | ### Notes on Usage * **State Verification:** Some calls return **trusted** vs. **verified** results, meaning finality may depend on L1 settlement. * **Performance Considerations:** Calls returning large datasets (e.g., `getWitness`) may take longer to execute. * **Gas Considerations:** `zkevm_estimateCounters` helps optimize transaction gas usage in zkEVM environments. For more details, refer to the **Polygon zkEVM API Documentation**: [Polygon zkEVM Docs](https://docs.polygon.technology/zkEVM/architecture/protocol/etrog-upgrade/#supported-opcodes). # FAQ Arbitrum ## Arbitrum Documentation/FAQ
What is Arbitrum? Arbitrum is a Layer 2 and Layer 3 scaling solution on Ethereum designed to make dApps faster and cost-effective, by offloading computation and storage from the Ethereum main chain. Providing higher throughput and lower fees.
Arbitrum Chains Ecosystem Arbitrum provides different types of rollups and execution environments tailored for various use cases: #### **Arbitrum One** * **Description:** The main Arbitrum L2 rollup with full Ethereum compatibility. * **Best For:** DeFi, NFTs, general dApps. #### **Arbitrum Nova** * **Description:** Optimized for **high-throughput and low-cost** transactions using AnyTrust technology. * **Best For:** Gaming, social apps, microtransactions. #### **Arbitrum AnyTrust** * **Description:** Uses **off-chain data availability** with a local DA, 3rd party DA for efficiency. * **Features:** * Custom gas token support. * Validium-based solution. * **Best For:** Enterprise solutions L2. #### **Arbitrum Orbit** * **Description:** Allows developers to launch **custom L2 or L3 rollups** with tailored settings. * **Best For:** Application-specific rollups, custom gas tokens, ecosystem chains.
Setup & Configuration * **Sequencer (with ArbOS):** Orders transactions and executes state transitions but does not submit rollup data to L1. * **Coordinator:** Aggregates L2 transactions into compressed batches before posting them to L1 Ethereum. * **Node Provider / RPC Interface:** Allows dApps and users to interact with the Arbitrum network. * **Fraud Proof System:** Handles fraud-proof verification and dispute resolution. * **Finalized Transactions:** Transactions validated through the fraud-proof mechanism.
Configuration Parameters * **`max_gas_limit_per_block`**: Determines the maximum gas allowed in each Arbitrum block. *(Applies to Arbitrum One & Orbit but differs for Nova & AnyTrust)*
Why is my bridge withdrawal taking so long? Arbitrum has a 7-day challenge period for fraud-proof verification. * During the 7-day challenge period, anyone can submit fraud proofs if they detect an invalid state transition. * If no fraud is detected, the transaction is finalized, and funds become available on Ethereum L1. * This mechanism ensures that Arbitrum remains secure without needing real-time computation on L1. #### Faster Withdrawal Alternatives A faster alternative is to use liquidity providers like Hop Protocol or Across Protocol. Waiting 7 days can be inconvenient, users can use third-party liquidity providers that offer fast exits by fronting the withdrawn funds. * **Hop Protocol** – Bridges assets instantly by using a network of liquidity providers. * **Across Protocol** – Provides rapid transfers across chains using bonded relayers.
Does Arbitrum support EIP-1559? Yes, Arbitrum does support EIP-1559. #### **What Does This Mean for Developers?** * **Gas estimation must be adjusted** – Arbitrum does use a "base fee" + "priority tip" structure. * **Wallets may display fees differently** compared to Ethereum mainnet.
What happens if the Arbitrum Sequencer goes offline? * **Failsafe Mode:** Users can submit transactions directly to Ethereum L1. * **Censorship Resistance:** If the sequencer fails to include a transaction, users can force inclusion after **24 hours**. * **Multiple Sequencer Support:** A new sequencer can be activated if the primary one is down.
Validators & Security Model Arbitrum uses a **three-tier validator model** to maintain security and detect fraud: #### **Security Mechanism:** * **Punishment for Fraud:** Malicious validators lose their stake. * **Observers Earn Rewards:** If they catch fraudulent activity.
# FAQ Optimism (OP)
About OP ### **Optimism** Optimism is a Layer 2 scaling solution for Ethereum that leverages rollup technology to bundle multiple transactions into batches before submitting them to Ethereum L1. #### **Core Components Overview:** * **Sequencer:** Orders and processes transactions before batching. * **Proposer:** Posts state roots and finalization data to L1. * **Batcher:** Sends compressed data batches to L1 for data availability. * **RPC Nodes:** Support horizontal scaling for high RPC traffic.
Setting Up an OP Rollup #### **Configuration Parameters Explained** * **`batcher_max_channel_duration`:** Controls the maximum duration a batch can stay open before being submitted. * **Definition**: Specifies the maximum duration (in L1 blocks) that a batcher can keep a channel open before submitting the batched transactions to L1. * **Purpose**: Ensures timely submission of transactions, balancing between cost efficiency and data availability. * **Recommendation**: Set this value considering the L1 block time (e.g., for Ethereum, \~12 seconds per block) and the desired frequency of batch submissions. * **`proposer_proposal_interval`:** Time interval for submitting state roots to L1. * **Definition**: Determines the time interval (in seconds) at which the proposer submits state roots to L1. * **Purpose**: Regular submissions help in maintaining the integrity of the rollup and facilitate L2 to L1 communication. * **Recommendation**: Align this interval with `batcher_max_channel_duration` to ensure synchronized operations and avoid redundant postings. * **`data_availability_type`:** Specifies how the rollup handles data availability (either `blobs` or `calldata`). * **Definition**: Indicates the method used for data availability in the rollup, either `blobs` or `calldata`. * **Purpose**: Determines how transaction data is stored and retrieved, impacting scalability and security. * **Recommendation**: Choose `blobs` for blob storage or `calldata` for embedding data directly in transactions, based on your application's requirements.
Bridging and Token Transfers Bridging tokens between Layer 1 (Ethereum) and Layer 2 (Optimism) is essential for enabling asset movement across the two layers. The process involves both deposits (moving assets from L1 to L2) and withdrawals (returning assets from L2 to L1). ![](/files/qGikH1V2yNTy1Kzw3aog) #### Deposit Flow (L1 to L2): 1. **User Initiation**: The user sends tokens to the L1 Standard Bridge contract. 2. **Message Relaying**: The L1 CrossDomain Messenger handles message transmission to L2. 3. **L2 Credit**: Tokens are minted or credited to the user’s L2 account upon message finalization. #### Withdrawal Flow: 1. **User Initiation**: The user initiates a withdrawal on L2. 2. **Message Relaying**: The L2 CrossDomain Messenger processes the request. 3. **L1 Finalization**: Tokens are released to the user's L1 account after the challenge period. #### Bridging Tokens Between L1 and L2 * Tokens can be bridged using the `OptimismPortalProxy.depositERC20Transaction` method. * Ensure token approval before deposit. * Depositing and Withdrawing Tokens.
Configuration (Set Before Deployment) ⚠ **Important:** The following parameters must be configured before rollup deployment and **cannot be changed after deployment.** * **Batching Parameters** * **Max Number of Batches:** Default is `300`. * **Max Batch Size:** Set to `120,000 bytes`. * **Max Batches Per Sequence:** Default is `300` but can be increased. * **Setting batcher\_max\_channel\_duration** * Ensure both `batcher_max_channel_duration` and `proposer_proposal_interval` are synchronized to prevent excessive postings to L1. * **Sequencer Rate Limits and Batch Size** * **Sequencer Rate Limit:** Default rate settings can be modified based on traffic needs. * **Batch Size:** The batch size can be adjusted for both L1 and L2 throughput optimization. #### **How to Decide Pre-Deployment Settings?** #### **Recommendation** * For low-latency rollups (high-speed apps) → Lower values for `batcher_max_channel_duration` and `proposer_proposal_interval`. * For cost-efficient rollups (large batch processing) → Higher values for these parameters to batch more transactions per submission.
## Troubleshooting
Faucet Not Sending Tokens Users have reported intermittent errors when attempting to receive tokens from the Optimism faucet, especially during periods of high demand. These errors often occur due to: * **Server Load:** High traffic can temporarily overwhelm the faucet service. * **Insufficient Funds:** The faucet may be out of funds for distribution. * **Rate Limits:** Users might hit daily or IP-based rate limits. #### **Suggested Solutions:** * Wait a few hours and retry the claim process. * Ensure the correct wallet network (L2) is selected. * Try alternative testnet faucets if available. [**Source: GitHub Optimism Docs Issue**](https://github.com/ethereum-optimism/docs/issues/1030?utm_source=chatgpt.com)
Max Number of Batches Per Sequence The **batcher** in the OP Stack is responsible for submitting L2 transaction data to L1 in a compressed format. To optimize performance and reduce costs, the `batcher_max_channel_duration` parameter controls how long a batch remains open before submission. #### **Key Settings:** * **Default:** `0` (disables batch duration tracking). * **Recommended:** Set to target **5 hours** of batching, which corresponds to approximately **1500 L1 blocks** (assuming a 12-second block time on Sepolia). #### **Best Practices:** * Adjust the batch size and interval based on network traffic patterns for cost optimization. [**Source: Optimism Batcher Configuration**](https://docs.optimism.io/builders/chain-operators/configuration/batcher?utm_source=chatgpt.com)
Resources * [Optimism Official Documentation](https://docs.optimism.io/) * [Optimism Stack Specification](https://specs.optimism.io/) * [Smart Contract Repositories](https://github.com/ethereum-optimism) * [OP Stack Configuration Tools](https://docs.optimism.io/builders/chain-operators/management/configuration)
# Getting set up
Step 1: Receive funds from the faucet [How to use a Faucet](/overview/main-functionality/how-to-use-a-faucet)
Step 2: Use hardhat configuration [How to use HardHat with Presto](/overview/features-for-developers/how-to-use-hardhat-with-presto)
Step 3: Deploy your own token [How To Deploy A Smart Contract](/overview/features-for-developers/how-to-deploy-a-smart-contract)
Step 4: Use new rollup in the web application or your backend
Step 5: (optionally) Bridge funds from the rootchain [How to Use a Bridge](/overview/main-functionality/how-to-use-a-bridge)
{% embed url="" %} Build your own layer2 chain {% endembed %}