Implement Eth JSON-RPC

[lrettig]

There are two fundamental issues with the current node API: 1. it's not complete and not terribly well designed (see summary here: #269 (comment)), and 2. it's not compliant with any existing blockchain API spec, which makes integration work quite difficult. Note that we have "competing" proposals on the table to rewrite/improve the existing API (#270), and to build an entirely new API (#269); we also have a related proposal to support even broader EVM compatibility (#189).

We can kill two birds with one stone by adding support for an existing, standard API, and the most obvious choice is Eth-flavored JSON-RPC. Skimming the JSON-RPC spec, I don't see any major issues or major incompatibilities, though this will require some additional work. If we do implement it, it's likely we'll need to drop certain endpoints and modify the behavior of others, but there's precedent for doing this and other projects have done this quite successfully.

Benefits:

• very quick to deploy. Can rely on existing code and implementations; no need to design an API.
• "out of the box" support for popular wallets including Metamask (using a snap) and Taho
• listing on chainlist
• "out of the box" support for open source explorers such as blockscout
• "out of the box" support for eth tooling such as truffle, hardhat, and foundry (probably useful for testing today, and much more useful soon when we add VM support)
• "out of the box" support for app tooling such as web3.js and ethers.js
• "out of the box" support for monitoring software (nodemonitor, netstats, etc.)
• much easier integration of existing cross-chain bridge infrastructure; would go a long way towards promoting cross-chain interop, assuring Spacemesh isn't "its own lonely island" relative to the Eth ecosystem and broader ecosystems (a lot of existing cross-chain tooling uses the same spec)
• easier light client support
• easier exchange integration
• not mutually exclusive with other approaches

Downsides:

• likely won't work without at least some modifications: e.g., eth doesn't have templates or account abstraction at L1, and our nonce design is a little different. Unclear how big this impact will be.
• could possibly restrict the Spacemesh design space in the future, if everyone gets used to using this API at the expense of others.

Lots of other chains that aren't natively EVM compatible have done this, so we're in good company. Here are examples:

• Moonbeam (Polkadot)
• C-Chain (Avalanche)
• Aurora (NEAR)
• Neon (Solana)

See also: #223

[dshulyak]

how wallets will work if txs are not compatible? beside objects that can be coerced into eth, there are many that can't. providing only eth api is not sufficient

with l1 rollup design such API does make sense, but there is no reason to implement it before doing vm work.

[dshulyak]

also before starting this work, we need to research that we can do compliant api. we should take reference spec for chosen API (i was looking at startknet rpc) and add notes what every method means and should do in spacemesh terms . and also account for some expected behavior which is not a part of the spec, but might be problematic for integration such as handling reorgs

[lrettig]

@dshulyak thanks for taking a look.

beside objects that can be coerced into eth, there are many that can't. providing only eth api is not sufficient

such as? ATXs I guess? I don't know that it's critical that this API expose all data. we'll have multiple APIs. and things like ATXs, ballots, proposals, etc. are not relevant from the perspective of the wallet or the user submitting transactions.

account for some expected behavior which is not a part of the spec, but might be problematic for integration such as handling reorgs

eth has reorgs too. I don't see an issue here.

we should take reference spec for chosen API and add notes what every method means and should do in spacemesh terms

agree, this is the next step.

[dshulyak]

such as? ATXs I guess? I don't know that it's critical that this API expose all data. we'll have multiple APIs. and things like ATXs, ballots, proposals, etc. are not relevant from the perspective of the wallet or the user submitting transactions.

this is what i said. eth api is not sufficient. submitting txs is not the only use case for data api.

also because txs are not compatible there is no reason to rush implementing it, before execution / vm engine is implemented

there are also rewards that represented as separate object in spacemesh, so somehow they will need to be represented.
i proposed to save/execute them as implicit (generated after executing block) transactions, but maybe there is a simpler approach.