Update substrate-evm-adapter.md

applications/substrate-evm-adapter.md

@@ -10,12 +10,12 @@
 
 ### Overview
 
-This project aims to present an alternative approach to EVM compatibility for Substrate chains. The main goals are to improve developer experience and introduce an approach that requires the least amount of changes to the runtime and client. It does so by leveraging best parts of multiple existing compatibility solutions and other awesome ecosystem tools.
+This project aims to present an alternative approach to EVM compatibility for Substrate chains. The main goals are to improve developer experience and introduce an approach that requires the least amount of changes to the runtime and client. It does so by leveraging the best parts of multiple existing compatibility solutions and other awesome ecosystem tools.
 
 The main components of the project are:
 
 - a standalone ETH RPC adapter that will enable a partial EVM compatibility for Substrate chains
-- pallet responsible for dispatching FRAME calls from the ETH RPC adapter
+- a pallet responsible for bridging ETH RPC adapter with the Substrate chain
 
 ### Project Details
 
@@ -28,25 +28,29 @@ As stated above, main requirements are:
 
 In its essence, EVM compatibility means that a Substrate chain can be interacted with using Ethereum tools and workflows. It is obvious that EVM compatibility solutions are important for the ecosystem to attract more developers and users. Therefore, it is imperative to provide as many solutions as possible to cater to different needs and requirements.
 
-What if we could provide a way to read the state of any Substrate chains using `web3.js`, without any fundamental changes to the chain and tools? And what if we could extend this to *almost* full EVM compatibility (read and write) by adding a single pallet to the chain? This is what we aim to achieve with this project, in a nutshell.
+Imagine being able to read the state of any Substrate chain using web3.js without making fundamental changes to the chain or tools. And what if we could extend this to *almost* full EVM compatibility (read and write) by adding a single pallet to the chain? This is what we aim to achieve with this project, in a nutshell.
 
 #### Substrate ETH-RPC Adapter
 
-The cornerstone of this project is a node service adapter that emulates an Ethereum RPC. It translates any incoming Ethereum JSON-RPC calls into their Substrate equivalent RPC calls in real-time, basically forwarding it to the local `smoldot` light client or remote Substrate RPC node. From the perspective of external tools, the adapter will look like a regular ETH RPC node. It will contain the mapping logic for the most common Ethereum RPC calls, such as `eth_getBlockByNumber`, `eth_getStorage`, etc. For the sake of simplicity each pallet will be given a unique, deterministic address (much similar to precompiles in Frontier).
+The cornerstone of this project is a node service adapter that emulates an Ethereum RPC. It translates any incoming Ethereum JSON-RPC calls into their Substrate equivalent RPC calls in real-time, basically forwarding it to the local `smoldot` light client or remote Substrate RPC node. From the perspective of external tools, the adapter will look like a regular ETH RPC node. It includes mapping logic for common Ethereum RPC calls like `eth_getBlockByNumber` and `eth_getStorageAt`, etc. For the sake of simplicity each pallet will be given a unique, deterministic address, much similar to precompiles in Frontier (probably a name of the pallet in byte form).
 
-Adapter, by default, will run an embedded light client to ensure that the access to the chain state is as fast as possible. By going this route, we will avoid the need to run a full node or make any changes to the client itself. It will be possible to not run the light client and connect to a remote Substrate node instead, but users will have to be aware of latency issues and well-known security risks of trusting a remote node.
+By default, the adapter runs an embedded light client to ensure fast access to the chain state. By going this route, we will avoid the need to run a full node or make any changes to the client itself. It will be possible to not run the light client and connect to a remote Substrate node instead, but users will have to be aware of latency issues and well-known security risks of trusting a remote node.
 
 There has been some talk about reading the chain state of Substrate node using tools like Metamask or `web3.js`. And this is exactly what we will achieve by implementing this module. For tools that only need read access, be it for data analysis or other purposes, this module will be sufficient. Therefore, accomplishment of at least this part of the project will already meet the demands of some users.
 
 #### Substrate EVM Adapter Pallet
 
-The second part of the project is to provide both the read and write access to the chain. Unfortunately, due to some fundamental differences between Ethereum and Substrate chains, it is not possible to achieve this out of the box. This is why it is necessary to have at least `pallet-evm` to provide and some other module that verifies ECDSA signatures and has some account mapping logic. This pallet will be loosely coupled with `pallet-evm` to access the EVM runner for executing bytecode. And will utilise `frontier`'s `dispatch` precompile to dispatch FRAME calls originating from the ETH RPC adapter. This part of the project can be opt-in feature that can be added to the runtime if close to full EVM compatibility is desired.
+The second part of the project is to provide both the read and write access to the chain. Unfortunately, due to some fundamental differences between Ethereum and Substrate chains, it is not possible to achieve this out of the box. This is why it is necessary to have at least `pallet-evm` to provide and some other module that verifies ECDSA signatures and has some account mapping logic. This pallet will loosely couple with `pallet-evm` to access the EVM runner, executing bytecode efficiently. And will utilise `frontier`'s `dispatch` [precompile](https://github.com/polkadot-evm/frontier/tree/master/frame/evm/precompile/dispatch) to dispatch FRAME calls originating from the ETH RPC adapter. This part of the project can be opt-in feature that can be added to the runtime if close to full EVM compatibility is desired.
 
+For account mapping, we will follow the [approach](https://forum.polkadot.network/t/wrappedevm-eth-rpc-compatibility-layer/2775/6) of `Unique`: hashing `AccountId20` to get `AccountId32` and truncating `AccountId32` to get `AccountId20`. This way, users will have to first top up their corresponding, deterministic Substrate style accounts before interacting with the chain.
 
 #### Full flow
 
 The following diagram is a high-level illustration of how the project will work:
 
+![Untitled-2024-03-27-2305](https://github.com/dastansam/Grants-Program/assets/22231829/4a1be51b-17b0-43a4-b42f-6f5694d3911f)
+
+
 #### Limitations and challenges
 
 Some limitations arise from the fact that Substrate and Ethereum are fundamentally different. For example, transaction hashes are not unique in Substrate, dust accounts issue is handled in Substrate, but not in Ethereum, etc. Therefore, it should be noted that it is extremely difficult to provide "full" EVM compatibility. And during the course of the development, there will certainly be some decisions that won't align with true EVM experience. However, the goal is to provide a *good enough* compatibility that will be agnostic to the chain and tools used. Most importantly, in some cases it would be even better to default to Substrate-like behaviour, since it is, in some sense, originally designed to fix some of the issues that Ethereum still has.
@@ -66,11 +70,11 @@ DApp demo is a simple web application that will interact with the Substrate chai
 These are the existing solutions that aim to provide EVM compatibility for Substrate chains. The most notable ones are:
 
 - **Frontier**: Offers full EVM compatibility by incorporating an EVM execution engine into the runtime and EVM RPC in the client. It demands significant changes to both the node and runtime, potentially introducing complexity and performance overhead.
-- **`ethink!`**: Aims to add EVM compatibility to `ink!` smart contracts. While innovative, it mainly focuses on a specific use case and does not provide a comprehensive solution for general EVM compatibility. It also requires embedding ETH RPC to the client. However, it is similar to our project in how it uses a custom pallet as a middleman between the EVM and the Substrate chain.
+- **`ethink!`**: Aims to add EVM [compatibility](https://sasha.ink/proposals/ethink-01/#stage-0-proof-of-concept--done) to `ink!` smart contracts. While innovative, it mainly focuses on a specific use case and does not provide a comprehensive solution for general EVM compatibility. It also requires embedding ETH RPC to the client. However, it is only similar to our project in how it uses a custom pallet as a middleman between the EVM and the Substrate chain.
 - **Polkamask**: A MetaMask snap designed to connect MetaMask with Substrate chains. Though it provides an easy-to-use solution for end-users, it relies on trusting an external plugin, raising concerns about security and trustlessness. It also doesn't provide a way to interact with the chain state outside of MetaMask.
 - **Acala EVM+**: An EVM compatibility solution for Acala Network. It is important to note that, among other solutions, this one is the closest to what we aim to achieve, however, it is tailored to Acala Network and requires some changes to existing developer tools (custom `bodhi.js` instead of `web3.js`) to work. Moreover, it uses modified `pallet-evm`, rpc adapter only works with remote Acala node, and it has some additional runtime APIs, etc.
 
-Our solution aims to use the best parts of these existing solutions while addressing some of their limitations. By providing a standalone ETH RPC adapter and an EVM adapter pallet, we offer a flexible and lightweight approach to EVM compatibility that can be easily integrated into any Substrate chain without imposing heavy requirements on the client and the runtime.  With a custom pallet that is loosely coupled with `pallet-evm`, we ensure keypair compatibility and a way to dispatch FRAME calls from the ETH RPC adapter. And most importantly, the goal is to be as generic as possible, so that it can be easily integrated into any Substrate chain.
+Our solution aims to use the best parts of these existing solutions while attempting to address some of their limitations. By providing a standalone ETH RPC adapter and an EVM adapter pallet, we offer a flexible and lightweight approach to EVM compatibility that can be easily integrated into any Substrate chain without imposing heavy requirements on the client and the runtime. By embedding the light client, we achieve faster and more reliable access to blockchain data, reducing latency and avoiding dependencies on external nodes. With a custom pallet that is loosely coupled with `pallet-evm`, we ensure keypair compatibility and a way to dispatch FRAME calls from the ETH RPC adapter. And most importantly, the goal is to be as generic as possible, so that it can be easily integrated into any Substrate chain.
 
 ## Team :busts_in_silhouette:
 
@@ -87,8 +91,8 @@ Our solution aims to use the best parts of these existing solutions while addres
 
 ### Legal Structure
 
-- **Registered Address:** No registred entity
-- **Registered Legal Entity:** No registred entity
+- **Registered Address:** No registered entity
+- **Registered Legal Entity:** No registered entity
 
 ### Team's experience
 
@@ -117,13 +121,13 @@ Team members:
 
 ### Overview
 
-- **Total Estimated Duration:** 3 months
+- **Total Estimated Duration:** 3.5 months
 - **Full-Time Equivalent (FTE):**  1 FTE
 - **Total Costs:** 30,000 USDT
 
 ### Milestone 1 — ETH RPC Adapter
 
-- **Estimated duration:** 7 weeks
+- **Estimated duration:** 8 weeks
 - **FTE:**  1
 - **Costs:** 15,000 USD