EVM release master checklist

[ilblackdragon]

This is a running list of required pieces to release full blown support for NEAR EVM. The EVM delivery is split into phases. Tasks that are able to be developed by community are marked with [Bounty].

Phase 1: Initial release: (?) the week of Nov 2nd

The goal of the release is to ship EVM as soon as possible to a controlled network to start testing it.

• [x] Near core supports feature flags (nightly_protocol) - https://github.com/near/nearcore/pull/3503
• [x] Gas usage finalised - https://github.com/nearprotocol/nearcore/pull/3299
• [x] Merged the bulk of EVM code - https://github.com/nearprotocol/nearcore/pull/3257
• [x] EVM upgradability - https://github.com/near/nearcore/issues/3544
• [x] Bring in EVM gas cost prices - https://github.com/near/nearcore/issues/3552
• [ ] Setup nightly deployment CI cc @chefsale @bowenwang1996

Acceptance criteria

• [ ] Betanet is up with EVM feature enabled
• [ ] CI is doing automatic hardforks of Betanet and running tests
• [ ] There's a short README how to deploy Solidity code to Betanet

Phase 2: Full scope Betanet release: (?) before EoY

The goal of Betanet release is to ship a public Beta of NEAR EVM. By the end of this phase we expect to receive a mostly working EVM without additional features development, only bug fixes and usability improvements.

• [x] Add nightly tests: running Balancers truffle tests end to end - https://github.com/nearprotocol/nearcore/issues/3450
• [x] EVM View and Method calls available through near-cli - https://github.com/near/near-cli/pull/517
• [ ] near-api-js supports secp256k1 keys in KeyPair - https://github.com/near/near-api-js/issues/440
• [x] near-web3-provider supports EVM https://github.com/near/near-web3-provider/pull/58
• [ ] Meta transaction relayer basic implementation. Should include basic flood prevention. https://github.com/near/nearcore/issues/3338
• [ ] Check how WASM contracts can call EVM contracts https://github.com/near/nearcore/issues/3697 @evgenykuzyakov
• [ ] [Bounty] Implement intellectual Ethereum -> NEAR EVM transaction feed with expected results https://github.com/near/nearcore/issues/3698
• [x] [Bounty] Upgrade EVM to the recent version - https://github.com/near/nearcore/issues/3506
• [ ] Check all additional filed EVM-related features and either move to the next release or include in this stage - https://github.com/near/nearcore/issues?q=is%3Aissue+is%3Aopen+EVM + other repos
• [ ] Check all EVM-related bugs and either move to the next release or include in this stage or in the next stage - https://github.com/near/nearcore/issues?q=is%3Aissue+is%3Aopen+EVM + other repos

Acceptance criteria

• [ ] The issues corresponding to this phase are all resolved
• [ ] Betanet implementation is not having critical issues for 2 weeks
• [ ] Transaction feed is working for 2 weeks with expected results
• [ ] If the above is met: set the bug bounty (with medium rewards)

Phase 3: Testnet release

• [ ] Rethink this: Everything needed for the Bridge operations is in place (nERC20 and NEP-21 contracts are linked & tokens can be transferred from WASM to EVM environments and back)
• [ ] All relevant documentation sections are updated
• [ ] Finalised specification for EVM precompile - https://github.com/nearprotocol/NEPs/pull/106
• [ ] [Bounty] Relayer for meta-transactions can charge users with ERC20 or other tokens @mikedotexe
• [ ] [Bounty] Explorer: EVM contracts support
• [ ] [Bounty] Explorer: Meta-transaction support
• [ ] [Bounty] Explorer: Search for EVM addresses support (contracts and accounts)

Acceptance criteria

• [ ] The issues corresponding to this phase are all resolved
• [ ] Betanet implementation is not having critical issues for 4 weeks
• [ ] Transaction feed is working for 4 weeks with expected results
• [ ] Balancer UI works with Metamask
• [ ] If the above is met: release EVM to Testnet and set the bug bounty(with high rewards)

Phase 4: Mainnet release

Acceptance criteria

• [ ] The Testnet implementation is not having critical issues for 4 weeks
• [ ] If the above is met: release EVM to Mainnet

Icebox

• [ ] Promise calls outside EVM - https://github.com/near/nearcore/issues/3339 & https://github.com/near/nearcore/issues/3449

Check with Illia:

This section contains issues mentioned by Illia. One need either to remove them or add to one of the above phases.

• [X] Added chain-id for MainNet and TestNet - https://github.com/ethereum-lists/chains/pull/110
• [ ] Create secp256k1 keys to operate for Ethereum in testing (near-web3-provider)
• [ ] Support code to work with meta transaction relayer (form a message to sign from ABI, etc), have a mode to support external wallet. (do we want this in a separate lib?, near-web3-provider)
• [ ] Default relayer running live on relayer.{network}.near.org? Should we move it to some other domain? (near-meta-relayer)

[alexauroradev]

I would vote for removing from the scope the bridging pieces. ERC20<->nERC20<->NEP-21 switches can be complicated: ERC20 is a standard, while an individual token contract can implement additional functionality that a developer would probably want to preserve in the NEAR EVM. And I believe the reasoning for the developer to migrate to NEAR EVM is not only to allow for low-fee transfers of tokens, but also to use all the other functionality of the token contract at low fees. In this case, how to match this with NEP-21 token? We don't want to force a developer to develop an additional NEP-21 compatible NEAR contract, do we? In case somebody wants to migrate their contract from Ethereum to NEAR, there's always an ability to freeze the contract, document its state, reproduce it in NEAR EVM with the same state, and launch the service. The bridging functionality will simplify this process, but there's no need to do it right now.

[ilblackdragon]

It's critical to support common ERC-20s, without them most of the applications that want to use NEAR EVM won't be able to even start.

E.g. they will need nETH, nDAI - which are bridged tokens, not a copy of DAI on NEAR (which is a separate thing, and probably should have a different name if someone forks Maker on NEAR)

Given we have applications that also will use these tokens in the native NEAR environment, tokens that exist in NEAR EVM should be exchangeable with native ones. If we don't have nERC-20 -- NEP-21 connection, the only way to exchange them will be to withdraw to Ethereum and then deposit back to NEAR - which seems really weird.

[maxzaver]

@ilblackdragon @djsatok We need to clarify exactly how we want tokens to be bridged from ETH to NEAR EVM. There seems to be several approaches discussed:

• Bridge ETH ERC20 (e.g. DAI) with NEAR NEP21, then bridge NEP21 with ERC20 running inside NEAR EVM ERC20 (nDAI). This is seems to be an approach discussed in this issue. It is however not clear how NEP21 is going to be bridged with NEAR EVM ERC20, which seems to require a separate effort. If we want to go this path we need to start with the user stories and then transition into a design. Since this can be a very complex project, I suggest we extract it into a separate effort;
• Bridge ETH ERC20 (e.g. DAI) directly with NEAR EVM ERC20 (nDAI). This would require running EthOnNearClient and EthOnNearProver in Solidity inside NEAR EVM which might not be feasible, due to computation cost.

[alexauroradev]

Let's fix the naming first: nERC20, nDAI, ... -- these are the references to a specific Solidity contracts in NEAR EVM, which are similar to the original ones from the Ethereum. The difference may be in the initial emission procedure, plus, obviously, the state of the contract will be different. NEP-21 DAI, ... -- these are the bridged DAI tokens from Ether to NEAR native environment. These tokens have only NEP-21 standard implemented, nothing more than that (if using the general ERC20 <-> NEP-21 connector in the bridge).

@nearmax, here are some considerations:

• It's worth having both nERC20 and NEP-21, since this widens the spectrum of the applications
• It's worth having the means to convert nERC20 <-> NEP-21, inside NEAR. This removes the liquidity split between two options, and decreases the switching time (direct transfer is seconds, rather than 4 hours + 6 minutes two transfers over the NEAR <-> Ethereum; Ethereum <-> NEAR EVM)
• It may be too complicated to introduce the changes into EVM once it's in production (a lot of people already using the current version with lots of tokens locked in the bridge), so it's better to define the nERC20 <-> NEP-21 bridging right now.

So, my point of view on the issue (the mix of the current bridge and your suggested second option):

• A bridge should provide the means to do both types of operations: ERC20 <-> nERC20 and ERC20 <-> NEP-21.
• nERC20 and NEP-21 connector contracts should know about each other, which results in the following workflow:
  • A user sends his X nERC20 to corresponding NEP-21 contract
  • NEP-21 calls nERC20 contract to burn X tokens
  • NEP-21 contract mints X tokens and transfers it back to the user
  • Same works in the opposite direction
• Once nearcore #3449 implemented, NEAR EVM contracts can call NEAR Wasm contracts, so there would be no need to run EthOnNearClient and EthOnNearProover-s inside NEAR EVM.

[alexauroradev]

@mikedotexe, @ilblackdragon, additional observation to put in the checklist:

We should check that all the methods from Ethereum JSON-RPC are covered in near-web3-provider (at least they return unsupported error) and the docs for the later are updated.

I'm not sure that this is true right now: Let's take a look at eth_getPastLogs.

The latest spec for Ethereum JSON-RPC is here and it's not containing eth_getPastLogs. The web3.js docs contains getPastLogs with the implementation here, which is calling eth_getLogs.

I'm not sure what protocol we should implement in near-web3-provider. Either we create additional web3 library with lots of functionality (which I believe the case now with near-web3-provider, then why it's not called near-web3 ) or we make use of the web3.js library as-is and just implement NEAR JSON-RPC, which is required for the Ethereum tooling that is not using web3,js.

[maxzaver]

nERC20 and NEP-21 connector contracts should know about each other

I see, you are suggesting to have a hard link between nERC20 and NEP-21 contracts. This might actually be the only way to do it. This would require modifications to the factory in https://github.com/near/rainbow-token-connector

[mikedotexe]

Just to make sure I'm following, the "hard link" mentioned above is a trusted, smart contract we have written that lives on the NEAR EVM and connects to the "outside world" of NEAR NEP-21, yes? Basically a locker, but with burn. Wanting to make sure we're not talking about having projects modify their ERC-20 to implement this themselves.