Dear Polkadot Community,

my name is Sasha 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 my 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.

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

Cheers,
Sasha.

---

(*upd. 12.01.2024: Project name was changed (s/polkamask/ethink/g) for the reasons explained in the comment. Crates are to be renamed in the future updates.)

Meet ethink!

(Please read the full proposal here)

ethink! is a set of crates unlocking the Ethereum RPC compatibility for smart contracts parachains. It allows dApp developer to migrate his users from Ethereum ecosystem to Polkadot ecosystem without changing user experience UI/UX-wise!

Rationale

Polkadot embraces no doubt the most advanced technologies in the industry. This allows us to do plenty of great things. With cross-chain interoperability and breaking fast execution engines coming, we have strong chances to become the number one ecosystem of decentralized applications.

For that to become a reality though, we also need to attract users. Most dApp users nowadays live in Ethereum world. We do have EVM-based chains in our ecosystem which leverage Ethereum’s massive userbase share. But EVM is the technology of bygone days. We can do better!

What if we could allow Ethereans to enjoy our native, more performant, feature-rich and cost-effective ink! smart contracts? Seamlessly, through the same interfaces they use for years. No cognitive barriers, no need to install and learn new tools. Just do your business as usual. Just use MetaMask for that, if you wish. Now with ink! dApps, too.

Current Ethereum compatibility solution for Substrate, Frontier, brings it along with the EVM executor. The following chart should make it clear why we might want not to take such an adjunct to the user-side compatibility feature:

(data source )

The performance downside of EVM is obvious. Why would a large successful dApp like DEX migrate to a chain where its contracts run twice slower? On the other hand, just having faster and cheaper runtime executor alone does not buy us large DeFi platforms coming to Polkadot from other ecosystems.

But let’s dream a little bit, and imagine what if we could port Uniswap to a Polkadot parachain? With everything working just the same way from the user perspective: same UI/UX, same signing extensions, same address formats, but definitely much better experience thankfully to lighting fast contracts execution under the hood.

Sounds tempting, isn’t it? Discussions on having Ethereum RPC compatibility for Polkadot smart contracts have being around for a while. I took some time to play with the idea and see if it’s something feasible to implement. This proposal describes what got out of it.

Project Status: Working Proof of Concept ☑

You can find working PoC in the ethink! repository.

The main fact about this PoC is that.. it works! 🎊 You can deploy a basic ink! contract to polkamask-node and then indeed interact with it via MetaMask as if it was an EVM contract. I encourage you to try the Demo yourself by following the instructions in the project repository (please do provide your feedback 🙏🏼 once tried it!).

Technical details of the current implementation can be found in the full proposal.

Next Stage: Early Prototype (Q1 2024)

We now have the concept proven with the PoC delivered at the Stage-0. But it is still a long way to make it viable for production parachains. This stage objective is to brush up the ethink! from its current “YOLO-hack-and-call-it-a-day” state into a solid starting point for sustainable and streamlined product development, effectively moving it towards a working Early Prototype.

We do this in agile style, keeping this project aimed at the applied usage at all stages.

Therefore each stage should bring a new real example of a practical use. A dApp around ERC20 token standard seems to be a good candidate for the next reality test for ethink!, because it has plenty of existing front-ends used by Ethereans. As this is one of the most popular contracts/dApps, it should serve us as a good litmus test.

Battle-Testing ⚒

It is important to emphasize that this project is already moved out of a purely theoretical research phase once the PoC has 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!

Full Proposal

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

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.