NEO Virtual Machine Dynamic Gas Fee Charging Proposal

[Jim8y]

Summary or problem description
Propose a dynamic charging mechanism for Neo virtual machine when executing transactions, specifically for operations on types such as Buffer, Array, Struct, and Map. The charges should be based on the size (quantity) of data elements within these types, rather than a fixed fee.

Do you have any solution you want to propose?
Implement a dynamic charging mechanism as follows:

• For operations on data types such as Buffer, Array, Struct, and Map, calculate fees based on the number of elements or the size of data they contain.
• Set a base fee, then increase the fee linearly or in tiers according to the data volume.
• Different charging standards may need to be established for different types to reflect the computational resources required to process these types.

Expected outcomes:

• Users will pay lower fees for operations with small data volumes, improving the economic efficiency of small-scale transactions. (it should be expected that all normal users will pay lower, but attackers will pay his lifesavings.)
• Fees will increase correspondingly for operations with large data volumes, effectively preventing resource abuse and potential DoS attacks.
• Enhance network security and stability by increasing the cost of attacks.

Where in the software does this update applies to?

• Consensus
• Ledger
• VM

[roman-khimov]

Makes sense in general, the difference in execution time is huge depending on number of elements involved (#1875 (comment)).

[shargon]

Related to neo-project/neo-vm#245

[Jim8y]

Related to neo-project/neo-vm#245

exactly

[Jim8y]

Flexible Opcode Fees for Compound Types and Buffer

Introduction

Background

Currently, Neo employs a fixed-price model for opcode fees, regardless of the complexity or size of the data being processed. This approach, while simple, can lead to inefficiencies and potential vulnerabilities, particularly when dealing with compound types and Buffers of varying sizes.

Problem Definition

The current fixed-price model for opcode fees presents several challenges:

1. Inefficient Resource Allocation:

   • Processing compound types with different numbers of subitems consumes varying amounts of computational resources (thousands of times), yet incurs the same fee.
   • Large Buffers require more processing time and resources but are charged the same as smaller ones.

2. Potential for Exploitation:

   • Malicious actors could exploit this system by creating transactions with large compound types or Buffers, consuming disproportionate resources without corresponding fee increases.

3. Discouraged Use of Efficient Data Structures:

   • Developers might avoid using larger, more efficient data structures due to fixed costs, potentially leading to suboptimal smart contract designs.

Purpose of the Proposal

We propose implementing a flexible fee structure for opcodes related to compound types and Buffers, denoted as complex-opcode. This new system would adjust fees based on the number of subitems in compound types or the size of Buffers being processed. The primary goals of this proposal are to:

1. Improve Resource Allocation: Ensure that complex-opcode fees accurately reflect the computational resources consumed.
2. Enhance Platform Security: Mitigate potential exploits related to processing large data structures.
3. Encourage Efficient Contract Design: Provide developers with incentives to optimize their data structures and operations.
4. Maintain Platform Competitiveness: Keep Neo at the forefront of blockchain technology by implementing more granular and fair pricing mechanisms.

This flexible fee approach offers several key advantages:

• Fair Pricing: Fees will more accurately reflect the actual computational cost of operations.
• Improved Performance: Discouraging unnecessarily large data structures can lead to overall improved network performance.
• Enhanced Security: Reducing the potential for resource exploitation enhances the security of the Neo network.
• Developer Flexibility: Allows developers to make more informed decisions about data structure usage based on actual costs.

By implementing this flexible fee mechanism, Neo can offer a more efficient, secure, and developer-friendly platform, further solidifying its position as a leading blockchain for smart contract execution.

Implementation Strategy

Technical Architecture

Overview

We propose modifying the current complex-opcode fee structure for operations involving compound types and Buffers. The new system will implement a base fee plus a variable component that scales with the number of subitems or the Buffer size.

Key Components:

1. Base Fee Reduction: Lower the base fee for affected complex-opcode to accommodate the new variable component.
2. Variable Fee Component: Implement a scaling factor based on subitem count or Buffer size.
3. Fee Calculation Function: Develop a function to compute the total fee based on the base fee and variable component.

Design Considerations

1. Fee Calculation:
   The total fee for an operation is calculated using the following equation:

   $$ F_{total} = F_{base} + (V_{c} \times S_{f}) $$

   Where:

   • $F_{total}$ is the total fee of an operation
   • $F_{base}$ is the base fee for the operation
   • $V_{c}$ is the variable component (e.g., number of subitems or Buffer size)
   • $S_{f}$ is the scaling factor

   The scaling factor $S_{f}$ should be configurable by the committee to allow for future adjustments. It can be represented as:

   $$ S_{f} = \frac{F_{increment}}{V_{unit}} $$

   Where:

   • $F_{increment}$ is the fee increment per unit
   • $V_{unit}$ is the unit of measurement (e.g., per subitem or per byte)

2. Affected Opcodes:

   • Identify and modify all opcodes that interact with compound types (e.g., arrays, maps) and Buffers.
   • Examples might include operations like APPEND, REVERSE, REMOVE, etc.

3. Performance Impact:

   • Ensure that the additional computation required for fee calculation doesn't significantly impact transaction processing times.
   • The time complexity of the fee calculation should be $O(1)$ to maintain efficiency.

4. Backwards Compatibility:

   • Consider how this change might affect existing smart contracts and provide a migration path if necessary.

Conclusion

By implementing this flexible fee mechanism with precise mathematical models, Neo can offer a more efficient, secure, and developer-friendly platform. The proposed equations provide a clear and professional framework for understanding and implementing the new fee structure, ensuring fairness, optimizing resource allocation, and encouraging the development of efficient smart contracts.

[roman-khimov]

scaling factor

We already have one and it's sufficient to me.

Otherwise we need more details for opcodes, as long as we don't do neo-project/neo-vm#245 it should be OK. I'd also try concentrating on elements first (REVERSE and alike), sizes shouldn't be a big problem since neo-project/neo-vm#514 (at least probably not worth additional complexity).

[roman-khimov]

BTW, variations in #1875 (comment) are based on tests that are still available in https://github.com/nspcc-dev/neo-go/blob/0968c3a81fb034ffe95ede7667d4deb4954b4021/pkg/vm/opcodebench_test.go#L163, consider those for some of edge cases as well.