Summary

Today we're excited to announce that the EVM RPC canister is now available for use! It is currently in beta, and will be while we iron out any kinks to ensure that it meets all the demands of your dapps safely and performantly. Test it out yourself and let us know if you run into any issues by either opening up an issue on GitHub or submitting feedback on the ICP Feedback Board.

View on GitHubView the documentation

What is it?

The EVM RPC canister is a service that lets you easily build integrations between ICP canister smart contracts and Ethereum smart contracts. It simplifies the process of procuring, managing, and paying for API keys for various EVM RPC providers. It also helps keep dapps secure by automatically inferring consensus among multiple RPC providers with each outbound request.

The problem

Building an integration between a canister and the Ethereum network currently requires the use of HTTPS outcalls. These calls are facilitated by services (often called RPC node providers) that require the use of subscription-based API keys. This presents developers with a few non-trivial challenges:

Management of API keys

RPC providers for Ethereum typically charge a subscription-based fee in order to use their services. While some offer free tiers, the quotas can be exhausted quickly in a production setting.

Furthermore, it is not straightforward to manage an API key (let alone multiple) in the context of a canister. There are a number of challenges to overcome:

• How do you ensure that a single developer managing API keys does not pose a centralization risk to the users of the dapp?

• What if you just want to kick the tires?

• What if you want to build something quickly?

• How do you keep your API keys secret?

Cost, complexity, and consensus

The problem is further compounded if we start to take cost into account. There are a number of factors that go into the calculation a developer makes when deciding to build something:

• How much engineering effort will this take?

• How much do I need to pay for third-party services (e.g. Ethereum RPC providers)?

• How important is trust and security to my users?

If managing API keys independently, the total cost begins to balloon as usage scales and the need for additional layers of consensus becomes more important - the latter requires querying multiple RPC providers, which each require an individual subscription, API key, management, etc.

What the EVM RPC canister solves

The EVM RPC canister abstracts away much of the complexity around managing keys and querying the Ethereum network for blocks, transactions, and other data with an easy to use, onchain API. It performs automatic consensus inference by sending requests to multiple providers in parallel and ensuring the responses agree. It also lets you send requests to other EVM chains through a generic request interface. Overall, it simplifies what you as a developer need to think about when setting up your Ethereum integrations.

How to use

Below is a quick start to getting an integration with the EVM RPC canister up and running. It's a simplified example that omits many complexities, but hopefully it still shows you how easy it is to get started.

Please ensure you install dfx before proceeding with the steps below.

Start a new project

dfx new evm_rpc_example
cd evm_rpc_example

Add the EVM RPC canister as a dependency

Using dfx deps we can automatically install the EVM RPC canister wasm into our local environment.

Edit the dfx.json file at the root of your project to add the EVM RPC canister as a dependency under the "canisters" key:

{
  "canisters": {
    "evm_rpc": {
      "type": "pull",
      "id": "7hfb6-caaaa-aaaar-qadga-cai"
    }
  },
  "defaults": {
    "build": {
      "args": "",
      "packtool": ""
    }
  },
  "output_env_file": ".env",
  "version": 1
}

Next, from your terminal, run the following command to fetch all dependencies:

dfx deps pull

Start the local replica:

dfx start --clean --background

Set the init args for the EVM RPC canister:

dfx deps init evm_rpc --argument '(record { nodesInSubnet = 31 })'

Locally deploy the evm_rpc canister:

dfx deps deploy evm_rpc

Now, use dfx to get the current Ethereum gas price:

dfx canister call evm_rpc request '(variant {Custom=record {url="https://ethereum.publicnode.com"}},"{\"jsonrpc\":\"2.0\",\"method\":\"eth_gasPrice\",\"params\":[],\"id\":1}",1000)' --wallet $(dfx identity get-wallet) --with-cycles 1000000000

The response:

(variant { Ok = "{\"id\":1,\"jsonrpc\":\"2.0\",\"result\":\"0x8ca25b481\"}" })

Raw RPC

You might be asking why the gas price is returned as a hex value. This endpoint was reached using the generic request method expose by the EVM RPC canister. This endpoint does not offer the same conveniences as the typed Candid RPC endpoints, nor does it perform automatic consensus inference. This method is exposed primarily to give you access to any Ethereum RPC API method in case the typed Candid RPC endpoints are not sufficient.

In the coming months, more tooling and improvements to the EVM RPC canister are expected to be released that will make it much easier to process raw Ethereum RPC data.

Candid RPC

Let's see what it looks like to call a typed Candid RPC method.

dfx canister call evm_rpc eth_getTransactionCount '(variant {EthMainnet = opt vec {variant {Cloudflare}}}, null, record {address = "0xdAC17F958D2ee523a2206206994597C13D831ec7"; block = variant {Latest}})' --with-cycles 1000000000 --wallet=$(dfx identity get-wallet)

Here, we call the eth_getTransactionCount method using Cloudflare as a provider. This will return the number of transactions for the given contract (i.e. address 0xdAC17F958D2ee523a2206206994597C13D831ec7)

We get back the following, which tells us there is one transaction:

(variant { Consistent = variant { Ok = 1 : nat } })

Bonus

The indomitable @rvanasa put together a small example that shows how to call the EVM RPC canister from a Motoko canister. Check it out: Motoko EVM RPC

Conclusion

The EVM RPC canister is designed to help you build integrations with Ethereum smart contracts quickly, easily, and in a cost-effective manner. While it is still early (and there are many improvements to come), this is a good chance to get ahead and build slick ICP cross-chain dapps!

If you have any feedback, or feel that the EVM RPC canister is missing any features or functionality, please write on GitHub, on the Developer Forum, or on the Feedback Board.

Looking forward to your comments!

Credits

This project would not have been possible without all the hard work and tireless dedication from a truly world-class team. Big thank you to Manu, Thomas, Grégory, and most of all Ryan for their contributions to this project. Ryan really put his heart into this project and it shows. Thank you, Ryan!