internet-computer-protocol / evm-rpc-canister

Interact with EVM blockchains from the Internet Computer.
https://internetcomputer.org/docs/current/developer-docs/multi-chain/ethereum/evm-rpc/overview
Apache License 2.0
63 stars 13 forks source link

Refactor to remove `cketh-minter` dependency #243

Closed rvanasa closed 4 weeks ago

rvanasa commented 2 months ago

The current EVM RPC implementation reuses logic from a fork of the ckETH minter canister codebase. Removing this dependency would speed up development and improve testability of the canister.

gregorydemay commented 2 months ago

@rvanasa @THLO I started to look into a bit more details as to what this would entail and came up with the following rough plan (please feel free to comment/challenge any point or suggest alternative)

Analysis

Usage of cketh_common in production code as of 04505cce853362ff1b8ea4954028333f54394419

Overview

  1. The main reason for using cketh_common is the usage of EthRpcClient, which contains all the logic for HTTPs outcalls (the EVM-RPC canisters method doing HTTPs outcalls, e.g., eth_fee_history, delegate to EthRpcClient).
  2. From there follows the usage of the various parameter or response types used by EthRpcClient

Rough Plan

  1. Copy over all data types from cketh_common (e.g., FeeHistory, LogEntry, but not EthRpcClient), into this repository. As part of this effort I think it would be useful
    1. to have a dedicated crate for the Candid types used in the API of the EVM-RPC canister. The easiest would be for this crate to live in the same repo as the evm-rpc canister so that it's always in sync.
    2. to have a dedicated crate for the type CheckedAmountOf (independent of the EVM-RPC canister) since this is also used by the ckETH minter (alternatively, integrate it into the phantom_newtype crate).
    3. We may want to have a clear separation between the types that are used for the candid interface (user/canister < > EVM-RPC) and the types that are used for the RPC communication (EVM-RPC <> Ethereum Json Provider), since the first are Candid-encoded and have an API character, while the second are JSON encoded and are an implementation detail (from the EVM-RPC canister point of view)
  2. Copy over the full code of EthRpcClient.
  3. Eliminate the dependency on cketh_common