# EVM RPC Canister **URL:** \ **Category:** Developers\ **Created:** [September 26, 2023, 12:25am UTC](https://forum.dfinity.org/t/evm-rpc-canister/23313 "2023-09-26T00:25:46Z")\ **Posts on this page:** 1\ **Showing post:** 53
**Author:** ![gregory-demay](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.dfinity.org/gregory-demay/32/8165_2.png) [@gregory-demay](https://forum.dfinity.org/u/gregory-demay)\ **Post date:** [August 26, 2024, 7:36am UTC](https://forum.dfinity.org/t/evm-rpc-canister/23313/53 "2024-08-26T07:36:57Z")
Hi everyone! 👋 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](https://github.com/internet-computer-protocol/evm-rpc-canister/releases/tag/release-2024-05-23) requires some strong trust assumptions regarding the principal that owns a provider (identified by [Provider::owner](https://github.com/internet-computer-protocol/evm-rpc-canister/blob/release-2024-05-23/src/types.rs#L355)), which is currently set to whoever initialized the canister. In the case of the [EVM-RPC canister](https://dashboard.internetcomputer.org/canister/7hfb6-caaaa-aaaar-qadga-cai), 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`](https://github.com/internet-computer-protocol/evm-rpc-canister/blob/release-2024-05-23/src/main.rs#L173). 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`](https://github.com/internet-computer-protocol/evm-rpc-canister/blob/release-2024-05-23/src/main.rs#L180). 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, 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](https://github.com/internet-computer-protocol/evm-rpc-canister/releases/tag/release-2024-05-23) [forked the code of the ckETH minter](https://github.com/internet-computer-protocol/evm-rpc-canister/blob/79681296c422710d6acd6be87726741c1cda499f/Cargo.toml#L30) 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! --- _[View the full topic](https://forum.dfinity.org/t/evm-rpc-canister/23313)._