hip-584 evm module

[mustafauzunn]

Encapsulating Hedera smart contract EVM specific logic in a library.
It would expose interfaces that will allow different implementations.
Mirror node would build ethereum-related REST APIs on top of the library.
Mirror nodes could use the library to simulate a transaction and the output would be used to
populate the return value for the REST API that is invoked.
Consensus nodes would also use the library and keep their existing logic by providing specific interface implementations.

[mshakeg]

Would it make sense to specify a gas limit in this HIP or at least allow for projects that have the evm module as a dependency configure a gasLimit? Infura sets a gas limit of 120m so a minimum of that seems sensible for a hardcoded limit.

[IvanKavaldzhiev]

Hey @mshakeg , indeed, it would be good to have a default gas limit for executing these calls. However, I think the HIP is not an ideal place for specifying such a detailed property. The default value would be part of the mirror-node web3's spring boot properties and would be configureable.

[mshakeg]

Hey @IvanKavaldzhiev I see, that's reasonable. Should I instead create an issue on the mirror-node repo requesting a 120m gasLimit?

[steven-sheehy]

An issue isn't necessary as the code on the mirror node hasn't even been written yet. We will ensure such a property gets added once the implementation starts.

[mshakeg]

@steven-sheehy I see, work has only recently begun on hashgraph/hedera-mirror-node/issues/4463

[johnda98]

Soooooo.. returned data of a state via this mirror'd EVM node .. would that state data returned(at zero 'cost') be 'of value' ie how 'sure' would a caller be that that state value at time of pull, is accurate ie 'true truthed' to the consensus millisecond of the self same state data that is held in the contract on consensus nodes ?

I would presume that the degree of confidence caveat at time of pull would be 'to the millisecond of consensus reach at time of pull and within a millisecond of consensus reach derived from a consensus node evm'

[mshakeg]

@johnda98 imu the return value would be accurate to within the specified block(and its corresponding timestamp), as mirror node clients can specify the exact block they want to simulate an eth_call.

[johnda98]

interesting.. so all contracts state are precisely the same as consensus nodes and updated as if it were as such... identical except this nodes evm rejects and state change calls - Executes.

nice.. get it out there..

essentially if a Customer bases his decision and subsequent Execute call to a consensus node - it would, technically be no different in integrity than basing that decision on state pulled from a consensus node - as is currently at modest cost.

now.. what about redundancy of these new Mirrors ? I guess I would code that if Mirror connect fails then DApp would default to a at cost Query.

how will it be consumed ? gRPC .. as hitting a REST maybe too slow for some DApps.. I guess if thats the case then they just pay for reg ContractQuery calls.

sounds good.

[bguiz]

Suggestion: Split POST /api/v1/contracts/call into POST /api/v1/contracts/call and POST /api/v1/contracts/estimateGas

Rationale:

• Easier to apply different rate limit numbers and logic (as per the "security implications" section
• Easier to apply separate caching to these APIs (where applicable)
• Less complicated, and easier to explain/ teach these APIs
• Corresponds with direct mapping of RPC names (eth_call, eth_estimateGas)