EVM Runtime base token

[alex.shevchenko]

EVM Runtime discussion has started here. The goal of this particular discussion is to dig into the EVM Runtime base token from the product perspective.

Background

There’s an ongoing project around adding EVM Runtime to the NEAR blockchain. The idea behind it is to allow for [presumably] simple migration of the developed Ethereum dApps to NEAR blockchain (with all the corresponding benefits of the faster confirmation times and much lower fees). Simple implies that dApp developers won’t need to re-write their Solidity code (just use truffle migrate or similar), and users won’t need to learn how to send their transactions (Metamask just works, maybe with minor additional steps). The question is how to implement this? And this discussion is devoted to one particular aspect of the implementation – the base EVM Runtime token.

Current state of affairs

At the moment EVM Runtime is implemented as a NEAR smart contract, just with the EVM code precompiled. You can see the details of implementation in the EVM Runner.

EVM gas is mapped to NEAR gas by linearly adjusting based on statistical correlation between how much resources the EVM smart contracts taken measured by NEAR’s instrumentation.

The fees paid by transaction sender are always charged in $NEAR. Relayers are used to allow users who are not holding $NEAR to run transactions inside and outside of EVM.

This discussion doesn’t affect transaction fee part in any way.

EVM currently uses $NEAR as a base token. Base token inside EVM is what used for account and contract balances and what will be passed around as inside msg.value.

There’re methods that allow depositing and withdrawing $NEAR to EVM Runtime accounts.

Also method call takes attached_deposit in $NEAR and passes it as msg.value into the subsequent calls of EVM. Which is used by base NEAR runtime contracts to call into EVM.

Known issues of the approach:

• ETH->$NEAR FE problems. Migration of dApps from Ethereum to NEAR EVM runtime will encounter ETH->$NEAR change problems. For example, FE of dApps should show $NEAR instead of ETH costs for the transaction (different labels), and in case there’s a re-calculation of costs into USD, FE would need to get the current exchange rate, which is yet uncommon for NEAR<–>USD pair.
• Integration with Metamask (or WalletConenct compatible wallets) may be cumbersome and misleading: user will be faced with his ETH balance, not $NEAR balance. Wallets do support entering a custom symbol for alternative network token but it’s still not propagated everywhere (see screenshots of MetaMask for MATIC in comments). One solution is to never require user to switch networks by always using meta-calls and to show their NEAR assets inside a Dapp. Note, that information about how much user will be paying in fees might be confusing to user who are not familiar with EIP-712 and also would require to be careful about which token user wants to pay fees in.
• Specifically, when switching network in MetaMask, there will not be a good way to compare the transaction fees as it will show fee in $NEAR (see screenshot below for Matic).
• User bridging their $ETH tokens to NEAR, would not see any balance in their wallet, as that balance by default will be in $NEAR.

Proposal: Extend EVM base token to be custom token

The proposal to switch EVM to use a custom token instead of $NEAR.

The change will require next things:

• When EVM contract is instantiated, it takes as parameter account_id of the token to use.
• Internal balance is considered this token instead of NEAR by default. Which means that operations like withdraw and deposit inside EVM are operating on token standard (e.g. calling transfer on NEP-21)
• when calling call method for EVM, can not attach deposit anymore. Instead must use token standard to move assets first. Note, that this is true for majority of use cases anyway, as people will want to move DAI, wNEAR, etc into EVM and back.
• value used everywhere inside EVM becomes this token (no code change)

Complications of this approach:

• Requires hard coding the token standard on the protocol level
• Now other contracts when using call method into EVM can not easily attach $NEAR. Instead they need to wrap it into wNEAR and pass it into EVM first.

ETH as a base currency for default EVM Runtime

Specifically, to address issues above, the default EVM runtime can use ETH as it’s base token.

By using Rainbow Bridge ETH can be transferred to NEAR native runtime (ETH → wETH → nETH), which then, using the deposit method of EVM runner can be transferred into NEAR EVM accounts.

Considerations:

• Default EVM is fully tied to $ETH and Raindbow Bridge operations.
• Relayers for raw_calls must do calculations between $ETH <> $NEAR. This is similar to calculations they must do for meta_call where any ERC-20 token can be used for payment. Generally, this is not a problem as it’s already needed and done off chain and based on individual preferences of relayers.

The end-user and developer workflow within this workflow would be pretty simple: transfer your ETH over the rainbow bridge to another execution environment (presumably, just multiple clicks in the bridge FE, where you can login with Metamask) and once the transfer is done, change the endpoint (either in Metamask or Truffle/Hardhat/…).

Known issues of both approaches

• We need to establish the account upgrade process from NEAR EVM-only account to full NEAR account.
• Rainbow bridge must allow for transfers into EVM with fees collected on Ethereum side, so the user won’t need to hold any $NEAR.

We encouraging you to share your comments on what approach you think will benefit the ecosystem the most and what issues you immediately see in both of them.

[evgenykuzyakov]

My main concern is the increased complexity of introducing a separate native currency that is not a stable coin either.

• Accounting for gas between native and EVM calls becomes an increasingly complex. It maybe easier to just launch a separate chain with only EVM accounts and then bridge it to native NEAR than to implement 2 competing currencies. Having AMM and NEAR/nETH pricing requires it to be synchronous and be tracked by all shards.
• This change increases the overall development complexity without giving anything useful. If NEAR to nETH price can be established (needed for gas accounting), then it shouldn’t be a problem to convert Eth to NEAR.
• wNEAR can be acquired on Ethereum side and later used for bridged assets. This is much simpler design comparing to having extra currency on NEAR EVM side.

[vgrichina]

Why not run it as a completely separate chain in that case? Just run separate EVM chain with NEAR consensus and call it ETH 2.0. Bridge it to NEAR main chain.

[illia]

The post should be corrected as base token inside EVM is not required to pay fees in general case. NEAR is always paid as a transaction fee to the network.

Base token is only required to pay fees back to relayer in the case of relaying raw ETH transactions and for transacting between accounts and contracts (e.g. paying ETH when calling an account). In case of meta_call, any ERC-20 can be used to pay back relayer.

I’ve been asking ETH devs, and it sounds like people prefer to use WETH though in their contracts though and use msg.value mostly just to wrap ETH into WETH.

This is obviously not true for Uniswap like contract, where ETH (base token) is used for main operations.

Main Con indeed is in increased complexity that EVM now depends on the NEAR’s token standard instead of just native NEAR API. Though, this opens up base token to be a EVM shard creator: wETH, wNEAR, nDAI or whatever.

As as side note, we have before discussed to have common API for tokens and NEAR, but never got to that because of design differences. It’s still an interesting question as we will get into similar situation where devs want to handle all tokens but NEAR would need to be special cased (I have this right now already with SputnikDAO).

[illia]

Security. A separate chain would not have security.

Hence believe in sharding vs app chains. I’ll link you to the draft of the blog post describing why launching separate chains is way more complicated and required large investment of time and money than launching applications on a sharded blockchain.

[illia]

I just wanted to clarify few things in the original post:

EVM Runtime accounts (which are literally secp256k1 public keys)

Addresses are 20 bytes. for NEAR accounts it’s hash(account_id)[12…] or hash(secp256k1 public key)[12…] for those which are meta transactions.

all transaction execution fees are eventually recalculated into $NEAR

To be clear, the change of base token will not change the fees at all. Fees are paid either by user with NEAR account (e.g. have NEAR or use relayer there) or by relayer. In case of relayers, user pays whatever token they want in most cases.

A user need to own $NEAR.

This decision doesn’t affect if user needs or doesn’t need to own $NEAR. They may or may not need $NEAR depending how their account is configured and if it’s inside EVM or not.

This need can be removed with protocol level

“This need is removed with”

however implementation of relayer incentive brings additional complications

Relayer incentives are already there - they get paid back in whatever token they want to accept whatever amount of money they are willing to relay for

Integration with Metamask (or WalletConenct compatible wallets)

Most wallets support alternative symbol there (here is an example setting up MM for Matic). Most CLI tools are still hard coded it though.

However, the indication of EIP-712 messages is just bizarre.

I would frame this, that EIP-712 message will show address of the token you are paying with and amount in a raw format. It’s not that bizarre but indeed less convenient than regular tx showing fee in base token.
Otherwise, I think EIP-712 display is actually better than regular transactions, because it would actually show method called and arguments properly.

There won’t be a straightforward indication for the user that he’s spending less on transaction fees (comparing to Ethereum), since the gas price is a recalculation into the EVM Runtime native token, which is different in NEAR and Ethereum.

This is only in the case of raw ethereum call (when people changed the MM), but yes in this case it will just show you are paying 0.0001 N for a tx, without showing $ equivalent.

[vlad]

I don’t find security argument very compelling. POS with ETH native token likely can be more secure because of ETH being super expensive already.

As for complexity – I agree 100% about apps, but if you think about EVM as platform – there are plenty of extra complexities launching it within NEAR as well.

[vlad]

Integration with Metamask (or WalletConenct compatible wallets) may be cumbersome and misleading: user will be faced with his ETH balance, not $NEAR balance.

How do xDAI, POA, TRON solve this issue?

[alex.shevchenko]

The most important feature that we bring with EVM shard, I believe is an ability to extend EVM precompiles list, so EVM Runtime will be integrated into NEAR native runtime. As an example, the async call outside of the EVM to NEAR native contracts can be implemented. This is not achievable easily with the setup of two chains.

[mattlockyer]

I’m with EVM shard approach mainly due to the interop with NEAR.

Eventual goal should be to have projects upgrade protocol contracts to proxy calls out to NEAR Rust contracts for better performance and gas fees, but they also don’t have to.

[mattlockyer]

RE: make EVM run on ETH, wETH, nETH etc…

This pushes complexity downstream to EVM on NEAR protocol level, where now we have NF and AMMs etc… re-balancing and making sure economics don’t get skewed.

Requires equal (likely less) complexity to simply build good relayer tools and “hide” NEAR from user by taking a cut of bridged ETH to pay for EVM fees in NEAR.

We’re so much cheaper than Ethereum there’s tons of room to lock up $5 of ETH as NEAR and do 100s of txs on NEAR EVM before that’s depleted.

We have access keys, we’re building relayers, why not open these tools up and let the community build markets, AMMs on NEAR and all sorts of stuff around a revenue source -> the cut of ETH users park with relayer after they cross the bridge?

[snjax]

Current version of Metamask support other EVM chains, like Athereum or Binance Smart Chain. So, it is not a problem to use $NEAR as native token for EVM. Also bulding chains with EVM support currently is a global trend, so support of different chains with different native token will be improved soon.

I suppose, $NEAR is best choice for NEAR EVM as native coin.

[illia]

Just to clarify, this is the current support level for other chains from MetaMask for example:

Even though there is a token “MATIC” used there as part of configuration for the Network, it doesn’t have information about the price of the token and ETH icon and label are still used in many places.

The price might not work on anything except MainNet though anyway. Need to double check.

[illia]

@mattlockyer

This pushes complexity downstream to EVM on NEAR protocol level, where now we have NF and AMMs etc… re-balancing and making sure economics don’t get skewed.

There is some misleading statements above.
In this proposal there is no need for anyone to do any balancing, AMMing or anything.

The two differences from the current state:

• Internal balance is considered some token instead of NEAR by default. Which means that operations like withdraw and deposit inside EVM are operating on token standard (e.g. calling transfer on NEP-21)
• when calling call method for EVM, can not attach deposit anymore. Instead must use token standard to move assets first. Note, that this is true for majority of use cases anyway, as people will want to move DAI, wNEAR, etc into EVM and back.

Then specific instantiation of EVM that depends on wETH token will have dependency on the bridge. Alternatively, one can also instantiate EVM that uses wNEAR, DAI or anything else as base token.

@mattlockyer

Requires equal (likely less) complexity to simply build good relayer tools and “hide” NEAR from user by taking a cut of bridged ETH to pay for EVM fees in NEAR.

I’m fully onboard with relayers via base NEAR accounts, but to make this work well we need to address two major issues:

• Current price for storage is too high, and given trustless relaying would require a contract per user, we need to reduce it at least by 10 if not 100x. At least for repeating contracts (there is NEP for that) E.g what’s described here Using NEAR with Ethereum wallets is not really practical right now without changes.
• EVM vs WASM is not really the differentiation. The differentiation is sync vs async environments. So it would be better to have unified version of sync envs (for example all contracts under *.name live on the same shard). Then contracts can be WASM or EVM independently and co-exist freely.

[evgenykuzyakov]

I think another reason to support NEAR natively on EVM is to be able to issue transactions from EVM accounts. A new type of transaction can go to evm account and be verified same way we verify NEAR transactions before converting them to Receipts. If we can to support such functionality, then we’ll need to be able to convert native evm account balance to gas, which is currently accounted in NEAR token.

[evgenykuzyakov]

If we go with not NEAR token, then we don’t need to keep balances on the internal EVM accounts. We can just have a EVM contract that we use for accounting, e.g. nETH. It will take care of deposit/withdraw functionality and we can remove it from the high-level EVM method names.

[miohtama]

I’ve been asking ETH devs, and it sounds like people prefer to use WETH though in their contracts though and use msg.value mostly just to wrap ETH into WETH.

This is true, but usability wise this is not great. Developers prefer to use WETH, because it makes their contracts simple - there is no special case for native currency, but everything can be coded as ERC-20 transfers (forgot about payable, etc.). However, the users prefer very much ETH, as WETH wrapping process still is not that simple. For example, wallets and user interfaces do not offer this option by default.

To make the matter more complicated, there are several versions of WETH. WETH10, being the latest, is very superior feature wise: transaction fess, relay support and such:

GitHub - WETH10/WETH10: revamped contract

It is not widespread yet, though.

[eatmore]

I am against using ETH as a native token. Originally, the rationale for EVM support was to make it possible for Ethereum DApps to migrate to NEAR without them having to rewrite, retest and reaudit their code. However, if they keep using ETH as a native token (and thus not touching NEAR token at all), they would be more like merely offloading their smart contract computation to NEAR blockchain (where it is cheaper). Migration should involve more than that, in addition to moving the computation it should involve switching to the new blockchain’s native token. Otherwise, it is like moving to another country while still using the currency of the country you came from.

Also, the way we are planning to implement it (with EVM runtime calling NEP-21 functions), we are making the exact implementation details of the JSON implementation that we use part of our consensus protocol, and it is likely not designed for that (for example, it may possibly change its behavior between versions).

[illia]

Currently upgrading the protocol is easier than upgrading smart contracts on NEAR (due to Sending and storing a contract in storage is over the contract gas limit · Issue #137 · near/NEPs · GitHub).

To be clear, our token standard will be part of NEAR Protocol, similar how ERC-20 is part of Etheruem now. You can’t really just change ERC-20 right now, because there are 10,000s of contracts and 1000s of tools that rely on it.

The current proposal to “update” token standard later that @evgenykuzyakov suggested was a wrapper contract, which can be done for EVM that uses ETH as well.

Diving into more technical point, I think making evm contract - ETH NEP-21 token itself will provide even better experience. This only requires to define rules of minting and burning it (e.g. bridging) vs dependency on another contract and requirement of additional cross contract calls to deposit / withdraw. This way the internal EVM account balances will be the ETH balances that other contracts and tools in NEAR will use.

[Arto]

@eatmore

Originally, the rationale for EVM support was to make it possible for Ethereum DApps to migrate to NEAR without them having to rewrite, retest and reaudit their code.

Such a migration becomes a dubious proposition in the first place if we don’t adopt ETH as the base token.

For example, @illia and I reviewed the Uniswap V2 code base as a representative sample, and found that the assumption that ETH is the chain’s base token is deeply hardcoded in dozens of files all over the project, spread out over multiple GitHub repositories.

If we don’t adopt ETH as a base token, then porting Uniswap to the NEAR EVM would involve forking all of the relevant repositories (starting with uniswap-sdk and uniswap-interface) and maintaining (indefinitely) a custom branch where we’ve done a search-and-replace of all hardcoded instances of "ETH", carefully reviewed and changed all hardcoded logic dealing with ETH/WETH conversions, and replaced all use of any ETH/USD or ETH/XXX price oracles.

Now repeat that same process for every single DeFi dapp to be deployed (or ported, in this scheme of things) to the NEAR EVM.

If we adopt ETH as a base token, Uniswap (and other dapps) can be deployed as-is after just changing the RPC endpoint URL.