Dear Polkadot Community,

my name is Sasha ([@agryaznov](https://github.com/agryaznov/)) and I have been working on Polkadot smart contracts technology stack for several years by now. First as an external contributor supported by Web3 Foundation [grants](https://github.com/w3f/Grants-Program/blob/master/applications/candle_auction_ink.md). Then as a member of **ink!** core team at Parity Technologies. And nowadays as an independent *Rank-II* member of the [Polkadot Fellowship](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fsys.ibp.network%2Fcollectives-polkadot#/fellowship).

The following is the second proposal for the project I'm currently working on, which I find quite promising for improving the Polkadot smart contracts adoption rate and, as a result, the overall ecosystem userbase growth. **All the milestones of the [Proposal-01](https://polkadot.subsquare.io/referenda/408) have been delivered. See the [Delivery-01](https://sasha.ink/delivered/ethink-01/) report for the details**.

This project is publicly discussed at the **Polkadot Community Forum** ([this](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375) thread), where it has received positive feedback and some inspirations for future features development.

Hoping you would consider giving this proposal some support. In any case, your feedback would be as always precious.

Cheers, 
Sasha.

---

![ink+mm](https://sasha.ink/images/ink+mm.png)

## Rationale ☝

**_tl;dr_**: We want to port popular Ethereum dapps onto Polkadot to attract more users to our ecosystem. [_ethink!_](https://github.com/agryaznov/ethink) supports this by making _pallet-contracts_ Ethereum RPC-compatible.

 

This has been described in details [here](https://sasha.ink/proposals/ethink-01/#rationale) and [here](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375).


## What's Done ✔

The following project stages are completed: 

<details>
<summary>
✅ Stage-0. Proof Of Concept.
</summary>

1. [x] Fully-fledged smart contracts [parachain node](https://github.com/agryaznov/ethink/tree/master/template/node), which exposes a *minimal required* set of Ethereum RPC methods.
2. [x] Runtime with [pallet-contracts](https://docs.rs/pallet-contracts/26.0.0/pallet_contracts/) aboard,
 which also provides means for validating the incoming Ethereum transaction and transforming it into a Substrate extrinsic.
3. [x] Crate [pallet-ethink](https://github.com/agryaznov/ethink/tree/master/frame/ethink) which is responsible for routing this extrinsic to an appropriate runtime destination module, 
 be it the executor (pallet-contracts) in case the transaction destination is a contract address, or the accounting module (pallet-balances) in case it is a user-owned account.
4. [x] Set of auxiliary crates to support working with Ethereum-flavored cryptography and data types. 
 *(Mostly taken from *Frontier* to re-use existing libraries as much as possible.)*
5. [x] A [fork of cargo-contract](https://github.com/agryaznov/cargo-contract/tree/polkamask) tool to help ink! developers use the same ink! tooling with 
 Ethereum-flavored cryptography primitives and Account format.
6. [x] A [fork of ink!](https://github.com/agryaznov/ink/tree/polkamask) with a little patch to allow working with _AccountId20_ addresses.
7. [x] A simple [dApp](https://github.com/agryaznov/ethink/tree/master/dapp) for demo purposes.
8. [x] Some initial amount of documentation, including the RPC requests registry and a quickstart guide.

</details>

<details open="">
<summary>
✅ Stage-1. Early Prototype.
</summary>

1. [x] Make ethink! work with `ERC20` example. 

2. [x] Polish Ethereum RPC methods implemented at the previous stage. 

3. [x] Implement more Ethereum RPC methods from the by now mocked set. 
 
4. [x] Add various tests, from unit to integration ones. 

5. [x] Overall code refactoring and better crates organization. 

6. [x] Documentation both in rustdoc and in the form of a Rust book
 
7. [x] Make the project work with unchanged upstream dependencies of _polkadot-sdk_ and _ink!_. 

</details>

 

**Early Prototype** version has been [released](https://github.com/agryaznov/ethink/releases/tag/0.2.0). It provides the template node for dapp developers and parachain builders to experiment with porting Ethereum dapps onto a _pallet-contracts_-based runtime. It works end-to-end with basic smart contracts, and its functionality is covered with integration tests. It does not require any changes to be upstreamed neither to _polkadot-sdk_ not to _ink!_. It works as an add-on to a parachain's runtime and client. Please, read the full [_Delivery-01_ report](https://sasha.ink/delivered/ethink-01/) for more details.


## What's Next 💡

Now that we have a development node working, we'd like to move further and evolve the project towards a **testnet-ready state**. Aside from pure technical issues needed to be solved for this (like e.g. benchmarking the _pallet-ethink_ for setting proper weights, and updating to latest _polkadot-sdk_ version), there is also one **crucial** thing regarding usability for dapp developers. 

As has been discussed in the [forum post](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375#the-road-to-all-hands-compatibility-6), _ethink!_ allows to port an Ethereum dapp onto a _pallet-contracts_ parachain without altering user experience. When it comes to developers though, they would still have to do some work:

![dapp layers](https://sasha.ink/images/ethink-post-1_3.1.png)

 
 

In particular, there is a conventional difference in the way contracts inputs are encoded in Ethereum and Polkadot: _Solidity_ contracts use ABI encoding, whereas _ink!_ contracts use SCALE. This can be solved either on the client side, by altering frontend logic of the dapp so that it encodes call inputs to SCALE instead of ABI. Or, this can be solved on the smart contract side, by adding ABI-decoding logic for its inputs (and ABI-encoding logic for its outputs) right into the contract. The second option seems to be achievable in short-term. But it might be a tricky thing to implement for a contract developer at the current state of things.

What we thereby want to do is to provide clear tools and guidance for contract developers to deal with Ethereum ABI-encoded data.

**Please, find the detailed [scope](https://sasha.ink/proposals/ethink-02/#stage-2-testnet-ready-prototype-q2-2024) of the next Stage in the full Proposal:** https://sasha.ink/proposals/ethink-02/ .


## Battle-Testing ⚒

It is important to emphasize that this project has moved out of a purely theoretical research phase since the **PoC** and **Early Prototype** have been released. 
Currently, it is a real working piece(s) of software which everybody willing can play with following the [guidelines](https://github.com/agryaznov/ethink/tree/0.2.0?tab=readme-ov-file#quickstart) provided in the project repository. 

**More than that**, the deliverables of this project are planned to be battle-tested via deployment to the experimental smart contracts parachain [**Yerba Network**](https://yerba.network/).

Meanwhile, all other *pallet-contracts*-based chains are warmly welcomed to the club!
 

## Public Discussion 

Please join the community discussion of the project at the [Polkadot Forum](https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375).


## Full Proposal

Full proposal text can be found here: https://sasha.ink/proposals/ethink-02/


## FAQ 🙋

### 1. How ethink! is different from Frontier?

Long story short, Frontier provides Ethereum compatibility to a quite deep degree, starting from the RPC endpoint down to the execution engine level. This makes your chain be more like a replica of an Ethereum, having its own EVM and in fact even producing (*and storing on chain*) the Ethereum blocks alongside your usual Substrate blocks.

With ethink!, we take a different approach: we don't want the [EVM part](https://sasha.ink/proposals/ethink-01/#rationale) of the deal. ethink! design was partially inspired by Frontier's, and it seeks to re-use its solutions as much as possible. Still, whereas Frontier's RPC facade is _tightly coupled_ with the EVM, ethink! provides the same-looking RPC interfaces for the *pallet-contracts* sitting under the hood.

### 2. Wouldn't creating a MetaMask Snap help?

MetaMask indeed provides the API for building special extensions (called _snaps_) for it to be used with custom chains. We are aware of the projects ([1](https://github.com/ChainSafe/metamask-snap-polkadot),[2](https://metamask.io/news/developers/aleph-zero-snap-onboarding-web-3-users-to-aleph-zero-network/)) implementing such _snaps_ for Substrate chains, and indeed we did consider this option for ethink! as well. 

However, taking this way for the objectives of our project seems to be a suboptimal decision, because: 

1. ethink! unlocks compatibility _not solely_ with MetaMask but with _any_ tooling working through the Ethereum RPC. 
 MetaMask is _just one_ of the most popular ones, but there are more others! We build ethink! having the *decentralization* among our core values in mind. 
 
2. One of the ultimate goals of ethink! is to allow _porting the existing_ Ethereum dApps to Polkadot _without_ alteration of the front-end part of it and its UX. Unfortunately this can't be solved with just an add-on to a browser extension, as it requires solving [compatibility issues](https://sasha.ink/proposals/ethink-01/#compatibility-decoded-) on lower levels. 

3. A _snap_ is a 3rd party add-on to the *private keys holding* extension. If this add-on works with different from MetaMask's default cryptography primitives, then it is likely to alter the signer part of it. This means that: 
 + first, it requires users to install some new piece of software, 
 + second, it requires users to trust this new piece of software their funds. 
 
 So at the end of the day it only _seems_ like not building a new wallet, while in the practice it is.

_(This approach might be worth testing as well. We just explained how's it different from ours.)_

### 3. How ink! and Solang are related to ethink!?

_ink!_ and _Solang_ are two distinct, and independent of each other, means for producing _pallet-contracts_ compatible Wasm binaries.
_ink!_ is a Rust-alike high-level language to write contracts which are then compiled into specially crafted Wasm blobs. 
_Solang_ is a compiler which does the same with contracts written in Solidity. 

The idea of the ethink! is to provide user-side seamless Ethereum RPC compatibility for Polkadot dApps. This means that we are likely to be able to make the process look the same for the dApp _user_ without requiring her to change anything. However, for the dApp _developer_ it would mean a good amount of job to be done to make this happen. Here is where our existing tooling for contract development, such as _ink!_ and _Solang_, might come to help. We provided some hints on this in the [compatibility](https://sasha.ink/proposals/ethink-01/#compatibility-decoded-) section of the Proposal, with more details to certainly come in the future ethink! docs.

- **Problem Statement:** Enhancing Polkadot smart contracts adoption by making them Ethereum RPC-compatible.
- **Significance:** Improving the Polkadot ecosystem userbase growth by attracting Ethereum dapp developers.
- **Proposed Solution:** Developing ethink! to enable porting Ethereum dapps onto Polkadot using pallet-contracts.
- **Expected Outcomes:** Increased usability for dapp developers, clear tools, and guidance for dealing with Ethereum ABI-encoded data.

#801 ink! + Ethereum RPC = ethink!. Proposal-02: Getting Testnet-Ready.

No Active Proposals