Hi everyone. If you attended today’s Global R&D, then you heard that DFINITY is working on a managed Ethereum RPC canister as a service to help you build Ethereum integrations into your dapps.
We are still working out the details of the API and would love to get your feedback. Please let us know what you would like this canister to do if it isn’t covered by the current incarnation of the API.
Methods
request
this will send a JSON RPC request including your payload to an Ethereum node through a provider, authenticated by an API key, and will fully decode the response so that it is useful to you within the context of a canister.
We had to write a lot of code just to decode responses in our Ethereum starter project, so we think this will be a major value add.
One thing to note is that you will need to attach cycles to the call in order to use this method. if you don’t attach any cycles, or don’t attach enough cycles, an error will be returned that tells you how many cycles you need to send.
verify_message
This refers to Ethereum signed message verification. We found this method useful in our ethereum starter project, and we would like to extend it to this canister as well.
Does calling this canister instead of directly calling some eth provider via a HTTPS outcall introduce extra latency?
is it gonna be a query or an update call?
High level overview of how it’s implemented inside would be interesting as well
One of the most powerful things will be able to get variables from specific contracts on different networks in a reliable way(with witness verification). We just had someone finish up Open: ICDevs.org - Bounty #16 - EVM Witness Library - $8,000+, but a bit of infrastructure around it so that I can ask things like "give me the value of the owner value of token id “X” for contract “Z” on polygon would really explode what we are able to do.
edit: Put another way…we want to call pure functions and/or access variables on contracts on different networks and have the RPC canister do the witness validation and block height confirmation.
100% agreed. The current scope of the Ethereum RPC canister is mostly based on requirements for the internal ckETH project, so I will make sure to represent this use case (calling smart contracts) in future design meetings.
In case anyone wants to do this while the RPC canister is under development, the IC ETH starter project includes some example code for calling smart contract functions via HTTPS outcalls. One way to increase reliability is to call multiple RPC services (Cloudflare, Alchemy, Gateway.fm, etc.) and check that the results are consistent with each other.
For everyone reading this: now is your best chance to suggest or vote on a feature for the Ethereum RPC canister! We are actively using this forum topic to prioritize features with the most overall value to the community.
Yep! In addition to a general-purpose JSON endpoint, we’re initially planning to include fully typed “Candid RPC” implementations for the following methods:
eth_getStorageAt → Hugely important for canisters to be able to inspect the variable at a particular block and confirm that, for instance, a user changed a flag from true to false…or to inspect other storage that is not exposed by function calls but may be important. Huge for interoperability.
eth_blockNumber → Important for treating blocks like a nonce if you are checking storage above. Canisters will need to be self disciplined to know how many blocks to wait for finality.
eth_getCode → useful for checking the hash and contract deployed on the evm chain and making sure that your canister can compare the code to a whitelist for contracts you want to interoperate at.
eth_estimateGas → Very important to make sure your canister has enough eth at its tecdsa address to do what it is trying to do. If gas is two high you can delay with a timer.
You’re correct that there isn’t a way to hide secrets from nodes. The current plan (if I understand correctly) is to use public API keys with IP allowlists for the relevant subnet. If someone tries to use these API keys on the same IC subnet, that’s totally fair game (although we might replace the keys from time to time). This is alright because most of the cost comes from HTTPS outcall consensus rather than the RPC request itself.
In the future, we may switch to using something along the lines of SEV-SNP or a sovereign network to secure the API keys.
Hi all. I’d like to give you a quick update on the Ethereum RPC Canister we’re building. We have settled on the scope for the MVP. It is as follows:
Typed Candid-RPC requests
With the primary goal of supporting the internal ckETH project, the canister initially offers first-class support (i.e. fully-typed interfaces) for the following 6 RPC methods:
eth_getLogs: Retrieves the logs of a specified block or transaction based on filter criteria.
eth_getBlockByNumber: Returns information about a block, given its block number.
eth_getTransactionReceipt: Retrieves details about a submitted transaction.
eth_feeHistory: Provides historical fee data to estimate gas prices for transactions.
eth_sendRawTransaction: Sends a signed transaction to the Ethereum network.
eth_getTransactionCount: Retrieves the number of transactions for a specified address.
We will continue to support more endpoints after the release of the MVP.
General JSON-RPC requests
A general-purpose JSON-RPC endpoint is available for use cases requiring functionality beyond the supported Candid-RPC endpoints. This makes it possible to call a wider range of RPC services and EVM blockchains (reference list) and is used internally by both the ckICP airdrop canister and ic-eth-starter project.**
Cycles cost estimation
This query method accepts the same arguments as request and returns the number of cycles to send with an equivalent call to the request method.
This is an optional convenience method inspired by [provable_getPrice()](https://docs.provable.xyz/#ethereum-quick-start) used in Solidity oracles.
An alternative approach is to send a large number of cycles and then use the TooFewCycles error message to send a follow-up request with an exact payment if necessary. The canister will return any unused cycles.
RPC provider registry
Returns a list of available RPC providers in the current canister.
The main purpose of this list is to indicate which combinations of chain id and service are available in the given environment, since the registered API keys may vary between the local replica and the mainnet canister.
Error handling
The canister uses the following representations for errors returned by RPC methods:
RpcError: Error types which may occur when calling an RPC service.
HttpOutcallError: An error encountered when performing an HTTPS outcall.
JsonRpcError: An error returned in a valid JSON-RPC response.
ProviderError: Errors which may occur when calling a provider registered in the canister.
Signature verification
This query method provides equivalent functionality to EIP-1271 signed message verification, a cryptographic operation which is highly useful for a wide range of use cases involving cross-chain communication. For example, the ic-eth-starter example project uses this operation to confirm that an Internet Identity principal is associated with an Ethereum wallet.**
I will continue to keep you in the loop as we make progress on this service. If you think we’re missing anything, let’s discuss in this thread!
What’s the latest update? Can you share any information on timelines? The test canisters, what are the drawbacks to using them, especially in regards to API keys?
The implementation of the EVM RPC canister is basically complete and the security review is currently ongoing. If there are no findings that incur a lot of additional effort, we should be able to announce a release plan fairly soon.
L2s are currently supported in the JSON-RPC request method. You should be able to utilize that method to integrate with BASE, although you won’t have the same luxury as with the Candid-RPC endpoints.
We will look at supporting custom Candid-RPC providers in the next iteration of the canister!
ETH starter project