simulateTransaction to expose a way to modify resources

[janewang]

What problem does your feature solve?

As this requested change is scoped specifically for simulateTransaction from stellar-core team. In march 2024, core released an ability to add a multiplicative factor or additive factor to adjust resources: https://github.com/stellar/rs-soroban-env/blob/main/soroban-simulation/src/simulation.rs#L23-L39

pub struct SimulationAdjustmentConfig {
    pub instructions: SimulationAdjustmentFactor,
    pub read_bytes: SimulationAdjustmentFactor,
    pub write_bytes: SimulationAdjustmentFactor,
    pub tx_size: SimulationAdjustmentFactor,
    pub refundable_fee: SimulationAdjustmentFactor,
}

What would you like to see?

We propose to add the following field to the optional resourceConfig in the simulateTransaction endpoint to support this change.

resourceConfig (optional)

• instructionLeeway: allows this many extra instruction when budgeting resources (already available)
• readBytesAdditiveValue
• writeBytesAdditiveValue
• txSizeAdditiveValue
• refundableFeeAdditiveValue

[ShinySyntax]

Your proposed feature addresses a specific requirement to fine-tune the resource usage during transaction simulation in Stellar's Soroban environment. By introducing the ability to adjust resources via additive values directly in the simulateTransaction endpoint, developers can more precisely manage how simulations impact system resources, aligning simulated conditions with real-world scenarios more effectively. This can be particularly beneficial in situations where developers need to account for variability in transaction size, instruction count, and data read/write operations, allowing them to anticipate and mitigate potential issues before deployment.

Here's an outline of how your proposal solves the existing problem:

1. Enhanced Resource Management: By adding parameters such as readBytesAdditiveValue, writeBytesAdditiveValue, txSizeAdditiveValue, and refundableFeeAdditiveValue, developers can adjust the simulation's resource constraints in more nuanced ways than just through multiplicative factors. This flexibility is crucial for testing how smart contracts will perform under different loads and conditions.

2. Increased Simulation Accuracy: These adjustments make the simulation process more representative of real-world operation by allowing for fine-grained control over each aspect of resource consumption. This accuracy is particularly useful in a blockchain environment where efficiency and optimization are critical.

3. Improved Debugging and Testing: The ability to tweak these values directly in the simulation request makes it easier to identify potential performance bottlenecks and optimize contract code accordingly before it goes live. It can also help in stress testing the system against extreme conditions.

4. User-Friendly Configuration: Including these configurations directly in the simulateTransaction endpoint as optional fields maintains the user-friendliness of the API, allowing developers to opt-in to advanced configurations as needed without overwhelming the basic functionality.

5. Proactive Issue Resolution: By simulating transactions with added flexibility in resource configuration, developers can proactively resolve issues that might arise due to resource constraints in the live environment, thereby reducing the risk of failed transactions due to unexpected conditions.

In summary, your proposal to extend the simulateTransaction endpoint with additive resource configuration options allows developers to achieve a higher degree of precision in their simulations, leading to more robust and reliable smart contract deployment on the Stellar network.

[silence48]

refundableFeeAdditiveValue would sure have saved some headaches