hiero-ledger / hiero-ledger/hiero-consensus-node
Enhance StandaloneDispatchFactory to consume DispatchHandleContext with custom built FeeAccumulator
- Dominant language
- Java
- Stars
- 406
- Forks
- 226
- Avg merge
- 3d 4h
- Merged PRs (30d)
- 210
Description
Mirror node should disable staking reward mechanism inside hedera-app.
Currently in the web3 module inside mirror-node we perform EVM transaction simulations via consuming the `hedera-app` artifact and building TransactionExecutor using TransactionExecutors.newExecutor method. Inside it we create a new RecordDispatch that uses a DispatchHandleContext object which is created using default values and implementation.
Inside the DispatchHandleContext there is logic related to charging and refunding gas fees utilized in TokenServiceApiImpl. In this logic there are 2 method being called, which are not needed on mirror node side and in the same time harm the performance of the module. These are `distributeToNetworkFundingAccounts` and `retractFromNetworkFundingAccounts`. We need a way to pass NO-OP implementations of these methods.
One way to do it is to build custom mirror node TokenServiceApi instance which has NO-OP implementation for the two methods or completely remove their usage. Then, mirror node can create a FeeAccumulator with this custom TokenServiceApi instance and finally, the specific FeeAccumulator can be passed in the TransactionExecutors.newExecutor method and be used in creating the DispatchHandleContext. In this way hedera-app won't perform staking reward logic during execution in the context of mirror node usage.
Contributor guide
Research direction
Start at the mirror-node web3 module's use of TransactionExecutors.newExecutor, then trace how it creates RecordDispatch and DispatchHandleContext. Review FeeAccumulator and TokenServiceApiImpl, focusing on distributeToNetworkFundingAccounts and retractFromNetworkFundingAccounts. Done means mirror-node simulations can supply a custom FeeAccumulator and avoid those staking reward operations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100