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

Dear Polkadot Community,

my name is Sasha (@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. Then as a member of ink! core team at Parity Technologies. And nowadays as an independent Rank-II member of the 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 have been delivered. See the Delivery-01 report for the details.

This project is publicly discussed at the Polkadot Community Forum (this 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.

---

Rationale ☝

tl;dr: We want to port popular Ethereum dapps onto Polkadot to attract more users to our ecosystem. ethink! supports this by making pallet-contracts Ethereum RPC-compatible.

This has been described in details here and here.

What's Done ✔

The following project stages are completed:

✅ Stage-0. Proof Of Concept.

1. Fully-fledged smart contracts parachain node, which exposes a minimal required set of Ethereum RPC methods.
2. Runtime with pallet-contracts aboard,
   which also provides means for validating the incoming Ethereum transaction and transforming it into a Substrate extrinsic.
3. Crate pallet-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. 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. A fork of cargo-contract tool to help ink! developers use the same ink! tooling with
   Ethereum-flavored cryptography primitives and Account format.
6. A fork of ink! with a little patch to allow working with AccountId20 addresses.
7. A simple dApp for demo purposes.
8. Some initial amount of documentation, including the RPC requests registry and a quickstart guide.

✅ Stage-1. Early Prototype.

1. Make ethink! work with ERC20 example.

2. Polish Ethereum RPC methods implemented at the previous stage.

3. Implement more Ethereum RPC methods from the by now mocked set.

4. Add various tests, from unit to integration ones.

5. Overall code refactoring and better crates organization.

6. Documentation both in rustdoc and in the form of a Rust book

7. Make the project work with unchanged upstream dependencies of polkadot-sdk and ink!.

Early Prototype version has been released. 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 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, 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:

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 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 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.

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.

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 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,2) 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 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 section of the Proposal, with more details to certainly come in the future ethink! docs.