EVM RPC Canister

Developers
53

Hi everyone! :wave:
I would like to share some updates regarding the next release of the EVM-RPC canister that is planned for the next quarter.

Improve Security

The current release requires some strong trust assumptions regarding the principal that owns a provider (identified by Provider::owner), which is currently set to whoever initialized the canister. In the case of the EVM-RPC canister, this corresponds to a principal (rxqtr-vwnhc-q4tjx-lozjs-u7nxo-2tqsn-cusmy-ip2ke-zy52n-x2ukd-gae, see the output of getProviders) controlled by an employee of the Dfinity foundation. Any user of the EVM-RPC canister currently trusts that principal for:

  1. Liveness/Availability: The owner could for example, without requiring the execution of any NNS upgrade proposal, completely remove a given provider by calling unregister_provider.
  2. Correctness: The owner of a provider could for example, without requiring the execution of any NNS upgrade proposal, arbitrarily change the hostname of a provider to an adversary-controlled server by calling update_provider.

We believe that the current design must be improved, so that any change in the providers supported by the EVM-RPC canister (except for the concrete API keys being used) requires an NNS upgrade proposal. We therefore plan the following changes:

  1. Hard-code the list of supported providers and make it immutable. That means,

    1. Remove the existing access control and all mutating methods (register_provider, unregister_provider, update_provider, manage_provider)
    2. Change the Provider struct so that only the API key can be set at runtime and nothing else. The existing provider IDs will be kept so that the change should not be breaking for existing users.
    3. Add a new method to set an API key for a given provider. This method can only be called from authorized principals identified in the canister initialization or upgrade arguments.

  2. Re-install the canister from scratch. This will involve some down time (a couple of minutes), the time the API keys are re-provisioned.

In our opinion, the proposed changes address the aforementioned issues:

  1. Reduce liveness/availability trust assumption: Removing a provider would require an NNS proposal, which reduces the trust needed in the owner of an API key. Note that since some providers used by the EVM RPC canister require a central party to pay for the API keys, trust in this central party (currently the Dfinity foundation) to keep paying for those keys is unavoidable.
  2. Completely remove the correctness assumption: whoever is authorized to set an API key cannot influence in any way the correctness of responses provided by the EVM RPC canister.

Improve Maintainability

The current release forked the code of the ckETH minter to initially speed up the development. However, this has become a burden for maintainability and will be removed. Users should not be impacted by this change (this can be seen as an implementation detail).

Fee free to comment or ask any clarifying questions, we welcome any feedback!

6 Likes