Add gas recommender IIP

[salaheldinsoliman]

No description provided.

[Copilot]

Pull Request Overview

The PR introduces a new IIP proposal for a gas price recommendation tool that leverages historical transaction data and real-time congestion indicators to guide transaction fee suggestions. Key changes include:

• Adding the proposal document with detailed sections on Abstract, Motivation, Specification, and Rationale.
• Describing both in-node gas price feedback and an external prediction engine.
• Outlining the design decisions and roadmap for future model comparisons.

[vekkiokonio]

The IIP present a good initial structure, but some details are missing and clarity can be improved.

[vekkiokonio]

The logic for computing the gas price feedback has slightly changed to limit codebase changes and still have an accurate estimation. @roman1e2f5p8s Can you please check this part?

[roman1e2f5p8s]

No sure what this comment is referring too. Do we need to describe the logic for computing the gas price feedback here?

[vekkiokonio]

To improve readability of the document, I would add a block diagram highlighting where (i) gas price feedback and (ii) gas price prediction get computed. It would also be nice to visually show what information is needed for the calculations

[vekkiokonio]

What do you mean here? You need to explain how the gas price feedback is given. Specifically, for canceled transactions we incapsulate the gas price feedback in the (invalid) sequence number. It would be useful to explain the logic used here. The suggested_gas_price field is only used for the computation of the feedback price, but it's not directly exposed afaiu.

[roman1e2f5p8s]

The suggested_gas_price contained in the cancellation error message is the feedback gas price.

[vekkiokonio]

This part is repeating what is already written above. I would like to see some more details on how the feedback and the prediction is computed, especially related to what information you need for the calculations

[vekkiokonio]

We could also mention Mamba (https://arxiv.org/abs/2312.00752) which is representing a breakthrough in ML prediction models

[roman1e2f5p8s]

Overall, it looks good to me. I left some suggestions and comments. More importantly, I would like to have more clarity on whether this proposal assumes in-node gas price feedback is already implemented in the protocol or not.

I would also suggest to keep lines within 80 characters for better readability and easier review.

[roman1e2f5p8s]

Suggested change

	description: An AI-assisted mechanism for estimating transaction fees in IOTA
	description: An AI-assisted mechanism for estimating gas price in IOTA

I would use "gas price" instead of "transaction fees" because it is what the recommender will be estimating.

[roman1e2f5p8s]

Suggested change

This IIP introduces a gas price recommendation mechanism for IOTA Rebased that leverages historical transaction outcomes and real-time congestion indicators to improve the user experience by reducing unnecessary fee over-payment and transaction cancellation. The mechanism is implemented as an off-chain, adaptive prediction model trained using feedback from previously cancelled and accepted transactions. At its core, the model estimates the minimal tip required for a transaction to be included under current network conditions by learning from features such as object hotness, computation cost, and scheduling outcomes. The training process uses online stochastic gradient descent to continuously refine the model with fresh data, allowing it to adapt to dynamic workloads and validator behavior. The proposed mechanism requires no changes to protocol logic and can be integrated into wallets, SDKs, and developer tooling to provide actionable, data-driven fee guidance.

This IIP introduces a gas price recommendation mechanism for IOTA that leverages historical transaction outcomes and real-time congestion indicators to improve the user experience by reducing unnecessary fee over-payment and transaction cancellation. The mechanism is implemented as an off-chain, adaptive prediction model trained using feedback from previously cancelled and accepted transactions. At its core, the model estimates the minimal gas price required for a transaction to be included under current network conditions by learning from features such as object hotness, computation cost, and scheduling outcomes. The training process uses online stochastic gradient descent to continuously refine the model with fresh data, allowing it to adapt to dynamic workloads and validator behavior. The proposed mechanism requires no changes to protocol logic and can be integrated into wallets, SDKs, and developer tooling to provide actionable, data-driven gas price guidance.

If I remember correctly, we tent not to use the term "Rebased" anymore.

[roman1e2f5p8s]

allowing it to adapt to dynamic workloads and validator behavior.

What do you mean by "validator behavior" here?

[roman1e2f5p8s]

The proposed mechanism requires no changes to protocol logic

Is it correct? The gas price feedback mechanism is required (which is on the protocol level) and a congestion tracker in the full node to dry-run transactions and get estimates.

[roman1e2f5p8s]

Suggested change

In IOTA, transactions can involve either owned objects (which are guaranteed to finalize upon passing consensus, regardless of their gas price) or shared objects (which may conflict with other transactions and cause congestion). However, the protocol currently offers no mechanism to help users estimate the appropriate tip for shared-object transactions, which are more likely to be delayed or cancelled under contention.

In IOTA, transactions can involve either only _owned objects_ (in which case such transactions are guaranteed to finalize upon passing consensus, regardless of their gas price) or contain _shared objects_ (such transactions may conflict with others, and thus, they require sequencing and might cause congestion). However, the protocol currently offers no mechanism to help users estimate the appropriate gas price for shared-object transactions, which are more likely to be delayed or cancelled under contention.

[roman1e2f5p8s]

The current mechanism lacks any feedback or proactive recommendation logic.

I am lost again. Is this proposal introduces the feedback mechanism as well, or it assumes the feedback is already provided by the protocol?

[roman1e2f5p8s]

Suggested change

	The gas price suggestion returned upon transaction cancellation is computed from real historical data observed by the node. It reflects object-level congestion at the time of deferral and uses percentile-based aggregation over recorded gas prices and execution durations. This provides immediate, data-grounded feedback to users without modifying protocol rules.
	The gas price suggestion returned upon transaction cancellation is computed from real historical data observed by the node. It reflects object-level congestion at the time of cancellation and uses statistics derived from recorded gas prices and execution durations. This provides immediate, data-grounded feedback to users without modifying protocol rules.

[roman1e2f5p8s]

without modifying protocol rules.

In-node gas price feedback does require modifications in the protocol.

[roman1e2f5p8s]

Suggested change

A learning-based model predicts, prior to submission, the minimum gas price likely required for successful inclusion. This model is trained on historical feedback collected over time. We chose online stochastic gradient descent (SGD) for its simplicity, adaptability, and low overhead in a high-throughput setting. It continuously updates per-object congestion weights and requires minimal infrastructure.

Prior to transaction submission, a learning-based model predicts the minimum gas price likely required for successful execution (i.e., cancellation due to congestion is avoided). This model is trained on historical feedback collected over time. We chose online stochastic gradient descent (SGD) for its simplicity, adaptability, and low overhead in a high-throughput setting. It continuously updates per-object congestion weights and requires minimal infrastructure.

[roman1e2f5p8s]

Suggested change

	There is a draft plan to implement and evaluate both models—online SGD and RNNs—on historical transaction datasets. This will allow for empirical comparison of accuracy, responsiveness, and usability. Depending on results, we may later recommend a more advanced architecture.
	There is a draft plan to implement and evaluate both models (online SGD and RNNs) on historical transaction datasets. This will allow for empirical comparison of accuracy, responsiveness, and usability. Depending on results, we may later recommend a more advanced architecture.

[roman1e2f5p8s]

Please put this IIP in the new folder, as IIP-3 is already taken.