HIP-584: Extend historical block support to cover system precompiles and historical EVM versions

[stoqnkpL]

Definition

We need to add support of historical blocks related to the work defined in HIP-584, so that we enrich user experience. Additionally we would want to support historical state in the context of system precompiles.

Abstract

This work package would enhance the user experience by extending eth_call to work with different block values in the context of system precompiles.

Motivation

Ongoing support of eth_call executions require full support of all possible block values for all type of read calls, including system precompiles.

Rationale

As defined in HIP-415, in Hedera the block number is the consecutive number of a record file that was streamed from the consensus nodes.

The JSON-RPC endpoint eth_call accepts a block number as an input argument. This block number specifies that the execution of eth_call has to be based on the state that is produced after the execution of all transactions into the specified block. In this way, the state would reliably reflect the changes included in the given block.

The block number can be specified in a hexadecimal format or with string values - “latest” or “earliest”. The other strings defined in Ethereum won’t be supported, since they don’t have an alternative in Hedera. These are - “pending”, “safe” and “finalized”. In order to be possible to query historical blocks, we should meet some requirements:

With the current package, we would enhance this support also for system precompiles.

User stories

1. As a user, I want to perform eth_call Ethereum JSON-RPC queries using historical blocks, calling a view function of a smart contract that in turn make calls to Hedera read only system contracts. This will allow me to see what a particular smart contract state was in the past which I can use to develop block explorers, analytical tools, etc.

Specification

1. Extend DB queries related to token and account info to filter by timestamp, defaulting to current timestamp. For some of the tables we have a normal and a historical table, that we would to query via UNION_ALL statement, sort by timestamp and limit to 1. In this way we would find the correct historical information. For the token allowances historical value - currently only the granted allowance is kept in the token_allowance_history table. More details are provided in the links below.
2. Enhance the algorithm defined in HWP-51 that determines which EVM version is valid for a given block range and which system contracts were available at the time of the block value e.g. HTSPrecompiledContract, ExchangeRatePrecompiledContract, PrngSystemPrecompiledContract . For the scope of HTSPrecompiledContract we need to support only read-related precompile calls.
3. Enhance the manual construction of the EVM and different create and call processors, as well as custom op codes to have properly constructed processors for each support evm version. They would be kept in a map, where the key would be the evm version.
4. Provide integration tests proving that historical block support for system contract related calls are working properly.
5. Provide acceptance tests proving that historical block support for system contract related calls are working properly.

Backwards compatibility

We extend the functionality of the existing code base in hedera-mirror-web3, so no implications here.

Security Implications

This work package shares the same security consideration like HIP-584 itself. We may receive a bunch of requests that put high load on the network, but we have a global rate limit mechanism over the web3 module, so we don’t have security implications specific for this work package.

References/Dependencies

1. https://hips.hedera.com/hip/hip-584
2. https://hips.hedera.com/hip/hip-415
3. Mirror-Node historical information support
4. EVM Archive Node with Historical block support for eth_call -design doc- [shared]

   ### Tasks
   - [ ] https://github.com/hashgraph/hedera-mirror-node/issues/7051
   - [ ] https://github.com/hashgraph/hedera-mirror-node/issues/7052
   - [ ] https://github.com/hashgraph/hedera-mirror-node/issues/7053
   - [ ] https://github.com/hashgraph/hedera-mirror-node/issues/7054
   - [ ] https://github.com/hashgraph/hedera-mirror-node/issues/7055
   - [ ] https://github.com/hashgraph/hedera-mirror-node/issues/7250
   - [ ] https://github.com/hashgraph/hedera-mirror-node/issues/7249
   - [ ] https://github.com/hashgraph/hedera-mirror-node/issues/7272
   - [ ] https://github.com/hashgraph/hedera-mirror-node/issues/7368
   - [ ] https://github.com/hashgraph/hedera-mirror-node/issues/7384
   - [ ] https://github.com/hashgraph/hedera-mirror-node/issues/7482
   - [ ] https://github.com/hashgraph/hedera-mirror-node/issues/7508
   - [ ] https://github.com/hashgraph/hedera-mirror-node/issues/7516
   - [ ] https://github.com/hashgraph/hedera-mirror-node/issues/7517
   - [ ] https://github.com/hashgraph/hedera-mirror-node/issues/7592

[kantorcodes]

Just flagging that implementing this would be incredibly helpful :)

[Nana-EC]

@kantorcodes thanks. Could you assist by giving a bit more information on where it's useful to you. A few questions

• What sort of contract or DApp flow do you have? We'd like to understand the user flow a bit more so any info around your context would be helpful.
• Is there a specific DApp you're intending to use this functionality in to increase our awareness?
• Does your use case relate to HTS or ERC tokens?
• How far back do you expect to call in terms of block or time? e.g. 5 blocks back from current, 1hr back in timestamp etc
• Do you repeatedly make calls for the same info or will your app cache it after first query?

Thanks

[steven-sheehy]

All sub tasks completed and v0.97 should have full historical support.