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.
2 Likes
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.
3 Likes
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?
1 Like
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.
2 Likes
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.
4 Likes
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
withdrawanddepositinside EVM are operating on token standard (e.g. callingtransferon NEP-21) - 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.
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.
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.
2 Likes
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.
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.
3 Likes
I’ve been asking ETH devs, and it sounds like people prefer to use WETH though in their contracts though and use
msg.valuemostly 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:
It is not widespread yet, though.
3 Likes
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).
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.
3 Likes
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.
3 Likes
I hear both sides of this argument but I think we could rely on very interesting token engineering magic to align $NEAR & $ETH.
For example, the simplest thing could be buying $NEAR with $ETH (gas fees) on AMMs to then burn or use for ecosystem funding.
This simple mechanism aligns ETH && NEAR in a very simple way. Ethereum devs/folks buy/use $ETH and that indirectly adds value to $NEAR …
1 Like
On yesterday’s weekly EVM Working Group meeting, we outlined our Q1/2021 roadmap and discussed the rationale for ETH as the NEAR EVM’s base token:
5 Likes
@Arto, @alex.shevchenko, @illia. @eatmore told me that EVM is interacting natively with NEP21 wETH, which means EVM interacts with contact through JSON. JSON is not a well-defined standard and dependent on JSON parser implementation, and maybe even on the specific version of serde that we are importing in nearcore for JSON parsing. Unfortunately, it means that a not well-defined standard is leaking into our protocol, since EVM being a native VM is a part of the protocol. It seems like we are risking of having a broken consensus if something in serde changes the way it parses JSON. I suggest we avoid depending on JSON in the protocol entirely and communiate with wETH using Borsh.
3 Likes
Sounds good to me, though I am not sure how easy it is to switch to borsh on the contract side
In order to bridge ETH to NEAR, we need to create a separate connector (not the existing fungible token connector), which was discussed here.
The general idea is that EVM Precompile contract will implement a current fungible token interface (NEP-21 less likely; NEP-141 more likely), with a token connector being a single contract to be able to mint and burn nETH tokens. This specific token connector literally implements a direct transfer of ETH to NEAR EVM for Ethereum users, and for NEAR users NEAR EVM destination is keccak(accountID). This approach can be used onwards for any NEAR users to interact with NEAR EVM.
I’m not sure that this fully answers your question, but I’m pretty sure that the scheme above can be implemented using strict serialisation protocols.
1 Like
The Fungible Token standard is what will define the protocol.
I think we have already decided that JSON will be used as an interface, so going forward consider Fungible Token standard part of the NEAR Protocol (this is the reason why it is in nomicon). Even though it’s potential possibility to later change the interface, the reality when we are going to have tons of various assets and value bridged - it will become as hard to update it as any other protocol change (e.g. require sweeping upgrades across the stack).
Hence using this standard to define ETH token inside EVM seems reasonable.
To my understanding there are two proposed designs:
- EVM implements NEP-21/NEP-141 interface;
- ETHMinter is extracted as a Wasm contract and EVM operates directly with the state of ETHMinter. EVM itself does not implement NEP-21/NEP-141 interface. ETHMinter implements NEP-21/NEP-141 interface.
I don’t think (1) is feasible. We cannot have JSON interface as part of the EVM because JSON is not a well defined standard. If we make it part of EVM it we will have a not well-defined protocol. This is not the same as having some Wasm contract have JSON interface, because in case of a contract specific rules of parsing JSON are compiled into Wasm and all NEAR nodes independently of how they were implemented agree on how it should be executed.
Image the following scenario.
- We are running a network, and someone does a contract call to EVM that implements NEP-21/NEP-141 using JSON interface. However, they make a typo in arguments, and add extra comma, e.g.
{ 'new_owner_id': 'alice.near', 'amount': '100', }; - Suppose we have three different versions of nodes running in the network: Rust implementation that uses serde_json X, slightly older Rust implementation that uses serde_json X-1, Go implementation;
- All three versions of the node process the arguments differently and disagree on what is the outcome. This happens because JSON parsers implement different ways of parsing JSON, and some of them even have extra logic (sometimes a lot of it) of handling slightly invalid input, like missing closing brackets. Note, if these arguments were calling Wasm contract then nodes wouldn’t disagree because JSON parser would’ve been compiled into Wasm and nodes do not disagree on how to execute Wasm.
The security consequences of such disagreement:
- Right now, since we don’t have slashing, the network would split. And the split will not be easy to recover. We are not going to ask maintainers of the Go NEAR node to quickly rewrite their JSON parsing library to perfectly mimic serde_json, and even if they do it will take days;
- If we introduce challenges later, the validators will be slashed.
The long-term maintenance consequence is that we would have to make the exact implementation of serde_json of version X part of our protocol spec, make all alternative implementations perfectly mimic this JSON parsing logic, which is not going to be easy. serde_json has a lot of logic that attempts to make it robust and forgiving, which might also be changing from version to version.
Even if we don’t have alternative implementation it is maintenance nightmare.
serde is 32k LOC, serde_json is 15k LOC. Imagine trying to keep an eye on every single change that tweaks its robustness in minor ways. Imagine someone bumps the minor version of serde_json and accidentally alters the robustness logic. Also, suppose that at some point we will want to bump serde_json version, it will be a protocol change, and it we would have to import both version of serde_json into NEAR node code to make sure we can validate old blocks. It took @birchmd weeks to introduce versioning into some chain structures, because we did not do it before Mainnet launch, and now we have to maintain the old unversioned legacy code, even though the difference is just a single byte. With serde_json in our protocol its maintenance will be always consuming our time and we would be spending energy on creating sophisticated ways to work it around.
Besides, it will be almost certain that we won’t ever have a full exhaustive protocol specification. CC @alexatnear , @Bowen
1 Like