Skip to main content

Overview

Advanced
Ethereum
Tutorial

EVM RPC is an ICP canister smart contract for communicating with Ethereum and other EVM blockchains using an on-chain API. Communication with EVM-compatible chains includes obtaining and sending information such as:

  • The logs of a specific block or transaction.

  • Information about a block.

  • Details about a transaction.

  • Historical data regarding the network's gas fee.

  • Transactions for a specific address.

  • Submitting a signed transaction.

The source code for this project is available on GitHub (internet-computer-protocol/evm-rpc-canister ⭐️) under the Apache 2.0 license.

Goal​

The goal of the EVM RPC canister is to act as a gateway between canisters on ICP and EVM-compatible networks through RPC services such as Alchemy, Ankr, or Cloudflare. The EVM RPC canister provides the necessary methods for other ICP canisters to send requests to the Ethereum JSON-RPC API and receive responses.

Terminology​

Below is a list of terms used to describe different aspects of using the EVM RPC canister:

  • RPC service: An IPv6 service such as Alchemy, Gateway.fm, or CloudFlare that offers access to the Ethereum JSON-RPC API over HTTP. Note that other EVM blockchains are often covered by such a JSON-RPC API as well.

  • network: An EVM blockchain such as the Ethereum mainnet or Sepolia testnet.

  • chain id: A well-known unique numeric identifier for an EVM network.

-provider: A specific JSON-RPC service registered in the EVM RPC canister. Every chain id for a particular service requires a different provider and typically also requires a different API key. Multiple providers can be registered for a service / chain id combination.

Management of API keys​

RPC providers often require API keys be used to authenticate RPC requests. Authenticated requests help mitigate potential DoS attacks that exhaust the request rate limits set by RPC providers. Using an API key can come with challenges for developers, such as:

  • API keys for RPC providers often require a paid subscription and/or compute credits beyond a certain number of requests per month.

  • For developers who want to build a quick prototype, it may not be worth procuring multiple API keys until later in development.

  • When a dapp developer controls an API key, the dapp is considered less decentralized.

  • Storing API keys securely is not supported at the platform level and requires developers to use their own strategies for protecting their keys, creating an additional complexity for developers who want to use reproducible builds. Personal keys are also visible to all nodes on the ICP subnet. Learn more about authentication.

To provide a solution for developers, the production EVM RPC manages the API keys for each RPC provider on behalf of the developer. If a developer wants to use their own API keys, however, they can pass their own keys to the EVM RPC canister. Test variations of the EVM RPC canister do not use API keys.

Costs​

Calls made to the EVM RPC canister cost cycles. The cost per request is generally similar to making the equivalent HTTPS outcalls in your own canister.

Learn more about the costs of EVM RPC requests.

Deployed EVM RPC canisters​

Next steps​