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.

Screen Shot 2021-01-08 at 8.01.15 AM680×1128 45.7 KB

Screen Shot 2021-01-08 at 8.28.32 AM690×1032 39.8 KB

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.

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.

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.

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).

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.

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.

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.

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?

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.

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.

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?

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.

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

Screen Shot 2021-01-08 at 8.01.21 AM694×1184 50.1 KB

Screen Shot 2021-01-08 at 8.01.15 AM680×1128 45.7 KB

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.

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.

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.

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

revamped contract

It is not widespread yet, though.

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.

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.

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 …

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:

EVM Q1/2021

EVM Q1/2021 near.org https://www.youtube.com/watch?v=jo96l6Vh5aU https://github.com/near/nearcore/discussions/3811

Weekly update 2021-01-15 · near/nearcore · Discussion #3811

The recording is available at: https://www.youtube.com/watch?v=jo96l6Vh5aU Agenda Current goal Q4 OKR review Q1 roadmap Q1 OKR planning Team updates Discussion Current goal We are planning Q1 OKRs,...

@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.

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.

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:

1. EVM implements NEP-21/NEP-141 interface;
2. 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

I’m not deep into the Runtime. Who the smart contract calls work on the API level? How the transaction is serialized over the wire? Are you using JSON API for communicating with a Node? I think JSON API is not a problem - because this is not a part of the blockchain. It’s just a communication with a dapp / wallet. Worst case, a node will fail to decode a transaction and will not include it in the block. So, more importantly, the transaction serialization in the block must be well defined.

As for the smart-contract, the current approach is:

1. serialize numbers as strings
2. serialize bytes as base64 strings (or whatever the smart contract will expect)
3. serialize complex object using JSON keeping the 2 above conditions.

The FT smart contract (NEP-141) doesn’t take complex objects as an argument.

That’s very valid point @nearmax, thanks for bringing this up.

Though, we don’t need super complex arguments parser that serde offers (for example here is 300 line JSON parser, which we should be using for our arg parsing anyway), so we can do define a specific NEP-141 argument parser in this case. Again, Fungible Token is the protocol standard and pretty much will define how all the tooling should work. Having inconsistent parsers across contracts will be not as terrible as network split but from user experience as bad.

I’m not sure what you mean “EVM operates directly with the state of ETHMinter”? Does this mean that we guarantee these contracts are always on the same shard? I don’t think that at this point we have such facilities or were planning to build them.

Alternative design that I would love to think through and measure performance of, is move all the EVM glue code back into “contract” land and just keep execute_evm(bytecode) env function. This would allow to push almost everything into “developer” land and have various versions of contract upgradability.

One of the main issues with this approach is how to handle storage staking. Relayers will need to charge user back for the storage they are paying which currently is substantially more expensive than on ETH and may make it hard to frontend to show it.

Let me and @Arto to think through this more.

@illia Thank you for slowing down and considering alternatives.

illia:

Alternative design that I would love to think through and measure performance of, is move all the EVM glue code back into “contract” land and just keep execute_evm(bytecode) env function. This would allow to push almost everything into “developer” land and have various versions of contract upgradability.

That would be the best, I am strongly supporting this option.

We can even make evm account special in a way that it has some special EVM-related host functions exposed, and everything else about it behaves just like a regular account, including ability to deploy any Wasm code. Then we don’t need separate evm and EthMinter accounts.

I’m not sure what you mean “EVM operates directly with the state of ETHMinter”? Does this mean that we guarantee these contracts are always on the same shard? I don’t think that at this point we have such facilities or were planning to build them.

Yes, if we can special-case our runtime for EVM, then we can also special case some subtree in MPT as non-dividable. We have to declare the entire subtree that corresponds to a single account as non-dividable anyway, so it is not really a kludge, just a special-case similarly to what we do with implicit accounts.

Though, we don’t need super complex arguments parser that serde offers (for example here is 300 line JSON parser, which we should be using for our arg parsing anyway), so we can do define a specific NEP-141 argument parser in this case.

In the past I tried to simplify serde_json to reduce its size, and it’s really not that easy. Even tiny_json is 16k LOC. Writing valid JSON parser is not that easy.

Again, Fungible Token is the protocol standard and pretty much will define how all the tooling should work.

I would disagree, Fungible Token is a standard, but not a protocol. When a standard becomes more socially accepted or even vouched/promoted/recommended/official by NEAR collective it still does not become a protocol. Standards (token standards, RPC standards, even network message standards) live in user-land, protocol lives in system-land.

Also, I would like to bring to the attention that this is an instance of us trying to move too fast. Even if we somehow prevent future issues with network split or slashing, it will be a maintenance hurdle. We are already at the state where some people spend a good portion of their time working around things that exist because we moved too fast at some point. One of the reasons why we’ve been able to continue building on top of the runtime code without significant slowdown is because we keep the runtime code clean Let’s keep it this way so that we can continue moving fast.

robert:

I think JSON API is not a problem - because this is not a part of the blockchain

@robert that’s the problem. The proposal in question suggests to make specific JSON parser implementation as part of the blockchain protocol.

nearmax:

In the past I tried to simplify serde_json to reduce its size, and it’s really not that easy. Even tiny_json is 16k LOC. Writing valid JSON parser is not that easy.

I linked to 300 LOC parser. Also in AS we have 300 LOC parser as well.

I would argue that it make sense to define specific set of rules for JSON that works inside smart contracts to avoid potential problems down the line, when UIs will work for some contracts and fail with completely unreadable JSON errors for others.

nearmax:

I would disagree, Fungible Token is a standard, but not a protocol.

If you want to argue about semantics of wording, here is definition for protocol that totally matches with Fungible Token or ERC-20:

A communication protocol is a system of rules that allow two or more entities of a communications system to transmit information via any kind of variation of a physical quantity.

To be clear, ERC-20 is even more important “protocol” in Ethereum, than, for example, definition of network messages. Changing network messages is doable reasonably easily. Changing ERC-20 is impossible and you can only build super-seeding version (like build NEAR and super-seeding with it’s token protocol) but the old ERC-20 will continue exist for decades to come.

This is the same with RPC - there are 1000s of applications now that are using this specific RPC end points in Ethereum. Changing them is possible but will require long deprecation and coordination process.

IMO that dividing “user-land” and “system-land” is the easiest way to build something that no one wants to use The fact is that those things that users actually interact with are more important than things that are under the hood.

I accidentally deleted @Bowen 's post where he mentions that he also thinks having JSON in the protocol is questionable. Sorry @Bowen

JSON is a standard: Information on RFC 8259 » RFC Editor

While not the focus of conversation here, it would be incredibly useful to support JSON for other reasons beyond ERC token support.

JSON is the basis of Verifiable Credentials and confidential storage which are emerging data standards. The ability to leverage this off-chain JSON data for inputs into smart contracts will be incredibly powerful.

I would like to make a short summary here:

1. NEAR EVM Runtime would use bridged ETH (nETH) as a base token: this is a made decision
2. Implementation details are unclear at this point: there’re concerns regarding JSON parsing on the protocol level, necessity of protocol upgrades for the all EVM upgrades and performance.
3. To decide on implementation additional research and discussions have started; see here