Determine the gas consumption of opcodes #1281
Assignees
Comments
piux2
added a commit
that referenced
this issue
Apr 25, 2024
<!-- please provide a detailed description of the changes made in this pull request. --> <details><summary>Contributors' checklist...</summary> - [x] Added new tests - [ ] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [ ] Updated the official documentation or not needed - [x] No breaking changes were made - [x] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details> Ref: #1070 #1067 #649 #1281 ## Summary The current gno.land node, optimized for development purposes, has a simplified verification process and gas meter implementation. To transition the gno.land node to a production-ready state, it is necessary to implement a comprehensive gas metering system that accurately accounts for VM gas consumption. This includes refining the gas fee structure to encompass all relevant costs, ensuring robust transaction validation, and calculating gas consumption based on actual computational load. This PR aims to address these limitations by introducing a complete gas meter and validation flow, laying the groundwork for further gas meter profiling and configuration. ## Problem Definition Current State and Limitations for Production: - **VM Gas Consumption Not Accounted in Gas Meter:** The current gas meter fails to calculate VM gas consumption, potentially allowing heavy contract loads without corresponding gas meter deductions. A refined system should measure and charge for VM gas usage accurately. - **Gas Fee Structure:** Presently, the gas fee structure only includes storage access, transaction size, and signature verification. VM gas fees are levied as a separate, flat fee, which might lead to confusion among users expecting the total fee to match the amount specified in the 'gas-fee' argument. For improved transparency and precision, the gas fee structure should integrate all these aspects. - **Transaction Validation:** The system currently validates basic information for VM msg_addpkg and msg_call. However, gas consumption cannot be determined before fully executing these messages against the VM. Consequently, VM transactions are placed in the mempool and propagated to other nodes, even if they may not meet the gas fee requirements to execute these transactions. This undermines the purpose of using gas fees to prevent VM spamming. ## Solution: ( Updated ) This is a high-level description of the implemented features: ~~Added an anteHandler in VM to monitor gas consumption~~ ~~Implemented chained VM anteHandler in auth.anteHandler~~ - Consume gas to verify account, signature and tx size in CheckTx - Consume VM gas in DeliverTx - Accumulated VM CPU cycles, memory allocation, store access, transaction size, and signature verification into a single gas meter. - Enabled local node checks of VM resource usage. The VM message is only aborted if it runs out of gas in basic CheckTx. However, the message is still propagated to other nodes if execution fails to prevent censorship - Introduced a structured format for logging gas consumption for profiling and metrics. - Introduced a gas factor linking gas to vm CPU cycles and memory allocation to balance between vm gas consumption with the rest. ## Trade-offs and Future Optimization: ( Updated ) ~~The current implementation processes messages against the VM to check gas consumption in abci.CheckTx() before inclusion in the mempool and propagation to other nodes.~~ ~~Messages lacking sufficient gas-wanted will be dropped, preventing abuse without adequate gas fees. However, the trade-off is that for each message with enough gas, the VM executes the transaction twice: once in CheckTx() and once in DeliverTx(). As these occur in separate execution contexts and are not in synchronized sequence, the performance impact is currently a secondary concern.~~ We moved the VM gas check from CheckTx to DeliverTx for the following reasons: - We only know the VM gas consumption after the messages have been processed. - Running VM execution for many CheckTx requests from the peers could overload the mempool that is executing CheckTx. - This could slow down the propagation of transactions across the entire network. By moving the VM gas check from CheckTx to DeliverTx, we are able to reduce the load on the mempool of a node and allow transactions to propagate through the network faster. In the future, we may use a predicted median value instead of the exact value from transaction execution for efficiency. ## What's Next: - Add a minimum gas price flag and configuration for node operation. - Provide a user-friendly fee input interface, offering 'gas-wanted' and 'gas price' as alternatives to the current 'gas-wanted' and 'gas-fee' inputs. - Tune the gas factor based on VM CPU and Memory Profiling. The current factor is 1:1 between gas and VM CPU cycles and memory allocation. --------- Co-authored-by: Thomas Bruyelle <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To determine the gas consumption of opcodes, we should collect metrics to establish the appropriate opcode gas configuration for the mainnet. Please refer to the following link for more information: github.com/gnolang/gno/blob/master/gnovm/pkg/gnolang/machine.go#L762-L881
cc @peter7891 @leohhhn @MichaelFrazzy @mvertes
Related with #1430
Related with #1106
The text was updated successfully, but these errors were encountered: