Skip to main content

Overview

The simulateTransaction endpoint in Stellar RPC allows you to submit a trial contract invocation to simulate how it would be executed by the Stellar network. This simulation calculates the effective transaction data, required authorizations, and minimal resource fee. It provides a way to test and analyze the potential outcomes of a transaction without actually submitting it to the network. It can be a nice way to get contract data as well sometimes. While calling the method on the rpc server is not the ONLY way to simulate a transaction, it will likely be the most common and easiest way. Here we will look at the objects involved and their definitions.

RPC Services

Stellar Development Foundation provides a testnet RPC service at http://soroban-testnet.stellar.org. For public network providers please refer to the Ecosystem RPC Providers list.

Testnet Endpoint:

https://soroban-testnet.stellar.org:443 SimulateTransactionParams is the argument passed to the simulateTransaction RPC endpoint:
SimulateTransactionResult is the return result from the call. It includes many useful things!

Things simulateTransaction is used for:

  1. Preparing invokeHostFunctionOp Transactions: Anytime you need to submit an invokeHostFunctionOp transaction to the network.
  2. Footprint Determination: To determine the ledger footprint, which includes all the data entries the transaction will read or write.
  3. Authorization Identification: To identify the authorizations required for the transaction.
  4. Error Detection: To detect potential errors and issues before actual submission, saving time and network resources.
  5. Restoring Archived Ledger Entries or Contract Code: To prepare and restore archived data before actual transaction submission.
  6. Simulating Contract Getter Calls: To retrieve certain data from the contract without affecting the ledger state. (It’s worth noting you could also retrieve certain contract data direct from the ledgerkeys without simulation if it doesn’t require any manipulation within the contract logic.)
  7. Resource Calculation: To calculate the necessary resources (CPU instructions, memory, etc.) that a transaction will consume.

How to Call simulateTransaction

Using Fetch

Here’s an example of how to call the simulateTransaction endpoint directly using fetch in JavaScript:

Using the JavaScript SDK

The Stellar SDK provides a convenient method to simulate a transaction:

Running the example

To run the above code, you will need to install the Stellar SDK into your project. You can do this by running the following command in your project directory: npm install @stellar/stellar-sdk Once your project is set up, you can create a new mjs file and paste the code above. You can then run the file using Node.js by running: node <filename>.mjs

Understanding the Footprint

A footprint is a set of ledger keys that the transaction will read or write. These keys are marked as either read-only or read-write:
  • Read-Only Keys: Available for reading only.
  • Read-Write Keys: Available for reading and writing.
The footprint ensures that a transaction is aware of all the ledger entries it will interact with, preventing unexpected errors during execution.

Assembling a Transaction

Once you have simulated the transaction and obtained the necessary data, you can assemble the transaction for actual submission. The assembleTransaction function in the SDK helps with this process, but you can also call prepareTransaction to have it both simulate and assemble the transaction for you in one step. Using the JavaScript SDK, we can call assembleTransaction to easily assemble a transaction.

Handling Archived Ledger Entries

When a ledger entry is archived, it needs to be restored before the transaction can be submitted. This is indicated in the restorePreamble field of the result.
Here is an example for handling restoration using the restorePreamble to restore archived data:

Fees and Resource Usage

Soroban smart contracts on Stellar use a multidimensional resource fee model, charging fees for several resource types:
  1. CPU Instructions: Number of CPU instructions the transaction uses.
  2. Ledger Entry Accesses: Reading or writing any single ledger entry.
  3. Ledger I/O: Number of bytes read from or written to the ledger.
  4. Transaction Size: Size of the transaction submitted to the network in bytes.
  5. Events & Return Value Size: Size of the events produced by the contract and the return value of the top-level contract function.
  6. Ledger Space Rent: Payment for ledger entry TTL extensions and rent payments for increasing ledger entry size.
Fees are calculated based on the resource consumption declared in the transaction. Refundable fees are charged before execution and refunded based on actual usage, while non-refundable fees are calculated from CPU instructions, read bytes, write bytes, and transaction size. Check out this document for a more in depth understanding of fees and metering.

Error Handling

The transaction simulation mechanism provides an estimation of CPU and memory consumption of a contract invocation during a transaction. It also highlights potential errors and resource limitations of the invocation before actual submission.

Backend Code and Workflow

The simulateTransaction endpoint leverages various backend components to simulate the execution of a transaction. Here is a brief explanation of how it works:
  1. Invocation of Simulation:
    • The simulation is initiated by calling simulate_invoke_host_function_op which takes in parameters such as the transaction to be simulated, resource configuration, and other necessary details.
  2. Snapshot Source and Network Configuration:
    • The simulation utilizes a snapshot source (MockSnapshotSource) and network configuration (NetworkConfig) to mimic the state of the ledger and network conditions.
  3. Resource Calculation:
    • The function simulate_invoke_host_function_op_resources computes the resources (CPU instructions, memory bytes) required for the transaction by analyzing ledger changes.
  4. Execution and Result Handling:
    • The core of the execution is handled by invoke_host_function_in_recording_mode, which records the transaction’s impact on the ledger.
    • The results are then processed, including any required authorizations, emitted events, and transaction data.
  5. Adjustments and Fees:
    • Adjustments to resource usage and fees are made based on predefined configurations (SimulationAdjustmentConfig), ensuring accurate fee estimation.
These functions are defined in the rs-soroban-env and also in a soroban-simulation crate and handle the core logic for simulating transactions.

Further Reading

For more information and examples, check out the code and other documentation: