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.
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
There’re methods that allow depositing and withdrawing $NEAR to EVM Runtime accounts.
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
ETHcosts 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
$NEARbalance. 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_idof the token to use.
- Internal balance is considered this token instead of NEAR by default. Which means that operations like
depositinside EVM are operating on token standard (e.g. calling
- when calling
callmethod 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.
valueused 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
callmethod 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.
- Default EVM is fully tied to $ETH and Raindbow Bridge operations.
raw_calls must do calculations between $ETH <> $NEAR. This is similar to calculations they must do for
meta_callwhere 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.